jet DB & Client side application DB

D

damik

Hello,

I am curious on the status of the jet db. (dead, not quite dead yet,
etc..)?

I am in need of something like it, a fast, fairly robust and reliable
db solution that I can use for a client side application (so single
user non-remote access).

Having been using MySQL and PostgreSql for web-based solutions, I
would a really like a DB solution that would allow to me create my
tables and columns via .sql file (rather then typing them through the
access interface)

Thanks in advance,

D
 
A

Arvin Meyer

To say that JET is in maintenance mode is Microsoft's stated position. JET
is far from dead. There are literally thousands of JET databases created
every day. If you are looking for a client-side DBMS, or even a small number
of networked users, JET has no equal. Microsoft has also stated that it will
be in existence for the next version of Office.

Frankly, I believe that the only way that JET will ever die is if they come
up with something better. Very few will "upgrade" to a non-JET RDBMS until
they do.
--
Arvin Meyer, MCP, MVP
Microsoft Access
Free Access downloads:
http://www.datastrat.com
http://www.mvps.org/access
 
A

Albert D. Kallal

Hello,

I am curious on the status of the jet db. (dead, not quite dead yet,
etc..)?

Hum, I have clients using FoxPro 2.6 on brand new pc's (that is 15 year old
software). You can head on down to Dan Bricklens site and load a copy of the
Original spread sheet that came out for the IBM pc in 1981 (Visi-Calc). So,
while no apple Mac code from the mid 80's ran on their OS after 7, and again
recently (ie: you had to throw out your software AND dev tools), the same
cannot be said for the MS stuff. So, you can run access 1.0 on a brand new
pc today (access 1.0 came out 10+ years ago). Hence, in a sense, since MS
has the best track record in the industry for forward compatibility, then it
might not matter what the status of JET is!

However, I will say that JET is a great little solution, and MS can't really
throw out the most popular database engine and file format in the world.
Audits for some companies show 100's, and I heard of companies that "easily"
count 45,000 mdb (JET) files in their inventory. In the pc world, the mdb
file format has clearly replaced the old dbase format as the most popular
database format.

Further, the brand new office 2003 has a dao (JET) reference included by
default (that has been missing for 2000, and XP) In fact, you have to go
back to access97 to have a dao JET reference included by default. So, if the
brand new version of office 2003 has a JET reference, then it seems quite
clear that the MS folks do listen to us developers. So, between the
incredible track record of software having such a long life, and the
re-introduction of a JET reference by default in access2003, then I don't
see much to worry about. In the same time frame competitors like Apple
forced all the code, dev tools etc to be thrown out and broke compatibility
at least twice in the above mentioned time frame.
Having been using MySQL and PostgreSql for web-based solutions, I
would a really like a DB solution that would allow to me create my
tables and columns via .sql file (rather then typing them through the
access interface)

You can most certainly type in, view, and even paste ddl commands into
ms-access. Of course, Oracle, MySql, ms-sql, JET etc. all have different
features. So, for example, last time I used MySql, it did not have cascade
deletes, but JET does. So, ddl statements and scripts are not going to be
compatible among the major vendors of data engines.

However, for basic table creating stuff, DLL statements will work just fine
if you stay away from specific features that each system has.

You can:

Cut and paste the ddl statement into the command line (debugger window).

You just type:

docmd.RunSql "paste your ddl statement goes here"

You can also just create a blank query, switch to sql view, and again paste
in the sql (you thus would not be using the command line prompt any more).

However, note that ms-access sql editor (query editor), or the ms-access
command prompt can't accept more then ONE ddl statement at a time. For a few
tables, the cut then paste approach works just fine.

If you have a lot of tables, then you certainly could write some code to
"read" the ddl commands. If you are fluent in VB, then in less then 1/2
hour, you could cobble something together to "read" the text file and
execute each line of ddl (sql).
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top