Clarification on Security?

I have been snooping on this board, searching for infomation on accessing a secure access database. I have written a program that assigns activation keys for another of our programs, and it's all finished, except for the securing of the database. For obvious reasons, it would be foolish to allow general access to the "access" database (no pun intended). From what I am reading on the posts it is not possible to access an encrypted, password protected database with ADO. If this is true, how come there is a spot for the password in the connection string. (not that I can get the connection string to work with a password anyway, I just figured it had something to do with quotes). Since I have never heard of ADOX, how hard is it to "retrofit" my current connection strings for that. Would it be easier to not encrypt, but just to password protect. What are the security issues with not encrypting. I Know I have a million questions here. If anybody has done this before or could lend an idea it would be greatly appreciated.

Medic,
Dunno if this will help, but we use the ADO setup below to get into an access secured (.mdw) access database of ours.
<PRE> conYourConnectionObject.ConnectionString = "Provider=Microsoft.Jet.OLEDB.3.51"
conYourConnectionObject.Properties("Jet OLEDB:System database") = "c:\pathto\your.mdw"
conYourConnectionObject.Properties("User ID") = "WhateverUsername"
conYourConnectionObject.Properties("Password") = "WhateverPassword"
conYourConnectionObject.Open "Data Source=c:\pathto\your.mdb"</PRE>You could probably combine the ConnectionString and Open arguments (that's the way I usually do opens) - this source was provided to me by my coworker who figured out how to do this after much experimentation and hair pulling. He sets up his ADO a little differently than I do. The main thing with this is that you can't just put the username and password in the connection string - you have to first let ADO know where the security file is and set it all up through (very obscure) properties.

Good luck,
Paul

Well Paul, Thanks for the code. I was able to use it to open my database, but only after a couple of frustrating hours setting up an mdw file. That's when I found out the mdw file restricts my Access executable access, not the database access. Therefore, on any other computer, the table opens just fine. I need something to open the database when it's encrypted with the database password, (which, by the way, does not offer support for a User name). VB may be frustrating sometimes, but Access is Far WORSE! I'm going to see if I can find some info on ADOX, since my hair pulling tim eis not over yet!

The Search for the Holy Grail has been successful! For any of you out there who are in the same boat I was in here is what I found!

DBConnection.Open "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & GloDBPath & "\ClaimsDirectActKeyGen.mdb;Jet OLEDB:Database Password=grsbls0104;Persist Security Info=False"

It's one line of beautiful code that works! Alas, it was from another Forum that I found it. I had given up on all of the rest of them, as this one was so superior. (Mainly due to a few great people whom have been ever so helpful! PWNettle and Bill Soo to name a few) Sometimes, though, you do find a few gems elsewhere. Here is what I understand, and somebody PLEASE correct me if I'm wrong.
My opinion about the mdw files is that they are absolutely useless. They allow you to set up User names and profiles that are very difficult and convoluted to set up, and then they require you to use them in conjunction with your Access executable. The Problem is, you take that same database file (*.mdb) and can open it just fine with another computer that has access on it! No Username or password required! (Asanine!) The lesser security method involved assigning a password to the DATABASE, which is then needed to open the file on other computers! This password does not involve usernames at all, which is why I found the string above to be my golden ticket! I hope my frustration is not all for not, and that others can read this later and be able to avoid the path I went down. And thanks again to all of you Gurus on the board who care! We really appreciate it!
Medic