DBMS_CRYPTO.HASH produces a different hash result when I use it in sqlldr?

Question

Hello,
If I execute the following in sqlplus:
SELECT LOWER(SYS.DBMS_CRYPTO.HASH(UTL_RAW.CAST_TO_RAW(CONCAT('Salt','000000000')),3)) FROM DUAL;
It produces one hash value. However, if I use similar logic in a sqlldr control file:
OPTIONS (SKIP=7)
LOAD DATA
INFILE 'C:\data.csv'
TRUNCATE INTO TABLE information
FIELDS TERMINATED BY '|' OPTIONALLY ENCLOSED BY '"'
TRAILING NULLCOLS
HOSTNAME          CONSTANT 'Company',
HOSTSERVICENAME     CONSTANT 'LOB',
ACCOUNTNAME,
LASTNAME,
EXTERNAL_ACCOUNT_ID     "LOWER(SYS.DBMS_CRYPTO.HASH(UTL_RAW.CAST_TO_RAW(CONCAT('Salt',:accountname)),3))"
Where ACCOUNTNAME in the file data.csv is also '000000000'. What am I doing wrong?
Thanks so much,
Jay

Answer 1

user3362629 wrote:
If anyone is interested, the problem was with the column datatype of the table. sqlldr was attempting to load data into a column of type NVARCHAR2. When I changed the column type to VARCHAR2, the hash values from both sqlldr and sqlplus were the same. I'm not sure if this is an Oracle bug or if this expected behavior. This was using Oracle Enterprise Edition 11g.Jay,
that's very interesting. One possible explanation that I could think of: Your SQL*Plus attempt:
If I execute the following in sqlplus:
SELECT LOWER(SYS.DBMS_CRYPTO.HASH(UTL_RAW.CAST_TO_RAW(CONCAT('Salt','000000000')),3)) FROM DUAL;used a VARCHAR2 literal, but the SQL*Loader code probably used a NVARCHAR2 as input to the function. From a RAW data perspective, these two, although representing the same string, could be quite different.
You could try to do the same in SQL*Plus, by using a NVARCHAR2 input to the function. If you want to achieve that using a literal the problem is, that it's not that simple to use a NVARCHAR2 literal. You would need to use an NVARCHAR2 literal (N'000000000') and in addition probably turn on the so called "NCHAR String Literal Replacement", which means that you need to set an environment variable (ORA_NCHAR_LITERAL_REPLACE = TRUE).
For more information regarding these issues, look here:
Text literals: http://download.oracle.com/docs/cd/B28359_01/server.111/b28298/ch7progrunicode.htm#CACHHIFE
NCHAR String Literal Replacement: http://download.oracle.com/docs/cd/B28359_01/server.111/b28286/sql_elements003.htm#SQLRF00218
It's probably far simpler to use a NVARCHAR2 stored somewhere in the database, or use e.g. a concatenation of the NCHR() function to generate a NVARCHAR2 on the fly than dealing with these literal conversion issues mentioned above.
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/