Tony,

<< Is it the case that when replicating updates from a main database to a
group of client databases, each client will receive an update file
containing all updates for all clients? And that each client will need to
load this all-inclusive update file into its database before somehow
removing the updates that are not relevant to the client? >>

Correct.  You can also just use BEFORE triggers to raise exceptions that are
then eaten by ERROR triggers, but that's a little convoluted.

<< If I've understood this correctly, then the ability to create individual
update files at the master database which are specifically tailored for each
client would be very handy. >>

Yes, the only issue is the current storage mechanism.

--
Tim Young
Elevate Software
www.elevatesoft.com

Leslie,

<< I suppose the actual writing to the change log file is triggered by
committing a transaction. Is it possible to apply a SQL based filter during
that procedure for the tables?  If yes, we could have a set of filters with
different change log files as target. So the PUBLISH command could have a an
extra INTO STORE  parameter and the every table could have a FilterCondition
parameter. This would mean we have more than one publish rule set so every
PUBLISHING  should  probably have a unique name for intended the recipients
too. >>

The store functionality probably won't work since right now the published
updates are logged in the database directory along with the normal table
files, but you do present an interesting solution.  There might be a way to
use separately-named update storage files for each, thus avoiding any issues
with fragmentation of the files.

<< If this is possible  it could be a very flexible solution, but with
linearly growing performance cost. The more log files there are, the slower
committing a transaction is. So it would probably be better to save a
complete change log first and process it in a lower priority thread where or
the other replication targets could be created during a simulated LOAD
UPDATES. >>

Possibly, although the update logging is usually quite small, so I'm not
particularly concerned with commit times.

<< If RecepientGroupName comes into the picture as a new system object, it
might be a logical extension to have a  detail system table with the URL of
the databases which should receive the updates. So at the and we could have
an easily configurable target list plus a  new command like >>

Updates files (the standalone .edbupd files, not the files used for storing
the published updates) are stored in stores, and transferred to and from
locations, by default, using local and remote stores.   So, there really
isn't any concept of a database with respect to these files.  However, one
can easily copy any given update file to numerous stores quite easily, and
one can even define a table in the database for storing information about
which stores get which update files.   Scheduling can be accomplished by
simply using a job to run such a script.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,


Glad I could help.

Do you think you will come up with a little more sophisticated replication in the near future?

Leslie   

Leslie,

<< Do you think you will come up with a little more sophisticated
replication in the near future?  >>

Sophisticated in what way ?  The only thing missing at this point is the
ability to filter the updates for the target database.  Other than that, you
can do any type of replication possible.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

I am tired, did not realize how my last post sounded. Sorry.  It's my English. Usually I can express what I want to, but occasionally I screw it
up. It was  filtering what I meant.

Leslie

Leslie,

<< I am tired, did not realize how my last post sounded. Sorry.  It's my
English. Usually I can express what I want to, but occasionally I screw it
up. It was  filtering what I meant. >>

No problem, I was just trying to clarify what you meant, and don't take
offense at all to suggestions for improvements.

--
Tim Young
Elevate Software
www.elevatesoft.com