Access Security (Access 2000)

Topic

New Reply

Hello,

I created an Access 2000 database for someone and when they go from ‘design’ mode to ‘view’ mode they get the following error:

Run-time error ‘-2147467259 (80004005)’ The database has been placed in a state by user ‘Admin’ on machine ‘WEIGET1’ that prevents it from being opened or locked.

‘WEIGET1’ is her machine and she is the only one with the database open. I am wondering if there are any security settings that I am missing that would cause her to get this message. I don’t know what I need to do so she doesn’t get the error. I’d like her to be able to go back and forth into design and view mode without problems. What am I doing wrong?

Any help would be very appreciated.

Regards,

Amanda

Reply | Quote

Replies

What OS are you using? Windows 2000? This sounds more like a Windows 2000 permissions problem than an Access security issue.

But first, you need to rule out that it’s not the Access security which is causing the problem. (I assume you didn’t create Access login security for this user. If so, none of the following applies.) In Access, go to User and Group Permissions under the Tools | Security menu. You should see only one user: Admin. Make sure that user has full rights for ALL the objects — the Database itself, Tables, Queries, Forms, Reports, etc.

If you find that the Admin user indeed has full rights, then like I said, your problem is most likely due to Windows 2000 (or whatever OS you’re using) permissions. In the directory where this DB is stored, make sure this user has full rights to the directory itself and this particular database file. You’ll have to log into Windows 2000 (or whatever OS you’re using) as an administrator in order to do this. I don’t remember all the particulars of setting permissions in Windows 2000, so you should consult your Windows documentation before doing this. Just remember, give this user full rights for that directory and the file itself.

Stephan

Reply | Quote

Thanks for the help, but, *sigh* unfortunately it didn’t solve the problem. *pout* I went ahead and checked all permissions and they were set correctly – to have full access. When I get the runtime error indicating that “The database has been placed in a state by user ‘Admin’ on machine ‘WEIGET1’ that prevents it from being opened or locked.” it is a “debug” message – meaning I can go in and debug the error. It takes me into VB code that I wrote that connects to the database. The following is the code:

Set Conn = New ADODB.Connection
Conn.Open “Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:My DocumentsdatabasesProductReleaseControl.mdb;”

and I am getting the error when I execute the Conn.Open statement – but only when I switch from design mode into view mode. Strange. Anyway, I am guessing that what is happening is that the connection is being created in view mode and then after switching into design mode and then back into view mode the connection is tried again and that is where it is locking up. So, perhaps my question is – How can I create a connection to the database in my VB code that will not cause this error when a user tries to go to and from design mode. Perhaps the connection string that I am using is not the right kind?

As always, any help is greatly apprecitaed.

Regards,

Amanda

Reply | Quote

Seems like you have set a password for the Admin User.
A database password is set in Tools | Security | Set Database Password. This will be only for this database.
If you have use Tools | Security | User And Groups Accounts and changed the password in the Change Logon Password, you change the password for the user Admin for all databases.

Reply | Quote

Just tried setting a password for Admin User and no luck. I still get the error. I’ve been looking at it all morning again and I think what is happening is when a form is in design mode, the database gets locked so design changes can be made. Then, when the form gets switched back to view mode and the connection string code tries to execute, the lock created while in design mode still exists and the code trying to open the connection fails. So, before I execute the Open command, maybe I need to “close” or “unlock” the database connection that was created while in design mode? I am not sure if that makes any sense, but I am thinking that the problem is not security (like I once thought), but rather a connection problem. Only, I know my ADODB connection “syntax” is fine, it’s just that it errors when I go from design mode to view mode.

Anyone have any suggestions?

Regards,

Amanda

Reply | Quote

Hi Amanda,
How is this code being triggered? I assume it’s event driven, but which event? Also, can you post the whole of the code?
Incidentally, I think Francois response was actually in relation to another post regarding password protection (but I could be wrong!)

Reply | Quote

Sory Amanda,
Rory is right.
This was for post 129787 from SOS Typing.

Reply | Quote

Rory,

Thanks for your reply. The code (the connection string) is inside of a Function that the form calls when it loads. Here is the function…

Function GetDBConnection()

‘Open the Connection Object
Set Conn = New ADODB.Connection
Conn.Open “Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:My DocumentsdatabasesCurrentCopy(Tonya)ProductReleaseControl.mdb;”

GetDBConnection = Conn

End Function

And here is the VB for the form that calls the function:

Private Sub Form_Current()

DoCmd.Maximize

‘Open the Connection Object
Call GetDBConnection

End Sub

So, when the “form_current” executes, it calls the function which creates the connection string. The form then uses the Conn object for various tasks. But, I think the database is still locked from the form previously being in design mode and that is why opening the connection is failing. Anyway, as always, any ideas or suggestions are appreciated.

Regards,

Amanda

Reply | Quote

Hi Amanda,
A couple of things:
1. I assume Conn is declared outside the procedure?
2. Is there a reason you’re using the form’s Current event rather than the open or load event? It will fire every time you change record as it stands.
3. You’re assigning Conn to GetDBConnection but you’re not actually using GetDBConnection to return an object. I’d suggest commenting out or removing the GetDBConnection = Conn line.
Any of that help?

Reply | Quote

Rory,

1. Yes, Conn is declared outside the procedure and is Global
2. I am not sure why I am putting the function call in Current instead of Open or Load….?? Must have been developing and put it there by mistake. Good catch!
3. I commented out he GetDBConnection = Conn line (good catch again!) but am still stuck with the same problem. I am still getting the runtime error when I switch from design mode to view mode.

Is there a setting in Access that I may be missing that would not lock the database when a form (or other object) is in design mode? I still think that the database is getting locked while it is in design mode and then when I flip back to view mode and the VB ADODB connection string tries to execute it fails because the database is still locked from it previously being in design mode.

Any ideas?

Regards,

Amanda

Reply | Quote

Have you closed and reopened the database since changing the code (just to make sure everything has reset itself)? I will have another think in the meantime!

Reply | Quote

Yup, closed and re-opened the DB a couple of times just to be sure.

Thanks for you help. I really do appreciate it.

Regards,

Amanda

Reply | Quote

It’s just a thought but one other thing to try is a compact and repair. I have seen some pretty strange occurrences that this procedure has fixed. You can locate this under Tools, Database Utilities, Compact and Repair.

Thanks,
Mark

Reply | Quote

Yup, tried compacting and repairing too. No luck. *sigh* I’m about ready to go crazy! Just can’t figure it out…..

Thanks for everyone’s continued help!

Reply | Quote

ADO connections are more persistent that DAO connections. Just switching to design view doesn’t necessarily close the connection. You might try specifically closing the connection in the Unload event of the form and see if that cures the problem.

Reply | Quote

Hi – sorry to butt in here, but I have a sneaking suspicion you have a thread of code running somewhere that has not been terminated. We see that kind of behavior in Access 2000 fairly often during the development phase. How is your global connection being set up? Just a hunch, but check and see if it’s really closing down. As a general rule, we do connections behind the form and then release them when the form is closed. It does add a small amount of overhead, but it’s much easier to debug when things go haywire. Hope this is useful in resolving your problem.

Reply | Quote

Here is a link to a child thread on the same topic. There is no point in having everyone bouncing back and forth.

Reply | Quote

Charlotte,

I’m sorry, guess it didn’t occur to me that I could change the subject otherwise I would not have cross-posted the question. Oops!

Everyone,

I am going to close the connection in the unload of the form again and see if it fixes the problem. I think I tried that already, but it is worth another try…

Thanks for everyone’s help! I don’t know if I have ever found another thread that is so helpful and responsive!

Amanda

Reply | Quote

[indent]

---

guess it didn’t occur to me that I could change the subject

---

[/indent]The Lounge has all the modern conveniences!

Reply | Quote