I created a database password. Everything seemed fine until I tried to open
a report and now get the error message "not a valid password". The other
reports seem fine but for some reason this one is locked up. Help please.

Yes, the report is in the same database that I protected and have since
unprotected. When I try to access the design view of the qry the report is
based on it will only open in SQL mode. I am not familiar enough with SQL to
figure out how to delete and recreate the links to the tables within this
database. Any other suggestions?

"Chris O'C via AccessMonster.com" wrote:

> If the report is using linked tables to the password protected db, delete
> these links and recreate them. You'll be prompted for the password when you
> make the links.
>
> Chris
> Microsoft MVP
>
>
> NV wrote:
> >I created a database password. Everything seemed fine until I tried to open
> >a report and now get the error message "not a valid password". The other
> >reports seem fine but for some reason this one is locked up. Help please.
>
> --
> Message posted via AccessMonster.com
> http://www.accessmonster.com/Uwe/For...urity/200810/1
>
>

Right, I agree with that. I still think it has something to do with setting
the password though since the report correctly opened thru a command button
and also by clicking on the report itself just prior to adding a password. I
also find it odd that the qry now will not open in design view. It doesn't
make any sense to me. The other buttons as well as other reports are
unchanged.

"Chris O'C via AccessMonster.com" wrote:

> Then it's not using a linked table from a password protected db.
>
> My suggestion was for a linked table used in a report in the current db -
> where the link to the table in the current db was created *before* you either
> added or removed a db password on the db where that table is really located.
>
> If your report and table are in the current db, it doesn't matter if there's
> a db password or not because you've already opened the db before you tried to
> open the report. The db password has no effect on the db that's already
> opened.
>
> Chris
> Microsoft MVP
>
>
> NV wrote:
> >Yes, the report is in the same database that I protected and have since
> >unprotected.
>
> --
> Message posted via AccessMonster.com
> http://www.accessmonster.com/Uwe/For...urity/200810/1
>
>

Thank you Chris. I was mistaken. It just occurred to me that the query for
that report had an old link to a entirely separate database that I also
happened to put a password on and I didn't think to remove that password
since it was a link I probably put in place years ago. I guess I have too
many databases. I appreciate your help in getting my head in the right place
to solve my problem. I removed the linked table to solve the problem,
however, in the event that I wanted to have the database locked but still
linked to another database that was locked how then do I get around the 'not
a valid password' problem?


"Chris O'C via AccessMonster.com" wrote:

> You're describing the problem that happens when someone puts a db password on
> a file that has tables which are linked to in other dbs. Whenever another db
> tries to open the linked table it reads the link info - which doesn't have a
> password in it because it didn't exist when the link was created and *never*
> gets updated if the table or db changes - to connect to the (now) password
> protected db.
>
> But you're telling me the report is in *this* db, the table is in *this* db,
> the password is on *this* db and there isn't a linked table the report is
> using.
>
> Could you be mistaken?
>
> Chris
> Microsoft MVP
>
>
> NV wrote:
> >Right, I agree with that. I still think it has something to do with setting
> >the password though since the report correctly opened thru a command button
> >and also by clicking on the report itself just prior to adding a password. I
> >also find it odd that the qry now will not open in design view. It doesn't
> >make any sense to me. The other buttons as well as other reports are
> >unchanged.
>
> --
> Message posted via AccessMonster.com
> http://www.accessmonster.com/Uwe/For...urity/200810/1
>
>