× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.