none
ODBC cursor library problem with unicode MFC application RRS feed

  • Question

  • Hi,

        I have a MFC desktop application developed using VS2010 and uses ODBC for database communication. The application was using MBCS and I am converting it in to Unicode.

       

        When converting the application into Unicode, I noticed that I am no longer able to edit the existing access databases and am able to only view the databases because the ODBC cursor library is not loaded during SQLConnectW(). (It shows the message "[Microsoft][ODBC Driver Manager] Cursor library not used.  Load failed"). Also, the SQLGetInfo() for SQL_POSITIONED_STATEMENTS returns 0 in unicode. Also I noticed that there is a KB article Q259477 which says ODBC Unicode cursor support is not possible.

         Currently following is what I want to know?

        1. Is there any other way to make cursors work with ODBC in Unicode? I am using SQL_OV_ODBC3 when setting SQLSetEnvAttr().

        2. If I use SQL_CUR_USE_DRIVER instead of SQL_CUR_USE_ODBC, will it solve the cursor problem in Unicode? If it solve, what will be the impact of changes I have to make?

       3. If it is not possible using ODBC, what should be a easier and faster way to move to any other approach? Should I look for OLEDB or ADO .Net? Which among them will be easier to implement? I would prefer to use ADO .Net from long term perspective.

       Regards,

    Janardhanan.R.


    Janardhanan.R.

    Friday, September 12, 2014 2:19 PM

Answers

  • 3. If it is not possible using ODBC, what should be a easier and faster way to move to any other approach? Should I look for OLEDB or ADO .Net? Which among them will be easier to implement? I would prefer to use ADO .Net from long term perspective.

    I want to first mention that ODBC is preferred over OLE DB for accessing relational databases. See related announcement in this forum: http://social.msdn.microsoft.com/Forums/en-US/e696d0ac-f8e2-4b19-8a08-7a357d3d780f/microsoft-is-aligning-with-odbc-for-native-relational-data-access-faq?forum=sqldataaccess

    ADO.NET includes a .NET Framework Data Provider for ODBC, which allows you to use ADO.NET with any Windows ODBC driver.  ADO.NET provides objects like DataReader, DataSet, and DataTable to facilitate data operations without exposing low-level drive-specific functions like cursors that may vary depending on the driver or provider.

    I believe you will find new development with ADO.NET faster and easier than the ODBC call-level interface.  However, it is quite a different paradigm so converting your existing code may not be trivial, especially if OO principals were not followed.  Since your preference is ADO.NET for the long term anyway, I suggest you explore moving to ADO.NET along with your Unicode conversion. 


    Dan Guzman, SQL Server MVP, http://www.dbdelta.com

    Sunday, September 14, 2014 4:31 PM
    Moderator

All replies

  • 3. If it is not possible using ODBC, what should be a easier and faster way to move to any other approach? Should I look for OLEDB or ADO .Net? Which among them will be easier to implement? I would prefer to use ADO .Net from long term perspective.

    I want to first mention that ODBC is preferred over OLE DB for accessing relational databases. See related announcement in this forum: http://social.msdn.microsoft.com/Forums/en-US/e696d0ac-f8e2-4b19-8a08-7a357d3d780f/microsoft-is-aligning-with-odbc-for-native-relational-data-access-faq?forum=sqldataaccess

    ADO.NET includes a .NET Framework Data Provider for ODBC, which allows you to use ADO.NET with any Windows ODBC driver.  ADO.NET provides objects like DataReader, DataSet, and DataTable to facilitate data operations without exposing low-level drive-specific functions like cursors that may vary depending on the driver or provider.

    I believe you will find new development with ADO.NET faster and easier than the ODBC call-level interface.  However, it is quite a different paradigm so converting your existing code may not be trivial, especially if OO principals were not followed.  Since your preference is ADO.NET for the long term anyway, I suggest you explore moving to ADO.NET along with your Unicode conversion. 


    Dan Guzman, SQL Server MVP, http://www.dbdelta.com

    Sunday, September 14, 2014 4:31 PM
    Moderator
  • Hi,

       Thanks for the reply. Meanwhile, I noticed that the Unicode restriction is seen with MS-Access probably because MS-Access don't provide a separate ODBC driver for SQL operations. The issue was not seen with SQL Server express editions and hopefully should work fine with other DB providers too. So, for now, we don't need to move to ADO .Net.

         Regards,

    Janardhanan.R.


    Janardhanan.R.

    Monday, September 29, 2014 8:57 AM