Yes, you do need a writer.
One of the great things about FME is that the vast majority of the operations you perform within the workbench (generally, SQLExecuter is one exception) are done in memory within the FME Environment and the source/destination data is only updated/inserted/deleted when the features are passed to a writer.
This means you can "play" around with data with little to no risk of making unwanted changes
Yes, you do need a writer.
One of the great things about FME is that the vast majority of the operations you perform within the workbench (generally, SQLExecuter is one exception) are done in memory within the FME Environment and the source/destination data is only updated/inserted/deleted when the features are passed to a writer.
This means you can "play" around with data with little to no risk of making unwanted changes
Hi,
I understand if I wanted to commit changes of attributes only happened after writing it back to same GDB. But can we write THE SAME gdb which already working as Reader?
I have checked it and not able to do it, so what is did is I took a copy of the Reader GDB and committed the changes.
Please correct me if I was wrong and looking for any enlightening.
Thanks.
Hi,
I understand if I wanted to commit changes of attributes only happened after writing it back to same GDB. But can we write THE SAME gdb which already working as Reader?
I have checked it and not able to do it, so what is did is I took a copy of the Reader GDB and committed the changes.
Please correct me if I was wrong and looking for any enlightening.
Thanks.
It sounds like you're trying, but are getting some errors? What are the errors?
Yes, you can read and write to the same GDB. As a GDB doesn't support multi editors/readers, its always worth making sure you have completed the read of you data before you begin the writes.
Some workflows won't need this changed as the logic in them will be blocking by nature, but if your workspace doesn't do this, its worth putting a feature holder in after the reader so you complete the read before doing anything else. This of course does have its downside as you're no holding all your features in memory
Hi, I'm not sure I expressed my question correctly so here is a bit of background. I am working with an existing workbench that receives the file it is working on from a cursor in python. The python script goes through a generated list performing the transformations in the workbench and generating an output. What I am looking to do is read on all the records in the FGDB with a field x value of null, loop through the rows that meet the where clause performing the previously mentioned transformations, and then populate the null cell in the filed that the query was performed on with some like "processed". I have successfully updated the table in memory but I want to commit those changes as well, with out overwriting the feature class. So are there writers that commit changes to existing and do not create new?
Hi, I'm not sure I expressed my question correctly so here is a bit of background. I am working with an existing workbench that receives the file it is working on from a cursor in python. The python script goes through a generated list performing the transformations in the workbench and generating an output. What I am looking to do is read on all the records in the FGDB with a field x value of null, loop through the rows that meet the where clause performing the previously mentioned transformations, and then populate the null cell in the filed that the query was performed on with some like "processed". I have successfully updated the table in memory but I want to commit those changes as well, with out overwriting the feature class. So are there writers that commit changes to existing and do not create new?
Yes, you need to set the writer mode to update, it defaults to insert
https://docs.safe.com/fme/html/FME_Desktop_Documentation/FME_ReadersWriters/DatabaseWriterMode/writer_mode.htm