Ken;
How do you pass things from the trigger to the background process?
We use the triggers to update (what is poorly described as) our OLAP type system. This makes some transactions pretty slow. This sounds like a pretty good way to speed things up.
P.S. I didnt design/code this thing - I just had to make it work - after it was sold and installed at a couple of client sites.
Thanks muchly
Colin Alfke
Product Development Manager
Vertical Technologies Inc.
#450, 800 - 6 Ave. S.W. Calgary T2P 3G3
P:(403) 237-7095 F:(403)237-7080
-----Original Message-----
From: Ken Wallis [mailto:kenws@empower.aust.com]
Sent: Friday, October 19, 2001 4:28 PM
To: u2-users@oliver.com
Subject: RE: copying U2 databases
> From: Klein Doyen T [mailto:Klein.DT@edreyfus.com]
> This is another thread like GOTO vs GOSUB. The techie types hate
> strong enforcement because it slows everything down and makes it
> more difficult to
> program.
Im a techie, but I like strong data typing. It helps me discover what Ive done wrong before I release it into general circulation. It has previously been established on this list that I dont conform to the norms for MV techies, so please dont anyone bother to tell me Im warped - I know already.
One thing I have found though is that unique constraints and referential integrity constraints in both Oracle and SQL Server can generate errors which are not always communicated properly across ODBC connections. Sometimes the only way to find out why your SQL is failing is to copy and paste it straight into isql/w or sqlplus.
and earlier he wrote:
> > You mean if you place a trigger in a file, there is no
> other way (Basic
> > program, editor etc) to prevent data from being added or
> changed? Its one
> > thing to say a trigger enforces it, but an entirely
> different thing to say
> > the database as a whole enforces it.
I have not yet found a way to subvert UniData triggers on files. Whether you update the records through BASIC, SQL, AE, VI, or COPY the trigger code still gets invoked. Consequently I try to keep my trigger logic as light as possible when using triggers for replication, and let a background process do the grunt work. If you were to use them for integrity checking the logic would have to be in-line, and you would take a performance hit. As a matter of interest, a client of mine once paid some very expensive Oracle consultants a lot of money to tell them that the most significant way they could improve the performance of their Oracle 8 database was to remove all the referential integrity and unique constraints from it and process that logic in the application. I think the words used were something like "its the only sensible way if you want to support a decent number of users".
Best Regards,
Ken Wallis
Empower Data Solutions Pty Limited
Blue Mountains, Sydney, Australia
Envision, enable, enhance, ... Empower
copying U2 databases
> From: alfkec@vertech.ca [mailto:alfkec@vertech.ca]
> How do you pass things from the trigger to the background process?
>
> We use the triggers to update (what is poorly described as) our OLAP
> type system. This makes some transactions pretty slow. This sounds
> like a pretty
> good way to speed things up.
From 5.x it gets easier because a trigger is then allowed to update another hashed file, so the trigger code simply pokes a record into a new file with a timestamp. That file is indexed, so a PHANTOM process can easily tell if there is new work to process and it pulls out the records and deals with them. All in all there is more code for the same transaction, but because the PHANTOM is just one process it runs in the background taking a known amount of resource and spreads the load out. For the 4.1 site where I have this running it was harder because I had to write a CALLC routine to be called from the trigger which would put a message on a message queue, and an ObjectCall based daemon process which would continually pull messages off queues and drop them into the indexed file.
HTH,
Ken Wallis
Empower Data Solutions Pty Limited
Blue Mountains, Sydney, Australia
Envision, enable, enhance, ... Empower
> -----Original Message-----
> From: Ken Wallis [mailto:kenws@empower.aust.com]
> I have not yet found a way to subvert UniData triggers on files.
> Whether you update the records through BASIC, SQL, AE, VI, or COPY
> the trigger code
> still gets invoked. Consequently I try to keep my trigger
> logic as light as
> possible when using triggers for replication, and let a
> background process do the grunt work.
> How do you pass things from the trigger to the background process?
>
> We use the triggers to update (what is poorly described as) our OLAP
> type system. This makes some transactions pretty slow. This sounds
> like a pretty
> good way to speed things up.
From 5.x it gets easier because a trigger is then allowed to update another hashed file, so the trigger code simply pokes a record into a new file with a timestamp. That file is indexed, so a PHANTOM process can easily tell if there is new work to process and it pulls out the records and deals with them. All in all there is more code for the same transaction, but because the PHANTOM is just one process it runs in the background taking a known amount of resource and spreads the load out. For the 4.1 site where I have this running it was harder because I had to write a CALLC routine to be called from the trigger which would put a message on a message queue, and an ObjectCall based daemon process which would continually pull messages off queues and drop them into the indexed file.
HTH,
Ken Wallis
Empower Data Solutions Pty Limited
Blue Mountains, Sydney, Australia
Envision, enable, enhance, ... Empower
> -----Original Message-----
> From: Ken Wallis [mailto:kenws@empower.aust.com]
> I have not yet found a way to subvert UniData triggers on files.
> Whether you update the records through BASIC, SQL, AE, VI, or COPY
> the trigger code
> still gets invoked. Consequently I try to keep my trigger
> logic as light as
> possible when using triggers for replication, and let a
> background process do the grunt work.