Triggers to Comeup everytime to update User defined fields

[Chris Kelleher]

Hi Qad Users:


QAD 8.6D
Char mode Unix
Progress 8.2C

I am trying to update the USER DEFINED FIELDS in the customer
maintenance (2.1.1) but the problem I am coming across is that
the triggers does not get executed everytime. It just gets executed
only when I update the sort field (because of ASSIGN OF
CM_MSTR.CM_SORT). I have just chosen cm_sort field at random.

Sometimes user just comes into the existing customer record and just F1
thrus it and this trigger never fires up.

>>> What I need is to pop up this screen everytime, even if user does
not update any fields to a already existing customer.

what can I do to resolve it. I have also tried to put the WRITE trigger
at the Database Schema for cm_mstr but same results.

SAMPLE of the CODE:

<BLOCKQUOTE><font size="1" face="Arial, Verdana">code:</font><HR><pre>
/* Begin of xxadcsmt.p (wrapper program) */

on assign of cm_mstr.cm_sort OLD VALUE old_addr
do:
update
cm_mstr.cm__chr01 validate({gpcode.v cm__chr01},
"Invalid Customer Classification")
colon 30 label "Customer Classification"
cm_mstr.cm__chr03 colon 30 label "Training Location" format
"x(25)"
cm_mstr.cm__dte01 colon 30 label "Customer Training Date"
with overlay frame x_cust_frame centered side-labels
title "CAUTION: **** Custom Fields for Customer Master ****
" row 10.
end.
{gprun.i ""adcsmt.p""}

/* End of xxadcsmt.p */
[/code]

I will appreciate any help.

Thank you

--
Praveen Chopra

 

[Chris Kelleher]

Praveen,

I believe the problem you're facing is that the trigger only fires if an
assign takes place. If you F1 through the screen and do not change
anything, I believe Progress recognizes that and does not do any assigns.
Ergo, no database event for the trigger to fire.

You could link the event to a find instead, but you'll see it hit a lot
more often, and not necessarily when you want.

I believe that coding will be your solution, but others may have easier
ideas.

Good luck.

Scott
===============================================================
Scott M. Dulecki /* 1998061901 */ +1 616 975 6322
Product Manager scott_dulecki@qad.com
QAD, Inc. http://www.qad.com
1188 East Paris SE Grand Rapids, MI 49546 USA

Next Michigan Progress Users Group: 17 November 1999

All opinions are my own, and don't necessarily reflect those of
any other living being.
===============================================================

 

[Chris Kelleher]

Hi Scott:

You are absosultely right about ASSIGN event not to fire. I had also tried
to link the FIND event to
sp_mstr, fr_mstr and even aud_det (as I knew there are some of the files
which get hit in the middle of the customer maintenance program but no screen
comes up)


I tried it this way

ON find of sp_mstr do: /* tried it with fr_mstr and aud_det also*/


<<same code as before>>

end.

Thanks .

praveen

 

[Chris Kelleher]

What I've found is that you have to fire on leaving the frame. Trick
is, since you're in a trigger procedure and not the proc itself, you
don't have access to the frame. Other trick is, you need acces to the
record as well. The following is a pseudo-code of what has worked
reasonably well for us:

<BLOCKQUOTE><font size="1" face="Arial, Verdana">code:</font><HR><pre>
on find of record
grab the recid.
on create of record
grab the recid.
on go anywhere
do:
/* YES, program-name(2), cuz program-name(1) is the trigger proc */
if program-name(2) is the program we want and
frame-name is the frame we want then
do:
find record using recid we grabbed above.
if avail(record) then
update userfields.
end.
end.
{gprun.i standard update proc}
[/code]

HTH,
---------------
Paul T. O'Leary
Evco Plastics, a leader in plastics injection molding
DeForest, WI USA