Re: Storing Numeric Values in the Database

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.

Regards, Chuck