Cached Updates

Asta supports data-aware controls and can generate SQL to automatically transmit update, insert and delete statements to the ASTA server. To enable automatic SQL generation you must set three public properties using the EditMode property editor. Make sure you set some SQL and make your table active first so that there are actual field names available for ASTA to work with.

The EditMode property editor allows you to set up a TAstaClientDataSet so that ASTA can automatically generate the SQL for you. The EditMode property editor requires that the TAstaClientDataSet have field information already defined by writing an SQL select statement and setting active to true. After using the property editor, it will display text regarding the EditMode status as Read Only, Cached or After Post. For fields that you do not want included in any insert, update or delete statement set the ReadOnly property of that field to true. For AutoIncrement fields, just pull down the AutoIncrement property with that field name and it will not be used on insert statements. of ASTA can Refetch the auto increment value of a field, and other fields automatically after an insert statement, as well as after update statements if the AstaServer you are running supports this.

1.      UpdateTablename:      This is the name of the table that is to be updated and works just like the TableName property with a pull down list of tables available on the server.

2.      PrimeFields:      Asta needs to know what fields are used to determine uniqueness.

3.      Update Method      If the database supports transactions (ASTA adds a begin transaction/commit pair to SQL statements) you may set this property to umCached. Asta will track any table inserts, edits or deletes and you must manually call the ApplyUpdates method. This will send the SQL to the server. If you set this property to umUAfterPost then on each row change the SQL will be sent to the server. The default is umManual.

function ApplyUpdates(TransactionMethod: TUpdateSQLMethod): Boolean;

TUpdateSQLMethod = (usmNoTransactions, usmUseSQL,

  usmServerTransaction,usmCommitAnySuccess);

ApplyUpdates can be handled in one of three ways:

1.      No Transactions:            This is what is called if the EditMode is set to umAfterPost and updates one row at a time.

2.      UsmUseSQL:            This applies cached updates and uses the TAstaClientSocket.SQLTransactionStart and SQLTransactionEnd to post the SQL to the server. The default for SQLTransactionStart is BEGIN TRANSACTION and the default for SQLTransactionEnd is COMMIT. ODBC for instance, by default is set to auto commit mode, and by using these paired statements surrounding multiple lines of SQL, transactions can be invoked.

3.      UsmServerTransaction:      This posts the SQL to the server and calls the explicit transaction support that ASTA servers have. The AstaBDEServer will use the TDataBase.StartTransaction call. The ASTAODBCExpress server will use the Thdbc.StartTransact. See the TAstaTransaction.doc for a discussion on transactions.

4.      UsmCommitAnySuccess      This posts the SQL to the server just like usmServerTransaction however a Commit will be called on the server if any SQL sent to the server is successful.

To set the Editmode at run time use the method

     procedure SetEditMode(const Primes: array of string;

       TheUpdateTable: string; TheUpdateMethod: TAstaUpdateMethod);

Here is an example from the DataAwareRunTime tutorial showing how a TAstaClientDataSet can be changed from editing a Customer Table to editing an Employee Table.

procedure TForm1.BitBtn1Click(Sender: TObject);

begin

  with AstaClientDataSet1 do begin

    Close;

    SQL.Clear;

    SQL.Add('Select * from Employee');

    Open;

    SetForUpdate(['EmpNO'], 'Employee', umAfterPost);

  end;

end;