Passing unicode strings to prepare method and other unicode questions

Martin Evans <[email protected]>
Newsgroups gmane.comp.lang.perl.modules.dbi.sybase.devel
Organization Easysoft Limited
Message-ID <[email protected]>
Hi,

Increasingly I am getting asked unicode questions and being presented 
with unicode issues that currently don't work in DBD::ODBC. Currenty 
DBD::ODBC supports the binding of unicode parameters and the returning 
of unicode result-set data.

I would like to change DBD::ODBC to support:

a) unicode column names (from NAME attribute, column_info etc)
b) unicode connection strings
c) unicode SQL
d) unicode table names (table_info etc)

Although I don't specifically need unicode connection strings I at least 
need to turn connection strings usually passed to SQLDriverConnect into 
ODBC wide characters and call SQLDriverConnectW because without this 
call other calls to SQLXXXW (wide functions) are mapped to ANSI 
functions by the ODBC driver manager. Since I need to do this it seemed 
reasonable to just go the whole way and support unicode connection strings.

(a) I have implemented and appears to be ok and (d) should be fairly 
easy too but (b) and (c) are a little trickier with the existing DBI 
interface (unless I'm mistaken).

dbd_st_prepare and dbd_db_login6 both take char* and not the original SV 
so how can I tell if the strings are utf8 encoded or not?

What I'd like to be able to do (in ODBC terms is):

In dbd_db_login6
   test if connection string has utf8 set on it
   if (utf8on)
     convert utf8 to utf16 (that is what ODBC wide functions use)
     call SQLDriverConnectW
   else
     call SQLDriverConnect (this is the ANSI version)

Similarly in prepare where a number of people have unicode column or 
table names and hence want to do "select unicode_column_name from table".

Is this what dbd_st_prepare_sv (as opposed to dbd_st_prepare) is for? 
and should there be a dbd_db_login6_sv?

Any help would be appreciated.

Martin
-- 
Martin J. Evans
Easysoft Limited
http://www.easysoft.com
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.