on 2022 Nov 29 5:36 AM
We have an Installation of 2 SQL-Anywhere 17 Databases, synchronizing with each other via Mobilink.
The Mobilink Server brings continously warnings:
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). Resolve the timestamp precision mismatch by setting the SQL Anywhere DEFAULT_TIMESTAMP_INCREMENT option on the remote database to 1000000 and TRUNCATE_TIMESTAMP_VALUES to 'On'. UltraLite remotes must set the TIMESTAMP_INCREMENT option to 1000000. The timestamp precision mismatch may affect upload conflict detection. Use the -zp option to cause the synchronization server to use the lowest timestamp precision for conflict detection purposes
This means for me that the remote has a lower precision than the server. But the following statements gives the same result on cons. and rem.
select * from sysoptions where "option" in ('TRUNCATE_TIMESTAMP_VALUES', 'DEFAULT_TIMESTAMP_INCREMENT'); ---> default_timestamp_increment = 1 ---> truncate_timestamp_values = OffAlso, the following statement gives the actual time on cons. and rem. with the same resolution:
select current timestamp; ---> 2022-11-29 11:02:55.394
Which means that both databases have the same timestamp resolution.
I thought it may be related to the already existing timestamps in the table being synchronized, so that I cut all the fractions (milliseconds) from the column of the table in charge, it did not help!
update MYTABLE set ColWithTimeStamp = dateadd(millisecond, -millisecond(ColWithTimeStamp), ColWithTimeStamp);
I tried to start mlsrv17 with the option -zp, also no success!
How could the solution look like?
Request clarification before answering.
What value is returned if you connect to the consolidated database using DBISQL using the same connection string that the Mobilink Server uses and you execute the following SQL :
SELECT last_modified FROM ml_scripts_modified
I suspect no rows are returned, which is why ML is unable to determine the timestamp precision.
If that's the case, populate the table again with a single row, using the same SQL you can find in the %SQLANY17%\\MobiLink\\setup\\syncsa.sql file.
insert into ml_scripts_modified ( last_modified ) values ( dateformat( CURRENT TIMESTAMP, 'yyyy/mm/dd hh:nn:ss' ) );
Reg
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I don't like the way we handle that situation without returning a warning that we were unable to determine the timestamp precision. I plan on making a change to make this situation more clear in the future.
The table ml_scripts_modified should be refreshed every time a new mobilink script is updated/inserted.
Calling the procedure ml_add_table_script didnt help as long as the table ml_scripts_modified was empty, once the table is filled, then calling the procedure refreshes the table.
i.e. the trigger (if there is any) can only update the table but cant insert a new row.
There is no any visible trigger on this table:
select * from systriggers where tname = 'ml_scripts_modified'--> nothing
There should be a "ml_script_trigger" (among others) according to the syncsa.sql script in the \\MobiLink\\Setup directory...
The trigger is not a trigger on table ml_scripts_modified because that table isn't the one the trigger has to react upon - instead it is triggered by DML statements on table ml_script. (And there are similar triggers for ml_table_script and ml_connection_script).
Could it be that the table ml_scripts_modified was from the begining (since applying syncsa.sql) empty?
syncsa.sql adds a row to the table, and there is no code in MobiLink or any SQL Anywhere tool to delete the row.
Something that wasn't an SAP process deleted the row, but you would need to look back in the transaction log (if you still have them) to see when and what deleted the row. I can tell you that it happened at the same time that you started getting the message that the consolidated database had 0 digits of precision in the fractional second.
Reg
User | Count |
---|---|
50 | |
9 | |
8 | |
6 | |
5 | |
5 | |
5 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.