Re: RE: embedded SQL Precompiler

["Mike Naughton" <mnaughton@xxxxxxxxxxxx>]

Joe -
I'll be really surprised if you haven't already thought of this, so maybe
I'm missing something basic, but I think this can actually be done fairly
easily.

First, it sounds as if the basic requirement is that the results of the
first "select" must stick around somewhere so that they can be available
for future selects. Why not just create a file in QTEMP, either by using
CRTPF (or CRTDUPOBJ), or directly with an SQL statement (I guess this
would be instead of creating a view, and I admit I'm not too clear on why
you might or might not want a view)? Once you have the file, your first
SQL select can insert into it (can't it?), and if the file is keyed on
customer number then listing all the customers and then going back and
retrieving the info is simple using either SQL or READs and CHAINs. (If
the file can't be keyed for some reason (?), then SQL would still work).

I guess a downside, performance-wise, might be the overhead of creating
the file in the first place -- some of the more adept programmers on the
list might suggest something fancier using a user space, maybe?

Seems simple enough to me (so I've _gotta_ be missing something. . . . )
rpg400-l@midrange.com writes:
>On the other hand, here's a feature that would be beyond either natigve
>I/O
>or the current state of SQL affairs: create a subset of records from an
>existing result set.  Now THAT would be nice.  Here's the business issue:
>
>1. Create a view of, say, invoices that were over 90 days, by customer and
>date
>2. Subselect out just the customer numbers from that set, showing them to
>the user
>3. Let the user pick a customer, and go back to the original result set
>and
>then subselect for just that customer


Mike Naughton
Senior Programmer/Analyst
Judd Wire, Inc.
124 Turnpike Road
Turners Falls, MA  01376
413-863-4357 x444
mnaughton@juddwire.com