We are running here into situations where a table record is suddenly locked even though its value is only read. Having a record immediately entering write-locked even if you never intend to modify it is really a bad idea.
Is it possible that the following trigger logic will still fail because Tulip is unable to process the record locks fast enough within a single trigger?
@sebme I have never seen this logic not work within the same trigger. I believe the only explanation is that another station or another record placeholder is still connected to that record. The Tulip database does not allow deletes of any records which are “active” at any station.
Well, I am afraid this is exactly what we are seeing here. The record is not loaded at any other station if you go through them. The error at the station itself says that the record is blocked by the station itself (player error in the console)… which should not be possible when this trigger is executed because as you can see in the screenshot, the placeholder is first cleared. There are two error messages thrown, the 1st complains that the trigger in the screenshot failed, the second that the deletion of the record failed because it is “in use”… 
Hi Sebastian,
it looks familiar. Try to put the Delete Record action (and the actions after) in a separate Trigger with the same IF clause.
That’s the way I go in my apps where I need to delete records.
I’m missing the counterpart of
“Load records” → “Unload record” 
HTH Chris
Yeah… the problem is we already have quite an extensive cascade of things in those triggers…
We seem to have found another area where this strange behavior seems to occur, though not in connection with the delete command. It seems to be happening only under certain circumstances, potentially when the client is under “heavy” load.
In that particular case the order of actions appears to be leading to completely different outcomes even though everything is happening inside the same rigger, and the only piece with a potential side-effect - the aggregation - always follows the clear events…
So this here…
…suddently leads to a different outcome than this here…
Notice that the only thing that has changed is the position of the clear command…
When running the same triggers in a simplified app, the outcomes are identical.
