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


-- 
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email:

MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/w@xxxxxxxxxxxxxxxx

To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/w@xxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.