Re: SQL*Forms 3.0 - trigger advice needed

Steve Frampton (frampton_at_mail.flarc.edu.on.ca) wrote:
: Hello!
 

: I'm developing a 2-page form as part of my organization's employee
: absence project. The form allows reconcilation of recorded absences with
: paper absence request forms.
 

: The first screen provides a list of outstanding absences requiring
: reconciliation with paper forms. Each record is displayed, with a "Form
: Recvd?" field which the user marks "Y" if a matching paper form is
: available.
 

: The second screen allows raw data modification of absence records (since
: during the reconciliation process, a lot of data entry errors are
: detected). From here, you can query any record in the database, and
: change any field.
 

: What I would like to accomplish is an automatic first query when you move
: from screen #1 to screen #2 (since presumably, you are going there
: because of an error you found with the data on screen #1). So if I am
: looking at Joe Smith's absence for June 10, I want it to automatically be
: loaded into screen #2 when I go there.
 

: This is *not* setup as a master-detail block relationship, nor do I want
: it to. From the second screen, I want to be able to query and modify any
: record in the database. Only the first query should assume I am looking
: at the same record as in screen #1.
 

: Ideally, this automatic load should be triggered with the "KEY-NXTBLK"
: from screen #1. Then it's guaranteed to be executed one time only.
: However, I haven't been able to get it to work.
 

: Actually...I did think of a stupid way. The "KEY-NXTBLK" trigger would
: fill the fields of a dummy block that doesn't get displayed. The
: "PRE-QUERY" trigger of screen #2 would load values from the dummy block,
: and then clear out the dummy block afterward, thus guaranteeing it only
: happens once.

I don't think this solution is stupid at all since you have to deliver screen #2 its search criteria either from a PRE-QUERY trigger, a where clause in the screen #2 block or ENFORCE_KEY_FROM attributes in screen #2 fields. Those criteria must be SQL*Forms field variables - not globals. You might consider using control fields in your screen #1 block with values copied from the appropiate database fields as the first event in your KEY-NXTBLK trigger and then deleted as the last event. Then you could reference these control field in your screen #2 through ENFORCE_KEY_FROM attributes.

: Is there a better way to accomplish this? By the way, another thing I
: would like is the ability to change the record on screen #1 if any
: changes were made to the same record on screen #2. Currently I've got to
: re-query the records.
 

: Any advice would be appreciated.
 

: ----------------< LINUX: The choice of a GNU generation. >-----------------
: Steve Frampton, Computer Services Operator <frampton_at_mail.flarc.edu.on.ca>
: Frontenac-Lennox & Addington County RCSSB Kingston, Ontario CANADA

--
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+   Christian Mondrup                                                      +
+   Scandiatransplant, Skejby Hospital, University Hospital of Aarhus      +
+   Brendstrupgaardsvej                                                    +
+                                                                          +
+   Phone:   +49 89 49 53 01                                               +
+   Telefax: +45 89 49 60 07                                               +
+   E-Mail:  scancm_at_biobase.dk                                             +
+                                                                          +
+   Opinions expressed are mine and do not reflect those of my employer.   +
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++