(Tutorial) Managing Database Operations Using ADO And C++

Managing Database Operations Using ADO And C++

Now that we have gone over the basics, described a way to design and create ADO wrapper classes, it is now time for the final phase of creating an ADO manager class that will work on all the concepts we have discussed. Our final goal with this design is to use as little code as possible in running any of the desired SQL operations against the database. Without this ADO manager class, every time we needed to perform some kind of operation we would have to set up the correct ADO wrapper classes, initialize them, set up our list of desired parameters, queries, etc and then execute the SQL command, check its status and perform error handling if something went wrong.

We would then have to look at the returned recordset and get the data from it. This would have to be done repeatedly for every time we wanted to access any part of the database. It would result in an enormous amount of repetitious code throughout our application. If we can design this ADO manager class correctly it will be much easier to do ADO database operations and will make any code changes for future database changes much easier. Things like adding or deleting columns and tables or any time a procedure changes in our database schema will require fewer code changes.

In designing the ADO manager class, we need to enumerate what the ADO manager class should do. Here is a list of some of the things we need:

• Seamlessly use the ADO wrapper classes to perform ADO operations.

• Execute the basic SQL operations of DELETE, INSERT, SELECT and UPDATE on a given table in the database.

• Handle the various differences of the parameter signatures that exist from procedure to procedure.

• Execute 'user defined' SQL queries and stored procedures.

• Iterate through a returned set of records.

To address the seamless use of the ADO wrapper classes is fairly easy. We will declare a set of pointers that point to each one of the ADO wrapper classes that we need. During normal operation of calls to the ADO manager class, the use of any one of these classes will be hidden from the caller. If these classes need to be persistent, they will either be assigned at instantiation or will be dynamically allocated at the ADO manager class instantiation. In other cases, the class will simply be initialized and deleted as needed. For example, the CADOConnection class will have been previously initialized. The pointer to this initialized class will be passed into the initialization of the ADO manager class. As another example, the CADOParameter class will need a new allocation that needs to be passed into ADO for each parameter that is needed for the procedure, so this will be a class member that will be allocated and deleted dynamically as needed.

To execute the basic DELETE, INSERT, SELECT and UPDATE procedures this will simply be a set of public functions that the caller will call named after the operation that is needed. These functions will operate only on tables in the database; USERQUERY will operate only on user defined queries or stored procedures. Calling any of these functions will automatically configure our ADO manager class to operate in the manner that is necessary to accomplish the database operation.

void ADO_USERQUERY();
void ADO_DELETE();
void ADO_INSERT();
void ADO_SELECT();
void ADO_UPDATE();

The following is a short list of available 'name mangled' parameter and value functions. This list does not cover every available column type that exists in a database table. These are the functions that are used in our inherited class that publicly inherites CADOManager. These are helper functions that make it easier to manage our ability to perform the database operations on the various queries and stored procedures we need to call. .[..]

Read full article..
Courtesy : Cprogramming.com