470,596 Members | 1,164 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 470,596 developers. It's quick & easy.

Error 3052 File sharing lock exceeded

Hi All,

Recently encountered problems with "Error 3052 File sharing lock exceeded". I have done some research and found the aswer here on the forum. However, I have the following questions:
- The number of records in my file (text file) are only small - 3500 and this error is happening. Thought it was suppose to occur only in big files?
- could it be in the code? it is stated "dbopentable" does that mean that the locking is done on the table e.g over 200,000 records. Would dbopendynamic be better?

Please provide any tips, suggestions etc.

May 8 '06 #1
3 4658
I don't think the type of recordset matters in this case.

I've never had this problem, but from what I've read, you could theoretically get this error with any number of records, it all depends on the value you've assigned to your MaxRecordLocks (or the value your administrator has set it to if you're on a Novell Netware server).

You've probably already seen how to adjust the MaxRecordLocks. Microsoft's technet article on the subject is here:


Your administrator will have to adjust it, though, if you are on a Novell Netware server.

If this doesn't solve your problem I'm not sure what you need to do, never had this problem myself so I'm only rehashing what I've read elsewhere on the subject.
May 10 '06 #2
Hi cweiss,

thanks for your response. Appreciate it.

you are right, I have tried adjusting the MaxRecordLock in the registry on the server and my computer. However, regardless of what number I put, eg 500,000 , it does not make a difference. Instead, I managed to load the file once most users have stopped using the server.

that was why I thought it might be the recordset.

Any more tips would be helpful...anyone????
May 11 '06 #3
Hmm, do you think it could be the number of users connecting to the DB simulateously? I don't use access as a backend (it sounds like you are though), so I wonder if that's why I've never had this problem.

I found a post that might help on google groups. One good point he made, I thought, was that if you use bound form, then every time it's opened, a connection to the underlying recordset will be opened.

Yes, we have a number of databases which are used concurrently by 50-100 users, with few problems. In certain "high volume" databases you may run into "record locking" (which is really page locking of 16 KB, I believe.). However, you can adjust the Record Locking "levels" in Tools ---> Options ---> Advanced, clicking on the "Edited Record" button, so that there is minimal locking.

I believe that there is a limit to the number of people that can have an
Access file open at the same time (about 256, I believe). But there are ways around this.

First would be to use SQL Server as a back-end. Second would to use UNBOUND forms for everything in the front-end (using SQL Server or Access as a back-end) and have absolutely NO linking of the front-end to the back-end. Instead, all data is called up and/or written to the back-end via SQL commands. In short, the user is connected to the back-end file only for the miniscule fraction of a second that the record is pulled into the form or being updated back into the table. (However, unless you are talking a really high production environment, e.g., have 1000+ users continuously entering data into the same back-end all day long non-stop, this probably isn't necessary.

---Phil S.
This may not be applicable to you though.

I am kinda curious as to what's causing your problem. If you find a solution before somebody here does, I'd be interested to hear what you did to fix it.
May 11 '06 #4

Post your reply

Sign in to post your reply or Sign up for a free account.

Similar topics

1 post views Thread by rdavis7408 | last post: by
9 posts views Thread by JTrigger | last post: by
17 posts views Thread by Peter Duniho | last post: by
1 post views Thread by scriptgirl123 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.