While the database objects are easy to code, they sometimes can adversely affect performance. Coding to the APIs and to stored procedures can be a frustrating endeavor. Fortunately, if you are using Visual Basic Enterprise Edition in the Windows® 95 environment, there are additional options. These options are a good compromise between the usability of database objects and the high performance of APIs: Remote Data Objects (RDO) and Remote Data Control (RDC).
RDO is a thin layer over the ODBC APIs. It provides a simple interface to advanced ODBC functionality without requiring programming to the API level. It does not have all of the overhead of the Jet Engine controlled Data Access Object (DAO) or its SQL optimizer. Yet it maintains a nearly identical programming interface as the DAOs. If you understand programming to the DAO, then switching over to the RDO is relatively simple compared to trying to switch over to API calls.
The following are differences between DAO and RDO:
- The DAO model is used for ISAM, Access and ODBC databases. The RDO model is designed for ODBC databases only, and it has been optimized for Microsoft® SQL Server 6.0 and Oracle.
- The RDO model can have better performance, with the processing being done by the server and not the local machine. Some processing is done locally with the DAO model, so performance may not be as good.
- The DAO model uses the Jet Engine. The RDO model does not use Jet Engine, it uses the ODBC backend engine.
- The RDO model has the capability to perform synchronous or asynchronous queries. The DAO model has limitations in performing these type of queries.
- The RDO model can perform complex cursors, which are limited in the DAO model.
The RDC is a data control similar to the standard data control. This means that where ever you might have used a data control, and the Jet engine, you now can use the RDC. You can drag a "data aware" control on your form. It can be bound to an RDC, as it could be bound to a regular data control.
Some of the advanced ODBC functionality the RDO allows is prepared SQL statements, multiple result sets, and stored procedures. When Jet executes a SQL statement dynamically it is a two-step process on the iSeries™ server. In the first step, the iSeries server looks at the statement and determines the best plan to retrieve the data requested based on the current database schema. In the second step, that plan is used to actually retrieve the data. Creating that plan can be expensive in terms of time because the iSeries server has to evaluate many alternatives and determine the best way to access the data. There is an alternative to forcing the iSeries server to recreate the access plan every time a SQL statement is run. The CreatePreparedStatement method of the rdoConnection object allows you to compile a data access plan on the iSeries server for an SQL statement without executing it. You can even include parameters in prepared statements, so you can pass new selection criteria every time you run the select statement.
The following sample Visual Basic code will show how to prepare a SQL statement with a parameter marker and run it multiple times with different values.
Label A shows where the SQL statement is defined. Notice that the statement does not include a specific for the CUSTNUM, but has a question mark for the value. The question mark signifies that this value is a parameter of the prepared statement. Before you can create a result set with the prepared statement, you must set the value of any parameters in the statement.
Label B shows where the value for the parameter is defined. Notice that the first parameter is defined as 0 not as 1. Once the value for the parameter is set you can run the OpenResultSet method of the rdoPreapredStatement to return the requested data.
Before you can re-query a prepared statement on the iSeries server, you have to make sure that the cursor has been completely processed and closed. Label C shows the MoreResults method of the rdoResultSet being used to do this. The MoreResults method queries the database. It determines if there is any more data in the result set to be processed, or if the result set has been processed completely. Once the cursor has been fully processed you can reset the parameter value and run the ReQuery method of the rdoResultSet to open a new result set.