Re: Error -2147467259 Could not save; currently locked by anoth

On Nov 16, 8:33 pm, "Ralph" <nt_consultin...@xxxxxxxxx> wrote:
"Mike" <M...@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message

news:EF5E65A8-DDE0-4754-A4F1-6390BEF70221@xxxxxxxxxxxxxxxx> Any one have idea? I don't think this is permission issue because I am
able
to save
new record in the same table with memo text.
Thanks

<snipped>
This error as others have reported is most commonly caused by permission
problems with the folder where the mdb file is located. You have however,
dismissed this.

I think you said you are the only "User" (Admin Exclusive-Access????), so
the next step is to determine why Jet thinks there is another User. The
other option is that the error itself is bogus, and that there is actually
something else going on because of a difference in circumstance.

If I were in your shoes I would go back over the whole process of calling
this particular routine.

One thing you are doing that I would change is the use of the "As New"
declaration.
Dim cnn As New ADODB.Connection

This is usually a bad idea. When you do this the code instruments the follow
'hidden' code for every call on the object...
If cnn Is Nothing Then
Set cnn = New ADODB.Connection
cnn.Execute ...
End If
So you saddle yourself with all this extra code. It also can hide problems,
because no matter where you call it you will get an initialized valid
object. But not necessarily the same object.

I would dump this declare in favor of specifically Newing a reference and
track that reference.
Dim cnn As ADODB.Connection : Set cnn = New ADODB.Connection

We don't know anything about the context where this call is being made, but
consider that ADO has a thing called Connection Pooling. That means when the
ADODB library is first initialized it create a Pool based on the Connection
String. Subsequent calls get a connection from this pool. It is possible in
a tight loop you actually have more than one connection.

Anyway, rework the code to remove the "As New" declarations. Second, expand
your investigation beyond the single call and see if there isn't something
interesting in the context between the call that fails and those that
succeed.

Poor help I know, but one never knows. <g>

-ralph

Set command
Lock type = optimistic
Cursor type = Static
Cursor Location = Client Side

This should solve the problem
.

Relevant Pages