First big THANK YOU to all who have posted re: Passwords in a
database.

But surely the passwords are stored in the WORKSPACE. So if I log on
with the workspace password I don't have to bother with a password for
each time I open a database. Right or Wrong ???

I am migrating (or is that migraine-ing) from VB4 to VB6 (you would
think they had the buggies fixed by now) so this is a learning time
for me, but I will share my findings and pitfalls with the other poor
souls who are adrift in the same boat :-)

The help file gives you the syntax but very short on concepts

Jeff

Gosh I'm answering my own question.

After a whole lot of swearing and hog-wrestling VB to the ground here
is what I have found out.

1. Data is accessed through the JET Engine (DAO data and ISAM stuff)
this is referred to in code as the DBEngine object. Below that is the
WorkSpace object (what for and what it does I don't know - maybe for
ISAMs ??) and then the database object.

(Please correct me if I go wrong)

2. The DBEngine gets its info from the SystemDB file (which you can
set) BUT if you set the password using Access then the MSAccess
program has used the system file C:\windows\system\System.MDW or MDA
for earlier versions (OK so far ???) So be carefull if you have 2.

How ever VB6 stores its info in a registry key SystemDB = "System.MDB"
which doesn't exist on my machine !

3. And here we come to the good bit. There are 2 passwords. One is a
LOGON password to the Workspace  and the Other is the DATABASE
password. It looks as if you have to use the DATABASE password in the
Connect string to open the database but must first LOGON to the
workspace using the LOGON password.

The logon requires a User Name and a password. Once input you are
through to the WorkSpace. To open the database you need a Database
password. Once you are in the database you are restricted by your User
name to what Tables, Forms, Reports etc you can access.

They obviously had a visit from Chairman Bill when they thought this
up.

There is also a matter of GROUPS - but I am off to pub for some brain
oil before tackling that chestnut

All of which is pretty fine when dealing with one machine, but what
happens (as in my case) you have the database on a network server. No
let's see... It looks for System.MDB or is it MDA or MDW on the path
in the registry or is it C:\Windows\System or doesn't it care .

As I said I'm off to Pub

Jeff

Back from Pub.

There are 2 levels of security for Access Database.

1. A password that is stored within the database itself and you must
supply in the Connect string (this is DAO only - Haven't figured out
anymore) e.g. "MS Access;PWD=MyPassword". Note the connect is MS
Access with a space between MS and Access. Then a semicolon. Then
PWD=. Then the password NO Quotes. Also the password is case
sensitive.

The connect string must be supplied EVERY time you open the database.
So all your Data Control must have it.

This password is set using ACCESS not VB. There is no way for VB to
read it, or check it is correct before using it. So how and where does
your VB program know what the password is ?? You could hard code it
into the program and hope no-one will open Access and tinker. You
could put it into an INI file but that defeats the object of having a
password.

And there will come a time when someone changes it and slips on a
banana skin and gets concussion, falls out of the 20th storey window,
leaves the company in a huff, or just forgets. Then all chaos breaks
loose and just when they forgot backups and just entered 6 months
information cause the auditors are coming in today. Once the password
has been changed there is no way to change it back if you don't know
it. No administrator override.

So using that password seems impractical to me.

2. The other level is User level security. A list of users, passwords,
and permissions are kept in the System.MDA, MDW, MDB, MDX, what the
heck file. Once you logon and enter your User name and Password you
can access the database. That is if you are using ACCESS program. VB
doesn't give a toss about those permissions and the DBEngine will let
you in regardless, and any other Tish Pot VB program that someone else
hacks up will do the same.

Which to my mind makes a nonsense of security.

And I am not going to all the trouble to set the DBEngine to the
System.MDW, code logon forms, add users, check permissions and hooray
henry with bouncy error trapping when I can build my own simple
encrypted user and password file and do the checking there.

Jeff