Re: ANNOUNCE: DBD::Oracle 1.23 Release Candidate 1
On Mon, February 16, 2009 5:33 pm, John Scoles wrote: > Well here it is the long awaited 1.23 > http://www.youtube.com/watch?v=67khDZ0P7Xo or the Sesame Street > http://en.wikipedia.org/wiki/Sesame_Street version of DBD::ORACLE > > You can find the release candidate here > > http://svn.perl.org/modules/dbd-oracle/trunk/DBD-Oracle-1.23-RC1.tar It's not a .tar file, it seems to be a .tar.gz file. $ file DBD-Oracle-1.23-RC1.tar DBD-Oracle-1.23-RC1.tar: gzip compressed data, from Unix It doesn't have directory structure in it (i.e. the top-level DBD-Oracle directory) so it dumps all files in current directory when "tar zxf"ing it. Seems to be a fair bit missing as well - there's no "t" directory with the tests? Redhat Linux 64-bit, Oracle 10.2 client, fails on make with: Error: 'OCILobLocator *' not in typemap in Oracle.xs, line 294 Error: 'OCILobLocator *' not in typemap in Oracle.xs, line 348 Error: 'OCILobLocator *' not in typemap in Oracle.xs, line 405 Error: 'OCILobLocator *' not in typemap in Oracle.xs, line 453 Error: 'OCILobLocator *' not in typemap in Oracle.xs, line 471 Error: 'OCILobLocator *' not in typemap in Oracle.xs, line 490 make: *** [Oracle.c] Error 1 ... but that's probably due to the archive being incomplete? (Is committing a tar file of the trunk into trunk a good idea? Sounds a bit recursive) -- Andy Hassall / / <http://www.andyh.co.uk> <http://www.andyhsoftware.co.uk/space> Space: disk usage analysis tool
DBD::Oracle on Oracle 11g
Initial results: Default build method fails as the Oracle makefiles (oracle.mk etc.) have apparently disappeared: Using Oracle in /Disk0/app/oracle/product/11.1.0 DEFINE _SQLPLUS_RELEASE = "1101000600" (CHAR) Oracle version 11.1.0.6 (11.1) Unable to locate an oracle.mk, proc.mk or other suitable *.mk file in your Oracle installation. (I looked in /Disk0/app/oracle/product/11.1.0/rdbms/demo/demo_xe.mk /Disk0/app/oracle/product/11.1.0/rdbms/lib/oracle.mk /Disk0/app/oracle/product/11.1.0/rdbms/demo/oracle.mk /Disk0/app/oracle/product/11.1.0/rdbms/demo/demo_rdbms.mk /Disk0/app/oracle/product/11.1.0/precomp/demo/proc/proc.mk /Disk0/app/oracle/product/11.1.0/precomp/demo/proc/demo_proc.mk /Disk0/app/oracle/product/11.1.0/proc/lib/proc.mk /Disk0/app/oracle/product/11.1.0/proc16/lib/proc16.mk under /Disk0/app/oracle/product/11.1.0) However, building with "perl Makefile.PL -l" is successful. Tests are almost all successful, but there are some failures in the array interface: t/26exe_array...ok 3/14 # Failed test '... we should have 19 tuple_status' # at t/26exe_array.t line 120. # got: 10 # expected: 19 t/26exe_array...NOK 14/14 # Failed test '... we should have 48 rows' # at t/26exe_array.t line 146. # got: 30 # expected: 48 # Looks like you failed 2 tests of 14. t/26exe_array...dubious Test returned status 2 (wstat 512, 0x200) DIED. FAILED tests 11, 14 Failed 2/14 tests, 85.71% okay Not sure what these are about yet - whether it's a bug in DBD::Oracle, Oracle, or a backwards compatibility break in the OCI API. Other than those failures, the rest appears to pass tests and work OK which is encouraging. -- Andy Hassall :: [EMAIL PROTECTED] :: http://www.andyh.co.uk http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool
Re: :Oracle function
John Scoles wrote: >> [EMAIL PROTECTED] wrote: >>> Anyone knows if DBD::Oracle has a function similar to the function >>> $sth->rows that exist in DBD::Mysql? >> >> This is a DBI feature. It exists for all drivers. >> >>> This function give us the number o rows in a select command. So, we >>> don´t have to run a fetchrow with a while loop to know how many rows >>> the select will return. >> >> This is driver-specific behavior. The DBI does not guarantee this. >> With Oracle, you will need to either (1) fetch all the rows first, or >> (2) change your SQL to "select count(1) from ...". > Oracle doesn't have this feature so DBD::Oracle doesn't either. This has cropped up many times before So you can blame Oracle on that. Thier logic (as it was explained to me) is "How could you get the number of rows you are going to fetch without counting them all first?" Oracle sort of does have the feature if you ask for it; call OCIExecute with OCI_STMT_SCROLLABLE_READONLY, and use OCIStmtFetch2 with OCI_FETCH_LAST to skip to the last row without fetching all the other data, and read OCI_ATTR_ROW_COUNT off the statement handle to get the number of rows (and then probably OCIStmtFetch2 + OCI_FETCH_FIRST to seek back to the start so the rest works as normal). Whether it's worth the overhead is another question (the manual has various performance warnings on the scrollable cursor feature) but it is available. -- Andy Hassall :: [EMAIL PROTECTED] :: http://www.andyh.co.uk http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool
RE: ANNOUNCE: DBD::Oracle 1.19 release candidate
>It would be great if you could test on the Lunix version of the client
Similar problems show up on the Linux client as well.
>or upgrade/pathc the windows 9.2.0.8 client
It's already at 9.2.0.8, that's the most recent patchset for 9.2.
My batch build/test script has just finished and I've put the results up
at:
http://www.andyh.co.uk/temp/DBD-Oracle/r7940/results.php
The "RC2" zip file in Subversion contains what looks like various test
copies of files, in particular "dbdimp_27.c", "dbdimp_fixed.c" etc., and as
a result it doesn't build. So I based the tests on an svn export of r7940.
(Not sure it's a good idea checking in temporary tarballs/zips of the
distribution into its source control repository)
Thanks,
--
Andy Hassall :: [EMAIL PROTECTED] :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool
-Original Message-
From: John Scoles [mailto:[EMAIL PROTECTED]
Sent: 11 October 2006 16:16
To: Andy Hassall
Cc: dbi-dev@perl.org
Subject: Re: ANNOUNCE: DBD::Oracle 1.19 release candidate
Will look into this on the next RC -3.
but I think it is a bug with the windows Oracle 9.2.0.8 full client rather
than DBD::Oracle.
Seems test 24implicit_utf8 only fails with this exact error with this
version of the Oracle client and DB.
It would be great if you could test on the Lunix version of the client or
upgrade/pathc the windows 9.2.0.8 client
cheers
John Scoles
- Original Message -
From: "Andy Hassall" <[EMAIL PROTECTED]>
To: "'John Scoles'" <[EMAIL PROTECTED]>
Cc:
Sent: Tuesday, October 10, 2006 6:59 PM
Subject: RE: ANNOUNCE: DBD::Oracle 1.19 release candidate
> Initial testing looks OK in the following, all against a
> WE8ISO8859P15/AL16UTF16 10.2.0.2 database, NLS_LANG=.WE8ISO8859P15 (not
> tried other NLS combinations yet):
>
>Cygwin (Perl 5.8.7, DBI 1.51, gcc 3.4.4)
> 9.2.0.8 full client
> 10.2.0.2 instant client
>
>Linux (Perl 5.8.8, DBI 1.52, gcc 3.4.6)
> 10.2.0.2 full client
>
>Windows (ActiveState Perl 5.8.8, DBI 1.5.2, MS Visual Studio.NET 2003)
> 10.2.0.2 instant client
> 10.2.0.1 xe client
>
> Test FAILs on:
>
>Windows (ActiveState Perl 5.8.8 build 817, DBI 1.5.2, MS Visual
> Studio.NET 2003)
> 9.2.0.8 full client
>
> t/24implicit_utf8...ok 1/74
> # Failed test 'byte_string test of row 4: column: nch (uft8) smiley
> face'
> # in t/nchar_test_lib.pl at line 341.
> # got: '38|58'
> # expected: '226|152|186'
>
> t/24implicit_utf8...NOK 34# Failed test 'nice_string test of row 4:
> column
> : nch (uft8) smiley face'
> # in t/nchar_test_lib.pl at line 344.
> # got: '&:'
> # expected: '\x{263A}'
> #row 4: DUMP(nch) = Typ=1 Len=4: 0,38,0,58
>
> # Failed test 'byte_string test of row 4: column: nch (uft8) smiley
> face'
> # in t/nchar_test_lib.pl at line 341.
> # got: '38|58'
> # expected: '226|152|186'
>
> # Failed test 'nice_string test of row 4: column: nch (uft8) smiley
> face'
> # in t/nchar_test_lib.pl at line 344.
> # got: '&:'
> # expected: '\x{263A}'
> #row 4: DUMP(nch) = Typ=1 Len=4: 0,38,0,58
> t/24implicit_utf8...NOK 71# Looks like you failed 4 tests of 74.
> t/24implicit_utf8...dubious
>Test returned status 4 (wstat 1024, 0x400)
> DIED. FAILED tests 33-34, 70-71
>Failed 4/74 tests, 94.59% okay
>
> (all other tests OK)
>
> These tests also fail in the same configuration with DBD-Oracle 1.18a and
> 1.17 so it doesn't look like a totally new problem.
>
> The 2nd and 4th failures have:
>
> # expected: '\x{263A}'
> #row 4: DUMP(nch) = Typ=1 Len=4: 0,38,0,58
>
> 0,38,0,58 is 0x0, 0x26, 0x0, 0x3a - some sort of confusion between UTF-8
> and the UTF-16 nchar encoding?
>
> Similarly with the 1st and 3rd failures:
>
> # got: '38|58'
> # expected: '226|152|186'
>
> It's expecting the UTF-8 encoding of \x{263A}, but it's getting the UTF-16
> encoding of it.
>
> Why it's only showing on Windows native and not Cygwin I don't know. I
> haven't got a 9.2 Linux client installed at the moment so can't check if
> it
> fails there yet.
>
> --
> Andy Hassall :: [EMAIL PROTECTED] :: http://www.andyh.co.uk
> http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool
>
> -Original Message-
> From: John Scoles [mailto:[EMAIL PROTECTED]
> Sent: 05 October 2006 16:27
> To: dbi-dev@perl.org
> Subject: ANNOUNCE: DB
RE: ANNOUNCE: DBD::Oracle 1.19 release candidate
Initial testing looks OK in the following, all against a
WE8ISO8859P15/AL16UTF16 10.2.0.2 database, NLS_LANG=.WE8ISO8859P15 (not
tried other NLS combinations yet):
Cygwin (Perl 5.8.7, DBI 1.51, gcc 3.4.4)
9.2.0.8 full client
10.2.0.2 instant client
Linux (Perl 5.8.8, DBI 1.52, gcc 3.4.6)
10.2.0.2 full client
Windows (ActiveState Perl 5.8.8, DBI 1.5.2, MS Visual Studio.NET 2003)
10.2.0.2 instant client
10.2.0.1 xe client
Test FAILs on:
Windows (ActiveState Perl 5.8.8 build 817, DBI 1.5.2, MS Visual
Studio.NET 2003)
9.2.0.8 full client
t/24implicit_utf8...ok 1/74
# Failed test 'byte_string test of row 4: column: nch (uft8) smiley face'
# in t/nchar_test_lib.pl at line 341.
# got: '38|58'
# expected: '226|152|186'
t/24implicit_utf8...NOK 34# Failed test 'nice_string test of row 4:
column
: nch (uft8) smiley face'
# in t/nchar_test_lib.pl at line 344.
# got: '&:'
# expected: '\x{263A}'
#row 4: DUMP(nch) = Typ=1 Len=4: 0,38,0,58
# Failed test 'byte_string test of row 4: column: nch (uft8) smiley face'
# in t/nchar_test_lib.pl at line 341.
# got: '38|58'
# expected: '226|152|186'
# Failed test 'nice_string test of row 4: column: nch (uft8) smiley face'
# in t/nchar_test_lib.pl at line 344.
# got: '&:'
# expected: '\x{263A}'
#row 4: DUMP(nch) = Typ=1 Len=4: 0,38,0,58
t/24implicit_utf8...NOK 71# Looks like you failed 4 tests of 74.
t/24implicit_utf8...dubious
Test returned status 4 (wstat 1024, 0x400)
DIED. FAILED tests 33-34, 70-71
Failed 4/74 tests, 94.59% okay
(all other tests OK)
These tests also fail in the same configuration with DBD-Oracle 1.18a and
1.17 so it doesn't look like a totally new problem.
The 2nd and 4th failures have:
# expected: '\x{263A}'
#row 4: DUMP(nch) = Typ=1 Len=4: 0,38,0,58
0,38,0,58 is 0x0, 0x26, 0x0, 0x3a - some sort of confusion between UTF-8
and the UTF-16 nchar encoding?
Similarly with the 1st and 3rd failures:
# got: '38|58'
# expected: '226|152|186'
It's expecting the UTF-8 encoding of \x{263A}, but it's getting the UTF-16
encoding of it.
Why it's only showing on Windows native and not Cygwin I don't know. I
haven't got a 9.2 Linux client installed at the moment so can't check if it
fails there yet.
--
Andy Hassall :: [EMAIL PROTECTED] :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool
-Original Message-
From: John Scoles [mailto:[EMAIL PROTECTED]
Sent: 05 October 2006 16:27
To: dbi-dev@perl.org
Subject: ANNOUNCE: DBD::Oracle 1.19 release candidate
http://svn.perl.org/modules/dbd-oracle/trunk/DBD-Oracle-1.19-RC1.zip
Changes in DBD-Oracle 1.19 (scn rev 7879)
Fixed execute_array to comply with DBI standard from Martin J. Evans, Xho
Jingleheimerschmidt and others
Fixed execute_array so it will not throw a Perl warning on undef values in
Tuples from John Scoles
Fixed some typos in code and READMEs from John Scoles
Fixed a few other little bugs dealing with compatibility with Oracle 8
Changes to README from Karl Auer
Suppress warning in 26exe_array.t from Philip Garrett
Added support for array context aware execute_for_fetch from Martin J.
Evans
Any and all testing would be greatly appreciated, but especially
testing of building against Oracle Instant Client and Oracle XE
on a range of platforms.
Please take this opertunitry to try out mass updates with execute_array.
Thanks!
John Scoles
RE: ANNOUNCE: DBD::Oracle 1.18 release candidate
First batch of automated test results here: http://www.andyh.co.uk/temp/DBD-Oracle/1.18RC1/ Windows native and Linux only so far. Linux/9.2 client appears to fail on Unicode tests - whilst 10g clients succeed. I've not been able to get any passes on Cygwin due to it apparently not picking up on the TNS_ADMIN environment variable - all tests fail because TNS is unable to resolve any database. I haven't had time to work out the causes of either of these problems yet - just posting the results as they come in. On the test results above, the database versions for the db names in the results are: Db name version OS DB charset -- XE 10.2.0.1XE (beta) Linux (32bit) WE8MSWIN1252 TEST102 10.2.0.2EE Linux (32bit) WE8ISO8859P15 XE_EXCESSION10.2.0.1XE Windows XP AL32UTF8 -- Andy Hassall :: [EMAIL PROTECTED] :: http://www.andyh.co.uk http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool -Original Message- From: John Scoles [mailto:[EMAIL PROTECTED] Sent: 12 July 2006 19:11 To: dbi-dev@perl.org Subject: ANNOUNCE: DBD::Oracle 1.18 release candidate http://svn.perl.org/modules/dbd-oracle/trunk/DBD-Oracle-1.18-RC1.zip =head1 Changes in DBD-Oracle 1.18 (scn rev 6642) Updated README.win32.txt fixed some typos updated for 10XE Added code to inplement support for the native OCI Array Interface with execute_array from orginal patches by Kristian Nielsen and others. Fixed expanded support for Lobs support from Jeffrey Klein Added notes on expanded support for Lobs to Oracle.pm Any and all testing would be greatly appreciated, but especially testing of building against Oracle Instant Client and Oracle XE on a range of platforms. Thanks! John
RE: Testing DBD::Oracle array interface
I can test on Windows native (MS Visual Studio.NET 2003), Windows Cygwin, and Whitebox Linux (an RHEL4 clone), with some combinations of 9.2, 10.2 and Oracle XE. I'm still setting things back up again on the Windows side after a hard drive crash, so this is a bit limited at the moment. I may also be able to do some limited testing on Solaris at work, but only where it's related to the process I mentioned that would benefit from array binding. I have a script that does batch builds and tests under various OS, Oracle client and NLS_LANG combinations, which I've run for the last couple of releases of DBD::Oracle; if you're interested I can tidy that up and publish it. -- Andy Hassall :: [EMAIL PROTECTED] :: http://www.andyh.co.uk http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool -Original Message- From: John Scoles [mailto:[EMAIL PROTECTED] Sent: 07 June 2006 17:10 To: [EMAIL PROTECTED] Cc: dbi-dev@perl.org Subject: Re: Testing DBD::Oracle array interface Thanks Andy that is great. I am finding a few things as I test on other boxes as well (Lunix and windows). Would you be so kind as to send me details on your test rig that is one area where my resources as a little limited. Cheers. - Original Message - From: "Andy Hassall" <[EMAIL PROTECTED]> To: "John Scoles" <[EMAIL PROTECTED]> Cc: Sent: Wednesday, June 07, 2006 11:29 AM Subject: Re: Testing DBD::Oracle array interface > > I have managed to add support for the Oracle Array Interface in > > DBD::Oracle. > > The original code comes from an old patch that Kristian Nielsen had > > created > > a while back but never seem to get into the to trunk. > > > > I was hoping someone could do a benchmark type test on loading many > > thousand > > or millions or records, as this seem to be what people want to use the > > interface for. > > I'm very interested in this, but for a slightly different reason - I > don't have huge data volumes, just hundreds to maybe a few thousand rows > at a time, but in one particular process I am having to connect over a > medium latency (120ms) transatlantic network link. The network overheads > for single rows inserts are killing performance here. > > Tried compiling on Cygwin to start with; this failed as an earlier change > in LOB support didn't add some lines to oci.def - patch attached to fix > it (this applies to both trunk and array branch). > > Have also now compiled and tested on Solaris; results from a simple test > inserting batches of 1000 rows to a remote database: > > Rate singlerow arrayinterface > singlerow 4.76/s -- -87% > arrayinterface 35.7/s 650% -- > > So that looks quite promising. > > thanks, > -- > Andy Hassall / <[EMAIL PROTECTED]> / <http://www.andyh.co.uk> > <http://www.andyhsoftware.co.uk/space> Space: disk usage analysis tool
Re: Testing DBD::Oracle array interface
> I have managed to add support for the Oracle Array Interface in > DBD::Oracle. > The original code comes from an old patch that Kristian Nielsen had > created > a while back but never seem to get into the to trunk. > > I was hoping someone could do a benchmark type test on loading many > thousand > or millions or records, as this seem to be what people want to use the > interface for. I'm very interested in this, but for a slightly different reason - I don't have huge data volumes, just hundreds to maybe a few thousand rows at a time, but in one particular process I am having to connect over a medium latency (120ms) transatlantic network link. The network overheads for single rows inserts are killing performance here. Tried compiling on Cygwin to start with; this failed as an earlier change in LOB support didn't add some lines to oci.def - patch attached to fix it (this applies to both trunk and array branch). Have also now compiled and tested on Solaris; results from a simple test inserting batches of 1000 rows to a remote database: Rate singlerow arrayinterface singlerow 4.76/s -- -87% arrayinterface 35.7/s 650% -- So that looks quite promising. thanks, -- Andy Hassall / <[EMAIL PROTECTED]> / <http://www.andyh.co.uk> <http://www.andyhsoftware.co.uk/space> Space: disk usage analysis tool dbd-oracle-oci.def.patch Description: Binary data
FW: %ENV changes not seen by other libraries in same process on cygwin
>> I'll try and get a patch out in the next day or two (unless I hit
>> any unexpected snags).
>>
>> I've named the new function "ora_cygwin_set_env" - is that
>> suitable?
>
> Perfect. Thanks Andy.
Patch attached. I've also added a README.cygwin.txt with the couple of
extra bits of information that are needed when building under Cygwin; native
vs. Cygwin paths, and the dependency on the w32api package.
All tests now successful; test results for r2429 (i.e. same revision as
RC5) plus patch applied, at the following address:
http://www.andyh.co.uk/temp/DBD-Oracle/r2429_plus_cygwin_patch/
--
Andy Hassall :: [EMAIL PROTECTED] :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool
Index: README.cygwin.txt
===
--- README.cygwin.txt (revision 0)
+++ README.cygwin.txt (revision 0)
@@ -0,0 +1,20 @@
+When building under Cygwin, ensure that your ORACLE_HOME environment
+variable is set to a native Windows path, but is included in the PATH
+environment variable using the Cygwin format (using "/cygdrive/").
+
+You can convert from Windows paths to Cygwin paths using the cygpath
+command. For example:
+
+export ORACLE_HOME='g:\oracle\product\10.2.0\db_1'
+export PATH=`cygpath -u $ORACLE_HOME`/bin:$PATH
+
+If building using Oracle Instant Client, omit "/bin".
+
+You will need the "w32api" Cygwin package installed, as DBD::Oracle requires
+headers from that package to address an issue where environment
+variable changes during the test suite are not passed to the Oracle DLL.
+This can be installed using the Cygwin installer, and selecting
+"w32api" under the "Libs" section.
+
+For more information on the issue see:
+http://groups.google.co.uk/group/perl.dbi.dev/msg/a369d927fae277b2
Index: dbdimp.c
===
--- dbdimp.c(revision 2429)
+++ dbdimp.c(working copy)
@@ -12,6 +12,11 @@
#define strcasecmp strcmpi
#endif
+#ifdef __CYGWIN32__
+#include "w32api/windows.h"
+#include "w32api/winbase.h"
+#endif /* __CYGWIN32__ */
+
#include "Oracle.h"
#if defined(CAN_USE_PRO_C)
@@ -95,7 +100,35 @@
return buf;
}
+#ifdef __CYGWIN32__
+/* Under Cygwin there are issues with setting environment variables
+ * at runtime such that Windows-native libraries loaded by a Cygwin
+ * process can see those changes.
+ *
+ * Cygwin maintains its own cache of environment variables, and also
+ * only writes to the Windows environment using the "_putenv" win32
+ * call. This call writes to a Windows C runtime cache, rather than
+ * the true process environment block.
+ *
+ * In order to change environment variables so that the Oracle client
+ * DLL can see the change, the win32 function SetEnvironmentVariable
+ * must be called. This function gives an interface to that API.
+ *
+ * It is only available when building under Cygwin, and is used by
+ * the testsuite.
+ *
+ * Whilst it could be called by end users, it should be used with
+ * caution, as it bypasses the environment variable conversions that
+ * Cygwin typically performs.
+ */
void
+ora_cygwin_set_env(char *name, char *value)
+{
+SetEnvironmentVariable(name, value);
+}
+#endif /* __CYGWIN32__ */
+
+void
dbd_init(dbistate_t *dbistate)
{
DBIS = dbistate;
Index: Oracle.pm
===
--- Oracle.pm (revision 2429)
+++ Oracle.pm (working copy)
@@ -25,7 +25,8 @@
) ],
ora_session_modes => [ qw( ORA_SYSDBA ORA_SYSOPER ) ],
);
-@EXPORT_OK = qw(ORA_OCI SQLCS_IMPLICIT SQLCS_NCHAR ora_env_var);
+@EXPORT_OK = qw(ORA_OCI SQLCS_IMPLICIT SQLCS_NCHAR ora_env_var
ora_cygwin_set_env);
+#unshift @EXPORT_OK, 'ora_cygwin_set_env' if $^O eq 'cygwin';
Exporter::export_ok_tags(qw(ora_types ora_session_modes));
my $Revision = substr(q$Revision: 1.103 $, 10);
Index: dbdimp.h
===
--- dbdimp.h(revision 2429)
+++ dbdimp.h(working copy)
@@ -263,6 +263,9 @@
char *ora_sql_error _((imp_sth_t *imp_sth, char *msg));
char *ora_env_var(char *name, char *buf, unsigned long size);
+#ifdef __CYGWIN32__
+void ora_cygwin_set_env(char *name, char *value);
+#endif /* __CYGWIN32__ */
sb4 dbd_phs_in _((dvoid *octxp, OCIBind *bindp, ub4 iter, ub4 index,
dvoid **bufpp, ub4 *alenp, ub1 *piecep, dvoid **indpp));
Index: Oracle.xs
===
--- Oracle.xs (revision 2429)
+++ Oracle.xs (working copy)
@@ -56,7 +56,17 @@
sv_setpv(sv, p);
ST(0) = sv;
+#ifdef __CYGWIN32__
+void
+ora_cygwin_set_env(name, value)
+char * name
+char * valu
RE: ANNOUNCE: DBD::Oracle 1.17 release candidate 5
> Here's a hopefully-final-stake-in-the-ground: > > http://www.data-plan.com/public/DBD-Oracle-1.17-RC5.tar.gz There seems to be a problem with the server? [EMAIL PROTECTED] ~/src $ wget http://www.data-plan.com/public/DBD-Oracle-1.17-RC5.tar.gz --23:48:53-- http://www.data-plan.com/public/DBD-Oracle-1.17-RC5.tar.gz => `DBD-Oracle-1.17-RC5.tar.gz' Resolving www.data-plan.com... 193.195.70.8 Connecting to www.data-plan.com|193.195.70.8|:80... connected. HTTP request sent, awaiting response... 500 Internal Error 23:49:04 ERROR 500: Internal Error. -- Andy Hassall :: [EMAIL PROTECTED] :: http://www.andyh.co.uk http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool
RE: %ENV changes not seen by other libraries in same process on cygwin
> > (3) Get DBD::Oracle to call the win32 SetEnvironmentVariable directly > > I'd be willing to add a cygwin-specific function to DBD::Oracle > (Oracle.xs and dbdimp.c) that calls SetEnvironmentVariable(). > > Patches welcome :) [An estimate of the time required would help since > I'm readying an RC5 that I hope to announce on dbi-users soonish.] I've made some initial changes, unconditionally adding the new code regardless of platform to test if it works. It certainly appears to - the previously failing nchar tests are now passing. I'll work on tidying it up, adding conditional compliation so it only applies to Cygwin and doing further testing on more combinations - I'll try and get a patch out in the next day or two (unless I hit any unexpected snags). I've named the new function "ora_cygwin_set_env" - is that suitable? -- Andy Hassall :: [EMAIL PROTECTED] :: http://www.andyh.co.uk http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool
RE: %ENV changes not seen by other libraries in same process on cygwin
> It sounds like the behavior is what you'd expect if %ENV was cached > instead of live (ie manipulating %ENV didn't alter the processes own > 'native' environment variables until a subprocess was spawned). Bingo. http://www.mail-archive.com/cygwin-cvs@cygwin.com/msg02867.html " winsup/cygwin ChangeLog environ.cc environ.h (win_env::add_cache): Add value to environment immediately if "immediate" is set. http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/environ.cc.diff?c vsroot=uberbaum&r1=1.109&r2=1.110 "immediate" defaults to false. I couldn't find a user-configurable way of setting it to true. This is the only place that calls the win32 SetEnvironmentVariable function - as opposed to putenv. For why this is bad for our purposes, over to MSDN: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/ _crt__putenv.2c_._wputenv.asp "_putenv and _wputenv affect only the environment that is local to the current process; you cannot use them to modify the command-level environment. That is, these functions operate only on data structures accessible to the run-time library and not on the environment "segment" created for a process by the operating system. When the current process terminates, the environment reverts to the level of the calling process (in most cases, the operating-system level). However, the modified environment can be passed to any new processes created by _spawn, _exec, or system, and these new processes get any new items added by _putenv and _wputenv." OK, so the Oracle DLL is unlikely to see any of these changes when it gets dynamically loaded into the current Perl process - since the real process-level environment block is unchanged via (perl)$ENV -> (cygwin)putenv -> cache and/or (win32)_putenv. Whereas: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/bas e/setenvironmentvariable.asp "The SetEnvironmentVariable function sets the contents of the specified environment variable for the current process." We want that called when a (Cygwin) environment variable is changed. More supporting evidence that's it's a Cygwin-level issue: http://www.cygwin.com/ml/cygwin/1999-04/msg00473.html There's a "noenvcache" option for the CYGWIN environment variable, but since the only place that SetEnvironmentVariable is called is actually inside the cache code, that doesn't help. It works on the native win32 version of Perl, because in $PERL_SRC/win32/win32.c, function win32_putenv _does_ call SetEnvironmentVariable. So, what's the options? Here's some: (1) Get Cygwin changed to sync up the win32 process environment with its own environment more aggressively - or at least, to have the option to do so (since it was presumably changed to not doing this for a good reason). (2) Get Perl on Cygwin to call the native win32 SetEnvironmentVariable at the same time as the cygwin putenv. This is probably a bad idea, since cygwin does some conversion on environment variables that this would likely interfere with. (3) Get DBD::Oracle to call the win32 SetEnvironmentVariable directly, at least during the testsuite, if building on Cygwin, rather than (or in addition to) writing to $ENV. One module that looked promising was Env::C - but even though this has "#if defined(WIN32)" tests, that just switches to using _putenv instead of putenv - but not SetEnvironmentVariable. (4) Limit the test suite under cygwin to only run those tests where NLS_NCHAR is already set to the required value - i.e. never actually call set_nls_nchar(). (1) and (2) would obviously take a while and need the agreement of the maintainers of each. I can have a look at (3) in DBD::Oracle, but it'll probably involve some C, since the Win32 module (installable from cygwin's installer as perl-libwin32) doesn't include SetEnvironmentVariable, and Win32::API won't build. Option (4) reduces the nchar test coverage quite a bit, so it's not very satisfactory, but it would be simplest. -- Andy Hassall :: [EMAIL PROTECTED] :: http://www.andyh.co.uk http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool
RE: ANNOUNCE: DBD::Oracle 1.17 release candidate 4
> Here's another stake-in-the-ground so we know where we're at:
>
> http://www.data-plan.com/public/DBD-Oracle-1.17-RC4.tar.gz
Test results for RC4 here:
http://www.andyh.co.uk/temp/DBD-Oracle/1.17RC4/
Just Linux and native Windows on there - all the combinations from last
time, plus new runs against an XE database (which appears to act like a
plain 10.2 database) - previously only tested the XE client, not the server.
100% pass on all of those.
For the Cygwin failures, something to do with environment variables is
prime suspect at the moment, specifically how it sets NLS_NCHAR at runtime
for some of the tests.
It seems to depend on the value of NLS_NCHAR before running the tests under
Cygwin. If it's set to AL32UTF8, then 22nchar_al32utf8 passes. If it's blank
or set to another value, the test fails. But on other platforms (even native
Windows on the same machine), the value is overridden at runtime by the
tests, so it doesn't matter what it's initially set to.
The debug output that shows the current value of NLS_NCHAR shows it as
AL32UTF8, but still it behaves as if it were the value in the parent process
environment.
There's a Perl bug "#36665: delete $ENV{FOO} leaves $FOO visible in
subprocesses on Cygwin Perl"
https://rt.perl.org/rt3/Ticket/Display.html?id=36665 which indicates there's
some issues with env vars under Cygwin Perl, but it doesn't quite explain
this behaviour - and it persisted even with trying the latest dev version of
Perl which has the fix for that particular bug.
Haven't got it quite worked out yet though, but seem to be getting closer.
--
Andy Hassall :: [EMAIL PROTECTED] :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool
RE: ANNOUNCE: DBD::Oracle 1.17 release candidate
> Looking at the logs again it seems the picture isn't too bad... > > Note that the NLS_LANG=.AL32UTF8 tests pass. That's the > config you ought to use. > > See the Unicode section in the DBD::Oracle docs for why > Oracle's "UTF8" > character set is broken and AL32UTF8 should be used instead. > > For the NLS_LANG=.WE8ISO8859P15 case you'll see that the unicode tests > are being skipped on non-cygwin platforms, so the real bug is in the > code that checks if the test should be run at all. They shouldn't. But tests like 22nchar_al32utf8 are failing, and only under Cygwin - these are "national" charset columns so should always be able to take Unicode (at least since 9i) - so shouldn't be skipped. Comparing two runs, cygwin vs. linux, both with: Database and client versions and character sets: Database 10.2.0.1.0 CHAR set is WE8ISO8859P15 (Non-Unicode), NCHAR set is AL16UTF16 (Unicode) Client 9.2.0.7 NLS_LANG is '.WE8ISO8859P15', NLS_NCHAR is '' http://www.andyh.co.uk/temp/DBD-Oracle/1.17RC1/linux_9207full_test102_WE8ISO 8859P15_test.log t/22nchar_al32utf8..ok t/22nchar_utf8..ok The tests run on Linux and pass. http://www.andyh.co.uk/temp/DBD-Oracle/1.17RC1/cygwin_9207full_test102_WE8IS O8859P15_test.log t/22nchar_al32utf8.. [ ... ] Failed 2/37 tests, 94.59% okay t/22nchar_utf8.. [ ... ] Failed 6/53 tests, 88.68% okay The same tests, same database, same NLS_LANG, fail under Cygwin. Unless I'm missing something! But that's why it looks a bit more involved to fix to me? -- Andy Hassall :: [EMAIL PROTECTED] :: http://www.andyh.co.uk http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool
RE: ANNOUNCE: DBD::Oracle 1.17 release candidate 3
> > What seems to be happening with RC3 is that Makefile.PL is behaving
> > as if I had a full Oracle install rather than an Instant Client.
>
> Yeap. I'll take a closer look at the log and see if I can spot why.
> Thanks for the details.
I think it just needs the Oracle XE and Oracle Instant Client branches
swapping around.
r2395 changed:
-elsif ($::opt_m =~ /\bdemo_xe.mk$/) { # Oracle XE
+elsif ($mkfile = find_mkfile() and $mkfile =~ /\bdemo_xe.mk$/) { # Oracle
XE
This is executed before the check for the Instant Client library that makes
it pick the direct-link approach. Problem is that find_mkfile() does a die()
if it can't find the makefile. Since the IC SDK directory isn't searched,
and it's not needed anyway if it's going for direct link, then this makes
the IC build fail at this point.
Swap the XE and IC tests over (as in attached patch) and it builds
successfully again for me (on Linux 10201instant, 10201xe, 10201full,
10104instant, 9207full).
So it then tries in order (for UNIX variants):
(1) Direct link (user-selected with -l)
(2) Instant Client direct link
(3) Oracle XE makefile
(4) Full client makefile
--
Andy Hassall :: [EMAIL PROTECTED] :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool
Index: Makefile.PL
===
--- Makefile.PL (revision 2402)
+++ Makefile.PL (working copy)
@@ -302,31 +302,6 @@
check_ldlibpthname();
}
-elsif ($mkfile = find_mkfile() and $mkfile =~ /\bdemo_xe.mk$/) { # Oracle XE
-
-print "Looks like Oracle XE ($mkfile)\n";
-
-fetch_oci_macros($mkfile);
-$MK{CCINCLUDES} = '-I$(ICINCHOME)'; # undo odd refinition in demo_xe.mk
-
-# From linux Oracle XE (10.2.0):
-# ICINCHOME=$(ORACLE_HOME)/rdbms/public/
-# ICLIBHOME=$(ORACLE_HOME)/lib/
-# ICLIBPATH=-L$(ICLIBHOME)
-# THREADLIBS=-lpthread[initially -lthread then redefined]
-# CCLIB=$(ICLIBPATH) -lclntsh $(THREADLIBS)
-# CCINCLUDES = -I$(ICINCHOME) [see above]
-# CCFLAGS=$(CCINCLUDES) -DLINUX -D_GNU_SOURCE -D_REENTRANT -g [initially
without -DLINUX -D_GNU_SOURCE]
-my $cclib = expand_mkvars($MK{CCLIB}, 0, 1);
-my $ccflags = expand_mkvars($MK{CCFLAGS}, 0, 1);
-
-$linkwith_msg = "$cclib";
-$opts{LIBS} = [ $cclib ];
-$opts{INC} = "-I$dbi_arch_dir $ccflags";
-$opts{dynamic_lib} = { OTHERLDFLAGS => "$::opt_g" };
-check_ldlibpthname();
-}
-
# --- special case for Oracle 10g instant client
elsif (-e "$OH/libclntsh.$so" or -e "$OH/libclntsh.$so.10.1") { # note lack
of ../lib/...
@@ -356,6 +331,32 @@
$opts{INC} = "-I$inc -I$dbi_arch_dir";
}
+
+elsif ($mkfile = find_mkfile() and $mkfile =~ /\bdemo_xe.mk$/) { # Oracle XE
+
+print "Looks like Oracle XE ($mkfile)\n";
+
+fetch_oci_macros($mkfile);
+$MK{CCINCLUDES} = '-I$(ICINCHOME)'; # undo odd refinition in demo_xe.mk
+
+# From linux Oracle XE (10.2.0):
+# ICINCHOME=$(ORACLE_HOME)/rdbms/public/
+# ICLIBHOME=$(ORACLE_HOME)/lib/
+# ICLIBPATH=-L$(ICLIBHOME)
+# THREADLIBS=-lpthread[initially -lthread then redefined]
+# CCLIB=$(ICLIBPATH) -lclntsh $(THREADLIBS)
+# CCINCLUDES = -I$(ICINCHOME) [see above]
+# CCFLAGS=$(CCINCLUDES) -DLINUX -D_GNU_SOURCE -D_REENTRANT -g [initially
without -DLINUX -D_GNU_SOURCE]
+my $cclib = expand_mkvars($MK{CCLIB}, 0, 1);
+my $ccflags = expand_mkvars($MK{CCFLAGS}, 0, 1);
+
+$linkwith_msg = "$cclib";
+$opts{LIBS} = [ $cclib ];
+$opts{INC} = "-I$dbi_arch_dir $ccflags";
+$opts{dynamic_lib} = { OTHERLDFLAGS => "$::opt_g" };
+check_ldlibpthname();
+}
+
else { # --- trawl the guts of Oracle's make files looking the how it wants to
link
#Lincoln: pick the right library path
check_ldlibpthname();
Instant Client packages (was: [svn:dbd-oracle] r2382 - dbd-oracle/trunk)
Is it worth being a bit more specific about what Instant Client packages to install in README? e.g.: (names in quotes match those used in the headings on http://www.oracle.com/technology/software/tech/oci/instantclient/htdocs/linu xsoft.html) Index: README === --- README (revision 2395) +++ README (working copy) @@ -48,7 +48,13 @@ Remember to *read* the DBI README file and this one CAREFULLY! Install enough Oracle software to enable DBD::Oracle to build. -For Oracle Instant Client that means install the SDK component. + +For Oracle Instant Client that means install the following packages: +* The "Basic" package for the essential Oracle libraries. +* The "SDK" package for the headers and makefile. +* The "SQL*Plus" component is optional, but will help DBD::Oracle + determine your Oracle version more easily. + For full Oracle installs that usually includes Pro*C and SQL*Net. (That's not very specific because it varies between Oracle releases.) -- Andy Hassall :: [EMAIL PROTECTED] :: http://www.andyh.co.uk http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: 11 January 2006 11:23 > To: [EMAIL PROTECTED] > Subject: [svn:dbd-oracle] r2382 - dbd-oracle/trunk > > Author: timbo > Date: Wed Jan 11 03:23:28 2006 > New Revision: 2382 > > Modified: >dbd-oracle/trunk/README > Log: > Assorted updates to the README > > > Modified: dbd-oracle/trunk/README > == > > --- dbd-oracle/trunk/README (original) > +++ dbd-oracle/trunk/README Wed Jan 11 03:23:28 2006 > @@ -1,7 +1,7 @@ > > DBD::Oracle -- an Oracle interface for Perl 5. > > - Copyright (c) 1994-2005 Tim Bunce, Ireland. > + Copyright (c) 1994-2006 Tim Bunce, Ireland. > > See the COPYRIGHT section in the Oracle.pm file for terms. > > @@ -23,7 +23,6 @@ DBD::Oracle -- an Oracle interface for > README.sec.txt - Oracle security issues to be aware of > README.login.txt - Help on how to connect to Oracle > README.longs.txt - Help on handling LONGs > - README.utf8.txt - Help on using UFT8 > README.clients.txt - What Oracle client files you need installed > > > @@ -49,14 +48,17 @@ DBD::Oracle -- an Oracle interface for > Remember to *read* the DBI README file and this one CAREFULLY! > > Install enough Oracle software to enable DBD::Oracle to build. > -That usually includes Pro*C and SQL*Net. That's not very specific > -because it varies so much between Oracle releases. > +For Oracle Instant Client that means install the SDK component. > +For full Oracle installs that usually includes Pro*C and SQL*Net. > +(That's not very specific because it varies between > Oracle releases.) > > -Except under MS Windows, ORACLE_HOME must point to the > Oracle Home > -used to create DBD::Oracle. Even under MS Windows, it > doesn't hurt. > +The ORACLE_HOME environment variable must point to the > Oracle Home > +used to create DBD::Oracle. (Not essential under MS Windows). > > -Make sure Oracle is working and you can use Oracle commands > -like sqlplus to talk to the database *from the machine* you > +MOST IMPORTANTLY: > + > +Make sure Oracle is working and you can use the Oracle sqlplus > +command to talk to the database *from the machine* you > want to build DBD::Oracle on. (This often involves setting > environment variables like PATH, LD_LIBRARY_PATH, TWO_TASK etc.) > > @@ -71,18 +73,17 @@ on Solaris) and add that to your PATH en > > Don't worry about most warnings when make runs, specifically > ones like > "end-of-loop code not reached", "ANSI C forbids braced-groups within > -expressions", "cast increases required alignment of target type" and > -"passing arg 2 of `oerhms' with different width due to prototype". > +expressions", "cast increases required alignment of target type" etc. > > If you have problems see the 'IF YOU HAVE PROBLEMS' section below. > -If it builds without error you should then run the tests. For the > +If it builds without error you should then run 'make test'. For the > main tests to work they must be able to connect to an Oracle > database. > > You will need to set either the TWO_TASK or ORACLE_SID environment > variables to the correct values for your database. Consult Oracle > documentation
RE: ANNOUNCE: DBD::Oracle 1.17 release candidate
> On Sun, Jan 01, 2006 at 11:39:17PM -0000, Andy Hassall wrote: >> >> Under Cygwin there are additional Unicode-related failures. > > Other will have to scratch that itch. I'd like to scratch, since I've written a Perl+Oracle tool at the office (an Oracle schema documentation tool) that is easier to distribute to other departments using Cygwin than ActiveState Perl because it has quite a few module dependencies that aren't all up-to-date using ActiveState PPM. Although the main one was DBD::Oracle itself, but it seems ActiveState have recently started building that again with their version that also bundles Oracle Instant Client, so ActiveState might again be a feasible option. I'd feel more confident with the Cygwin route if DBD::Oracle Unicode support was 100% under Cygwin in case anyone enters non-ISO-8859-15 data into it (which so far they haven't - but it does use NVARCHAR2 columns just in case). However, realistically I don't think I'll have the time to look into it for this release, since 1.17 seems pretty close to ready. This may be something I can try and help with for 1.18. At the moment I'm not quite sure at which layer to start looking - it's apparently something specific to the Cygwin build of Perl, or a lower-level library within Cygwin on which its Perl is based, as neither the Windows-native nor Linux nor Solaris builds exhibit the problem. The output data in all the failing tests is shorter than the expected result, so it looks like something along the line is translating the data through a character set encoding with a smaller répertoire, such as a single-byte encoding, or it's corrupting it by trying to force it to UTF-8 and failing in some way - but these are just guesses so far - more investigation is clearly needed. -- Andy Hassall :: [EMAIL PROTECTED] :: http://www.andyh.co.uk http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool
RE: ANNOUNCE: DBD::Oracle 1.17 release candidate 2
Linux build fails with RC2:
[EMAIL PROTECTED] ~/src/DBD-Oracle-1.17 $ perl Makefile.PL
Using DBI 1.50 (for perl 5.008007 on i686-linux) installed in
/home/andyh/perl/lib/site_perl/5.8.7/i686-linux/auto/DBI/
Configuring DBD::Oracle for perl 5.008007 on linux (i686-linux)
Remember to actually *READ* the README file! Especially if you have any
problems.
Using Oracle in /u01/app/oracle/product/10.2.0/db_1
DEFINE _SQLPLUS_RELEASE = "1002000100" (CHAR)
Oracle version 10.2.0.1 (10.2)
Looks like Oracle XE
(/u01/app/oracle/product/10.2.0/db_1/rdbms/demo/demo_xe.mk)
Unable to read /u01/app/oracle/product/10.2.0/db_1/rdbms/demo/demo_xe.mk: No
such file or directory at Makefile.PL line 1264.
I get this regardless of which Oracle home I actually have in ORACLE_HOME
and PATH.
I think the following change made in r2377 is the culprit:
# default to using XE .mk file if one exists
-if (-s "$OH/rdbms/demo/demo_xe.mk" && !$::opt_m) {
-$::opt_m = "$OH/rdbms/demo/demo_xe.mk";
-warn "Looks like an Oracle XE, so we'll use $::opt_m\n";
-}
+$::opt_m ||= "$OH/rdbms/demo/demo_xe.mk";
This ends up setting $::opt_m to an XE makefile even if it doesn't exist, so
it goes into the XE-specific branch below, and so never ends up calling
find_mkfile() in the generic "else" branch.
Should the change above be reverted?
Or might it be better to call find_mkfile() earlier instead, to give
$::opt_m a value (since the XE makefile is now in the list searched in
find_mkfile)?
Reverting the changed lines above works for me, but I don't have XE
installed on Linux at the moment; I've only got that installed on Windows. I
suspect if I install XE on Linux then it'll cause problems as it'll pick up
the XE makefile, but use a non-XE home?
I'm trying to install XE on Linux now, but have run into some complications.
If I can get it installed I'll post back with some results on how it
interacts with the code above.
The good news is that 24implicit_utf8 appears to be passing where previously
it failed, i.e. with:
Database 10.2.0.1.0 CHAR set is WE8ISO8859P15 (Non-Unicode), NCHAR set is
AL16UTF16 (Unicode)
Client 10.2.0.1 NLS_LANG is '.UTF8', NLS_NCHAR is ''
... at least from Linux 10gR2/full client (after fixing the Makefile.PL to
get it to build). I'll run the other combinations again when I get a chance.
--
Andy Hassall :: [EMAIL PROTECTED] :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool
> -Original Message-
> From: Tim Bunce [mailto:[EMAIL PROTECTED]
> Sent: 11 January 2006 12:55
> To: dbi-dev@perl.org
> Cc: Paul Vallee; John Scoles
> Subject: ANNOUNCE: DBD::Oracle 1.17 release candidate 2
>
>http://www.data-plan.com/public/DBD-Oracle-1.17-RC2.tar.gz
>
> =head1 Changes in DBD-Oracle 1.17 RC2 (svn rev 2385)
>
> Fixed automatic csform setting for some UTF8 cases and for
> Oracle 8.0
> Fixed truncation error on fetch into UTF8 charset thanks to
> Honza Pazdziora.
> Fixed INTERVAL DAY TO SECOND thanks to Honza Pazdziora.
> Fixed undef warnings when connecting with undef $user.
> Fixed LOB streaming example thanks to Pablo Zorzoli.
>
> Added support for nested cursors in select lists thanks to
> Charles Jardine.
> Added "Trailing Spaces" section to docs thanks to Michael A Chase.
> Added support for binary floats/doubles thanks to Dennis Box.
>
> Changed "Binding Cursors" docs, clarifying examples thanks
> to Charles Jardine.
> Changed Makefile.PL to avoid risk of sqlplus hanging thanks
> to Mark Dedlow,
> and more reliably use correct sqlplus thanks to Honza Pazdziora.
> Changed Makefile.PL to prefer ~/rdbms/public over other
> ~/rdbms/* for .h files.
> Changed Makefile.PL to improve build rule detection.
> Changed Makefile.PL to improve cygwin build thanks to Andy Hassall.
> Changed Makefile.PL to Instant Client build support thanks
> to Hilmar Lapp.
> Changed Makefile.PL to do VMS logical name checks thanks to
> Jakob Snoer.
> Updated README.vms re logical name tables thanks to Jakob Snoer.
> Updated README.aix thanks to Stephen de Vries.
> Updated README.macosx thanks to Stephen de Vries.
> Renamed README.*'s to add .txt suffix to make life easier for some.
> Removed README.utf8 since the topic was covered better in
> the main docs.
>
> The Copyright terms for DBD::Oracle have been simplified
> and now read:
> The DBD::Oracle module is free software; you can redistribute it
> and/or modify it under the same terms as Perl 5.
>
> =cut
>
> As before, any and all testing would be greatly appreciated,
> but especially
> testing of building against Oracle Instant Client and Orac
RE: ANNOUNCE: DBD::Oracle 1.17 release candidate
> Any and all testing would be greatly appreciated, but especially > testing of building against Oracle Instant Client and Oracle XE > on a range of platforms. I've put up a page with the test results for various combinations at: http://www.andyh.co.uk/temp/DBD-Oracle/1.17RC1/ It builds successfully and the majority of tests run OK on all the combinations, but there are some Unicode-related issues, in particular on 24implicit_utf8 on Linux and Windows with UTF8 client character set against a non-Unicode database. Under Cygwin there are additional Unicode-related failures. -- Andy Hassall :: [EMAIL PROTECTED] :: http://www.andyh.co.uk http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool
RE: PATCH: Use the correct sqlplus to find out version (was: Re: ANNOUNCE: DBD::Oracle 1.17 release candidate)
There's a couple of extra quirks to consider when building on Cygwin. You
have to specify ORACLE_HOME as a Windows-native path (since Oracle itself
needs it, and won't understand Cygwin paths) e.g.:
c:\oracle\ora92
(or with the slashes reversed) ... but PATH must contain only Cygwin-style
paths, e.g.:
/cygdrive/c/oracle/ora92
Since $Config{path_sep} on Cygwin is ":" (as on Unix), the ":" in the drive
specification messes things up when it's added to PATH - it adds two
non-existent directories instead of the Oracle home.
The path ought to be run through `cygpath -u` first. As far as I can see
this is the only place where a path list is being built up; for individual
file operations, Cygwin will accept either sort of path.
The next quirk is Cygwin and/or Perl's handling of "-x" to find if
sqlplus.exe is executable in "find_bin". See:
http://www.cygwin.com/ml/cygwin/2005-06/msg00168.html
http://www.cygwin.com/ml/cygwin/2005-06/msg00313.html
To get Cygwin to report sqlplus.exe as actually executable, it needs the
"use filetest 'access'" pragma adding.
http://search.cpan.org/dist/perl/lib/filetest.pm
Patch on top of previous patch to cope with this attached.
--
Andy Hassall :: [EMAIL PROTECTED] :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool
> -Original Message-
> From: Honza Pazdziora [mailto:[EMAIL PROTECTED]
> Sent: 29 December 2005 20:22
> To: Tim Bunce
> Cc: dbi-dev@perl.org
> Subject: PATCH: Use the correct sqlplus to find out version
> (was: Re: ANNOUNCE: DBD::Oracle 1.17 release candidate)
>
> On Wed, Dec 28, 2005 at 11:11:31PM +, Tim Bunce wrote:
> > http://www.data-plan.com/public/DBD-Oracle-1.17.tar.gz
> >
> > =head1 Changes in DBD-Oracle 1.17 (svn rev 2334)
>
> Hello Tim,
>
> please consider the following patch which uses sqlplus from
> ORACLE_HOME first, to figure out the client version:
>
> --- DBD-Oracle-1.17/Makefile.PL 2005-12-28 23:09:52.0 +0100
> +++ DBD-Oracle-1.17-patched/Makefile.PL 2005-12-29
> 21:09:27.0 +0100
> @@ -1433,7 +1433,7 @@
> my $client_version_full = '';
>
> my $sqlplus_exe = ($os eq 'Win32' || $os eq 'MSWin32') ?
> "sqlplus.exe" : "sqlplus";
> -local $ENV{PATH} = join $Config{path_sep}, $ENV{PATH},
> "$OH/bin", $OH;
> +local $ENV{PATH} = join $Config{path_sep}, "$OH/bin",
> $OH, $ENV{PATH};
> local $ENV{SQLPATH} = ""; # avoid $SQLPATH/login.sql
> causing sqlplus to hang
> print "path=$ENV{PATH}\n";
> if (find_bin($sqlplus_exe)) {
>
> Without this patch, any random sqlplus from user's PATH will be used
> instead of the sqlplus in $OH. In fact,
>
> local $ENV{PATH} = join $Config{path_sep}, "$OH/bin", $OH;
>
> might be even better, omitting $ENV{PATH} completely and just focusing
> on the ORACLE_HOME directory.
>
> Yours,
>
> --
> --
> --
> Honza Pazdziora | [EMAIL PROTECTED] |
> http://www.fi.muni.cz/~adelton/
> .project: Perl, mod_perl, DBI, Oracle, large Web systems,
> XML/XSL, ...
> Only self-confident people can be simple.
Index: Makefile.PL
===
--- Makefile.PL (revision 2351)
+++ Makefile.PL (working copy)
@@ -1383,6 +1383,7 @@
sub find_bin{
+use filetest 'access';
my $bin = shift;
my $path_sep = $Config{path_sep};
foreach (split(/\Q$path_sep/, $ENV{PATH})){
@@ -1433,8 +1434,21 @@
my $client_version_full = '';
-my $sqlplus_exe = ($os eq 'Win32' || $os eq 'MSWin32') ? "sqlplus.exe" :
"sqlplus";
-local $ENV{PATH} = join $Config{path_sep}, "$OH/bin", $OH, $ENV{PATH};
+my $sqlplus_exe = ($os eq 'Win32' || $os eq 'MSWin32' || $os eq 'cygwin')
? "sqlplus.exe" : "sqlplus";
+
+my $OH_path = $OH;
+
+# When building under Cygwin, ORACLE_HOME must be a native Windows
+# path so Oracle itself can use it, but it needs to be translated
+# to a Cygwin path so it can be joined into the PATH.
+# Otherwise, the colon in the drive specification (e.g. "c:") is
+# treated as a separator.
+
+if ($os eq 'cygwin') {
+chomp($OH_path = `/usr/bin/cygpath -u $OH_path`)
+}
+
+local $ENV{PATH} = join $Config{path_sep}, "$OH_path/bin", $OH_path,
$ENV{PATH};
local $ENV{SQLPATH} = ""; # avoid $SQLPATH/login.sql causing sqlplus to
hang
print "path=$ENV{PATH}\n";
if (find_bin($sqlplus_exe)) {
RE: DBD Oracle & Instantclient 10
Part of the changes look for Unix-style shared libraries which doesn't cover Windows instant client; here's a patch that tweaks enough to get it to build, and logs of Windows-native and Cygwin builds and tests. Both done against the following instant client zips unpacked to d:\lib\instantclient_10_2: instantclient-basic-win32-10.2.0.1-20050930.zip instantclient-sdk-win32-10.2.0.1-20050930.zip instantclient-sqlplus-win32-10.2.0.1-20050930.zip The changes in the patch are: (1) Also look for oci.dll in the place where libclntsh.so.10.1 is checked for the ORACLE_HOME validity check. (2) Modified the MSWin32/cygwin-specific OCIDIR search to be able to use the 'sdk' subdirectory from the instant client. (3) Fix a bug in the statement that checks for sqlplus.exe vs. sqlplus - it was looking for $^O eq 'Win32' when it's really 'MSWin32'. With these it compiles and runs; not 100% test passes, but I believe these are existing issues in the latest revision of DBD::Oracle and not due to the makefile changes. -- Andy Hassall :: [EMAIL PROTECTED] :: http://www.andyh.co.uk http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool > -Original Message- > From: John Scoles [mailto:[EMAIL PROTECTED] > Sent: 06 October 2005 12:35 > To: dbi-dev@perl.org > Subject: DBD Oracle & Instantclient 10 > > I am looking for volunteers testers for a new version of the > Makefile.PL for Oracle Instantclient 10. > > You can find it at > http://svn.perl.org/modules/dbd-oracle/branches/pythian > > This version has been tested on a Linux box but I would like > to see how it performs on other environments. > > Any feedback you may have would be very much appreciated. > > TXs [EMAIL PROTECTED] ~/src/pythian $ export PATH="/cygdrive/d/lib/instantclient_10_2:$PATH" [EMAIL PROTECTED] ~/src/pythian $ which sqlplus /cygdrive/d/lib/instantclient_10_2/sqlplus [EMAIL PROTECTED] ~/src/pythian $ export ORACLE_HOME=d:/lib/instantclient_10_2 [EMAIL PROTECTED] ~/src/pythian $ export NLS_LANG=.WE8ISO8859P15 [EMAIL PROTECTED] ~/src/pythian $ export ORACLE_USERID=test/[EMAIL PROTECTED] [EMAIL PROTECTED] ~/src/pythian $ perl Makefile.PL Using DBI 1.47 (for perl 5.008007 on cygwin-thread-multi-64int) installed in /usr/lib/perl5/site_perl/5.8/cygwin/auto/DBI/ Configuring DBD::Oracle ... >>> Remember to actually *READ* the README file! Especially if you have any problems. Using Oracle in d:/lib/instantclient_10_2 DEFINE _SQLPLUS_RELEASE = "1002000100" (CHAR) Oracle version 10.2.0.1 (10.2) Using OCI directory 'sdk' Checking for functioning wait.ph System: perl5.008007 cygwin_nt-5.1 inspiron 1.5.18(0.13242) 2005-07-02 20:30 i686 unknown unknown cygwin Compiler: gcc -O3 -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe -I/usr/local/include Linker: /usr/bin/ld Sysliblist: Checking if your kit is complete... Warning: the following files are missing in your kit: META.yml Please inform the author. LD_RUN_PATH=d:/lib/instantclient_10_2/lib:d:/lib/instantclient_10_2/rdbms/lib Using DBD::Oracle 1.16. Using DBD::Oracle 1.16. Using DBI 1.47 (for perl 5.008007 on cygwin-thread-multi-64int) installed in /usr/lib/perl5/site_perl/5.8/cygwin/auto/DBI/ Writing Makefile for DBD::Oracle *** If you have problems... read all the log printed above, and the README and README.help files. (Of course, you have read README by now anyway, haven't you?) [EMAIL PROTECTED] ~/src/pythian $ make cp Oracle.pm blib/lib/DBD/Oracle.pm cp mkta.pl blib/lib/DBD/mkta.pl cp oraperl.ph blib/lib/oraperl.ph cp dbdimp.h blib/arch/auto/DBD/Oracle/dbdimp.h cp ocitrace.h blib/arch/auto/DBD/Oracle/ocitrace.h cp Oraperl.pm blib/lib/Oraperl.pm cp Oracle.h blib/arch/auto/DBD/Oracle/Oracle.h cp mk.pm blib/arch/auto/DBD/Oracle/mk.pm cp lib/DBD/Oracle/GetInfo.pm blib/lib/DBD/Oracle/GetInfo.pm /usr/bin/perl.exe -p -e "s/~DRIVER~/Oracle/g" /usr/lib/perl5/site_perl/5.8/cygwin/auto/DBI//Driver.xst > Oracle.xsi /usr/bin/perl.exe /usr/lib/perl5/5.8/ExtUtils/xsubpp -typemap /usr/lib/perl5/5.8/ExtUtils/typemap -typemap typemap Oracle.xs > Oracle.xsc && mv Oracle.xsc Oracle.c gcc -g -c -Id:/lib/instantclient_10_2/sdk/include -Id:/lib/instantclient_10_2/rdbms/demo -I/usr/lib/perl5/site_perl/5.8/cygwin/auto/DBI/ -g -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe -I/usr/local/include -DUSEIMPORTLIB -DVERSION=\"1.16\" -DXS_VERSION=\"1.16\" "-I/usr/lib/perl5/5.8/cygwin/CORE" -Wall -Wno-comment -DUTF8_SUPPORT -DNEW_OCI_INIT -DORA_OCI_VERSION=\"10.2.0.1\" -Wall -Wcast-align -Wpointer-arith -Wbad-function-cast -Wcast-qual -Wconversion Oracle.c In file included from Oracle.c:85: /usr/lib/perl5/site_perl/5.8/cygwin/auto/DBI/Driver_xst.h: In function `dbdxst_bind_params': /usr/lib/perl5/site_perl/5.8/
RE: PATCH: Segfault with selecting intervals
> + my $ora_server_version = $dbh->func("ora_server_version");
> + if ($ora_server_version < 10) {
> +ok(0, 1, 1); # skip
The INTERVAL datatype was introduced in 9i - in which case perhaps this
should be "< 9.2" ?
Also regarding:
--- oci8.c.orig 2005-06-06 10:31:38.0 +0200
+++ oci8.c 2005-06-06 10:35:29.0 +0200
@@ -1207,6 +1207,7 @@
case 182: /* INTERVAL YEAR TO MONTH */
case 183: /* INTERVAL DAY TO SECOND */
+ case 190: /* INTERVAL DAY TO SECOND */
case 187: /* TIMESTAMP */
case 188: /* TIMESTAMP WITH TIME ZONE */
case 232: /* TIMESTAMP WITH LOCAL TIME ZONE */
For completeness shouldn't that also then include:
+ case 189: /* INTERVAL YEAR TO MONTH descriptor */
as per:
http://download-uk.oracle.com/docs/cd/B10501_01/appdev.920/a96584/oci03typ.h
tm#421821
... and a similar test using TO_YMINTERVAL?
--
Andy Hassall <[EMAIL PROTECTED]> / Space: disk usage analysis tool
<http://www.andyh.co.uk> / <http://www.andyhsoftware.co.uk/space>
RE: [svn:dbd-oracle] rev 515 - dbd-oracle/trunk
Haven't had time to do a test on as many combinations as last time, and
changed distributions on linux testbox so haven't got Oracle back up again
on that.
FWIW I have the following 100% passes on Windows, Visual Studio .NET 2003,
Oracle 9.2.0.5 and 10.1.0.3 with DBD::Oracle svn rev 515 with Unicode-based
databases.
Operating system: MSWin32
--
Build against Oracle 9.2.0.5SUCCESS
--
Test against database: exc92
(9.2.0.5, Windows, AL32UTF8 / AL16UTF16)
--
NLS_LANG=WE8ISO8859P15PASS
NLS_LANG=WE8ISO8859P1 PASS
NLS_LANG=WE8MSWIN1252 PASS
NLS_LANG=UTF8 PASS
NLS_LANG=AL32UTF8 PASS
Operating system: MSWin32
--
Build against Oracle 10.1.0.3 SUCCESS
--
Test against database: exc101
(10.0.1.3, Windows, AL32UTF8 / AL16UTF16)
--
NLS_LANG=WE8ISO8859P15PASS
NLS_LANG=WE8ISO8859P1 PASS
NLS_LANG=WE8MSWIN1252 PASS
NLS_LANG=UTF8 PASS
NLS_LANG=AL32UTF8 PASS
I can see there being an ultimate character set torture test with the
Encode module, and working out the intersection between NLS_LANG's character
set and that of the database character set and again for the database
national character set, and running each character through an insert and
select and making sure it comes out the same as it went in (taking into
account UTF8 flags and so on). No time to write such a thing at the moment
though :-(
--
Andy Hassall <[EMAIL PROTECTED]> / Space: disk usage analysis tool
<http://www.andyh.co.uk> / <http://www.andyhsoftware.co.uk/space>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: 22 October 2004 10:09
> To: [EMAIL PROTECTED]
> Subject: [svn:dbd-oracle] rev 515 - dbd-oracle/trunk
>
> Author: timbo
> Date: Fri Oct 22 02:09:14 2004
> New Revision: 515
>
> Modified:
>dbd-oracle/trunk/Changes
>dbd-oracle/trunk/Makefile.PL
> Log:
> A release, at last!
>
>
> Modified: dbd-oracle/trunk/Changes
> ==
>
> --- dbd-oracle/trunk/Changes (original)
> +++ dbd-oracle/trunk/Changes Fri Oct 22 02:09:14 2004
> @@ -1,4 +1,4 @@
> -=head1 Changes in DBD-Oracle 1.16 (svn rev 509) 21st October 2004
> +=head1 Changes in DBD-Oracle 1.16 (svn rev 515) 22nd October 2004
>
>NOTE:
>This release has major changes to Unicode support. See below.
> @@ -47,6 +47,7 @@
> Corrected typo in ora_lob_read() example thanks to
> Johannes Wierny.
> Corrected LOB example thanks to Sascha Pfalz and Thomas Upton.
> Updated README.macosx thanks to Hilmar Lapp.
> + Updated README.hpux thanks to Gram Ludlow and Lincoln Baxter.
> Added $dbh->reauthenticate($user,$pass) docs thanks to
> Andy Hassall.
> Added $dbh->{ora_parse_error_offset} docs thanks to Andy Hassall.
> Added gcc example to README.aix thanks to Adrian Terranova.
>
> Modified: dbd-oracle/trunk/Makefile.PL
> ==
>
> --- dbd-oracle/trunk/Makefile.PL (original)
> +++ dbd-oracle/trunk/Makefile.PL Fri Oct 22 02:09:14 2004
> @@ -4,7 +4,10 @@
> # vim: ts=8:sw=4
>
> BEGIN { $^W = 1 }
> -BEGIN { require 5.004 }
> +
> +# perl5.5 could be supported with some work.
> +# If you need it, then do the work yourself and send me a
> diff. Thanks.
> +BEGIN { require 5.006 }
>
> use ExtUtils::MakeMaker 5.16, qw(&WriteMakefile $Verbose);
> use Getopt::Long;
RE: DEFAULT clause without NOT NULL?
> Do any databases support CREATE TABLE statement with fields > having a DEFAULT clause without a NOT NULL? Oracle and MySQL do, at least. [EMAIL PROTECTED] src]$ sqlplus test/test SQL*Plus: Release 9.2.0.5.0 - Production on Mon Aug 30 00:13:29 2004 Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved. Connected to: Oracle9i Enterprise Edition Release 9.2.0.5.0 - Production With the Partitioning option JServer Release 9.2.0.5.0 - Production SQL> CREATE TABLE foo ( 2 bar INTEGER, 3 baz INTEGER DEFAULT 42 4 ) 5 / Table created. SQL> desc foo; Name Null?Type - BARNUMBER(38) BAZNUMBER(38) SQL> INSERT INTO foo (bar, baz) VALUES (1, NULL); 1 row created. SQL> INSERT INTO foo (bar) VALUES (1); 1 row created. SQL> commit; Commit complete. SQL> select * from foo; BARBAZ -- -- 1 1 42 [EMAIL PROTECTED]:~$ mysql -p Enter password: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 6 to server version: 4.0.18-max Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql> connect test; Connection id:7 Current database: test mysql> CREATE TABLE foo ( -> bar INTEGER, -> baz INTEGER DEFAULT 42 -> ); Query OK, 0 rows affected (0.03 sec) mysql> INSERT INTO foo (bar, baz) VALUES (1, NULL); Query OK, 1 row affected (0.00 sec) mysql> INSERT INTO foo (bar) VALUES (1); Query OK, 1 row affected (0.01 sec) mysql> select * from foo; +--+--+ | bar | baz | +--+--+ | 1 | NULL | |1 | 42 | +--+--+ 2 rows in set (0.00 sec) -- Andy Hassall <[EMAIL PROTECTED]> / Space: disk usage analysis tool <http://www.andyh.co.uk> / <http://www.andyhsoftware.co.uk/space>
RE: ora_can_unicode discussion
> Send ora_nls_parameters() + ora_can_unicode() + docs + tests :) > (Against the latest code in subversion.) Patch attached. Adds: ora_can_unicode ora_nls_parameters (now returns a copy of the cached hashref, in case the user wants to modify it) New test 15nls.t -- Andy Hassall <[EMAIL PROTECTED]> / Space: disk usage analysis tool <http://www.andyh.co.uk> / <http://www.andyhsoftware.co.uk/space> DBD-Oracle-rev247-ora_can_unicode.ora_nls_parameters.patch Description: Binary data
RE: New Oracle "Instant Client"
>> No headers so obviously can't compile against just this - >> have to use a full Oracle home for that. >> Compiled DBD-Oracle svn rev. 185. against Oracle 10.1.0.2 > > Thanks for this info. > Could you please also provide the perl Makefile.PL > command that you used to generate the Makefile? > > I generate it with -F, but I had lots of errors not only related > to ORACLE_HOME. > After the make test did not work. You cannot compile against the Instant Client, you must compile against a full Oracle home. I did not specify any parameters to Makefile.PL, although I had to modify some of the Oracle home detection logic to work cleanly with 10g, which I've posted previously in a patch. The current development version of DBD::Oracle compiles against 10g on Linux without modification. I've just tried DBD-Oracle 1.15 again (the latest released version), and whilst it gets the Oracle home detection wrong, it compiles and tests fine for me. What errors did you get? -- Andy Hassall <[EMAIL PROTECTED]> / Space: disk usage analysis tool <http://www.andyh.co.uk> / <http://www.andyhsoftware.co.uk/space>
RE: ora_can_unicode discussion
>> $dbh->ora_can_store_string($string) perhaps? Bitmask >> return value as per ora_can_unicode? >> >> There are OCI functions that can answer this, e.g. >> OCINlsCharSetConvert() followed by >> OCICharSetConversionIsReplacementUsed(). > > Patches most welcome :) OK. Should I separate out ora_nls_parameters (and dump ora_can_unicode), or keep it until ora_can_store_string is done and send it all in one patch later? -- Andy Hassall <[EMAIL PROTECTED]> / Space: disk usage analysis tool <http://www.andyh.co.uk> / <http://www.andyhsoftware.co.uk/space>
RE: ora_can_unicode discussion
ent character set, and whether the
utf8 flag is set on the Perl string, can I store this value without data
loss, either in the database charset, or the national charset, or both?".
$dbh->ora_can_store_string($string) perhaps? Bitmask return value as per
ora_can_unicode?
There are OCI functions that can answer this, e.g. OCINlsCharSetConvert()
followed by OCICharSetConversionIsReplacementUsed().
The Euro symbol is a good example for this question, since it's either not
present, or in completely different places in the most popular character
sets.
e.g. Binding "\x{20ac}" should be fine so long as your database is in UTF8,
one of the other Unicode sets, or WE8ISO8859P15 or WE8MSWIN1252. But not if
it's WE8ISO8859P1 (Latin-1) - it doesn't have a Euro symbol.
If you try and bind its single-byte equivalent, chr(128) or chr(164), it
depends on your client character set as well as the database character set.
Hope I'm making some sense :-)
--
Andy Hassall <[EMAIL PROTECTED]> / Space: disk usage analysis tool
<http://www.andyh.co.uk> / <http://www.andyhsoftware.co.uk/space>
RE: test_dynamic Error 29 installing DBD-Oracle v 1.15 on red hat9 Oracle 9.2
> I do not think it is a good idea to select from V$ tables: many users
> are not granted permission to see select from those.
OK - most V$ views need additonal privileges, but V$NLS_PARAMETERS has a
public synonym and SELECT is granted to PUBLIC - there are another 22 v$
views (out of 188) in 8i that are 'public' like this.
I can select from the view without any privileges beyond CREATE SESSION on a
fresh install of 8i:
Connected to Oracle8i Enterprise Edition Release 8.1.7.4.1
Connected as sys
SQL> create user noprivs identified by noprivs;
User created
SQL> grant create session to noprivs;
Grant succeeded
SQL> connect noprivs/[EMAIL PROTECTED]
Connected to Oracle8i Enterprise Edition Release 8.1.7.4.1
Connected as noprivs
SQL> select count(*) from v$nls_parameters;
COUNT(*)
--
17
So does this privilege commonly get revoked?
If it's to change to use NLS_DATABASE_PARAMETERS, it needs to take into
account NLS_SESSION_PARAMETERS as well to pick up things like the session's
NLS_DATE_FORMAT. Does it need to consider NLS_INSTANCE_PARAMETERS? I don't
know what the interaction here is - which is probably why v$nls_parameters
is there, to get Oracle to work that out :-)
>$ENV{NLS_LANG} should give you the client NLS environment.
On most platforms yes, and assuming you haven't changed it since the
connect. On Windows there's the registry to worry about (which looks a bit
of a pain in a multiple-home environment).
Also you could conceivably open one $dbh with NLS_LANG as Unicode, change
NLS_LANG and open a second one in single-byte; the first one would still be
in Unicode as it's only at connect time that NLS_LANG makes a difference,
but a method based on the current value of NLS_LANG would then give the
wrong answer for the first $dbh.
--
Andy Hassall <[EMAIL PROTECTED]> / Space: disk usage analysis tool
<http://www.andyh.co.uk> / <http://www.andyhsoftware.co.uk/space>
RE: test_dynamic Error 29 installing DBD-Oracle v 1.15 on red hat 9 Oracle 9.2
> On Fri, Mar 19, 2004 at 05:28:42PM -0000, Andy Hassall wrote:
>>
>>> might be better to add a ora_nls_parameters() method using:
>>>
>>> and then implement ora_can_unicode() in terms of
>>> $dbh->{ora_nls_parameters}
>>>
>>> If that sounds good to you could you rework it that way?
>>
>> OK - will do.
>>
> ora_nls_parameters() could default to caching and take a param to
> force an update of the cache.
Updated patch attached.
These changes cover the server - does there need to be something to cover
the client settings, e.g. examine NLS_LANG at connect time (either
environment variable, or from registry on Windows) to check if the client is
using Unicode?
thanks,
--
Andy Hassall <[EMAIL PROTECTED]> / Space: disk usage analysis tool
<http://www.andyh.co.uk> / <http://www.andyhsoftware.co.uk/space>
DBD-Oracle-rev237-ora_can_unicode.patch
Description: Binary data
RE: test_dynamic Error 29 installing DBD-Oracle v 1.15 on red hat 9 Oracle 9.2
> > Attached is the patch for adding ora_can_unicode.
>
> Thanks. Is the /UTF/ regex safe against false matches?
I believe so - I checked the values in v$nls_valid_values and only the
Unicode-based character sets had 'UTF' in them.
SQL> select value
2 from v$nls_valid_values
3 where parameter = 'CHARACTERSET'
4 andvalue like '%UTF%';
VALUE
AL24UTFFSS
UTF8
UTFE
AL32UTF8
AL16UTF16
Or would you prefer the character sets to be matched exactly against a
list? I can gather the values from 8i, 9i and 10g if required.
> I was about to apply it when I started wondering if it could be one
> with one db query instead of two. Then I started wondering if it
> might be better to add a ora_nls_parameters() method using:
>
> $dbh->{ora_nls_parameters} = $dbh->selectall_hashref(q{
> SELECT parameter, value FROM v$nls_parameters
> });
>
> and then implement ora_can_unicode() in terms of
> $dbh->{ora_nls_parameters}
>
> If that sounds good to you could you rework it that way?
OK - will do.
I don't think they can be safely cached - some of them are alterable at
session level (e.g. nls_date_format), whereas it was a safe bet that
database character sets wouldn't change during the life of a session
(although not impossible).
> See also the install_method() calls in DBD::Oracle::driver().
Ah, I see.
thanks,
--
Andy Hassall <[EMAIL PROTECTED]> / Space: disk usage analysis tool
<http://www.andyh.co.uk> / <http://www.andyhsoftware.co.uk/space>
RE: test_dynamic Error 29 installing DBD-Oracle v 1.15 on red hat 9 Oracle 9.2
>>> It would be handy to have a function that, given a $dbh, >>> returns 1 if the >>> database national char set supports unicode (which would be >>> true for Oracle >=9) >>> and 2 if the database default charset is unicode. >>> >>> Could even live in the driver as an $dbh->ora_can_unicode; method. >> 0 = Neither character set is Unicode. >> 1 = National character set is Unicode. >> 2 = Database character set is Unicode. >> 3 = Both national and database character sets are Unicode. > > And please, > just for now, stick to adding $dbh->ora_can_unicode so as not to tread > on Jeff Urlwin and Lincoln Baxter's toes, as they're working with > me on utf8 support. Attached is the patch for adding ora_can_unicode. I've dug out 8i and checked whether you can have a Unicode main character set, with a non-Unicode national character set - you can: SQL> select * from v$nls_parameters where parameter like '%CHARACTERSET'; PARAMETERVALUE -------- NLS_CHARACTERSET UTF8 NLS_NCHAR_CHARACTERSET WE8ISO8859P15 thanks, -- Andy Hassall <[EMAIL PROTECTED]> / Space: disk usage analysis tool <http://www.andyh.co.uk> / <http://www.andyhsoftware.co.uk/space> DBD-Oracle-rev237-ora_can_unicode.patch Description: Binary data
RE: test_dynamic Error 29 installing DBD-Oracle v 1.15 on red hat 9 Oracle 9.2
> > What do you think? > > I think the constants would be overkill, especially given the > relatively short life overwhich this will be useful. Fair point. > Please use subversion as the development source has moved on > a fair bit, Yep, I've got it checked out of the subversion repository. > especially in the area of character sets and unicode. And please, > just for now, stick to adding $dbh->ora_can_unicode so as not to tread > on Jeff Urlwin and Lincoln Baxter's toes, as they're working with > me on utf8 support. Will do. thanks, -- Andy Hassall <[EMAIL PROTECTED]> / Space: disk usage analysis tool <http://www.andyh.co.uk> / <http://www.andyhsoftware.co.uk/space>
Patch: DBD::Oracle: RULE hint in data dictionary queries vs. Oracle 10g
Queries in DBD::Oracle use the RULE hint, as the solution to the problem arising from this thread: http://groups.google.co.uk/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&th=e4a175ce235 b5e0d&rnum=1 Gathering statistics on the SYS schema in Oracle 9.2 was supported, but produced very bad execution plans that caused t/meta to hang. Oracle said they were going to remove the Rule Based Optimiser in 10g, which would have made /*+RULE*/ an invalid hint and hence ignored silently. However, they've gone down the path of keeping the RBO, but making it 'desupported'. So this means that the data dictionary queries issued by DBD::Oracle are now using a desupported feature, so if it ever caused a problem in any way, Oracle Support's first reply would be 'remove the rule hints, not a supported feature'. Attached patch uses ora_server_version to determine whether to insert the hint or not; data dictionary queries will be issued unhinted in 10g, and since Oracle 10g automatically gathers stats on everything in sight, it will use CBO. I've tested it on a 10g Linux database, and it doesn't exhibit the hangs that it did in 9i without the hint - verified that Oracle itself had indeed gathered stats on SYS, so they must have fixed the optimiser's behaviour on the SYS schema. Also tested on 9.2, queries were issued hinted with RULE as before. Whilst I'm on 10g issues, the behaviour of 'DROP TABLE' has changed in 10g - it doesn't actually drop the table unless you use 'DROP TABLE xxx PURGE' now, it puts it in a 'recycle bin'. Should the DBD::Oracle tests add 'purge' to the drop tables if it's running against 10g? Or should it not bother - it's the DBA's job/decision to purge the recycle bin regularly? thanks, -- Andy Hassall <[EMAIL PROTECTED]> / Space: disk usage analysis tool <http://www.andyh.co.uk> / <http://www.andyhsoftware.co.uk/space> DBD-Oracle-conditional-rule-hint-rev227.patch Description: Binary data
RE: New Oracle "Instant Client"
> On Fri, Mar 05, 2004 at 01:44:02AM -0000, Andy Hassall wrote: >>> http://otn.oracle.com/tech/oci/instantclient/instantclient.html >>> >>> "Download and be ready in seconds. Deploy your applications right >>> out of the box. Deliver the promise. Free. >>> >>> Naturally I'd like DBD::Oracle to support "Instant Clients". >> >> Short answer: It works on Linux, at least as far as passing > make test. > >> So it whinges a bit about ORACLE_HOME not being set, but works. > > I've checked in a change that should stop those. Could you > check it for me? Yes, that's sorted it - rev 189 now passes tests without ORACLE_HOME warnings using Instant Client. -- Andy Hassall <[EMAIL PROTECTED]> / Space: disk usage analysis tool <http://www.andyh.co.uk> / <http://www.andyhsoftware.co.uk/space>
RE: New Oracle "Instant Client"
> http://otn.oracle.com/tech/oci/instantclient/instantclient.html > > "Download and be ready in seconds. Deploy your applications right > out of the box. Deliver the promise. Free. > > Naturally I'd like DBD::Oracle to support "Instant Clients". Short answer: It works on Linux, at least as far as passing make test. Long answer: Looks like the Oracle developers aren't talking to the documentation guys (as usual) - the installation instructions say to 'Unzip the packages into a single directory such as "instantclient".'. Except it's an RPM file. So, installed the RPM, it puts libraries in /usr/lib/oracle/client/10.1.2. The basic package comes with this lot: [EMAIL PROTECTED] andyh]# rpm --query --list -p oracle-instantclient-basic-10.1.0.2-1.i386.rpm /usr/lib/oracle/10.1.0.2/client/lib/classes12.jar /usr/lib/oracle/10.1.0.2/client/lib/libclntsh.so.10.1 /usr/lib/oracle/10.1.0.2/client/lib/libnnz10.so /usr/lib/oracle/10.1.0.2/client/lib/libocci.so.10.1 /usr/lib/oracle/10.1.0.2/client/lib/libociei.so /usr/lib/oracle/10.1.0.2/client/lib/libocijdbc10.so /usr/lib/oracle/10.1.0.2/client/lib/ojdbc14.jar No headers so obviously can't compile against just this - have to use a full Oracle home for that. Compiled DBD-Oracle svn rev. 185. against Oracle 10.1.0.2 Relevant bits of environment: [EMAIL PROTECTED] DBD-Oracle]# echo $ORACLE_HOME [EMAIL PROTECTED] DBD-Oracle]# echo $PATH /usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin: /root/bin [EMAIL PROTECTED] DBD-Oracle]# echo $LD_LIBRARY_PATH /usr/lib/oracle/10.1.0.2/client/lib [EMAIL PROTECTED] DBD-Oracle]# echo $NLS_LANG ENGLISH_UNITED KINGDOM.WE8ISO8859P15 [EMAIL PROTECTED] DBD-Oracle]# echo $ORACLE_USERID test/test@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=testbox.localhost)(PORT= 1521))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=dev101))) So no reference left to the Oracle home - started a fresh session for this to make sure. Specified the connect string using the full syntax since it won't know where tnsnames.ora is. LD_LIBRARY_PATH pointing to the Instant Client libraries. [EMAIL PROTECTED] DBD-Oracle]# make test PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t t/01base...ok t/10generalORACLE_HOME environment variable not set! t/10generalok t/20select.ORACLE_HOME environment variable not set! t/20select.ok t/21nchar..NLS_LANG=ENGLISH_UNITED KINGDOM.WE8ISO8859P15 ORACLE_HOME environment variable not set! NLS_CHARACTERSET=WE8ISO8859P15 NLS_NCHAR_CHARACTERSET=UTF8 t/21nchar..ok t/25plsql..ORACLE_HOME environment variable not set! t/25plsql..ok t/30long...ORACLE_HOME environment variable not set! t/30long...ok t/40ph_typeORACLE_HOME environment variable not set! t/40ph_typeok 11/19 Placeholder behaviour for ora_type=1 (the default) varies with Oracle version. Oracle 7 didn't strip trailing spaces, Oracle 8 did, until 9.2.x Your system doesn't. If that seems odd, let us know. t/40ph_typeok t/50cursor.ORACLE_HOME environment variable not set! t/50cursor.ok t/60reauth.skipped all skipped: no reason given t/70meta...ORACLE_HOME environment variable not set! t/70meta...ok All tests successful, 1 test skipped. Files=10, Tests=1554, 43 wallclock secs ( 7.29 cusr + 0.95 csys = 8.24 CPU) So it whinges a bit about ORACLE_HOME not being set, but works. -- Andy Hassall <[EMAIL PROTECTED]> / Space: disk usage analysis tool <http://www.andyh.co.uk> / <http://www.andyhsoftware.co.uk/space>
RE: DBD::Oracle 1.15 + Oracle 10g + Linux = success (with a small tweak)
>> SQL*Plus can report the version of the Oracle home in a >> readily parseable way: >> >> $ echo DEFINE _SQLPLUS_RELEASE | sqlplus -S /nolog >> DEFINE _SQLPLUS_RELEASE = "1001000200" (CHAR) >> >> Any objections to me writing a patch to run sqlplus as >>above to get this value? > > That would be great. Thanks. Patch attached; have tried it on Linux + Oracle 10g, 9.2, and Solaris + Oracle 7.3.4, 8.0.6, 9.0.1, 9.2. 7.3 doesn't report the version through _SQLPLUS_RELEASE, however it fell back to one of the other methods correctly. -- Andy Hassall <[EMAIL PROTECTED]> / Space: disk usage analysis tool <http://www.andyh.co.uk> / <http://www.andyhsoftware.co.uk/space> DBD-Oracle-1.15-Makefile.PL-Oracle10.v2.patch Description: Binary data
RE: ANNOUNCE: DBD::Oracle 1.15
> Added $dbh->{ora_parse_error_offset} attribute
Attached: some POD for the attribute above (I should have included this with
the patch for the attribute), and also for the reauthenticate private func
since it's undocumented.
ta,
--
Andy Hassall <[EMAIL PROTECTED]> / Space: disk usage analysis tool
<http://www.andyh.co.uk> / <http://www.andyhsoftware.co.uk/space>
DBD-Oracle-1.15-pod.patch
Description: Binary data
Fw: Announce: Release Candidate of DBD::Oracle 1.15 available
Andy Hassall wrote: > --- Tim Bunce <[EMAIL PROTECTED]> wrote: > On Mon, Jan 12, 2004 at > 05:48:48PM -0500, Jeff Urlwin wrote: >>> >> Um, Andy, you didn't mention that one in your "Solaris 2.7 / 9.2.0.4 >> / 32-bit" >> results. Did you see that? > > Hm, I'm trying to compile it again and I'm now hitting the 32/64 bit > problem again. You'd better ignore my results until I work out what > I've done - sorry. > > It _does_ link if I use '-l' when running Makefile.PL though - but > I'm sure I didn't do that the first time. What's puzzling me is that > the 1.15 I built yesterday and installed into a test directory is > correctly linked against $ORACLE_HOME/lib32. For what it's worth, I found out what was going on - was a non-deterministic problem resulting from clocks being out of sync between the server I was compiling on, and the fileserver the files were on. From a freshly unpacked directory, got the following from Makefile.PL: " Attempting to discover Oracle OCI build rules cc-c -o DBD_ORA_OBJ.o DBD_ORA_OBJ.c by executing: (make -f /opt/oracle/9.2.0.C/rdbms/demo/demo_rdbms.mk build ECHODO=echo ECHO=echo GENCLNTSH='echo genclntsh' CC=echo OPTIMIZE= CCFLAGS= EXE _ORA_OBJ.o) Oracle oci build prolog: + make: *** Warning: File `DBD_ORA_OBJ.o' has modification time in the future (2004-01-14 13:15:13.817217 > 2004-01-14 13:15:13.155464156) Oracle oci build command: + -L/opt/SUNWcluster/lib -R/opt/SUNWcluster/lib -o build -L/opt/oracle/9.2.0.C/rdbms/lib/ -L/opt/oracle/9.2.0.C/lib/ -o DBD_ORA_EXE DBD_ORA_OBJ.o host9 -lnus9 -lnldap9 -lldapclnt9 -lnsslb9 -lnoname9 -lntcp9 -lntcps9 -lnsslb9 -lntcp9 -lntns9 -lnsl -lsocket -lgen -ldl -R/opt/oracle/9.2.0.C/lib -laio -lthread + make: warning: Clock skew detected. Your build may be incomplete. Unable to interpret Oracle build commands from /opt/oracle/9.2.0.C/rdbms/demo/demo_rdbms.mk. Using fallback approach. " The clock skew gets picked up as an error, and it then goes to another method, which correctly picks up the lib32 directory instead of lib, and it builds and links correctly. But because the clock problem is intermittent, the next time I tried it the first method 'succeeded', but picked 'lib' and not 'lib32' and so the link failed. -- Andy Hassall <[EMAIL PROTECTED]> / Space: disk usage analysis tool <http://www.andyh.co.uk> / <http://www.andyhsoftware.co.uk/space>
Re: Announce: Release Candidate of DBD::Oracle 1.15 available
for DBD::Oracle () chmod 644 Oracle.bs rm -f blib/arch/auto/DBD/Oracle/Oracle.dll LD_RUN_PATH="d:/Oracle/Ora92/lib:d:/Oracle/Ora92/rdbms/lib" ld2 -s -L/usr/local /lib Oracle.o dbdimp.o oci7.o oci8.o -o blib/arch/auto/DBD/Oracle/Oracle.dll / usr/lib/perl5/5.8.2/cygwin-thread-multi-64int/CORE/libperl.dll.a -L/cygdrive /d/T emp/DBD-Oracle-1.15 -loci gcc -shared -o Oracle.dll -Wl,--out-implib=libOracle.dll.a -Wl,--export-all-sym bols -Wl,--enable-auto-import -Wl,--stack,8388608 \ -s -L/usr/local/lib Oracle.o dbdimp.o oci7.o oci8.o /usr/lib/perl5/5.8.2/cygwin -thread-multi-64int/CORE/libperl.dl l.a -L/cygdrive/d/Temp/DBD-Oracle-1.15 -loci Creating library file: libOracle.dll.a Oracle.o(.text+0x7961):Oracle.c: undefined reference to `_OCILobWriteAppend' collect2: ld returned 1 exit status perlld: *** system() failed to execute gcc -shared -o Oracle.dll -Wl,--out-implib=libOracle.dll.a -Wl,--export-all-sym bols -Wl,--enable-auto-import -Wl,--stack,8388608 \ -s -L/usr/local/lib Oracle.o dbdimp.o oci7.o oci8.o /usr/lib/perl5/5.8.2/cygwin -thread-multi-64int/CORE/libperl.dl l.a -L/cygdrive/d/Temp/DBD-Oracle-1.15 -loci make: *** [blib/arch/auto/DBD/Oracle/Oracle.dll] Error 1 -- Andy Hassall <[EMAIL PROTECTED]> / Space: disk usage analysis tool <http://www.andyh.co.uk> / <http://www.andyhsoftware.co.uk/space>
Re: Announce: Release Candidate of DBD::Oracle 1.15 available
--- Tim Bunce <[EMAIL PROTECTED]> wrote: > On Mon, Jan 12, 2004 at 05:48:48PM -0500, Jeff Urlwin wrote: > > > > > > > > Almost 4 months after the previous release candidate, and 10 > > > months after the last full release, here's another release candidate: > > > > > > > > > http://homepage.eircom.net/~timbunce/DBD-Oracle-1.15-rc2-20040 > > > 112.tar.gz > > > > Works ok on Oracle 9.2.0.4.0 on Solaris (32 bit) except the varchar > trimming > > issue, which has been discussed here before. > > > > t/ph_typeok 11/19 expected 'trailing' but got 'trailing ' for > VARCHAR2 > > t/ph_typeFAILED test 12 > > Failed 1/19 tests, 94.74% okay > > Um, Andy, you didn't mention that one in your "Solaris 2.7 / 9.2.0.4 / > 32-bit" > results. Did you see that? Hm, I'm trying to compile it again and I'm now hitting the 32/64 bit problem again. You'd better ignore my results until I work out what I've done - sorry. It _does_ link if I use '-l' when running Makefile.PL though - but I'm sure I didn't do that the first time. What's puzzling me is that the 1.15 I built yesterday and installed into a test directory is correctly linked against $ORACLE_HOME/lib32. Also; whilst the server I was testing against was 9.2.0.4, the client it was compiled against turns out to be 9.2.0.1 which is probably why ph_type passes. = -- Andy Hassall ([EMAIL PROTECTED]) icq(5747695) http://www.andyh.co.uk http://www.andyhsoftware.co.uk/space | disk usage analysis tool Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html
Re: Announce: Release Candidate of DBD::Oracle 1.15 available
Tim Bunce wrote: > > http://homepage.eircom.net/~timbunce/DBD-Oracle-1.15-rc2-20040112.tar.gz > > =head1 Changes in DBD-Oracle 1.15 12th January 2004 > > I'd be grateful for reports of any testing you can do on this. > > I would especially like to fix any build-time problems. I'm aware > there > are still problems on Solaris with Oracle 9.2 related to 32/64 bit > lib directories. I don't have Oracle 9.2 so I can't test it myself. > Patches, or just detailed problem reports, for that or any other > build problems are most welcome. Didn't get much time to test it on actual scripts today, but 1.15-rc2 built and tested OK on Solaris 2.7 / 9.2.0.4 / 32-bit - the build problems from 1.14 appear to be fixed. -- Andy Hassall <[EMAIL PROTECTED]> / Space: disk usage analysis tool <http://www.andyh.co.uk> / <http://www.andyhsoftware.co.uk/space>
Re: DBD::Oracle - update of type_info_all from ODBC?
Tim Bunce wrote: > > Darn it! Where are the various TIMESTAMP and INTERVAL types I was > expecting to find? Is the ODBC driver manager recent (v3 ODBC specs?) The Oracle ODBC driver docs appear to say they don't support INTERVAL. (Says this in the helpfile installed when you install the ODBC driver, in Oracle ODBC Driver Help / For All Users / Oracle ODBC Driver / Features Not Supported) Can't find a mention of TIMESTAMP though. Then again there's not much 9i information in them - they look very much like the 8i docs, except for one mention of supporting failover in 9.2.0.4. -- Andy Hassall <[EMAIL PROTECTED]> / Space: disk usage analysis tool <http://www.andyh.co.uk> / <http://www.andyhsoftware.co.uk/space>
DBI 1.40 META.yaml identifies as 1.39
META.yaml in DBI 1.40 hasn't been updated, which causes PPM::Make to think it's building 1.39. This shows up when you install the PPD or search for DBI - it won't see 1.40. Patch attached. -- Andy Hassall <[EMAIL PROTECTED]> / Space: disk usage analysis tool <http://www.andyh.co.uk> / <http://www.andyhsoftware.co.uk/space> META.yaml.patch Description: Binary data
Re: DBD::Oracle - update of type_info_all from ODBC?
Tim Bunce wrote:
> On Fri, Jan 09, 2004 at 10:49:35PM -0000, Andy Hassall wrote:
>> Tim Bunce wrote:
>>> I'd be very grateful if someone could send me the output of:
>>>
>>> perl -MDBI::DBD::Metadata -e write_typeinfo_pm dbi:ODBC:dsnname
>>> user pass Oracle
>>>
>>> Where dsnname is an ODBC DSN that uses a recent (9.2 or at least
>>> 9.1) Oracle ODBC driver to talk to a similarly recent Oracle
>>> database
>>> server.
>>
>> I might be missing something here, but DBI::DBD::Metadata from DBI
>> 1.40 doesn't appear to have a write_typeinfo_pm sub. It's got
>> write_typeinfo though (line 308).
>>
>> $ perl -MDBI::DBD::Metadata -e write_typeinfo_pm dbi:ODBC:web test
>> test Oracle
>>
>> Undefined subroutine &DBI::DBD::Metadata::write_typeinfo_pm called
>> at -e line 1.
>>
>> write_typeinfo works, but the parameters are in a different order,
>> which had me confused for a bit!
>
> Uh. Bugs in the DBI::DBD docs. Patches welcome :)
Is it really a doc bug? Metadata has write_typeinfo_pm in @EXPORT but never
defines it, and write_typeinfo is inconsistent with write_getinfo_pm.
The following sorts that out:
--- Metadata.pm.orig2004-01-10 00:04:46.598710400 +
+++ Metadata.pm 2004-01-10 00:12:03.486924800 +
@@ -245,7 +245,7 @@
}
Please replace Driver (or "") with the name of your driver.
-Note that this stub function is generated for you by the write_typeinfo
+Note that this stub function is generated for you by the write_typeinfo_pm
function, but you must manually transfer the code to Driver.pm.
=cut
@@ -305,9 +305,9 @@
return $val;
}
-sub write_typeinfo
+sub write_typeinfo_pm
{
-my ($driver, $dsn, $user, $pass) = @_ ? @_ : @ARGV;
+my ($dsn, $user, $pass, $driver) = @_ ? @_ : @ARGV;
my $dbh = DBI->connect($dsn, $user, $pass, {AutoCommit=>1,
RaiseError=>1});
$driver = "" unless defined $driver;
@@ -316,7 +316,7 @@
# Transfer this to ${driver}.pm
# The type_info_all function was automatically generated by
-# DBI::DBD::Metadata::write_typeinfo v$DBI::DBD::Metadata::VERSION.
+# DBI::DBD::Metadata::write_typeinfo_pm v$DBI::DBD::Metadata::VERSION.
package DBD::${driver}::db; # This line can be removed once
transferred.
@@ -331,7 +331,7 @@
# Don't forget to add version and intellectual property control
information.
# The \%type_info_all hash was automatically generated by
-# DBI::DBD::Metadata::write_typeinfo v$DBI::DBD::Metadata::VERSION.
+# DBI::DBD::Metadata::write_typeinfo_pm v$DBI::DBD::Metadata::VERSION.
package DBD::${driver}::TypeInfo;
>> Output attached, command used was:
>>
>> $ perl -MDBI::DBD::Metadata -e "DBI::DBD::Metadata::write_typeinfo
>> 'Oracle','dbi:ODBC:web','test','test'" > TypeInfo.pm
>>
>> $ perl -MDBI -e 'DBI->installed_versions'
>> Perl: 5.008001(MSWin32-x86-multi-thread)
>> OS : MSWin32 (4.0)
>> DBI : 1.40
>> DBD::Oracle : 1.14
>> DBD::ODBC : 1.06
>
>> Forgot to mention - Oracle client & server both 9.2.0.4.
>
> Darn it! Where are the various TIMESTAMP and INTERVAL types I was
> expecting to find? Is the ODBC driver manager recent (v3 ODBC specs?)
Hm, where should I be looking for this? My knowledge of ODBC is fairly
limited. I've updated MDAC to 2.8, the latest version on microsoft.com; I
believe that updates the driver manager? (from what it says on google
searches).
--
Andy Hassall <[EMAIL PROTECTED]> / Space: disk usage analysis tool
<http://www.andyh.co.uk> / <http://www.andyhsoftware.co.uk/space>
Re: DBD::Oracle - update of type_info_all from ODBC?
Andy Hassall wrote: > Tim Bunce wrote: > > Output attached, command used was: > > $ perl -MDBI::DBD::Metadata -e "DBI::DBD::Metadata::write_typeinfo > 'Oracle','dbi:ODBC:web','test','test'" > TypeInfo.pm > > $ perl -MDBI -e 'DBI->installed_versions' > Perl: 5.008001(MSWin32-x86-multi-thread) > OS : MSWin32 (4.0) > DBI : 1.40 > DBD::Sponge : 11.10 > DBD::Proxy : install_driver(Proxy) failed: Can't locate > RPC/PlClient.pm in @INC > DBD::Oracle : 1.14 > DBD::ODBC : 1.06 > DBD::ExampleP : 11.12 Forgot to mention - Oracle client & server both 9.2.0.4. -- Andy Hassall <[EMAIL PROTECTED]> / Space: disk usage analysis tool <http://www.andyh.co.uk> / <http://www.andyhsoftware.co.uk/space>
Re: DBD::Oracle - update of type_info_all from ODBC?
Tim Bunce wrote: > I'd be very grateful if someone could send me the output of: > > perl -MDBI::DBD::Metadata -e write_typeinfo_pm dbi:ODBC:dsnname > user pass Oracle > > Where dsnname is an ODBC DSN that uses a recent (9.2 or at least 9.1) > Oracle ODBC driver to talk to a similarly recent Oracle database > server. I might be missing something here, but DBI::DBD::Metadata from DBI 1.40 doesn't appear to have a write_typeinfo_pm sub. It's got write_typeinfo though (line 308). $ perl -MDBI::DBD::Metadata -e write_typeinfo_pm dbi:ODBC:web test test Oracle Undefined subroutine &DBI::DBD::Metadata::write_typeinfo_pm called at -e line 1. write_typeinfo works, but the parameters are in a different order, which had me confused for a bit! Output attached, command used was: $ perl -MDBI::DBD::Metadata -e "DBI::DBD::Metadata::write_typeinfo 'Oracle','dbi:ODBC:web','test','test'" > TypeInfo.pm $ perl -MDBI -e 'DBI->installed_versions' Perl: 5.008001(MSWin32-x86-multi-thread) OS : MSWin32 (4.0) DBI : 1.40 DBD::Sponge : 11.10 DBD::Proxy : install_driver(Proxy) failed: Can't locate RPC/PlClient.pm in @INC DBD::Oracle : 1.14 DBD::ODBC : 1.06 DBD::ExampleP : 11.12 -- Andy Hassall <[EMAIL PROTECTED]> / Space: disk usage analysis tool <http://www.andyh.co.uk> / <http://www.andyhsoftware.co.uk/space> TypeInfo.pm Description: Binary data
Re: Tunneling a DBI connection through a telnet session
Jeff Welty wrote: > I've searched around, and can't find any references to this, so I > believe I'm breaking new ground here. > > What I'd like to do, (because of the politics of my situation and the > near lack of good technical support in my organization which imposed > ridiculous constraints on application development), is this: > > On a client box (PC), using only Perl-TK and Net::telnet, open a > telnet connection to a server (running ORACLE), and issue the > commands and responses via the telnet session to another Perl script > which would run on the server. I'm envisioning the data being > encoded as CSV to be piped over the telnet session. The client is > restricted for readonly access, and the data is alphanumeric, no > blobs. > > Has anyone ever done, tried, or contemplated such a thing? > > No, I can't have my own process listening on a server port. Telnet or > talking directly to the ORACLE server are my only options. I know I > can go the ODBC driver route on the client PC, but that is ugly for > other reasons. Just to totally rule out the easy way before getting complicated - is logging in via SSH rather than telnet also not an option? Tunnelling is pretty straightforward through SSH. -- Andy Hassall ([EMAIL PROTECTED]) icq(5747695) (http://www.andyh.co.uk) Space: disk usage analysis tool (http://www.andyhsoftware.co.uk/space)
Re: DBD::Oracle beta available for testing
Tim Bunce wrote:
> On Wed, Sep 24, 2003 at 10:27:02PM +0100, Andy Hassall wrote:
>>
>> Adding D:/oracle/ora92/precomp/lib/MSVC/oraSQL9.LIB to that link.exe
>> command makes it link OK - and tests pass (except the usual trailing
>> space one):
>
> Great. Thanks. Any chance you could send me a patch to Makefile.PL?
Attached patch does a version and compiler search similar to the one done
for the OCI libraries.
(Although the way this, and the OCI search, does the sort may have to be
revised when 10G is released, if they keep the same library naming
convention; oci10.lib will sort after oci9.lib - but then again, do Oracle
homes ever have both libraries present? I assume at some point they did
which is why the code's there in the first place?)
Probably needs to take into account the option Steffen added as well?
(patch is against Makefile.PL after Steffen's patch applied, but there's no
overlaps so it applies to the original beta version too)
With patch, compiles+links OK on Windows 2000, Microsoft VC++ 6.0SP5, with
following client versions:
9.2.0.4
8.1.7.0
8.1.7.4
8i was installed as Client, using the Custom option, cutting it down to
basically just Net8 support and Pro*C.
Tests were done against a 9.2.0.4 database; I've only got the client bit of
8.1 installed, haven't got a database handy.
With client version 8.1.7.[0,4], but not 9.2.0.4, the long test fails as
Steffen described:
Failed 1/9 test scripts, 88.89% okay. 12/1530 subtests failed, 99.22% okay.
Failed Test Stat Wstat Total Fail Failed List of Failed
---
t\long.t 372 12 3.23% 60 68 76 86 88 90 153 161 169 179
181 183
--
Andy Hassall ([EMAIL PROTECTED]) icq(5747695) (http://www.andyh.co.uk)
Space: disk usage analysis tool (http://www.andyhsoftware.co.uk/space)
DBD-Oracle-1.15-Makefile.PL.diff
Description: Binary data
Re: DBD::Oracle beta available for testing
Tim Bunce wrote: > On Wed, Sep 24, 2003 at 10:27:02PM +0100, Andy Hassall wrote: >> >> Adding D:/oracle/ora92/precomp/lib/MSVC/oraSQL9.LIB to that link.exe >> command makes it link OK - and tests pass (except the usual trailing >> space one): > > Great. Thanks. Any chance you could send me a patch to Makefile.PL? I'll try and put one together tommorrow - haven't got Oracle 8i on this Windows machine at the moment - and I did the link manually by editing the link command rather than the makefile. Presumably it's going to need a similar version sort to the $OCILIB variable as it'll be oraSQL8.lib on 8i? FYI 1.15 on Linux / 9.2.0.4 compiles and links, all tests but ph_type pass. -- Andy Hassall ([EMAIL PROTECTED]) icq(5747695) (http://www.andyh.co.uk) Space: disk usage analysis tool (http://www.andyhsoftware.co.uk/space)
Re: DBD::Oracle beta available for testing
Tim Bunce wrote: > On Wed, Sep 24, 2003 at 08:08:51PM +0100, Andy Hassall wrote: >> Tim Bunce wrote: >>> On Wed, Sep 24, 2003 at 11:24:17AM +0200, Steffen Goeldner wrote: >>>> dmake >>>> ... >>>> Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland >>>> Error: Unresolved external '_SQLEnvGet' referenced from >>>> C:\TEMP\DBD-ORACLE-1.15\DBDIMP.OBJ Error: Unresolved external >>>> '_SQLSvcCtxGet' referenced from C:\TEMP\DBD-ORACLE-1.15\DBDIMP.OBJ >>> >>> If you (or someone else) are familar enough with windows, could you >>> check if those symbols are in some other oracle library that we're >>> not linking with? >> >> Those symbols are part of SQLLIB: >> >> http://download-west.oracle.com/docs/cd/B10501_01/appdev.920/a97269/pc_01int.htm#1174 >> >> $ORACLE_HOME/precomp/lib/oraSQL9.LIB has those symbols (and the other >> version in the msvc subdirectory): > > Okay. You're using Oracle 9.x but Steffen was using Oracle 8.1.7. > > I know the code that uses those symbols isn't properly #ifdef'd > out on older versions of Oracle so I need to fix that. > > But I also need to know if DBD::Oracle builds okay on Windows > for Oracle 9.x users. Does it? If not then I presume the problem > is that we need to link to oraSQL9.LIB. Does that fix it? > > If DBD::Oracle does work ok on windows with Oracle 9.c then I'm > just left with the problem of working out a) the oldest Oracle > version that supports SQLEnvGet etc, and b) how to tell that > version from the header files (sadly Oracle doesn't provide a > simple way to do that). It also fails building against 9.2.0.4: [EMAIL PROTECTED] /cygdrive/d/Temp/DBD-Oracle-1.15 $ nmake Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. cp Oracle.h blib\arch\auto\DBD\Oracle/Oracle.h cp Oracle.pm blib\lib\DBD\Oracle.pm cp oraperl.ph blib\lib/oraperl.ph cp dbdimp.h blib\arch\auto\DBD\Oracle/dbdimp.h cp ocitrace.h blib\arch\auto\DBD\Oracle/ocitrace.h cp Oraperl.pm blib\lib/Oraperl.pm cp lib/DBD/Oracle/GetInfo.pm blib\lib\DBD/Oracle/GetInfo.pm cp mk.pm blib\arch\auto\DBD\Oracle/mk.pm rem rem D:\Perl\bin\perl.exe -p -e "s/~DRIVER~/Oracle/g" d:/Perl/site/lib/auto/DBI/Driver.xst > Oracle.xsi D:\Perl\bin\perl.exe D:\Perl\lib\ExtUtils/xsubpp -typemap D:\Perl\lib\ExtUtils\typemap -typemap typemap Oracle.xs > Oracle.xsc && D:\Perl\bin\perl.exe -MExtUtils::Command -e mv Oracle.xsc Oracle.c cl -c -ID:/oracle/ora92/oci/include -ID:/oracle/ora92/rdbms/demo -ID:/oracl e/ora92/precomp/public -Id:/Perl/site/lib/auto/DBI -nologo -Gf -W3 -MD -Zi -DNDEBUG -O1 -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DPERL_IMPLICI T_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX -MD -Zi -DN DEBUG -O1-DVERSION=\"1.15\" -DXS_VERSION=\"1.15\" "-ID:\Perl\lib\CORE" -DUTF8_SUPPORT Oracle.c Oracle.c Oracle.xs(99) : warning C4013: 'ora_st_cancel' undefined; assuming extern returning int Oracle.xs(273) : warning C4013: 'dbd_init_oci_drh' undefined; assuming extern returning int cl -c -ID:/oracle/ora92/oci/include -ID:/oracle/ora92/rdbms/demo -ID:/oracl e/ora92/precomp/public -Id:/Perl/site/lib/auto/DBI -nologo -Gf -W3 -MD -Zi -DNDEBUG -O1 -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DPERL_IMPLICI T_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX -MD -Zi -DN DEBUG -O1-DVERSION=\"1.15\" -DXS_VERSION=\"1.15\" "-ID:\Perl\lib\CORE" -DUTF8_SUPPORT dbdimp.c dbdimp.c dbdimp.c(328) : warning C4013: 'SQLEnvGet' undefined; assuming extern returning int dbdimp.c(386) : warning C4013: 'SQLSvcCtxGet' undefined; assuming extern returning int dbdimp.c(1100) : warning C4018: '>' : signed/unsigned mismatch dbdimp.c(1641) : warning C4018: '!=' : signed/unsigned mismatch cl -c -ID:/oracle/ora92/oci/include -ID:/oracle/ora92/rdbms/demo -ID:/oracl e/ora92/precomp/public -Id:/Perl/site/lib/auto/DBI -nologo -Gf -W3 -MD -Zi -DNDEBUG -O1 -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DPERL_IMPLICI T_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX -MD -Zi -DN DEBUG -O1-DVERSION=\"1.15\" -DXS_VERSION=\"1.15\" "-ID:\Perl\lib\CORE" -DUTF8_SUPPORT oci7.c oci7.c cl -c -ID:/oracle/ora92/oci/include -ID:/oracle/ora92/rdbms/demo -ID:/oracl e/ora92/precomp/public -Id:/Perl/site/lib/auto/DBI -nologo -Gf -W3 -MD -Zi -DNDEBUG -O1 -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DPERL_IMPLICI T_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX -MD -Zi -DN DEBUG -O1-DVERSI
Re: DBD::Oracle beta available for testing
Tim Bunce wrote: > On Wed, Sep 24, 2003 at 11:24:17AM +0200, Steffen Goeldner wrote: >> dmake >> ... >> Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland >> Error: Unresolved external '_SQLEnvGet' referenced from >> C:\TEMP\DBD-ORACLE-1.15\DBDIMP.OBJ Error: Unresolved external >> '_SQLSvcCtxGet' referenced from C:\TEMP\DBD-ORACLE-1.15\DBDIMP.OBJ > > If you (or someone else) are familar enough with windows, could you > check if those symbols are in some other oracle library that we're > not linking with? Those symbols are part of SQLLIB: http://download-west.oracle.com/docs/cd/B10501_01/appdev.920/a97269/pc_01int.htm#1174 $ORACLE_HOME/precomp/lib/oraSQL9.LIB has those symbols (and the other version in the msvc subdirectory): [EMAIL PROTECTED] /cygdrive/d/Oracle/ora92/precomp/lib $ nm oraSQL9.LIB | grep SQLSvcCtxGet T _SQLSvcCtxGet I __imp__SQLSvcCtxGet [EMAIL PROTECTED] /cygdrive/d/Oracle/ora92/precomp/lib $ nm oraSQL9.LIB | grep SQLEnvGet T _SQLEnvGet I __imp__SQLEnvGet [EMAIL PROTECTED] /cygdrive/d/Oracle/ora92/precomp/lib/msvc $ nm oraSQL9.LIB | grep SQLEnvGet T _SQLEnvGet I __imp__SQLEnvGet [EMAIL PROTECTED] /cygdrive/d/Oracle/ora92/precomp/lib/msvc $ nm oraSQL9.LIB | grep SQLSvcCtxGet T _SQLSvcCtxGet I __imp__SQLSvcCtxGet -- Andy Hassall ([EMAIL PROTECTED]) icq(5747695) (http://www.andyh.co.uk) Space: disk usage analysis tool (http://www.andyhsoftware.co.uk/space)
Re: Announce: DBI 1.38 release candidate
--- Tim Bunce <[EMAIL PROTECTED]> wrote: > I'd be grateful if you could take a moment to try out this > release candidate of DBI 1.38: > If all is well please reply to the list with a short message giving > the output of: > > perl -MDBI -e 'DBI->installed_versions' C:\Temp\DBI-1.38>perl -MDBI -e "DBI->installed_versions" Perl: 5.008 OS : MSWin32 DBI : 1.38 DBD::Sponge : 11.09 DBD::Oracle : 1.14 DBD::ODBC : 1.06 DBD::ExampleP : 11.10 (All tests successful, 7 tests skipped.) > perl -MDBI -e 'DBI->installed_versions' Perl: 5.008 OS : solaris DBI : 1.38 DBD::Sponge : 11.09 DBD::SQLite : 0.25 DBD::Oracle : 1.14 DBD::File : 0.2001 DBD::ExampleP : 11.10 DBD::CSV : 0.2002 (All tests successful, 9 tests skipped.) = -- Andy Hassall ([EMAIL PROTECTED]) icq(5747695) http://www.andyh.co.uk http://www.andyhsoftware.co.uk/space | disk usage analysis tool Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://uk.messenger.yahoo.com/
