Error 3188 Access97 Bug

  • Thread starter Thread starter Ian Smith
  • Start date Start date
I

Ian Smith

In attempting to resolve my popup problem (appears a few
lines beneath this one), I came upon mention of my
symptoms as a "long outstanding bug in Acess97". Yet I
can't find any mention of it on the microsoft site, and
few mentions of it elsewhere. Worse, I can't find a
workaround.

Can anyone shed any light on this "bug" and its current
status?

Here's the symtom:

A form displays a memo in a small field. To edit the
field, I do a me.renew to ensure I'm not holding a lock on
the record, then open up a popup form to see and edit the
full text.

All is well until the memo grows in size (the reference I
read thought something like 2000 characters would triger
it). At that point, the popup gets Error 3188 - Couldn't
update; currently locked by another session on this
machine.

The lock is bogus. The main form has done everything it
can to ensure it isn't locking the record, and the code
works until the memo field gets large.

Help, Please!
 
Ian, I don't have a solution for you, but the bug is still reproducable in
Access 2003.

If you are not releasing a runtime, you could work around the issue with
Shift+F2 to fire up the zoom box. Programmatically it's RunCommand
acCmdZoomBox.
 
Isn't the zoom box just a normal Access form in a wizard database somewhere?
If so, I wonder how >it< avoid the problem. It might be worth the OP's time
to check that out.

TC
(off for the day)
 
field, I do a me.renew to ensure I'm not holding a lock

I take it that it doesn't work with Memo fields once
they become large enough to move to a separate page in
the database.

I'm interested, but not amazed. (I see that Microsoft
only ever claimed to have reduced the problem of excessive
locking on memo pages, not eliminated it).

Use an unbound pop-up, copy the memo data into it,
then use code to update the original field in the
original form.

Or temporarily unbind the background form while the
pop-up is open.

Or close the background form while you have the pop-up
bound to the record.

Or put your memo fields into a table of their own,
and manage the linking and relationships yourself,
instead of depending on the database engine to do
it.


This problem is a part of the problem of handling locking
and append/update/delete anomalies with related tables. It
is made difficult because Jet does not have a means to
compare memo fields to determine if the data has changed.
Expect this 'bug' to be 'fixed' only if the Jet Engine is
re-written or replaced.


(david)
 
Yes, the zoom box could be simulated with a text box on an unbound form.
Copy the contents of the control to the text box, and pass a reference to
the memo field (even Screen.ActiveControl would do).

Then if the user choose Ok (rather than Cancel) in your quazi-zoombox form,
copy the contents of the text box back to the Value of the original control.

May not be what the original poster needed, but it would work around the
issue.

(A day off is better than an off day.)
 
Allen Browne said:
Ian, I don't have a solution for you, but the bug is still reproducable in
Access 2003.

If you are not releasing a runtime, you could work around the issue with
Shift+F2 to fire up the zoom box. Programmatically it's RunCommand
acCmdZoomBox.
Click to expand...

Are you saying the ZoomBox doesn't work in the Runtime?
 
The Zoom box doesn't work for my application. But copying
the text to an unbound text box might be my answer.

Thanks
 
Thansk for your thoughts, David.

I was thinking of temporarily unbinding the main form, but
I think I like the idea of copying the memo text to an
unbound form better.
 
Allen Browne said:
It's been many years since I tried, Rick.
Is you experience different?
Click to expand...

Well on my machine where I can only test using the /Runtime switch it still
works. I don't have a machine handy with _only_ the Runtime on it to see
if that makes a difference.
 
Back
Top