Skip to main content
Question

UpdateDetector Ignores Special Characters In SQL Server 2012


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.

10 replies

takashi
Influencer
  • 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
kddunn wrote:

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
Influencer
  • April 26, 2017
kddunn wrote:

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
kddunn wrote:

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
Influencer
  • April 26, 2017
kddunn wrote:

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
kddunn wrote:

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
kddunn wrote:

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.


Reply


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings