|
Home > Archive > SQL Anywhere Mobile > November 2005 > Last download time
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 |
Last download time
|
|
| Chance 2005-11-08, 4:14 pm |
| From the help...
The last_download timestamp is the value obtained from the consolidated
database during the last successful synchronization immediately prior to the
download phase. If the current user has never synchronized successfully,
this value is set to 1900-01-01.
Two questions:
1) OK so the time on the remotes are irrelevant because the time come is
coming from the consolidated database?
2) What system table(s) stores this value?
tia,
chance.
| |
| Breck Carter [TeamSybase] 2005-11-08, 4:14 pm |
| On 7 Nov 2005 07:35:20 -0700, "Chance" <chance@booklog.com> wrote:
>From the help...
>
>The last_download timestamp is the value obtained from the consolidated
>database during the last successful synchronization immediately prior to the
>download phase. If the current user has never synchronized successfully,
>this value is set to 1900-01-01.
>
>Two questions:
>
>1) OK so the time on the remotes are irrelevant because the time come is
>coming from the consolidated database?
That's right. Remote databases are notorious for having weird times
set, beyond the control of MobiLink Police Headquarters :)
>2) What system table(s) stores this value?
dbo.ml_subscription on the consolidated, sys.syssync on the remote;
note that the value stored on the remote uses the clock time from the
consolidated.
Also note there are *subtleties* that determine when last_download is
updated on the consolidated, such as the setting of SendDownloadAck.
Generally you don't care... unless you're going to write code that
makes decisions based on queries against ml_subscription. Section 7.7
of my book talks about this: "The MobiLink System Tables".
Breck
>
>tia,
>chance.
>
--
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
| |
| Chance 2005-11-08, 4:14 pm |
| Thanks. Question, what would happen if someone mucked around with the time
on the server? I don't know of anyway to stop them from doing this, how
'bout you?
--
Chance
Lead Software Engineer
Research & Development
Computerworks/Booklog
chance@booklog.com
Blog:
http://chance.PBDJMagazine.com
"Breck Carter [TeamSybase]" < NOSPAM__bcarter@risi
ngroad.com> wrote in
message news:pbvum1559jjr9bd
du33l4usft06qnsvrfu@
4ax.com...
> On 7 Nov 2005 07:35:20 -0700, "Chance" <chance@booklog.com> wrote:
>
>
> That's right. Remote databases are notorious for having weird times
> set, beyond the control of MobiLink Police Headquarters :)
>
>
> dbo.ml_subscription on the consolidated, sys.syssync on the remote;
> note that the value stored on the remote uses the clock time from the
> consolidated.
>
> Also note there are *subtleties* that determine when last_download is
> updated on the consolidated, such as the setting of SendDownloadAck.
> Generally you don't care... unless you're going to write code that
> makes decisions based on queries against ml_subscription. Section 7.7
> of my book talks about this: "The MobiLink System Tables".
>
> 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
| |
| Breck Carter [TeamSybase] 2005-11-08, 4:14 pm |
| On 7 Nov 2005 09:03:44 -0700, "Chance" <chance@booklog.com> wrote:
>Thanks. Question, what would happen if someone mucked around with the time
>on the server? I don't know of anyway to stop them from doing this, how
>'bout you?
It depends on if and how the date is used. If it is used for the
*usual* timstamp download cursors, pushing the date into the past may
cause rows to be re-downloaded, affecting performance but not logic.
Pushing the date into the future may stop rows from being downloaded
that should be... not good for the logic.
Just don't grant them the ability; i.e., don't run a GRANT MUCK AROUND
statement :)
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
|
|
|
|
|