SQL Anywhere Mobile - Download filtering timestamp precision warning

Author

Download filtering timestamp precision warning

Breck Carter [TeamSybase]

2005-08-17, 8:25 pm

MobiLink warns about two different issues related to timestamp
precision; one comes with a bunch of suggestions, the other does not.

Will the suggested use of DEFAULT_TIMESTAMP_IN
CREMENT,
TRUNCATE_TIMESTAMP_V
ALUES and dbmlsrv9 -zp *also* solve the issue
mentioned in the *second* warning below?

SQL Anywhere 9.0.2.3124
Oracle9i Release 9.2.0.1.0
iAnywhere Solutions 9 - Oracle Wire Protocol 4.20.00.81

=====
W. 08/17 10:32:45. <1.5> [1]: Warning: [10017] The consolidated and
remote databases have different timestamp precisions. Consolidated
database timestamps are precise to 0 digit(s) in the fractional second
while the remote database timestamps are precise to 6 digit(s)
W. 08/17 10:32:45. <1.5> [1]: Warning: [10018] The timestamp precision
mismatch may be resolved by setting the DEFAULT_TIMESTAMP_IN
CREMENT
option on the remote database to 1000000 and TRUNCATE_TIMESTAMP_V
ALUES
to 'On'
W. 08/17 10:32:45. <1.5> [1]: Warning: [10020] The timestamp precision
mismatch may affect upload conflict detection. Use the -zp option to
cause the MobiLink synchronization server to use the lowest timestamp
precision for conflict detection purposes
=====

=====
W. 08/17 10:32:45. <1.5> [1]: Warning: [10015] Table
'EVENT_RESULT_OPTION
' has at least one timestamp column. Due to a
timestamp precision mismatch, uploaded timestamps can lose precision,
defeating download filtering
=====

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

Graham Hurst

2005-08-24, 8:25 pm

If you use DEFAULT_TIMESTAMP_IN
CREMENT and TRUNCATE_TIMESTAMP_V
ALUES to
get the same timestamp precision on the remotes as on the consolidated,
then you shouldn't need to use -zp and you shouldn't see the 2nd
warning. Since the timestamp precisions would then match, the conditions
would not exist that trigger warnings 10015, 10017, 10018, 10020 and 10021.

Cheers,

Graham

Breck Carter [TeamSybase] wrote:
> MobiLink warns about two different issues related to timestamp
> precision; one comes with a bunch of suggestions, the other does not.
>
> Will the suggested use of DEFAULT_TIMESTAMP_IN
CREMENT,
> TRUNCATE_TIMESTAMP_V
ALUES and dbmlsrv9 -zp *also* solve the issue
> mentioned in the *second* warning below?
>
> SQL Anywhere 9.0.2.3124
> Oracle9i Release 9.2.0.1.0
> iAnywhere Solutions 9 - Oracle Wire Protocol 4.20.00.81
>
> =====
> W. 08/17 10:32:45. <1.5> [1]: Warning: [10017] The consolidated and
> remote databases have different timestamp precisions. Consolidated
> database timestamps are precise to 0 digit(s) in the fractional second
> while the remote database timestamps are precise to 6 digit(s)
> W. 08/17 10:32:45. <1.5> [1]: Warning: [10018] The timestamp precision
> mismatch may be resolved by setting the DEFAULT_TIMESTAMP_IN
CREMENT
> option on the remote database to 1000000 and TRUNCATE_TIMESTAMP_V
ALUES
> to 'On'
> W. 08/17 10:32:45. <1.5> [1]: Warning: [10020] The timestamp precision
> mismatch may affect upload conflict detection. Use the -zp option to
> cause the MobiLink synchronization server to use the lowest timestamp
> precision for conflict detection purposes
> =====
>
> =====
> W. 08/17 10:32:45. <1.5> [1]: Warning: [10015] Table
> 'EVENT_RESULT_OPTION
' has at least one timestamp column. Due to a
> timestamp precision mismatch, uploaded timestamps can lose precision,
> defeating download filtering
> =====
>
> 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

Sponsored Links