Qlik Replicate is altering the data type for oracle BD NUMBER columns with precision greater than 38

[WLYB]

Please review the following issue:

Qlik Replicate is altering the DB Oracle data type for NUMBER columns with precision greater than 38 when replicating from an Oracle data source. Specifically, it reduces the precision to 0.000000000000000.

During replication from Oracle to Azure Event Hub, columns defined as NUMBER with precision > 38 are not preserved as is.

Even when changing the data type to VARCHAR and stopping and restarting the task, Qlik Replicate continues to convert NUMBER > 38 columns, resulting in data loss or incorrect data.

Our current data flow setup is as follows:

• From Oracle (ODS) to local disk: T_LSS_ODS
• From local disk: S_ODS_LSS to Azure Event Hub
•  

Both T_LSS_ODS and S_ODS_LSS are located on the same Qlik application server.

The issue concerns the column ORA_LINE_ID, which has the NUMBER data type at the Oracle database level.

Currently, the setup involves converting NUMBER to VARCHAR at each step:

• ODS (NUMBER) → VARCHAR
• T_LSS_ODS (NUMBER as VARCHAR)
• S_ODS_LSS (NUMBER as VARCHAR)
•  

We would greatly appreciate your guidance on how to resolve this issue.

[john_wang · Accepted solution]

Hello @WLYB ,

Please start by isolating the issue from LogStream. For example, try running a direct replication from Oracle to Azure Event Hub without using LogStream.

Also, set the following option:

• Expose NUMBER as: varchar

If the issue still persists, please enable verbose logging by setting the following parameters:

• SOURCE_UNLOAD

• SOURCE_CAPTURE

• TARGET_LOAD

• TARGET_APPLY

After reproducing the behavior, please decrypt the task log files and open a support ticket. Our support team will be happy to assist you further.

Regards,

John.

[WLYB]

Hello John,

Thank you for your advice.
I tried to isolate the problem, and it is definitely linked to log streaming. The direct Qlik replication works fine.

Do you have any ideas on how to resolve this issue using log streaming?

Regards

WLYB

[Dana_Baldwin]

Hi @WLYB 

Thank you for following up to let us know it works with a direct task. There are too many possibilities as to the cause, so we need the verbose logging that @john_wang mentioned. It is best to provide that on a support case for the sake of privacy, as logs posted here are public, and also because we may need to involve our internal support team - we can do that from a support case but we have no elevation path from a Community post.

I hope this helps!

Thanks,

Dana