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#]

Re: Catching CDatabase Exceptions?

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]]

Re: Catching CDatabase Exceptions?

Mike C# wrote:[color=blue]
>
> If anyone knows of any light-weight wrappers for ODBC that avoid MFC,
> I appreciate it! Thanks[/color]

How 'bout using ADO? You can use

#import "msado15.dl l" 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#]

Re: Catching CDatabase Exceptions?


"Carl Daniel [VC++ MVP]" <cpdaniel_remov e_this_and_nosp am@mvps.org.nos pam>
wrote in message news:%23PTNdhCk GHA.3440@TK2MSF TNGP02.phx.gbl. ..[color=blue]
> How 'bout using ADO? You can use[/color]

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]]

Re: Catching CDatabase Exceptions?

Mike C# wrote:[color=blue]
> "Carl Daniel [VC++ MVP]"
> <cpdaniel_remov e_this_and_nosp am@mvps.org.nos pam> wrote in message
> news:%23PTNdhCk GHA.3440@TK2MSF TNGP02.phx.gbl. ..[color=green]
>> How 'bout using ADO? You can use[/color]
>
> 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.[/color]

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#]

Re: Catching CDatabase Exceptions?


"Carl Daniel [VC++ MVP]" <cpdaniel_remov e_this_and_nosp am@mvps.org.nos pam>
wrote in message news:%23gT8BCDk GHA.4652@TK2MSF TNGP05.phx.gbl. ..[color=blue]
> 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.[/color]

I thought ADO interfaces through OLE DB?
[color=blue]
> 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.[/color]

I'll look around for it. Thanks!

[Carl Daniel [VC++ MVP]]

Re: Catching CDatabase Exceptions?

Mike C# wrote:[color=blue]
> "Carl Daniel [VC++ MVP]"
> <cpdaniel_remov e_this_and_nosp am@mvps.org.nos pam> wrote in message
> news:%23gT8BCDk GHA.4652@TK2MSF TNGP05.phx.gbl. ..[color=green]
>> 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.[/color]
>
> I thought ADO interfaces through OLE DB?[/color]

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#]

Re: Catching CDatabase Exceptions?


"Carl Daniel [VC++ MVP]" <cpdaniel_remov e_this_and_nosp am@mvps.org.nos pam>
wrote in message news:uSm7oYIkGH A.1276@TK2MSFTN GP03.phx.gbl...[color=blue][color=green]
>> I thought ADO interfaces through OLE DB?[/color]
>
> 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.
>[/color]

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]]

Re: Catching CDatabase Exceptions?

"Mike C#" <xxx@yyy.com> wrote in message
news:uRlkg.7700 $AI5.2130@fe08. lga...[color=blue]
>
> "Carl Daniel [VC++ MVP]" <cpdaniel_remov e_this_and_nosp am@mvps.org.nos pam>
> wrote in message news:uSm7oYIkGH A.1276@TK2MSFTN GP03.phx.gbl...[color=green][color=darkred]
>>> I thought ADO interfaces through OLE DB?[/color]
>>
>> 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.
>>[/color]
>
> 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 :)[/color]

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

Any luck tracking down OpenODBC?

-cd

[Mike C#]

Re: Catching CDatabase Exceptions?


"Carl Daniel [VC++ MVP]" <cpdaniel_remov e_this_and_nosp am@mvps.org.nos pam>
wrote in message news:OJDcBXNkGH A.984@TK2MSFTNG P04.phx.gbl...[color=blue]
> Well, there is that :) But at least it would get rid of MFC!
>
> Any luck tracking down OpenODBC?[/color]

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