Ian,

> Your excellent sales force has encouraged me to have a quick refresher
> on IBLogManager. You cant argue with a product with users as
> advocates!

I do my best to keep my customers happy. ;-)

> We've implemented a fairly rudimentary process that queries
> modified/inserted/deleted records and pumps them from the live
> database into a replication/master database and creates a text log of
> changed records (we dont know what for, but are sure it will be useful
> one day!)

If you are talking about pumping logged operations/records into
an external database, then IBLMPump in the IBLM product family
is the way to go. It is a command line utility which can be used
in three different ways.

- Manually, every time you start IBLMPump.exe
- Scheduled with e.g. the Task Scheduler of Windows
- Background pumping while running, either using Firebird events
or via an polling interval

That works very well to keep your production database tiny.

> >From browsing you site i think this is essentially what IBLogManager
> does, only with a lot more sophistication. Have i got the right
> impression?

People usually understand how they could cook up such an logging/auditing
mechanism in their database, but I'm not only offering one tool, but
a suite of tools to make your auditing life a lot easier.

For example, if you want to define a full logging schema, that means
all tables and their columns should be tracked, then, well, it is
simply one mouse-click, namely using the "Register all Tables"
facility. I wouldn't like to build the logging trigger manually,
really. ;-)

> Does it have any mechanisms to force replication from the
> live database or does it reply on the client doing it?

I do have an Addon called IBLMRedo, but the idea behind is
a bit different to a "real" replication, because it was
designed to act as a roll-forward log, that assumes that
a full logging schema is defined in your database. That's
different to the approach a replicator might use, because
usually it looks up a changed record by using the primary
key, instead of logging all column changes. Another thing
is that IBLMRedo is a GUI driven tool, that means it can't
be scheduled, because there is some interaction with the
user necessary who has to define the starting point inside
the change log the roll-forward log shall start.

And, and, and ... ;-)

The product family really has grown over the years and
is more then creating triggers. As said, the purpose is
to make any auditing life much more easier. ;-)


Best Regards,
Thomas Steinmaurer

Logging/Auditing Suite for InterBase and Firebird
http://www.iblogmanager.com
Logging/Auditing Suite for Advantage Database Server
http://www.adslogmanager.com