Re: Embedded SQL problem - Feature or Bug?

[Sue Romano <slromano@xxxxxxxxxx>]

This is a feature.

At precompile time for *prv, the SQL precompiler cannot make too many
assumptions about the table's definition in a prior release, so we use the
current release rules in most cases (rules tend to get relaxed, not
tightened as time goes by).  It is possible that the column was character
in the earlier release and then altered in the new release to be numeric.
For this implicit numeric conversion enhancement, we determined it was best
to not enforce the V5R2 error checking in a later release since the
precompile could fail for some cases where the table definition had
changed.  Since the final error checking is done when the INSERT is run,
omitting this error check at precompile time does not cause any serious
problem (other than issuing an error that needs to be handled by the
programmer).

Any syntax for new SQL functionality (like a new data type, a new object
type, or a new query clause) will cause the precompile for an earlier
release to fail.

Sue Romano
SQL parser

> I recently made the determination (purely by accident) that DB2/400 on
V5R4 will automatically attempt to >re-cast fields to the proper type.  It
appears that on the V5R4 system it compiles fine (even when >specifiying
target release V5R2), since it apparently recasts the alphameric field as
numeric on the INSERT.
> However, I'm relatively confident that even though this program compiled
properly on the V5R4 machine, it >would bomb when we tried to run it on the
V5R2 box, since DB2/400 can't do the proper recasting on V5R2.
> The simple fix is to change the host variables to be numeric, which we
did, and it now compiles on the V5R2 >box.
> However, my thoughts are that IBM should enforce this casting restriction
when compiling on the V5R4 box to >target release V5R2.  Comments?
> Regards,
> Steve