[Maybe spam] Re: Re: Retrieving and displaying records by non-indexed fields on Quick screens

[Chris Sharman]

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
> 
> .
>