[AccessD] Dubious value

>From the following blog:

http://blogs.msdn.com/michkap/archive/2005/10/19/482694.aspx

There is the Jet 4.0 feature of record level locking that people love, so I
will talk about that.

Now the rule is that once the database is opened (by anybody), that is the
mode of the datasbase until all user are out of it; this makes sense since
locking schemes have to apply to all concurrent users to have any meaning.

So what this means is that the Access setting in the Tools|Options Advanced
tab (the chekbox "Open databases using record-level locking") is a request,
not a demand. If the database is already opened in the other mode, your open
will not fail, and with the current design you are not even warned that your
preference was not heeded since your request could not be honored.

But two additional warnings that you my find useful here exist:

    * 3811 -- Attempt to open the datasbase with the requested record level
locking failed; page level locking will be used
    * 3812 -- Attempt to open the datasbase with the requested page level
locking failed; record level locking will be used

What this means is that if in your database you run the following code after
it is open:

    Set con = New ADODB.Connection
    con.Provider = "Microsoft.JET.OLEDB.4.0"
    con.Properties("Data Source") = CurrentDb.Name
    con.Properties("Jet OLEDB:Database Locking Mode") = 1 ' use 0 for page
level check
    con.CursorLocation = adUseServer
    con.Open

and the database was not in the mode you asked for tht you will see one of
those warnings in the NativeError property, right in
con.Errors(0).NativeError! You will see one of the following values
(depending on whether you set the locking mode to 0 or 1 in the code) if
there is something in that collection (on 100% success it will be empty):

    * 249761507 -- Warning 3811 above (in hex it is 0x0ee30ee3, and 0x0ee3
is indeed 3811)
    * 249827044 -- Warning 3812 above (in hex it is 0x0ee40ee4, and 0x0ee4
is indeed 3812)

So it is as simple as that. You can obviously combine this with an
Application.GetOption("Use Row Level Locking") to see if the user running
the code is the cause of the problem so you can kick them out or whatever.
This becomes a much cooler way to solve problems such as those documented in
KB article 237333, which just tells people to change the setting in Access
and does not help people to fix the problem of the fact that it is not
always that user's settings which are causing the problem....


************************

As always happens however... When I try and use that code, none of the above
errors occur, rather I get a message:

"the database has been placed in a state that prevents it from being opened
or locked"

I thought I would use this code to troubleshoot locking issues since I have
several clients where locking is an issue.  Can anyone look at the code and
comment on why I would not get the indicated error?

I am (for now) just running the code inside of my framework, standalone.

John W. Colby
www.ColbyConsulting.com