Re: SQL Pre-compiler Issue

On 21-Oct-2015 10:10 -0500, John Yeung wrote:

On Wed, Oct 21, 2015 at 10:29 AM, CRPence wrote:

FWiW: That the GENLVL(31) was not sufficiently effective seems
troublesome. Indeed, again, that situation would appear to be
"something the pre-compiler ought to be able to deal with". There
seems quite possibly to be a defect, at least as described; a
defect, that if not there, would have allowed that Severity Level
specification to overcome the issue. Effectively, by deleting the
file, the problem has been circumvented, but not resolved; i.e. the
apparent defect remains to be encountered again in another [or a
repeat] incident.

To be completely honest, I haven't fully followed your analysis, so
maybe you're saying what I'm thinking, just in different words; or
maybe you're saying something different.

I am totally with you on the "seems like a defect" language. ;)

From where I'm sitting, it feels like the compilation (of correct
*syntax*) should either (1) always succeed whether or not the file
is found, and if there's a runtime error, so be it; or (2) never
succeed when the file is not found.

I would be comfortable with "default GENLVL" behavior to be either
of the above. That is, I could make sense of "default GENLVL"
resulting in behavior (1) (and possibly no way of achieving (2)); or
of "default GENLVL" behavior being (2) and "permissive GENLVL"
behavior being (1).

That what the OP describes seems an apparent defect, apparently we are in agreement. As for the rest, not so much.

With regard to how the SQL deals with [non]existent references for validity checking statements, I am quite content with the compromise and the apparent rationale behind the choice to ignore the missing-references, whilst not ignoring those located-references for which the validity checking fails. Maybe that is, arguably, just a reflection of familiarity.? But in my opion:

While those absolutes might fit, in a /logical/ sense, they tend not to fit, in a /practical/ sense. Perhaps strangely, most people are [begrudgingly] joyful when the pre-compiler diagnoses that their reference is problematic. That although they may have to make changes to their source, and then issue the pre-compile request again, they usually have fared better than if they had only learned of the likely failure *after* they also ran their test suite. In the end, they have saved possibly huge amounts of time. In rare exception cases, when a program needs to be aware of the existence of both a prior and a present [or both the present and a future] _description of_ the reference [e.g. the Record Format (RCDFMT) of an altered or eventually to be altered TABLE], they can easily enough adjust their Severity Level (GENLVL) specification to ignore the error. Given the simultaneous-two-world-view scenario is atypical, IMO tending towards placating that small minority would just make the SQL seem less nice and less helpful for the vast majority.