Access97 "Write Conflict"

[ragtopcaddy via AccessMonster.com]

I've seen dozens of posts in this NG, but none of them has a definitive
answer, at least one that will solve my difficulties.

I have an Access97 development db. I am absolutely certain that I am the only
"user' of this db. I wrote an afterupdate event procedure for a checkbox that
evaluates the checkbox and changes some text in textboxes on the form. To be
more precise, because I couldn't get the textboxes to update (2448: You can't
assign a value to this object.), I have resorted to updating the underlying
table for the query that the form is based on. This works fine for the open
event of the form.

But for the checkbox, when I check it, the code runs perfectly (updating the
underlying table), but when it finishes, I get the "Write Conflict" dialog
and no matter which button I select, the textboxes display the correct result
of the function, but the checkbox is no longer checked. This is driving me
nuts. I've written thousands of after update events and never seen anything
like this.

Please advise.

 

[ragtopcaddy via AccessMonster.com]

Well, as often happens, while framing the question I found the solution on my
own.

Unlike some of the denizens of this NG, I will share my life lesson with you
;-) (Don't you hate it when someone solves one of these things and simply
says that they've solved it!?)

Simply enough, (and there were mentions of this in some threads, but not
clearly stated enough to penetrate my skull), all I had to do in the after
update event was insert as the 1st line, "Me.Dirty = False" to save the
record before proceeding. That seems to have foiled that dastardly "other
user" (a thousand curses upon him) from changing my record ;-).

Is it possible that the same unsaved record problem was causing the 2448
error?

I've seen dozens of posts in this NG, but none of them has a definitive
answer, at least one that will solve my difficulties.

I have an Access97 development db. I am absolutely certain that I am the only
"user' of this db. I wrote an afterupdate event procedure for a checkbox that
evaluates the checkbox and changes some text in textboxes on the form. To be
more precise, because I couldn't get the textboxes to update (2448: You can't
assign a value to this object.), I have resorted to updating the underlying
table for the query that the form is based on. This works fine for the open
event of the form.

But for the checkbox, when I check it, the code runs perfectly (updating the
underlying table), but when it finishes, I get the "Write Conflict" dialog
and no matter which button I select, the textboxes display the correct result
of the function, but the checkbox is no longer checked. This is driving me
nuts. I've written thousands of after update events and never seen anything
like this.

Please advise.

--
Bill Reed

"If you can't laugh at yourself, laugh at somebody else"

Message posted via AccessMonster.com

 

[Tony Toews [MVP]]

Well, as often happens, while framing the question I found the solution on my
own.
Fabulous.

Unlike some of the denizens of this NG, I will share my life lesson with you
;-) (Don't you hate it when someone solves one of these things and simply
says that they've solved it!?)
Agreed.

Simply enough, (and there were mentions of this in some threads, but not
clearly stated enough to penetrate my skull), all I had to do in the after
update event was insert as the 1st line, "Me.Dirty = False" to save the
record before proceeding. That seems to have foiled that dastardly "other
user" (a thousand curses upon him) from changing my record ;-).

Is it possible that the same unsaved record problem was causing the 2448
error?

Yes. Why not test it?

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[ragtopcaddy via AccessMonster.com]

Thanks, as always, for your response.

Inserting "Me.Dirty = False" did not, in and of itself, solve the error 2448
problem. However, moving the procedure, including "Me.Dirty = False", from
the On Open event of the form to the On Load event did. Not only did the move
resolve the 2448 error (apparently, when the On Open event fires, the form is
still in design mode), but it also got rid of the ghostly presence of an
empty Access window whenever I closed the form, necessitating a Task Manager
session to get rid of it.

Yes. Why not test it?

Tony

--
Bill Reed

"If you can't laugh at yourself, laugh at somebody else"

Message posted via AccessMonster.com