What Is IDO Collection?

IDO Collection Explained

When a form opens or an integration calls LoadCollection, the IDO runtime executes the underlying query and returns a collection object rather than a raw result set. Each row carries the requested property values and a state marker. As the user edits fields or a script modifies values, rows flip to a modified state; new rows are marked inserted, removed rows marked deleted. UpdateCollection then sends only the changed rows back, and the runtime generates the corresponding SQL.

This state tracking is what makes optimistic concurrency work. The collection typically carries a row-pointer or timestamp value captured at load. If another user changed the same row in the interval, the update fails rather than silently overwriting their work. Developers meeting SyteLine for the first time often encounter this as a puzzling update error; the correct response is to reload the collection and reapply the change, not to disable the check.

In form scripting and extension classes, the collection is the object you actually manipulate. Scripts read and set property values by name for the current row, iterate rows, insert new ones, and mark rows for deletion, then call update to persist. Because the API works in property names rather than column names, scripts stay readable and survive schema changes that leave the property mapping intact.

Two practical constraints matter. First, collections are memory-resident, and LoadCollection honours a configured record cap, so a request expecting fifty thousand rows may quietly receive far fewer. Always paginate deliberately and verify counts. Second, a collection is a snapshot - it does not track database changes made after the load, so long-lived collections in a batch process can operate on stale data and should be refreshed at sensible intervals.