on 09-29-2016 10:25 AM
Hi,
I'm wonder if it's possible to force an ongoing synchronization to stop in any event before the real dowload/upload data occurs?
For exemple, is it possible to write some SQL in the script for "begin_synchronization" event that will stop all future processing for this synchronization?
The reason is that we synchronize a couple of hundred tables by using "last_changed"-column in each of these. We also have up to 300-400 clients the synchronize every minute to make sure every client have the latest data.
This will cause a lot of selects just to determinate if there are any data changed at the consolidated database.
I'm think of using one table with one row that are trigged on every change. Lets call this "any_last_changed".
So when a table is updated the "last_changed" is updated but also the "any_last_changed".
Then is my plan that in "begin_synchronization" check this value. If nothing is changed then quit else continue and do a select in every table to find the updated row.
If any one have any other idea I want to know hw to handle this scenario. Maybe using "begin_download"/"begin_download_table" instead?
I can't change my download script right now. It would be to much work to handle it on every table.
I'm using Sybase 16, As consolidated database I'm running both SQL-Server and Oracle
/ Peter
Hi Peter,
I can think of a couple of approaches, but I'm afraid none of them will completely satisfy you.
The only way limited to add'l sync scripts I can think of is to raise an exception in prepare_for_download or begin_download (conn. level), but this will be treated as a sync. error.
If you have your download logic encapsulated in procedures, you can branch between a real SELECT and a dummy with an empty result set driven by a session variable, but that's probably what you just excluded in your description.
You could organize the sync clients to use multiple publications, a tiny one with any_last_changed, which is downloaded first and used to control whether the sync on the user data publication(s) will be upload only or bidirectional.
Did you evaluate the actual benefit of short-cutting the download queries? My experience with SQL Anywhere as cons.db (v.10 / 12 / 16) is that an index on the last_changed column alone is extremely efficient in recognizing 0 hits.
HTH for the moment
Volker
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
84 | |
24 | |
11 | |
9 | |
7 | |
6 | |
5 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.