Re: SQLCOD 12

On 29-Mar-2014 12:01 -0700, CRPence wrote:

<<SNIP>> Irrespective the possibility there may be a defect for one
invocation failing to properly identify the 01545 condition, the
statement can be rewritten to avoid the Subject issue; i.e. rewritten
to provide Correlation Identifiers for the files and to qualify the
field names with the respective identifier. <<SNIP>>

Although the OP never stated the release, I decided to try a similar embedded SQL on v5r3. I noticed that the warning occurred only on the first invocation, and only when that first invocation started without an existing access plan; i.e. SQL4013 "Access plan has not been built." appeared in the PRTSQLINF output. There was no AccPln because the files referenced in the UPDATE had not been created when the program was compiled. The pre-compiler had logged a warning SQL1103 "Column definitions for table &1 in &2 not found.", because the program was coded to create the files [with CREATE TABLE or perhaps instead DECLARE GLOBAL TEMPORARY TABLE] during run-time, before the UPDATE. Running the program each additional time since the first invocation, as long as the access plan was not rebuilt [e.g. rebuilt due to the file being altered] in that future invocation, the UPDATE would complete with SQLSTATE='00000'.

That the warning SQLCODE=+12 with SQLSTATE=01545 would occur only when the access plan is [re]built, seems a reasonable effect. If the AccPln exists and is both validated and used, then the correlation that was *assumed* by the SQL [as described by the text for msg SQL0012] is already in effect, and that condition was previously warned; i.e. there is little reason to warn again. Thus I retract any implication that there must be *consistency* between the two separate requests to the same embedded SQL UPDATE statement from the OP. The recommended means to avoid the warning however, as described in the quoted text from my prior reply, still holds.