• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1087
  • Last Modified:

odbc wrapper to support nvarchar (unicode) data type in sql server

I have a agent framework that uses libodbc++ to connect to sql server and get the data. However libodbc++ wrapper only supports non-unicode data types. Now i have a requirement that has nvarchar (unicode) datatype to be fetch from the table. Since Libodbc++ does not support unicode, i am stuck. Also my agent framework uses MBCS (VC++ with MBCS support).
What options do i have here?
0
picasothakkar
Asked:
picasothakkar
  • 2
  • 2
1 Solution
 
itsmeandnobodyelseCommented:
Do you have the source code of libodbc++ (is it RoqueWave?). If yes, you should be able to add wide character support to the fetch functioniality as it is only an SQL_C_WCHAR flag instead of SQL_C_CHAR when binding columns (and of course handle the return buffer as a wide character string). If not, you could call native ODBC to fetch data from the table. That is possible even if you use libodbc++ same time. If the environment and database handles libodbc++ uses are available - check the header files of libodbc++ for HENV and HDBC - you could use the current connection for your own native calls.

Regards, Alex
0
 
picasothakkarAuthor Commented:
Alex, i appreicate your time. Thank you.
Libodbc++ is freeware with source code available. I googled for it. I found out that people had similar issues which coudn't get resolved with small changes.
Can you give me more information on using native ODBC to fetch data? Sorry but being a java guy i find it difficult to understand c++.
Thanks again,
Picaso
0
 
itsmeandnobodyelseCommented:
If source code is available it seems to me the simplest to advance the exitisting interface with the nvarchar type. There are only a few ODBC calls within the library that are affected by the new type. Note, ODBC already has constants SQL_WCHAR, SQL_WVARCHAR and SQL_C_WCHAR  that were supposed to specify the required data type. The latter is the 'C' type of the buffer what means that the buffer is of type WCHAR* or unsigned short*. SQL_WCHAR and SQL_WVARCHAR describe the column types NCHAR and NVARCHAR of SQLSERVER.

You need to spot the the interface in libodbc++ where you could define data types to fetch data using a database query (and where a wide character datatype is missing). When looking at the source code you should be able to find the 'native' ODBC calls where the datatype used in libodbc++ was transformed to ODBC SQL_C_VARCHAR and SQL_VARCHAR. The constants were used with ODBC calls SQLBindCol and SQLBindParameter. If you post that piece of code we should be able to add statements to support wide characters as well. If you could post an address where the source of libodbc++ could be downloaded, I would check that issue for you.

See also http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odbc/htm/odbcconverting_data_from_c_to_sql_data_types.asp to learn more about conversion of ODBC data types.

Regards, Alex
0
 
picasothakkarAuthor Commented:
hi Alex,
I appreciate your help. I was trying to push the client to cast the view to varchar instead of nvarchar. However that didn't  work out and i am running out of options at this moment. I will be following your instructions to handle nvarchar by making changes in libodbc++ source code. However as i mentioned earlier, i am not too confident on the outcome and although i know i would be asking too much from you, I will really appreciate if you can help me do it. Please let me know the best way i can accomplish these changes.
The source code for libodbcxx can be dowloaded from
http://prdownloads.sourceforge.net/libodbcxx/libodbc%2B%2B-0.2.3.tar.gz?download
Thanks,
Picaso
0

Featured Post

VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now