|
Home > Archive > SQL Anywhere Mobile > October 2005 > Timing Issue with Downloads
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 |
Timing Issue with Downloads
|
|
| Kevin Dunn 2005-10-27, 8:20 am |
| We are using ASA 9.01.1841 and have implemented in our download_cursor scripts to only pull down records that have changed since the last time a user has synched. The issue we had was if Remote User A adds records on 9/1/05 12:15 and then synchs on say 9/4/05 our mod_datetime field stills has the 9/1/05 12:15 datetime and if Remote User B had synched say on 9/3/05 they will not get the new records that Remote User A has added when Remote User B synchs the next time because of the mod_datetime field being in the past.
I have since changed the upload_* scripts to set the mod_datetime field to the current datetime during the synch process. My issue is that we have remote users with missing data that happen before the fix to the scripts, Is there any way to have those tables with the issue replicate all data down to the remote users?
--
Kevin Dunn
Email: kevin.dunn@spsinc.com
Home Email: kdunn2@carolina.rr.com
H: 704-488-0048
W: 704-544-5501 ext 295
| |
| Greg Fenton 2005-10-27, 8:20 am |
| Kevin Dunn wrote:
> The issue we had was if Remote
> User A adds records on 9/1/05 12:15 and then synchs on say 9/4/05 our
> mod_datetime field stills has the 9/1/05 12:15 datetime and if Remote
> User B had synched say on 9/3/05 they will not get the new records that
> Remote User A has added when Remote User B synchs the next time because
> of the mod_datetime field being in the past.
This is why the "mod_datetime" is a column that should only exist in the
*consolidated* and only be maintained by the consolidated. The remotes
don't need that value as its only purpose is for synchronization. If
you need to maintain the date for you application's needs (e.g. a
"order_entered_on" value), then you should have a *separate* data column
for you application than the "mod_datetime" used for synchronization
purposes.
What type of database are you using for your consolidated?
What is the definition of the "mod_datetime" column?
> I have since changed the upload_* scripts to set the mod_datetime
> field to the current datetime during the synch process. My issue is
> that we have remote users with missing data that happen before the fix
> to the scripts, Is there any way to have those tables with the issue
> replicate all data down to the remote users?
One way would be to manually update the mod_datetime value of all rows
in the table to a value older than the previous synchronization time of
all your remotes. This way those rows would all be re-downloaded (this
might take some time), and you'd likely be downloading lots of rows each
remote already has, but any previously missed rows would also be downloaded.
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/
| |
| Kevin Dunn 2005-10-27, 8:20 am |
| The mod_datetime column is of data type datetime and our consolidated server
is ASA 9.01.1841. I see your point about only having the field in the
consolidated database, I will remember that next time when I design a table.
If I update the mod_datetime field on the existing records when the rows are
downloaded the ones that don't exist will be inserted?
Thanks for your help
--
Kevin Dunn
Email: kevin.dunn@spsinc.com
Home Email: kdunn2@carolina.rr.com
H: 704-488-0048
W: 704-544-5501 ext 295
"Greg Fenton" <greg. fenton_NOSPAM_@ianyw
here.com> wrote in message
news:434aa435$1@foru
ms-1-dub...
> Kevin Dunn wrote:
>
> This is why the "mod_datetime" is a column that should only exist in the
> *consolidated* and only be maintained by the consolidated. The remotes
> don't need that value as its only purpose is for synchronization. If you
> need to maintain the date for you application's needs (e.g. a
> "order_entered_on" value), then you should have a *separate* data column
> for you application than the "mod_datetime" used for synchronization
> purposes.
>
> What type of database are you using for your consolidated?
> What is the definition of the "mod_datetime" column?
>
>
>
> One way would be to manually update the mod_datetime value of all rows in
> the table to a value older than the previous synchronization time of all
> your remotes. This way those rows would all be re-downloaded (this might
> take some time), and you'd likely be downloading lots of rows each remote
> already has, but any previously missed rows would also be downloaded.
>
> 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/
| |
| Greg Fenton 2005-10-27, 8:20 am |
| Kevin Dunn wrote:
>
> If I update the mod_datetime field on the existing records when the rows are
> downloaded the ones that don't exist will be inserted?
>
Yes. Any rows sent via a download_cursor will either be inserted or
update the existing rows with the downloaded values (in the MobiLink
world, the "consolidated is King"...what it gives a remote, the remote
takes).
greg.fenton
--
Greg Fenton
Consultant, Solution Services, iAnywhere Solutions
--------
Visit the iAnywhere Solutions Developer Community
Whitepapers, TechDocs, Downloads
http://www.ianywhere.com/developer/
| |
| Kevin Dunn 2005-10-27, 8:21 am |
| Thanks for the help, it worked.
--
Kevin Dunn
Email: kevin.dunn@spsinc.com
Home Email: kdunn2@carolina.rr.com
H: 704-488-0048
W: 704-544-5501 ext 295
"Greg Fenton" <greg. fenton_NOSPAM_@ianyw
here.com> wrote in message
news:434c10fd@forums
-2-dub...
> Kevin Dunn wrote:
>
> Yes. Any rows sent via a download_cursor will either be inserted or
> update the existing rows with the downloaded values (in the MobiLink
> world, the "consolidated is King"...what it gives a remote, the remote
> takes).
>
> greg.fenton
> --
> Greg Fenton
> Consultant, Solution Services, iAnywhere Solutions
> --------
> Visit the iAnywhere Solutions Developer Community
> Whitepapers, TechDocs, Downloads
> http://www.ianywhere.com/developer/
|
|
|
|
|