Is there an established procedure to be used in OI to

do the following:

User enters data into a form bound to a table.

Determine what has changed within an Edit_Table

structure.

Back out what was there originally

Add what was changed.

In AREV, we would do the following:

Use OREC to determine whether this was a New Record

or an existing one.  Loop through the OREC<field#,value#

structure and remove the information from related tables

Use @RECORD to add the new.

This procedure would automatically remove deleted AMV's

from related tables and replace with new data.

It was kind of a brute force approach, but since the AMV

chain contained information that was not on the screen, it

was useful. Does OI have a record structure corresponding

to OREC? Is @RECORD updated properly if the DEFPROP property

is updated during entry time?

Thanks …

Don Miller

C3 Inc.

Don,

Is there an established procedure to be used in OI to do the following: User enters data into a form bound to a table. Determine what has changed within an Edit_Table structure. Back out what was there originally Add what was changed.

In the CLEAR and READ events, make a copy of the data in the edit table:

* this is the READ event

call Forward_Event()

Ctrl=@window: ".ET_DATA" ;* whatever your edit table ID is

List=Get_Property(Ctrl, "DEFPROP")

call Set_Property(Ctrl, "@ORIG", List)

return 0

* this is the CLEAR event

call Set_Property(Ctrl, "@ORIG", "")

return 1

* this is the WRITE event

List=Get_Property(Ctrl, "DEFPROP")

Orig=Get_Property(Ctrl, "@ORIG")

* process as in Arev … either before the WRITE (by

* doing a RETURN 1) or after the WRITE (by calling

* Forward_Event then checking Get_EventStatus)

…

The only other case is if you are working with DataSets against ODBC, SQL Server, or Oracle, in which case the DataSet tracks the inserts, updates, and deletes for you.

Cameron Purdy

Revelation Software

Cam..

Does your response imply that the DBTABLE must contain all

data elements that need to be checked? I understand that

I can programatically make some elements not visible to

the user. In my AREV app, I could simply do the following:

OREC WAS THE ORIGINAL

K1=COUNT(OREC,@VM)+(stuff ne '')

FOR I=1 TO K1

 REMOVE THE EFFECT OF ALL FIELDS, including stuff

 not on the screen

NEXT I

K1=COUNT(CONTROL_FIELD,@VM)+(CONTROL_FIELD # "")

FOR LMT=1 TO K1

.. assume that elements 1-15 are on this form

.. elements 16-59 are in the domain of the visible

.. data, but are maintained off screen by other processes.

   @RECORD=something

.. ADD BACK THE EFFECT OF EVERYTHING IN @RECORD

NEXT LMT

In effect, it didn't matter whether an AMV was deleted

or changed. The logic did both. If the elements moved

around due to insertions, etc., it didn't matter.

It looks as though the contents of the DB_TABLE are the

only control. Does @RECORD get updated prior to the write

in such a way that this logic would work?

Thanks

Don M.

Don,

It is not quite the same. @record is not what gets written out on the WRITE event, rather the original record (read from the table) has the contents of bound controls applied and then is written.

There are a variety of ways to accomplish what you want, including using a hidden edit table bound to those other columns.

Cameron Purdy

Revelation Software

View this thread on the Works forum...