[Previous] [TOC] [Next]

Serializing a Recordset


Two of the primary reasons for employing a custom recordset are serialization and software locking. Because passing objects across machines causes a considerable performance penalty, we need a way of efficiently moving a recordset from one physical tier to another.

Serialization allows you to export the contents of your objects (such as the variables) as a primitive data type. What can you do with this primitive data type? Well, you can use it to re-create that object in another environment-maybe in another process, maybe in another machine. All you need is the class for the object you have serialized to support the repopulation of its internal variables from this primitive data type. The process of serialization has tremendous performance advantages in that we can completely transfer an object to another machine and then utilize the object natively in that environment without incurring the tremendous performance cost that is inherent in accessing objects across machine boundaries.

The cRecordset object stores its data and state internally in four arrays. The Serialize property supports exposing these arrays to and receiving them from the outside world, so transferring a recordset from one physical tier to another is simply a matter of using the Serialize property on the cRecordset. Here's an example:

Dim oRec     As New cRecordset
  Dim oDAL     As New cDAL  ' Assume this DAL is on another machine.

  oRec.Serialize = oDAL.OpenRecordset("Employees").Serialize
  Set oDAL = Nothing
  MsgBox oRec.RecordCount

Now we have a recordset that can live independently. It can even be passed to another machine and then updated by a DAL on that machine, if required.

[Previous] [TOC] [Next]