[AccessD] Error 3218 "Couldn't Update; Currently Locked" <<HOW TO TEST?>>

Gustav Brock gustav at cactus.dk
Mon Jan 19 02:25:51 CST 2004


Hi Sad

> thanx again. However, I'm a 'rent-a-programmer'
> (what's the official anglish term?) and this
> organisation is completely Oracle minded => SQL-server
> is bad, MS sucks and Access...isn't that some sort of
> notepad? 

> So, I need proof. Is there a correct way to test this?

Yes, talk to the NetWare administrator. She just needs to type them on
the console, no rebooting is needed. If success, append the commands
to the autoexec.ncf file, if not they will vanish the next time the
server is rebooted - in a couple of years.

These settings are not hacks but the documented way to deal with the
issue which is not related to Access only but to any (database)
program requesting bunches of record locks:

  http://support.novell.com/cgi-bin/search/searchtid.cgi?/10019363.htm
  http://support.novell.com/cgi-bin/search/searchtid.cgi?/2914607.htm

The reason why these settings are low as default is only to save a few
KB of ram which was important in the days of x86 processors and
servers running on 8 or 16 MB ram. For the newer NetWare versions - I
believe from 5.1 and up - the default settings are much higher.

/gustav


> --- Gustav Brock <gustav at cactus.dk> wrote:
>> Hi Sad
>> 
>> Those settings are probably to low.
>> Try setting them to maximum:
>> 
>> > These two commands may be set at the console screen, they will take
>> > effect at once and doesn't require restart of the server. If they
>> > prove of beneficial, include them in the autoexec.ncf file of the
>> > server. 
>> >
>> > SET MAXIMUM RECORD LOCKS = 200000
>> > SET MAXIMUM RECORD LOCKS PER CONNECTION = 100000
>> >
>> > The only drawback is a slightly larger RAM allocation which is not
>> > significant with today's multimegabyte servers but did count in the
>> > days of servers running on 8 to 16 MB RAM and every 100K was of
>> > importance.
>> 
>> /gustav
>> 
>> 
>> > These are the new settings:
>> > Max. Records Lock per Connection: 1000
>> > Max. Files Lock per Connection: 5000
>> > Max. Records Lock: 40000
>> > Max. Files Lock: 400000
>> 
>> > How can I test these? Ok, for the first one I have to
>> > lock 999, 1000, 1001 records...question is how do I do
>> > that?
>> 
>> > Is importing a file with 999, 1000, 1001 records
>> > enough?
>> 
>> > Any testing tips/links?
>> > TIA.
>> 
>> > SD
>> 
>> 
>> > --- Jim Dettman <jimdettman at earthlink.net> wrote:
>> >> <<We use A2K SP1 on a Novell network.
>> >> occasionally the users get the following error:
>> >> Error 3218 "Couldn't Update; Currently Locked">>
>> >> 
>> >>   There are lots of things that will cause that
>> >> message, but I think you
>> >> might be barking up the wrong tree in that it's a
>> >> Novell problem.
>> >> 
>> >>   From your comments abut it being "buggy", I would
>> >> think more that the app
>> >> was poorly written and stepping on it's own toes,
>> >> resulting in the above
>> >> error.
>> >> 
>> >>   One way to check that out easily is to copy the
>> >> backend to a local drive,
>> >> re-link the tables (I'm assuming it's a split app),
>> >> then test.  If you still
>> >> get the error messages it has nothing to do with
>> >> Novell.  If the error
>> >> disappears, then it's related to locking.
>> >> 
>> >>   The other test you can do is using the SetOption
>> >> method of the dbEngine
>> >> object, set dbMaxLocksPerFile to a number less then
>> >> the allowed number of
>> >> locks under Novell.  This will ensure that JET never
>> >> uses more locks then
>> >> Novell allows.  If that was the problem, the error
>> >> messages will disappear.
>> >> 
>> >> Jim Dettman
>> >> President,
>> >> Online Computer Services of WNY, Inc.
>> >> (315) 699-3443
>> >> jimdettman at earthlink.net



More information about the AccessD mailing list