Simple ODBC classes without MFC

Introduction

I have written a lot of database apps. Most of them have been small, and I soon realized that the CRecordset class was the only class requiring MFC for the majority of those apps. So, I sat down and wrote these classes to provide most of the functionality I needed and so I could get rid of MFC dependancies.

These classes are extremely basic, and provide little use for someone who does not use the ODBC API directly. However, for those of you that do use the API, you might find them useful.

There are three classes in this collection, CODBCCnx, CODBCQuery and CODBCFatQuery (you can find them all in the files ODBC.h and ODBC.cpp.) CODBCCnx is the most complex (so far), it creates the connections to the DBMS and allows you to easily share those connections. CODBCQuery and CODBCFatQuery really don't do much yet, but sometime in the near future I plan on adding functionality to them. For now, they are basically coming along for the ride, because they are in the same files ;)

CODBCCnx class

CODBCCnx provides three functions, Connect(), Disconnect() and IsOk(). The Connect() function allows you to connect either through a DSN or by using the computer's network name.

//connecting to a DBMS through a DSN, "foodsn"


CODBCCnx dsn();
dsn.Connect("foodsn","username","password");

//NOTE: CODBCCnx dsn("foodsn",username","password"); is the same as above


//checking to see if we are connected

if(!dsn.IsOk()){
	//we are connected

}
else{
	//we are NOT connected

}

//connecting using a computer name on the network

CODBCCnx name("SQL Server","CompName","username","password");
//again, checking to see if we are connected

if(!name.IsOk()){
	//we are connected, and there was much rejoicing

}
else{
	//not connected

}

Ok so now we are connected, lets disconnect from the database. The Disconnect() function forces you to make a decision on how you want to disconnect. Because there might possibly be transactions still going on, you can either roll them back, or wait for them to commit. If you do not provide a value for the parameter, calling Disconnect rolls the transactions back by default.

//disconnecting from above connection (dsn)

dsn.Disconnect();	//this rolls all uncommitted transactions back

//NOTE: dsn.Disconnect(SQL_ROLLBACK) is the same thing



//disconnecting from above connection, name

name.Disconnect(SQL_COMMIT); //this forces all uncommitted transactions to finish.

CODBCQuery class

Ok, so we have connected and disconnected, big deal. The nice thing about these classes is being able to share that connection we just made. This is where CODBCQuery comes in. CODBCQuery is not really useful by itself, but it is quite a handy class if you use it as a base class. The only thing note worthy about it, is the constructor, and the public statement handle. Code speaks well....

//establish a connection using dsn

CODBCCnx *pDsn = new CODBCCnx("foodsn", "username", "password");
CODBCQuery qry1, qry2;

if(!pDsn->IsOk())
{
	//connected!! now lets share some connections :)

	pDsn->Connect(qry1.h_qstmt);
	pDsn->Connect(qry2.h_qstmt);
}
else{
	//not connected

}

//or we can do everything in one step

CODBCQuery qry(new CODBCCnx("foodsn", "username", "password"), true);

//or we can take the pDsn and pass it to a bunch of new query objects

CODBCQuery qry2(pDsn), qry3(pDsn,false);

//or we can have the CODBCQuery class connect itself

CODBCQuery qry4("SQL Server", "CompName", "username", "password");
//using a DSN

CODBCQuery qry5(NULL, "foodsn", "username", "password");

As you can see in the above code snippet, the constructors for CODBCQuery are pretty flexible. The most important thing to note is the boolean flag. If you pass the value true, CODBCQuery will delete the pointer. However, if you pass just the pointer or false as well, then CODBCQuery will NOT delete the pointer.

One final note. There is a global function, SQLSuccess(). You pass it a SQLRETURN variable, and it will return a non-zero value if the SQLRETURN value is either SQL_SUCCESS or SQL_SUCCESS_WITH_INFO I just simply grew tired of typing those out ;)

The only thing left to do after all this connecting and sharing is to bind variables to result sets. Which I leave for you to do :)

I didn't provide a demo, because I feel that these classes are too simple to warrant one. However, if you would like one give me a holler and I will gladdly provide you with one.

Dependancies

If you look at the code, there are two files, strutil.h and strutil.cpp. They are very simple functions to handle char*. I found all the work you have to go through allocating memory for strcpy, etc.. annoying. So I replaced them with the funcs in those files. To prevent name collisions, I put them in the jkl_str namespace. I hope you find them useful.

History

5 Nov 2001 - updated download