Err 3188: Couldn't Update; currently locked by another session

A very old app of mine that's been in production use, and largely
unchanged since about 1998 has started recently throwing error 3188
(can't update, locked by another session on this machine) when
saving edits to some memo fields.

I have found a number of things:

1. it happens only with long memo fields, starting somewhere above
255 characters (though I don't know exactly where.

2. it happens only on fields that have multiple controls that
display their data.

In the form I'm having the problem with, it's based on a table with
multiple record types, so two different tabs have controls with the
field displayed on them, though only one is visible at a time. There
is also a subform built on the same table that is non-editable that
displays a summary version of the record (it formats it like the
client's printed catalog entries).

I've solved the problem by tracking changes to the controls and
saving the record after either of the controls is updated. But the
only way to make it not error out is by swapping out the subform.

This did not used to happen -- it seems to have started happening
only in the last few weeks.

Any ideas on this?

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

On Wed, 22 Jun 2005 01:28:25 +0000, David W. Fenton wrote:
[color=blue]
> A very old app of mine that's been in production use, and largely
> unchanged since about 1998 has started recently throwing error 3188
> (can't update, locked by another session on this machine) when
> saving edits to some memo fields.
>
> I have found a number of things:
>
> 1. it happens only with long memo fields, starting somewhere above
> 255 characters (though I don't know exactly where.
>
> 2. it happens only on fields that have multiple controls that
> display their data.
>
> In the form I'm having the problem with, it's based on a table with
> multiple record types, so two different tabs have controls with the
> field displayed on them, though only one is visible at a time. There
> is also a subform built on the same table that is non-editable that
> displays a summary version of the record (it formats it like the
> client's printed catalog entries).
>
> I've solved the problem by tracking changes to the controls and
> saving the record after either of the controls is updated. But the
> only way to make it not error out is by swapping out the subform.
>
> This did not used to happen -- it seems to have started happening
> only in the last few weeks.
>
> Any ideas on this?[/color]
David,

FWIW, I have been experiencing the same error while reworking an old
(circa 1988) A97 app, originally developed on Win95, using my
recently-purchased XP Pro laptop. Memo fields do not come into play as in
your case, but I upgraded (?) XP to SP2 the other day and I do not recall
seeing the problem since. Not much to go on, but there it is.

Cheers,
Doug

David W. Fenton wrote:[color=blue]
> A very old app of mine that's been in production use, and largely
> unchanged since about 1998 has started recently throwing error 3188
> (can't update, locked by another session on this machine) when
> saving edits to some memo fields.
>
> I have found a number of things:
>
> 1. it happens only with long memo fields, starting somewhere above
> 255 characters (though I don't know exactly where.
>
> 2. it happens only on fields that have multiple controls that
> display their data.
>
> In the form I'm having the problem with, it's based on a table with
> multiple record types, so two different tabs have controls with the
> field displayed on them, though only one is visible at a time. There
> is also a subform built on the same table that is non-editable that
> displays a summary version of the record (it formats it like the
> client's printed catalog entries).
>
> I've solved the problem by tracking changes to the controls and
> saving the record after either of the controls is updated. But the
> only way to make it not error out is by swapping out the subform.
>
> This did not used to happen -- it seems to have started happening
> only in the last few weeks.
>
> Any ideas on this?
>
> --
> David W. Fenton http://www.bway.net/~dfenton
> dfenton at bway dot net http://www.bway.net/~dfassoc[/color]

I'll take a shot in the dark. Originally your multiple controls made
the changes fast enough to avoid the record lock collision between
them. Perhaps something like disk fragmentation over time has slowed
the edits enough for the problem to manifest itself for the long memo
fields first because their update is slower. I'd try defragmenting
before trying the save with the corresponding subform swap. Access
happens to be notoriously good at fragmenting hard drives. Although
the problem has cropped up in the last few weeks it may have been
creeping up on you all along.

James A. Fortune

Doug Hutcheson <spamcatcher@software-biz.com> wrote in
news:pan.2005.06.24.04.53.27.888585@software-biz.com:
[color=blue]
> FWIW, I have been experiencing the same error while reworking an
> old (circa 1988) A97 app, originally developed on Win95, using my
> recently-purchased XP Pro laptop. Memo fields do not come into
> play as in your case, but I upgraded (?) XP to SP2 the other day
> and I do not recall seeing the problem since. Not much to go on,
> but there it is.[/color]

Well, it's running on Win2K, as is my development box, and for me it
occurs on both (both SP4).

The problem surely can't be related, as mine is only happening with
long memo fields.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc