Re: Synch publications separately, subscribe on child table

[Unknown]

While that is something that is easy to do with Mobilink
from the remotes (using dbmlsync -p and related ultralite features),
it is not a feature of dbremote.

SQL Remote does not track publication by offset whereas
Mobilink does (one of the earliest defining feature of ML, in fact).

<Jo...@isr.umich.edu> wrote in message
news:4b0006ff....@forums.sybase.com...
>I have 2 questions for replication, using SQLAnywhere 11:
>
> 1. Can I create multiple publications for one remote database that can
> be synchronized independently?
> What I need is to be able to synch on a priority basis. The data in
> table set X is more important and needs to be updated on a more
> frequent basis than the data in table set Y. Table set Y will contain
> large binary objects that are needed at the remote db at a lower
> priority and will take longer to download than table set X.
>
>
> 2. Can I create a publication that will replicate based off of a child
> table, allowing the key linked rows in the parent table to reside on
> more than one remote database, i.e. subscriber is defined on the child
> table?
>
> Table A Def:
> ------------
> Table_A_Id int PK
> SomeData1
> SomeData2
>
>
> Table B def:
> ------------
> Table_A_Id int PK FK
> Table_B_Id int PK
> SomeData1
> SomeData2
> SubscriberId varchar(20)
>

[Volker Barth]

Jody,

to your second question:

I don't know if I understand you correct, but you can use the SUBSCRIBE
BY filter to define a join condition in a publication, i.e. something like

create publication PUB_Test (
...
table A subscribe by
(select B.SubscriberId from B where A.Table_A_Id = B.Table_A_Id),
...
);

If you then create a subscription for a remote for a user with a
particular SubscriberId, then she will get all according rows from A
based on the value in B.

HTH
Volker

[Breck Carter [TeamSybase]]

SQL Remote is easier to use than MobiLink if your requirements are
simple. However, as your requirements become more complex, SQL Remote
rapidly moves towards "virtually impossible to use"... and you have
started along that path. When Volker mentioned SUBSCRIBE BY clauses
with subqueries, my blood ran cold... yes, you can do it...

Breck Wonders If "Hinting" Includes Jumping Up And Down And Shouting

PS In case it helps, if the blobs aren't updated they won't be
downloaded because SQL Remote sends updates, not the whole row.

--
Breck Carter - Blog: http://sqlanywhere.blogspot.com/

SQLA questions and answers: http://sqla.stackexchange.com

RisingRoad helps SQL Anywhere developers make better databases
http://www.risingroad.com/
Breck.Carter at gmail

[Volker Barth]

Breck Carter [TeamSybase] wrote:
> SQL Remote is easier to use than MobiLink if your requirements are
> simple. However, as your requirements become more complex, SQL Remote
> rapidly moves towards "virtually impossible to use"... and you have
> started along that path. When Volker mentioned SUBSCRIBE BY clauses
> with subqueries, my blood ran cold... yes, you can do it...
>
> Breck Wonders If "Hinting" Includes Jumping Up And Down And Shouting
>
> PS In case it helps, if the blobs aren't updated they won't be
> downloaded because SQL Remote sends updates, not the whole row.
>

IMHO, as long as only a few tables are involved and "subscribe by with
subqueries" doesn't lead to several join-levels (though that works,
too), this is not near "impossible".

MobiLink has its own trade-offs, and the fact that the whole row is sent
as an update is one: You will typically have to "outsource" BLOBs in
their own table when they are modified less often than other fields of
the same original table.

"It depends", they say:)

Volker Still Prefers SQL Remote...

[Jo...@isr.umich.edu]

On 15 Nov 2009 05:56:14 -0800, Jo...@isr.umich.edu wrote:

Thanks for all the comments. This is basically of what I expected to
hear. We currently use ASA6 with Sql Remore (on a different system)
and I wanted to be sure I didn't miss something that was new in
SQLA11.