From: Peter Fallon on
Kevin,

If Access opens it by itself then you have two options.

1) use the code you have now, but do NOT use an userID or Pwd
parameters. This makes the JET enine open using the (read only?)
defaults - which is what Access itself uses when it doesn't request a
password.

2) I usually have success inspecting the relevant EXE with a binary/Hex
viewer. While an experienced programmer will disguise user ID and
password strings, they probably won't bother to hide literal
filenames/paths, so you may find these scattered about in the EXE as
literal string storage.

It will take a bit if guesswork to determine what each file is, but you
will find it illuminating...

> Thanks Peter,
> I think you are on to it. It is a secured database and your suggestion
> re the MDW file fits the behaviour. However, I can't find an MDW file
> anywhere so your theory on it being 'hidden' also fits with what is
> happening.
>
> I have tried all the combinations of user/passwords and the other
> suggsted syntaxes but always the same result. No read access!
>
> Strange that Access opens it without any passwords being requested,
> though.
> Perhaps I need to use the OLEDB driver instead of the ODBC one. I'll
> keep digging <sigh>
>
>
> Kevin
>
>
From: Kevin Butler on
Hi Peter

I have found a file called SYSTEM.MDW which relates to a workgroup mode
for the database. As I understand it the permissions info will be
stored in that file.
Any ideas on introducing this in to the connection string?

I have tried various combinations but without success:
cConnString:= "Driver=Microsoft ACCESS Driver (*.mdb);DBQ="+cfile+";
SystemDB=.mdw ; UID=Admin ; PWD= ;"
It seems I need a parameter for the mdw file name (perhaps) but?

Also I installed Vo2ADO from the 2.7 CD. That stopped 2.7 from running
with the STATUSBAR message and the differing vo27gui.dll file size
error. This is documented on the NG but seems that it is a complete
re-install of 2.7 and the patches in the right sequence to cure so I
flagged it. Fortunately uninstalling Vo2ADO resolved the issue and put
me back to a working 2.7.

All I need to do is to read the mdb file. I can't believe that it has
become so difficult. Would it be this problematic in VB or C#?

Kevin.

From: Kevin Butler on
Problem resolved .....
The mdb is secured and uses a workgroup information file.
The connection string that works is like this:

cConnString:= "Driver=Microsoft ACCESS Driver (*.mdb);DBQ="+cfile+";
SystemDB="+cMdw+" ; Uid=Admin; PWD=admin ;"
oConn:=sqlconnection{}
lConnected := oConn:driverconnect(,SQL_DRIVER_NOPROMPT, cConnString)

Note that the file SYSTEM.MDW used by the MDB needs to be passed in the
string (cMdw is the qualified file name)

The User name and password need to be valid in the mdw file. It will
not work with the default "Admin" and blank password. Admin and admin
are valid logon to the secured MDB in this case.

Thanks for the help guys.

Kevin.

From: Peter Fallon on
Kevin,

Using user level security in Access tends to be a pain the first time.
Once you have some code worked out, you just cut and paste it everywhere
<g>.

You might find this site of interest if you have to discover
passwords...etc from databases in the future:

http://www.lostpassword.com/

> Problem resolved .....
> The mdb is secured and uses a workgroup information file.
> The connection string that works is like this:
>
> cConnString:= "Driver=Microsoft ACCESS Driver (*.mdb);DBQ="+cfile+";
> SystemDB="+cMdw+" ; Uid=Admin; PWD=admin ;"
> oConn:=sqlconnection{}
> lConnected := oConn:driverconnect(,SQL_DRIVER_NOPROMPT, cConnString)
>
> Note that the file SYSTEM.MDW used by the MDB needs to be passed in the
> string (cMdw is the qualified file name)
>
> The User name and password need to be valid in the mdw file. It will
> not work with the default "Admin" and blank password. Admin and admin
> are valid logon to the secured MDB in this case.
>
> Thanks for the help guys.
>
> Kevin.
>
>

From: Kevin Butler on
Thanks Peter,
Interesting site. I'll bookmark it.

Cheers
Kevin

Peter Fallon wrote:
> Kevin,
>
> Using user level security in Access tends to be a pain the first time.
> Once you have some code worked out, you just cut and paste it everywhere
> <g>.
>
> You might find this site of interest if you have to discover
> passwords...etc from databases in the future:
>
> http://www.lostpassword.com/
>