SQL Anywhere Mobile - mobilink general working

Author

mobilink general working

Eric Verhorstert

2005-06-07, 11:24 am

I have read the mobilink help but still do not understand how it works.
I would appreciate if someone could help me with these questions in the
situation we upload the consolidated database from a desktop remote
database.

1. dbmlsync is the program which creates the upload stream?

2. to create the upload stream the information send to the consolidated
database is taken from the log file and not from the db file.

3. because the data comes from the log file the sync software knows
which records are deleted at the remote database.

Is this correct?

Thanks

Eric

Nick Elson

2005-06-07, 1:24 pm

There are two types of remotes with Mobilink Sychronization,
ASA databases and UltraLite applications (and their databases).

> 1. dbmlsync is the program which creates the upload stream?

Yes. It also receives the download stream and applies that as well.

dbmlsync is only used with ASA databases. UltraLite's run time
libraries do synchronization through a different mechanism.

> 2. to create the upload stream the information send to the
> consolidated database is taken from the log file and not from the db file.

Correct. The log is scanned and converted in memory before uploading.

> 3. because the data comes from the log file the sync software knows
> which records are deleted at the remote database.

That is a (small) part of it, but UltraLite synchronization also knows
about any deletions that have occurred.

As asked, I am not certain what may be concerning you
about those deletes.

"Eric Verhorstert" <eric.verhorstert@farm.nl> wrote in message
news:42a5cee6$1@foru
ms-2-dub...
>I have read the mobilink help but still do not understand how it works. I
>would appreciate if someone could help me with these questions in the
>situation we upload the consolidated database from a desktop remote
>database.
>
> 1. dbmlsync is the program which creates the upload stream?
>
> 2. to create the upload stream the information send to the consolidated
> database is taken from the log file and not from the db file.
>
> 3. because the data comes from the log file the sync software knows which
> records are deleted at the remote database.
>
> Is this correct?
>
> Thanks
>
> Eric

Eric Verhorstert

2005-06-08, 3:24 am

I printed and read the help file. The part "How the upload stream is
processed" then "Procossing deletes after inserts and updates" is confusing.

Here I understand that the order in which the update stream is processed
is not the same in which the information is in the log file.

Text in the help file is:
"The upload stream is formatted so all operations for a single table are
grouped together" and "deletes are applied after all inserts and
updates have been applied".

This is what I understand:
In our application we delete a record, do a commit and then insert a new
one and do a commit. This record has the same promary key as the one we
deleted. In the upload stream first the new insert is done (this is
probably not possible because the primary key already exists) and then
the delete is done. So, after synchronisation I am missing a record.

Is this correct?

Thanks
Eric

Nick Elson wrote:
> There are two types of remotes with Mobilink Sychronization,
> ASA databases and UltraLite applications (and their databases).
>
>
>
>
> Yes. It also receives the download stream and applies that as well.
>
> dbmlsync is only used with ASA databases. UltraLite's run time
> libraries do synchronization through a different mechanism.
>
>
>
>
> Correct. The log is scanned and converted in memory before uploading.
>
>
>
>
> That is a (small) part of it, but UltraLite synchronization also knows
> about any deletions that have occurred.
>
> As asked, I am not certain what may be concerning you
> about those deletes.
>
> "Eric Verhorstert" <eric.verhorstert@farm.nl> wrote in message
> news:42a5cee6$1@foru
ms-2-dub...
>
>
>
>

Breck Carter [TeamSybase]

2005-06-08, 7:24 am

The MobiLink client dbmlsync merges all changes made to a row since
the last synchronization into a single "final version" of the row. So,
a delete followed by an insert will be uploaded as an insert.

FYI: Rows are identified by primary key value, so take care not to
update the primary key value of any row on the remote.

Also, the foreign key structure on the *remote* database is used to
control the order in which uploaded changes are applied on the
*consolidated* database. In other words, parent table rows are
inserted before child rows, and the opposite order is used for
deletes.

Breck

On 7 Jun 2005 23:13:59 -0700, Eric Verhorstert
<eric.verhorstert@farm.nl> wrote:
[color=darkred]
>I printed and read the help file. The part "How the upload stream is
>processed" then "Procossing deletes after inserts and updates" is confusing.
>
>Here I understand that the order in which the update stream is processed
>is not the same in which the information is in the log file.
>
>Text in the help file is:
>"The upload stream is formatted so all operations for a single table are
>grouped together" and "deletes are applied after all inserts and
>updates have been applied".
>
>This is what I understand:
>In our application we delete a record, do a commit and then insert a new
>one and do a commit. This record has the same promary key as the one we
>deleted. In the upload stream first the new insert is done (this is
>probably not possible because the primary key already exists) and then
>the delete is done. So, after synchronisation I am missing a record.
>
>Is this correct?
>
>Thanks
>Eric
>
>Nick Elson wrote:

--
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

Eric Verhorstert

2005-06-08, 7:24 am

Primary keys are never updated in our program. I am glad we did not
develop that.

But if a delete, followed by an insert is uploaded as an insert then we
probably should check if the primary key exists and then update the
record instead of insert.

Is that the way to handle?

Thanks,

Eric

Breck Carter [TeamSybase] wrote:
> The MobiLink client dbmlsync merges all changes made to a row since
> the last synchronization into a single "final version" of the row. So,
> a delete followed by an insert will be uploaded as an insert.
>
> FYI: Rows are identified by primary key value, so take care not to
> update the primary key value of any row on the remote.
>
> Also, the foreign key structure on the *remote* database is used to
> control the order in which uploaded changes are applied on the
> *consolidated* database. In other words, parent table rows are
> inserted before child rows, and the opposite order is used for
> deletes.
>
> Breck
>
>
> On 7 Jun 2005 23:13:59 -0700, Eric Verhorstert
> <eric.verhorstert@farm.nl> wrote:
>
>
>
> --
> 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-06-08, 9:24 am

OOOPS! I should have written this:

a delete followed by an insert will be uploaded as an update

Sorry for the confusion.

Breck Apparently Needs More Sleep

On 8 Jun 2005 05:05:14 -0700, Eric Verhorstert
<eric.verhorstert@farm.nl> wrote:
[color=darkred]
>Primary keys are never updated in our program. I am glad we did not
>develop that.
>
>But if a delete, followed by an insert is uploaded as an insert then we
>probably should check if the primary key exists and then update the
>record instead of insert.
>
>Is that the way to handle?
>
>Thanks,
>
>Eric
>
>Breck Carter [TeamSybase] wrote:

--
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

Shuchit

2005-06-08, 9:24 am

Eric Verhorstert <eric.verhorstert@farm.nl> wrote in news:42a68ca7@forums
-1-
dub:

> This is what I understand:
> In our application we delete a record, do a commit and then insert a new
> one and do a commit. This record has the same promary key as the one we
> deleted. In the upload stream first the new insert is done (this is
> probably not possible because the primary key already exists) and then
> the delete is done. So, after synchronisation I am missing a record.
>
> Is this correct?
>

No. A delete followed by an insert with the same primary key should be
uploaded as an update operation by MobiLink.

Shuchit

Nick Elson

2005-06-08, 9:24 am

Reusing primary keys can be a source of confusion and complexity
and is also a practice you may want to design out as well.

There may be good reason in the application logic to allow this
to occur, but too often designers reuse keys because of artificial
criteria that should not be modeled in the database.

Often it is also an indication of a bad design decision. Take the
standard example of the case where part numbers are reused for
different parts or even just newer models of the same part. Instantly
you have lost control over your inventory [Do I have 12 pieces of the
old part? Or 12 pieces of the new part? Or do I have N pieces of one
and 12-N pieces of the other???] and may ship the wrong part to
the customer.

"Eric Verhorstert" <eric.verhorstert@farm.nl> wrote in message
news:42a68ca7@forums
-1-dub...[color=darkred]
>I printed and read the help file. The part "How the upload stream is
>processed" then "Procossing deletes after inserts and updates" is
>confusing.
>
> Here I understand that the order in which the update stream is processed
> is not the same in which the information is in the log file.
>
> Text in the help file is:
> "The upload stream is formatted so all operations for a single table are
> grouped together" and "deletes are applied after all inserts and updates
> have been applied".
>
> This is what I understand:
> In our application we delete a record, do a commit and then insert a new
> one and do a commit. This record has the same promary key as the one we
> deleted. In the upload stream first the new insert is done (this is
> probably not possible because the primary key already exists) and then the
> delete is done. So, after synchronisation I am missing a record.
>
> Is this correct?
>
> Thanks
> Eric
>
> Nick Elson wrote:

Sponsored Links