Yes, you just add a record to a little log every time something changes, regardless of whether it is a delete, update or insert. My thought was pretty simple:

A trigger on your server:

CREATE TRIGGER MyTrigger FOR MyTable AFTER INSERT OR UPDATE OR DELETE AS
begin
if (UPDATING) then
begin
INSERT INTO MyTableChanges(ChangeID, ChangeType, ChangeDate, ID, MyField1, MyField2...)
VALUES (GEN_ID(MYTABLECHANGES_GEN, 1), 'U', CURRENT_DATE, NEW.ID, NEW.MyField1, NEW.MyField2...)
end
else if (INSERTING) then
begin
INSERT INTO MyTableChanges(ChangeID, ChangeType, ChangeDate, ID, MyField1, MyField2...)
VALUES (GEN_ID(MYTABLECHANGES_GEN, 1), 'I', CURRENT_DATE, NEW.ID, NEW.MyField1, NEW.MyField2...)
end
else if (DELETING) then
begin
INSERT INTO MyTableChanges(ChangeID, ChangeType, ChangeDate, ID, MyField1, MyField2...)
VALUES (GEN_ID(MYTABLECHANGES_GEN, 1), 'D', CURRENT_DATE, OLD.ID, OLD.MyField1, OLD.MyField2...)
end
end

Checking this table on your client:

SELECT *
FROM MyTableChanges
WHERE ID > MaxIDFromLastTimeTheClientWasUpdated

(Delphi pseudocode)
if cMyTableChanges.FieldByName('ChangeType').AsString = 'U' then
(<WhateverYouDoToUpdateMyTable)
else if cMyTableChanges.FieldByName('ChangeType').AsString = 'I' then
(<WhateverYouDoToInsertIntoMyTable)
else if cMyTableChanges.FieldByName('ChangeType').AsString = 'D' then
(<WhateverYouDoToDeleteFromMyTable)

HTH,
Set

-----Original Message-----
From: firebird-support@yahoogroups.com [mailto:firebird-support@yahoogroups.com] On Behalf Of emb_blaster
Sent: 1. juli 2011 22:49
To: firebird-support@yahoogroups.com
Subject: SV: [firebird-support] Re: is "UPDATE or INSERT" the best way to replicate a read-only local table ever?

> >In true, we need run the mass delete before or we will could leave some deleted rows in the table, leading to a not equal state in the local table...
> >
> >So seems to me that, "Insert or Update" will not be a good idea in this specific case...
> >
> >Any other ideas?
>
> Are there many changes to this table? If not, you could have - well, more or less a copy of it that you populate through a trigger when changes happens to the original table. This copy would have to contain a few additional fields - a new primary key since a record might be updated several times before deletion and a field saying whether the trigger that fired was due to adding a record, modifying it or deleting. Then you could just modify your client database with what was inserted into this copy table since last time the client updated its table.
>
> Of course, if the server deletes 20000 rows each day and adds 20000 new rows and you only update the client once a month, then this is a stupid idea.
>
> HTH,
> Set
>

Hi Set,
I am not sure that I understood it. But definitively the server do NOT deletes, adds or update 20000 rows a day.
Explain me more about the deletion part. When I delete the row in the server and the client is not in the network that time. It will have to add to another table what row was deleted? Is that?
Thanks for your idea and time. We would not like to do a complete journaling for this, but maybe we could do an hybrid process. :)