Access vs SQL

[lgbjr]

Hello All,

I've been developing a VB.NET app that requires the use of a DB. Up to now,
I've been using Access. It's a bit slow, but everything works. I'm at a
point now where I need to decide if I should stay with Access or move the DB
to SQL. I'm trying to come up with a list of Pros/Cons for such a move. My
list is a bit lopsided, as I have very little experience with SQL and quite
a bit with Access.

PROS for moving to SQL:
Increased Performance?
Increased Reliability?
Lifecycle of Access?
Future Access Version compatibility issues?

CONS for moving to SQL:
My limited knowledge of SQL
Clients not required to have an SQL server

I've added a few items to the PROS list, but with ?s, as I don't really
know.

If there are a few Access advocates and SQL advocates out there that could
give me some viewpoints, I'd be more comfortable making a decision based on
the facts, rather than my limited knowledge.

TIA
Lee

[Ken Tucker [MVP]]

Hi,

The MSDE is a free scaled back version of sql server. So the
client isn't required to buy sql server. If you design an app using msde
and later need the networking features of sql server it is real easy to
upgrade you app.

http://msdn.microsoft.com/library/de.../usingmsde.asp

http://www.microsoft.com/downloads/d...DisplayLang=en

Ken
--------------------
"lgbjr" <lg***@online.nospam> wrote in message
news:ex**************@TK2MSFTNGP09.phx.gbl...
Hello All,

I've been developing a VB.NET app that requires the use of a DB. Up to now,
I've been using Access. It's a bit slow, but everything works. I'm at a
point now where I need to decide if I should stay with Access or move the DB
to SQL. I'm trying to come up with a list of Pros/Cons for such a move. My
list is a bit lopsided, as I have very little experience with SQL and quite
a bit with Access.

PROS for moving to SQL:
Increased Performance?
Increased Reliability?
Lifecycle of Access?
Future Access Version compatibility issues?

CONS for moving to SQL:
My limited knowledge of SQL
Clients not required to have an SQL server

I've added a few items to the PROS list, but with ?s, as I don't really
know.

If there are a few Access advocates and SQL advocates out there that could
give me some viewpoints, I'd be more comfortable making a decision based on
the facts, rather than my limited knowledge.

TIA
Lee

[Scott M.]

You've got a CON for SQL that "Clients not required to have an SQL server".
I'd say that's a PRO.

Here are some other major issues to consider:

Access has limited concurrent connection support while SQL Server was
designed as a server, so it supports many concurrent connections.
Access does not support Stored Procedures but SQL Server does.
Access does not implement any db security (beyond a db password), but SQL
Server has a robust security model.
"lgbjr" <lg***@online.nospam> wrote in message
news:ex**************@TK2MSFTNGP09.phx.gbl...

Hello All,

I've been developing a VB.NET app that requires the use of a DB. Up to
now, I've been using Access. It's a bit slow, but everything works. I'm at
a point now where I need to decide if I should stay with Access or move
the DB to SQL. I'm trying to come up with a list of Pros/Cons for such a
move. My list is a bit lopsided, as I have very little experience with SQL
and quite a bit with Access.

PROS for moving to SQL:
Increased Performance?
Increased Reliability?
Lifecycle of Access?
Future Access Version compatibility issues?

CONS for moving to SQL:
My limited knowledge of SQL
Clients not required to have an SQL server

I've added a few items to the PROS list, but with ?s, as I don't really
know.

If there are a few Access advocates and SQL advocates out there that could
give me some viewpoints, I'd be more comfortable making a decision based
on the facts, rather than my limited knowledge.

TIA
Lee

[lgbjr]

Scott and Ken,

For staying with Access, you're right, that should be a PRO.

Thanks for the tips. I guess I sort of knew these things, just from the
reading I've done. And, I'm almost certain that the right long term decision
is to move to SQL Server. I think I might take Ken's advice and take a baby
step in what is probably the right direction by using MSDE to start.

My basic concern is not my lack of SQL Server knowledge. I just felt that
using SQL Server for what my app needs was a bit of overkill. And, thus,
requiring my clients to purchase SQL Server seemed wrong. But, this thinking
is based on what my app does today.

So, no decision yet, but, I think MSDE gives me the easy scalability for the
future, without the overkill of SQL Server today.

Thanks!

Lee
"Scott M." <s-***@nospam.nospam> wrote in message
news:eT**************@TK2MSFTNGP09.phx.gbl...

You've got a CON for SQL that "Clients not required to have an SQL
server". I'd say that's a PRO.

Here are some other major issues to consider:

Access has limited concurrent connection support while SQL Server was
designed as a server, so it supports many concurrent connections.
Access does not support Stored Procedures but SQL Server does.
Access does not implement any db security (beyond a db password), but SQL
Server has a robust security model.
"lgbjr" <lg***@online.nospam> wrote in message
news:ex**************@TK2MSFTNGP09.phx.gbl...

Hello All,

I've been developing a VB.NET app that requires the use of a DB. Up to
now, I've been using Access. It's a bit slow, but everything works. I'm
at a point now where I need to decide if I should stay with Access or
move the DB to SQL. I'm trying to come up with a list of Pros/Cons for
such a move. My list is a bit lopsided, as I have very little experience
with SQL and quite a bit with Access.

PROS for moving to SQL:
Increased Performance?
Increased Reliability?
Lifecycle of Access?
Future Access Version compatibility issues?

CONS for moving to SQL:
My limited knowledge of SQL
Clients not required to have an SQL server

I've added a few items to the PROS list, but with ?s, as I don't really
know.

If there are a few Access advocates and SQL advocates out there that
could give me some viewpoints, I'd be more comfortable making a decision
based on the facts, rather than my limited knowledge.

TIA
Lee

[Cor Ligthert]

lgbjr,

Not that I am against any database however the major pro for me from access.
And that only because that I have not seen it yet.

Access is very easy to install and it is portable.

Cor

[Cor Ligthert]

Scott,

Access does not support Stored Procedures but SQL Server does.

See in this procedure
http://msdn.microsoft.com/library/de...l/acadvsql.asp

Cor

[J L]

Hi Igbjr,
I am in exactly the same situation as you. My biggest concerns about
SQL or any other server based DB are (1) the initial
installation/setup issues and (2) the skill level required by my
customers to maintain it. My customer base is the food industry and
for the most part they do not have IT departments and DBA's in the
packing plants to support "high technology". And it does not have to
be very "high" to exceed their limits.

I have used Access for many years and found it easy on both accounts.
Since my databases are only accessed programatically and I do not use
bound controls but open/close very quickly, I have never ran into
concurrency issues. I have also not found problems with MDB file size
yet but that is my major concern.

In addition to MSDE as a starting point, I am also considering MySql
and Firebird.

So I will continue to lurk this thread and hope you get more insight
form the Gurus. Also would appreciate hearing how you will make your
decision to move away from Access.

John

On Sat, 9 Apr 2005 20:29:05 +0800, "lgbjr" <lg***@online.nospam>
wrote:

Scott and Ken,

For staying with Access, you're right, that should be a PRO.

Thanks for the tips. I guess I sort of knew these things, just from the
reading I've done. And, I'm almost certain that the right long term decision
is to move to SQL Server. I think I might take Ken's advice and take a baby
step in what is probably the right direction by using MSDE to start.

My basic concern is not my lack of SQL Server knowledge. I just felt that
using SQL Server for what my app needs was a bit of overkill. And, thus,
requiring my clients to purchase SQL Server seemed wrong. But, this thinking
is based on what my app does today.

So, no decision yet, but, I think MSDE gives me the easy scalability for the
future, without the overkill of SQL Server today.

Thanks!

Lee
"Scott M." <s-***@nospam.nospam> wrote in message
news:eT**************@TK2MSFTNGP09.phx.gbl...

You've got a CON for SQL that "Clients not required to have an SQL
server". I'd say that's a PRO.

Here are some other major issues to consider:

Access has limited concurrent connection support while SQL Server was
designed as a server, so it supports many concurrent connections.
Access does not support Stored Procedures but SQL Server does.
Access does not implement any db security (beyond a db password), but SQL
Server has a robust security model.
"lgbjr" <lg***@online.nospam> wrote in message
news:ex**************@TK2MSFTNGP09.phx.gbl...

Hello All,

I've been developing a VB.NET app that requires the use of a DB. Up to
now, I've been using Access. It's a bit slow, but everything works. I'm
at a point now where I need to decide if I should stay with Access or
move the DB to SQL. I'm trying to come up with a list of Pros/Cons for
such a move. My list is a bit lopsided, as I have very little experience
with SQL and quite a bit with Access.

PROS for moving to SQL:
Increased Performance?
Increased Reliability?
Lifecycle of Access?
Future Access Version compatibility issues?

CONS for moving to SQL:
My limited knowledge of SQL
Clients not required to have an SQL server

I've added a few items to the PROS list, but with ?s, as I don't really
know.

If there are a few Access advocates and SQL advocates out there that
could give me some viewpoints, I'd be more comfortable making a decision
based on the facts, rather than my limited knowledge.

TIA
Lee

[Gerald Hernandez]

"lgbjr" <lg***@online.nospam> wrote in message
news:ex**************@TK2MSFTNGP09.phx.gbl...

Hello All,

I've been developing a VB.NET app that requires the use of a DB. Up to now, I've been using Access. It's a bit slow, but everything works. I'm at a
point now where I need to decide if I should stay with Access or move the DB to SQL. I'm trying to come up with a list of Pros/Cons for such a move. My
list is a bit lopsided, as I have very little experience with SQL and quite a bit with Access.

<Snipped>

As you have found, sometimes there is no clear winner out of the gate.
As others have mentioned, let's add the 3rd option of MSDE, so the basic
choices we are considering are Access, MSDE, and SQL.
Each of those options can be made to do just about anything you need, with
increased options as you go up the list.
So I propose that instead of basing your decisions on the merits of each DB
engine, consider the needs of your application and customers. Then go down
the list and see which one fits each item and score it.

How many users will need to access the database simultaneously?
Are you using the database primarily as a storage place, or do you have many
updates?
How much data are you storing?
How processor intensive is your application?
Do the customers need to use and/or manage the database outside of your
application?

Access:
Best for single user. But can support many users if necessary.
Pros:
Works great as a storage container. Works best for smaller amounts of data,
say dozens of MB. Although you can get close to 2GB.
Fairly decent if your application is processor intensive.
Works great in low memory environment.
Easy to manage.
Very portable and easy to install just about anywhere.
Cons:
If you have many updates then you need to constantly compact it. The 2GB
limit can be reached fairly easily if you have lots of updates.
Inefficient across a network.
Version updates can be problematic.
Best performance if you use DAO. Future upgrade to MSDE or SQL is not
seemless and requires many code changes.
Can use ADO for near seemless upgrade to MSDE or SQL, but performance is
much less than DAO.

MSDE:
Best for 2-5 users. Can support more, but don't exceed 25.
Pros:
Handles many updates more efficiently than Access.
Can store up to 2GB per database.
No additional cost to your clients.
Near seemless upgrade to full SQL. Usually few, if any, code changes needed.
Cons:
If your application is processor intensive, then you should set up a
seperate server machine. If loaded on the same machine, then the processor
requirements of your application could negate any performance gains.
Requires more memory. If your database is small, can be less efficient than
Access.
Designed to be managed completely by your application. Not easy for clients
to manage.
Less portable than Access.

SQL:
Best for 6+ users.
Pros:
Handles queries and updates very efficiently.
Can store up to 2GB+ (depending upon version, OS, etc) per database.
Can be easily managed and accessed by your clients.
Cons:
Should really have a seperate machine, preferrably a server, dedicated to
it.
Requires a great deal of memory.
Can require significant additional cost to your clients. Need Server OS and
client licensese, SQL Server software, server license, plus client licenses.
I wouldn't consider it portable at all.
It is quite possible that moving up to MSDE might be a great choice.
However, if you really don't need it, it is also quite likely that with
tweaking you could significantly improve the performance of your Access
code. Quite often, simple things like the choice of your Cursor location and
recordset type can have large performance differences when using Access.

Hope this helps.
Gerald

[Richard Myers]

> My basic concern is not my lack of SQL Server knowledge. I just felt that

using SQL Server for what my app needs was a bit of overkill. And, thus,
requiring my clients to purchase SQL Server seemed wrong. But, this thinking is based on what my app does today.

You can administer MSDE through an Access front via *.adp Projects. There
are also a bunch of free utilities out there to do this for you.
Your right to base your decision on what your application does today not
tomorrow..... thats why you undertake a requirements definition and
vigilantly guard against *creeping scope*.
..
From a coding standpoint the best thing you can do re: future proofing is
too ensure you have proper separation of your data access layers.

A change of DAL 18 months from now should not neccessitate a complete
rewrite. In fact it could be considered a marketable feature/benefit
if you design your DAL correctly using say the *Provider Pattern* that your
application can run on the *customers* choice of data store - XML, my sql-
whatever - this could be decided on a per client basis ( subject to your
support preferences of course).

I appreciate you're on a knowledge quest but if you really want future
proofing Id start with application design, proper nTier development and
pattern usage. If you do this correctly choice of datastore should almost
be as easy as plug and play.

Richard

[lgbjr]

Hello All,

Thank You for your responses! All of you have given me quite a bit to think
about!

Richard, I understand completely. A bit of background: Even though I am
developing a software package, I would not, by any stretch of the
imagination, consider myself a software developer. I'm an Engineering
Consultant for the Mobile Communications Industry. For the past 10 years,
I've been writing PERL apps (when necessary) to automate repetitive tasks
and make my life easier. These apps were for my use only. Over the years, I
have had several clients ask me to provide these small apps to them. So, I
moved from writing plain code, to writing an app with a user-friendly
interface. Now, my clients want more. And they're willing to pay for it
(above and beyond what they pay for my engineering services). Fortunately, I
knew enough to write a scope of work (basically for myself), just as I would
do for a typical engineering project. So, I do understand 'creeping scope'.

Regarding the ability to 'Plug and Play' a variety of DB engines, I have
considered this as well. At the beginning of this project, I was using C1
Express components (no data adapters, no datasets, just Express Tables and
an Express connection (OLEDB)). While this was extremely easy to implement,
I realized that there was no upgrade path (upgrade = rewrite). Now, still
using C1 components, I know (think) I can upsize to MSDE or SQL Server with
only minor code changes.

Gerald, I agree. Rather than trying to decide which DB engine is better,
it's safe to say that all are good, if used in the environment they were
designed for. Right now, wihtout thinking about growth, I could deploy with
Access (1-2 users performing updates, additional 3-4 users viewing data,
approximately 1-1.5GB size). But, this, based on what I have read, and your
comments, is near the upper limit of what Access was designed for.

JL, though it may not seem so, I am in a similar situation regarding IT
support. Even though all of the mobile operators have extensive IT
departments, the engineering and IT departments are always fighting. So, I
need my app to be self-maintainable.

After posting this, I'm going to install SQL2KDesktop (MSDE) and try to get
a feel for what it will take to do a migration (I already have SQL Server
running on another machine). I like Richard's idea of allowing the client to
decide which DB engine to use. Hopefully my coding and forward-thinking was
robust enough to allow this with only some minor tweaks. However, if I get
lost in a sea of errors, I think my backup will be to use MSDE.

Again, thanks for your insights!!

Regards,
Lee

"lgbjr" <lg***@online.nospam> wrote in message
news:ex**************@TK2MSFTNGP09.phx.gbl...

Hello All,

I've been developing a VB.NET app that requires the use of a DB. Up to
now, I've been using Access. It's a bit slow, but everything works. I'm at
a point now where I need to decide if I should stay with Access or move
the DB to SQL. I'm trying to come up with a list of Pros/Cons for such a
move. My list is a bit lopsided, as I have very little experience with SQL
and quite a bit with Access.

PROS for moving to SQL:
Increased Performance?
Increased Reliability?
Lifecycle of Access?
Future Access Version compatibility issues?

CONS for moving to SQL:
My limited knowledge of SQL
Clients not required to have an SQL server

I've added a few items to the PROS list, but with ?s, as I don't really
know.

If there are a few Access advocates and SQL advocates out there that could
give me some viewpoints, I'd be more comfortable making a decision based
on the facts, rather than my limited knowledge.

TIA
Lee

[aatcbbtccctc]

Haven't read all the replies, so apologies if this has aready been
said:

1. Access is *not* a database. It is a front-end IDE. The underlying
database for Access is normally MS Jet, a comlementary but completely
seperate product. You can have an Access front-end with any compatible
database including but not limited to Jet, Oracle, SQL Server, etc.
Conversely, you can use a Jet database with any complementary front-end
including but not limited to Access, VB, etc.

2. SQL also is *not* a database. SQL is a data access language which is
used in many databases, including but not limited to Jet, SQL Server,
Oracle, etc.

IOW, please let's get the terminolgy right :-)

HTH,
TC

[Steve]

> After posting this, I'm going to install SQL2KDesktop (MSDE) and try to

get a feel for what it will take to do a migration (I already have SQL
Server running on another machine). I like Richard's idea of allowing the
client to decide which DB engine to use. Hopefully my coding and
forward-thinking was robust enough to allow this with only some minor
tweaks. However, if I get lost in a sea of errors, I think my backup will
be to use MSDE.

You might want to check this out too Lee

http://www.asql.biz/DbaMgr.shtm

It's a very nice (and free) admin GUI for MSDE. Very useful since MSDE comes
with nothing

Steve

[Cor Ligthert]

>

1. Access is *not* a database.

In my opinion is this sentence wrong.

It is not a database *server* however it is a database system in a file.

I hope this helps,

Cor

[lgbjr]

I agree, and apologies. I do understand the difference between SQL
(Structured Query Language) and an SQL Server (which provides a database
environment in which SQL is used to access and manipulate data). And I also
argree that MS Access as a product is not a database, it's an IDE for
developing a DB front end.

However, I think everyone that has replied to my post understood what I was
talking about (I hope)

Either way, I'll try to be more careful with my wording.

Cheers
Lee

<aa**********@yahoo.com> wrote in message
news:11*********************@o13g2000cwo.googlegro ups.com...

Haven't read all the replies, so apologies if this has aready been
said:

1. Access is *not* a database. It is a front-end IDE. The underlying
database for Access is normally MS Jet, a comlementary but completely
seperate product. You can have an Access front-end with any compatible
database including but not limited to Jet, Oracle, SQL Server, etc.
Conversely, you can use a Jet database with any complementary front-end
including but not limited to Access, VB, etc.

2. SQL also is *not* a database. SQL is a data access language which is
used in many databases, including but not limited to Jet, SQL Server,
Oracle, etc.

IOW, please let's get the terminolgy right :-)

HTH,
TC

[Cor Ligthert]

lgbjr,

And I also agree that MS Access as a product is not a database, it's an IDE
for developing a DB front end.

As I wrote in my previous message this is not true, I have the idea you are
talking about the MS office Access product. You can create an access
database using ADO in your program as a part of your development.

Cor

[lgbjr]

Cor,

I think this is a symantics issue. I will agree that throughout the user
populance, many people refer to Access, MS Access, an Access DB, etc. as
being a database. While this has been / is acceptable for most people, I
believe what TC said is technically correct.

Most people open MS Access, create some tables, queries, forms, modules,
etc. and the language used to drive the front end is VBA (forms, modules,
etc). Most are unaware that the actual DB engine is not Access (as there's
no such thing), it's Jet (by default).

After loading MSDE, since it doesn't have a GUI, I am using MS Access, via
an ADP project, to make modifications to the MSDE DB (SQL Server DB). If MS
Access were, as you're implying, a database engine, you wouldn't be able to
change database engines in the product. Therefore, MS Access should really
be thought about and talked about as an IDE that supports several DB engines
(similar to VS.NET being an IDE that supports several programming
languages).

Again, I believe this is a symantics issue. Everyone knows/knew what I was
talking about, but, from now on, when I catch myself refering to an Access
DB, I'll replace that with a Jet DB with a front end built in MS Access, or
whatever DB engine I happen to be using.

Of course, if I talk to my clients about a Jet DB, I'll just get blank
stares and questions about what happened to the Access DB. ;-)

Cheers
Lee
"Cor Ligthert" <no************@planet.nl> wrote in message
news:O7*************@TK2MSFTNGP12.phx.gbl...

lgbjr,

And I also agree that MS Access as a product is not a database, it's an
IDE for developing a DB front end.

As I wrote in my previous message this is not true, I have the idea you
are talking about the MS office Access product. You can create an access
database using ADO in your program as a part of your development.

Cor

[Cor Ligthert]

Lee,

An answer without words,

http://support.microsoft.com/default...b;en-us;823927

:-)))

Cor

[aatcbbtccctc]

Not so, Cor.

MS Access does not contain any of the base technologies for creating &
managing tables & indexes; parsing, optimizing & executing SQL; or any
of the other things that database products have to do.

Those technologies all reside in a completely seperate product, MS Jet.
Access uses the Jet API to create & maintain tables & indexes, execute
SQL, and so on.

Access does ask Jet (via a Jet API) to create, within the MDB file,
some containers for Access to store its own things (forms, reports
etc.) - but that does not make Access, a database.

I suspect your mistake is in believing that an MDB file is an *Access*
file. It is not - it is a *Jet* file, in which Access is able to store
its own things (in addition to the standard Jet things).

A VB program can use a Jet MDB file for database storage; but VB is not
Access, and does not require Access to be present in any way, shape or
form.

HTH
TC

[aatcbbtccctc]

Cor Ligthert wrote:

You can create an access database using
ADO in your program as a part of your
development.

That is not an Access database. It is a Jet database. It does not
require MS Access to be present (before, now, or in the future) on the
PC.

HTH,
TC

[aatcbbtccctc]

Microsoft's use of the term "Access Database" in that article, is
incorrect.

If I happened to mis-spell my own name, that would not make the
mis-spelling correct!

HTH,
TC

[Cor Ligthert]

TC,

You make in my opinion a mistake what is a database. For a database is not
even SQL required (In the last case we are mostly talking about a relational
database). It only needs that the data is accessable in a random way and
that there is an ability to replace parts of the data when there is an
update, delete or insert.

Cor

[Richard Myers]

Cor you're wrong.
TC you're being pedantic.
I hope neither of you are customer facing for your respective firms.

Richard

<aa**********@yahoo.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...

Cor Ligthert wrote:

You can create an access database using
ADO in your program as a part of your
development.

That is not an Access database. It is a Jet database. It does not
require MS Access to be present (before, now, or in the future) on the
PC.

HTH,
TC

[Cor Ligthert]

Richard,

Cor Ligthert wrote:

You can create an access database using
ADO in your program as a part of your
development.

Cor you're wrong.
TC you're being pedantic.
I hope neither of you are customer facing for your respective firms.

Will you explain what is wrong in my statement?

Cor

[Richard Myers]

JT already has.
"Cor Ligthert" <no************@planet.nl> wrote in message
news:u5**************@TK2MSFTNGP14.phx.gbl...

Richard,

Cor Ligthert wrote:

You can create an access database using
ADO in your program as a part of your
development.

Cor you're wrong.
TC you're being pedantic.
I hope neither of you are customer facing for your respective firms.

Will you explain what is wrong in my statement?

Cor

[aatcbbtccctc]

Richard Myers wrote:

I hope neither of you are customer facing for your respective firms.

What an arrogant comment. This is a technical discussion forum, not a
shop front counter. I believe that technical accuracy is important in a
technical forum. You obviousy disagree. I leave readers to judge for
themselves.

Goodbye.

TC

[aatcbbtccctc]

You miss my point as to which components perform what tasks.

I don't intend to comment further.

Cheers,
TC

[Cor Ligthert]

Richard,

No he did not on my question too you to explain why you wrote that this
statement from me is not true.

You can create an access database using
ADO in your program as a part of your
development.

At least you should tell why?

Cor

[Cor Ligthert]

TC,

Sorry, your points sounds for me as splitting hairs.

Which sounds for me the same as if you want to tell that somebody born in
the US is not an American but an USan and somebody born in the EU is not
an European but an EUan.

Everybody visiting this newsgroups knows what is meant (and use that in
relation) by the Access database and are in the same way telling about MS
Access that it is an application.

Just my thought,

Cor

[Richard Myers]

"Cor Ligthert" <no************@planet.nl> wrote in message
news:Oi**************@TK2MSFTNGP15.phx.gbl...

Richard,

No he did not on my question too you to explain why you wrote that this
statement from me is not true.

You can create an access database using
ADO in your program as a part of your
development.

At least you should tell why?

Nope. Im currently eating ice cream with a fork which seems much more
interesting than continuing with this thread.
If you dont get it then thats fine, i really dont care either way. Check
out MSDN or alternatively try Access Help Files.

Richard

[Paul Clement]

On 10 Apr 2005 18:58:31 -0700, aa**********@yahoo.com wrote:

¤ Not so, Cor.
¤
¤ MS Access does not contain any of the base technologies for creating &
¤ managing tables & indexes; parsing, optimizing & executing SQL; or any
¤ of the other things that database products have to do.
¤
¤ Those technologies all reside in a completely seperate product, MS Jet.
¤ Access uses the Jet API to create & maintain tables & indexes, execute
¤ SQL, and so on.
¤

This is incorrect.

I'm not sure why you're attempting to separate Jet from Microsoft Access. Each version of Microsoft
Access is actually hard-wired for a specific version of Jet and the functionality is essentially
integrated. You can also use DAO, ADO etc (independently) to work with an Access database directly
or via OLEDB or ODBC drivers but there isn't the same level of support as when using the Microsoft
Access application.

¤ Access does ask Jet (via a Jet API) to create, within the MDB file,
¤ some containers for Access to store its own things (forms, reports
¤ etc.) - but that does not make Access, a database.
¤

Huh?

¤ I suspect your mistake is in believing that an MDB file is an *Access*
¤ file. It is not - it is a *Jet* file, in which Access is able to store
¤ its own things (in addition to the standard Jet things).
¤

Baloney. It can contain data, code and database related objects that are native to the Microsoft
Access application. An MDB file *is* an Access database.

¤ A VB program can use a Jet MDB file for database storage; but VB is not
¤ Access, and does not require Access to be present in any way, shape or
¤ form.

That is, unless you attempt to use functionality that is not supported by Jet, but is only available
through the Microsoft Access application.
Paul
~~~~
Microsoft MVP (Visual Basic)

[Scott M.]

How about if we say that an .mdb file is an Access file that wraps a JET
database and adds extensions of its own?

"Can't we all just get along?"

I think the fundamental point here is that there is no such thing as DATA
stored in Access format. An Access file is DATA stored in a JET database
along with Access elements such as reports, forms, VBA code, etc. and all of
that is placed in an Access .mdb file.

The proof in the pudding is that the data stored in an Access file can be
programmatically accessed and manipulated without having the Access client
because the actual data is not stored in an Access format, but in a JET
database.


"Paul Clement" <Us***********************@swspectrum.com> wrote in message
news:t1********************************@4ax.com...

On 10 Apr 2005 18:58:31 -0700, aa**********@yahoo.com wrote:

¤ Not so, Cor.
¤
¤ MS Access does not contain any of the base technologies for creating &
¤ managing tables & indexes; parsing, optimizing & executing SQL; or any
¤ of the other things that database products have to do.
¤
¤ Those technologies all reside in a completely seperate product, MS Jet.
¤ Access uses the Jet API to create & maintain tables & indexes, execute
¤ SQL, and so on.
¤

This is incorrect.

I'm not sure why you're attempting to separate Jet from Microsoft Access.
Each version of Microsoft
Access is actually hard-wired for a specific version of Jet and the
functionality is essentially
integrated. You can also use DAO, ADO etc (independently) to work with an
Access database directly
or via OLEDB or ODBC drivers but there isn't the same level of support as
when using the Microsoft
Access application.

¤ Access does ask Jet (via a Jet API) to create, within the MDB file,
¤ some containers for Access to store its own things (forms, reports
¤ etc.) - but that does not make Access, a database.
¤

Huh?

¤ I suspect your mistake is in believing that an MDB file is an *Access*
¤ file. It is not - it is a *Jet* file, in which Access is able to store
¤ its own things (in addition to the standard Jet things).
¤

Baloney. It can contain data, code and database related objects that are
native to the Microsoft
Access application. An MDB file *is* an Access database.

¤ A VB program can use a Jet MDB file for database storage; but VB is not
¤ Access, and does not require Access to be present in any way, shape or
¤ form.

That is, unless you attempt to use functionality that is not supported by
Jet, but is only available
through the Microsoft Access application.
Paul
~~~~
Microsoft MVP (Visual Basic)

[Cor Ligthert]

Scott,

I think the fundamental point here is that there is no such thing as DATA
stored in Access format. An Access file is DATA stored in a JET database
along with Access elements such as reports, forms, VBA code, etc. and all
of that is placed in an Access .mdb file.

And what does that mean in your opinion about any other database. In this
thread is by one person denied that an Access datatase is a database. He
tells that it is a kind of application that uses a Jet database. What is not
false, however is in my opinion with an Access database normaly used the
same database and when we talk about the application we talk about MS Access
(at least I do).

Cor

[Scott M.]

> And what does that mean in your opinion about any other database.

We're not talking about other databases in this thread. Access is special
in this regard.

In this thread is by one person denied that an Access datatase is a
database. He tells that it is a kind of application that uses a Jet
database.
Actually, I think pretty much everyone in this thread (except you) has said
this...because it's true.
What is not false, however is in my opinion with an Access database normaly
used the same database and when we talk about the application we talk about
MS Access (at least I do).

It's true that for most discussions, people will tend to say "Access" when
talking about the MS Access software product as well as when they are
referring to the "type" of database they are using. For *most*
conversations that is fine because most people will know what you mean.

For the purpose of this thread though, we must get a bit more technical and
separate the database from the product that uses that database.

Technically speaking, there is no such database storage format as "Access",
there is the JET database storage format that Access uses and wraps.

Think about this for a second Cor...if I wanted to connect to the data
stored in a MS Access file (.mdb), I'd have several choices:

DAO - DAO is a data access paradigm that ONLY works with JET databases

ADO - ADO would need a connection object and the connection object would
need a connection string. The connection string would be this:
Proider=Microsoft.JET.4.0;Data Source=.... (notice the JET in there?)

ADO.NET - same as ADO

[Paul Clement]

On Mon, 11 Apr 2005 16:03:13 -0400, "Scott M." <s-***@nospam.nospam> wrote:

¤ How about if we say that an .mdb file is an Access file that wraps a JET
¤ database and adds extensions of its own?
¤
¤ "Can't we all just get along?"
¤

What's the fun in that? ;-)

¤ I think the fundamental point here is that there is no such thing as DATA
¤ stored in Access format. An Access file is DATA stored in a JET database
¤ along with Access elements such as reports, forms, VBA code, etc. and all of
¤ that is placed in an Access .mdb file.
¤
¤ The proof in the pudding is that the data stored in an Access file can be
¤ programmatically accessed and manipulated without having the Access client
¤ because the actual data is not stored in an Access format, but in a JET
¤ database.

So can an Excel Workbook. So can a CSV file. Does that make them "Jet databases"?

Jet is the database access layer component for Microsoft Access. It does not define any specific
type of database. It is not a product and many who use Access have absolutely no awareness of Jet.
Paul
~~~~
Microsoft MVP (Visual Basic)

[Cor Ligthert]

Paul,

So can an Excel Workbook. So can a CSV file. Does that make them "Jet
databases"?

Thanks for pointing us on that.

Cor

[Cor Ligthert]

Scott,

And what does that mean in your opinion about any other database.
We're not talking about other databases in this thread. Access is special
in this regard.

Before you write next time something, look than at least at the topic.
Actually, I think pretty much everyone in this thread (except you) has
said this...because it's true.

Read the messages, I have not the idea beside you and the one who told that
Microsoft don't know what Access is wrote the same as you.

Look for the rest too the answer from Paul.

Cor

[Scott M.]

> Jet is the database access layer component for Microsoft Access. It does

not define any specific
type of database. It is not a product and many who use Access have
absolutely no awareness of Jet.

It's true that most who use Access don't know anything about JET. That only
proves that Access wraps the JET database.

Tell me, what is the connection string in ADO or ADO.NET to connect to an
..mdb file?
Tell me, what is the only kind of data that DAO can connect to?

[Scott M.]

>>> And what does that mean in your opinion about any other database.

We're not talking about other databases in this thread. Access is
special in this regard.

-----> Before you write next time something, look than at least at the
topic.

Cor, the last several times you have replied to my comments in other
threads, you have come back at me with cryptic responses like this one.
What are you trying to say? I have read this thread and my posts are very
clear on what I'm saying. Your posts, on the other hand, are contradictory
and confusing.
Actually, I think pretty much everyone in this thread (except you) has

said this...because it's true.

-----> Read the messages, I have not the idea beside you and the one who
told that
-----> Microsoft don't know what Access is wrote the same as you.

I have absolutley no idea what you are trying to say here.
Look for the rest too the answer from Paul.

Paul has posted 1 message in this thread prior to my comment to you and I
disagree with him as well.

[Scott M.]

From:

http://www.microsoft.com/resources/d.../jetintro.mspx

"Since its introduction in 1992, the Microsoft Jet database engine has been
in a unique position. Because Microsoft Jet is not a stand-alone product -
you cannot buy it at your local software retailer - most developers who use
it have learned about its functionality in a second-hand fashion from the
documentation included in Microsoft Access, Microsoft Office, Microsoft
Visual Basic®, Microsoft Visual C++®, or Microsoft Visual J++®. "

"Paul Clement" <Us***********************@swspectrum.com> wrote in message
news:2m********************************@4ax.com...

On Mon, 11 Apr 2005 16:03:13 -0400, "Scott M." <s-***@nospam.nospam>
wrote:

¤ How about if we say that an .mdb file is an Access file that wraps a JET
¤ database and adds extensions of its own?
¤
¤ "Can't we all just get along?"
¤

What's the fun in that? ;-)

¤ I think the fundamental point here is that there is no such thing as
DATA
¤ stored in Access format. An Access file is DATA stored in a JET
database
¤ along with Access elements such as reports, forms, VBA code, etc. and
all of
¤ that is placed in an Access .mdb file.
¤
¤ The proof in the pudding is that the data stored in an Access file can
be
¤ programmatically accessed and manipulated without having the Access
client
¤ because the actual data is not stored in an Access format, but in a JET
¤ database.

So can an Excel Workbook. So can a CSV file. Does that make them "Jet
databases"?

Jet is the database access layer component for Microsoft Access. It does
not define any specific
type of database. It is not a product and many who use Access have
absolutely no awareness of Jet.
Paul
~~~~
Microsoft MVP (Visual Basic)

[Scott M.]

From:

http://www.microsoft.com/resources/d.../jetintro.mspx

"Since its introduction in 1992, the Microsoft Jet database engine has been
in a unique position. Because Microsoft Jet is not a stand-alone product -
you cannot buy it at your local software retailer - most developers who use
it have learned about its functionality in a second-hand fashion from the
documentation included in Microsoft Access, Microsoft Office, Microsoft
Visual Basic®, Microsoft Visual C++®, or Microsoft Visual J++®. "
"Cor Ligthert" <no************@planet.nl> wrote in message
news:uJ**************@TK2MSFTNGP10.phx.gbl...

Scott,

And what does that mean in your opinion about any other database.

We're not talking about other databases in this thread. Access is
special in this regard.

Before you write next time something, look than at least at the topic.

Actually, I think pretty much everyone in this thread (except you) has
said this...because it's true.

Read the messages, I have not the idea beside you and the one who told
that Microsoft don't know what Access is wrote the same as you.

Look for the rest too the answer from Paul.

Cor

[Cor Ligthert]

"Scott M." <s-***@nospam.nospam> schreef in bericht
news:O8*************@TK2MSFTNGP10.phx.gbl...

And what does that mean in your opinion about any other database.

We're not talking about other databases in this thread. Access is
special in this regard.

-----> Before you write next time something, look than at least at the
topic.

Cor, the last several times you have replied to my comments in other
threads, you have come back at me with cryptic responses like this one.
What are you trying to say? I have read this thread and my posts are very
clear on what I'm saying. Your posts, on the other hand, are
contradictory and confusing.

We are talking about the use of Access vs SQL (server) in this thread, look
at the subject of all the messages.

For me did you not notice that, because that is what you wrote. It does
really not give me much believe that you did read this message thread.

Cor

[Scott M.]

LOL!!!

Cor, the subject may be Access vs. SQL, but the topic quickly turned to JET
and Access. The fact that you want to ignore what we have actually been
talking about here (including your own comments), just tells me that you
have nothing else to offer.
"Cor Ligthert" <no************@planet.nl> wrote in message
news:eG**************@TK2MSFTNGP12.phx.gbl...

"Scott M." <s-***@nospam.nospam> schreef in bericht
news:O8*************@TK2MSFTNGP10.phx.gbl...

> And what does that mean in your opinion about any other database.

We're not talking about other databases in this thread. Access is
special in this regard.

-----> Before you write next time something, look than at least at the
topic.

Cor, the last several times you have replied to my comments in other
threads, you have come back at me with cryptic responses like this one.
What are you trying to say? I have read this thread and my posts are
very clear on what I'm saying. Your posts, on the other hand, are
contradictory and confusing.

We are talking about the use of Access vs SQL (server) in this thread,
look at the subject of all the messages.

For me did you not notice that, because that is what you wrote. It does
really not give me much believe that you did read this message thread.

Cor

[Cor Ligthert]

Scott,

Cor, the subject may be Access vs. SQL, but the topic quickly turned to
JET and Access. The fact that you want to ignore what we have actually
been talking about here (including your own comments), just tells me that
you have nothing else to offer.

We ????

There was only one person beside later you, who in this thread told that
access was not a db.

This is from your first message in this thread.Access does not implement any db security (beyond a db password)

And now Access is no more a db, why has it than a db password.

Scott, whatever you write in newsgroups can be checked, so watch what you
write.

However in the last sentence from your last message you are right, I have
nothing more to offer in this thread, everything is already written in this
thread and that was already before you started beating that dead horse.

Cor

[Scott M.]

It's clear Cor that English isn't your first language (not trying to insult
you, just stating a fact). And, it's clear that you haven't been reading or
writing your English very well also.

Let's go back and "check" the thread as you suggest:

There were seven (7) messages on the "Access is or isn't a database" topic
involving three (3) other people BESIDES myself BEFORE I said anything about
Access and JET.

Yes, I did say "Access does not implement any db security (beyond a db
password)", but that doesn't automatically mean that Access is a database at
all. It simply means that Access implements a password on the JET database.
Are you really telling me that you couldn't put that together yourself?

You confuse me to no end Cor, because you write such off the wall things.
You constantly contradict yourself and state things that were never said by
anyone as if they were said by me and then deny things that were said by
yourself.

You are really telling me that you don't understand the concept of a thread
that breaks off into a sub-thread about a different twist on the original
post?

Seriously?

And are you seriously telling me that you can't separate something that was
said in one thread (when the term Access is used to refer to BOTH the
product and the data as I stated in my earlier post that I guess you didn't
read) from something that was said in a sub-thread (when we were discussing
this on a more technical level where Access is NOT used to describe BOTH the
product and the data)?

If my posts confuse you, my desire to have you clarify yourself bothers you
and my asking that you not go on babbling about un-related and non-factual
information bothers you so, please feel free to filter me from your NG
reader.

You are constantly telling me to go back and read the thread, but it is you
who isn't reading (or understanding) what is being said and is coming up
with non-sensical statements. It's very clear what I am saying, to whom I
said it and when, here's the summary:

Access is not as good as SQL for concurrent users.
Access does not support Stored Procedures to the extent that SQL does.
Access does not support the same level of security that SQL does.
Access is a product that wraps a JET database and extends it's UI via VBA,
Forms, Queries and Reports.

This is pretty darn clear Cor and it is almost identical to what I've said
in the previous posts. You may not agree (and I respect your right to do
so), but you seem to be the only one who doesn't, at least, understand what
I'm saying.


"Cor Ligthert" <no************@planet.nl> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...

Scott,

Cor, the subject may be Access vs. SQL, but the topic quickly turned to
JET and Access. The fact that you want to ignore what we have actually
been talking about here (including your own comments), just tells me that
you have nothing else to offer.

We ????

There was only one person beside later you, who in this thread told that
access was not a db.

This is from your first message in this thread.

Access does not implement any db security (beyond a db password)

And now Access is no more a db, why has it than a db password.

Scott, whatever you write in newsgroups can be checked, so watch what you
write.

However in the last sentence from your last message you are right, I have
nothing more to offer in this thread, everything is already written in
this thread and that was already before you started beating that dead
horse.

Cor

[Scott M.]

Here's even more from that same article:

"Microsoft Access Users When you create an object through DAO by using
Microsoft Jet, only the standard built-in properties are created in the new
object's Properties collection. However, when Microsoft Access creates a
Microsoft Jet object, it may add several user-defined properties to objects.
These properties are a special case of user-defined properties known as
application-defined properties. For example, when you create a table in the
Microsoft Access user interface, and type a value in the Description field,
it automatically adds a new property to the TableDef object to represent the
description."

Notice how they refer to Access, not as the database, but as the "Microsoft
Access user interface"?

Notice how they talk about MS Access creating a "Microsoft Jet object"?

And, if you read the whole article, you'll see them talk about the actual
database being one of the DAO objects and that the DAO objects are APIs to
JET objects.

Is this clear enough for you?
"Cor Ligthert" <no************@planet.nl> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...

Scott,

Cor, the subject may be Access vs. SQL, but the topic quickly turned to
JET and Access. The fact that you want to ignore what we have actually
been talking about here (including your own comments), just tells me that
you have nothing else to offer.

We ????

There was only one person beside later you, who in this thread told that
access was not a db.

This is from your first message in this thread.

Access does not implement any db security (beyond a db password)

And now Access is no more a db, why has it than a db password.

Scott, whatever you write in newsgroups can be checked, so watch what you
write.

However in the last sentence from your last message you are right, I have
nothing more to offer in this thread, everything is already written in
this thread and that was already before you started beating that dead
horse.

Cor

[Scott M.]

By the way, did you even bother to READ this:

From:

http://www.microsoft.com/resources/d.../jetintro.mspx

"Since its introduction in 1992, the Microsoft Jet database engine has been
in a unique position. Because Microsoft Jet is not a stand-alone product -
you cannot buy it at your local software retailer - most developers who use
it have learned about its functionality in a second-hand fashion from the
documentation included in Microsoft Access, Microsoft Office, Microsoft
Visual Basic®, Microsoft Visual C++®, or Microsoft Visual J++®. "

"Cor Ligthert" <no************@planet.nl> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...

Scott,

Cor, the subject may be Access vs. SQL, but the topic quickly turned to
JET and Access. The fact that you want to ignore what we have actually
been talking about here (including your own comments), just tells me that
you have nothing else to offer.

We ????

There was only one person beside later you, who in this thread told that
access was not a db.

This is from your first message in this thread.

Access does not implement any db security (beyond a db password)

And now Access is no more a db, why has it than a db password.

Scott, whatever you write in newsgroups can be checked, so watch what you
write.

However in the last sentence from your last message you are right, I have
nothing more to offer in this thread, everything is already written in
this thread and that was already before you started beating that dead
horse.

Cor

[lgbjr]

Hi All,

LOL! I've quite enjoyed reading all of the posts in this thread. To get back
to the original topic for a second, I just wanted to let everyone know what
I decided to do.

I downloaded and installed MSDE 2000 (as well as DBAMgr2K). I did an upsize
from Access, tweaked my app a bit, and viola, everything works.

while downloading and installing MSDE 2000, my only thoughts were that
Access was simple (I'm always on a quest to keep things simple for my
users). MSDE 2000 adds a bit of complexity, but I have to say, compared to
the performance gains, it's well worth it. Two of the tables have OLEObject
(picture) fields (6 in one table, 8 in another). while running my app with
the "Jet or Access or MS Access" DB (wink), there was a noticeable delay in
retrieving and displaying records from the DB that had pictures. With MSDE,
pictures, or no pictures, retrieving records is fast!

thanks for all of the advice, and the entertainment!!

Lee

"lgbjr" <lg***@online.nospam> wrote in message
news:OR**************@TK2MSFTNGP09.phx.gbl...

Hello All,

Thank You for your responses! All of you have given me quite a bit to
think about!

Richard, I understand completely. A bit of background: Even though I am
developing a software package, I would not, by any stretch of the
imagination, consider myself a software developer. I'm an Engineering
Consultant for the Mobile Communications Industry. For the past 10 years,
I've been writing PERL apps (when necessary) to automate repetitive tasks
and make my life easier. These apps were for my use only. Over the years,
I have had several clients ask me to provide these small apps to them. So,
I moved from writing plain code, to writing an app with a user-friendly
interface. Now, my clients want more. And they're willing to pay for it
(above and beyond what they pay for my engineering services). Fortunately,
I knew enough to write a scope of work (basically for myself), just as I
would do for a typical engineering project. So, I do understand 'creeping
scope'.

Regarding the ability to 'Plug and Play' a variety of DB engines, I have
considered this as well. At the beginning of this project, I was using C1
Express components (no data adapters, no datasets, just Express Tables and
an Express connection (OLEDB)). While this was extremely easy to
implement, I realized that there was no upgrade path (upgrade = rewrite).
Now, still using C1 components, I know (think) I can upsize to MSDE or SQL
Server with only minor code changes.

Gerald, I agree. Rather than trying to decide which DB engine is better,
it's safe to say that all are good, if used in the environment they were
designed for. Right now, wihtout thinking about growth, I could deploy
with Access (1-2 users performing updates, additional 3-4 users viewing
data, approximately 1-1.5GB size). But, this, based on what I have read,
and your comments, is near the upper limit of what Access was designed
for.

JL, though it may not seem so, I am in a similar situation regarding IT
support. Even though all of the mobile operators have extensive IT
departments, the engineering and IT departments are always fighting. So, I
need my app to be self-maintainable.

After posting this, I'm going to install SQL2KDesktop (MSDE) and try to
get a feel for what it will take to do a migration (I already have SQL
Server running on another machine). I like Richard's idea of allowing the
client to decide which DB engine to use. Hopefully my coding and
forward-thinking was robust enough to allow this with only some minor
tweaks. However, if I get lost in a sea of errors, I think my backup will
be to use MSDE.

Again, thanks for your insights!!

Regards,
Lee

"lgbjr" <lg***@online.nospam> wrote in message
news:ex**************@TK2MSFTNGP09.phx.gbl...

Hello All,

I've been developing a VB.NET app that requires the use of a DB. Up to
now, I've been using Access. It's a bit slow, but everything works. I'm
at a point now where I need to decide if I should stay with Access or
move the DB to SQL. I'm trying to come up with a list of Pros/Cons for
such a move. My list is a bit lopsided, as I have very little experience
with SQL and quite a bit with Access.

PROS for moving to SQL:
Increased Performance?
Increased Reliability?
Lifecycle of Access?
Future Access Version compatibility issues?

CONS for moving to SQL:
My limited knowledge of SQL
Clients not required to have an SQL server

I've added a few items to the PROS list, but with ?s, as I don't really
know.

If there are a few Access advocates and SQL advocates out there that
could give me some viewpoints, I'd be more comfortable making a decision
based on the facts, rather than my limited knowledge.

TIA
Lee

[Scott M.]

You are on the right path Lee. Good luck!
"lgbjr" <lg***@online.nospam> wrote in message
news:uB***************@TK2MSFTNGP10.phx.gbl...

Hi All,

LOL! I've quite enjoyed reading all of the posts in this thread. To get
back to the original topic for a second, I just wanted to let everyone
know what I decided to do.

I downloaded and installed MSDE 2000 (as well as DBAMgr2K). I did an
upsize from Access, tweaked my app a bit, and viola, everything works.

while downloading and installing MSDE 2000, my only thoughts were that
Access was simple (I'm always on a quest to keep things simple for my
users). MSDE 2000 adds a bit of complexity, but I have to say, compared to
the performance gains, it's well worth it. Two of the tables have
OLEObject (picture) fields (6 in one table, 8 in another). while running
my app with the "Jet or Access or MS Access" DB (wink), there was a
noticeable delay in retrieving and displaying records from the DB that had
pictures. With MSDE, pictures, or no pictures, retrieving records is fast!

thanks for all of the advice, and the entertainment!!

Lee

"lgbjr" <lg***@online.nospam> wrote in message
news:OR**************@TK2MSFTNGP09.phx.gbl...

Hello All,

Thank You for your responses! All of you have given me quite a bit to
think about!

Richard, I understand completely. A bit of background: Even though I am
developing a software package, I would not, by any stretch of the
imagination, consider myself a software developer. I'm an Engineering
Consultant for the Mobile Communications Industry. For the past 10 years,
I've been writing PERL apps (when necessary) to automate repetitive tasks
and make my life easier. These apps were for my use only. Over the years,
I have had several clients ask me to provide these small apps to them.
So, I moved from writing plain code, to writing an app with a
user-friendly interface. Now, my clients want more. And they're willing
to pay for it (above and beyond what they pay for my engineering
services). Fortunately, I knew enough to write a scope of work (basically
for myself), just as I would do for a typical engineering project. So, I
do understand 'creeping scope'.

Regarding the ability to 'Plug and Play' a variety of DB engines, I have
considered this as well. At the beginning of this project, I was using C1
Express components (no data adapters, no datasets, just Express Tables
and an Express connection (OLEDB)). While this was extremely easy to
implement, I realized that there was no upgrade path (upgrade = rewrite).
Now, still using C1 components, I know (think) I can upsize to MSDE or
SQL Server with only minor code changes.

Gerald, I agree. Rather than trying to decide which DB engine is better,
it's safe to say that all are good, if used in the environment they were
designed for. Right now, wihtout thinking about growth, I could deploy
with Access (1-2 users performing updates, additional 3-4 users viewing
data, approximately 1-1.5GB size). But, this, based on what I have read,
and your comments, is near the upper limit of what Access was designed
for.

JL, though it may not seem so, I am in a similar situation regarding IT
support. Even though all of the mobile operators have extensive IT
departments, the engineering and IT departments are always fighting. So,
I need my app to be self-maintainable.

After posting this, I'm going to install SQL2KDesktop (MSDE) and try to
get a feel for what it will take to do a migration (I already have SQL
Server running on another machine). I like Richard's idea of allowing the
client to decide which DB engine to use. Hopefully my coding and
forward-thinking was robust enough to allow this with only some minor
tweaks. However, if I get lost in a sea of errors, I think my backup will
be to use MSDE.

Again, thanks for your insights!!

Regards,
Lee

"lgbjr" <lg***@online.nospam> wrote in message
news:ex**************@TK2MSFTNGP09.phx.gbl...

Hello All,

I've been developing a VB.NET app that requires the use of a DB. Up to
now, I've been using Access. It's a bit slow, but everything works. I'm
at a point now where I need to decide if I should stay with Access or
move the DB to SQL. I'm trying to come up with a list of Pros/Cons for
such a move. My list is a bit lopsided, as I have very little experience
with SQL and quite a bit with Access.

PROS for moving to SQL:
Increased Performance?
Increased Reliability?
Lifecycle of Access?
Future Access Version compatibility issues?

CONS for moving to SQL:
My limited knowledge of SQL
Clients not required to have an SQL server

I've added a few items to the PROS list, but with ?s, as I don't really
know.

If there are a few Access advocates and SQL advocates out there that
could give me some viewpoints, I'd be more comfortable making a decision
based on the facts, rather than my limited knowledge.

TIA
Lee

[Paul Clement]

On Tue, 12 Apr 2005 13:12:30 -0400, "Scott M." <s-***@nospam.nospam> wrote:

¤ > Jet is the database access layer component for Microsoft Access. It does
¤ > not define any specific
¤ > type of database. It is not a product and many who use Access have
¤ > absolutely no awareness of Jet.
¤
¤ It's true that most who use Access don't know anything about JET. That only
¤ proves that Access wraps the JET database.
¤
¤ Tell me, what is the connection string in ADO or ADO.NET to connect to an
¤ .mdb file?

oConn.Open "Driver={Microsoft Access Driver (*.mdb)};" & _
"Dbq=c:\somepath\mydb.mdb;" & _
"Uid=admin;" & _
"Pwd="

¤ Tell me, what is the only kind of data that DAO can connect to?
¤

DAO can connect to any number of database types including Microsoft Access and ODBC supported
databases such as SQL Server and Oracle and ISAM databases such as xBase, Excel, Paradox etc.
Paul
~~~~
Microsoft MVP (Visual Basic)

[Paul Clement]

On Tue, 12 Apr 2005 13:19:48 -0400, "Scott M." <s-***@nospam.nospam> wrote:

¤ From:
¤
¤ http://www.microsoft.com/resources/d.../jetintro.mspx
¤
¤ "Since its introduction in 1992, the Microsoft Jet database engine has been
¤ in a unique position. Because Microsoft Jet is not a stand-alone product -
¤ you cannot buy it at your local software retailer - most developers who use
¤ it have learned about its functionality in a second-hand fashion from the
¤ documentation included in Microsoft Access, Microsoft Office, Microsoft
¤ Visual Basic®, Microsoft Visual C++®, or Microsoft Visual J++®. "
¤

Isn't that kind of what I said?

Do we now want to count the number of times the phrase "Jet database" and "Access database" are used
interchangeably? Not much point is there. ;-)
Paul
~~~~
Microsoft MVP (Visual Basic)