On 7 Oct 2009, at 10:13am, Jean-Denis Muys wrote: > [setup description] > > I'd appreciate some feedback here or > pointers to litterature.
You see how complicated you had to get before you had an acceptable solution ? Two extra columns ? Timestamps ? Retention of records which have to be ignored ? I see nothing obvious wrong, so here are some general comments. Try really really hard just to have all sites access your MySQL database remotely. MySQL is an excellent client/server version of SQL. You could kill all the complexity you had to invent by just having everyone access your database live. Not only is the programming simpler, but you can back everything up in one go, and everyone has completely up-to-date data. If this solution cannot be implemented for you, try Keep a journal. Keep an unaltered central copy of the data. As each site contacts the central site, play that sites journal back against the unaltered central copy. The post-journal central copy of the database becomes the new copy for distribution. If these just cannot be done, you have to implement your own solution. Check that it handles these nasty scenarios for synchronisation: One site deletes a record then another site modifies it. e.g. Branch 1 sez "Our supplier withdrew the product 'Flinns' and created a new one."; Branch 2 sez "Our supplier renamed their 'Flinns' product to be 'Flanns' because 'Flinns' is a swearword in Hijinks. Each site then continues selling the new product. Headquarters considers these the same product, and wants sales figures added up, not considered separate. Superseding UPDATEs. Starting with three cars: black, red and green, one site resprays all black cars red and another site resprays all red cars green. After synchronising, depending on which update you get first you may or may not end up with a red car. Competing UPDATE and INSERT. One site creates new product for category L. Then Headquarters sends out a memo that category L is now category Q but it doesn't know about the new product yet. The site's copy of the database gets accurate data, but since Headquarters got the UPDATE first, then the INSERT, it somehow still has a category L product. If your system deals with those, it's most of the way there. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
