Search results

Thank you all for your contributions. I have to conclude that my plan to change the trigger code "in mid flight" was simply flawed. I will have to move to a different method.

11.7.4 on Linux Hi DBAs, I'm testing an addition to the system that uses write and delete triggers on a selection of tables. The triggers exist on a Linux server and four AppServers. I was hoping to be able to "switch-on" the triggers at an exact moment. I thought of a few different ways...

Thank you Cecil and Tom. I believe you have confirmed my understanding. I just wanted to be sure there was no "good reason" to use c/s that I was not aware of.

I should have explained a bit better. Yes, of course, a local user must use a client/server connection for getting at an AppServer. The situation I'm dealing with is users who simply access a DB using a character-based application. Ron.

11.7.4 on Linux Hello DBAs, Over a long period working with Progress, systems I have worked on have used a very straight-forward "rule" -- local users connect via "direct connect" (ie via shared memory) -- and remote users use client/server connections. However, in the system I work with now...

OE 11.7.4 on Linux. As per best advice -- I have always set-up Storage Areas as Type 2 -- and appreciate the various reasons why Type 1 Areas should never be used (except of course for Area 6). However .... the system I look after is a package and like nearly all cases of using packaged...

Thank you Tom. I think what you have explained helps. I will pick my way through it and see if I can solve the problem. Ron.

Thank you Stefan -- I appreciate your help -- but it doesn't actually help. Tom and Dan have slides illustrating "strong" and "weak" scope -- but the slides are very simplistic. When I try to fit my logic around what they show I end-up in a mishmash that doesn't work. I will just have to play...

OE 11.7.4 on Linux. Although I've worked with Progress for a long time, I confess that my understanding of transactions and record scoping has many gaps. :confused: I have read (and re-read) presentations from Tom and Dan -- and I still have gaps. Here is a small test program: > cat...

Yes, Rob, I think there are a number of ways this can be addressed -- but the big 'relief' is that the cause of the problem has been found .. it was really bugging me. (I'm sure you can imagine.)

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...