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:
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:
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
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:
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.
IMPLEMENTING USER NAVIGATION ON THE RECORDSET OBJECT FURNISHED BY A Data
Environment'S COMMAND OBJECT
Private Sub cmdMoveFirst_Click()
Private Sub cmdMoveLast_Click()
Private Sub cmdMoveNext_Click()
If deNWind.rsEmployees.EOF Then
Private Sub cmdMovePrevious_Click()
If deNWind.rsEmployees.BOF Then