There is also support for updating data through a ProDataSet. This can be more complicated than performing individual database record updates because a ProDataSet, by its very nature, represents a set of related records, possibly in many tables, which are likely to be changed in one session (in a client session, typically) and then returned to a server session to be applied to the database or other data source. The ProDataSet therefore needs a standard way to keep track of multiple changes, to identify which records have been modified, added, or deleted. It also needs to keep track of the original or before-image versions of modified or deleted records, so that the server can verify whether records have been changed by other users since they were read, and then apply all changes to the database either in a single transaction or in multiple transactions, as appropriate.
The server must also be able to return errors to the client and pass back the final versions of records that might have been further changed on the server. All this is done in a consistent way with a substantial level of default support from the ProDataSet methods, plus events to allow the process to be extended through custom ABL code at all the appropriate places. As changes are made to the ProDataSet's tables, they are logged within the ProDataSet so that, when the ProDataSet is returned to the server, processing the changes and applying them to the database is straightforward.
