Re: Database syncronization

Here are some options:

1. Pre-assign batches of values to each computer so there can be no conflict
2. Set up some rules for handling conflicts when they arise
3. Check with a master database on every change

Option 3 will of course be slow if you're doing many changes to your data. You can implement option 1 by creating a replicated table of "value blocks."

Yuval

On Sat, 27 Apr 2002 02:11:04 +0100, "Bytter" <bytter_at_netc.pt> wrote:

>Hi,
>
>I've got a problem that I can't seem to resolve in a simple way. My problem
>is: one database in 'n' computers (to make it simple, lets start with 2).
>Both have the same tables, which have the same fields. But both run on two
>different computers. On both, they can add new things, delete old ones, and
>modify existing entries. But, at one time, they must syncronize. They data
>must be shared: those entries added, must be added, those modified must be
>modified, and so on... (simple uh :)) Let's start using a simple table, with
>an unsigned long int primary key:
>
>Names
>-------
>Cod (LONG INT) (PK) (auto-increment)
>Name (varchar)
>
>Ok until here... Now let's run it on two diferent computers. Tables are
>empty, we create two diferent entries on both computers. They get the same
>'Cod'... :-(
>
>Now, let's change our 'Cod' to a TIMESTAMP... The problem seems to be
>resolved but then, who said that it wouldn't be possible two create two
>entries at the same second? Nothing guarantees that the clock is
>synchronized, nothing guarantees how many users are using it at the SAME
>TIME... So, problem unresolved.
>
>Third try: add an ID to the end of 'Cod', and mantain it TIMESTAMP. Well,
>fine... Problem is when 'n' (number of computers running the database
>independently) starts to grow... It doesn't seem a genial way to do it...
>
>So, what's next ? Any ideas ? I'm really needing some help here... Oh, and
>they are meant to be practically implemented (consider performance).
>
>Sorry about my english, but my thanks in advance,
>
>Hugo Jose Ferreira
>
Received on Sun Apr 28 2002 - 23:41:40 CEST