DB INSERT FAIL (w/ OJDBC 12.2.0)

I’m toiling over an insert statement wondering why it’s returning an ORA-00904 error only to find out, after checking the error logs, that Knime is generating malformed sql using quotes which I don’t appear to be able to change. This node would be markedly improved if you added a property to disable the quotes because Oracle doesn’t appear to like them. However, what puzzles me is I’ve used DB INSERT with other Oracle workflows without issue, but after numerous attempts to recreate the same logic when it did work I still continue to get the error. This is what’s captured to the logs. There’s really no need for quotes in the first place as there are no spaces.

Create SQL statement as prepareStatement:

INSERT INTO “DB”.“RMC_LL_OB_FILE_TRANSFER_LOG_TEMP” (“SourcePath”, “DestinationPath”, “Directory”, “Status”) VALUES (?,?,?,?)

I also attempted the same thing with DB Writer and it’s the same issue. I’ve got another process that gets it’s table names from a joiner and is writing to a global temporary table without issue. Nothing about this adds up.

Hello @kevinnay ,
this is the expected behavior. By default the database framework quotes all identifiers e.g. column names to ensure that they stay consistent. Otherwise the column names in KNIME tables and in the DB tables might be different since in the database column names are case insensitive if they are not quoted.

You can disable this behavior in the Advanced tab of the Oracle Connector node.


Either you can enable the “Delimit only identifier with spaces” option or if you want to disable it completely you can simply remove the double quotes from the Identifier delimiter options.

Alternatively you can change the case of the KNIME table columns to match it with the one in the database using the Column Renamer node.

Bye
Tobias

1 Like

Hi @kevinnay,

Continuing from what @tobias.koetter has mentioned, I thought it may be worth noting that double-quoting column names in Oracle isn’t only necessary when there are spaces in the name, although that would of course be one use case.

Oracle, like most SQL databases is case-sensitive under the hood when it comes to column and table names, although that isn’t immediately apparent because if you don’t include them inside double quotes it will treat identifiers as upper case regardless of the case used to type them. So if you never double quote anything, you’d never need to, regardless of what case you type

As you know, all of the following will work:

select sysdate from dual;

select sysdate from DuAl;

select SysDate from Dual;

select sysdate from "DUAL";

because in all of the above, Oracle “sees” the unquoted identifers as in fact being upper case
i.e.
select SYSDATE from DUAL

and that’s all good because SYSDATE and DUAL are held in the database in uppercase. What this means though is that this will fail:

select sysdate from "dual";

and so will this:
select "sysdate" from DUAL;

because there is no table called dual in lower case, and nor is lower case “sysdate” a known pseudo-column identifier.

KNIME assumes that the column names that you have in your data tables are likely to be the same as the column names in your database. As the Oracle database is in fact case-sensitive, it will therefore add double-quotes to ensure this case-sensitivity is maintained. So that I would think is the reasoning behind having quoted identifiers turned on by default.

Mind you, speaking personally I cannot envisage ever wanting to put myself through the pain of having anything other than upper case column and table names in my database, and having to type double quotes in all my queries outside of KNIME, which I imagine is where you find yourself too. :wink:

1 Like

Beautiful. I was hoping I had missed something, just missed that in the connector. Thank you. Ran like a champ.

Yes good points. In our system there are actually aspects that are case sensitive and others that are not and it has caught me a few times if I wasn’t paying attention. Thanks for the additional insights.

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.