Skip to main content
  • EN

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.

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.

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.

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.

 

 

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?

 

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.

 

 

Here's a graphic:

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.

 

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.

 

 

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.

 

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

Reply


Community Stats

30,133
Posts
114,383
Replies
37,770
Members
Terms & ConditionsCookie settings
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.