| > I have a customer who has a question about to purge RDB$CHANGES. He
> has 50 transfers, and some of them are executed once by semester. I've saw
> note 166 and told him about this kind of transfer, but he doesn't accept the
> suggestion to execute all transfers. He would like to know the possibility
> to delete rows in RDB$CHANGES manually (without executing transfers).
The problem with doing selective deletion is how to tell which rows are no
longer needed by any transfers. The rows are not marked in the RDB$CHANGES
table as to which transfers need them. For example, you can have 10 transfers
all replicating the same set of rows, each transfer to a different target table.
In such case, only one row is stored in the RDB$CHANGES table, not 10, for each
source row. Therefore, we can't discard a row from RDB$CHANGES until all of
the transfers have had a chance to process that row. For this reason, the
purging process only deletes rows associated with transfers whose TSER number
is less than some cutoff value (see note 166 for some discussion there).
What is the reason your customer cannot run these transfers more often
than once per semester?
Claude
|
| Hi Claude,
Thanks a lot for your help (again).
> What is the reason your customer cannot run these transfers more often
> than once per semester?
My customer has some information which are updated almost once per semester,
and he has made a procedure which runs the transfer when the record is
updated (without schedule). He thought that could save some cpu time,
dio...
Anyway, I told him about ROR behave and he is going to redefine the schedules,
and run all transfers. Thanks God :-).
Pedro.
|