Prior to V5R4, a field selected from an AS400 file into an ADO recordset carried the same definition whether it was selected using IfNull() or not. For example, a field defined as "TSTDAT 8S 0" in DDS would have 8 as its ADO Precision property whether it arrived via
Select TSTDAT...
or
Select IfNull(TSTDAT,0)....
However, in V5R4, the first query will return a field with a Precision of 8, while the second will return a field with a Precision of 11. Anyone have a clue what in Sam Hill is going on? Even if the field in question is always null, DB2/400 knows how it's defined, otherwise the query would blow chunks to begin with. So if the DB & ADO are suddenly unable to get together on the right field def, is IBM going to call that a bug or a feature?
Oh, and, FWIW, the workaround is that--when it matters--such fields must now be selected as follows:
Select IfNull(TSTDAT,Zoned(0,8,0))...
Select TSTDAT...
or
Select IfNull(TSTDAT,0)....
However, in V5R4, the first query will return a field with a Precision of 8, while the second will return a field with a Precision of 11. Anyone have a clue what in Sam Hill is going on? Even if the field in question is always null, DB2/400 knows how it's defined, otherwise the query would blow chunks to begin with. So if the DB & ADO are suddenly unable to get together on the right field def, is IBM going to call that a bug or a feature?
Oh, and, FWIW, the workaround is that--when it matters--such fields must now be selected as follows:
Select IfNull(TSTDAT,Zoned(0,8,0))...