Re: Best Practices

[Terri Jenkins <LDYGLFR@AOL.COM>]

This is a general coding practice, and somewhat unspecific to SQR, but I
usually like to chose the 'core' table that will drive my logic, and fine tune
accessing that table first.  For instance, in retrieving certain types of
customer payments from Accounts Receivable, I have built my SELECT on the
ITEM_ACTIVITY table, and SHOW the significant fields.  I'll also use a counter
to tally the total number of rows retrieved from this 'driving' table, and
maybe sum the paid amount field.  I'll then show this to my main contact,
whether a user or IS liason and simply ask if they anticipated that N rows
would be driving the program.  They may say it's outrageous, or maybe that it
sounds right.  Either way, you get a feel for whether what they asked for is
really what they wanted.  It sometimes feels a little slow on the start when
doing this, but I have seen that users like immediate feedback at the onset.
Then when they have buy-in to what's driving the SQR, I can fly through all
the cross reference SELECTS to embellish upon the info on the driver rows.

For debugging, I prefer SHOW statements over DISPLAY because you can code
multiple literals in a SHOW without hasseling with the NOLINE parameter.

To emphasize another user's suggestion, more verbose procedure names are
helpful to those maintaining a program long after we contractors leave.

And, I do agree that neatness counts.

T.Jenkins
Tech Solutions, Inc.