RE: SQL Proc and Call Statment -- MIDRANGE-L

Instead of a monitor program, could you have the file A trigger write the
necessary info to a file/data area/data queue and then have a trigger on
file B read that info and send the email?

Richard

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of Desta, Wes
Sent: Wednesday, March 07, 2007 11:26 AM
To: public-midrange-l-Zwy7GipZuJhWk0Htik3J/w@xxxxxxxxxxxxxx
Subject: Re: SQL Proc and Call Statment




Trigger on file B wouldn't work because I'm comparing the before and
after image of a column value in File A. I guess I will have to use a
data queue to store the info and have a program monitor it.

Wes

"Richard Casey" <casey_r-XrYUcXHvavKNKE6diT/z+w@xxxxxxxxxxxxxxxx> wrote
in message
news:<MCEFIANIPCBBDNGNALGACEOKDKAA.casey_r@xxxxxxxxxxxxxxxx>...

Would it work to put the trigger on file B? The trigger could then

read the

new info from file A and send your email.

Richard


-----Original Message-----
From: midrange-l-bounces-Zwy7GipZuJhWk0Htik3J/w@xxxxxxxxxxxxxxxx
[mailto:midrange-l-bounces-Zwy7GipZuJhWk0Htik3J/w@xxxxxxxxxxxxxxxx]On

Behalf Of Desta, Wes

Sent: Wednesday, March 07, 2007 10:30 AM
To: public-midrange-l-Zwy7GipZuJhWk0Htik3J/w@xxxxxxxxxxxxxx
Subject: Re: SQL Proc and Call Statment

The problem is that the update/insert run sequentially in the same
thread thus when the trigger on File A is called, File B hasn't been
updated yet. I need the updated info in File B. I was hoping to run my
program in a different thread, and force it to wait for the File B
update.

<rob-tksaTn4SAz0AvxtiuMwx3w-XMD5yJDbdMReXY1tMh2IBg@xxxxxxxxxxxxxxxx>

wrote in message

news:<OFB5DEC9EB.2DBBE1CC-ON85257297.00530F5E-85257297.0053C4C0-tksaTn4S
Az0@xxxxxxxxxxxxxxxx

m>...

Why does file B cause an issue?

Do you fear that the fact that the trigger program may have a record

lock

and then update program may try to do something and conflict?

Remember,

the trigger runs sequentially.  Therefore it won't return to the

calling

program until it is completely done.

Do you fear that the calling program may already have a record lock

thus

conflicting with the trigger program?  If so, then having the

trigger

put

off the access to B to a data queue or anything may not buy you

anything

if don't free up the lock in the original program before the data

queue

processor tries to access B.

Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
PO Box 2000
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





"Wes"

<destaw-IYLBcaqmmjSwZA6j3JqgvUEOCMrvLtNR-XMD5yJDbdMReXY1tMh2IBg@xxxxxxxx
mane.org>

Sent by: midrange-l-bounces-Zwy7GipZuJhWk0Htik3J/w@xxxxxxxxxxxxxxxx
03/06/2007 05:58 PM
Please respond to
Midrange Systems Technical Discussion

<midrange-l-Zwy7GipZuJhWk0Htik3J/w@xxxxxxxxxxxxxxxx>



To
midrange-l-Zwy7GipZuJhWk0Htik3J/w@xxxxxxxxxxxxxxxx
cc

Fax to

Subject
SQL Proc and Call Statment






I'm working a program that will send an e-mail based on a insert

trigger

on
Table A. In the trigger, we also look up Table B. The problem is

that

Table
B is updated/inserted after Table A, and the update is running in

the

same


thread. I was thinking of creating  SQL proc (proc would sleep for 2
seconds) and call it from the trigger.
Is it possible to force the procedure to run in a different thread

(so

it's
not blocked by the sleep etc)?


--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.446 / Virus Database: 268.18.7/713 - Release Date: 3/7/2007
9:24 AM