VB6 beginners tutorial - Learn VB6

Advanced VB6 tutorial - Learn Advanced VB6

Systems Analysis - System analysis and Design tutorial for Software Engineering

You are here: Visual Basic > Advanced VB6 tutorial > Chapter 8

Programming With a Data Environment Designer in Visual Basic 6

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 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:


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.



Private Sub cmdMoveFirst_Click()
End Sub

Private Sub cmdMoveLast_Click()
End Sub

Private Sub cmdMoveNext_Click()
If deNWind.rsEmployees.EOF Then
End If
End Sub

Private Sub cmdMovePrevious_Click()
If deNWind.rsEmployees.BOF Then
End If
End Sub

See Also


<< Previous | Contents | Next >>

Home | About Us | Privacy Policy | Contact Us

Copyright © | All Rights Reserved