On what table does this 'status' attribute sit? if it is on this pdf table, then there's no way you would ever end up with a status = 0. If FME writes the row it does, if it doesn't, it doesn't.
If you're worried about failures, validate the data before you write to be sure there's nothing wrong with it.
If the database itself is unreliable, then you could structure your process to read both your input files and the current output table, compare and find what needs to be written, and write to the database what needs to go. At the end of the process filecopy the pdfs to somewhere else to mark them as processed. So if the database falls over, your input files are still there and you can safely retry, and the workspace also tells you what the difference is.
On what table does this 'status' attribute sit? if it is on this pdf table, then there's no way you would ever end up with a status = 0. If FME writes the row it does, if it doesn't, it doesn't.
If you're worried about failures, validate the data before you write to be sure there's nothing wrong with it.
If the database itself is unreliable, then you could structure your process to read both your input files and the current output table, compare and find what needs to be written, and write to the database what needs to go. At the end of the process filecopy the pdfs to somewhere else to mark them as processed. So if the database falls over, your input files are still there and you can safely retry, and the workspace also tells you what the difference is.
If I have to write 10000 files to the database, I want to be able to pause at some point. I just wanted some method to secure that all the files would be written. What you write makes absolute sense. This seems like the way to go:
If the database itself is unreliable, then you could structure your process to read both your input files and the current output table, compare and find what needs to be written, and write to the database what needs to go
