Fog Creek Software
Discussion Board




Access 2.0 came back to haunt me

Do you remember Access 2.0 from 1994? No? I don't, either... when I first got my hands on Office, it was in the times of Office 95.

Anyway, Access 2.0 is from 1994, which means it's almost 10 years old.

My boss has an old, but complex Access 2.0 application.

He wants me to write a program, in Visual Studio .NET, which writes data in the Access 2.0 tables.

The problem is, I can't even open those .MDB files! :-(

They are password-protected, or something.

I tried and tried and tried, for hours.

Even got a password cracker which tells me the workgroups and passwords to the files.

The problem is, Jet 4.0 doesn't want to accept any of the passwords.

Access 2.0 has a strange security model involving workgroups, users, passwords and protected objects.

The problem is, I don't have a clue where, in the Jet 4 driver, to put the information I have from the password cracker. It only asks me for an username and password.

Also, from reading on the MS site, it seems that my user has to "join" a group, somehow, but I have no clue where those groups are stored.

Also what I don't understand this: Access 2.0 uses JET to access databases, or just accesses the .MDB files directly?

Because, if Access 2.0 accesses the .MDB files directly, it means I probably won't be able to access the Access 2.0 .MDB files using JET 4.

The old app using Access 2.0 also distributes the Access 2.0 .EXE - perhaps a runtime version, or something.

I have no clue how that Access 2.0 manages to open the old .MDB file. It "just works", for some reason, but if I try to run just the .EXE, without parameters, it asks me for username+password, and the user/pass combinations that work when opening .MDB files, don't work when running the Access 2.0 .EXE which comes with the app.

I hope I shall find a solution to this problem with strange workgroups which you have to join (How? Only God knows... it's undocumented), users, passwords, and protected objects.

No escape from Access 2.0
Wednesday, September 17, 2003

I have tried for a few more hours.

I tried other password crackers for Access. Most of them can't crack the passwords of the .MDB file because the format is too old.

Somehow, the old accounting application consisting in this .MDB files starts up successfully and works, but I can't open the .MDBs.

To paraphrase an old Nightmare on Elm Street movie:

Access 2.0 is the ancient substance of nightmares. It always appears strangely distributed with old, extremely crappy accounting applications. When the boss wants to export data to it using modern tools, the programmers all begin to have the same strange nightmares about Access 2.0 and then one of them is gruesomely murdered in his sleep. Thus begins an ordeal of trying to make workgroups, users, objects and passwords fit, in a desperate, hopeless attempt to access the ancient .MDB data.

I'm desperate, folks!

No escape from Access 2.0
Wednesday, September 17, 2003

Why don't you ask your boss for the password?

here's an idea
Wednesday, September 17, 2003

Since you point out that the application just runs without any prompts for passwords, then I will assume you are the rightful owner of the data.

I will point out that the security in ms-access is about the same as any other security system I have ever used. That means you have users, groups, and then assign permissions to those groups (and if you are bad, then you assign permissions of objects to actual users.!  And, the same goes for bad system admin who assign files permissions to users!).  They all work about the same way.

I am not sure why when issues of security for windows, or products like ms-access appear, a sudden brain freeze seems to occur.  I can’t tell you how many times I seen system admin to start assigning file permissions to users in place of groups. The same goes for ms-access also! Regardless, my only point here is that the security model of ms-access works the same as just about every security system I used.

However, lets just leave this debate for a another day. You sound frustrated, and I don’t want to take any advantage of both your frustration and also lack of knowledge here.

You mention that when you run the application, it just starts. What does the startup shortcut look like? Likely, the workgroup is set in that startup.

You also mentioned that you have JET 4.

JET 4.0 can and should be able to read/open that file. I would fire up ms-access, and go tools->security->workgroup administer. Use that to browse to the dir with the old mdb file, and then join the old workgroup file in that dir. You should now be able to open that data file. Of course, you are playing with a copy of the data right?.

You also fail to mention what version of ms-access you have now (but jet 4.0 is the one for the last 2 versions....3 if you count office 2003 beta).

Earlier versions of ms-access do NOT include the workgroup manager. But a2000 and a2002 do. (for earlier versions, the workgroup program is a separate .exe you run).

So, take a look at the old application shortcut used to startup. It is even possible that the user name, and password set in that shortcut? Perhaps the shortcut does specify the security file that belongs to the mdb (this is VERY likely, and is STILL standard practice even today 10 years later).

Either the startup is a batch file...or a shortcut with some additional options.

Much light will be shed by simply looking at the startup options of this application.

At any rate, as far as I know, jet 4.0 can read 2.0 files. Here is a list of supported formats:

Supported formats for JET 4.0
http://support.microsoft.com/?id=283294

So, the ms-access can import xml, or even the old 1.0 data format which is even OLDER then 2.0!

You also don’t mention if you can view/use the access 2.0 UI or not. (does the old trick of holding down the shift key during startup work?). It is very possible you are using the runtime version of access 2.0, and thus old access UI is NOT available. That is based on vb3 by the way!

Also, do you have to “keep” this whole thing in the old format?

Also, I would consider using the ms-access newsgroups. There are a lot of folks who hang around there that would give you lots of help.

Anyway, give the above a shot. I would also consider enlisting someone in your area who has ms-access experience....

Albert D. Kallal    (MVP - Microsoft Access)
Edmonton, Alberta Canada
kallal@msn.com
http://www.attcanada.net/~kallal.msn

Albert D. kallal
Wednesday, September 17, 2003

Thank you for your help and comments.

When the accounting app starts, what happens in fact?

The shortcut to it is something like:

C:\APP\MSARN200.EXE C:\APP\app.mdb /Excl /ini C:\WINDOWS\app.ini

In fact, MSARN200.EXE seems to be a copy of Access 2.0.

The application starts and asks me for a password. I give it to it (I know the password). Then the application starts with custom menu, etc. I can't access the MS Access menu from there.

If, however, I try to start MSARN200.EXE directly, or I try to start a copy of Access 2.0 (I have a separate Access 2.0 which may not be complete), and enter the same password I tried for the MDB, the MDB doesn't open.

I'll keep trying.

No escape from Access 2.0
Wednesday, September 17, 2003

Holding Shift down while starting the application doesn't work. Also, I have to keep the data in the old format - I just have to write some data in the .MDB files.

The shortcut to the application specifies an .INI file which contains something like this:

[Options]
SystemDB=C:\Application\System1.Mda
UtilityDB=C:\Application\Utility1.mda

Ok, cool! So .. what am I supposed to do with this information?!

There is no place in the connection string builder dialog where I can put this weird info (the MDA paths).

Let's say I create an empty .UDL file and double-click on it, in order to access the JET 4 connection string dialog.

If I have a working connection string to this .MDB, I can use it with Visual Studio .NET / OleDB, and the nightmare will be over.

Let's see how I navigate this dialog:

First tab (Provider): I select "Microsoft JET 4.0 OLEDB Provider".

Second tab (): I select the database (the .MDB).

Then, I try to get the password right. I try the user/pass combination I use to start the god damn program.

Then, I press the "Test connection" button.

A MessageDlg appears, saying: "Test connection failed because of an error in initializing provider. Cannot start your application. The workgroup information file is missing or opened exclusively by another user."

I wish the next horror movie they release to be Freddy vs. Access 2.0. At least I shall have some satisfaction when Freddy wins! :) LOL! In fact, I don't like horror movies.

No escape from Access 2.0
Wednesday, September 17, 2003

Not sure if this is the problem or not, and going off of memory, but doesn't Jet 4.0 require 32 bit (*.mdw) rather than 16 bit (*.mda) files?

Kevin
Wednesday, September 17, 2003

Not sure about oledb, but in dao you can call the  PutSystemDB method of the _DBEngine to set the systemDB to use.

Cpt. Kirk
Wednesday, September 17, 2003

You should be able to join the workgroup file (in your case, the work group file is a mda file).

So, try joining the system1.mda. That should get you in.

Remember, each database does NOT store the passwords and user names. That would not make sense for a company that might have 5, or even 20 databases. Each database is secured to a workgroup file. That way, you can add new users to the workgroup file, and then they can then use all the databases (mdb) files that belong to that workgroup. It would be silly to have to go and add a user to each of the secured databases. Imagine with just 10 users, and 20 databases. It just could not work any other way!

So, when you specify your connection string, you have been specifying the security file...right? Just trying to connect to the mdb file is complete useless without the proper workgroup file.

Provider=Microsoft.Jet.OLEDB.4.0;
Data Source=<database>;
Jet OLEDB:System Database=<system database>;
User Id={{USER}}; Password={{PASSWORD}};

Replace <database> with the full path to the .MDB file. Replace <system database> with the full path to the Access security database (.MDW file).

In your case, the system Database should be set to the full path name to your mda file. This should work...but I not even 100% sure which of the two mda files you are supposed to use (I think system1...but try both).

As mentioned, this is much easier to test in ms-access using the UI. Get ms-access opening the database. It will take less the 5 minutes to try. You can then start working on your connection string in vb.net.

Albert D. Kallal
Edmonton, Alberta Canada
kallal@msn.com
http://www.attcanada.net/~kallal.msn

Albert D. kallal
Wednesday, September 17, 2003

MSARN is the Access runtime - Access 2.0 had a runtime version that you could buy to distribute (royalty-free) with your application. Then your users didn't have to have Access.

So if you're trying to open the mdb, you need a version of Access that will read/import 2.0 installed.

Philo

Philo
Wednesday, September 17, 2003

Access 2.0 uses the Jet engine that it came with.  If you can find the ODBC driver for it (which will be 16bit I think), then you might have better luck.

http://www.bsdg.org/swag/DELPHI/0044.PAS.html gives a reasonable description of how to  use the Access 2.0 Jet database using ODBC and gives the DLLs you should have.

Simon Lucy
Wednesday, September 17, 2003

Thank you, everybody, for the useful information!

The database connection now works perfectly for Access 2.0

You know the connection string builder dialog - the one you can use to build a connection string?

Bellow are the complete steps needed to access an Access 2.0 .MDB, using the corresponding .MDA.

The .MDA file contains information about users, groups, passwords.

First, I had to see how the application is launched - simply the shortcut parameters. One parameter was an .INI file, which contained a reference to the .MDA file.

Once I knew the .MDA files, I had to do this:

1. Create an empty (0-bytes) .URL file (for example, TEST.UDL).

2. Double-click on it.

3. Set the provider (MS Jet 4.0).

4. Set the .MDB in the second tab.

5. In the last tab, which is called "Advanced", there is the "Jet OLEDB:System database" property, which you have to set to the full path to the .MDA.

6. Press ok button, look into the .UDL file, copy and paste the query string.

Thank all of you, once again, for helping me!!!

Thank you very much!

I escaped the Access 2.0 hell! :)

No escape from Access 2.0
Wednesday, September 17, 2003

*  Recent Topics

*  Fog Creek Home