In article [EMAIL PROTECTED],
Alex Adriaanse [EMAIL PROTECTED] writes:
Thanks for the input everyone. I think Harald's approach will work
well...
I'm not so sure anymore :-(
Consider something like that:
UPDATE tbl SET col1 = 1 WHERE col2 = 1;
UPDATE tbl SET col1 = 2 WHERE col2 = 1;
with
Harald Fuchs wrote:
In article [EMAIL PROTECTED],
Alex Adriaanse [EMAIL PROTECTED] writes:
Thanks for the input everyone. I think Harald's approach will work
well...
I'm not so sure anymore :-(
Consider something like that:
UPDATE tbl SET col1 = 1 WHERE col2 = 1;
UPDATE tbl SET col1 = 2
Thanks for the input everyone. I think Harald's approach will work
well, so I'm planning on doing what he suggested, with a few
modifications. I think I can still use a sequence-backed INTEGER rather
than TIMESTAMP, and have the trigger that sets the revision to NULL also
NOTIFY the daemon
I think that would greatly decrease the chances of a race condition
occurring, but I don't think it'd solve it. What if 150 other revisions
occur between a row update and its corresponding commit?
Alex
Vincent Hikida wrote:
To fetch all updates since the last synchronization, the client would
In article [EMAIL PROTECTED],
Alex Adriaanse [EMAIL PROTECTED] writes:
I think that would greatly decrease the chances of a race condition
occurring, but I don't think it'd solve it. What if 150 other
revisions occur between a row update and its corresponding commit?
How about the following:
I'm working on an application where we have a central database server
and a bunch of clients that are disconnected most of the time, need to
maintain a local copy of the central database. The client databases are
based on One$DB since it has to be lightweight. The client does not
access the
To fetch all updates since the last synchronization, the client would
calculated a value for $lastrevision by running this query on its local
database:
SELECT max(revision) AS lastrevision FROM codes;
It would then fetch all updated rows by running this query against the
server:
SELECT * FROM
