Why using IB LogManager?

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:

  1. Creating the operation log table
  2. Creating the after insert trigger on the operation log table, which fires the DML Caching notification event.
  3. 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.

Example of use

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.

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:

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

Logging schema definition

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.

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:

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;

Run your IBO application

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.