I remember quickreading them, seemed quite ok if use case was able to work with free version. DB exchangeability a big plus in my book, but not all devs think that is important. Paid support was steep IIRC, be certain to check as well as licensing terms.
In desktop surroundings should be no problem, I wondered about the android client, but that would not be needed in your current use case if my visualization is not to far off target. Back then only android as mobile client, which is easy to understand as the language is Java, but that would also be no deal breaker for you.


>Hi Dragan and Thomas,
>
>I am looking into the community edition of SymmetricDS (www.symmetricds.com). Looks interesting.
>
>It seems to be more straightforward than MySQL Replication. What do you guys think?
>
>
>
>
>>>Hi Guys,
>>>
>>>Basically, I am doing a POS app which will be used by a handful of branches and one head office. All will be connected via internet.
>>>
>>>We would like for the following to be implemented:
>>>
>>>1. Whenever head office say creates, deletes or modifies a new product, it will be propagated to the Products table of each branch.
>>>
>>>2. Conversely, branch sales data feeds are pushed to the head office.
>>>
>>>3. In the event that internet connection fails during this "synching", how does one know where "we left off" to continue?
>>
>>I had to devise such a scheme back in 1998, with three grain silos and one central office. The connections were miserable - modems which just wouldn't connect most of the time, or floppies which may be damaged from all the dust in the air.
>>
>>My solution would be to always do two-way updates. Every record had a two part key - the workstation id (two bytes) and the pk (integer in a c(10) field). Actually, the first part was site id - all six boxes at the central used the same one. Everyone would write their own records, while records from others were read-only, except the central could overwrite anything. Every record had a timestamp of the last write. The newly updated records from all tables would be written into a temp subfolder and zipped from distribution. The received zips would again be unzipped into a temp subfolder and inserted/updated into main tables. The order of receiving was irrelevant (though it may lead to inconsistencies, i.e. if one update was missing some things wouldn't total right), but would be set right when the missing zip arrived.
>>
>>It was sort of complicated but turned out to be robust; it passed all the tests. However, the whole scheme was abandoned after a few months - the personnel manning the stations were not motivated to maintain it. The modems worked perhaps a few times, floppies would be forgotten or lost.