Search results

As I was explaining .... the replication system is working quite well -- except that it is slow. I checked the trigger code several times and could see no obvious reason for the problem. Each trigger deals with a different table, of course, but have exactly the same pattern. They: 1. Create...

Tom and Rob -- thank you, your help is always very valuable! I deleted the post because I realised that it was my mistake -- I saw the compiler messages warning that some code would never be executed (of course!) -- but forgot that the compile script would deliberately NOT replace the existing...

Removed.

(Sorry - I've removed this until I do some more investigating.)

Hi once again ... This project to replicate a particular set of tables is up-and-running. All works according to plan -- but the performance at peak times is "unspectacular". The problem is the trigger code. It was made to be as brief and uncomplicated as possible -- but I will have to...

Thank you Patrice -- that's good to know. When dealing with high-volume replication, saving any time is important. The version of OE is 11.7.4. Ron.

Fear not -- there were other instructions that I left out because I did want to distract from the main issue, which was the BUFFER-COPY. I was just surprised by this because I have not encountered anything similar before. Just something to be aware of in the future. :)

This is a comment, rather than a query, and it is probably a "Development" item, rather than "DBA" -- but it relates to this thread, so I put it here. Table "A" is being replicated withe a write-trigger. The trigger copies the record from "A" to table "X". The fields in table "X" are...

Thank you Tom!

Hello ! Can I ask a very basic question, please? At the time when a Replication-Write trigger executes it is my understanding that a transaction is open. Therefore the changed data may be captured but it should not be taken as "committed" until (at least) it is subsequently discovered that...

Ah, yes, good point! :) As you say, Tom, testing for _Trans existing is unnecessary. If the pointer record can be obtained with EXCL lock the original transaction must have ended with a commitment. Sometimes the obvious is not obvious.

Yes it is a separate process -- but it accesses the pointer record with EXCL lock before taking the transaction# and seeing if the _Trans record exists. Since the pointer record was created as part of the trigger execution it is encumbered by the original transaction. If an undo occurred the...

I don't think that's correct, Tom. If the user says "no" it initiates a roll-back. But the record that the "chaser" program holds is in the same transaction so it cannot "see" that the _Trans record is no longer present because the current pointer record is encumbered by the same transaction...

Yes -- but ... Using the example I mentioned: "If a process local to the server updates the DB a repl trigger executes. Details of the update go into a table A that only holds "in abeyance" data. A separate record is created in table B holding the transaction# and a rowid pointer to the record...

I don't understand the problem. If the _Trans record for this transaction is available the current record is skipped. The only way I could envision a problem is for the _Trans record to be "wrongly not available" -- and I can't see how that could happen. The need for a table scan on _Trans is...

Thank you Tom -- I think you have clarified the situation. If a roll-back occurs the "A" and "B" records I mentioned will get undone -- so the absence of a _Trans record for the transaction is sufficient to believe that the update has been committed. Therefore, it appears that the triggers...

In summary, Tom, I believe you are saying that getting the current transaction# and later testing for its existence in _Trans will not work when the update is caused by a remote connection. I don't really understand why that is so -- but I do appreciate that being able to re-access the record...

CDC was considered at length but it caused problems for us that I won't expand on here. If a process local to the server updates the DB a repl trigger executes. Details of the update go into a table A that only holds "in abeyance" data. A separate record is created in table B holding the...

Thank you Tom -- but I'm still not clear about this. On the Linux server where the DB resides the replication trigger captures details about the update and uses DBTASKID to get the current transaction#. Another process checks these "in abeyance" details and tests _Trans to see if the...

Thank you Tom -- but are you saying that the client cannot discover the current transaction ID? If a replication trigger executes on the client -- how can one know that the current transaction is completed and therefore operation is committed? Ron.