Hello Harm,

Is my assumption correct that this is about refreshing in between edits of the same row? (E.g. edit field, press Enter, refresh details, edit field, etc.)

In general when e.g. a trigger or database constraint check has not had a chance yet to reject changes to a row, it is a security risk if any value for a reference column can be used to disclose data in details that would otherwise have been impossible to see.

So in order to achieve this one would not just have to call a default stored procedure for example, but also to commit the row with an UPDATE statement after every edit. This makes cancellation really hard or even impossible, plus there will be impact on how process flows behave in such situations.

I think that under strict conditions a UI could definitely behave like this, but it would have to be configurable and non-default behaviour. I have some doubts about the usefulness of such an endeavour, but I’ll be happy to be convinced otherwise.

Kind regards,

Henk

Hi Henk,

This is the scenario, what you see below is a modal form, which is used to make a production order. The master data is stored in a staging table, the detail is a view that shows calculated values. I like to refresh detail when the field “Besteleenheden” is updated.

Now we have achieved this with a refresh task (without logic). It works, but ideally the refresh task should not be necessary.