Re: How do I use ADO in VC++ 6.0 to get the columns names of the t



Greg wrote:
Thanks to everyone for Your help (especially to Bob)
I solved my problem similar to a little snippet attached below:

_bstr_t table = "test"; //table name

DAO::RecordsetPtr pRec = CurrDB->OpenRecordset(table);

DAO::FieldsPtr pFields = pRec->GetFields();

pRec = CurrDB->OpenRecordset(query);

pFields = pRec->GetFields();

for (short nIndex=0; nIndex < pFields->Count; nIndex++)
{
_variant_t name;

name = pFields->GetItem(nIndex)->GetName();
}

pRec->Close();
pRec = NULL;

(is it right?)

It works, doesn't it?
The thing is, you're using DAO (Data Access Objects) rather than ADO
(ActiveX Database Objects). Nothing wrong with that: DAO was the original
programmatic data access method created for the Jet (Access) database
engine. It was developed and in use for many years and as such, is a very
robust library for working with Jet databases. If the only database engine
you are planning to work with is Jet, you could conceivably go through the
rest of your programming life without making a single call to the ADODB or
ADOX libraries.

It's when it comes to accessing other databases that problems appear. Near
the end of DAO's life, MS attempted to tack on code to allow it to use ODBC
to work with other database engines, and after a couple years, came to the
conclusion that DAO was not going to be suited for this: it was too tightly
integrated with the Jet database engine. So they started work on ADO, and,
when they proved to themselves that it would be viable, they deprecated DAO
and concentrated their efforts on perfecting ADO - something that never
happened of course, due to the introduction of .Net: ADO is pretty robust
but there are still minor issues with it that will never get resolved
because it has now been deprecated in favor of ADO.Net.

You see, MS came to the conclusion that since ADO was based on COM, it had
issues (mainly security) that prevented it from being a good tool to use for
web-based distributed programming. Thus, the introduction of ADO.Net, which
is based on managed .Net libraries. ADO.Net is out-of-scope for this group
(which explains the lack of traffic here - MS has adonet groups set up for
supporting ADO.Net questions).

So, back to the DAO vs. ADO decision:
1. You could make the choice to tackle the learning curve for DAO,
postponing the ADO learning curve until later. The thing is, you will likely
be on your own - there is still a group in the Access hierarchy devoted to
DAO questions, but they concentrate on Access VBA, not C++. It's been years
since I wrote or maintained DAO code so the help I can give will be limited
to pointing you at google searches, etc., and of course, I've never written
C++ myself.
2. You can discard your attempt to use DAO, and tackle the ADO learning
curve now. We're still here to help with that so you won't be on your own.
3. You can try to tackle both learning curves simultaneously: the problem is
some confusion can arise because both libraries have objects with the same
names ("recordset" for one) so you will need to be very explicit when
referring to such objects, something which I gather C++ forces one to do so
that might not be an issue.
4. You can decide to make the plunge into the .Net world. The plus is you
will find a lot of support, because that is the current MS strategy and
thousands of programmers are using it. The downside is the lack of support
..Net provides for working with Jet: you might find yourself having to use
Interop to work with ADO or DAO anyways ... but things might have changed in
this regard ... run this by the ADO.Net guys and see what they have to say.

--
Microsoft MVP - ASP/ASP.NET - 2004-2007
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"


.



Relevant Pages

  • Re: Databases - DAO and ADO
    ... Jet or ODBC? ... DAO or ADO? ... While I wait for additional books to arrive (just bought VB6 Database for ...
    (microsoft.public.vb.general.discussion)
  • Re: How to enforce subtypes/supertypes in Access 2000?
    ... DAO is the native object model for Jet databases and, as such, is the ... ever need ADO. ... Private Sub SetContactType() ...
    (microsoft.public.access.tablesdbdesign)
  • Re: What Database model should I use?
    ... ADO is more modern then DAO. ... I would convert Jet to ODBC, but there are other ways too ... >> You do realise that VB can use the Jet database engine, ...
    (microsoft.public.vb.database)
  • Re: What Database model should I use?
    ... I PROBABLY want to eventually convert the local tables from JET ... Google search on ADO and DAO? ... >> I should have said convert to a real SQL database. ...
    (microsoft.public.vb.database)
  • Re: Knowledge Base Help Not working
    ... Database is a DAO object. ... both Access 2000 and 2002 use ADO. ... Microsoft DAO 3.6 Object Library, ... For example, to ensure that you get a DAO recordset, you'll need to ...
    (microsoft.public.access.formscoding)

Loading