Re: DBD::Oracle beta available for testing

2003-09-25 Thread Tim Bunce
Thanks!

Tim.

On Thu, Sep 25, 2003 at 10:11:20AM +0200, Steffen Goeldner 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?
  
  (Otherwise you could just remove the if(use_proc_connection){...} blocks
  so you can continue testing the rest of the code.)
 
 O.k., to continue I added an option for Makefile.PL and some #ifdef's in
 dbdimp.c. I'm not sure if this option (and its name) is a good idea. Thus
 I try to find those symbols and the library ...
 
 
 Steffen
 diff -cb DBD-Oracle-1.15-orig/Makefile.PL DBD-Oracle-1.15/Makefile.PL
 *** DBD-Oracle-1.15-orig/Makefile.PL  Tue Sep 23 00:31:19 2003
 --- DBD-Oracle-1.15/Makefile.PL   Wed Sep 24 20:39:07 2003
 ***
 *** 84,92 
   $::opt_f = 0;   # include text of oracle's .mk file within generated Makefile
   $::opt_F = 0;   # force - ignore errors
   $::opt_W = 0;   # just write a basic default Makefile (won't build)
   
   Getopt::Long::config( qw( no_ignore_case ) );
 ! GetOptions(qw(b! v! d! g! p! l! c! 8! f! F! W! m=s n=s s=s S=s))
   or die Invalid arguments;
   
   $::opt_g = '-g';  # convert to actual string
 --- 84,93 
   $::opt_f = 0;   # include text of oracle's .mk file within generated Makefile
   $::opt_F = 0;   # force - ignore errors
   $::opt_W = 0;   # just write a basic default Makefile (won't build)
 + $::opt_ProC = 1;# use ProC
   
   Getopt::Long::config( qw( no_ignore_case ) );
 ! GetOptions(qw(b! v! d! g! p! l! c! 8! f! F! W! m=s n=s s=s S=s ProC!))
   or die Invalid arguments;
   
   $::opt_g = '-g';  # convert to actual string
 ***
 *** 581,586 
 --- 582,589 
   
   $opts{DEFINE} .= ' -Xa' if $Config{cc} eq 'clcc';   # CenterLine CC
   
 + $opts{DEFINE} .= ' -DHAVE_NO_PRO_C' unless $::opt_ProC;
 + 
   if ($::opt_8) {
   $opts{DEFINE} .= ' -DNO_OCI8';
   print \n**\n;
 Common subdirectories: DBD-Oracle-1.15-orig/Oracle.ex and DBD-Oracle-1.15/Oracle.ex
 diff -cb DBD-Oracle-1.15-orig/dbdimp.c DBD-Oracle-1.15/dbdimp.c
 *** DBD-Oracle-1.15-orig/dbdimp.c Thu Jun 12 01:04:35 2003
 --- DBD-Oracle-1.15/dbdimp.c  Wed Sep 24 20:44:11 2003
 ***
 *** 17,23 
   #include Oracle.h
   
   /* #include sql2oci.h for SQL_SINGLE_RCTX but causes clashes */
 ! #if !defined(SQL_SINGLE_RCTX)  defined(OCI_V8_SYNTAX)
   #define SQL_SINGLE_RCTX (dvoid *)0 /* from precomp/public/sqlcpr.h */
   #endif
   
 --- 17,23 
   #include Oracle.h
   
   /* #include sql2oci.h for SQL_SINGLE_RCTX but causes clashes */
 ! #if !defined(SQL_SINGLE_RCTX)  defined(OCI_V8_SYNTAX)  !defined(HAVE_NO_PRO_C)
   #define SQL_SINGLE_RCTX (dvoid *)0 /* from precomp/public/sqlcpr.h */
   #endif
   
 ***
 *** 321,328 
   init_mode |= OCI_THREADED;
   #endif
   
 - #ifdef SQL_SINGLE_RCTX
   if(use_proc_connection) {
   /* Use existing SQLLIB connection. Do not call OCIInitialize(), */
   /* since presumably SQLLIB already did that.*/
   status = SQLEnvGet(SQL_SINGLE_RCTX, imp_drh-envhp);
 --- 321,328 
   init_mode |= OCI_THREADED;
   #endif
   
   if(use_proc_connection) {
 + #ifdef SQL_SINGLE_RCTX
   /* Use existing SQLLIB connection. Do not call OCIInitialize(), */
   /* since presumably SQLLIB already did that.*/
   status = SQLEnvGet(SQL_SINGLE_RCTX, imp_drh-envhp);
 ***
 *** 332,340 
 SQLEnvGet. Failed to load ProC environment.);
   return 0;
   }
   }
   else {  /* Normal connect. */
 - #endif /* SQL_SINGLE_RCTX*/
   
   imp_drh-proc_handles = 0;
   /* XXX recent oracle docs recommend using OCIEnvCreate() instead of */
 --- 332,340 
 SQLEnvGet. Failed to load ProC environment.);
   return 0;
   }
 + #endif /* SQL_SINGLE_RCTX*/
   }
   else {  /* Normal connect. */
   
   imp_drh-proc_handles = 0;
   /* XXX recent oracle docs recommend using OCIEnvCreate() instead of */
 ***
 *** 356,361 
 --- 356,362 
   if (shared_dbh_ssv) {
   if (!imp_dbh-envhp) {
   if(use_proc_connection) {
 + #ifdef SQL_SINGLE_RCTX
   status = SQLEnvGet(SQL_SINGLE_RCTX, imp_dbh-envhp);
   imp_dbh-proc_handles = 1;
   if (status != SQL_SUCCESS) {
 ***
 *** 

Re: DBD::Oracle beta available for testing

2003-09-25 Thread Steffen Goeldner
Tim Bunce wrote:
 
 Is it an alpha or a beta? Who knows? Probably more alpha than beta
 but it it what it is and you're welcome to hit on it.

Perl 5.6.1, MSWin32, Borland 5.5, Oracle 8.1.7

dmake test:

t\base...ok
t\cursor.ok
t\generalok
t\long...ok 53/372# failed test 60 at line 328.
t\long...ok 58/372# failed test 68 at line 328.
t\long...ok 62/372# failed test 76 at line 328.
t\long...ok 70/372# failed test 86 at line 342.
# failed test 88 at line 342.
t\long...ok 79/372# failed test 90 at line 342.
t\long...ok 145/372# failed test 153 at line 328.
t\long...ok 147/372# failed test 161 at line 328.
t\long...ok 155/372# failed test 169 at line 328.
t\long...ok 163/372# failed test 179 at line 342.
# failed test 181 at line 342.
t\long...ok 171/372# failed test 183 at line 342.
t\long...ok 343/372
Some tests for LONG data type handling failed. These are generally Oracle bugs.
Please report this to the dbi-users mailing list, and include the
Oracle version number of both the client and the server.
Please also include the output of the 'perl -V' command.
(If you can, please study t/long.t to investigate the cause.
Feel free to edit the tests to see what's happening in more detail.
Especially by adding trace() calls around the failing tests.
Run the tests manually using the command perl -Mblib t/long.t)
Meanwhile, if the other tests have passed you can use DBD::Oracle.

t\long...dubious
Test returned status 4 (wstat 1024, 0x400)
DIED. FAILED tests 60, 68, 76, 86, 88, 90, 153, 161, 169, 179, 181, 183
Failed 12/372 tests, 96.77% okay
t\meta...ok
t\ph_typeok
t\plsql..ok
t\reauth.skipped test on this platform
t\select.ok
Failed Test Stat Wstat Total Fail  Failed  List of Failed
---
t\long.t   4  1024   372   12   3.23%  60 68 76 86 88 90 153 161 169 179
   181 183
1 test skipped.
Failed 1/9 test scripts, 88.89% okay. 12/1490 subtests failed, 99.19% okay.
dmake.exe:  Error code 32, while making 'test_dynamic'

--

Verbose output for t/long attached. Hints welcome!

BTW: I have a core dump after the last test. If I add
an '$dbh-disconnect;' to the END {}, it says

  t\longok 372/372DBI::db=HASH(0x180be8c)-disconnect
invalidates 5 active statement handles (either destroy
statement handles or call finish on them before
disconnecting) at t\long.t line 380.

and still crashes ...


SteffenUsing C:/temp/DBD-Oracle-1.15/blib
t\longcreate table dbd_ora__drop_me ( idx integer, lng LONG, dt date )
1..372
long_data0 length 10240
long_data1 length 81920
long_data2 length 71680
create table dbd_ora__drop_me ( idx integer, lng BLOB, dt date )
 --- insert some BLOB data (ora_type 113)
ok 1
ok 2
ok 3
ok 4
ok 5
 --- fetch BLOB data back again -- truncated - LongTruncOk == 1
LongReadLen 20, LongTruncOk 1
ok 6
ok 7
ok 8
ok 9
ok 10
ok 11
ok 12
ok 13
 --- fetch BLOB data back again -- truncated - LongTruncOk == 0
LongReadLen 81910, LongTruncOk
ok 14
ok 15
ok 16
ok 17
ok 18
ok 19
 --- fetch BLOB data back again -- complete - LongTruncOk == 0
LongReadLen 82920, LongTruncOk
ok 20
ok 21
ok 22
ok 23
ok 24
ok 25
ok 26
ok 27
 --- fetch BLOB data back again -- via blob_read
ok 28
ok 29
ok 30
ok 31
ok 32
ok 33
ok 34
ok 35
ok 36
ok 37
ok 38
 --- testing ora_auto_lob to access BLOB LobLocator
ok 39
40: OCILobLocatorPtr=SCALAR(0x22ad698)
ok 40
ok 41
ok 42
ok 43
41: OCILobLocatorPtr=SCALAR(0x22ad6bc)
ok 44
ok 45
ok 46
ok 47
42: OCILobLocatorPtr=SCALAR(0x22ad698)
ok 48
# failed test 60 at line 328.
ok 49
ok 50
ok 51
43: undef
ok 52
40 locator: OCILobLocatorPtr=SCALAR(0x22ad698)
ok 53
ok 54
# failed test 68 at line 328.
40 content: '040 foo!.X0.x.X0.x.X'
ok 55
ok 56
ok 57
ok 58
ok 59
not ok 60
error: ORA-24801: illegal parameter value in OCI lob function (DBD ERROR: 
OCILobWriteAppend)
41 locator: OCILobLocatorPtr=SCALAR(0x22ad6bc)
ok 61
ok 62
# failed test 76 at line 328.
41 content: '041 foo!901234567890'
ok 63
ok 64
ok 65
ok 66
ok 67
not ok 68
error: ORA-24801: illegal parameter value in OCI lob function (DBD ERROR: 
OCILobWriteAppend)
42 locator: OCILobLocatorPtr=SCALAR(0x22ad698)
ok 69
ok 70
42 content: '042 foo!cd2bcdefabcd'
# failed test 86 at line 342.
# failed test 88 at line 342.
ok 71
ok 72
ok 73
ok 74
ok 75
not ok 76
error: ORA-24801: illegal parameter value in OCI lob function (DBD ERROR: 
OCILobWriteAppend)
43 locator: undef
ok 77
ok 78
ok 79
ok 80
# failed test 90 at line 342.
ok 81
ok 82
ok 83
round again to check the length...
ok 84
40 locator: OCILobLocatorPtr=SCALAR(0x22ad728)
ok 85
not ok 86
41 locator: OCILobLocatorPtr=SCALAR(0x22ad6bc)
ok 87
not ok 88
42 locator: OCILobLocatorPtr=SCALAR(0x22ad728)
ok 89
not ok 90
43 locator: undef
ok 91
ok 92
ok 93
long_data0 length 10240
long_data1 length 81920
long_data2 length 71680
create table dbd_ora__drop_me ( idx integer, lng CLOB, dt date )
 --- 

Re: DBD::Oracle beta available for testing

2003-09-25 Thread Steffen Goeldner
Steffen Goeldner wrote:

 Perl 5.6.1, MSWin32, Borland 5.5, Oracle 8.1.7

[...]
 
 error: ORA-24801: illegal parameter value in OCI lob function (DBD ERROR: 
 OCILobWriteAppend)

Metalink lists such an error as Bug #886191, fixed
in 8.1.7. Hmmm.


Steffen


Re: DBD::Oracle beta available for testing

2003-09-25 Thread Tim Bunce
On Thu, Sep 25, 2003 at 04:09:57PM +0200, Steffen Goeldner wrote:
 Steffen Goeldner wrote:
 
  Perl 5.6.1, MSWin32, Borland 5.5, Oracle 8.1.7
 
 [...]
  
  error: ORA-24801: illegal parameter value in OCI lob function (DBD ERROR: 
  OCILobWriteAppend)
 
 Metalink lists such an error as Bug #886191, fixed
 in 8.1.7. Hmmm.

Hmm indeed :-)

Tim.


Re: DBD::Oracle beta available for testing

2003-09-25 Thread Tim Bunce
On Thu, Sep 25, 2003 at 12:39:05PM +0200, Steffen Goeldner wrote:
 Steffen Goeldner wrote:
  
  [...]
 
  I try to find those symbols and the library ...
 
 Thanks to Andy Hassall, I found the symbols in orasql8.dll.
 I did not install Pro*C and have a $ORACLE_HOME/precomp
 but no $ORACLE_HOME/precomp/lib (and no orasql8.lib).

Er, so how did you find the symbols in orasql8.dll then?

 Even if, Borland C++ is no longer supported:
 
   http://my.kharkov.org/docs/oracle/nt.816/a73023/ch1.htm#1660
 
 I see 2 options:
 
 1) Make an orasql8.lib:
 
  implib -a ORASQL8 /Oracle/Ora81/bin/ORASQL8.DLL
 
and add it to $opts{LIBS} in Makefile.PL.
 
 2) Import via .def file, e.g.:
 
 $opts{IMPORTS} = {
   _SQLEnvGet= 'orasql8.SQLEnvGet',
   _SQLSvcCtxGet = 'orasql8.SQLSvcCtxGet'
 } if $os eq 'MSWin32'  $Config{cc} eq 'bcc32';  # Borland CC

Does that work for you? And for other compilers?
Wouldn't orasql8.dll still need to be installed and listed on the
linker command line?

 The remaining question is: how to find out the correct
 version number? Maybe something like that:
 
   if ( $os eq 'MSWin32' ) {
 for ( glob $OH/ORAINST/*.rgs) {
   my $rgs = substr $_, length $OH/ORAINST/;
   $rgs =~ /(\d)(\d)(\d)/;
   $inspdver{RDBMS} = join '.', $1, $2, $3;
 }
   }
 
 (There is an empty! 'Oracle 817 Production.rgs' in my
 $OH/ORAINST directory. I don't know how portable that is.)

There might be a version number in the registry.

But since *very* few people would need the ability to
share database connections with ProC/SQLLIB code my preference
right now is to just disable it entirely on Windows and
only enable it on other platforms for Oracle = 9.0.

Tim.


Re: DBD::Oracle beta available for testing

2003-09-25 Thread Andy Hassall
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

2003-09-25 Thread Kristian Nielsen
Tim Bunce [EMAIL PROTECTED] writes:

 But since *very* few people would need the ability to
 share database connections with ProC/SQLLIB code my preference

Yes, I agree, I implemented this because I wanted to migrate a large
ProC based codebase gradually to using Perl/DBI, so I am embedding Perl
in a ProC-based application. Few people would ever find themselves in
this unfortunate situation, and if they did, having to slightly tweak
the DBD::Oracle build would be the least of their problems.

 right now is to just disable it entirely on Windows and
 only enable it on other platforms for Oracle = 9.0.

Hm, I *think* that I had this running on 8.1.7 before we upgraded to
Oracle 9. Not absolutely sure though.

Sorry that I cannot help with the Windows part, but I do not have
access to a Windows Oracle development environment.

 - Kristian.

-- 
Kristian Nielsen   [EMAIL PROTECTED]
Development Manager, Sifira A/S