At 18:56 17/09/2009, you wrote: ´¯¯¯ > % 99+% of the time, there won't be two updates "at the same time". In > other words, copy 1's change will almost always propagate to copy 2 > before copy 2 does another update. `---
The devil is in the 1% and the "almost" of course. But what do you and other think of his: Since the OP postulates that the chance of update clashes are low to very low, and given that he aims at a fixed number of only 4 updaters, isn't it possible to maintain, for each of 4 servers and _at the application level_ 4 distinct connections, one being local and the other 3 being remote. Of course all read-only operation can be done on the local connection, while a easy encapsulation is needed for write operations taking care of return codes. Avoiding all non-reproducible data (e.g. rowids generated by sqlite or timestamps, which will vary from system to system) isn't it possible for him to do it this way? It is certainly a waste of resource (but this is a redundant system) and it won't be very fast due to added write contention, but at least he won't have to do surgery on each new SQLite release. Since the OP had been thinking of a backup before each write, it shouldn't be a highly demanding environment. That's too easy, there must be a catch somewhere... Where is the thinko? _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
