From: Joerg Bruehe
Date: August 19 2010 11:25am
Subject: Re: OpenOffice, Go-OO, ODBC, Offline Data Entry
List-Archive: http://lists.mysql.com/mysql/222589
Message-Id: <4C6D1490.9080501@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

Hi!


Jerry Schwartz wrote:
> I deal with a somewhat similar situation. Even though we have fast VPN =

> connections among our various offices, each has been afflicted with a=20
> different database structure (and software) which they cannot change.
>=20
> What I suggest you do is use the kind of "pseudo-synchronization" that =
we do.=20
> Use a local copy of the application and database on each PC (MySQL will=
 do=20
> fine on even a modest system). Timestamp each record when you create or=
 change=20
> it.
>=20
> When the user is back in contact with the office, extract all of the re=
cords=20
> with timestamps newer than the last "synchronization" event and update =
the=20
> central database.
>=20
> Is this foolproof? Absolutely not, if there are conflicts between the c=
hanges=20
> by different users. You'll be stuck with "He who write last, writes bes=
t"; but=20
> I think that's as good as it's going to get for you.

AIUI, you could prevent that by having a second timestamp, "based-on":
If "based-on" in the new record is the same value as "changed-on" in the
central data base, update - if they differ, you had somebody else come
first and will now need some manual alignment.

>=20
> How well this works depends upon the type of work. If the users have=20
> non-overlapping "customers", or whatever, then it won't be too bad. You=
'll=20
> have to judge for yourself.
>=20
> [[...]]

HTH,
J=F6rg

--=20
Joerg Bruehe,  MySQL Build Team,  joerg.bruehe@stripped
ORACLE Deutschland B.V. & Co. KG,   Komturstrasse 18a,   D-12099 Berlin
Geschaeftsfuehrer: Juergen Kunz, Marcel v.d. Molen, Alexander v.d. Ven
Amtsgericht Muenchen: HRA 95603