After studying this a bit, it seems that DB2 is a bit complex with
regard to rsmd.getColumnName and rsmd.getColumnLabel. First,
depending on the platform of DB2, a column label can mean different
things. For example, in all platforms of DB2 (z/OS, LUW, etc.), in
some cases a select statement that uses a column alias, will yield the
alias name from getColumnLabel. However, in mainframe DB2 (z/OS,
etc.), there is a "LABEL on " statement that is used to give columns a
"label" that in some configurations is returned from
rsmd.getColumnLabel. There is a new data source property available
for DB2 JDBC 4.0 drivers that changes the semantics of these two API
(See useJDBC4ColumnNameAndLabelSemantics property)
If the driver conforms to JDBC 4.0, and DB2 server is mainframe, then
there are basically two configurations:
1. useJDBC4ColumnNameAndLabelSemantics = DB2BaseDataSource.YES :
"LABEL on" column labels are ignored; getColumnLabel = column alias in
select statement if provided. If not provided, then it is the column
2. useJDBC4ColumnNameAndLabelSemantics = DB2BaseDataSource.NO : "LABEL
on" column labels are returned from getColumnLabel. Column aliases
are returned from getColumnName.
For older drivers the default behavior is item 2 above. Item #1 would
potentially solve the issue that Christian is having without a code
change to SQuirreL. I would be curious to see if that is correct, if
Christian would like to try. According to the configuration
instructions in the document I cited, you would need to use a JDBC 4.0
driver and append the following to the JDBC URL:
I'm still planning to convert our usage of getColumnLabel to
getColumnName, but I would be curious to see if the above has any
effect on the problem with DB2 on the mainframe platform.
On Thu, Jan 28, 2010 at 8:26 PM, Robert Manning
> Thanks for confirming that Christian - I suspected that but I wanted
> to have another look to be sure. We will take care of this issue
> before the 3.1 release in February and when we do there will be a
> snapshot that you (and others who might be interested in the impact of
> this change) to try out.
> On Thu, Jan 28, 2010 at 2:02 PM, Christian Gruenberg
> <christian@...> wrote:
>>>> I also think that if we do this in core, then probably
>>>> most if not all of Christian's custom DB2 datatypes are unnecessary.
>>>> I skimmed over them so it is possible that I missed something but they
>>>> seemed to be merely overriding the core implementation of
>>>> getWhereClauseValue() and the like in *DataTypeComponent. I'll take
>>>> another look.
>> You are right, they are unnecessary now if you'll corret the basic datatypes.