If you switch to FeatureWriters instead of standard writers I think you'll be able to handle the failure via the rejected port so the workspace will still complete.

I've just realised the FeatureWriter doesn't have a rejected port, was thinking of a FeatureReader

https://community.safe.com/s/bridea/a0r4Q00000HbqeEQAR/ignore-failed-writers

It might also work to change the parameter "Ignored failed readers" to yes?

Tried this one, but it failed. I think because there's no ip-connection to the database and thus FME cannot "check" if it can write to the database. It probably will work if there is a connection, but the write fails. Thanks for the tip anyway, cause I had not noticed this parameter before!!

I'm surprised that you say this check is happening at the beginning of the workspace, as in my experience that doesn't happen. See

https://community.safe.com/s/bridea/a0r4Q00000HbqcWQAR/check-writer-accessibility-when-a-workspace-is-started

If it's not something that happens on startup there should be a way of handling it in the workspace

Well, probably not specifically on start up, but (I think) it first tries to perform to write 1 feature to (all) writers (and quits or not, according the "Ignored failed readers"-parameter). But in order to write to a (database)writer 1) you have to have access to the (location of the) database (ip-connection) and 2) you have to have acces (authorised, database not locked etc) to the database. It looks now that if 1) fails it is enough to stop the workbench no matter the "Ignored failed readers"-parameter.

The check is not upfront so you can just check whether the database is accessible in your workspace and then stop features from hitting the writer if the database isn't accessible. I'd test just using a simple Select 1 statement in an SQLcreator and then use that result to determine the flow of features in the workflow

Tried it that way, with SUCCESS!!!

Thanks very much 💪 👍

ebygomm's answer does the tric. Thanks anyway sigtill 👍