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
