While entity objects can be modified and marked for insertion or deletion in multiple ways during some time, all these changes are saved with a call to the single SubmitChanges method. They are translated into SQL, and those CUD SQL commands are performed in the order determined by the LinqConnect runtime. This order depends on the relationships between the modified entities, and should guarantee that no conflicts occur during the SubmitChanges call. Evidently, it may differ from the order the changes were actually made in the application code.
For example, inserting a 'parent' and 'child' sides of an association may be done in either order in the application, whereas at the server the 'parent' entity should be persisted first; so LinqConnect places it before 'child' in the change queue. As another example, the opposite should take place when deleting both 'child' and 'parent': deleting 'parent' may cause a foreign key constraint violation if the 'child' still remains in the database, hence the runtime sets the 'child' deletion to be performed first.
The obvious advantages of such an approach are the following:
This section describes the details of the SubmitChanges process, the possibilities of tuning it and the ways of handling the errors that may occur when persisting data.
This topic describes how to customize Insert, Update, and Delete operations for a specific entity class.
This topic provides information concerning the most common cases of update errors and the methods LinqConnect provides for processing them.