If you've been eager to start developing Visual Basic (VB) applications to access your AS/400 data, this article is for you! The VB interactive tutorial (activated by selecting Learning Microsoft Visual Basic from the VB Help menu) is an excellent place to learn about forms, controls, properties, and event-driven programming, but it doesn't teach you a thing about accessing your AS/400 data. I'll assume you either have taken the tutorial or have some basic knowledge of how to write a standalone VB application. I'll show you how to build on that knowledge by teaching you some simple VB techniques that will help you make the transition into the world of client/server programming.
Getting your first AS/400 client/server application up and running teaches you many important concepts. To begin the excursion to full client/server enlightenment, I'll show you how to create a very simple client/server program that accesses your AS/400 database. I'll explain, step-by-step, how to create a sample program. The program will display the records from the QCUSTCDT file (or table) in the QIWS library, but you can modify the program to read any AS/400 database file.
The database access concepts you learn here will serve as a foundation upon which you can build. You need to learn many things to create a professional client/server application, but these basics will give you a place to start.
Before I show you how to create the sample application, let me briefly explain what it does. When the program runs, it asks you to select an ODBC data source, as shown in 1. (ODBC is a method of accessing external data from some PC applications, including VB. If you don't have an ODBC data source configured, check out some of the ODBC articles listed in the related reading box on page 107 for information on how to configure one.)
Before I show you how to create the sample application, let me briefly explain what it does. When the program runs, it asks you to select an ODBC data source, as shown in Figure 1. (ODBC is a method of accessing external data from some PC applications, including VB. If you don't have an ODBC data source configured, check out some of the ODBC articles listed in the related reading box on page 107 for information on how to configure one.)
In the dialog box shown in 1, you choose your AS/400 ODBC data source and press the OK button. This establishes a connection to the AS/400 and retrieves your data. The sample application is displayed as shown in 2.
In the dialog box shown in Figure 1, you choose your AS/400 ODBC data source and press the OK button. This establishes a connection to the AS/400 and retrieves your data. The sample application is displayed as shown in Figure 2.
To navigate through the records in the table, you click on the arrow buttons of the data control. The inner arrows move you backward and forward through the table one record at a time. The outer arrows with the vertical bars move you to the beginning or end of the table. As you move through the records in the table, you see the information change to reflect the field values from the current record.
The tool that allows you to create the link to the AS/400 is a data control. The data control allows you to access your AS/400 database and navigate through the records in the table. It also manages the connection with the AS/400 database and retrieves the records from the database. VB retrieves records into a special object called a recordset, which you can refer to programmatically when you require more advanced functionality. You can create recordsets from ODBC data sources using SQL statements.
As you have seen, data controls also provide the ability to navigate through the records in the recordset. Whenever you move to a different record using the data control, it automatically retrieves the field values for the new record. Bound controls then display the field values for that record on the form.
Bound controls are VB controls that you can use to display data retrieved by a data control. They are called "bound" because one way to use them is to "bind" them to a particular field in the data control's recordset. Every time the data control retrieves a record passed by the database, it sends the values for each field in that record to the corresponding controls that are bound to it. Bound controls require no code to display the values from a data control, so they are a tremendous time-saver when developing your first client/server application.
You can use bound controls to display data from the database in its appropriate format. This example uses standard VB label controls bound to a data control to display the data from the fields. Many other types of controls can be bound to a data control to display recordset data in almost any way you can imagine.
Now that you've seen what this application does, I'll show you how to create it. The application (shown in VB design mode in 3) originates from a blank VB form. First, you place a data control on the form (Label A in 3). Then, you set properties for the data control to configure it to access the AS/400 database (see 4). The Connect property is set to ODBC; (Label A in 4). Setting it to this value instructs VB to display a list of available ODBC data sources so you can choose which one to use when the program runs. I also set the value of the data control's ReadOnly property to True (Label B in 4) to avoid inadvertently updating the data.
Now that you've seen what this application does, I'll show you how to create it. The application (shown in VB design mode in Figure 3) originates from a blank VB form. First, you place a data control on the form (Label A in Figure 3). Then, you set properties for the data control to configure it to access the AS/400 database (see Figure 4). The Connect property is set to ODBC; (Label A in Figure 4). Setting it to this value instructs VB to display a list of available ODBC data sources so you can choose which one to use when the program runs. I also set the value of the data control's ReadOnly property to True (Label B in Figure 4) to avoid inadvertently updating the data.
The SQL statement that returns the records you want is placed in the RecordSource property of the data control (Label C in 4). In this case, the property is set to the value Select * from qiws.qcustcdt. You can set this property to any valid record retrieval SQL statement, so retrieving data from another table is a simple matter of changing this statement. Even complex multiple-table joins can be retrieved with the data control, using more advanced SQL statements.
The SQL statement that returns the records you want is placed in the RecordSource property of the data control (Label C in Figure 4). In this case, the property is set to the value Select * from qiws.qcustcdt. You can set this property to any valid record retrieval SQL statement, so retrieving data from another table is a simple matter of changing this statement. Even complex multiple-table joins can be retrieved with the data control, using more advanced SQL statements.
Because a library is specified in the SQL statement, I had to set the Options property (Label D in 4) of the data control as well. The Options property is actually many properties wrapped up in one. To activate the various functions of this property, you have to turn on the appropriate bit in the property's value. This isn't as bad as it may sound. In this case, all you have to do is supply the value that turns on the SQL passthrough bit. That value is 64. SQL passthrough instructs the VB database engine to pass the SQL string through to the AS/400 instead of trying to process it itself. This is necessary for this example because the VB database engine does not directly support AS/400 libraries from within SQL statements, but the AS/400 does support them.
Because a library is specified in the SQL statement, I had to set the Options property (Label D in Figure 4) of the data control as well. The Options property is actually many properties wrapped up in one. To activate the various functions of this property, you have to turn on the appropriate bit in the property's value. This isn't as bad as it may sound. In this case, all you have to do is supply the value that turns on the SQL passthrough bit. That value is 64. SQL passthrough instructs the VB database engine to pass the SQL string through to the AS/400 instead of trying to process it itself. This is necessary for this example because the VB database engine does not directly support AS/400 libraries from within SQL statements, but the AS/400 does support them.
The next step is to place the bound controls on the form. I used label controls (Label B in 3) because they are useful for displaying read-only data. To bind a label control to a data control, you set two properties. The first property to set is the DataSource property. You set this to the name of the data control to which you wish to bind. Dropping down the list box of this property displays all the data controls on the form (see 5), allowing you to choose one without typing.
The next step is to place the bound controls on the form. I used label controls (Label B in Figure 3) because they are useful for displaying read-only data. To bind a label control to a data control, you set two properties. The first property to set is the DataSource property. You set this to the name of the data control to which you wish to bind. Dropping down the list box of this property displays all the data controls on the form (see Figure 5), allowing you to choose one without typing.
The other label property you must set is the DataField property. You set this property to the name of the field you want to display in the label. Again, dropping down the list box of this property displays all the fields available from the data control if you have set your data control properties correctly (see 6). You must set the data control properties as discussed previously, because the first time you display this list, VB actually logs on to your AS/400 using your data control parameters to retrieve the list of field values.
The other label property you must set is the DataField property. You set this property to the name of the field you want to display in the label. Again, dropping down the list box of this property displays all the fields available from the data control if you have set your data control properties correctly (see Figure 6). You must set the data control properties as discussed previously, because the first time you display this list, VB actually logs on to your AS/400 using your data control parameters to retrieve the list of field values.
Once the data control and the bound fields are on the form, give the fields labels and position them so they look the way you want on the form. Label controls (Label C in 3) are also used to create the field labels. To distinguish the field labels from the actual data fields on the screen, I gave the data fields a border by setting their BorderStyle to 1 - Fixed Single. Then I set the Caption property of the field label controls to the text values that described the field. Once you set these properties, you can run the application and watch it in action.
Once the data control and the bound fields are on the form, give the fields labels and position them so they look the way you want on the form. Label controls (Label C in Figure 3) are also used to create the field labels. To distinguish the field labels from the actual data fields on the screen, I gave the data fields a border by setting their BorderStyle to 1 - Fixed Single. Then I set the Caption property of the field label controls to the text values that described the field. Once you set these properties, you can run the application and watch it in action.
As you can see, creating your first client/server application using a bound data control is relatively simple. No code is required, and you can point and click to lay out the form. The advantage of using the data control is its ease of use, but you pay a price in that it doesn't perform as well as other methods of accessing data from a remote server. For this reason, you'll need to learn many other techniques before you can implement your first successful client/server program into a production environment. However, by taking advantage of the simplicity of the bound data control, you can begin to explore client/server programming to see if it fits in your plans.
Brian Singleton is an associate technical editor for Midrange Computing. He can be reached by E-mail at
Related Reading
"Creating Client/Server Applications with ODBC" August 1994
"The ODBC Pre-Flight" January 1995
"ODBC Overview" February 1995
"An Introduction to Event-driven Programming" June 1995
"ODBC Performance Basics" August 1995
LATEST COMMENTS
MC Press Online