|
Home > Archive > SQL Anywhere Mobile > May 2005 > How does MobiLink handle this update statement
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]
| Author |
How does MobiLink handle this update statement
|
|
| Brian Greiman 2005-05-12, 9:25 am |
| We have some flawed logic in our application that will update a primary key
value for our table. I have fixed the logic and will be deploying to all
end-users at next opportunity (60 remote users). I am wondering if I can
fix temporarily using event scripts in ML server.
Here is scenario:
1. Row inserted with primary key values of 1, 0, 0.
2. Update occurs to change primary key to 1, 1, 12.
How does ML handle second update statement? Here is a sample that was
generated on remote database::
UPDATE DBA.in_invoice_detail
SET brand=1,
size=12
WHERE company=1
AND brand=0
AND size=0
Since this row does not exist, will it do an insert? What events will fire
when the 2nd update comes across. I am looking for a way to temporarily
beat the system until I can get new program out to all users.
Thansk for any help,
Brian
| |
| Reg Domaratzki \(iAnywhere Solutions\) 2005-05-12, 8:24 pm |
| Assuming you do a synch between step one and step two, the second operation
will cause the upload_update script to be fired by MobiLink, but since the
new values of the pkey are used in the upload_update statement, the update
will update zero rows. You'll be left with a row on the consolidated with
pkey (1,0,0) and the same row on the remote with pkey (1,1,12).
The only solution I can think of is to use forced conflicts on the table,
and capture both the before and after images. You can then call a stored
procedure in the resolve_conflict event to handle the situation, while you
have access to old and new values.
--
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/swx/sdmain.stm
-> Choose SQL Anywhere Studio
-> Set "Platform Preview" and "Time Frame" to ALL
"Brian Greiman" <bgreiman@bernicks.com> wrote in message
news:42836253$1@foru
ms-2-dub...
> We have some flawed logic in our application that will update a primary
key
> value for our table. I have fixed the logic and will be deploying to all
> end-users at next opportunity (60 remote users). I am wondering if I can
> fix temporarily using event scripts in ML server.
>
> Here is scenario:
> 1. Row inserted with primary key values of 1, 0, 0.
> 2. Update occurs to change primary key to 1, 1, 12.
>
> How does ML handle second update statement? Here is a sample that was
> generated on remote database::
> UPDATE DBA.in_invoice_detail
> SET brand=1,
> size=12
> WHERE company=1
> AND brand=0
> AND size=0
>
> Since this row does not exist, will it do an insert? What events will
fire
> when the 2nd update comes across. I am looking for a way to temporarily
> beat the system until I can get new program out to all users.
>
> Thansk for any help,
> Brian
>
>
| |
| Brian Greiman 2005-05-12, 8:24 pm |
| Reg:
What would you expect in the following scenario:
1. Row inserted with primary key values of 1, 0, 0.
2. Update occurs to change primary key to 1, 1, 12.
3. Update occurs to change primary key to 1, 2, 12.
4. Synch occurs to upload data to consolidate.
What events would you expect to fire on ML Server and what would you expect
to see as final result?
Still trying to understand what exact flow would be. I looked at resulting
log files from such operations, but it is still very confusting.
Brian
"Reg Domaratzki (iAnywhere Solutions)" < Spam_bad_rdomarat@ia
nywhere.com>
wrote in message news:4283ad76@forums
-1-dub...
> Assuming you do a synch between step one and step two, the second
operation
> will cause the upload_update script to be fired by MobiLink, but since the
> new values of the pkey are used in the upload_update statement, the update
> will update zero rows. You'll be left with a row on the consolidated with
> pkey (1,0,0) and the same row on the remote with pkey (1,1,12).
>
> The only solution I can think of is to use forced conflicts on the table,
> and capture both the before and after images. You can then call a stored
> procedure in the resolve_conflict event to handle the situation, while you
> have access to old and new values.
>
> --
> 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/swx/sdmain.stm
> -> Choose SQL Anywhere Studio
> -> Set "Platform Preview" and "Time Frame" to ALL
>
> "Brian Greiman" <bgreiman@bernicks.com> wrote in message
> news:42836253$1@foru
ms-2-dub...
> key
all[color=darkred]
can[color=darkred]
> fire
>
>
| |
| David Fishburn 2005-05-13, 3:24 am |
| "Brian Greiman" <bgreiman@bernicks.com> wrote in
news:4283cc10@forums
-1-dub of sybase.public.sqlanywhere.mobilink:
BG> What would you expect in the following scenario:
BG> 1. Row inserted with primary key values of 1, 0, 0.
BG> 2. Update occurs to change primary key to 1, 1, 12.
BG> 3. Update occurs to change primary key to 1, 2, 12.
BG> 4. Synch occurs to upload data to consolidate.
BG>
BG> What events would you expect to fire on ML Server and what would you
BG> expect to see as final result?
This is the same as the previous example.
dbmlsync coalesces these operations (step 2&3) into 1 operation which is
uploaded. Since the row already existed on the remote, it is uploaded
as an "update" event.
On 1 row is uploaded with values 1,2,12 and the event for this table is
fired *once*.
Please ALWAYS include version and MORE importantly BUILD number
with EACH post (dbeng9 -v).
And in cases like this indicate what your consolidated database is and
what version.
--
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]
| |
| Breck Carter [TeamSybase] 2005-05-13, 9:24 am |
| On 12 May 2005 20:28:13 -0700, David Fishburn
<fishburn_spam@off.ianywhere.com> wrote:
>"Brian Greiman" <bgreiman@bernicks.com> wrote in
> news:4283cc10@forums
-1-dub of sybase.public.sqlanywhere.mobilink:
>
>BG> What would you expect in the following scenario:
>BG> 1. Row inserted with primary key values of 1, 0, 0.
>BG> 2. Update occurs to change primary key to 1, 1, 12.
>BG> 3. Update occurs to change primary key to 1, 2, 12.
>BG> 4. Synch occurs to upload data to consolidate.
>BG>
>BG> What events would you expect to fire on ML Server and what would you
>BG> expect to see as final result?
>
>This is the same as the previous example.
>
>dbmlsync coalesces these operations (step 2&3) into 1 operation which is
>uploaded. Since the row already existed on the remote, it is uploaded
>as an "update" event.
Doesn't that imply a sync between steps 1 and 2?
Breck
>On 1 row is uploaded with values 1,2,12 and the event for this table is
>fired *once*.
>
>Please ALWAYS include version and MORE importantly BUILD number
>with EACH post (dbeng9 -v).
>
>And in cases like this indicate what your consolidated database is and
>what version.
--
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
| |
| Brian Greiman 2005-05-13, 9:24 am |
| We are using ASA v9.01.1964 on both remote and consolidate.
Only one sync is occurring in this example (step 4).
Am I correct in assuming that the MLServer will process the following:
1. Receive an insert of 1, 0, 0. upload_insert event is called.
2. Receive an update of 1,2,12. upload_update event is called, upload_fetch
event called and no corresponding row is found so conflict resolution
scripts are triggered.
If I don't resolve the conflicts with any script, what happens to the update
in 2. Is it lost or does an insert happen and I am left with two rows in
consolidate (1,1,0 and 1,1,12)?
Brian
"Breck Carter [TeamSybase]" < NOSPAM__bcarter@risi
ngroad.com> wrote in
message news:50c98158g7fu7t8
4tlr9rfedug0h01eo8l@
4ax.com...
> On 12 May 2005 20:28:13 -0700, David Fishburn
> <fishburn_spam@off.ianywhere.com> wrote:
>
>
> Doesn't that imply a sync between steps 1 and 2?
>
> 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
| |
| Reg Domaratzki \(iAnywhere Solutions\) 2005-05-13, 9:24 am |
| No, if all three operations occur between synchs, an insert will be sent,
with primary key value (1,2,12), and an update, where the pkey changes from
(1,1,12) to (1,2,12).
I. 05/13 10:14:16. Upload operations on table 't1'
I. 05/13 10:14:16. Insert row:
I. 05/13 10:14:16. <pk1>: 1
I. 05/13 10:14:16. <pk2>: 1
I. 05/13 10:14:16. <pk3>: 12
I. 05/13 10:14:16. <c1>: 42
I. 05/13 10:14:16. Update row:
I. 05/13 10:14:16. Preimage:
I. 05/13 10:14:16. <pk1>: 1
I. 05/13 10:14:16. <pk2>: 1
I. 05/13 10:14:16. <pk3>: 12
I. 05/13 10:14:16. <c1>: 42
I. 05/13 10:14:16. Postimage:
I. 05/13 10:14:16. <pk1>: 1
I. 05/13 10:14:16. <pk2>: 2
I. 05/13 10:14:16. <pk3>: 12
I. 05/13 10:14:16. <c1>: 42
I. 05/13 10:14:16. # rows inserted in table t1 : 1
I. 05/13 10:14:16. # rows deleted in table t1 : 0
I. 05/13 10:14:16. # rows updated in table t1 : 1
I've attached a sample that shows this. Unzip the contents of the zip file
into an EMPTY directory, open a DOS prompt, CD into the directory where the
files exist, make sure ASA9 is in your path, and type "mlrep". Examine the
file check.txt to see what row where uploaded as a result of running
more.sql against the remote. Updating primary keys is EVIL. There's a
reason you should NOT change the PREVENT_ARTICLE_PKEY
_UPDATE database
option.
--
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/swx/sdmain.stm
-> Choose SQL Anywhere Studio
-> Set "Platform Preview" and "Time Frame" to ALL
"Brian Greiman" <bgreiman@bernicks.com> wrote in message
news:4284b25d$1@foru
ms-1-dub...
> We are using ASA v9.01.1964 on both remote and consolidate.
>
> Only one sync is occurring in this example (step 4).
> Am I correct in assuming that the MLServer will process the following:
> 1. Receive an insert of 1, 0, 0. upload_insert event is called.
> 2. Receive an update of 1,2,12. upload_update event is called,
upload_fetch
> event called and no corresponding row is found so conflict resolution
> scripts are triggered.
>
> If I don't resolve the conflicts with any script, what happens to the
update
> in 2. Is it lost or does an insert happen and I am left with two rows in
> consolidate (1,1,0 and 1,1,12)?
>
> Brian
>
>
>
> "Breck Carter [TeamSybase]" < NOSPAM__bcarter@risi
ngroad.com> wrote in
> message news:50c98158g7fu7t8
4tlr9rfedug0h01eo8l@
4ax.com...
you[color=darkred]
is[color=darkred]
> http://www.amazon.com/exec/obidos/A...7/risingroad-20
>
>
begin 666 update_pkey.zip
M4$L#!!0``@`(`*A1K3*
KI%&LG ```"H!```(````;6]R92YS<6PK3BU1R"\H
MR<S/4P@(<@US]0N)=PP*\73V<8T/':-C \-<'$,<56P55#/3TM3M^;ERLPK
M3BTJ4< C,*\E7*#%4*$O,*4TM5M
PU#$`0A,C3:"2Y/S<W,P2(*.T("6Q)!6D
MK!AH34&VH:VA#I R@E#&MH9&"N49J46I$"F%Q+P4L*P!E&5L:T"4:49X33.$
MFV9HA&Q<,?$^SP-Y' !02P,$% `"``@`P%& M,ED2$C,W`@``Z@8```D
```!M
M;')E<"YB87255$V+VS 0O1O'X9 H-V-DLU2" B$8RE)ZZJ70XT*1+241L
22O
M).<#^N,[DIS$L;U-]B);HYDW3S-O](T7&PUZM4J3-#%<0EQ_:R@V5*TYN T'
M5<N<&_0"/-..0VVYL9.."^RH$30OT:" #+4(Q;H7A#*C4M7+38$P
3RYV/R9Y]
M7I;+TCI=`=GCB:/&P6Q/A0.61_,12 $CKM99H95=LES%GUJPC.5T6>U99M_*
MD8?BAEKN0& #91;S'JU^F+$^3E38P^P
GCL0"AX--\,I^,D<#X,S -K2ADASZO\1,B
MTR0>SG[![$= O8'6=H\XH;B2"7-/>'2\!%+GC,B!&'B8/IRWCP9D:7@US:EK
M&\.%L19M&V)U35(;WK5AJ.*%ZR+:HRHVT1C$<OS+>'G%A0QQ(0-<2)\+&>!"
MAKF0*RZ^U\RJ((Y]'7+
]63S=+90TD=L[& Q(=+PT1*U#:`3\(Z\!Q6
7U_:7SB
M9M#CI$34FE H;5+!EZ?%U^XI43Y#H:MC]^0#<AX*[^N:Y:5>`W&Q3?[_0Q/3
M!#> ?C<T.M? 3++#V16A1IR'8J5763K^
DM=-^^#.EEP$$W:W9+8"L\2TI2R '
MK+'B(TQ+V5EJ$"CZS#?H_Y]*]RIM.DW& 1L@01'$CF2S]BQFRH62S
1JLC('53
M-"^', & GBH4G,5QW]P@$M12V4W=
P/90TJ2C"W[SS=2L0#V>I/RZ13V]@@,C
ML.%S:GO@LWV_S6?H?I%#JGE3S,L3< )OE^U =CL6&%]LSQ7]02P,$% `"``@`
M&%&M,E< 9VY8^`@``%@4```@```!
C;VYS+G- Q;*U476_:,!1]'A+_X;X
%)#I!
MJ:9-B%6LN P-A97"M#U9)KZ 5<>.;(>J^_6S8PJAVS1M6A#F7N?XG.O[0<$,
MR]&A`57FU&"N'=I!L]%L6'2@"R>T@J)<2Y&]GDB]9I)RYMB:6:2"PQ"Z@U]!
M.4I/2K7D5.JM];ADGB85;V:0.03/(?W:@U:S\:IXZ(%0#K=H.I5[>>[VZVYV
MAI7,.IIK+C8". 3B1HW4L+X#CAI72G78J)
B-R9I[@`9]:7K/CA?RWWVXVVE5L
M-PLR6A+XO)C?D/%J06 U^\@4ETB,T<9'"OZ9KY;A!UA6W?CXG((*WC2-NQA.
MTDQS_#/*1VK9-@#WS&0[9EJ];K?;?H$M+1JJ?-4.ND?LY=N7T"K)-6P="O[6
M'\ADFL8C%Q=PT7OW!H2
%^[L9H=-T3+& #91;2=+ZDJW1ZMR)UU%4
-]64TFX[I[7Q!
MII.4?B+?(E!LZC<?1FYM?MJ\`K=#%<\<!,16:8-A/Z+!5\!7# O8:J&V)^P]
M63X780@A4X/X#J7%,T:VUL95A/9)93NCE?C.PKG?</5K7%Y;;+Q#TG%L7R8E
MY)(RSFE,K\V,*%P+DGT
OZ4#BJK4LI&:<"N6+Y9+0>TFT0P/HT/=[)DNTT+KN
MQ,^8W(Y6LV4[>6[&OU,J"S^7&)6B'43"9/IY&<(U/.[09S5,6O!"3L.8G>Q^
ML/]1/(Y[%(\V;(S.0P3_67;$<Z&"P? 6CJK2STEAMHK;UVID+:I
T@$Y9^QR?
MO_.U/(14.3&L\S^/]\= ?@!02P,$% `"``@`'%&M,O0=E0,9`0``S0$```<`
M``!R96TN<W%L=9!/:\) $,7/#>0[#+FL@@C6HWC8Q&T;L$G8W13L):S)8(.K
M*\E:D-+OWDVTM/;/88=],+_W9B:CG#XRR;B 8XM-L3_N9K[G>RU:, =;FST<
MCFM=E^-[;=9*%Y6R:JU:+.H*YO#V";W/_F(JU&BQ,+HJM-FT#B!I0OJ LD%E
M$9R9=G4"`]^[.6PG4.\M;K 9]? +V6DZ_R_*ZMZEWJCG!%D
\#9S-RK'O3H>\-
M^[B(,RH99'FXC",JXS2!8!'28!Q8;*T;-X !2!HN63=,QUP(L4JB!YX
F\?.9
MR@7C$#2X^UH]^+];Y*&(> )SU0J8_,WT/X"[]Y0=RE3$@,LKBC !=+#@3`LB+
M:>U<FU+I[D<@/=N*ISEYG717_0!02P$"% `4``(`" "H4:TRJZ11K)P````J
M`0``" `````````!`" `MH$`````;6]R92YS<6Q02P$"% `4``(`" # 4:TR
M61(2,S<"``#J!@``"0`````````!`" `_X'"````;6QR97 N8F%T4$L!`A0`
M% `"``@`&%&M,E< 9VY8^`@``%@4```@````
``````0`@`+:!( ,``&-O;G,N
M<W%L4$L!`A0`% `"``@`'%&M,O0=E0,9`0``S0$```<``````````0`@`+:!
AA 4``')E;2YS<6Q02P4&``````0`! #8````P@8`````
`
end
| |
| Breck Carter [TeamSybase] 2005-05-13, 9:24 am |
| Changes to primary key values are generally forbidden with MobiLink,
and I have not done any research. It shouldn't be too hard, however,
to test; you could put MESSAGE ... TO CONSOLE statements in the
various scripts to see what happens, AND use -v+ on both dbmlsrv9.exe
and dbmlsync.exe command lines to see the row values, scripts, etc.
I am very interested in what you find. Changing primary key values
sometimes happens, and I would be interested if there was a way to
make MobiLink handle it in an elegant fashion.
Breck
On 13 May 2005 06:57:49 -0700, "Brian Greiman" <bgreiman@bernicks.com>
wrote:
>We are using ASA v9.01.1964 on both remote and consolidate.
>
>Only one sync is occurring in this example (step 4).
>Am I correct in assuming that the MLServer will process the following:
>1. Receive an insert of 1, 0, 0. upload_insert event is called.
>2. Receive an update of 1,2,12. upload_update event is called, upload_fetch
>event called and no corresponding row is found so conflict resolution
>scripts are triggered.
>
>If I don't resolve the conflicts with any script, what happens to the update
>in 2. Is it lost or does an insert happen and I am left with two rows in
>consolidate (1,1,0 and 1,1,12)?
>
>Brian
>
>
>
>"Breck Carter [TeamSybase]" < NOSPAM__bcarter@risi
ngroad.com> wrote in
>message news:50c98158g7fu7t8
4tlr9rfedug0h01eo8l@
4ax.com...
>http://www.amazon.com/exec/obidos/A...7/risingroad-20
>
--
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\) 2005-05-13, 9:24 am |
| Argh, a bloody typo in my last post. The primary key on the insert is
(1,1,12), NOT (1,2,12).
> No, if all three operations occur between synchs, an insert will be sent,
> with primary key value (1,1,12), and an update, where the pkey changes
from
> (1,1,12) to (1,2,12).
--
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/swx/sdmain.stm
-> Choose SQL Anywhere Studio
-> Set "Platform Preview" and "Time Frame" to ALL
"Reg Domaratzki (iAnywhere Solutions)" < Spam_bad_rdomarat@ia
nywhere.com>
wrote in message news:4284b877$1@foru
ms-1-dub...
> No, if all three operations occur between synchs, an insert will be sent,
> with primary key value (1,2,12), and an update, where the pkey changes
from
> (1,1,12) to (1,2,12).
>
> I. 05/13 10:14:16. Upload operations on table 't1'
> I. 05/13 10:14:16. Insert row:
> I. 05/13 10:14:16. <pk1>: 1
> I. 05/13 10:14:16. <pk2>: 1
> I. 05/13 10:14:16. <pk3>: 12
> I. 05/13 10:14:16. <c1>: 42
> I. 05/13 10:14:16. Update row:
> I. 05/13 10:14:16. Preimage:
> I. 05/13 10:14:16. <pk1>: 1
> I. 05/13 10:14:16. <pk2>: 1
> I. 05/13 10:14:16. <pk3>: 12
> I. 05/13 10:14:16. <c1>: 42
> I. 05/13 10:14:16. Postimage:
> I. 05/13 10:14:16. <pk1>: 1
> I. 05/13 10:14:16. <pk2>: 2
> I. 05/13 10:14:16. <pk3>: 12
> I. 05/13 10:14:16. <c1>: 42
> I. 05/13 10:14:16. # rows inserted in table t1 : 1
> I. 05/13 10:14:16. # rows deleted in table t1 : 0
> I. 05/13 10:14:16. # rows updated in table t1 : 1
>
> I've attached a sample that shows this. Unzip the contents of the zip
file
> into an EMPTY directory, open a DOS prompt, CD into the directory where
the
> files exist, make sure ASA9 is in your path, and type "mlrep". Examine
the
> file check.txt to see what row where uploaded as a result of running
> more.sql against the remote. Updating primary keys is EVIL. There's a
> reason you should NOT change the PREVENT_ARTICLE_PKEY
_UPDATE database
> option.
>
> --
> 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/swx/sdmain.stm
> -> Choose SQL Anywhere Studio
> -> Set "Platform Preview" and "Time Frame" to ALL
>
> "Brian Greiman" <bgreiman@bernicks.com> wrote in message
> news:4284b25d$1@foru
ms-1-dub...
> upload_fetch
> update
in[color=darkred]
> you
> is
uploaded[color=darkr
ed]
is[color=darkred]
and[color=darkred]
>
>
>
| |
| Breck Carter [TeamSybase] 2005-05-13, 1:23 pm |
| It looks like a sync followed by an insert and then a primary key
change is uploaded as an insert of the final row; so far so good.
However, a sync followed by a primary key change is uploaded as an
update of the row identified by the *new* primary key value, so it
doesn't match anything. I cannot see how any MobiLink script running
on the consolidated could handle this because the uploaded row does
not contain the old primary key values, so an UPDATE statement running
on the consolidated could not specify which row to change.
Breck
On 13 May 2005 06:57:49 -0700, "Brian Greiman" <bgreiman@bernicks.com>
wrote:
>We are using ASA v9.01.1964 on both remote and consolidate.
>
>Only one sync is occurring in this example (step 4).
>Am I correct in assuming that the MLServer will process the following:
>1. Receive an insert of 1, 0, 0. upload_insert event is called.
>2. Receive an update of 1,2,12. upload_update event is called, upload_fetch
>event called and no corresponding row is found so conflict resolution
>scripts are triggered.
>
>If I don't resolve the conflicts with any script, what happens to the update
>in 2. Is it lost or does an insert happen and I am left with two rows in
>consolidate (1,1,0 and 1,1,12)?
>
>Brian
>
>
>
>"Breck Carter [TeamSybase]" < NOSPAM__bcarter@risi
ngroad.com> wrote in
>message news:50c98158g7fu7t8
4tlr9rfedug0h01eo8l@
4ax.com...
>http://www.amazon.com/exec/obidos/A...7/risingroad-20
>
--
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
| |
| Brian Greiman 2005-05-13, 8:24 pm |
| From what I have seen a sync followed by a primary key change followed by
another primary key change is uploaded as an insert and then an update. A
primary key change after a synch is doomed to failure, because the new
primary key does not exist (as you stated below). About the only thing I
can do is match up the row on the other key elements that have not changed
and do an update of these values in the upload_end script. Conflict
resolution events are fired on this table because the row from the
consolidate is not found.
Brian
"Breck Carter [TeamSybase]" < NOSPAM__bcarter@risi
ngroad.com> wrote in
message news:kfs981hl8muqudu
2t9un1png14d4s4u3el@
4ax.com...
> It looks like a sync followed by an insert and then a primary key
> change is uploaded as an insert of the final row; so far so good.
>
> However, a sync followed by a primary key change is uploaded as an
> update of the row identified by the *new* primary key value, so it
> doesn't match anything. I cannot see how any MobiLink script running
> on the consolidated could handle this because the uploaded row does
> not contain the old primary key values, so an UPDATE statement running
> on the consolidated could not specify which row to change.
>
> Breck
>
> On 13 May 2005 06:57:49 -0700, "Brian Greiman" <bgreiman@bernicks.com>
> wrote:
>
upload_fetch[color=d
arkred]
update[color=darkred
]
you[color=darkred]
is[color=darkred]
is[color=darkred]
>
> --
> 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
|
|
|
|
|