Tim,

I have asked about this before, but cannot find it now where.

Having the equivalent of TDataSet.OnFilter for  Save Updates would be very very useful.
Every replication I am planning to do requires this.  I can see, that it would require to
extend the table definition, so it is probably a lot of work, but still, it would be
really really useful.

Regards,
Leslie



 

Leslie,

<< Having the equivalent of TDataSet.OnFilter for  Save Updates would be
very very useful. Every replication I am planning to do requires this.  I
can see, that it would require to extend the table definition, so it is
probably a lot of work, but still, it would be really really useful. >>

There's some issues with this that I still need to work out.  Updates are
saved in a time-ordered fashion so as to not cause any issues when loading.
IOW, if you insert a row, and then update it, EDB will load these updates in
the correct order.  When you start filtering the updates, you start to
disrupt the transaction history and it can cause issues.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

<<There's some issues with this that I still need to work out.  Updates are
saved in a time-ordered fashion so as to not cause any issues when loading.
IOW, if you insert a row, and then update it, EDB will load these updates in
the correct order.  When you start filtering the updates, you start to
disrupt the transaction history and it can cause issues.>>

What I had in mind is almost the same as the current SAVE UPDATES, not a flexible filtering.

Suppose it is possible to create an AllowSavingRowToStore(Storename: VARCHAR; AllowSave:
BOOLEAN ) trigger for every Table, which is fired for every ROW for every STORE during
SAVE UPDATES.

If the returned AllowSave is False the row is skipped for the store being processed. After
SAVE UPDATES  is finished, all changes are considered saved, later replication of the
skipped rows is not possible.

This sould be enough. With the use of such trigger it would be possible  to send only that
portion of the database to every user which they have right to work with. What do you
think?

Regards,
Leslie

Tim,

Having a the choice to allow fireing the same triggers during BackUp would be very useful
too. It would make easy to create the inital database for every user/user group. Everyone
gets only the data they have right to work with from the beginning, and it remains so with
the the later updates.   

Regards,
Leslie

Leslie,

<< If the returned AllowSave is False the row is skipped for the store being
processed. After SAVE UPDATES  is finished, all changes are considered
saved, later replication of the skipped rows is not possible.  >>

Ahh, that makes it much easier then.

<< This sould be enough. With the use of such trigger it would be possible
to send only that portion of the database to every user which they have
right to work with. What do you think? >>

Yes, but how would you do this if you're permanently skipping certain rows ?
Remember, SAVE UPDATES dumps all updates for the database (from the
specified tables) to the same update file, and then wipes out the updates
from the published tables.  I thought that you only wanted updates in the
update file that applied to a particular user ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Leslie,

<< Having a the choice to allow fireing the same triggers during BackUp
would be very useful too. It would make easy to create the inital database
for every user/user group. Everyone gets only the data they have right to
work with from the beginning, and it remains so with the the later updates.
>>

That's a little tougher.  While the replication works on a per-row basis,
the backups work on a raw basis in order to be as fast as possible.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

<< Yes, but how would you do this if you're permanently skipping certain rows ?
Remember, SAVE UPDATES dumps all updates for the database (from the
specified tables) to the same update file, and then wipes out the updates
from the published tables.  I thought that you only wanted updates in the
update file that applied to a particular user ?>>


What I suggested is to build as many update files as  there are stores, instead of
creating one and copy it to many stores.
Of course it means the engine needs to write(or skip) every row for every store itself,
which keeps the DB readonly much longer.  I guess this may be a problem when there are
many stores and/or many updates  to save, and  users are actively updating the database.
But more frequent saves should hopefully finish fast enough not to cause noticeable delay
for the users trying to updatie the DB.

Regards,
Leslie

Leslie,

<< What I suggested is to build as many update files as  there are stores,
instead of creating one and copy it to many stores. Of course it means the
engine needs to write(or skip) every row for every store itself,which keeps
the DB readonly much longer.  I guess this may be a problem when there are
many stores and/or many updates  to save, and  users are actively updating
the database.  But more frequent saves should hopefully finish fast enough
not to cause noticeable delay for the users trying to updatie the DB. >>

Hmm, I think I see where you're going with this.  I'll have to think about
it further.  It would be preferable for something like this to be
data-driven instead of SQL clause-driven due to the possible number of
target stores/filter criteria that would be necessary for the SAVE UPDATES
statement.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

<<Hmm, I think I see where you're going with this.  I'll have to think about
it further.  It would be preferable for something like this to be
data-driven instead of SQL clause-driven due to the possible number of
target stores/filter criteria that would be necessary for the SAVE UPDATES
statement.>

I thought supplying the store's name for the trigger should be enough information to
decide if a record should be saved into  given store.   But I am sure  you are taking into
account  more than I can think of.


Regards,
Leslie

Once again, I whish it was possible to edit the comment afer being posted. I know  I
should be more careful, yet ...  

Leslie