|
Home > Archive > SQL Anywhere Mobile > February 2006 > Resolve conflict
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| R.Brouwer 2006-02-16, 7:24 am |
| Is there a simple way when resolving conflicts, the remote
who modified
a record the last time wins the conflict.
Another thing, what if the consolidate modified the record
later, in this case the record shouldn't be updated.
TIA
| |
| Breck Carter [TeamSybase] 2006-02-16, 7:24 am |
| See my book, or the Help:
MobiLink Administration Guide
Synchronization Techniques
Handling conflicts
Resolving conflicts
Resolving conflicts with resolve_conflict scripts
Breck
On 16 Feb 2006 04:36:28 -0800, R.Brouwer wrote:
>Is there a simple way when resolving conflicts, the remote
>who modified
>a record the last time wins the conflict.
>Another thing, what if the consolidate modified the record
>later, in this case the record shouldn't be updated.
>
>TIA
--
SQL Anywhere Studio 9 Developer's Guide
Buy the book: http://www.amazon.com/exec/obidos/A...7/risingroad-20
bcarter@risingroad.com
RisingRoad SQL Anywhere and MobiLink Professional Services
www.risingroad.com
| |
| Reg Domaratzki \(iAnywhere Solutions\) 2006-02-16, 7:24 am |
| > Is there a simple way when resolving conflicts, the remote
> who modified
> a record the last time wins the conflict.
Do you mean the time that the record was updated at the remote, or the time
that the update was synchronized to the consolidated?
> Another thing, what if the consolidate modified the record
> later, in this case the record shouldn't be updated.
Are you trying to stop ALL updates to the table on the consolidated? I'm a
little unclear what you're asking here.
--
Reg Domaratzki, Sybase iAnywhere Solutions
Sybase Certified Professional - Sybase ASA Developer Version 8
Please reply only to the newsgroup
iAnywhere Developer Community : http://www.ianywhere.com/developer
iAnywhere Documentation : http://www.ianywhere.com/developer/product_manuals
ASA Patches and EBFs : http://downloads.sybase.com/swd/base.do
-> Choose SQL Anywhere Studio
-> Set filter to "Display ALL platforms IN ALL MONTHS"
<R.Brouwer> wrote in message news:43f46297.77f.1681692777@sybase.com...
> Is there a simple way when resolving conflicts, the remote
> who modified
> a record the last time wins the conflict.
> Another thing, what if the consolidate modified the record
> later, in this case the record shouldn't be updated.
>
> TIA
| |
| R.Brouwer 2006-02-16, 9:24 am |
| > See my book, or the Help:
>
> MobiLink Administration Guide
>
> Synchronization Techniques
>
> Handling conflicts
>
> Resolving conflicts
>
> Resolving conflicts with resolve_conflict scripts
>
> Breck
>
> On 16 Feb 2006 04:36:28 -0800, R.Brouwer wrote:
>
> remote >who modified
> record >later, in this case the record shouldn't be
> updated. >
>
> --
> SQL Anywhere Studio 9 Developer's Guide
> Buy the book:
>
http://www.amazon.com/exec/obidos/A...7/risingroad-20
> bcarter@risingroad.com
> RisingRoad SQL Anywhere and MobiLink Professional Services
> www.risingroad.com
I implemented the upload_fetch, upload_old_row_inser
t and
the upload_new_row_inser
t.
When i started at the resolve_conflict i realised i need the
modify datetime for the uploaded row and the modify datetime
of the row being updated in the consolidated database.
The helpfiles aren't helping me out there (ea..probably i
misunderstand something)
TIA
| |
| David Fishburn 2006-02-16, 9:24 am |
| R.Brouwer wrote in news:43f46297.77f.1681692777@sybase.com
of sybase.public.sqlanywhere.mobilink:
RB> Is there a simple way when resolving conflicts, the remote
RB> who modified
RB> a record the last time wins the conflict.
RB> Another thing, what if the consolidate modified the record
RB> later, in this case the record shouldn't be updated.
Please ALWAYS include version and MORE importantly BUILD number
with EACH post (dbeng9 -v).
I just realized our documentation does not really provide any examples
of how to perform the standard timestamp based conflict resolution
rules. That is disappointing. I will include a sample to the doc team
to include it. That will be in our next major release of SA.
There are a number of ways to do what you ask but each of them requires
you to write some code.
If your consolidated database is ASA (please include this information
with future posts) then you have a few more options.
I personally favour this approach (from the 9.0.2 docs):
MobiLink Administration Guide
Synchronization Techniques
Handling conflicts
Resolving conflicts
Resolving conflicts with upload_update scripts
Okay, this sample DOES show timestamp based resolution, but it was very
difficult to find.
Read through that section, this part is of special interest:
IF( @@rowcount = 0 ) THEN
--
David Fishburn
Certified ASA Developer Version 8
iAnywhere Solutions - Sybase
Professional Services
Please only post to the newsgroup
Please ALWAYS include version and MORE importantly BUILD number with
EACH post (dbeng9 -v).
EBFs and Maintenance Releases
http://downloads.sybase.com/swx/sdmain.stm
Developer Community / Whitepapers
http://www.ianywhere.com/developer
CaseXpress - to report bugs
http://casexpress.sybase.com
CodeXchange - Free samples
[url]http://ianywhere.codexchange.sybase.com/servlets/ ProjectDocumentList[
/url]
| |
| R.Brouwer 2006-02-16, 9:24 am |
| > > Is there a simple way when resolving conflicts, the
>
> Do you mean the time that the record was updated at the
> remote, or the time that the update was synchronized to
> the consolidated?
>
> updated.
>
> Are you trying to stop ALL updates to the table on the
> consolidated? I'm a little unclear what you're asking
> here.
>
> --
> Reg Domaratzki, Sybase iAnywhere Solutions
> Sybase Certified Professional - Sybase ASA Developer
> Version 8 Please reply only to the newsgroup
>
> iAnywhere Developer Community :
> http://www.ianywhere.com/developer iAnywhere Documentation
> : http://www.ianywhere.com/developer/product_manuals ASA
> Patches and EBFs : http://downloads.sybase.com/swd/base.do
> -> Choose SQL Anywhere Studio
> -> Set filter to "Display ALL platforms IN ALL MONTHS"
>
>
> <R.Brouwer> wrote in message
> updated. >
>
>
First of all thanks for the fast reply.
Situation, 2 remote databases : R1 and R2 (Cosolidate C)
When R1 modifies rec A at a given time, R2 modifies the same
column at a later time.
When R2 synchronize, Row A will be updated on C.
Now when R1 synchronizes the row A...it was modified
earlyer, so i don't want it to update. How can i accomplish
this?
What will happen if the row on the consolidated database is
modified later than R2 modified it?
TIA
(Version Info : SQL Anywhere 9.0.2.3249)
| |
| R.Brouwer 2006-02-16, 9:24 am |
| > R.Brouwer wrote in news:43f46297.77f.1681692777@sybase.com
> of sybase.public.sqlanywhere.mobilink:
>
> RB> Is there a simple way when resolving conflicts, the
> remote RB> who modified
> RB> a record the last time wins the conflict.
> RB> Another thing, what if the consolidate modified the
> record RB> later, in this case the record shouldn't be
> updated.
>
> Please ALWAYS include version and MORE importantly BUILD
> number with EACH post (dbeng9 -v).
>
> I just realized our documentation does not really provide
> any examples of how to perform the standard timestamp
> based conflict resolution rules. That is disappointing.
> I will include a sample to the doc team to include it.
> That will be in our next major release of SA.
>
> There are a number of ways to do what you ask but each of
> them requires you to write some code.
>
> If your consolidated database is ASA (please include this
> information with future posts) then you have a few more
> options.
>
> I personally favour this approach (from the 9.0.2 docs):
> MobiLink Administration Guide
> Synchronization Techniques
> Handling conflicts
> Resolving conflicts
> Resolving conflicts with upload_update
> scripts
>
> Okay, this sample DOES show timestamp based resolution,
> but it was very difficult to find.
>
> Read through that section, this part is of special
> interest:
> IF( @@rowcount = 0 ) THEN
>
> --
> David Fishburn
> Certified ASA Developer Version 8
> iAnywhere Solutions - Sybase
> Professional Services
> Please only post to the newsgroup
> Please ALWAYS include version and MORE importantly BUILD
> number with EACH post (dbeng9 -v).
>
> EBFs and Maintenance Releases
> http://downloads.sybase.com/swx/sdmain.stm
>
> Developer Community / Whitepapers
> http://www.ianywhere.com/developer
>
> CaseXpress - to report bugs
> http://casexpress.sybase.com
>
> CodeXchange - Free samples
>
[url]http://ianywhere.codexchange.sybase.com/servlets/ ProjectDocumentList[
/url]
>
I'm running SQL Anywhere v9.0.2.3249
I don't get the upload_update example, first of all i count
10 arguments in the stored procedure 'sp_update_customer'
and I count 6 arguments in the call to the stored procedure
in the upload_update event (call
sp_update_customer(.......))
Maybe this is correct, my knowledge about stored procedures
and triggers isn't that good.
If I see the explanation of the upload_update table event I
miss aruments.
Probably I miss something here.
In the update_old/new_row_insert events I get the old/new
row uploaded from the client.
How can I find out when they where modified?
Do I have to insert a timestamp (default timestamp) column
in every table I want to synchronize on all remote databases
(like I have to do on the consolidated database for
time-synchronization)?
TIA
| |
| Breck Carter [TeamSybase] 2006-02-16, 9:24 am |
| It's a dangerous game, relying on datetime values set on a remote
database where you have no control overy the clock setting :)
Breck
On 16 Feb 2006 07:10:37 -0800, David Fishburn
<fishburn_spam@off.ianywhere.com> wrote:
>R.Brouwer wrote in news:43f46297.77f.1681692777@sybase.com
>of sybase.public.sqlanywhere.mobilink:
>
>RB> Is there a simple way when resolving conflicts, the remote
>RB> who modified
>RB> a record the last time wins the conflict.
>RB> Another thing, what if the consolidate modified the record
>RB> later, in this case the record shouldn't be updated.
>
>Please ALWAYS include version and MORE importantly BUILD number
>with EACH post (dbeng9 -v).
>
>I just realized our documentation does not really provide any examples
>of how to perform the standard timestamp based conflict resolution
>rules. That is disappointing. I will include a sample to the doc team
>to include it. That will be in our next major release of SA.
>
>There are a number of ways to do what you ask but each of them requires
>you to write some code.
>
>If your consolidated database is ASA (please include this information
>with future posts) then you have a few more options.
>
>I personally favour this approach (from the 9.0.2 docs):
>MobiLink Administration Guide
> Synchronization Techniques
> Handling conflicts
> Resolving conflicts
> Resolving conflicts with upload_update scripts
>
>Okay, this sample DOES show timestamp based resolution, but it was very
>difficult to find.
>
>Read through that section, this part is of special interest:
> IF( @@rowcount = 0 ) THEN
--
SQL Anywhere Studio 9 Developer's Guide
Buy the book: http://www.amazon.com/exec/obidos/A...7/risingroad-20
bcarter@risingroad.com
RisingRoad SQL Anywhere and MobiLink Professional Services
www.risingroad.com
| |
| Breck Carter [TeamSybase] 2006-02-16, 9:24 am |
| The example's wrong, you need a matching CALL.
Yes, you need a column to keep track of row timestamps. Like I said
earlier, beware of remote computers with wonky clock settings.
Breck
On 16 Feb 2006 08:13:19 -0800, R.Brouwer wrote:
>http://ianywhere.codexchange.sybase...7/risingroad-20
bcarter@risingroad.com
RisingRoad SQL Anywhere and MobiLink Professional Services
www.risingroad.com
| |
| R.Brouwer 2006-02-16, 11:24 am |
| > The example's wrong, you need a matching CALL.
>
> Yes, you need a column to keep track of row timestamps.
> Like I said earlier, beware of remote computers with wonky
> clock settings.
>
> Breck
>
> On 16 Feb 2006 08:13:19 -0800, R.Brouwer wrote:
>
> news:43f46297.77f.1681692777@sybase.com >> of
> sybase.public.sqlanywhere.mobilink: >>
> BUILD >> number with EACH post (dbeng9 -v).
> provide >> any examples of how to perform the standard
> timestamp >> based conflict resolution rules. That is
> disappointing. >> I will include a sample to the doc team
> to include it. >> That will be in our next major release
> of SA. >>
> of >> them requires you to write some code.
> this >> information with future posts) then you have a few
> more >> options.
> docs): >> MobiLink Administration Guide
> BUILD >> number with EACH post (dbeng9 -v).
> ocumentList >>
> count >10 arguments in the stored procedure
> 'sp_update_customer'
>and I count 6 arguments in the call
> to the stored procedure >in the upload_update event (call
> procedures >and triggers isn't that good.
> I >miss aruments.
> column >in every table I want to synchronize on all remote
> databases >(like I have to do on the consolidated database
> for >time-synchronization)?
>
> --
> SQL Anywhere Studio 9 Developer's Guide
> Buy the book:
>
http://www.amazon.com/exec/obidos/A...7/risingroad-20
> bcarter@risingroad.com
> RisingRoad SQL Anywhere and MobiLink Professional Services
> www.risingroad.com
Hi Breck,
Yes didn't even think about the clock settings...but you
have a solid rock point there.
How can I solve this little problem?
At this point I can say the last one who synchronizes wins
the game.
Or are there any other solutions?
TIA, Remco
| |
| Breck Carter [TeamSybase] 2006-02-16, 11:24 am |
| On 16 Feb 2006 08:41:30 -0800, R.Brouwer wrote:
>the last one who synchronizes wins
>the game.
For that, you need do nothing, just sit back and watch MobiLink take
the default action :)
In effect, every update to the consolidated database is honored in the
order in which it is received. For MobiLink synchronizations, it is
the time of the upload that determines when that update happens.
Note that MobiLink uploads entire *rows*... something to think about.
Breck
--
SQL Anywhere Studio 9 Developer's Guide
Buy the book: http://www.amazon.com/exec/obidos/A...7/risingroad-20
bcarter@risingroad.com
RisingRoad SQL Anywhere and MobiLink Professional Services
www.risingroad.com
| |
| R.Brouwer 2006-02-16, 11:24 am |
| > On 16 Feb 2006 08:41:30 -0800, R.Brouwer wrote:
>
>
> For that, you need do nothing, just sit back and watch
> MobiLink take the default action :)
>
> In effect, every update to the consolidated database is
> honored in the order in which it is received. For MobiLink
> synchronizations, it is the time of the upload that
> determines when that update happens.
>
> Note that MobiLink uploads entire *rows*... something to
> think about.
>
> Breck
>
> --
> SQL Anywhere Studio 9 Developer's Guide
> Buy the book:
>
http://www.amazon.com/exec/obidos/A...7/risingroad-20
> bcarter@risingroad.com
> RisingRoad SQL Anywhere and MobiLink Professional Services
> www.risingroad.com
Hi Breck,
So with time-synchronization is meant the time you will
synchronize with the consolidated database, and not the last
time the record was modified.
Think I misunderstood this.
So in order to synchronize on last record modified i need to
track modifications myself (Like a colum with type timestamp
DEFAULT timestamp).
I'm I right?
TIA Remco
| |
| Breck Carter [TeamSybase] 2006-02-16, 11:24 am |
| If you want to track the time a row was changed, you need a column
with TIMESTAMP DEFAULT TIMESTAMP.
On 16 Feb 2006 09:32:49 -0800, R.Brouwer wrote:
>http://www.amazon.com/exec/obidos/A...7/risingroad-20
>Hi Breck,
>
>So with time-synchronization is meant the time you will
>synchronize with the consolidated database, and not the last
>time the record was modified.
>Think I misunderstood this.
>So in order to synchronize on last record modified i need to
>track modifications myself (Like a colum with type timestamp
>DEFAULT timestamp).
>I'm I right?
>
>TIA Remco
--
SQL Anywhere Studio 9 Developer's Guide
Buy the book: http://www.amazon.com/exec/obidos/A...7/risingroad-20
bcarter@risingroad.com
RisingRoad SQL Anywhere and MobiLink Professional Services
www.risingroad.com
| |
| R.Brouwer 2006-02-16, 1:24 pm |
| > If you want to track the time a row was changed, you need
> a column with TIMESTAMP DEFAULT TIMESTAMP.
>
>
>
> On 16 Feb 2006 09:32:49 -0800, R.Brouwer wrote:
>
> MobiLink >> synchronizations, it is the time of the upload
> that >> determines when that update happens.
> to >> think about.
> oad-20 >> bcarter@risingroad.com
> Services >> www.risingroad.com
> last >time the record was modified.
> to >track modifications myself (Like a colum with type
> timestamp >DEFAULT timestamp).
>
> --
> SQL Anywhere Studio 9 Developer's Guide
> Buy the book:
>
http://www.amazon.com/exec/obidos/A...7/risingroad-20
> bcarter@risingroad.com
> RisingRoad SQL Anywhere and MobiLink Professional Services
> www.risingroad.com
Hi Breck,
Thanks for your time, I've asked all the questions and got
all the answers I needed.
Take care, Remco
| |
| David Fishburn 2006-02-17, 7:26 am |
| R.Brouwer wrote in news:43f4a49f.66ce.1681692777@sybase.com
of sybase.public.sqlanywhere.mobilink:
....
RB> I'm running SQL Anywhere v9.0.2.3249
RB>
RB> I don't get the upload_update example, first of all i count
RB> 10 arguments in the stored procedure 'sp_update_customer'
RB> and I count 6 arguments in the call to the stored procedure
RB> in the upload_update event (call
RB> sp_update_customer(.......))
RB> Maybe this is correct, my knowledge about stored procedures
RB> and triggers isn't that good.
RB> If I see the explanation of the upload_update table event I
RB> miss aruments.
RB> Probably I miss something here.
For a more complete example you can see the script I created on
CodeXchange.
http://ianywhere.codexchange.sybase...ctDocumentList?
folderID=319&expandFolder=319&folderID=0
Registration is free.
Once you have look at this sample:
Conflict Resolution Without Temporary Tables
--
David Fishburn
Certified ASA Developer Version 8
iAnywhere Solutions - Sybase
Professional Services
Please only post to the newsgroup
Please ALWAYS include version and MORE importantly BUILD number with
EACH post (dbeng9 -v).
EBFs and Maintenance Releases
http://downloads.sybase.com/swx/sdmain.stm
Developer Community / Whitepapers
http://www.ianywhere.com/developer
CaseXpress - to report bugs
http://casexpress.sybase.com
CodeXchange - Free samples
[url]http://ianywhere.codexchange.sybase.com/servlets/ ProjectDocumentList[
/url]
| |
| Greg Fenton 2006-02-17, 7:26 am |
| R.Brouwer wrote:
> So with time-synchronization is meant the time you will
> synchronize with the consolidated database, and not the last
> time the record was modified.
> Think I misunderstood this.
> So in order to synchronize on last record modified i need to
> track modifications myself (Like a colum with type timestamp
> DEFAULT timestamp).
> I'm I right?
In my opinion, it is a *rare* application that wants to maintain "first
one wins" for updates in the field. Often you want to attempt to merge
changes coming from different remotes based on some business logic.
More often, you want to design your application/schema such that the
shared rows are not being affected at multiple remotes. We'd need to
understand your application's requirements to determine if tracking the
time that a remote's change is made makes sense in your case.
However, on the consolidated you almost always want to have a
"last_modified" column of TIMESTAMP DEFAULT TIMESTAMP in order to have
remotes only download rows that have changed since their last
synchronization.
Hope this helps,
greg.fenton
--
Greg Fenton
Consultant, Solution Services, iAnywhere Solutions
--------
Visit the iAnywhere Solutions Developer Community
Whitepapers, TechDocs, Downloads
http://www.ianywhere.com/developer/
|
|
|
|
|