Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Compacting Access D/B Requires Password

5 views
Skip to first unread message

XcelSoft

unread,
Aug 1, 2003, 12:01:15 PM8/1/03
to
I have an Access 2k database that is password protected and is set to
compact on close. After I installed SR1a, now during the compacting
process the password prompt pops up and you have to enter the d/b
password in order to continue.

Is there a way to stop the password promt from appearing during
compacting??

Thanks,

Xcelsoft

Deano

unread,
Aug 1, 2003, 12:30:57 PM8/1/03
to

I ran precisely into this problem and ultimately i gave up on trying to
solve it. The solution I was given was to use a loader Access db that would
open a password protected db, remove the password then set it to "". After
the compact code ran then the password would be set once more.

The code in the loading program was;

'Start of code
--------------
'*********** REMOVE PASSWORD ***********

Dim dbPwd As DAO.Database, strOpenPwd As String

strOpenPwd = ";pwd=magic"
Set dbPwd = OpenDatabase(txtPath, True, False, strOpenPwd)
With dbPwd
.NewPassword "magic", ""
.Close
End With
'****************************************

Dim RetVal
RetVal = Shell("MSAccess.exe """ & txtPath & """ /compact", vbNormalFocus)

Dim db As Database
Set db = OpenDatabase(txtPath, True, False, strOpenPwd)
db.NewPassword "", "magic"

'end of code
-----------

The user would supply txtPath by typing into a textbox.

The problem was while it would work at times it often just bugged out, as
the password state wasn't always correctly set.
I really didn't know why it was happening and it was hard to debug.
Compacting in the runtime environment would definitely bugger up the
password, so that it would work once, then fail the next time.

We wanted a password protected db (for what it was worth) that could be
opened and compacted without the user entering the password. But I just
felt it to be too flaky and more than likely i'd have to hand out passwords
anyway for users to open the damn thing as soon as it went wrong. I really
don't think the database password is meant to be manipulated in this way
else it would be a whole lot more reliable.

Suffice to say we have bitten the bullet and are now supplying the password
up front. The user enters this and have the ability to auto-login into our
app once it loads (so they don't have to enter a db password and then log
into our app with a username and password as well - this is fine for our
app).


hth
Martin


Deano

unread,
Aug 1, 2003, 12:35:49 PM8/1/03
to
Deano wrote:

< my post snipped>

that was in Access 2000 BTW.


Eric Sherman

unread,
Aug 1, 2003, 1:13:13 PM8/1/03
to

Thanks for your reply. I will give it a try.

ET Sherman


*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

0 new messages