On 02-Nov-2015 22:23 -0600, Roger Harman wrote:
<<SNIP>>
The SQL0204 error is what I've seen in my testing if the file does
not exist.

Other than invoking a CHKOBJ from the program, I just wasn't sure if
there were a simple way with minimal overhead instead of forcing an
error.

The system is message-based, and despite the SQL using return-codes, even the existence checks by the SQL come about by an error condition; i.e. non-existence always will be manifest as an error, somewhere.

While there exist lower-overhead means to check, than by using the SQL to perform the check with the processing of the statement that will be attempted against the possibly-missing-object [and I have listed some below], this particular scenario is likely not well-served by using any; skip to the end of my reply for why.


If it doesn't exist, the program just exits - no harm/no foul in
this situation.

While I am not a fan of checking first and then reacting, in this scenario of the reaction being effectively /no matter/ vs the reaction being to /create-the-missing-object/, the problems inherent in the latter [due to concurrency] are avoided. And if the checking for existence is deferred to the SQL, then that is going to be somewhat slower than a check performed outside the SQL; but, one must ask, "Noticeably slower?" Yet, if the table-reference(s) are unqualified, deferral to the SQL is generally the best choice, because knowing or figuring out how the SQL is going to resolve the table-reference depending on use of *SYS vs *SQL naming can be a PITA.

Given the files are apparently permanent, and thus not in QTEMP, and if the table-references are library-qualified, then a CLLE procedure that performs the Check Object (CHKOBJ) or perhaps instead just using the Retrieve Object Description (QUSROBJD) API or even the stat() API or the Materialize Context (QusMaterializeContext) API, would probably suffice quite nicely; but if the naming of the files [as described in the OP] implies possibly the use of SQL /long/ names, then instead using the Retrieve Short Name (QDBRTVSN) API or a query of SYSTABLES catalog VIEW [or another query of the underlying data] could be an effective requirement when not deferring to the SQL statement that refers to the TABLE by name.

Realistically, the range of retro-active updates should pretty much
guarantee that a non-existence would be a rarity - maybe not worth
the worry - other than trapping the error and allowing a graceful
exit.

That alone implies the best option; that would be, the deferral to the actual SQL statement doing the DML to test for existence. That is because the SQL has to verify the existence of the file anyway, for each statement. And if almost every time the SQL will succeed in that existence-checking, then the exception-case is rare. Thus if the code were to be written /presumed-fail/ by adding an existence check prior to the SQL statement, then the rare exception-case is being doubly-tested for, on the vast majority of invocations; i.e. approaches doubling the number of existence checks. So having the code written instead as /presumed-success/, by simply letting the SQL perform the existence-check for the SQL statement, and thus the SQL will report the rare exception-case, the only additional work is limited to those rare\few exception cases; in this case, being especially inexpensive additional work, of an effective RETURN statement.


This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].