FW: Problem in screen design

[Peter Bateman]

From: peterbateman808 at hotmail.com
To: jnalder at ascprofiles.com
Subject: RE: Problem in screen design
Date: Thu, 18 Mar 2010 14:20:05 -0300








Hi Jay:

   An error in the FIND sequence goes back to the next primary record if there is one otherwise back to the action field

Regards,
Peter
From: JNalder at ascprofiles.com
To: peterbateman808 at hotmail.com
Date: Wed, 17 Mar 2010 16:28:40 -0700
Subject: RE: Problem in screen design













OK, but can you get additional records based on non-matching records?
 
I wanted the FIND to retrieve multiple records (as in get sequential).
I did not expect the failed get to produce an error condition, but to cycle through and .merely try to get the next record.
 
 
Jay Nalder.

 


From: Peter Bateman [mailto:peterbateman808 at hotmail.com]


Sent: Wednesday, March 17, 2010 4:23 PM

To: Nalder, Jay

Cc: PowerHouse List

Subject: RE: Problem in screen design


 
Hi Jay:



   My idea is the reverse of the technique where you remove the optional

   from the get of the secondary to display only those primary records which have a


   corresponding secondary file. A failed get on a non optional secondary should raise an


   error condition.



From:- http://public.dhe.ibm.com/software/data/cognos/documentation

          /docs/en/powerhouse/8.4g/QD.pdf



   "Error Handling in the FIND Procedure

   If an error occurs during the execution of this procedure, 

   QUICK backs up to the last GET verb for the PRIMARY file. 

   If no such verb exists, QUICK prompts the screen user in the Action field,

   without displaying any retrieved data."



If QUICK is working as described in the manual then I think my technique should

work.



Regards,

Peter



From: JNalder at ascprofiles.com

To: peterbateman808 at hotmail.com; pandurang.rajpurohit at in.ibm.com

CC: powerh-l at lists.sowder.com; powerh-l-bounces+pandurang.rajpurohit=in.ibm.com at lists.sowder.com; vidyasagar.goparaju at kewill.com

Date: Wed, 17 Mar 2010 11:34:40 -0700

Subject: RE: Problem in screen design

I think that your FIND procedure won’t quite work as desired.
-         
The error condition won’t let you find the ‘next record’
 
Here is an extension on your idea:
screen test
 
file apmisumi primary
 
file apmisumi designer alias xpart open 2
   access via doc-char using doc-char of apmisumi optional
   select if gm-part of xpart = "    12844161"
 
file apmisumi designer alias xdup  open 3
   access via apmisumi-key using apmisumi-key of apmisumi
 
FIELD DOC-CHAR    OF APMISUMI REQUIRED NOCHANGE
FIELD SOURCE-CODE OF APMISUMI REQUIRED NOCHANGE
FIELD GM-PART     OF APMISUMI REQUIRED NOCHANGE
FIELD DOC-TYPE    OF APMISUMI
FIELD ORD-NUM     OF APMISUMI
FIELD ORD-PART    OF APMISUMI
 
PROCEDURE FIND
  BEGIN
    while 3 = 3
    begin
      IF PATH = 1
        THEN GET APMISUMI VIA APMISUMI-KEY
      IF PATH = 2
        THEN GET APMISUMI VIA DOC-CHAR
      IF PATH = 3
        THEN GET APMISUMI SEQUENTIAL
      if not accessok    ;if we fail to get the next primary record then exit on failed condition
      then break
      get xpart optional ;we have a primary record.  do we find a matching record (same DOC-CHAR and GM-PART=12844161)?
      if newrecord of xpart
      then break         

      end
    end
  END
BUILD
 
The FIND procedure is couched in an ‘infinite loop’
You exit the loop when the primary find fails or
when the primary find succeeds and the [bad_part] find fails
 
in the case where the primary find succeeds and the [bad_part] find also succeeds then it simply loops on the 3=3 condition.
 
 
 
 y in touch. Get Messenger on your phone now. 		 	   		  
_________________________________________________________________
Check your Hotmail from your phone. 
http://go.microsoft.com/?linkid=9712957
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sowder.com/pipermail/powerh-l/attachments/20100318/d8952eb3/attachment.htm