Skip to main content
  • EN

Hi All,

I might be asking a silly question but here it goes:

I am trying to pass some records through a Feature Writer and off the back of that pass the unique id of the written records into a SQL stored procedure so I can track it has been written successfully. However if I use the Feature Writer then I lose the attributes in the summary and therefore can't use the unique id in my stored procedure 😞

Is there a way to expose this attribute so I can use the unique id. I have attached some screen shots.

 

I dont think that it is possible, you will need to go 'around' the FeatureWriter to supply the ID's to the SQLExecutor.

https://docs.safe.com/fme/html/FME_Desktop_Documentation/FME_Transformers/Transformers/featurewriter.htm?Highlight=featurewriter

 

I dont think that it is possible, you will need to go 'around' the FeatureWriter to supply the ID's to the SQLExecutor.

https://docs.safe.com/fme/html/FME_Desktop_Documentation/FME_Transformers/Transformers/featurewriter.htm?Highlight=featurewriter

 

Hi,

 

 

Thanks for that, I had thought about that but there is no guarantee that what is passed to the SQLExecutor or the Writer will both have the same result e.g. I pass both transformers 10 records, 9 get written by the FeatureWriter and 1 fails but 10 pass through the SQLExecutor successfully then that is wrong.

 

 

 

 

Hi,

 

 

Thanks for that, I had thought about that but there is no guarantee that what is passed to the SQLExecutor or the Writer will both have the same result e.g. I pass both transformers 10 records, 9 get written by the FeatureWriter and 1 fails but 10 pass through the SQLExecutor successfully then that is wrong.

 

 

 

 

The FeatureWriter will give you the number of features written, so you can at least verify that all features were written, though it doesn't help you identify which ones failed if they didn't.

There's an idea here for adding an output port to the FeatureWriter, which would retain all the incoming attributes. Feel free to give it your vote if you think it would be helpful in your case.

There's an idea here for adding an output port to the FeatureWriter, which would retain all the incoming attributes. Feel free to give it your vote if you think it would be helpful in your case.

Thanks David, I tried that and found that the only features in the list were the named connection and count. Otherwise that would have been perfect.

 

 

The FeatureWriter will give you the number of features written, so you can at least verify that all features were written, though it doesn't help you identify which ones failed if they didn't.
Yes, unfortunately I need the unique ID so I can pass to the audit table via my stored procedure.

 

 

Thanks David, I tried that and found that the only features in the list were the named connection and count. Otherwise that would have been perfect.

 

 

Yes, that's why we all need to vote and cross our fingers for this to be implemented :-)

 

 

While I second voting on the idea david_r suggested, to solve your actual problem, what about hooking up a featureReader to the output port of the featureWriter to read your data back in? It would require that the ID attribute is written out, but it would guarantee that only those features written would trigger the sqlExecuter.

I kind of did a bit of a workaround, which feels a bit hacky but it works and bar an initial load the amount of records going through will be only small.

Please see screen shot.capture1.png

Reply


Community Stats

30,129
Posts
114,377
Replies
37,768
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.