In my current project we're using InfoPower's data-aware controls.
Because the data-aware grids post AUTOMATICALLY, we ended up using
'temporary' tables.  Changes are only saved to the 'permanent' tables
when the user selects a Done button.

This appears to be an inherent drawback to using data-aware components.
My next project will be using Sybase and unless I use 'temp' tables
again, I will have set checkpoints and execute rollbacks if changes are
cancelled.  This seems clunky.

Any recommendations for components to use for transaction processing?

TimR...@ix.netcom.com

P.S.  Please respond via email, or email AND news.

If you're using Delphi 2 you can use cached updates and explicit SL
Transaction management statements - it works really well (i use
interbase an oracle 7.2)

Christian
On Thu, 21 Nov 1996 11:24:19 -0600, Tim Rand <TimR...@ix.netcom.com>
wrote:

Tim Rand <TimR...@ix.netcom.com> wrote in article
<32949043....@ix.netcom.com>...

The alternative is to used cached updates. This achieves the same
effect, just a little cleaner.

Ryan VanIderstine

The right model would allow a client side application to edit an entire
set of rows.  No updates would be posted for any of the rows until your
client application explicitly posted changes for the set of rows.

Cached updates and transaction control can fake the correct behavior to
some extent.  However, you may run into several problems:  
   - events like Before & after post fire at the wrong time,
   - you may have to post master records before detail rows are posted,
      to define the primary key for the master record (and the
      the foreign keys in the detzil records.)
   - transactions may have to be started when the user first edits a
single record
      and concluded when he posts the entire set of records.
      If the interface to the database doesn't support a number
      of independent transactions, this may limit the user to a single
form.
   - optimistic record locking will require record checksums or
     version numbers that are used by the client-based app.
     the server based DB software may not keep track of changes
     to the set of detail records since they were retrieved.

The odd thing is that these considerations occur to programmers coding
database apps but they don't seem to occur to those who develop database
software.

Bill Hunt

We are thinking about the following and would like any comments/input
(especially negative, that is reasons not to do it):

1. Use NON-data-aware controls when users edit and insert records.

2. Prior to and following this "virtual" editing/inserting, check table's
timestamp. If the same, assign the changed values to the table; if
different, allow user to view changes made by the other user.

Clay Shannon

 __________________________________________________
B. Clay Kollenborn-Shannon
InfoHighway 101, P.O. Box 1116, San Andreas,CA 95249
Baseball software
ClaySie...@aol.com  

the scenario is as follows :
when to the user needs to change/add data :
- start a transaction
- let the user do all his changes
- issue a commit on a OK, or a rollback on a cancel
- if there are conflicts (another user made changes in the same records,
  you get an exception from the database/BDE.  Trap this exception and take the appropriate actions
  (rollback, start again, refresh data ...)

The advantage is that you can always use data-aware controls, and never have to do
the 'time-stamp' checking yourself.

Of course, not all databases support transactions is the same way.  All database servers do
support transactions, and some desktop databases do well.

We're using this approach on an Access database.

Jan Kempenaers
--
WTCM - CRIF
Department Mechanical Engineering
Celestijnenlaan 300-C
B-3001 Heverlee (Belgium)
Tel : +32-(0)16-322591  Direct line : ...2764
Fax : +32-(0)16-322984
BBS : +32-(0)16-225894
Homepage : http://www.wtcm.kuleuven.ac.be/

1. Delphi doesn't provide optimistic locking for some formats (Paradox
and DBase.)

2. The transaction has to be started when the record is displayed.  If
the app allows the user to display more than one form, you may have
several transactions in progress - one for each edit form.

3. You don't want other users to see any results from the user's edits
until he clicks OK.  That depends on characteristics of the server DB
engine, the ODBC driver, and undocumented behavior of the BDE.

There are 3 other alternatives to the timestamp:
        a version number which is incremented each time a record is
changed.
        a checksum of the contents of some or all the fields in a
record.
        a copy of the record as it was read.

Bill Hunt