I've been trying to use DBD::ADO 2.84 (the latest available via ActiveState PPM). I wrote up a simple script to perform a SELECT from Oracle 8.1.7:
use strict;
use DBI qw(:sql_types);
my $userid = "****";
my $password = "****";
my $sql = 'SELECT SYSDATE FROM DUAL';
my $dsn = "Provider=OraOLEDB.Oracle;Data Source=****;";
unlink 'dbitrace.log' if -e 'dbitrace.log';
DBI->trace(1, 'dbitrace.log');
my $dbh = DBI->connect("dbi:ADO:$dsn", $userid, $password,
{ RaiseError => 1, AutoCommit => 0 });
my $sth = $dbh->prepare($sql);
$sth->execute();
$sth->dump_results();
$sth->finish();
$dbh->disconnect();
Up to the execute(), it's OK. I then get the error:
>perl -w OneWorld_Table_Description.pl
Use of uninitialized value in subroutine entry at E:/Perl/site/lib/DBI.pm line 587.
DBD::ADO::st execute failed: Can't execute statement 'SELECT SYSDATE FROM DUAL':
Description : Multiple-step operation completed with one or more errors. Check each status value.
HelpContext :
HelpFile :
NativeError :
Number : 265946
Source : OraOLEDB
SQLState :
at OneWorld_Table_Description.pl line 42.
DBD::ADO::st execute failed: Can't execute statement 'SELECT SYSDATE FROM DUAL':
Description : Multiple-step operation completed with one or more errors. Check each status value.
HelpContext :
HelpFile :
NativeError :
Number : 265946
Source : OraOLEDB
SQLState :
at OneWorld_Table_Description.pl line 42.
>Exit code: 255
The output from the DBI trace (level 1):
DBI 1.42-ithread default trace level set to Ox1/0 (in pid 1876)
-> DBI->connect(dbi:ADO:Provider=OraOLEDB.Oracle;Data Source=****;, ****, ****, HASH(0x15d5700))
-> DBI->install_driver(ADO) for MSWin32 perl=5.008003 pid=1876 ruid=0 euid=0
install_driver: DBD::ADO version 2.84 loaded from E:/Perl/site/lib/DBD/ADO.pm
<- install_driver= DBI::dr=HASH(0x1b57384)
->ADO Connection: <- STORE('Provider' 'OraOLEDB.Oracle')= 'OraOLEDB.Oracle' at ADO.pm line 146
->> Storing Provider OraOLEDB.Oracle
->> Open ADO connection using Data Source=****
->> Transaction support: 2 Transactions can contain DML statements. DDL statements within a transaction cause the transaction to be committed.
1 <> FETCH('Warn')= 0 ('Warn' from cache) at ADO.pm line 1290
<- STORE('Active' 1)= 1 at ADO.pm line 208
1 <> FETCH('AutoCommit')= 1 ('AutoCommit' from cache) at ADO.pm line 1301
1 <> FETCH('Warn')= 0 ('Warn' from cache) at ADO.pm line 1290
<- connect= DBI::db=HASH(0x1cc814c)
1 <> FETCH('Warn')= 0 ('Warn' from cache) at ADO.pm line 1290
<- STORE('LongReadLen' 0)= 1 at ADO.pm line 450
<- STORE('LongTruncOk' 0)= 1 at ADO.pm line 451
<- STORE('RowsInCache' 0)= 0 at ADO.pm line 456
<> FETCH('ado_conn')= Win32::OLE=HASH(0x1cc847c) ('ado_conn' from cache) at ADO.pm line 1384
<> FETCH('ado_comm')= Win32::OLE=HASH(0x15d57c0) ('ado_comm' from cache) at ADO.pm line 1385
<> FETCH('Statement')= ( 'SELECT SYSDATE FROM DUAL' ) [1 items] ('Statement' from cache) at ADO.pm line 1387
<- STORE('NUM_OF_PARAMS' 0)= 1 at ADO.pm line 1404
1 <> FETCH('Statement')= 'SELECT SYSDATE FROM DUAL' ('Statement' from cache) at ADO.pm line 1459
!! ERROR: -1 'Can't execute statement 'SELECT SYSDATE FROM DUAL':
Description : Multiple-step operation completed with one or more errors. Check each status value.
HelpContext :
HelpFile :
NativeError :
Number : 265946
Source : OraOLEDB
SQLState :
' (err#1)
1 <- set_err(-1 'Can't execute statement 'SELECT SYSDATE FROM DUAL':
Description : Multiple-step operation completed with one or more errors. Check each status value.
HelpContext :
HelpFile :
NativeError :
Number : 265946
Source : OraOLEDB
SQLState :
')= undef at ADO.pm line 1568
<- destroy statement handler
-> destroy statement handler
-- State: 1
-- Modified ADO Connection Attributes: 0
-- AutoCommit: 0, Provider Support: 2, Comments: Transactions can contain DML statements. DDL statements within a transaction cause the transaction to be committed.
I'm running 5.8.3.809 of ActiveState's Perl. I looked on perl.dbi.users with no luck. I'd post this to the list, but my company's spam filter would snarf it. :( Any ideas?
Update (21-May-2004): I tried to build DBD::Oracle via CPAN. It failed tests on long and ph_types which included a Memory Violation. Long story short, I downgraded to ActiveState's 5.6.1 build 638, and installed the latest available DBI amd DBD::Oracle via PPM. Now, I'm "shittin' in tall cotton". :) Thanks, to everyone who commented.
A bad mix
VSarkiss on 2004-05-19T03:19:39
I'd avoid using OraOLEDB altogether. (An Oracle product working nicely on MS? What will they think of next?)
May seem silly, but why aren't you using DBD::Oracle? It works fine on Win32....
Re:A bad mix
Buck on 2004-05-19T20:27:50
Not so silly as the answer. While it does work fine on Win32, ActiveState *STILL* won't make it available via PPM. I've already fought that battle and lost.
Re:A bad mix
jplindstrom on 2004-05-19T20:42:03
Isn't it that Oracle's license doesn't allow anyone to redistribute the client libs?
Re:A bad mix
Buck on 2004-05-19T21:32:55
According to ActiveState's list (the URL escapes me), the build failed on Win32. I'm gonna try it via CPAN just because I'm persistent in a masochistic sort of way. :)
idea
cog on 2004-05-19T17:11:20
Get another (temporary) e-mail (web-mail) out there and post the list. There's plenty of sites to chose from.
Re:idea
Buck on 2004-05-21T18:24:15
I found out my ISP for my home account has a webmail interface, so I used it and got myself subscribed. Thanks.
