Telerik OpenAccess Classic

Telerik OpenAccess ORM Send comments on this topic.
Returning the Container Objects to the Database
Programmer's Guide > OpenAccess ORM Classic (Old API) > Programming With OpenAccess > The OpenAccess ORM Disconnected API > Returning the Container Objects to the Database

Glossary Item Box

This documentation article is a legacy resource describing the functionality of the deprecated OpenAccess Classic only. The contemporary documentation of Telerik OpenAccess ORM is available here.

To add database objects to the container, you used the ObjectContainer method CopyFrom(). The complimentary operation is performed with the container method CopyTo(). This method works with an object scope and a verification mode:

C# Copy Code
void CopyTo( IObjectScope scope, Verify verifyMode )
VB .NET Copy Code
void CopyTo(IObjectScope scope, Verify verifyMode)

The object scope transaction must be started (Transaction.Begin() must be called) before calling the CopyTo() method. The verification mode expresses two things: which objects to verify and whether the objects corresponding to the database objects are locked when verified. It is possible to check all verifiable objects, only the verifiable objects that were modified in the container, or nothing. You can specify the verification mode with the OpenAccess.Verify enumeration. The following lists the verification mode enumeration values:

Container Verification Modes


All objects of verifiable classes are checked. You must specify which classes use container object verification.


Only those objects of verifiable classes that are marked as modified in the container are checked.


No verification checks are made.


The Verify.Lock mode can be combined with Verify.All or Verify.Changed to automatically lock the database objects that are verified:

C# Copy Code
container.CopyTo( scope, Verify.All | Verify.Lock );
VB .NET Copy Code
container.CopyTo(scope, Verify.All Or Verify.Lock)

The database objects corresponding to container objects are locked with a WRITE or READ lock depending on whether the container object has been modified or not, respectively. If any lock cannot be granted, the CopyTo() operation fails and all locks set so far in the database are released. You can retry the CopyTo() operation at a later time.

Using Verify.Lock is independent of the transaction concurrency model (optimistic or pessimistic) used by the object scope. Locking the database objects during verification ensures that they are not changed during the copy phase and between the copy and the object scope transaction commit call. Otherwise the CopyTo() operation may fail during the actual object copy if a lock cannot be granted for the object in the object scope (pessimistic scope transaction model). Or the transaction commit may fail if an object is changed after transfer from the container and before commit of the object scope transaction (optimistic scope transaction model).

The CopyTo Operation

When you call CopyTo(), the operation first verifies the optimistic concurrency information of the objects. The appropriate container object modification states are sent to the server where the corresponding objects in the database are compared and locks attempted. The complete CopyTo() operation will fail if a single object was modified in the meantime or if a lock cannot be granted.

If the there are no update conflicts and, if requested, all the locks are set, the container objects are copied to the object scope. From the point of view of the object scope, any changes to the objects were made there. You can make additional changes inside the scope and finally choose to commit or rollback the transaction. A transaction commit will write the changes to the database. You can also rollback the transaction and retry the container CopyTo() operation again at a later time.

If the CopyTo() operation fails, you will have to decide if the changes made to the objects in the container can simply be abandoned or, if not, whether it is easier to redo the changes to the container objects or to edit the container objects to bring them in line with the objects in the database. The simpler approach is to create a new container and fill it with the current database objects. In the new container, re-create the changes and again attempt to copy the container back to the database.

If re-creating the changes is not possible, you can attempt to modify the container objects to reflect the changes made in the container and the changes made to the database objects. This is, in effect, means merging the changes made to the container objects with those made, in the meantime, to the database objects. To merge the changed objects, read the appropriate objects into the object scope and make your changes to the objects in the container. When the container objects reflect the merged changes, you can retry the container CopyTo() operation.

Re-creating the container changes should be your first choice. Creating a general-case merger algorithm can be difficult, requiring extensive application-specific knowledge of the object model and the potential conflicts that can arise.

Extracting changes from the ObjectContainer

It is also possible to extract the changes from an ObjectContainer, into a new instance. The "extract" can be serialized and could be sent to an application server. The object scope on the app server side is then updated with the extracted modifications, and the underlying transaction is committed. The resulting modifications for the remote ObjectContainer are computed and replayed into it. This will evict deleted objects and mark dirty objects as clean.

The ObjectScope's transaction must not be active; it is controlled by the CommitChanges method. Serialization has been omitted here for simplicity.

C# Copy Code
ObjectContainer container = new ObjectContainer();


new Employee() );

if (scope.Transaction.IsActive)

ObjectContainer.ChangeSet c1 =
// Serialization of c1 is possible, but omitted here for simplicity.

ObjectContainer.ChangeSet c2 = ObjectContainer.CommitChanges(c1,
           ObjectContainer.Verify.Changed, scope, true, true);
// Serialization of c2 is also possible, but omitted here
// Apply will modify the container state according to the result of
// Apply will modify the container state according to the result of

VB .NET Copy Code
Dim container As New ObjectContainer()
container.Add(New Employee())
If scope.Transaction.IsActive Then
End If
Dim c1 As ObjectContainer.ChangeSet = container.GetChanges(ObjectContainer.Verify.Changed)
' Serialization of c1 is possible, but omitted here for simplicity.
Dim c2 As ObjectContainer.ChangeSet = ObjectContainer.CommitChanges(c1, ObjectContainer.Verify.Changed, scope, True, True)
' Serialization of c2 is also possible, but omitted here
' Apply will modify the container state according to the result of
' Apply will modify the container state according to the result of

The "extract" will be stored in an instance of class ObjectContainer.ChangeSet. Using this change set, your modifications (here just a new instance in the container) will be serializable with the minimal change set needed; network traffic is reduced due to this. The change set can then be applied to an IObjectScope instance. When you need to update the object container with the result of the CommitChanges method, you must Apply() the result of this method to the container. This step can be omitted, if the container is not used afterwards.

The static ObjectContainer.CommitChanges method will perform all the necessary transaction (Begin/Commit/Abort) calls, and it provides a convenient API for incorporating remote changes into a database.