- Forum
- Windows Programming
- Migrating from ODBC to ADO in legacy cod
Migrating from ODBC to ADO in legacy code.
Hi all.
That's my first issue in this forum.
I have to migrate the system's data access to SQL Server 2008 from ODBC to ADO.
Did somebody do something like that?
I mean, some libraries in C/C++, tips, examples.
Is it a hard work? I don't know how estimate it, because today is my first contact with the code.
Thank you.
That's my first issue in this forum.
I have to migrate the system's data access to SQL Server 2008 from ODBC to ADO.
Did somebody do something like that?
I mean, some libraries in C/C++, tips, examples.
Is it a hard work? I don't know how estimate it, because today is my first contact with the code.
Thank you.
Well, you would need to be familiar with both ODBC database access and ADO (ActiveX Data Objects) database access.
By including "adoctint.h" (a Windows system standard header) you would be able to instantiate ADO database objects and work with them, i.e., use their various interface methods and objects to read/write ODBC compliant databases.
Personally, I never moved away from ODBC, and I never saw a need to 'upgrade' any of my code to ADO. Others have, I know, but I never did. In your case I'd first ask seriously whether its an absolute necessity to do this.
Does the ODBC code work? Do you realize that ODBC is perfectly fine with working with any version of SQL Server? Microsoft updated its ODBC system code to be perfectly functional in x64 environments. As things stand right now, my database systems that I code work with both Microsoft Access and SQL Server x86 or x64.
There is no way of knowing this, because it would be in the realm of Microsoft proprietary code, but its likely that ADO uses ODBC in its implementation to actually work with relational databases. In that sense, its a COM implementation of ODBC. ADO is object oriented; ODBC procedurally oriented. If I'm right about this, one could view ADO as just a wrapper system around ODBC, which is likely the more fundamental lower level abstraction layer.
If you really want to do this conversion, I can provide some example code to get you started.
By including "adoctint.h" (a Windows system standard header) you would be able to instantiate ADO database objects and work with them, i.e., use their various interface methods and objects to read/write ODBC compliant databases.
Personally, I never moved away from ODBC, and I never saw a need to 'upgrade' any of my code to ADO. Others have, I know, but I never did. In your case I'd first ask seriously whether its an absolute necessity to do this.
Does the ODBC code work? Do you realize that ODBC is perfectly fine with working with any version of SQL Server? Microsoft updated its ODBC system code to be perfectly functional in x64 environments. As things stand right now, my database systems that I code work with both Microsoft Access and SQL Server x86 or x64.
There is no way of knowing this, because it would be in the realm of Microsoft proprietary code, but its likely that ADO uses ODBC in its implementation to actually work with relational databases. In that sense, its a COM implementation of ODBC. ADO is object oriented; ODBC procedurally oriented. If I'm right about this, one could view ADO as just a wrapper system around ODBC, which is likely the more fundamental lower level abstraction layer.
If you really want to do this conversion, I can provide some example code to get you started.
Last edited on
Topic archived. No new replies allowed.