Before Update

[Nelson]

I oncatenate "serial numbers" that are a unique combination of fileds in the
record. I want to be sure these are calculated prior to moving off of a
recordset. My goal was to calculate these at the "Before Update" event, and
then move on to the next recordset. However I am not able to move off of the
current recordset when I refresh these serial numbers I am trapped inthe
"Before Update" event.

 

[Brian Bastl]

Hi Nelson,

The general rule of thumb is that any value which is the result of a
calculation should not be stored. There certainly are exceptions. Why do you
need to store this, when it is easily derived?

Brian

 

[John Vinson]

I oncatenate "serial numbers" that are a unique combination of fileds in the
record.

Ummmm...

Very bad idea.

It's storing derived *and* redundant data. I would very strongly
suggest NOT storing this information in any table; it not only wastes
space, but it gives you a major headache keeping the derived data in
synch with the base data.

I want to be sure these are calculated prior to moving off of a
recordset. My goal was to calculate these at the "Before Update" event, and
then move on to the next recordset. However I am not able to move off of the
current recordset when I refresh these serial numbers I am trapped inthe
"Before Update" event.

About the only way I can think of is to update this composite field in
the AfterUpdate event of each of its components. Of course this won't
protect you if someone bypasses the form, or runs an update query; you
can still get WRONG serial numbers. It's best just to calculate this
concatenation "on the fly" in a calculated field in the Query upon
which your form or report is based.

John W. Vinson[MVP]