Retrieving and displaying records by non-indexed fields on Quick
screens
roger32909 at bellsouth.net
roger32909 at bellsouth.net
Tue Jul 19 13:37:03 CDT 2005
Thanks, Chris. This worked fine with default PATH & FIND procedures!
No need for (S)elect in the action field.
-----------------------------------------------------------------------
TEMP T-FROM-DATE DATE
TEMP T-TO-DATE DATE
TEMP T-INCOMPLETES CHAR*1 INITIAL "N"
;*****************************************************************
; FILES AND DATA
;*****************************************************************
FILE VOUCHERS PRIMARY OPEN READ OCCURS 15
ACCESS VIA VOUCHER-ID USING VOUCHER-ID & ;(01)
REQUEST VOUCHER-ID
ACCESS VIA CPART-CODE USING CPART-CODE & ;(02)
REQUEST CPART-CODE
ACCESS VIA DUE-DATE USING DUE-DATE & ;(03)
REQUEST DUE-DATE
ACCESS SEQUENTIAL & ;(04)
REQUEST T-INCOMPLETES
ACCESS SEQUENTIAL & ;(05)
REQUEST T-FROM-DATE, T-TO-DATE
SELECT IF &
( T-FROM-DATE = 0 AND T-INCOMPLETES = "N" ) & ;(01,02,03)
OR ( T-INCOMPLETES = "Y" AND COMPLETED NE "Y" ) & ;(04)
OR ( T-INCOMPLETES = "N" AND DUE-DATE >= T-FROM-DATE & ;(05)
AND DUE-DATE <= T-TO-DATE )
Roger
>
> From: Chris Sharman <chris.sharman at ccagroup.co.uk>
> Date: 2005/07/18 Mon PM 12:26:18 EDT
> To: roger32909 at bellsouth.net, PowerH List <powerh-l at lists.sowder.com>
> Subject: Re: [Maybe spam] Re: Re: Retrieving and displaying records by
> non-indexed fields on Quick screens
>
> roger32909 at bellsouth.net wrote:
> > Thanks, Chris, for your email. See my reply to Joe regarding (S)elect not suited for multiple fields on same line. We display some 15 records in a cluster.
>
> There's two selects: select statement and select procedure/verb, which
> are subtly different.
>
> I was thinking of something like:
>
> temp fromdate date
> temp todate date
> temp unindval
> file myfile...
> access index1
> access index2
> access index3
> access sequential request fromdate, todate
> access sequential request unindval
> access sequential
> select if (promptok of todate and mydate of myfile<=todate and mydate
> of myfile>fromdate) or (promptok of unindval and myval of
> myfile=unindval) or not (promptok of todate or promptok of unindval)
>
> If promptok isn't usable the path variable may be.
>
> Chris
> >>From: Chris Sharman <chris.sharman at ccagroup.co.uk>
> >>Date: 2005/07/18 Mon AM 04:18:03 EDT
> >>To: roger32909 at bellsouth.net
> >>Subject: Re: Retrieving and displaying records by non-indexed fields on Quick
> >> screens
> >>
> >>roger32909 at bellsouth.net wrote:
> >>
> >>>Restrictions: PH 7.10G on OpenVMS with no relational database, only RMS files. The project manager declined request for additional indexes.
> >>>
> >>>The requirement is to allow user to retrieve and display records by at least 5 fields. Three are indexed and can be handled by normal ACCESS statements with default PATHs & FINDs. But the fourth is a date range and the fifth is a non-indexed field.
> >>>The primary file will occur 15 times and the user may drill down by using a designer procedure 01 to run a screen displaying more details.
> >>>
> >>>This system already has 2 screens with multiple prompts and a convoluted SELECT statement, custom PATH & FIND procedures to handle screen displays of data retrieved on non-indexed fields. Of course there is no sort/order, but it works. A new screen is supposed to follow this pattern. But I wonder if there may be a simpler solution.
> >>>
> >>>For example, I have seen (and used) permanent indexed subfiles (re-filled by QTP or QUIZ) to sort & display records on QUICK screens retrieved on non-indexed fields. The tradeoff is a slight delay for the QTP/QUIZ run.
> >>>
> >>>I have not tried, but assume one could also declare several versions of the same file using aliases with ACCESS/SELECT statements and passing the retrieved data to occurring TEMPs for screen display.
> >>>
> >>>Would like to hear of other possible solutions to similar requirements.
> >>
> >>Joe's correct - select should enable you to do what you want, probably
> >>with minimal procedural code. See select, promptok, etc.
> >>
> >>But if this file is small, there's no good reason not to add the indices
> >>you want (ease of maintenance more important than performance).
> >>If it's not small, and you're doing significant volumes of non-indexed
> >>lookup, there's a good case for adding the indices you want to reduce
> >>the I/O load and improve response.
> >>
> >>Chris
> >>
> >
> >
> > --------------------------------------------------------------------------------
> > Date: Mon, 18 Jul 2005 11:26:21 -0400
> >
> > .
> >
>
>
More information about the powerh-l
mailing list