Install Package: VB6.0 w/ SQL Server 2000

Hello,
I want to upgrade my Access 2003 app to have a
VB 6.0 front-end and SQL Server 2000 Standard back-end, that I want
to sell on the market. I do not want to use MSDE
because of the 2GB limitation. My questions are:
1) will my customers have to purchase SQL Server 2000?
(or me, and then give them the copy w/ my app).
2) what is the best way to wrap this up in an install
package? I already have InstallShield Express 4.0
and SageKey's Access 2003 MSI Wizard; am investigating
if these will let me include SQL Server. . . any ideas
on how to mass-sell something w/ SQL Server back-end?
Thanks,
Christy Warner.
Christy Warner
www.autoaudit.com
Christy Warner
www.autoaudit.com
"ChristyWarner" <cwarner@.autoaudit.com> wrote in message
news:DB69C611-0E69-47B1-B940-4FAB81DA9C36@.microsoft.com...
> Hello,
> I want to upgrade my Access 2003 app to have a
> VB 6.0 front-end and SQL Server 2000 Standard back-end, that I want
> to sell on the market. I do not want to use MSDE
> because of the 2GB limitation. My questions are:
Access suffers from the same 2 GB limitation on database size.

> 1) will my customers have to purchase SQL Server 2000?
> (or me, and then give them the copy w/ my app).
If MSDE is not an option, your customers should probably have SQL Server. I
wouldn't recommend buying a bunch of copies of SQL Server to bundle with
your app, as you don't necessarily know your clients' licensing needs, etc.

> 2) what is the best way to wrap this up in an install
> package? I already have InstallShield Express 4.0
> and SageKey's Access 2003 MSI Wizard; am investigating
> if these will let me include SQL Server. . . any ideas
> on how to mass-sell something w/ SQL Server back-end?
People mass-market SQL Server specific products all the time. You basically
need to test it on SQL Server and make sure you specify it in the system
requirements for your app. A quick question - are you selling to home users
or businesses? If you're selling to individual home users or small
businesses, you might reconsider using MSDE, as it is freely available, and
the 2 GB restriction shouldn't be so bad for an app that previously ran on
Access.
|||Yes, selling to businesses, hopefully larger ones, which is why
I'm switching to SQL Server.
When my customers install their SQL Server, can I still refer
to it in my VB code w/ the same connection string? e.g. server=(local),
or do I have to specify an exact server name that the customer
has assigned?
thanks,
Christy.
"Michael C#" wrote:

> "ChristyWarner" <cwarner@.autoaudit.com> wrote in message
> news:DB69C611-0E69-47B1-B940-4FAB81DA9C36@.microsoft.com...
> Access suffers from the same 2 GB limitation on database size.
>
> If MSDE is not an option, your customers should probably have SQL Server. I
> wouldn't recommend buying a bunch of copies of SQL Server to bundle with
> your app, as you don't necessarily know your clients' licensing needs, etc.
>
> People mass-market SQL Server specific products all the time. You basically
> need to test it on SQL Server and make sure you specify it in the system
> requirements for your app. A quick question - are you selling to home users
> or businesses? If you're selling to individual home users or small
> businesses, you might reconsider using MSDE, as it is freely available, and
> the 2 GB restriction shouldn't be so bad for an app that previously ran on
> Access.
>
>
|||It's best to give the customer an option to configure their SQL Server
settings themselves, either during Setup or within the app itself. If
you're planning to mass-market your app, you definitely need to allow for
changes to the connection settings somehow - not every business is going to
have their network configured the same way and you can't necessarily count
on the fact that they'll be running your app on the same box as SQL Server.
Additionally, they might be using SQL Authentication instead of Windows
Integrated, in which case they'll need to access the login
username/password, etc. And hard-coding your username/password into your
app is big security no-no; sticking the customer with a username/password
combo that might not meet their security policies and requirements is also
not a good thing.
"ChristyWarner" <cwarner@.autoaudit.com> wrote in message
news:43C2467F-8064-4822-9402-19482E8D3EE3@.microsoft.com...[vbcol=seagreen]
> Yes, selling to businesses, hopefully larger ones, which is why
> I'm switching to SQL Server.
> When my customers install their SQL Server, can I still refer
> to it in my VB code w/ the same connection string? e.g. server=(local),
> or do I have to specify an exact server name that the customer
> has assigned?
> thanks,
> Christy.
> "Michael C#" wrote: