[RBASE-L] - DBGrid & Scrolling Region (was RBTI_DIRTY_FLAG)

Fri, 27 Mar 2009 21:54:16 -0700

By chance, I found that you _can_ sort a scrolling region without basing it on a view by using both a Scrolling region and a DBGrid: Build your scrolling region, locate DBEdits and variables if you want & get it all fluffed up - the SR is your data viewing/editing area.  Then create a DBGrid on the same table.  Locate the same columns in the grid that you have in the SR - same position, same width.  Make the height of the DBGrid just enough to show column headings and locate the DB Grid right above the SR.  Click a heading in the DBGrid and the scrolling region sorts.  A test table with 365,000 rows sorts instantaneously on PK & indexed columns.  Only drawback is you can't move the columns... well, you can in the grid but they don't move in the SR.
(RB 7.6.6.30315, but I suspect it's been capable of this for a while)
Doug
[2nd try - I had a BMP of a form showing the DBGrid & SR.  Listserve took everything out of the email as I thought it might.
I'll send it privately to anyone wants it]
 
Emmitt Dove wrote:

You can view the dbgrid as a single object – and certainly in the forms builder it is, but what I was getting at is that it is made up of rows and columns.  Each of those cells is a field on a table.  One dbedit = one field in the current row of a table.  Think of the dbgrid as a variable number of dbedits.

 

By the way, it just occurred to me that if you really need better control over what happens moving into or out of individual fields, you *could* build a scrolling region to look and act very much like a dbgrid.  The advantage would be all the on-entry, on-exit and on-click eeps available.  What you lose is the ability to move columns around and sort by clicking the title.  But even the sorting could be emulated, if the region is based upon a view.

 

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]

 

From: [email protected] [mailto:[email protected]] On Behalf Of Doug Hamilton
Sent: Friday, March 27, 2009 6:39 PM
To: RBASE-L Mailing List
Subject: [RBASE-L] - Re: RBTI_DIRTY_FLAG

 

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.

[email protected]

(203) 214-5683 m

(203) 643-8022 o

(203) 643-8086 f

[email protected]

 

From: [email protected] [mailto:[email protected]] 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.

[email protected]

(203) 214-5683 m

(203) 643-8022 o

(203) 643-8086 f

[email protected]

 

Reply via email to