Subject | TechInfo: Using IBLM 2.0 as Integrator for IBO DML Caching |
---|---|
Author | Thomas Steinmaurer |
Post date | 2002-03-17T18:28:26Z |
Hi IBO-list,
IBO offers a superb mechanism called IBO DML Caching to
synchronize data changes immediately in your multi-user
(client) environment. Your application can be configured
easily to reflects changes committed by another. The DML
Caching mechanism is described in a help-file on Jason's
web site http://www.ibobjects.com/TechInfo.html.
In short this mechanism is based on the assumption that
committed changes are logged in a table and each time
a new log record is added, an event is fired from an after
insert trigger on the log table. This event is catched
within your client application from the main DML Caching
component TIB_SyncCursor and datasets which are registered
for DML Caching are synchronized nearly in real-time.
So, how can IBLM 2.0 help me to use the IBO DML Caching
mechanism? Committed data changes are logged within the
database by using triggers on each tracked table. As
you know, without IBLM, this would be very time consuming
and a faulty process, especially on huge database with
many tables.
IBLM 2.0 can act as "Integrator" for DML Caching within
your application. To log which record has changed can
be already done easily on operation log level. Currently
only one thing in the actual official release of IBLM 2.0
is missing to make this integration complete. The after
insert trigger on the operation log table, which fires
the change event isn't created in the actual official
release.
This is included in the newest non-official IBLM 2.0 Beta
Version (2.0.5.1 BETA). The logging preparation process
was adapted to allow the creation of the after insert
trigger on the operation log table, which fires the event
for the synchronization.
If you are interested in trying this BETA-Release to see,
how easy the IBO DML Caching Mechanism can be integrated
in your IBO application, then please send me an E-Mail.
Thanks for your time!
Regards,
Thomas Steinmaurer
http://www.iblogmanager.com
IBO offers a superb mechanism called IBO DML Caching to
synchronize data changes immediately in your multi-user
(client) environment. Your application can be configured
easily to reflects changes committed by another. The DML
Caching mechanism is described in a help-file on Jason's
web site http://www.ibobjects.com/TechInfo.html.
In short this mechanism is based on the assumption that
committed changes are logged in a table and each time
a new log record is added, an event is fired from an after
insert trigger on the log table. This event is catched
within your client application from the main DML Caching
component TIB_SyncCursor and datasets which are registered
for DML Caching are synchronized nearly in real-time.
So, how can IBLM 2.0 help me to use the IBO DML Caching
mechanism? Committed data changes are logged within the
database by using triggers on each tracked table. As
you know, without IBLM, this would be very time consuming
and a faulty process, especially on huge database with
many tables.
IBLM 2.0 can act as "Integrator" for DML Caching within
your application. To log which record has changed can
be already done easily on operation log level. Currently
only one thing in the actual official release of IBLM 2.0
is missing to make this integration complete. The after
insert trigger on the operation log table, which fires
the change event isn't created in the actual official
release.
This is included in the newest non-official IBLM 2.0 Beta
Version (2.0.5.1 BETA). The logging preparation process
was adapted to allow the creation of the after insert
trigger on the operation log table, which fires the event
for the synchronization.
If you are interested in trying this BETA-Release to see,
how easy the IBO DML Caching Mechanism can be integrated
in your IBO application, then please send me an E-Mail.
Thanks for your time!
Regards,
Thomas Steinmaurer
http://www.iblogmanager.com