I'm developing C++ based applications for Win32 targets, and while I'm
using VStudio.NET 2k2, I don't intend to generate managed C++ targets
(they seem sluggish to me).

The various applications I'm building must provide customers the
option of using MS SQL, Firebird or perhaps the recent MySQL. To that
end I was considering ADO, until I realized the licensing expense for
ODBC clients for Firebird (back when 1.0 was "new", the IBPhoenix
driver was not quite functional, and the XTG driver was the only one I
could get to work).

Then, the Firebird.NET provider became available, and I saw what may
have been a reasonable choice. I set out to build a set of objects
that would allow an application built upon unmanaged C++ code to make
use of the ADO.NET platform (making a mixed target product - ADO.NET
is based upon managed C++ targets), which gave a consistent means of
application development which could easily switch between MS SQL,
Firebird, MySQL and possibly other ADO.NET compliant databases (the
object library I was making would take care of differing behaviors of
these engines, minor as they are).

I took a break for other project work, and now that I return, research
indicates Firebird is almost ready for version 1.5 (RC8 as of this
post), and Firebird.NET provider is at RC4 of it's version 1.5. At the
same time, it seems the IBPhoenix ODBC client is, at last, out in
version 1.1, and a beta of 1.2 is also available.

All that is background to my central question:

Would I expect better performance and ease of development, with
respect to unmanaged C++ targets, to work with ADO, relying upon the
ODBC provider from IBPhoenix for Firebird (and the known ADO access
for the other engines), or would I do better to continue with the
mixed mode project (which is about 50% finished, partly functional)
and depend upon ADO.NET?

To refine my question, let me add these points. In ADO.NET, much use
is made of the DataReader, which is a managed C++ object. Using it
would mean most of my application code would also be managed, and I
witness a slower performance than I do in unmanaged targets, so I
decline to use the DataReader quite as much as the application
tutorials and literature recommend. Instead, I populate STL containers
and use them, relegating the DataReader to the one unique feature I'd
enjoy having - it's nearly automated output of XML.

On the other hand, I have an ADO based object library that's about 80%
complete, and obviously with Firebird that would mean IBPhoenix ODBC
drivers, or the XTG drivers when customers might prefer.

The MSDN material suggests ADO.NET is the future, but I've lost count
how many times that's been said, only to have a new future thrust
before us. To believe the MSDN material, all new projects should make
use of ADO.NET, but then they expect us to shift either to C#, VB or
write managed C++ targets. The don't seem to think unmanaged targets
should have easy access to the ADO.NET platform, at least that I've
determined; yet it IS possible to make a mixed mode object such that
unmanaged code "doesn't know" the data is coming from a managed
subset.

I hesitate to jump back in unless I can hear some convincing replies
that tell me ADO.NET is either so much faster, or better for some
intangible reason, that using ADO in new material is somehow
illogical.

Any ideas and experience on these topics? Please jump in...