Catching CDatabase Exceptions?

[Mike C#]

Hi all,

'Nother question. I have a piece of code that is using the MFC CDatabase
object to connect to a database. It executes a SQL statement against SQL
Server using the ExecuteSQL() function. This brought up the question of
capturing the exceptions that are thrown by the CDatabase object. Is there
a way for me to trap it in my code and use my own error-handling mechanism?
I tried putting it in a try...catch block with no success. As always, any
ideas are appreciated!

By the way, the *only* things I'm using MFC for are the CDatabase and
CRecordset objects. Does anyone out there know of any well-tested,
"light-weight" wrappers for ODBC? (I'm stuck with ODBC for this project,
BTW). The only functions I'm using in the CDatabase and CRecordset are
ExecuteSQL() and retrieving a "scalar" value (i.e., I'm reading a single
row, single column table) via the CRecordset. I'd like to get away from MFC
completely, but also don't want to have to write my own ODBC wrappers if I
can avoid it.

Thanks!

 

[Mike C#]

I think I've found the answer. I was trying to catch a CException, but I
need to catch a CDBException.

If anyone knows of any light-weight wrappers for ODBC that avoid MFC, I
appreciate it! Thanks

 

[Carl Daniel [VC++ MVP]]

If anyone knows of any light-weight wrappers for ODBC that avoid MFC,
I appreciate it! Thanks

How 'bout using ADO? You can use

#import "msado15.dll" no_namespace rename("EOF", "EndOfFile")

to get smart-pointer based wrappers over the full ADO API. I'm not sure it
that's lighter in weight than MFC, but it's another option, and the
compiler-generated wrappers from #import more closely conform to "modern"
C++ programming conventions than MFC does.

-cd

 

[Mike C#]

How 'bout using ADO? You can use

Thanks for the thought, but unfortunately corporate policy dictates ODBC
only Since this is a big company, it takes a while to move new
technology forward. The ODBC policy is in place because several
applications rely on it, of which I'm only responsible for a couple; and
there is a group of legacy (and I mean *LEGACY*) systems that comprise the
"lowest common denominator" that these apps need to run on. Basically I'm
stuck with ODBC - if not, I'd switch them over to OLE DB and be done with it
Ideally I'd like to find a wrapper class that performs similarly to
CDatabase but without all the MFC overhead... I might just make my own,
since I'm only using a limited amount of the functionality available anyway.

 

[Carl Daniel [VC++ MVP]]

"Carl Daniel [VC++ MVP]"

How 'bout using ADO? You can use

Thanks for the thought, but unfortunately corporate policy dictates
ODBC only Since this is a big company, it takes a while to move
new technology forward. The ODBC policy is in place because several
applications rely on it, of which I'm only responsible for a couple;
and there is a group of legacy (and I mean *LEGACY*) systems that
comprise the "lowest common denominator" that these apps need to run
on. Basically I'm stuck with ODBC - if not, I'd switch them over to
OLE DB and be done with it Ideally I'd like to find a wrapper
class that performs similarly to CDatabase but without all the MFC
overhead... I might just make my own, since I'm only using a limited
amount of the functionality available anyway.

But ADO is just an interface library - you can still access the underlying
database via ODBC while using ADO as your API. At a technology level, it's
really not significantly different from using MFC. Of course, corporate
policies don't always reflect technological reality.

You might also look for "Open ODBC" on the Internet. It's a C++ class
library for accessing ODBC data sources that I used several years ago. I
have no idea what it's current state of development or support might be, but
it was usable for most simple data access needs way back when.

-cd

 

[Mike C#]

But ADO is just an interface library - you can still access the underlying
database via ODBC while using ADO as your API. At a technology level,
it's really not significantly different from using MFC. Of course,
corporate policies don't always reflect technological reality.

I thought ADO interfaces through OLE DB?

You might also look for "Open ODBC" on the Internet. It's a C++ class
library for accessing ODBC data sources that I used several years ago. I
have no idea what it's current state of development or support might be,
but it was usable for most simple data access needs way back when.

I'll look around for it. Thanks!

 

[Carl Daniel [VC++ MVP]]

"Carl Daniel [VC++ MVP]"

But ADO is just an interface library - you can still access the
underlying database via ODBC while using ADO as your API. At a
technology level, it's really not significantly different from using
MFC. Of course, corporate policies don't always reflect
technological reality.

I thought ADO interfaces through OLE DB?

Yeah, it does. But OLE DB in turn can use ODBC to access the underlying
data. Bottom line is that you don't need anything but an ODBC driver for
your underlying data source no matter which data access technology you use.

-cd

 

[Mike C#]

Yeah, it does. But OLE DB in turn can use ODBC to access the underlying
data. Bottom line is that you don't need anything but an ODBC driver for
your underlying data source no matter which data access technology you
use.

But if I were to use ADO to access OLE DB to access ODBC... Well let's just
say my main purpose in re-designing these apps is to enhance performance

 

[Carl Daniel [VC++ MVP]]

But if I were to use ADO to access OLE DB to access ODBC... Well let's
just say my main purpose in re-designing these apps is to enhance
performance

Well, there is that But at least it would get rid of MFC!

Any luck tracking down OpenODBC?

-cd

 

[Mike C#]

Well, there is that But at least it would get rid of MFC!

Any luck tracking down OpenODBC?

Not yet, I spent the day adding error logging functionality to this app.
But tomorrow's another day Thanks!