ADO and VC++. Which approach?
-
I've found 3 different ways of doing ADO in VC++. 1) The most common way seems to be doing an #import on the ado15.dll This generates smart pointers to all the objects and off you go. 2) I've also seen used: Import the desired classes from ado15.dll as a typelib, using the class wizard which generates a truckload of COleDispatch wrapper classes. 3) Raw COM: Do CoCreateInstance on the interfaces using CLSID's built from the "ADODB.Whatever" type string. The problem I have with 1) #import is that a class that is both a pointer and not a pointer (-> and .) makes me shudder. I know, it's only overloaded operators, but still.... The REAL problem I have with #import is with _bstr_t. I find that CComBSTR is a much better class if I'm going to also be converting to and from CString's , but the #import smartpointers force me to use _bstr_t's. The problem I have with 2) COleDispatch generated classes is all those classes I have to have in my project. I get dizzy looking at the class view. So I decided on method 3). So far I've had good luck with it. The only 'disadvantage' is that I'm responsible for doing all the housecleaning. (This might be a good thing). CComBSTR works great with this approach , and a pointer is a pointer is a pointer (No smartpointer operator goofiness). All the interfaces are defined outside of my project so I don't have to have them in my class view. Does anyone know any GOTCHA!'s that I might run into using raw COM approach? (Or perhaps any alternate methods). Thanks, Chrys. :rose:
-
I've found 3 different ways of doing ADO in VC++. 1) The most common way seems to be doing an #import on the ado15.dll This generates smart pointers to all the objects and off you go. 2) I've also seen used: Import the desired classes from ado15.dll as a typelib, using the class wizard which generates a truckload of COleDispatch wrapper classes. 3) Raw COM: Do CoCreateInstance on the interfaces using CLSID's built from the "ADODB.Whatever" type string. The problem I have with 1) #import is that a class that is both a pointer and not a pointer (-> and .) makes me shudder. I know, it's only overloaded operators, but still.... The REAL problem I have with #import is with _bstr_t. I find that CComBSTR is a much better class if I'm going to also be converting to and from CString's , but the #import smartpointers force me to use _bstr_t's. The problem I have with 2) COleDispatch generated classes is all those classes I have to have in my project. I get dizzy looking at the class view. So I decided on method 3). So far I've had good luck with it. The only 'disadvantage' is that I'm responsible for doing all the housecleaning. (This might be a good thing). CComBSTR works great with this approach , and a pointer is a pointer is a pointer (No smartpointer operator goofiness). All the interfaces are defined outside of my project so I don't have to have them in my class view. Does anyone know any GOTCHA!'s that I might run into using raw COM approach? (Or perhaps any alternate methods). Thanks, Chrys. :rose:
I suggest doing #1, but use the Visual C++ extensions for ADO to avoid the BSTR stuff. A small sample can be found here: www.gl.umbc.edu/~bcorfm1/software.html