Commented by: @mrotteveel

This is not a bug, it is an intentional change that is documented in the releasenotes

See under 'Other fixes and changes':
"FBResultSetMetaData#⁠getcolumnName(int) will now return the original column name (if
available) for compliance with the JDBC specification, getColumnLabel(int) will still
return the alias (or the column name if no alias is defined). See Compatibility with
com.sun.rowset.* for potential problems when using the reference implementation of
CachedRowSet.
Jaybird 2.2.1 introduced the connection property columnLabelForName which will revert to
the old behavior when set to true. Be aware that the old behavior is not JDBCcompliant."

and under:
Compatibility with com.sun.rowset.*:
"The reference implementation of javax.sql.rowset included with Java in package
com.sun.rowset does not correctly look up columns by name as it ignores column aliases and only
allows look up by the original column name5 (this specifically applies to
5 See JDBC162 and http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7046875 for details
com.sun.rowset.CachedRowSetImpl).
We advise you to either only access columns by their index or use an implementation which
correctly uses the column label for column lookup (which is either the alias or the original column
name if no alias was defined).
Jaybird 2.2.1 introduced the connection property columnLabelForName for backwards compatible
behavior of ResultSetMetaData#⁠getColumnName(int). Set property to true for backwards
compatible behavior (getColumnName() returns the column label); don't set the property or set it to
false for JDBCcompliant behavior (recommended)."

You should use getColumnLabel() instead of getColumnName(). The JDBC specification defines columnName as the original column name (if any), while the columnLabel is the alias defined in the AS clause, or otherwise the columnName if no alias is defined. So you will almost always need to use getColumnLabel(). If you want the old behavior, then you can specify the connection property columnLabelForName=true

See also: JDBC162, JDBC258, JDBC260

Commented by: @mrotteveel

Specifically for SQuirreL: See also http://stackoverflow.com/q/12709814/466862

Commented by: Derryck welas (welas)

Mark thanks for your reply,

so this "select a.symbol as "Newname" from unit a " complies with jdbc 3.0 (i'm oke with that !)

getcolumnLabel() returns the aliased name
getcolumnName() returns the actual table name

Just a quick verification this seems to fail

"select a.symbol as "newname" from unit a group by symbol"

getcolumnLabel() returns the aliased name ---->oke
getcolumnName() should return the actual table name ---> empty !!! (fails)

is this impossible for getcolumnName() in this case ?

Commented by: @mrotteveel

If I understand you correctly then "select a.symbol as "newname" from unit a group by symbol" does not show 'symbol' for the columnName? I will need to test that .The only reason I can think of right now, is that Firebird does not include the original column name in the xsqlvar because it is a grouped query. If so, that is a limitation of Firebird. I will get back to you about that.

Commented by: Derryck welas (welas)

Rechecked:

"select a.symbol as "newname" from unit a group by symbol"
these call can be seen on the MetaData Tab in squirel. (attached picture)

fails on 2 calls:
getcolumnName()
getTablename()

Commented by: @mrotteveel

As you are also missing the tableName, I am almost sure that Firebird somehow forgets this info in a grouped query, so it is not included in the xsqlvar. I don't think I will have time to actually test this until somewhere next week, as the Firebird Conference is this week.

Commented by: @mrotteveel

The output of ISQL with SET SQLDA_DISPLAY ON shows it is a limitation of Firebird itself:

SQL> select RDB$RELATION_ID AS RDB$RELATION_ID FROM RDB$DATABASE;

INPUT SQLDA version: 1 sqln: 10 sqld: 0

OUTPUT SQLDA version: 1 sqln: 20 sqld: 1
01: sqltype: 501 SHORT Nullable sqlscale: 0 sqlsubtype: 0 sqllen: 2
: name: (15)RDB$RELATION_ID alias: (15)RDB$RELATION_ID
: table: (12)RDB$DATABASE owner: (6)SYSDBA

RDB$RELATION_ID

        144

SQL> select RDB$RELATION_ID AS RDB$RELATION_ID FROM RDB$DATABASE GROUP BY RDB$RELATION_ID;

INPUT SQLDA version: 1 sqln: 10 sqld: 0

OUTPUT SQLDA version: 1 sqln: 20 sqld: 1
01: sqltype: 501 SHORT Nullable sqlscale: 0 sqlsubtype: 0 sqllen: 2
: name: (0) alias: (15)RDB$RELATION_ID
: table: (0) owner: (0)

RDB$RELATION_ID

        144

Commented by: @mrotteveel

Interestingly enough, removing the alis does display it, so it is most likely a bug:

SQL> select RDB$RELATION_ID FROM RDB$DATABASE GROUP BY RDB$RELATION_ID;

INPUT SQLDA version: 1 sqln: 10 sqld: 0

OUTPUT SQLDA version: 1 sqln: 20 sqld: 1
01: sqltype: 501 SHORT Nullable sqlscale: 0 sqlsubtype: 0 sqllen: 2
: name: (15)RDB$RELATION_ID alias: (15)RDB$RELATION_ID
: table: (12)RDB$DATABASE owner: (6)SYSDBA

RDB$RELATION_ID

        144

Commented by: @mrotteveel

Opened CORE3973 to report problem in Firebird. I will close this issue as I can't solve it in Jaybird.