Skip to main content
Question

Expose FeatureWriter attributes

  • April 11, 2017
  • 9 replies
  • 177 views
J
Forum|alt.badge.img

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.

 

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.

9 replies

itay
Supporter
Forum|alt.badge.img+18
  • itaySupporter
  • Supporter
  • April 11, 2017

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

 

J
Forum|alt.badge.img
  • johnbyrnejb
  • Author
  • April 11, 2017

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.

 

 

 

 

jdh
Contributor
Forum|alt.badge.img+40
  • jdhContributor
  • Contributor
  • April 11, 2017
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.
david_r
Celebrity
  • david_rCelebrity
  • April 12, 2017

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.

J
Forum|alt.badge.img
  • johnbyrnejb
  • Author
  • April 12, 2017

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.

 

 

J
Forum|alt.badge.img
  • johnbyrnejb
  • Author
  • April 12, 2017
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.

 

 

david_r
Celebrity
  • david_rCelebrity
  • April 12, 2017
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 :-)

 

 

jdh
Contributor
Forum|alt.badge.img+40
  • jdhContributor
  • Contributor
  • April 12, 2017

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.

J
Forum|alt.badge.img
  • johnbyrnejb
  • Author
  • April 13, 2017

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

Community Stats

32,206
Posts
122,292
Replies
39,887
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.