Deleting multiple rows as a set

Related products: Web and Windows GUI Universal GUI
  • 10 January 2020

The GUI supports multiselect deletion of rows for a while now. The default GUI functionality that deletes multiple rows performs too slow and even slower than a task that does the same delete actions.

Selecting all rows in a grid (more than 100) and starting the delete function takes a lot of time to ‘prepare’ the delete. Eventually a pop-up is shown with a confirmation message. Answering the confirmation message with ‘yes’ will start deleting the selected rows. The actual deletion process also takes too much time. Triggers play a role in this too.

We would like to use the default GUI delete function as a set (just as SQL prefers) instead of row for row deletion. The Software Factory could have a checkbox for it in the ‘Subjects’ screen that is called something like ‘Multi-row deletion’.

A small work-around can be achieved using multirow task execution (, for the time being. Please note that when applying this approach, it's difficult to explain to an end user that they should use the task in stead of the default ‘delete’ button (I can't explain it to non IT-users...)

But indeed it's very very slow.

This is also a bit similar to the opposite, inserting large sets of data, discussed over here:

Both deleting and inserting (import) are not using the advantages of set based operations.

Hi René,

a developer is implementing the multirow task execution as we speak.It works really well but is indeed difficult to explain to end users. In this case all other screens use the default delete function and this particular screen needs/gets a task.

Maybe the task could replace the default delete function without showing the task button? Or the task could start when pressing ‘CTRL + -’...

Linking tasks to C(R)UD actions to execute a task when clicking the Insert/Copy, Update or Delete button is a feature that is already on our (Indicium) backlog, and I like the idea to be able to use multirow tasks too. 

Regarding the performance of the current batch delete: the user interface will first check if all rows are unmodified (using a select statement) before showing the confirmation dialog. When deleting, the layout procedure is executed first to check whether it is allowed to delete the row. This should only take milliseconds per row, however.

Does the debug screen give an indication of what the delay is causing?


Updated idea status OpenNeeds feedback

Hi @K.Bakkenes,

We would still like to hear your input on the last question Jasper asked. Thanks in advance!​​​​​​

Maybe this could be solved by combining




Although it doesn't solve set based imports, which we would like to have.