When using SLT to replicate data from Oracle DB to HANA, you might see SQL error 932 occurred on a specific table and the initial load was failed.
The reason is that you have defined a long field in the table, e.g. VARCHAR(2000).
Following is an example of the problem and the workaround.
- We create table SLT_DEMO with 3 long fields - BBB, CCC and DDD, and insert 2 records into it as below.
Image may be NSFW.
Clik here to view. - We start to load the table in SLT.
Image may be NSFW.
Clik here to view.
However the load failed. We can see SQL error 932 below in tag "Application Log" or by clicking "View Errors" button.
Image may be NSFW.
Clik here to view.
Image may be NSFW.
Clik here to view.
We also can see the following shortdump occurred in ST22.
Image may be NSFW.
Clik here to view. - Now let's check the proxy table of SLT_DEMO.
You can see the data type of CCC and DDD were converted to "STRING" which should be "CHAR".
However BBB was converted to "CHAR" correctly.
Image may be NSFW.
Clik here to view.
Data type "STRING" is for "LONG" and "CLOB", so when SLT tried to read data from SLT_DEMO on the source DB, it hoped field CCC and DDD should be "LONG" or "CLOB".
However it found the data type of CCC and DDD were"VARCHAR", then error "inconsistent datatype" occurred. - We can use table IUUC_DB_COL_TYPE to specify the data type of a field in SLT as below.
We need to stop the load and add 2 records in table IUUC_DB_COL_TYPE for CCC and DDD in SE11.
Image may be NSFW.
Clik here to view.
We need to specify the values as below.
Image may be NSFW.
Clik here to view.
Field "DBCON NAME" and "DB SCHEMA" can be found in tag "Administration Data" in LTRC.
Image may be NSFW.
Clik here to view.
Now we have 2 convert rules in table IUUC_DB_COL_TYPE.
Image may be NSFW.
Clik here to view. - Let's start the load in LTRC again.
You can see the data was loaded without any problem.
Image may be NSFW.
Clik here to view.
Image may be NSFW.
Clik here to view.
We do not have a plan to enhance this functionality at the moment and the design may change, so there is no Note or KBA to introduce the workaround.
If you have the same problem, you have to refer to this blog.