BeforeUpdate problem

[Dick Minter]

I have a form bound to a client list that shows client status and the
assigned salesperson ([assignment] field). I have placed code in the
BeforeUpdate event of the [status] field that, when the client status is
changed from "active" to "inactive" prompts the user for confirmation, and
with an affirmative response calls a module procedure that updates records in
two other tables, as well as removing the salesperson [assignment] in the
underlying table for the bound form. The (2115) error occurs, I assume, when
the form's BeforeUpdate event attempts to fire. Since the module procedure
is used elsewhere, I would prefer not to modify it as a solution. Can you
suggest an alternative?

DM

 

[Dick Minter]

I have a form bound to a client list that shows client status and the
assigned salesperson ([assignment] field). I have placed code in the
BeforeUpdate event of the [status] field that, when the client status is
changed from "active" to "inactive" prompts the user for confirmation, and
with an affirmative response calls a module procedure that updates records in
two other tables, as well as removing the salesperson [assignment] in the
underlying table for the bound form. When I try to save the record I get a "write conflict" error. I had assumed the error was occuring in the form's BeforeUpdate event, but apparently not.

Since the module procedure is used elsewhere, i would prefer not to modify
it. Can you suggest another approach?

 

[Dick Minter]

I apologize for the fragmentary nature of these posts.

I have read the posts regarding write conflicts and the use of the dirty
property, and I recognize that setting the dirty property (forcing a write to
disk) cannot be done in the BeforeUpdate event. Unfortunately, the logic
used to determine the call to the module procedure causing the conflict must
reside there. My solution, which I'm not really please with, was to create a
module variable (status flag), a module procedure to set the variable, and a
module function to return it. Now, the code in the Beforeupdate event sets
the module variable, while the original procedure call has been moved to the
subject control's AfterUpdate event, which is preceded by a procedure call
returning the module variable (status flag).

I would apprecaite suggestions for an alternative approach.

DM

I have a form bound to a client list that shows client status and the
assigned salesperson ([assignment] field). I have placed code in the
BeforeUpdate event of the [status] field that, when the client status is
changed from "active" to "inactive" prompts the user for confirmation, and
with an affirmative response calls a module procedure that updates records in
two other tables, as well as removing the salesperson [assignment] in the
underlying table for the bound form. When I try to save the record I get a "write conflict" error. I had assumed the error was occuring in the form's BeforeUpdate event, but apparently not.

Since the module procedure is used elsewhere, i would prefer not to modify
it. Can you suggest another approach?

DM

 

[Tony Toews [MVP]]

I have read the posts regarding write conflicts and the use of the dirty
property, and I recognize that setting the dirty property (forcing a write to
disk) cannot be done in the BeforeUpdate event. Unfortunately, the logic
used to determine the call to the module procedure causing the conflict must
reside there. My solution, which I'm not really please with, was to create a
module variable (status flag), a module procedure to set the variable, and a
module function to return it. Now, the code in the Beforeupdate event sets
the module variable, while the original procedure call has been moved to the
subject control's AfterUpdate event, which is preceded by a procedure call
returning the module variable (status flag).

I would apprecaite suggestions for an alternative approach.

Why not do the confirmation in the BeforeUpdate event and the record
updating in the After Update event?

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/

 

[Dick Minter]

That's what I ended up doing, but I had to create addl module procedures to
pass the results of the test (in BeforeUpdate) to the procedure call in
AfterUpdate. Is is not possible to cause BeforeUpate to fire from within the
event procedure, placing the dependent procedure call after?

DM