On Sun, Aug 31, 2008 at 11:47:38PM +0100, Martin J. Evans wrote: > Tim Bunce wrote: >> On Fri, Aug 29, 2008 at 12:37:48PM +0100, Martin Evans wrote: >> >>> Martin Evans wrote: >>> >>>> 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? >> >> Yes, and yes. >> > Thanks Tim. So how do I get a login6_sv? (I've got an awful feeling you are > going to say send a patch).
Your feeling is spot on. Should be trivial though. There are several similar cases in Driver.xst already. Thanks for working on this Martin! Tim. >>> Also, to use dbd_st_prepare_sv am I supposed to add something like the >>> following to ODBC.xs: >>> >>> #include "ODBC.h" >>> # the following line added: >>> #define dbd_st_prepare_sv dbd_st_prepare_sv >> >> Each driver should have a .h file that contains a bunch of line like >> >> #define dbd_db_do ora_db_do >> #define dbd_db_commit ora_db_commit >> #define dbd_db_rollback ora_db_rollback >> ...etc... >> >> They indicate which methods have implementations in C, which >> implementation should be used, i.e. dbd_db_login vs dbd_db_login6, >> and they ensure that the C function names are unique so multiple drivers >> can be statically linked into the same executable. (Though few people >> care about static linking these days.) >> >> The "Implementation header dbdimp.h" in the DBI::DBD docs talks about this. >> >> So, to answer your question, alongside your existing set of #defines >> you'd add #define dbd_st_prepare_sv odbc_st_prepare_sv. >> >> (It's probably a personal preference if you name the actual C function >> odbc_st_prepare_sv, or name it dbd_st_prepare_sv and let the macro >> rename it for you.) >> >> Tim. > > Sorted, thank you. > > I've got a load of unicode changes for DBD::ODBC but I'm still not 100% > about some of them. I keep getting emails from people tapping in stuff like > japanese (JIS) strings into their SQL and expecting it to just work across > different platforms. To add to the confusion ODBC (as far as Microsoft is > concerned) already defines SQLxxxW functions which are (wide - ha, i.e., > UCS-2 versions for the normal ANSI functions). The current changes would > allow connection to a unicode data source name (if I've got login6_sv), > preparing of unicode SQL and support for unicode column and table names - > all decode_utf8'ed to perl. > > As an aside, if anyone reading this has wanted any kind of unicode support > in DBD::ODBC (which is not already there) please get in contact with me. > > Martin
