This is something that changed in KNIME 2.4.2: When I now use the database reader and a SQL statement such as "Select ID as Foo from Molecules" the output table has the original db table name as the column name (i.e. ID) and NOT the alias name (i.e. Foo).
This is was certainly not the case with KNIME 2.3.1. Is this a bug? Is there a way to overcome this in KNIME 2.4.2?
Thank you both for reporting these problems: a) I need to look into the alias issue reported under Oracle comparing KNIME 2.3.1 with 2.4.2, is this correct? b) The second problem, CODING ERROR, is a warning reported by the framework if the underlying spec generated by configure does not match the one created by execute. I assume, the underlying table has not changed from configure to execute, so I treat this as a bug of the actual node implementation.
I am using the standard KNIME 2.4.2 on WinXP and the java-mysql driver 5.1.16. In the database reader, I use com.mysql.jdbc.Driver and a local mysql instance of chEMBL db v11.
The SQL command is simply:
SELECT canonical_smiles as George FROM compound_structures limit 100
I leave the box "Run SQL query without configure" checked.
The output is a column with the name "canonical_smiles", i.e. the alias was not passed on the output KNIME table as expected.
When I run the same SQL statement with the box "Run SQL query without configure" UN-checked the node returns the same data (canonical_smiles) but also throws an error:
ERROR Database Reader CODING PROBLEMDataSpec generated by configure does not match spec after execution.
ERROR Database Reader DataSpec generated by configure does not match spec after execution.
This error does not occur if I remove the alias part from the sql command:
SELECT canonical_smiles FROM compound_structures limit 100
Please note the aliases work fine with Oracle dbs.
Also note that aliases used to work in MySQL databases in KNIME 2.3.1.
After some more investigations, it turns out that the mysql driver implementation has changed in the meantime which is also reported here. At the same time, we decided to not wrap SQL queries into additional 'SELECT * FROM (...) table_alias' clauses which caused this problem to appear at first place. I see two workarounds a) you manually wrap the SQL statement or b) you append ?useOldAliasMetadataBehavior=true to the end of the database driver URL.