Although you can bind controls to Command objects of the Data Environment Designer
in the VB design environment, you will sooner or later need more control over this data than
that afforded by automated design-time binding of controls.
To manipulate the data exposed through a Data Environment's Connections
and Commands, you typically program the Recordset object returned by a Command object.
When you add a Data Environment to your VB project, the Data Environment becomes
available to the project's code as a variable, taking on the name you gave it when you created
it (or the default name if you did not change the name). This is similar to what happens when
you add a form to your project. (The form becomes available in code under the name you gave it
or allowed it to take by default.)
Just as the objects contained in a form or in containers contained by the
form are available in code by referring to them with dotted syntax (FormName.Object or FormName.ContainerObject.Object),
so objects contained in the Data Environment become available in code in the following formats:
DataEnvironmentName.ConnectionName
DataEnvironmentName.CommandName
Even though a Command object is logically subordinate to a Connection object
in the Data Environment Designer's visual hierarchy and, in fact, depends on a Connection
object for its existence, the Command object must be referred to as directly belonging to
the Data Environment.
This is in keeping with the ADO object model's "flat" object hierarchy.
This also implies that no two Command objects can have the same name in a Data Environment,
even if they are under different Connection objects.
When your project runs and the physical connection is established, the Command
objects return Recordset objects. The name of each Recordset object is available in code in
the following format:
DataEnvironmentName.rsCommandName
In other words, the environment automatically creates a Recordset object as
a property of DataEnvironment. The environment automatically assigns the Recordset a name based
on the name of the Command object that supports it: Its name will be "rs" plus the
CommandObject name.
If you had created a Command object named Employees under a Data Environment named
deNWind, for example, you could refer to the Recordset in your code as this:
deNWind.rsEmployees
You can manipulate a Recordset programmatically with methods and properties,
as discussed in the section titled "Programming
with ADO" and more particularly under the section titled "Programming
with the Recordset."
If you bind TextBox controls to a Data Environment's Recordset as discussed
in the preceding section, for example, you will usually want to give the user the ability to
navigate the rows of the Recordset as displayed in the controls. One way to accomplish user
navigation would be to add four CommandButtons whose Click event procedures are called, respectively,
the MoveFirst, MoveLast, MoveNext, and MovePrevious methods of the Recordset object, as illustrated
in Listing 8.1.
The code in the listing assumes that there is a Data Environment Designer named
deNWind and a Command object named Employees. The environment then creates a Recordset named
rsEmployees (based on the Command object's name).
The code in the listing manipulates this Recordset object through the Data Environment.
LISTING 8.1
IMPLEMENTING USER NAVIGATION ON THE RECORDSET OBJECT FURNISHED BY A Data
Environment'S COMMAND OBJECT
Private Sub cmdMoveFirst_Click()
deNWind.rsEmployees.MoveFirst
End Sub
Private Sub cmdMoveLast_Click()
deNWind.rsEmployees.MoveLast
End Sub
Private Sub cmdMoveNext_Click()
deNWind.rsEmployees.MoveNext
If deNWind.rsEmployees.EOF Then
deNWind.rsEmployees.MoveLast
End If
End Sub
Private Sub cmdMovePrevious_Click()
deNWind.rsEmployees.MovePrevious
If deNWind.rsEmployees.BOF Then
deNWind.rsEmployees.MoveFirst
End If
End Sub
