Why not just have a primary key with 2 columns, one of which is a serial and the other is a "siteid" or "installid"
thatis different for each server?<br /><br /> TomDB wrote: <blockquote cite="mid1807736772.20061114221053@uk2.net"
type="cite"><prewrap="">would there be any default available field (like the OID of the
records) that would be unique in the two versions of the datbase?
there isn't "by accident" something like a unique UID like an MD5 or
something... ?
cause if there is no replication available, I'd consider this
(together with PHP)
a) replacing the serial fields by generated UID's (md5 of ID + a
string that depends on the install)
or
b) start the autoincrement field at a high number in the second
install (since I can estimate that there will never by > 10 000
records)
+ store all queries that were performed & run them in the
network-master afterwards.
</pre><blockquote type="cite"><blockquote type="cite"><pre wrap="">I'd like to create a setup where there are exactly
2masters which
need to be synchronized against each other. The two masters should
have read+write access, but don't have a permanent connection to each
other. One will be on a LAN-server, the other instance will be
installed on a Windows-client-laptop which can be taken along the
road. When coming back to the office, we need to sync the changed
data.
is there any tool that will allow me to do so ? </pre></blockquote></blockquote><pre wrap=""> </pre><blockquote
type="cite"><prewrap="">If you got *really* clever you could maybe pull it off with Slony, but
in general, no, this isn't possible. </pre></blockquote><pre wrap="">
</pre></blockquote>