After Update event problem

  • Thread starter Thread starter mscertified
  • Start date Start date
M

mscertified

I have a continuous form that can insert new records to the bound table.
There are 2 hidden fields for columns in the table that the user cannot
directly set. One of these is a numeric (long) column that has to be set to
the highest current value in the column plus 1 (don't ask why). So in the
AfterUpdate event, I do a DMAX and set the column to the value + 1. However,
my column always contains ZERO (the default value). Why? Is there a pronblem
in using the AfterUpdate event for this? Is it a problem that my AfterUpdate
event contains a DMAX against the table the form is bound to?

Thanks.
 
Your table and/or form have a default value of zero for that field/control.
Delete it.
 
I have a continuous form that can insert new records to the bound table.
There are 2 hidden fields for columns in the table that the user cannot
directly set. One of these is a numeric (long) column that has to be set to
the highest current value in the column plus 1 (don't ask why). So in the
AfterUpdate event, I do a DMAX and set the column to the value + 1. However,
my column always contains ZERO (the default value). Why? Is there a pronblem
in using the AfterUpdate event for this? Is it a problem that my AfterUpdate
event contains a DMAX against the table the form is bound to?

Thanks.
Click to expand...

The Form's AfterUpdate event occurs (duh!) *after* the record has been updated
to disk, and therefore cannot change the values in the table (or may cause an
infinite loop instead). Use BeforeUpdate instead, *if* you need to do this
highly inefficient, non-normalized, unreasonable process.

Does this value need to be updated in *the current record*, or in every record
in the table!? Why can't you just use DMax() in whatever process needs the
value, rather than recalculating and storing it?
 
I'm not the OP, but I use a similar technique with a SortOrder column that I
maintain for a lot of my lists.

I'm not sure why you think it is highly inefficient, non-normalized, and
unreasonable. Have you never had a client that wanted a auto-number like
field (InvoiceNum would be an example) that incremented for each new record,
but was not an auto number?

--
HTH
Dale

Don''t forget to rate the post if it was helpful!

email address is invalid
Please reply to newsgroup only.
 
Back
Top