database trigger

Robert Edis robeconsult@sbcglobal.net
Wed, 27 Apr 2005 11:17:33 -0700 (PDT)


Viet

Database table triggers are tricky and sometimes
unpredictable.  They also represent "hidden" logic in
that future maintenance programmers may be unaware of
it when making changes to any code that touches that
table.  I would avoid triggers unless they were the
only option.

As Joe says doing the logic in a field process
procedure is probably the best way to acheive what you
want.

There are two other database options available to you
as well but either may require a re-fetch of the data
if SSNUMS is displayed on the PH form.  These are:

1. a stored procedure run from the PH form
2. a calculated (formula) column in the database

That latter can never be modified as it is only the
result of a calculation using other table columns.

Regards,

Blue


--- Joe Boyle <atla38@dsl.pipex.com> wrote:

> if you do an update stay, you would have to modify
> the PH code anyway
> because the trigger will alter the row contents and
> the checksum value for
> subsequent puts. You would then have to do another
> get to update the
> checksum. You might as well add process procedures
> on each of the two fields
> to handle the changes.
> 
> Regards, Joe.
> 
> 
> -----Original Message-----
> From: powerh-l-admin@lists.sowder.com
> [mailto:powerh-l-admin@lists.sowder.com] On Behalf
> Of Viet Nguyen
> Sent: 27 April 2005 14:46
> To: powerh-l@lists.sowder.com
> Subject: database trigger
> 
> Hi All,
>    I am migrating c-isam to oracle db and I have a
> question. 
>    1) I have a field SSNUMS which has a substructure
> SSNUMBER & STATUS.
>    To eliminate modification to power code I am
> thinking about using
> trigger table trigger that will UPDATE the higher
> structure SSNUMS when
> there is an update is done on SSNUMBER or STATUS.
> Could someone give me
> some advise on how powerhouse handles the update or
> how to create the
> trigger so that it doesn't recursively call on
> itself?
> Thanks.
> Viet.
> 
> 
> -----Original Message-----
> From: powerh-l-admin@lists.sowder.com
> [mailto:powerh-l-admin@lists.sowder.com] On Behalf
> Of Ken Langendock
> Sent: Friday, April 22, 2005 11:32 AM
> To: roger32909@bellsouth.net; Martin McDonough
> Cc: powerh-l@lists.sowder.com
> Subject: Re: RE: force a FIND?
> 
> Ok let me clarify this for you.
> 
> screen a
> 
> temp t-xyz-key char(??)
> 
> file XYZ primary
> access via xyz-key usign t_xyz-key 
> access via xyz-key request xyz-key
> 
> procedure x ; can be procedure entry/find/whatever
> begin
>   run screen b
>   push find ; invokes once this procedure ends
>   let t_xyz-key = xyz-key of XYZ
> end
> 
> procedure path
> begin
>  if " " ne t-xyz-key
>     then let path = 1
>     else prompt xyz-key
> end
> 
> procedure postfind
> let t_xyz-key = " " ; clear it out for next find
> 
> 
> 
> If you want more clarification....send me the screen
> code.
> 
> Ken
> 
> --- roger32909@bellsouth.net wrote:
> > Already tried PUSH FIND.  This still required user
> > intervention to Find the updated record.
> > 
> > REFRESH does not do a FIND.
> > 
> > The PRIMARY file XYZ record is NOT passed to the
> > called screen.
> > In the called screen, the file XYZ is a DESIGNER
> > file. 
> > 
> > Agree with you, Martin, but unfortunately the
> > subscreen is called from many other screens, so it
> > is not possible to pass the record.
> > 
> > > 
> > > From: "Martin McDonough"
> > <martin.mcdonough@rosebys.com>
> > > Date: 2005/04/22 Fri AM 10:17:25 EDT
> > > To: <roger32909@bellsouth.net>
> > > Subject: RE: force a FIND?
> > > 
> > > If possible, the correct way to do this would be
> > to pass the primary
> > > file 'XYZ' to the subscreen and display the
> field
> > from the 'passed' file
> > > on the subscreen.
> > > 
> > > By putting 'REFRESH' on the field statement of
> the
> > main screen, after
> > > the update is done in the subscreen and you
> return
> > to the main screen,
> > > the value will be automatically refreshed.
> > > 
> > > Regards
> > > 
> > > Martin McDonough
> > > 
> > > -----Original Message-----
> > > From: powerh-l-admin@lists.sowder.com
> > > [mailto:powerh-l-admin@lists.sowder.com] On
> Behalf
> > Of
> > > roger32909@bellsouth.net
> > > Sent: 22 April 2005 15:07
> > > To: powerh-l@lists.sowder.com
> > > Subject: force a FIND?
> > > 
> > > OpenVMS 7.3  PH 7.10.G1
> > > 
> > > We have an old screen that works this way:
> > > 
> > > The PRIMARY file in the main screen is XYZ.
> > > The user has the option of calling another
> screen.
> > > If the user goes to the subscreen, file XYZ is a
> > DESIGNER file in that
> > > screen and an XYZ field is updated.
> > > 
> > > But when the return is made to the original
> > calling screen, the original
> > > record is still displayed without the updated
> > field.
> > > 
> > > To be sure, the screen designer displays a
> message
> > telling the user that
> > > data has changed and to perform a(nother) FIND
> to
> > see the updated data.
> > > 
> > > Is there a way to perform this FIND for the user
> > so that when the RETURN
> > > is made, the updated data is displayed on the
> > screen without user
> > > intervention?
> > > 
> > > -- 
> > > 
> > > = = = = = = = = = = = = = = = = = = = = = = = =
> =
> > = = =
> > > Mailing list: powerh-l@lists.sowder.com
> > > Subscribe: "subscribe" in message body to
> > > powerh-l-request@lists.sowder.com
> > > Unsubscribe: "unsubscribe &lt;password&gt;" in
> > message body to
> > > powerh-l-request@lists.sowder.com
> > >
> http://lists.sowder.com/mailman/listinfo/powerh-l
> > > This list is closed, thus to post to the list
> you
> > must be a subscriber.
> > > 
> > > Disclaimer: 
> > > 
> > > This message contains information that may be
> > privileged or confidential and is intended only
> for
> > the person to whom it is addressed.
> > >  If you are not the intended recipient, you are
> > not authorized to read, print, retain, copy,
> > disseminate, distribute, or use this message or
> any
> > part of this message.
> > >  If you receive this message in error, please
> > notify the sender immediately by using the reply
> > option and delete all copies of this message.
> > > 
> > > Rosebys Operations Ltd.
> > > 
> > > WWW.ROSEBYS.COM
> > > 
> > > 
> > > 
> 
=== message truncated ===