RE: SQL null indicators when not all columns are null capable

Chuck,

The issue was that the date in the table was a date data type in *ISO format. The embedded SQL was using the date format for the job when it retrieved the records which was *MDY. The result was placing mm/dd/yy into a date expecting to receive yyyy/mm/dd. Adding the DATFMT(*ISO) option to my SET statement corrected the issue.

As I'm typing this I'm wondering why it matters. If the date in the table is a date data type and the field in the result set is a date data type why would the representations matter? Maybe it really is a bug? Or, is the value SQL places into the result set the same representation it would use if displaying on the screen?

Rick

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Wednesday, April 14, 2010 2:20 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: SQL null indicators when not all columns are null capable

What does DATFMT() show in PRTSQLINF? How is the variable ReceivedBack declared according to the listing? Does the returned data match the expected format; i.e. the SQL date format? If the LIKE declared variable appears other than as DATE(10), what if the variable is declared instead, explicitly as an alphanumeric with a length of 10 bytes?

Regards, Chuck

Privileged and Confidential. This e-mail, and any attachments there to, is intended only for use by the addressee(s) named herein and may contain privileged or confidential information. If you have received this e-mail in error, please notify me immediately by a return e-mail and delete this e-mail. You are hereby notified that any dissemination, distribution or copying of this e-mail and/or any attachments thereto, is strictly prohibited.