selection for report without selection table

[Bruce Easton]

(inline reponses -Bruce - STN, Inc.)

Mark wrote Thursday, July 24, 2008 12:44 PM:
>
> You'll never BELIEVE what Bruce Easton said here...:
> > Mark wrote Thursday, July 24, 2008 11:53 AM:
> > >
> > > Hi All,
> > >
> > > I need a pointer.  There's a report someone did that relies on a
> > > processing
> > > table that uses SELECT.
> > >
> > > I need to issue this report, complete with the grand total
> section, etc.,
> > > but from inside a dreport session that's running on another table
> > > entirely.
> > > I need to basically do it all via lookups or whatnot.
> > >
> > > I -could- do it via a separate process, but -not- as a system
> call, and I
> > > need to get the selection data to any process without using selection
> > > tables to issue the selections, since it can't be run interactively.
> > >
> > > If I have a weak spot in fP, it's printing, mostly because I've rarely
> > > needed it.  Hence...Help???  :)
> > >
> > > TIA,
> > >
> > > mark->
> > > --
> > > Fairlight->
> > > Consulting
> >
> > Mark - above where you say 'selection tables' (3rd paragraph) -
> > are you thinking selection sets or selection processing?
> > Either way, both can be used non-interactively.  Also, I'm
> > curious - why does it have to run from another table?
>
> Based on what I've seen, a selection processing table is in place
> that asks
> for data for range limiting on dates, etc.

As per my last response, you can substitute interactive input with
hard-coding or with values supplied via -r+ at pm, etc. as necessary.

>
> You know my personal model of doing web-based work from a central control
> file, as I've shown you how I do it.  I need to marry that to conventional
> printing without altering the command line or invoking another concurrent
> licensed process (5,0.14--any system call to another eats a license
> seat, and no we can't upgrade).
>
> So how would you do it in OG from a control file? :) I've done something
> with FORM once or twice, but the original code wasn't mine.  Would that
> work, if I switch to dclerk as I did for those instances?

You should be able to use FORM and FORMM to print from the
same clerk session that you are using as a control session, but
then you would need to replace the selection with a lookups and
loop control structure and then make your own pieces of the original
form (header piece, data line piece [where the loop ctrl structure
is needed], GT, etc.) and then call or embed processing
(where you may be able to re-use parts of the original output
processing if there is any) to match each form part.
I have used this technique before, but not yet running from a
web-based clerk session (from @menu).

> I could write a
> file with the limiting info I need, then exit and have the next command do
> the clerk/FORM.

Yeah, but if you're trying to stay in the same clerk session
(I'm assuming all from @menu), then why not just control your
filtering there inside lookup loops rather than doing I/O to
another file?

> Or another dreport with this non-interactive selection
> processing,  Then subsequent commands to do the PDF generation, etc.  Am I
> on the right track if I write my limiting data to a file, then run dreport
> on the -v table, but take out the interactive questions and
> replace it with
> file I/O that gets my data from the first dreport?

Oh - so you are doing PDF generation at the same time.
Well if you use dreport with -v, then there should be no need to use
a limiting file - take out interactive and replace with values
from @pm, etc. passed from the clerk controlling process to get
the proper selection done.  Output finished report to a file and
then run pdf processor on that file to produce pdf.

[..]
>
> Thanks!
>
> mark->
> _______________________________________________