|Subject||Re: SURVIVING SERVER DOWNTIME|
> I can "visualise" using replication but triggers as a solution towardsI may have been unclear at this point. Triggers don't do anything in
> this problem is a bit grey for me. an example of such a trigger perhaps
> would help shed some light?
terms of replication except to allow you to track what has been
changed. It should not be too hard to download anything new (once you
know what has been changed since the last synchronisation).
As a simple example:
Assume you had the following table.
You could make a before insert or update trigger to set
New.UpdateNo = gen_id(gen_ProductUpdateNo, 1);
Anytime your application or some interface system modifes the price,
it gets a new update number.
Each client knows the highest update number, so it just issues a query
select ID, Descr, Price, UpdateNo
where UpdateNo > :MyGreatestUpdateNo
(You must have an index on UpdateNo for performance)
Your client must merge this into the local database, again reasonably
trivial. You could make use of events to notify your clients that they
need to synchronise, but I personally have steered clear of them due
to problems that you can have with firewalls and the fact that a 15
minute interval between synchronisations is acceptable to our software.