Thanks Emmitt. Do I even need to update a column?
Couldn't I define a variable vDirtyTable INTEGER = 1 in an OnBeforeStart
EEP and the trigger would just SET VAR vDirtyTable = 1.
'Course, by flagging a column I know which rows were updated; that would
speed up the updating process cause I'd only have to recalc inventory on
the flagged rows, not all of 'em as I would if I used a variable.
Great idea - thanks.
Doug
Emmitt Dove wrote:
Doug,
Actually, in the after update trigger you don't even need to compare the
values of SYS_OLD and SYS_NEW; the update occurred because something
changed. Ergo, set your flag column to 1.
Emmitt Dove
Manager, Converting Applications Development
Evergreen Packaging, Inc.
[email protected]
(203) 214-5683 m
(203) 643-8022 o
(203) 643-8086 f
[email protected]
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Doug
Hamilton
Sent: Thursday, March 12, 2009 5:09 PM
To: RBASE-L Mailing List
Subject: [RBASE-L] - How to detect a dirty table?
Hi List - I have a question about detecting changes to data in a temp table.
I load selected transactions (e.g.a specific workorder) into a temp
table for editing and then write them all back to the original table.
The temp table is in a scrolling region on a form with the columns
located as DBEdits in the region.
When I edit a column, I see that the RBTI_DIRTY_FLAG gets set to 1.
I test for the 1 on an exit button and give the user the option whether
to update the original table or not.
However, if user goes off the row in the region, the changed data is
written to the temp table and RBTI_DIRTY_FLAG is set to 0.
My test then fails and user loses the option and may apply unwanted
updates (typos, etc) to the original table.
So...
Is there an easy way to test for a "dirty table"?
Do I need to write code for each located column, comparing before &
after values & setting a "vDirtyFlag"? (gaak)
I tried:
SET VAR vTableDirty = (IFEQ(RBTI_DIRTY_FLAG,1,1,.vTableDirty))
in both an OnRowExit EEP for the table and an OnExitEEP for the DBEdit
but neither one trapped the RBTI_DIRTY_FLAG value of 1. Apparently the
row gets written and RBTI_DIRTY_FLAG set back to zero before the EEPs fire.
I'm sure this has come up before and apologize for the redundancy.
TIA for your help or pointing me to an RRBYW example, FTE article, etc.
Doug
