SQL Anywhere Feedback - MobiLink uploads

Author

MobiLink uploads

Brian Greiman

2005-06-21, 8:23 pm

It would be nice to be able to handle uploads from the remotes in the same
manner as dbremote. The remote database could read through transaction
logs, build SQL statements and then apply these directly against
consolidated server. This would save having to write upload_update,
upload_insert, upload_delete scripts as well as some conflict resolution.
The main difference is it sends SQL scripts instead of raw data.

I realize that this would not work if the schema was drastically different
on the consolidated from the remote (only if remote was a subset and column
names matched). Maybe have a option in the database or extended option to
turn on this functionality?

I still like the way downloads are handled via MobiLink.

Brian

Breck Carter [TeamSybase]

2005-06-21, 8:23 pm

There appear to be two aspects to your request; is one of them more
important than the other?

(a) not having to write the upload_etcetera scripts?

(b) having each row change uploaded separately, instead of uploading
the final version of each row?

I *think* (b) is available with the dbmlsync -tu option for
"transaction-level uploads".

Personally, I very much like the idea of (a), and there may be ways to
do it without (b). For example, having the opposite of download_cursor
scripts running on the remote to build the upload stream, and having
the opposite of dbmlsync running on the consolidated database to apply
the upload stream in the same manner: INSERT with ON EXISTING UPDATE.

.... also known as script-driven uploads, or peer-to-peer
synchronization :)

Breck

On 21 Jun 2005 13:02:14 -0700, "Brian Greiman" <bgreiman@bernicks.com>
wrote:

>It would be nice to be able to handle uploads from the remotes in the same
>manner as dbremote. The remote database could read through transaction
>logs, build SQL statements and then apply these directly against
>consolidated server. This would save having to write upload_update,
>upload_insert, upload_delete scripts as well as some conflict resolution.
>The main difference is it sends SQL scripts instead of raw data.
>
>I realize that this would not work if the schema was drastically different
>on the consolidated from the remote (only if remote was a subset and column
>names matched). Maybe have a option in the database or extended option to
>turn on this functionality?
>
>I still like the way downloads are handled via MobiLink.
>
>Brian
>

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

David Fishburn

2005-09-09, 9:25 am

"Brian Greiman" <bgreiman@bernicks.com> wrote in
news:42b8723f$1@foru
ms-2-dub of
sybase.public.sqlanywhere. product_futures_disc
ussion:

BG> It would be nice to be able to handle uploads from the remotes in the
BG> same manner as dbremote. The remote database could read through
BG> transaction logs, build SQL statements and then apply these directly
BG> against consolidated server.

We specifically moved away from sending SQL from the remote to the
consolidated with the MobiLink technology. It does not provide a
flexible enough architecture to handle all our customer's requirements.

By providing the raw data to each of these scripts, YOU can choose what
you want done with this change. For example, if an update is uploaded
to the MobiLink server, some customers turn that into:
1. an insert into a temporary table
2. call to a stored procedure
3. an action against an application server
4. There are many more that I have seen.

BG> This would save having to write upload_update, upload_insert,
BG> upload_delete scripts as well as some conflict resolution.

The scripts: upload_insert, upload_update, upload_delete all get
generated by the MobiLink server. My usual approach is to use
SendColumnNames=ON, and let MobiLink write all the scripts (for a given
script version) and then I modify the download event scripts. The
upload scripts I never really change, since the default behaviour is
usually right.

Conflict resolution is a different story. With the Jasper release we
are introducing conflict detection and resolution in the same manner as
SQL Remote does. In other words it is on a column basis, NOT a row
basis.

In SQL Remote you have to write a special type of trigger to handle the
conflict. These triggers of course do not exist in Oracle and Microsoft
SQL Server. I have posted some samples of alternate ways to deal with
conflict resolution here:
http://ianywhere.codexchange.sybase...ctDocumentList?
folderID=319&expandFolder=319&folderID=0
Choose the sample:
Conflict Resolution Without Temporary Tables
or

http://ianywhere.codexchange.sybase.../1138/ML_Confli
ct_Without_Temporary
_Tables.zip

--
David Fishburn
Certified ASA Developer Version 8
iAnywhere Solutions - Sybase
Professional Services
Please only post to the newsgroup
Please ALWAYS include version and MORE importantly BUILD number with
EACH post (dbeng9 -v).

EBFs and Maintenance Releases
http://downloads.sybase.com/swx/sdmain.stm

Developer Community / Whitepapers
http://www.ianywhere.com/developer

CaseXpress - to report bugs
http://casexpress.sybase.com

CodeXchange - Free samples
[url]http://ianywhere.codexchange.sybase.com/servlets/ ProjectDocumentList[
/url]

David Fishburn

2005-09-09, 9:25 am

"Breck Carter [TeamSybase]" < NOSPAM__bcarter@risi
ngroad.com> wrote in
news:16vgb1tjlts0vt0
qhang6ajim4uuftahvh@
4ax.com of
sybase.public.sqlanywhere. product_futures_disc
ussion:

....
BC> For example, having the opposite of download_cursor
BC> scripts running on the remote to build the upload stream, and having
BC> the opposite of dbmlsync running on the consolidated database to
apply
BC> the upload stream in the same manner: INSERT with ON EXISTING UPDATE.
BC>
BC> ... also known as script-driven uploads, or peer-to-peer
BC> synchronization :)

This is part of the Jasper release. You will have an option in an ASA
remote whether to:
1. use the current method (ie log scanning) to determine which rows get
uploaded.
or
2. use script based uploads where you write stored procedures to
determine which data is uploaded for each table in the remote.

Breck, it looks like you are finally getting more of your "wish" list.

--
David Fishburn
Certified ASA Developer Version 8
iAnywhere Solutions - Sybase
Professional Services
Please only post to the newsgroup
Please ALWAYS include version and MORE importantly BUILD number with
EACH post (dbeng9 -v).

EBFs and Maintenance Releases
http://downloads.sybase.com/swx/sdmain.stm

Developer Community / Whitepapers
http://www.ianywhere.com/developer

CaseXpress - to report bugs
http://casexpress.sybase.com

CodeXchange - Free samples
[url]http://ianywhere.codexchange.sybase.com/servlets/ ProjectDocumentList[
/url]

Breck Carter [TeamSybase]

2005-09-09, 11:23 am

On 9 Sep 2005 06:02:16 -0700, David Fishburn
<fishburn_spam@off.ianywhere.com> wrote:

>Breck, it looks like you are finally getting more of your "wish" list.

Techwave was a wonderful experience, lots of clapping and woohoo-ing
on my part :)

Just got the "accepted into beta" email, can the software itself be
far behind?

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