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).
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
