Re: Storing Numeric Values in the Database

You can buy me a Dr Pepper next time I'm in Rochester for being your straight man!

I think we are in complete agreement here. I find RUNQRY good for one thing, DSPPFM for another. This thread will help people understand which to use when.

Now as to ORDER BY - it's easy enough to write a command that lets you enter any SQL statement, using Query Management. And there you can put anything in. Of course, you do need to know SQL. Or you could do something that'd be like RUNQRY, that would include selectivity and ordering and whatever - sorta like the SEQUEL product, but not all that hard to do. The same thing could probably be writ using dynamic embedded SQL in RPG, too.

BTW, I'm doing a presentation on QM at the Sept meeting of WMCPA this Thursday - I think it's a great tool for ad hoc stuff and reporting, despite all the heat about Web Query! Hey, who knows, might try to educate the world next about REXX!!

Ducking
Vern

On 9/3/2011 11:39 AM, CRPence wrote:

Yet I was contrasting the two tools [DSPPFM vs RUNQRY QRY(*NONE)] for
their ability to present data as RRNs, which is likely very relevant to
most users with regard to displaying the data in a member.

The point in mentioning "no ORDER BY" is of course, to emphasize that
the order of rows returned by a RUNQRY QRY(*NONE) is undefined and thus
unpredictable. That remains factual, no matter that most will have
falsely inferred the results will always be in "arrival sequence". Very
many times I had to explain to a customer that the "defect" they were
reporting for a change in order of rows was instead a usage-error,
because their query request did not include ordering; a query which [at
least seemed] to have long given arrival sequence results, suddenly
would no longer. As long as the user of RUNQRY QRY(*NONE) for the
purpose of displaying physical data understands that [and other
nuances], then I agree that the RUNQRY can be a great tool for them,
either along with or instead of DSPPFM.

With DSPPFM the order is defined-as and thus known to be in "arrival
sequence". That the data returned from RUNQRY may not reflect the
physical-order conflicts with the typical expectation for viewing the
physical data. Without physical order, identifying a particular row
requires tracking to a primary or unique key. And while DSPPFM has its
own issue for not representing the deleted rows relative to the active
rows, at least there is feedback for which active row remains presented
at the top of the displayed data. And with DSPPFM the relative or
direct positioning input field can be used to request that the specific,
previous, or next RRN be presented as the first row of the displayed
data; the actual RRN that was found is then shown in the feedback above
the data\rows.

FWiW RUNQRY [using CQE] does honor the select\omit [both of the index
and dynamic] of the access path for the LFM named on the QRYFILE [or in
the *QRYDFN], but again, order is undefined both for RUNQRY QRY(*NONE)
and for a *QRYDFN with no sort field specifications [aka "no ORDER BY"].

Regards, Chuck

On 02-Sep-2011 16:41 , Vern Hamberg wrote:

All true enough and good points. The OP, however, was speaking of
DSPPFM, and that also has no ORDER BY. Using RUNQRY on an LF seems
never to use the access path - well, I've not tried it, actually.

And you can't run DSPPFM against a select-omit - HMMMM!

As I replied to John, I did say "almost completely" to describe my
use of RUNQRY over DSPPFM. I'm usually more often interested in
seeing the real-world value than in the hex value underneath. But I
do like seeing the over-under - I once got a glimpse at the S/36
tools - was it called POP?

So again we use the tool we need to get our job done.

Regards and hope y'all have a good Labor Day - no working allowed
here in the States, please!

On 9/2/2011 4:32 PM, CRPence wrote:

On 02-Sep-2011 08:12 , John Yeung wrote:

On Fri, Sep 2, 2011 at 10:40 AM, Vern Hamberg wrote:

Instead, I use RUNQRY - it, also, is always there, and it
displays everything as their value, not their hex
representation.

But you missed a big advantage DSPPFM has over RUNQRY, which Joe
already pointed out: DSPPFM is very, very fast, and will show
you ANY record you choose (by RRN) almost instantly. RUNQRY has
to load all the records sequentially and cannot "jump" to a
record. For some files, RUNQRY is not a practical
option.<<SNIP>>

Using RUNQRY of a file ["default queries" as we called them]
enables no means to include an ORDER BY clause so no specific
collation can be assumed. While arrival sequence is the most
probable outcome [even if the file named is a keyed logical file
member over just one physical member.data], the order of rows
presented can not be predicted.

And while RUNQRY can assist to identify which key has a field with
an error, there is no means to see what is the actual origin for an
error such as decimal data errors whether blanks or something else
in NUMERIC type data; seeing RRN possibly only by review of some
logged database messages which may remain only when running in
debug. But of course DSPPFM is similarly worthless for reviewing
the date\time types with errors, because of the design which
matches the layout to the DSPFFD instead of the actual internal
storage. Somewhat silly, since a primary purpose of BRWPFM was to
enable reviewing the hex code points that make up the internal
representation of the data in any particular RRN, typically in
response to an error that had identified that RRN.