|
Home > Archive > SQL Anywhere Mobile > August 2005 > logfile question
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]
|
|
| R. van der Wiele 2005-08-29, 3:24 am |
| ASA 9.02.3137
Hi there, I have a question concening the logfile of a database and
Mobilink;
Does (can) Mobilink use(s) the logfile of a database to check what rows are
deleted, inserted, etc., So it can replicate the data to the other site
(server/client). (This is what I thought at first)
Or is it up to me (scripts) to determine what data gets
deleted/inserted/etc.?! (That's what I do now, and seems to work OK)
Regards, Ron van der Wiele
| |
| Greg Fenton 2005-08-29, 11:24 am |
| R. van der Wiele wrote:
> Does (can) Mobilink use(s) the logfile of a database to check what rows are
> deleted, inserted, etc., So it can replicate the data to the other site
> (server/client). (This is what I thought at first)
The MobiLink *server* does not use the transaction log in any way. This
is because ML supports more than just ASA as a consolidated, and the
vendors of those other consolidated RDBMS don't document their
transaction log formats.
The MobiLink *client* (dbmlsync) does use the transaction log since
dbmlsync only supports ASA remotes.
So indeed it is up to your scripts to determine which rows have changed
and to send the appropriate ones to the remotes. The only time I've
ever had to track the type of change is determining DELETEs in a
different way than INSERTs or UPDATEs (because a DELETE in the
consolidated would make the row disappear). Typically I track DELETEs
by recording them in a "shadow table" (alternatively you can use a flag
in the main table to indicate that the row is "deleted"...but this is
used less frequently).
The only other thing you typically need to do is to track the last time
that a row was changed in the consolidated. Typically we do this by
adding a "last_modified" column to each synchronized table *in the
consolidated*. For ASA consolidateds, this column is defined as:
last_modified TIMESTAMP DEFAULT TIMESTAMP.
For other consolidateds, you typically need to use a trigger to update
the timestamp when the row is modified.
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/
| |
| R. van der Wiele 2005-08-29, 11:24 am |
| Thanks Greg, now I know that the logfile is not actively used by Mobilink
during/for synchronization (had to know for sure :).
Btw. the lastmodified I did know :)
Thanks,
Regards, Ron
"Greg Fenton" <greg. fenton_NOSPAM_@ianyw
here.com> wrote in message
news:43132701$1@foru
ms-2-dub...
> R. van der Wiele wrote:
are[color=darkred]
>
> The MobiLink *server* does not use the transaction log in any way. This
> is because ML supports more than just ASA as a consolidated, and the
> vendors of those other consolidated RDBMS don't document their
> transaction log formats.
>
> The MobiLink *client* (dbmlsync) does use the transaction log since
> dbmlsync only supports ASA remotes.
>
> So indeed it is up to your scripts to determine which rows have changed
> and to send the appropriate ones to the remotes. The only time I've
> ever had to track the type of change is determining DELETEs in a
> different way than INSERTs or UPDATEs (because a DELETE in the
> consolidated would make the row disappear). Typically I track DELETEs
> by recording them in a "shadow table" (alternatively you can use a flag
> in the main table to indicate that the row is "deleted"...but this is
> used less frequently).
>
> The only other thing you typically need to do is to track the last time
> that a row was changed in the consolidated. Typically we do this by
> adding a "last_modified" column to each synchronized table *in the
> consolidated*. For ASA consolidateds, this column is defined as:
> last_modified TIMESTAMP DEFAULT TIMESTAMP.
>
> For other consolidateds, you typically need to use a trigger to update
> the timestamp when the row is modified.
>
> 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/
|
|
|
|
|