Skip to main content
Question

UpdateDetector Ignores Special Characters In SQL Server 2012

  • April 26, 2017
  • 10 replies
  • 38 views

Forum|alt.badge.img

I'm using a workspace that utilizes the UpdateDetector and the fme_db_operation INSERT, UPDATE, and DELETE functions to synchronize a table called Topology. In the Topology table there is a field called PASSWORDX that contains encrypted characters like "...." . When the database was first empty, the INSERT went fine, but a few weeks later when the password changed from "...." to "/_,|", FME says that the updates were written to the table, but actually were not.

I was able to run this script in SQL Server Manager and successfully update the table:

UPDATE dbo.TOPOLOGY

 

set PASSWORDX='/_,|'

 

where NOINS = '0EB2996'

 

GO

Could this be something with the FME UpdateDetector transformer? I'm using FME Desktop 2017, latest build on a Windows 10 machine.

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.

10 replies

takashi
Celebrity
  • April 26, 2017

Hi @kddunn, if you are using the MS SQL Server (Spatial or Non-Spatial) writer, firstly make sure that the Feature Operation parameter in the writer feature type properties is set to fme_db_operation.


Forum|alt.badge.img
  • Author
  • April 26, 2017

Yes, I created 3 AttributeCreators for each of the Insert, Update, and Delete operations and the fme_db_operation is set for each in the Configuration.


Forum|alt.badge.img
  • Author
  • April 26, 2017

Yes, I created 3 AttributeCreators for each of the Insert, Update, and Delete operations and the fme_db_operation is set for each in the Configuration.

I should also mention that I made some changes on a few test records, and all the other fields in the table updated successfully.

 

 


takashi
Celebrity
  • April 26, 2017

Yes, I created 3 AttributeCreators for each of the Insert, Update, and Delete operations and the fme_db_operation is set for each in the Configuration.

I meant the Feature Operation parameter in the writer feature type properties. Have you set the parameter to fme_db_operation?

 


Forum|alt.badge.img
  • Author
  • April 26, 2017

Yes, I created 3 AttributeCreators for each of the Insert, Update, and Delete operations and the fme_db_operation is set for each in the Configuration.

The Feature Operation parameter in the SQL Write has been properly set to fme_db_operation. I suspect it's something to do with the password characters themselves, but no error messages are given.

 

 


Forum|alt.badge.img
  • Author
  • April 26, 2017

Here's a graphic:


takashi
Celebrity
  • April 26, 2017

Here's a graphic:

OK. I cannot find any wrong thing in your workflow.

 

Does the feature coming from the Updated port of the UpdateDetector have the correct password string '/_,|'? Check this with a Logger.

 


Forum|alt.badge.img
  • Author
  • April 26, 2017

Here's a graphic:

After placing Inspectors before and after the Attribute Creator coming out of the Updated port, and before and after the UpdateDetector, I verified that the record in question is not making it through the UpdateDetector and on to the database. The only thing unique about the value in the PASSWORDX field is the | character in it.

 

 


Forum|alt.badge.img
  • Author
  • April 26, 2017

Here's a graphic:

 

So what I meant to say was that the piping character | is the only character I'm using that is different from all the other password combinations we use in the PASSWORDX field.

 


Forum|alt.badge.img
  • Author
  • May 10, 2017

I will take this up with Safe Support to see if they can provide an answer.