ODBC, ADO or OLEDB ?
-
Hi there, I have recently finished a collection of classes which provide support for database processing. The only problem though is the classes use the (old-deprecated) ODBC API. Some time ago I was told ADO data source connectivity is a much better approach because of its ease of use, speed and so forth. This made me think about updating (or actually rewritting) the entire collection so that it can support the latest in what regards to datasource connectivity. But I have been doing some reading and would like to ask you some questions: - doesn't ADO use OLEDB? And if so, should I not be thinking about supporting OLEDB rather than ADO as it would create an additional layer between the ODBC driver and the App? - in what concerns compatibility and speed, what is, in your own opinion, the platform I should be aiming for? Thank you very much, David
-
Hi there, I have recently finished a collection of classes which provide support for database processing. The only problem though is the classes use the (old-deprecated) ODBC API. Some time ago I was told ADO data source connectivity is a much better approach because of its ease of use, speed and so forth. This made me think about updating (or actually rewritting) the entire collection so that it can support the latest in what regards to datasource connectivity. But I have been doing some reading and would like to ask you some questions: - doesn't ADO use OLEDB? And if so, should I not be thinking about supporting OLEDB rather than ADO as it would create an additional layer between the ODBC driver and the App? - in what concerns compatibility and speed, what is, in your own opinion, the platform I should be aiming for? Thank you very much, David
I think the time needed to load the data from hard disk takes much longer than the time to process requests and transfer them via ODBC. I myself use ODBC, too, and I don't see any reason why I shouldn't do so. Don't try it, just do it! ;-)
-
Hi there, I have recently finished a collection of classes which provide support for database processing. The only problem though is the classes use the (old-deprecated) ODBC API. Some time ago I was told ADO data source connectivity is a much better approach because of its ease of use, speed and so forth. This made me think about updating (or actually rewritting) the entire collection so that it can support the latest in what regards to datasource connectivity. But I have been doing some reading and would like to ask you some questions: - doesn't ADO use OLEDB? And if so, should I not be thinking about supporting OLEDB rather than ADO as it would create an additional layer between the ODBC driver and the App? - in what concerns compatibility and speed, what is, in your own opinion, the platform I should be aiming for? Thank you very much, David
Yes, ADO uses OLEDB. Using OLEDB will give you the most functionality and performance. Consider using ATL wrapper classes, they'll make it easier. For example:
HRESULT hr = spDataInitialize.CoCreateInstance(CLSID_MSDAINITIALIZE); if(FAILED(hr)) return 1; hr = spDataInitialize->GetDataSource(NULL, CLSCTX_INPROC_SERVER, pwszConnectionString, IID_IDBInitialize, reinterpret_cast<IUnknown**>(&spDBInitialize)); if(FAILED(hr)) return 1; hr = spDBInitialize->Initialize(); if(FAILED(hr)) return 1; ATL::CComQIPtr spDBCreateSession = spDBInitialize; if(!spDBCreateSession) return 1; hr = spDBCreateSession->CreateSession(NULL, IID_IDBCreateCommand, reinterpret_cast<IUnknown**>(&spDBCreateCommand)); if(FAILED(hr)) return 1; hr = spDBCreateCommand->CreateCommand(NULL, IID_ICommand, reinterpret_cast<IUnknown**>(&spCommand)); if(FAILED(hr)) return 1; ATL::CComQIPtr spCommandStream = spCommand; if(!spCommandStream) return 1; -
Yes, ADO uses OLEDB. Using OLEDB will give you the most functionality and performance. Consider using ATL wrapper classes, they'll make it easier. For example:
HRESULT hr = spDataInitialize.CoCreateInstance(CLSID_MSDAINITIALIZE); if(FAILED(hr)) return 1; hr = spDataInitialize->GetDataSource(NULL, CLSCTX_INPROC_SERVER, pwszConnectionString, IID_IDBInitialize, reinterpret_cast<IUnknown**>(&spDBInitialize)); if(FAILED(hr)) return 1; hr = spDBInitialize->Initialize(); if(FAILED(hr)) return 1; ATL::CComQIPtr spDBCreateSession = spDBInitialize; if(!spDBCreateSession) return 1; hr = spDBCreateSession->CreateSession(NULL, IID_IDBCreateCommand, reinterpret_cast<IUnknown**>(&spDBCreateCommand)); if(FAILED(hr)) return 1; hr = spDBCreateCommand->CreateCommand(NULL, IID_ICommand, reinterpret_cast<IUnknown**>(&spCommand)); if(FAILED(hr)) return 1; ATL::CComQIPtr spCommandStream = spCommand; if(!spCommandStream) return 1;Let's try this again, this time with the angle brackets.. ;-)
HRESULT hr = spDataInitialize.CoCreateInstance(CLSID_MSDAINITIALIZE); if(FAILED(hr)) return 1; hr = spDataInitialize->GetDataSource(NULL, CLSCTX_INPROC_SERVER, pwszConnectionString, IID_IDBInitialize, reinterpret_cast<IUnknown**>(&spDBInitialize)); if(FAILED(hr)) return 1; hr = spDBInitialize->Initialize(); if(FAILED(hr)) return 1; ATL::CComQIPtr<IDBCreateSession> spDBCreateSession = spDBInitialize; if(!spDBCreateSession) return 1; hr = spDBCreateSession->CreateSession(NULL, IID_IDBCreateCommand, reinterpret_cast<IUnknown**>(&spDBCreateCommand)); if(FAILED(hr)) return 1; hr = spDBCreateCommand->CreateCommand(NULL, IID_ICommand, reinterpret_cast<IUnknown**>(&spCommand)); if(FAILED(hr)) return 1; ATL::CComQIPtr<ICommandStream> spCommandStream = spCommand; if(!spCommandStream) return 1; -
Hi there, I have recently finished a collection of classes which provide support for database processing. The only problem though is the classes use the (old-deprecated) ODBC API. Some time ago I was told ADO data source connectivity is a much better approach because of its ease of use, speed and so forth. This made me think about updating (or actually rewritting) the entire collection so that it can support the latest in what regards to datasource connectivity. But I have been doing some reading and would like to ask you some questions: - doesn't ADO use OLEDB? And if so, should I not be thinking about supporting OLEDB rather than ADO as it would create an additional layer between the ODBC driver and the App? - in what concerns compatibility and speed, what is, in your own opinion, the platform I should be aiming for? Thank you very much, David
ADo wraps OLEDB. ADO has had some bugs and portability issues (to WinCE). I think most have been sorted out but it has left a sour taste in the mouths of some of us - i don't use it. ODBC is a cleaner API (in my opinion) than OLEDB - i am not a fan of COM. That said, ODBC is not supported by WinCE but OLEDB is. So i have database classes that wrap both ODBC and OLEDB but provide a common method interface. I generally use ODBC on the desktop and OLEDB on WinCE. ...cmk Save the whales - collect the whole set
-
ADo wraps OLEDB. ADO has had some bugs and portability issues (to WinCE). I think most have been sorted out but it has left a sour taste in the mouths of some of us - i don't use it. ODBC is a cleaner API (in my opinion) than OLEDB - i am not a fan of COM. That said, ODBC is not supported by WinCE but OLEDB is. So i have database classes that wrap both ODBC and OLEDB but provide a common method interface. I generally use ODBC on the desktop and OLEDB on WinCE. ...cmk Save the whales - collect the whole set
Hi and thanks for replying. It is interesting to know you are (also) an adept of the ODBC_API... but looking at both the ODBC_API and OLEDB what would you say about performance issues such as: - memory usage; - processing speed (in the general sense); And what about the future? I mean, do you think ODBC will still be supported in the future or will it be made deprecated by Microsoft? #David
-
Hi and thanks for replying. It is interesting to know you are (also) an adept of the ODBC_API... but looking at both the ODBC_API and OLEDB what would you say about performance issues such as: - memory usage; - processing speed (in the general sense); And what about the future? I mean, do you think ODBC will still be supported in the future or will it be made deprecated by Microsoft? #David
dNimrod#X wrote: looking at both the ODBC_API and OLEDB what would you say about performance issues such as: - memory usage; - processing speed (in the general sense); I've never compared them head-to-head. I almost always use ODBC on desktop and OLEDB on PDA - you can't compare the relative speeds due to the difference in the platforms. At this point i wouldn't expect to find much of a performance difference between the two. Any difference would likely be dwarfed by the time required for the RDBMS to execute the query. dNimrod#X wrote: do you think ODBC will still be supported in the future or will it be made deprecated by Microsoft? I don't know. I don't think it will be depreciated any time soon (knock on wood). ODBC has an open source port for UNIX (MAC?) so it is now truely a cross-platform API. http://www.odbc.org/[^] http://www.iodbc.org/[^] ...cmk Save the whales - collect the whole set