Re: ANNOUNCE: DBD::Oracle 1.17
From the latest docs: AL16UTF16 = valid for NCHAR columns (CSID=2000) UTF8 = valid for NCHAR columns (CSID=871), deprecated AL32UTF8 = valid for NCHAR and CHAR columns (CSID=873) -and- Both UTF8 and AL32UTF32 can be used in NLS_LANG and NLS_NCHAR. For example: NLS_LANG=AMERICAN_AMERICA.UTF8 NLS_LANG=AMERICAN_AMERICA.AL32UTF8 NLS_NCHAR=UTF8 NLS_NCHAR=AL32UTF8 Where does this information come from? Our db-admins are telling me that in our current installation (10.1.0.3), AL32UTF8 cannot be used for the national language character set, just the database character set. Could someone please provide a pointer to the source of this information.
Re: ANNOUNCE: DBD::Oracle 1.17
On Tue, Feb 14, 2006 at 11:00:33AM -0500, Paul G. Weiss wrote: From the latest docs: AL16UTF16 = valid for NCHAR columns (CSID=2000) UTF8 = valid for NCHAR columns (CSID=871), deprecated AL32UTF8 = valid for NCHAR and CHAR columns (CSID=873) -and- Both UTF8 and AL32UTF32 can be used in NLS_LANG and NLS_NCHAR. For example: NLS_LANG=AMERICAN_AMERICA.UTF8 NLS_LANG=AMERICAN_AMERICA.AL32UTF8 NLS_NCHAR=UTF8 NLS_NCHAR=AL32UTF8 Where does this information come from? Our db-admins are telling me that in our current installation (10.1.0.3), AL32UTF8 cannot be used for the national language character set, just the database character set. Could someone please provide a pointer to the source of this information. AL32UTF8 cannot be used for the *server* national language character set but can for the client. Tim.
Re: Add PERL_NO_GET_CONTEXT to DBI.xs
On 6-Feb-06, at 5:10 PM, Tim Bunce wrote: On Mon, Feb 06, 2006 at 05:53:18AM -0800, Gisle Aas wrote: Tim Bunce [EMAIL PROTECTED] writes: I agree. Any chance yould you patch lib/DBI/DBD.pm to add in a section describing what driver authors need to do? Is this enough? That's great. I tweaked it a bit and appended the body of it below. Let me know if I've said anything wrong. Driver authors please take note! Can I add that in conditionally based on the DBI version? e.g. #if (DBI_VERSION 151) #define PERL_NO_GET_CONTEXT #endif Matt.
Re: Add PERL_NO_GET_CONTEXT to DBI.xs
Matt Sergeant [EMAIL PROTECTED] writes: On 6-Feb-06, at 5:10 PM, Tim Bunce wrote: On Mon, Feb 06, 2006 at 05:53:18AM -0800, Gisle Aas wrote: Tim Bunce [EMAIL PROTECTED] writes: I agree. Any chance yould you patch lib/DBI/DBD.pm to add in a section describing what driver authors need to do? Is this enough? That's great. I tweaked it a bit and appended the body of it below. Let me know if I've said anything wrong. Driver authors please take note! Can I add that in conditionally based on the DBI version? e.g. #if (DBI_VERSION 151) #define PERL_NO_GET_CONTEXT #endif There isn't currently a DBI_VERSION to test against. DBIXS.h does define DBIXS_VERSION and this could have been incremented, but PERL_NO_GET_CONTEXT need to be defined before this file is included. If DBIXS_VERSION was moved to a different header file this could have been made to work: #include DBIXS_VERS.h #if DBIXS_VERSION = 94 #define PERL_NO_GET_CONTEXT #endif #include DBIXS.h --Gisle
Re: Add PERL_NO_GET_CONTEXT to DBI.xs
On 14-Feb-06, at 6:20 PM, Gisle Aas wrote: There isn't currently a DBI_VERSION to test against. DBIXS.h does define DBIXS_VERSION and this could have been incremented, but PERL_NO_GET_CONTEXT need to be defined before this file is included. If DBIXS_VERSION was moved to a different header file this could have been made to work: #include DBIXS_VERS.h #if DBIXS_VERSION = 94 #define PERL_NO_GET_CONTEXT #endif #include DBIXS.h Shame. So I guess the other option is a MakeMaker pre-processing routine which modifies SQLiteXS.h Matt.
