Skip to main content
Question

MSSQL to Oracle resulting in all NULL in destination table

  • October 12, 2017
  • 3 replies
  • 12 views
M
Forum|alt.badge.img

Hi,

Currently having issues with a Microsoft SQL Server source table writing to an Oracle12c destination. The package appears to run smoothly without errors, however when checking the destination every field is null. It has the correct number of rows at any rate, but absolutely no data.

Bit more in depth...I have an Oracle Data source that writes to my Oracle destination DB correctly, so I believe the writer is configured correctly. I have tried removing the Oracle destination and simply having the MS data source write to a CSV, which also works. When I try to use the CSV as a data source and copy it to Oracle, I once again receive all nulls.

Was wondering if anyone has seen this before and if they have a working solution. I'm aware Oracle likes Uppercase and Microsoft seems to enjoy lower case and I'm investigating that route now. Any help much appreciated.

Thanks

This post is closed to further activity.
It may be an old question, an answered question, an implemented idea, or a notification-only post.
Please check post dates before relying on any information in a question or answer.
For follow-up or related questions, please post a new question or idea.
If there is a genuine update to be made, please contact us and request that the post is reopened.

3 replies

trentatsafe
Safer
Forum|alt.badge.img+6
  • trentatsafeSafer
  • Safer
  • 278 replies
  • October 12, 2017

Hello @mefromcanada

 

 

As you stated, my first thought is the case of the attributes. You mention that the correct number of features are present in the database, the NULLS would be as a result of an incorrectly matching source to destination attributes.

 

 

Are you able to share a sample of your data? I wouldn't mind trying to load the data, to see if it is, in fact, a case issue. One test you could perform quick if you want to use the 'BulkAttributeRenamer' transformer to change the case to match. This would be a quick test to demonstrate if this is, in fact, the issue.

 

Let me know if that helps.
M
Forum|alt.badge.img
  • mefromcanada
  • Author
  • 2 replies
  • October 12, 2017

Answered my own question ;)

Ultimately it's capitalization at fault and the table to table copy was treating the fields of the same name as completely different fields. Opening up the source columns and manually mapping them to the destination columns corrected the issue.

M
Forum|alt.badge.img
  • mefromcanada
  • Author
  • 2 replies
  • October 12, 2017

Hello @mefromcanada

 

 

As you stated, my first thought is the case of the attributes. You mention that the correct number of features are present in the database, the NULLS would be as a result of an incorrectly matching source to destination attributes.

 

 

Are you able to share a sample of your data? I wouldn't mind trying to load the data, to see if it is, in fact, a case issue. One test you could perform quick if you want to use the 'BulkAttributeRenamer' transformer to change the case to match. This would be a quick test to demonstrate if this is, in fact, the issue.

 

Let me know if that helps.
Thanks Trent...just had to play with the mappings a bit. Going in with the viewpoint that case <> CASE led me to mapping the fields as if they weren't the same name. All good now

 

 

Community Stats

32,093
Posts
121,875
Replies
39,731
Members

Latest FME

Terms & ConditionsCookie settingsAccessibility statement
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.