RE: SQL Proc and Call Statment

["Richard Casey" <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@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx]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@xxxxxxxxxxxxxxxx> wrote in message
news:<OFB5DEC9EB.2DBBE1CC-ON85257297.00530F5E-85257297.0053C4C0@xxxxxxxx
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@xxxxxxxxxxxxxxxx>
> 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