Synchronizing a Recordset
After a cRecordset object has been used by UpdateRecordset to successfully update the data source, the cRecordset object needs to have the same changes committed to itself, which is accomplished by means of the Synchronize method.
Using the Synchronize method will remove all Deleted rows from the recordset and will set any Updated or Created rows to Read status. This gives the developer using the cRecordset object control over committing changes and also means the recordset state can be maintained in the event of an UpdateRecordset failure. Here is an example of synchronizing a recordset after a row has been updated:
oDAL.UpdateRecordset oRec oRec.Synchronize Parameters
Simply supplying the name of a cRecordset object to OpenRecordset is usually not enough information, except maybe when retrieving entire sets of data, so we need a way of supplying parameters to a DAL cRecordset operation.
This is achieved by using a cParams object. The cParams object is simply a collection of cParam objects, which have a name and a value. The cParams object, like the cRecordset object, can also be serialized. This is useful if the parameters need to be maintained on another machine.
CParams Interface
| Member | Description |
| Add | Adds a new cParam object with a name and a value |
| Item | Returns a cParam object |
| Count | Returns the count of collected cParam objects |
| Remove | Removes a cParam object |
| Serialize | Converts or sets the content of cParams object into an array |
CParam Interface
| Member | Description |
| Name | Name of the parameter |
| Value | Variant value of the parameter |
Here is an example of retrieving a recordset with parameters:
Dim oDAL As New cDAL
Dim oRec As New cRecordset
Dim oPar As New cParams
oPar.AddField "EmpID", "673"
oPar.AddField "CurrentlyEmployed", "Yes"
Set oRec = oDAL.OpenRecordset("Employees", oPar)
MsgBox oRec.RecordCount
We can see now that only two well-defined objects are parameters to the DAL-cRecordset and cParams-and both of these objects support serialization, giving a consistent, distributed operation-aware interface.
Commands
A lot of database operations do not involve, or should not involve, cRecordset objects. For instance, checking and changing a password are two operations that do not require the overhead of instantiating and maintaining a cRecordset. This is where you use the ExecuteCommand method of the DAL. The ExecuteCommand method takes as parameters both the name of the command to perform and a cParams object.
Any output cParam objects generated by the command are automatically populated into the cParams object if they are not supplied by default. Here's an example of checking a password:
Dim oDAL As New cDAL
Dim oPar As New cParams
oPar.Add "UserID", "637"
oPar.Add "Password", "Chebs"
oPar.Add "PasswordValid", "" ' The DAL would have added this output
' parameter if we had left it out.
oDAL.ExecuteCommand "CheckPassword", oPar
If oPar("PasswordValid").Value = "False" Then
Msgbox "Sorry Invalid Password", vbExclamation
End If
Transactions
Most corporate data sources support transactions; our DAL must enable this functionality as well. This is relatively easy if you are using data libraries such as DAO or RDO, since it is a trivial task to simply map these transactions onto the underlying calls. If your data source does not support transactions, you might have to implement this functionality yourself. If so, may the force be with you. The three transaction commands are BeginTransaction, CommitTransaction, and RollbackTransaction.
The DAL is taking care of all the specifics for our transaction, leaving us to concentrate on the manipulation code. In the case of a transaction that must occur across business objects, we'll see later how these business objects will all support the same DAL. Here's an example of updating a field inside a transaction:
Dim oRec As New cRecordset
Dim oDAL As New cDAL ' Assume local DAL so don't need serialization
With oDAL
.BeginTransaction
Set oRec = oDAL.OpenRecordset("Employees")
With oRec
.Edit
.Fields("FirstName") = "Steve Gray"
.Update
End With
.UpdateRecordset oRec
.CommitTransaction
End With
Wrap Up
So that's a look at how our abstracted data interface works. I hope you can see how the combination of cDAL, cRecordset, and cParams presents a consistent logical interface to any particular type of data source. There is comprehensive support for distributed operation in the sense that the DAL is completely stateless and that the input and output objects (cParams and cRecordset) both support serialization.