How to prevent entity listbox from auto save?

How do I configure an entity listbox to NOT save edited entries?

I have a user that wants to be able to commit or not-commit all changes to a entity selection.

Why not use a transaction? Idea of a transaction is to bundle many modifications and confirm or deny…


: Thomas MAUL

Why not use a transaction?

Um, because I was so focused on looking at my problem from a particular direction? :lol:

Perfect - thank you.


Or maybe turn the entity selection to a collection (with the .toCollection() member method).

Work with the collection in the list box.

And push all the updates done in the collection to the database with the dataClass.fromCollection() member method ?

: Marie-Sophie LANDRIEU

Or maybe turn the entity selection to a collection (with the
.toCollection() member method).

I actually use this approach with another form/table in the same project. It’s very much like the approach of copying a selection to arrays for display and editing in 4D classic - which this project relies on heavily. Something I like about this approach is being able to add a right-hand ‘comments’ column to the listbox with notes like “New record - not saved.”

So it seems there are three basic approaches for managing data entry with listboxes using ORDA:


  • easy, 4D handles saving for you
  • little (or zero) code required, you just set up the listbox
  • values update when changed elsewhere (though you may have to poke the listbox)
  • values in related records update automatically
  • each record is handled individually
  • each record is handled individually
  • when auto saving doesn’t work there is no notice (you have to look)
  • updates of remotely changed values don’t always appear quickly


  • familiar to classic 4D approach of using arrays
  • complete control over what’s displayed or allowed to change
  • requires coding (though way less than using arrays)
  • no auto updating


  • familiar approach
  • retain all the PROS of entity selection auto updating
  • ensure all changes are saved or rejected as a whole
  • opening transactions on a form can create bottlenecks (esp. if the user leaves for lunch in the middle)
  • probably the most amount of coding to manage the save

I like Optimistic Locking very much. This is the greatest thing about using ORDA with data display. I have been able to put together extremely sophisticated forms showing inter-related data using zero code. Do the same thing in classic 4D would have required dozens of methods just to setup and more to manage saving.

Staging to collections is the appropriate approach for things like Invoices or anything financial, most likely. It provides the ability to look at the whole proposed entry, validate, check and confirm before committing. But you trade off having updates automatically.

Transactions are likely best used in concert with Staging collections. I remain hesitant to open transactions on an input form though I know lots of folks have done so for years.

This little exercise has been useful for clarifying the options.