Error 3218 Could not update; currently locked - but it isn't

[nodrog77]

(see also thread702-1520919 )

Hey All,

This is a problem that has suddenly appeared in a Database that has been working very well for a number of years. It is a single shared database on a network drive which can have up to around 20 users.
- The Version is Access 2003:
---------------------------
Version 11.0
Build 6566
Product ID 73931-640-1920351-57895
Application path C:\Program Files\Microsoft Office\OFFICE11\
Language English (United States)
ADO version 2.8
VBA version 6.05
References VBA, Access, stdole, DAO, ADODB, Office
Database name RAVTRACK_2010.mdb
Database size 44568.0 KB
Current user Admin
Jet version 4.0

------------------------------------
- The default open mode is shared
-the default record locking is No Locks but the option "Open Databases using record level locking" is ticked.

Full Description:
The error is originating in a Parent form with a (continuous) child subform and What appears to be happening is that the error 3218 is occuring but the entire table appears to be locked from then onwards, This error can occur with only two users and neither need to be accessing the same record it seems. I am going to further investigate this problem and post updates but it seems strange that this has just started happening. I have seen something similar reported with Access 2000 (

http://support.microsoft.com/kb/238258/en-us)

and other users reporting the problem on Tech Noticeboards with Access 2003 but no solution

Any Ideas would be good - but please note - I'm not going to move to a multiple front end/ linked back end solution just to fix this problem,

Ciao,
Lea

 

[lameid]

Are you saying that you are not using a split database with each user having his own copy of the front end?

That is my first thought and recommendation. Turning off Autocorrect could conceivably have some impact but not likely (aside from things working faster).

 

[nodrog77]

lameid - No I'm not using a split Database - for various reasons including the fact that I don't have access to individual users machines to install and maintain front end copies and the network the Database resides is not reliable enough to even split the database into two version (one code and one data).

Can you explain why turing off "autocorrect" would make a difference?

Thanks

 

[lameid]

Autocorrect is another source of locking of tracking changes to objects. I doubt it would have an impact but conceivably. More likely it may speed up a machine causing the problem.

for various reasons including the fact that I don't have access to individual users machines to install and maintain front end copies and the network the Database resides is not reliable enough to even split the database into two version (one code and one data

Are you saying a performance decrease in using a split applcation over the network? Are you using Novell? Until recently I had never seen that effect but since the company I am contracting for uses an old version of it, I have seen that problem.

 

[nodrog77]

Thanks lameid,

I'll investigate turning off autocorrect.

Re: Split application over the network,

I'm not sure whether I have a performance Decrease over the network with a split database. We just have a problem with the server we use for all our data being way overused and having a habit of dropping out every now and again (it is a Novell network by the way). Splitting the application in two (which I tried for a while) just tends to create more of a mess to clean up when a dropout happens so I put everything back in the one file again.

Thanks for you're help ,

Leandra

 

[lameid]

Using a split database with a copy on each user's computer should decrease server usage by having the Application objects not have to load over the network. On the Flip side in this Novell environment I'm in there seems to be both file cache and some sort of Network throttling at work.

When the database is split a continuous connection is not kept to the data so it is not cached locally. Because it is not Cached it gets really slow. The problem here is that updates do not necessarily happen right away. I have heard reports of users of another database not see changes until they both get out and back in. I suspect if more than one person was updating data at a time that there would be problems with one set of changes being over written. I suspect Novell can be set to be Access friendly. Unfortunately, I have a snowball's chance in hell of getting anything changed here.

I only mention it, in case you are in a similar or the same environment