To integrate Global DML Caching in your IBO application, there must be some work done at database level. You can do this either manually or by using IB LogManager.

IB LogManager will help you to integrate Global DML Caching into your database. That includes:

• Creating the operation log table
• Creating the after insert trigger on the operation log table, which fires the DML Caching notification event.
• Maintaining the logging triggers on tables, which should be tracked by the DML Caching mechanism

Of course, (1) and (2) can be done manually, but (3) can be a mess when doing it manually on a huge database with many tables.

IB LogManager can act as "Integrator" for Global DML Caching in your application, because (1) and (2) can be done in the Prepare-Wizard and (3) is simply registering an table operation for logging.

The following example uses the "employee.gdb" database, which comes with every InterBase and Firebird installation, but these steps are applicable to any database.

First, connect to the "employee.gdb" database and then prepare the database for logging.

Use the Prepare-Wizard to prepare the database for logging. Two things in the Prepare-Wizard are important, when IBO DML Caching should be integrated in your database:

• Step 1 - Create Logging Tables: The name of the operation log table (default: IBLM$OPERATIONLOG), because the table name is needed for the proper use of the TIB_SyncCursor component in your client application.
• Step 7 - Additional: Select the "Integrate IBO DML Caching Support" option to create the after insert trigger on the operation log table, which fires the synchronization event. Remember the event name, because this is also needed to configure the TIB_SyncCursor component in your application properly.

Click "Finish" to prepare and to integrate the IBO DML-Caching Support in your database.

Choose, which table operations (delete/insert/update) should be logged. If you would like to track all changes in the table CUSTOMER for each data manipulation, then register the complete table for logging. Remember, each time a change in the table CUSTOMER happens, a new record in the operation log table is added and the after insert trigger fires the synchronization event, which must be captured in the client application.

Yes, that's all at database level. Now we are ready to integrate the DML Caching in your IBO application.

The full source (Delphi 5) is available here.

Lets have a look on a simple demo application to see, how things must be configured.



As you can see, this application uses the common set of components (TIB_Connection, TIB_Transaction, TIB_Query, TIB_Datasource, TIB_Grid) to view the table CUSTOMER in the "employee.gdb" database. Additional the TIB_SyncCursor component (the last one) is used to integrate the DML Caching mechanism in your IBO application.

We have used IBLM 2.1 to setup DML Caching database objects inside the database. Now it's time to configure the TIB_SyncCursor component properly.



In the property editor of the TIB_SyncCursor component above, there are properties with fixed and user-defined values:

• Fixed (set these properties as shown above): ActionDeleteVal, ActionEditVal, ActionInsertVal, ColActionName, ColIDName, ColKeyFieldsName, ColKeyValuesNames.
• User-defined (set these properties with the names used in the Prepare-Wizard): ColUserName ('USER_NAME' resp. 'BENUTZER' when using English/German column names in the operation log table), EventName, TableName

The TIB_SyncCursor component is now configured properly.

Set the DMLCacheFlags property of each TIB_Dataset descendant (TIB_Query in our demo application), which should be synchronized by the DML Caching mechanism.



Set dcfReceiveEdit, dcfReceiveInsert and/or dcfReceiveDelete to True/False according to the trackable data manipulation operation.

The last task is to call the Prepare method of TIB_SyncCursor at run-time. This can be done in the AfterConnect event of TIB_Connection.

  procedure TfmMainForm.icoMainAfterConnect(Sender: TIB_Connection);
  begin
    iscMain.Prepare;
  end;

Start the IBO application at least twice and connect to the "employee.gdb" database using distinct InterBase or Firebird users (e.g. the first using USER_A and the second using USER_B). Change any data and after committing the changes, they should be reflected in the other application instance.

If you have any questions or suggestions, please send us an e-mail.