FW: need help with dclerk
Fairlight
fairlite at fairlite.com
Thu Sep 9 12:15:41 PDT 2010
With neither thought nor caution, John Esak blurted:
>
> Exactly as Bruce says here. Clerk is absolutely the superior choice for any
> report that even requires only one interactive request. If there is really
> nothing to ask of the user, then and pretty much *only* then *report alone
> is the thing to use.
To address Brian's original question, I use report with -sr N to sit on
specific "slots" (records) in a control file to avoid locking contention,
and do ALL my processing via lookups to other files. That's my
architecture. But the client had printing, and he designs these forms for
back-of-house receipts and notifications, and they print like 11 records
per page, and I dunno...I don't do printing since 1995, so I don't design
the printing code. I just adapt his to a CGI context. Since he uses FORM
to kick his printing off from the "F" key in clerk, it was written that
way, and I just adapt to making it work non-interactively with the same
code.
> In the past, I've put up a lot of examples of why clerk gives you better
> user interaction and much more error checking and "approval" stages before
> you launch the report. My favorite technique is to put up a POPUP UPDATE
> screen and get all the criteria from the user into dummy fields... YES,
> using all the LISTBOX's and BROWSE's and any other nifty thing clerk is
> capable of doing that report is not... And then passing the retrieved
> parameters to the environment via putenv(), then SYSTEM out to a "rreport
> filename -v sel_prc -f format ..." where the -v process uses getenv() to
> use the values placed there to produce the desired report... Records sorted
> and selected just so.
And getting back to -my- environment requirements... Because OneGate keeps
track of how many "slots" are in use, you don't want actual instances of
clerk or report to be onegate_session_count + N, you want it to be
onegate_session_count.
So I do 99% of my work in report, and one of the things I do is write what
I call a "chain" file, which is really a one-line system()-using perl
script, to disk. When report exits, the chain file is executed next by
onegate and in turn runs clerk, which means that clerk only runs -after-
report has finished, so you don't get increased counts from nested system()
calls to subsequent fP binaries. Then after that command is finished, the
chain file is unlinked. It's really elegant, even if it seems convoluted
at first.
mark->
--
Audio panton, cogito singularis.
More information about the Filepro-list
mailing list