How to re-provide password to encrypted linked tables?

[Jill Elaine]

I am building an Access 2002 frontend with linked tables to an
encrypted Paradox 7 database. When I first create these linked tables,
I'm asked for the password to the encrypted Paradox database, and the
linked tables are successfully created. I use the data from these
linked tables in several forms.

All works great until I close the Access frontend and open it again.
When I try to use the forms, I get an error message: "Could not decrypt
file." I know that this is because I need to supply the password again
to access the linked tables.

<growling noises> Why doesn't Access just give me a nice little popup
requesting the password like it did the first time I linked the tables?
How can I get Access to give me the chance to type in the password
again so that the linked tables will work?

Or can I somehow pass the password to Access behind the scenes the
first time the user opens a form? Or maybe can I get Access to save the
password from the initial linking so that it's not needed everytime the
frontend is opened?

Note: I'm not connecting to the encrypted database via ODBC (I don't
have the ODBC drivers for Paradox 7). I'm able to initially link the
database tables (read-only) by just browsing to the folder and
providing the password.

I got this database project dropped in my lap when a 'higher paid'
quit. It's a bit over my head, I admit, but I'm pretty tenacious! I'll
very much appreciate any help and advice you all might have to offer.
Thank you, Jill Elaine

[Jill Elaine]

That noise you hear is me pounding my head against the wall and
wailing, "Why? Why? Why?"

You'd think I'd be celebrating because I've actually fixed the problem
BUT the "fix" (really a workaround) is so MSconvoluted that I think
I'll lose my lunch.

The fix: I already had JET 4 (and Office XP SP3 btw) but I installed
JET SP8 for Windows 2000. I am NOT sure if this really did anything,
but I need to mention it anyway, just in case.

First I deleted all the linked tables to the encrypted Paradox database
that I had previously created.

Then I discovered that I could get the linked tables to work correctly
_IF_ I was asked for the Paradox password when I created the linked
table.

__I had to be sure I was asked for the Paradox password *FOR EACH*
linked table I created!__

If I followed the procedure below, I could close and reopen the Access
database and the linked Paradox tables would open without any errors
(and without requesting the Paradox password).

So, my procedure: I had to open the Access database, create one new
linked table, provide the Paradox password, close the Access database,
open it up again, create the next new linked table, provide the Paradox
password, close the Access database (reiterate until all encrypted
Paradox tables show up as linked tables in Access).

IF I was not asked for the Paradox password when I linked a particular
table, upon first opening Access, that table would throw the error,
"Could not decrypt file", if I tried to open that table before I opened
any "password linked" (for lack of a better term) Paradox tables.
("Password linked" = provided password when creating the link)

Access will allow you to create many linked tables to an encrypted
database at one time, while asking for the password for only the
_FIRST_ linked table you create. The first linked table will be the
only 'password linked' one. Access *appears* to successfully create the
links to the other tables in the encrypted database after you provide
the password for the first link you create, but only the FIRST table
(apparently) is associated with the required password!

This can be very confusing as, if you open the "password linked" table
first, the "non-password linked" tables will open afterwards, but if
you try to open a "non-password linked" table (when you first open
Access), you'll receive the error "Could not decrypt file".

Further information: this issue of "password and non-password linked"
tables (to an encrypted database) is associated with the error message
"Application-defined or object-defined error" when running the Linked
Table Manager in Access. If you try to update a "non-password linked"
table (and no "password linked" tables have been opened or accessed),
LTM throws that error.

I had a mix of "password and non-password linked" tables in my Access
database, which meant that sometimes the linked tables would work and
sometimes I'd get errors, depending on which linked table I first
accessed! What a nightmare to solve! I found so many related questions
in numerous Access forums...and no documentation on MS Knowledge Base.
Hopefully this 'workaround' will help others with the same problem I
had.

Had to answer my own question! :-)
Jill Elaine

[Ananda Sim]

Hi Jill,

It may be a generic assumption in Jet. Jet .mdb and ODBC connections to
say Oracle assume that there is one username/password into a set of
database tables within the same security container. Maybe Jet does this
for Paradox tables as well even though we know that Paradox tables are
exist as physically separate entities on the file system.

Ananda

Jill Elaine wrote:

That noise you hear is me pounding my head against the wall and
wailing, "Why? Why? Why?"

You'd think I'd be celebrating because I've actually fixed the problem
BUT the "fix" (really a workaround) is so MSconvoluted that I think
I'll lose my lunch.

The fix: I already had JET 4 (and Office XP SP3 btw) but I installed
JET SP8 for Windows 2000. I am NOT sure if this really did anything,
but I need to mention it anyway, just in case.

First I deleted all the linked tables to the encrypted Paradox database
that I had previously created.

Then I discovered that I could get the linked tables to work correctly
_IF_ I was asked for the Paradox password when I created the linked
table.

__I had to be sure I was asked for the Paradox password *FOR EACH*
linked table I created!__

If I followed the procedure below, I could close and reopen the Access
database and the linked Paradox tables would open without any errors
(and without requesting the Paradox password).

So, my procedure: I had to open the Access database, create one new
linked table, provide the Paradox password, close the Access database,
open it up again, create the next new linked table, provide the Paradox
password, close the Access database (reiterate until all encrypted
Paradox tables show up as linked tables in Access).

IF I was not asked for the Paradox password when I linked a particular
table, upon first opening Access, that table would throw the error,
"Could not decrypt file", if I tried to open that table before I opened
any "password linked" (for lack of a better term) Paradox tables.
("Password linked" = provided password when creating the link)

Access will allow you to create many linked tables to an encrypted
database at one time, while asking for the password for only the
_FIRST_ linked table you create. The first linked table will be the
only 'password linked' one. Access *appears* to successfully create the
links to the other tables in the encrypted database after you provide
the password for the first link you create, but only the FIRST table
(apparently) is associated with the required password!

This can be very confusing as, if you open the "password linked" table
first, the "non-password linked" tables will open afterwards, but if
you try to open a "non-password linked" table (when you first open
Access), you'll receive the error "Could not decrypt file".

Further information: this issue of "password and non-password linked"
tables (to an encrypted database) is associated with the error message
"Application-defined or object-defined error" when running the Linked
Table Manager in Access. If you try to update a "non-password linked"
table (and no "password linked" tables have been opened or accessed),
LTM throws that error.

I had a mix of "password and non-password linked" tables in my Access
database, which meant that sometimes the linked tables would work and
sometimes I'd get errors, depending on which linked table I first
accessed! What a nightmare to solve! I found so many related questions
in numerous Access forums...and no documentation on MS Knowledge Base.
Hopefully this 'workaround' will help others with the same problem I
had.

Had to answer my own question! :-)
Jill Elaine