Not a problem - you will need to use a scripted macro for this (
unless someone can show me how to do it otherwise ). You would call
this macro in the After Record Action event. The macro is not
particularly difficult to envision, I am just curious how you will
link the two ( or more records ). Looking at the data I see that the
field "inspection" is not unique. Is there some combination of fields
that will yeild a unique ( natural ) key?
Just to explain you 'the name of the game': during construction we do
not accept all the things: for such cases we have conclusions
'REJECTED' and 'OWC'.
In both cases same item has to be inspected at least one more time. It
would be handy to have information which items have to be re-inspected
on one place (separate table?). Query of table tInspection with R or
OWC as criteria can not help: doesn't mean that same Item is not
accepted on some later date. Of course, situation is more complicated,
all records in such (new) table has to be unique. Moreover if one
re-inspect an item, there is no guarantee that this item will be
accepted - two-three-inspections are not unusual, depending on a
Builder. So basically, on insert of new record macro has to check if
such record already exist in a 'new' table: if exist and if
conclusion is R or OWC, macro suppose to update a date in those new
table; if conclusion is something else (not R or OWC) macro suppose to
delete that record from the new table. If record doesn't exist and
conclusion is R or OWC, macro suppose to add record to the table -
Date and Inspection are Ok. However, all records has to be 'intact' in
a table tInspection.
OK, I have the business process - I think.
Can I assume that the following data ( tInspection.Inspection,
tInspection.Type ) will form the key to be used when determining if this
inspection is or is not in the 'new' table?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
