If you use ADO, then OLEDB is generally better than using ODBC, if an OLEDB database manager driver is available for the provider in question. [/b][/i][/u][sub]*******************************************************
General remarks:
If this post contains any suggestions for the use or distribution of code, components or files of any sort, it is still your responsibility to assure that you have the proper license and distribution rights to do so!
OLEDB can not be used directly from within VB because of VB does not support all the datatypes used by OLEDB. If you want to use OLEDB, you've got to go through ADO (which is actually a wrapper around the OLEDB interfaces).
Greetings,
Rick
Hmmm... [/b][/i][/u][sub]*******************************************************
General remarks:
If this post contains any suggestions for the use or distribution of code, components or files of any sort, it is still your responsibility to assure that you have the proper license and distribution rights to do so!
I was thinking more on the line of creating your own OLEDB.
I guess you are talking about an existing OLEDB provider. [/b][/i][/u][sub]*******************************************************
General remarks:
If this post contains any suggestions for the use or distribution of code, components or files of any sort, it is still your responsibility to assure that you have the proper license and distribution rights to do so!
True, you're not directly communicating with OLEDB, but you can use ADO to communicate with the OLEDB provider, which in turns talks to the database. ADO is an API wrapper around OLEDB. It's still faster than ODBC, because you have to access an extra layer.
Well, actually ADO's not an API layer around the OLEDB interfaces. Actually is a COM layer around it.....
And no CCLINT, I'm not talking about an existing OLEDB provider, what I'm talking about was communicating directly with the OLEDB interfaces. This is not possible from within VB, which is sad on one hand (because of omission of another layer) but on the other hand, ADO makes it much more easier and programmer friendly to go through OLEDB to data storage.
But Omega is absolutely right; ADO is still faster to access databases than it is to do it with ODBC. And besides, almost every COM interface expects ADO recordsets and such, so if you were to write logic that may be implemented elsewhere, you're quite safe using ADO.
Greetings,
Rick
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.