[RBASE-L] - Re: RBTI_DIRTY_FLAG

[Doug Hamilton]

Possible.  But I think my "best practices" aren't the best.
I'm editing permanent-table data (inventory xacts) in a db grid.  I think
it's better to load the xacts for the particular item into a temp table &
use the SYS_ROWVER approach to determine which rows were changed and then
update those rows in the permanent table.  Each row has a unique ID.

You're right - We
don’t need no steenkin’ dirty flag!  (just a RowVer column)

BTW,  GOTH.com, what did you mean by:
I
see that my error was viewing the dbgrid as one db object.  It is really
a collection of many.


  DBGrid
has but one Component ID ( I think), although one can determine which cell
one is in by 
GETPROPERTY CIDDBGrid CURRENTCOLUMNNAME 'vCurrColumn'
and form _expression_ vRowID = RowID.
Is that what you meant by many db objects?

ohmmmmmmmmmm....

Doug

Emmitt Dove wrote:
   
  
 
  
 
    
  
    
  Doug,
  
   
  
  Another
thought:  how about using a trigger on your table to set a global variable
for you?
  
   
  
    
  Emmitt
Dove
  
  Manager,
Converting Applications Development
  
  Evergreen
Packaging, Inc.
  
  emmitt.d...@everpack.com
  
  (203)
214-5683 m
  
  (203)
643-8022 o
  
  (203)
643-8086 f
  
  emmitt.w.d...@comcast.net
  
  
   
  
    
   
 
  From: rbase-l@rbase.com 
[mailto:rbase-l@rbase.com] On Behalf Of Emmitt Dove
 Sent: Friday, March 27, 2009 6:08 PM
 To: RBASE-L Mailing List
 Subject: [RBASE-L] - Re: RBTI_DIRTY_FLAG
  
  
  
   
  
  >Enlightenment?
 >Doug 
  
   
  
  Available
at GuruOnTheHill.com.  |-)
  
   
  
  The
problem is how to capture the value at the proper time.  There’s no on-entry-into-field
eep or on-exit-from-field eep in the grid.  As you note, by the time you
leave the row the row is saved and the dirty flag should be 0.
  
  For
my purposes, I needed to know if any of the rows in the temp table represented
by the dbgrid had been changed.  I accomplished this by adding a column to
the temp table named “myrowver” type integer, computed to be (IFNULL(myrowver,1,(myrowver
+ 1))).  First I populate the temp table (which involves an INSERT and a
few UPDATEs) then ALTER TABLE to add the myrowver column.  As I go into the
form each myrowver value is 1.  When it is time to figure out if an update
to the permanent table is in order, I look to see if any rows have myrover
> 1.
  
   
  
  We
don’t need no steenkin’ dirty flag!
  
   
  
    
  Emmitt
Dove
  
  Manager,
Converting Applications Development
  
  Evergreen
Packaging, Inc.
  
  emmitt.d...@everpack.com
  
  (203)
214-5683 m
  
  (203)
643-8022 o
  
  (203)
643-8086 f
  
  emmitt.w.d...@comcast.net
  
  
   
  
    
   
 
  From: rbase-l@rbase.com 
[mailto:rbase-l@rbase.com] On Behalf Of Doug Hamilton
 Sent: Friday, March 27, 2009 5:39 PM
 To: RBASE-L Mailing List
 Subject: [RBASE-L] - Re: RBTI_DIRTY_FLAG
  
  
  
   
  
  I was just dealing with
this today.  It seems Larry's summary is correct.  Plus, it appears that RBTI__DIRTY_FLAG
does change to 1 when tabbing out of a field and staying on the same row.
 It stays zero until you leave the field.
 
 To trap the RBTI_DIRTY_FLAG for processing after leaving a DB Grid, I tried
On Row Exit and After Leaving Section table EEPs with 
 
 SET VAR vRowDirtyFlag = (IFEQ(RBTI_DIRTY_FLAG,1,1,.vRowDirtyFlag))
 
 Unfrtunately, neither EEP fires if I change data and then click a Push Button 
elsewhere on the form. 
 But putting the code in an After Saving Row EEP seems to trap the 1, although
I would have thought that by then it's too late - the row has already been
saved and RBTI_DIRTY_FLAG is reset to zero.
 
 Enlightenment?
 Doug 
 
 Emmitt Dove wrote:
  
  I
see that my error was viewing the dbgrid as one db object.  It is really
a collection of many.
  
   
  
  But,
I accomplished my goal by emulating the sys_rowver technique (without setting
autorowver on.)
  
   
  
    
  Emmitt
Dove
  
  Manager,
Converting Applications Development
  
  Evergreen
Packaging, Inc.
  
  emmitt.d...@everpack.com
  
  (203)
214-5683 m
  
  (203)
643-8022 o
  
  (203)
643-8086 f
  
  emmitt.w.d...@comcast.net
  
  
   
  
    
   
 
  From: rbase-l@rbase.com [mailto:rbase-l@rbase.com] On Behalf
Of Lawrence Lustig
 Sent: Wednesday, March 25, 2009 11:02 AM
 To: RBASE-L Mailing List
 Subject: [RBASE-L] - Re: RBTI_DIRTY_FLAG
  
  
  
   
  
    
    
  << 
  
  
    
  Should I
be expecting .RBTI_DIRTY_FLAG to return 1 if a value was changed in a dbgrid?
  
  
    
    
    
  >> 
  
   
  
  Depends whether you scrolled out of the row or not.
  
   
  
  If you have already scrolled out of the row, that
row has been saved, and the RBTI_DIRTY_FLAG should reset to 0.
  
   
  
  If you have NOT scrolled out of the row, but have
tabbed out of the field you changed, I would expect RBTI_DIRTY_FLAG to contain
1, but I haven't tested it.
  
   
  
  If you have neither scrolled out of the row NOR tabbed
out of the field, then I would imagine the flag would still be 0, since the
change in the field has probably not yet been written back into the form's
row buffer.
  
  --
  
  Larry