I'm developing a couple of applications that I need some advice on which
database structure to use. My first thought is SQL Server of course, but
after looking at my potential users and their needs, I'm having second
thoughts.

My #1 goal (besides the apps working properly of course) is to simplify
deployment and database set up, as I will have a wide range of users, from
those who have just bought a PC, to students, to companies with SQL Servers.

I have two completedly independent apps:

App 1: A standalone VB app that will be single user. No need to communicate
or share with anything else. For that app I'm thinking a Access database
and ADO would be fine. I'm also wondering if making the app utilitize web
forms might help in simplicity and deployment, or, if the .NET framework is
there anyway and required for the app, if it makes any difference and it
would just be better to use Win forms to get better looking controls for the
forms.

App 2: A VB app that will have a thin client on the individual PC's, but
will pull data off a centralized location. The volume of data and traffic
to and from the database will be extremely low. I was originally thinking
SQL for this, but I'm wondering for my inexperienced users, if going with a
Access db would be better for them too. I'm also thinking web forms on this
too, especially to prevent administrators from having to install on every
PC. I assume the app would just have the Access db in the directory it's
installed to. Remember #1 goal is deployment and setup ease.

If there are better ways to do this to make this the simpliest for my users
so they don't have to install SQL, please let me know. If I'm way off-base,
let me know, I'm open to all valid suggestions. tia. z

What difference would it make to the user which DB you used? Wouldn't that
be transparent to them?

Bob Lehmann

"z" <(E-Mail Removed)> wrote in message newsaPrc.6384$hi6.641434@attbi_s53...
> I'm developing a couple of applications that I need some advice on which
> database structure to use. My first thought is SQL Server of course, but
> after looking at my potential users and their needs, I'm having second
> thoughts.
>
> My #1 goal (besides the apps working properly of course) is to simplify
> deployment and database set up, as I will have a wide range of users, from
> those who have just bought a PC, to students, to companies with SQL
Servers.
>
> I have two completedly independent apps:
>
> App 1: A standalone VB app that will be single user. No need to
communicate
> or share with anything else. For that app I'm thinking a Access database
> and ADO would be fine. I'm also wondering if making the app utilitize web
> forms might help in simplicity and deployment, or, if the .NET framework
is
> there anyway and required for the app, if it makes any difference and it
> would just be better to use Win forms to get better looking controls for
the
> forms.
>
> App 2: A VB app that will have a thin client on the individual PC's, but
> will pull data off a centralized location. The volume of data and traffic
> to and from the database will be extremely low. I was originally thinking
> SQL for this, but I'm wondering for my inexperienced users, if going with
a
> Access db would be better for them too. I'm also thinking web forms on
this
> too, especially to prevent administrators from having to install on every
> PC. I assume the app would just have the Access db in the directory it's
> installed to. Remember #1 goal is deployment and setup ease.
>
> If there are better ways to do this to make this the simpliest for my
users
> so they don't have to install SQL, please let me know. If I'm way
off-base,
> let me know, I'm open to all valid suggestions. tia. z
>
>
>

I don't think Web Forms would make sense for App 1 if it's supposed to be a
standalone application. All of the clients would have to to be running IIS -
that's probably unlikely. If you're deploying a bunch of Access databases
and later on you want to make a change to the database, you'll have to
redeploy the application and migrate existing databases.

For App 2, if the database is centralized then the database you choose for
your application shouldn't affect how difficult the application is to use.
The thing to worry about when using an Access backend is concurrent
connections and database size, which you mentioned shouldn't be an issue.
Web Forms would make sense for App 2, the clients wouldn't have to install
anything.

"z" <(E-Mail Removed)> wrote in message newsaPrc.6384$hi6.641434@attbi_s53...
> I'm developing a couple of applications that I need some advice on which
> database structure to use. My first thought is SQL Server of course, but
> after looking at my potential users and their needs, I'm having second
> thoughts.
>
> My #1 goal (besides the apps working properly of course) is to simplify
> deployment and database set up, as I will have a wide range of users, from
> those who have just bought a PC, to students, to companies with SQL
Servers.
>
> I have two completedly independent apps:
>
> App 1: A standalone VB app that will be single user. No need to
communicate
> or share with anything else. For that app I'm thinking a Access database
> and ADO would be fine. I'm also wondering if making the app utilitize web
> forms might help in simplicity and deployment, or, if the .NET framework
is
> there anyway and required for the app, if it makes any difference and it
> would just be better to use Win forms to get better looking controls for
the
> forms.
>
> App 2: A VB app that will have a thin client on the individual PC's, but
> will pull data off a centralized location. The volume of data and traffic
> to and from the database will be extremely low. I was originally thinking
> SQL for this, but I'm wondering for my inexperienced users, if going with
a
> Access db would be better for them too. I'm also thinking web forms on
this
> too, especially to prevent administrators from having to install on every
> PC. I assume the app would just have the Access db in the directory it's
> installed to. Remember #1 goal is deployment and setup ease.
>
> If there are better ways to do this to make this the simpliest for my
users
> so they don't have to install SQL, please let me know. If I'm way
off-base,
> let me know, I'm open to all valid suggestions. tia. z
>
>
>