Tim Bunce wrote:
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.
Ok, as you say the change is trivial for a unicode username and password:
#ifdef dbd_db_login6_sv
ST(0) = dbd_db_login6(dbh, imp_dbh, dbname, username, password,
attribs) ? &sv_yes : &sv_no;
#elif defined(dbd_db_login6)
ST(0) = dbd_db_login6(dbh, imp_dbh, dbname, u, p, attribs) ?
&sv_yes : &sv_no;
#else
ST(0) = dbd_db_login( dbh, imp_dbh, dbname, u, p) ? &sv_yes : &sv_no;
#endif
and an additional line in dbd_xsh.h I presume but not "dbname" which is
the one I'd really like as it is currently char *. How do I get dbname
to be an SV - as you may have guessed by now I'm not an XS expert. Is it
just a case of changing my DBD::ODBC::db::_login to say it is an SV*?
Thanks for the pointers.
Martin
--
Martin J. Evans
Easysoft Limited
http://www.easysoft.com
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
