RE: Informix, AIX 5.1 -- no joy w/ AIX C or gcc
From: Jonathan Leffler [mailto:[EMAIL PROTECTED] > If you (and Darryl) could send me outputs of 'perl -V' from your > working versions of Perl + DBI + DBD::Informix, it may help > me - thanks. All that fun stuff is in my original post: Subject: DBD::Informix, AIX 5.1 -- no joy w/ AIX C or gcc Sent: Mon 10/20/2003 11:07 AM (Note that subject is different than this subject.) Per my later posts, we got out of crisis mode w/ a Perl 5.6.1 RPM. I've retained all of the problem environment, though, if you want to instruct me in your ways of C wizardry I'd be happy to do and try whatever for the greater good. j
RE: DBI.pm DBD::Oracle::db
Tim,
I changed to wrong user id and wrong password, but the trace files seems to
have no difference
from the previous underline problem. Please see the attached trace files.
I thought with the DBI.pm and DBD::Oracle, Oracle client is not required,
but one of users from the list
corrected me. Thank to Michael A. Chase.
Thanks
Mei
-Original Message-
From: Tim Bunce [mailto:[EMAIL PROTECTED]
Sent: Monday, October 27, 2003 12:04 PM
To: Chang, Mei
Cc: '[EMAIL PROTECTED]'
Subject: Re: DBI.pm DBD::Oracle::db
On Mon, Oct 27, 2003 at 09:29:48AM -0700, Chang, Mei wrote:
> Tim,
>
> I installed an Oracle Client on a W2K Server, and everything works.
> Does this make sense to you?
Sure. It's fixed the underlying problem, but possibly not fixed the
lack of an error message on connect failures. Try forcing connect
failures (by using incorrect password and/or wrong dbname etc) and
see if you do get reasonable error messages. Thanks.
Tim.
> Thanks
> Mei
>
> -Original Message-
> From: Tim Bunce [mailto:[EMAIL PROTECTED]
> Sent: Friday, October 24, 2003 4:43 AM
> To: Chang, Mei
> Cc: '[EMAIL PROTECTED]'
> Subject: Re: DBI.pm DBD::Oracle::db
>
>
> No idea. Try a higher trace level (eg 9).
>
> Tim.
>
> On Thu, Oct 23, 2003 at 03:23:10PM -0600, Chang, Mei wrote:
> > Users,
> >
> > I wrote a perl script and compiled it by perl2exe. I placed the exe
file
> to
> > different machines, the results were different:
> >
> > Procedures:
> >
> > 1. ran from my pc, it worked fine (my PC is Win2K) - My pc has DBI
module
> > and perl 5.6 installed
> > 2. placed the executable on server A (Win NT)and ran on it, it worked
> fine.
> > - This server happened to have perl 5.0.1 and oracle client installed.
> > 3. placed on Server B (W2k) and ran on it, it failed on db-connect
(please
> > see the attached trace file)
> > 4. Mapped to server B's drive with the executable there, and ran it from
> my
> > pc, and it worked.
> > 5. Logged onto server B, and ran the executable on Server B again, it
> still
> > failed with the same error.
> >
> > The only problem seemed to be on the server B. but looking I could
> not
> > figure out what's wrong?
> > (Note: The dsn, sid, db name, user id, password are all the same. )
> >
> > With the executable, I should not need the perl.exe on server B,
and
> > with DBI and DBD, I should not need Oracle client. What did I miss?
> >
> > Thanks in advance.
> >
> > M. Chang
> >
> >
> > The two trace files were from server B .
> >
> > procedure #3's results
> > <>
> >
> > procedures #4 results
> > <>
> >
> >
> >
> > **
> > This message, including any attachments, contains confidential
information
> intended for a specific individual and purpose, and is protected by law.
If
> you are not the intended recipient, please contact sender immediately by
> reply e-mail and destroy all copies. You are hereby notified that any
> disclosure, copying, or distribution of this message, or the taking of any
> action based on it, is strictly prohibited.
> > TIAA-CREF
> > **
> >
>
> > NOT WORKING
> >
> >
> >
> > DBI 1.37-ithread dispatch trace level set to 4
> > Note: perl is running without the recommended perl -w option
> > -> DBI->connect(dbi:Oracle:db1;host=prodsys;sid=db1, tec, ,
> HASH(0x8b7f0e4))
> > -> DBI->install_driver(Oracle) for MSWin32 perl=5.006001 pid=2272
> ruid=0 euid=0
> >install_driver: DBD::Oracle version 1.06 loaded from
> PERL2EXE_STORAGE/DBD/Oracle.pm
> > New DBI::dr (for DBD::Oracle::dr, parent=, id=)
> > dbih_setup_handle(DBI::dr=HASH(0x8dfceb8)=>DBI::dr=HASH(0x8d83564),
> DBD::Oracle::dr, 0, Null!)
> > dbih_make_com(Null!, , DBD::Oracle::dr, 84, )
> thr#08B7F374
> > <- install_driver= DBI::dr=HASH(0x8dfceb8)
> > -> connect for DBD::Oracle::dr (DBI::dr=HASH(0x8dfceb8)~0x8d83564
> 'db1;host=prodsys;sid=db1' 'tec' HASH(0x8d8387c)) thr#08B7F374
> > 1 -> debug in DBD::_::common for DBD::Oracle::dr
> (DBI::dr=HASH(0x8d83564)~INNER) thr#08B7F374
> > 1 <- debug= 4 at Oracle.pm line 90 via d:\Utils\App\time_to_close.exe
> line 60
> > New DBI::db (for DBD::Oracle::db, parent=DBI::dr=HASH(0x8d83564),
id=)
> > dbih_setup_handle(DBI::db=HASH(0x8d83534)=>DBI::db=HASH(0x8d82930),
> DBD::Oracle::db, 8dfcc0c, Null!)
> > dbih_make_com(DBI::dr=HASH(0x8d83564), 08D831E8, DBD::Oracle::db,
676,
> ) thr#08B7F374
> >
> >
>
> *
> > <- connect= undef at DBI.pm line 582 via
> d:\Utils\App\time_to_close.exe
> > line 60
> > -> errstr in DBD::_::common for DBD::Oracle::dr
> (DBI::dr=HASH(0x8dfceb8)~0x8d83564) thr#08B7F374
> > <- errstr= undef at DBI.pm line 584 via
d:\Utils\App\time_to_close.exe
> line 60
> >DBI connect('db
Re: DBD::Sybase and Sybase::CTlib build problems w/ 5.8.1, Solaris, gcc 3.x
On Mon, 2003-10-27 at 07:29, Nicholas Clark wrote: > On Tue, Oct 21, 2003 at 03:00:58PM +0100, Alan Burlison wrote: > > It would be really helpful if anyone who has seen this problem checks the > > patch works for them, and then it can be given the all-clear to be > > integrated into 5.8.2-to-be. Thanks! > > I'm waiting on someone saying that it works. I've just tried rebuilt 5.8.1 with the patch, and this fixes the problem that I was having with building DBD::Sybase. So from my perspective the patch works. Michael -- Michael Peppler Data Migrations, Inc. [EMAIL PROTECTED] http://www.mbay.net/~mpeppler Sybase T-SQL/OpenClient/OpenServer/C/Perl developer available for short or long term contract positions - http://www.mbay.net/~mpeppler/resume.html
Trouble Installing DBD::Oracle on Red Hat 8
Hi All, I am trying to install DBD::Oracle for the first time on Linux. I've had experiences with Solaris, but am not as savvy in Linux. I installed the 9i client librarues for linux, confirmed connectivty by tnsping a database on the network, set my Oracle home, sid, and path variables and try to run perl Makefile.PL and get this: Using DBI 1.30 installed in /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/auto/DBI Configuring DBD::Oracle ... >>> Remember to actually *READ* the README file! Especially if you have any problems. Using Oracle in /home/harsch/OraHome1 WARNING: could not decode oracle version from /home/harsch/OraHome1/orainst/inspdver, or /home/harsch/OraHome1/install/unix.rgs or from ORACLE_HOME path /home/harsch/OraHome1. Oracle version based logic in Makefile.PL may produce erroneous results. Found header files in rdbms/demo. * I can't find the header files I need in your Oracle installation. You probably need to install some more Oracle components. I'll keep going, but the compile will probably fail. See README.clients for more information. * Unable to locate an oracle.mk, proc.mk or other suitable *.mk file in your Oracle installation. (I looked in /home/harsch/OraHome1/rdbms/lib/oracle.mk /home/harsch/OraHome1/rdbms/demo/oracle.mk /home/harsch/OraHome1/rdbms/demo/demo_rdbms.mk /home/harsch/OraHome1/otrace/demo/atmoci.mk /home/harsch/OraHome1/precomp/demo/proc/proc.mk /home/harsch/OraHome1/precomp/demo/proc/demo_proc.mk /home/harsch/OraHome1/proc/lib/proc.mk /home/harsch/OraHome1/proc16/lib/proc16.mk) The oracle.mk (or demo_rdbms.mk) file is part of the Oracle RDBMS product. The proc.mk (or demo_proc.mk) file is part of the Oracle Pro*C product. You need to build DBD::Oracle on a system which has one of these Oracle components installed. (Other *.mk files such as the env_*.mk files will not work.) In the unlikely event that a suitable *.mk file is installed somewhere non-standard you can specify where it is using the -m option: perl Makefile.PL -m /path/to/your.mk See README.clients for more information and some alternatives. at Makefile.PL line 903.
Re: DBI.pm DBD::Oracle::db
On Mon, 27 Oct 2003 09:29:48 -0700 "Chang, Mei" <[EMAIL PROTECTED]> wrote: > I installed an Oracle Client on a W2K Server, and everything works. > Does this make sense to you? It is possible for things to work in MS Windows. If you question is whether the Oracle client software is necessary for DBD::Oracle to work, yes it is. -- Mac :}) ** I usually forward private questions to the appropriate mail list. ** Ask Smarter: http://www.catb.org/~esr/faqs/smart-questions.html Give a hobbit a fish and he eats fish for a day. Give a hobbit a ring and he eats fish for an age.
Re: DBI.pm DBD::Oracle::db
On Mon, Oct 27, 2003 at 09:29:48AM -0700, Chang, Mei wrote:
> Tim,
>
> I installed an Oracle Client on a W2K Server, and everything works.
> Does this make sense to you?
Sure. It's fixed the underlying problem, but possibly not fixed the
lack of an error message on connect failures. Try forcing connect
failures (by using incorrect password and/or wrong dbname etc) and
see if you do get reasonable error messages. Thanks.
Tim.
> Thanks
> Mei
>
> -Original Message-
> From: Tim Bunce [mailto:[EMAIL PROTECTED]
> Sent: Friday, October 24, 2003 4:43 AM
> To: Chang, Mei
> Cc: '[EMAIL PROTECTED]'
> Subject: Re: DBI.pm DBD::Oracle::db
>
>
> No idea. Try a higher trace level (eg 9).
>
> Tim.
>
> On Thu, Oct 23, 2003 at 03:23:10PM -0600, Chang, Mei wrote:
> > Users,
> >
> > I wrote a perl script and compiled it by perl2exe. I placed the exe file
> to
> > different machines, the results were different:
> >
> > Procedures:
> >
> > 1. ran from my pc, it worked fine (my PC is Win2K) - My pc has DBI module
> > and perl 5.6 installed
> > 2. placed the executable on server A (Win NT)and ran on it, it worked
> fine.
> > - This server happened to have perl 5.0.1 and oracle client installed.
> > 3. placed on Server B (W2k) and ran on it, it failed on db-connect (please
> > see the attached trace file)
> > 4. Mapped to server B's drive with the executable there, and ran it from
> my
> > pc, and it worked.
> > 5. Logged onto server B, and ran the executable on Server B again, it
> still
> > failed with the same error.
> >
> > The only problem seemed to be on the server B. but looking I could
> not
> > figure out what's wrong?
> > (Note: The dsn, sid, db name, user id, password are all the same. )
> >
> > With the executable, I should not need the perl.exe on server B, and
> > with DBI and DBD, I should not need Oracle client. What did I miss?
> >
> > Thanks in advance.
> >
> > M. Chang
> >
> >
> > The two trace files were from server B .
> >
> > procedure #3's results
> > <>
> >
> > procedures #4 results
> > <>
> >
> >
> >
> > **
> > This message, including any attachments, contains confidential information
> intended for a specific individual and purpose, and is protected by law. If
> you are not the intended recipient, please contact sender immediately by
> reply e-mail and destroy all copies. You are hereby notified that any
> disclosure, copying, or distribution of this message, or the taking of any
> action based on it, is strictly prohibited.
> > TIAA-CREF
> > **
> >
>
> > NOT WORKING
> >
> >
> >
> > DBI 1.37-ithread dispatch trace level set to 4
> > Note: perl is running without the recommended perl -w option
> > -> DBI->connect(dbi:Oracle:db1;host=prodsys;sid=db1, tec, ,
> HASH(0x8b7f0e4))
> > -> DBI->install_driver(Oracle) for MSWin32 perl=5.006001 pid=2272
> ruid=0 euid=0
> >install_driver: DBD::Oracle version 1.06 loaded from
> PERL2EXE_STORAGE/DBD/Oracle.pm
> > New DBI::dr (for DBD::Oracle::dr, parent=, id=)
> > dbih_setup_handle(DBI::dr=HASH(0x8dfceb8)=>DBI::dr=HASH(0x8d83564),
> DBD::Oracle::dr, 0, Null!)
> > dbih_make_com(Null!, , DBD::Oracle::dr, 84, )
> thr#08B7F374
> > <- install_driver= DBI::dr=HASH(0x8dfceb8)
> > -> connect for DBD::Oracle::dr (DBI::dr=HASH(0x8dfceb8)~0x8d83564
> 'db1;host=prodsys;sid=db1' 'tec' HASH(0x8d8387c)) thr#08B7F374
> > 1 -> debug in DBD::_::common for DBD::Oracle::dr
> (DBI::dr=HASH(0x8d83564)~INNER) thr#08B7F374
> > 1 <- debug= 4 at Oracle.pm line 90 via d:\Utils\App\time_to_close.exe
> line 60
> > New DBI::db (for DBD::Oracle::db, parent=DBI::dr=HASH(0x8d83564), id=)
> > dbih_setup_handle(DBI::db=HASH(0x8d83534)=>DBI::db=HASH(0x8d82930),
> DBD::Oracle::db, 8dfcc0c, Null!)
> > dbih_make_com(DBI::dr=HASH(0x8d83564), 08D831E8, DBD::Oracle::db, 676,
> ) thr#08B7F374
> >
> >
>
> *
> > <- connect= undef at DBI.pm line 582 via
> d:\Utils\App\time_to_close.exe
> > line 60
> > -> errstr in DBD::_::common for DBD::Oracle::dr
> (DBI::dr=HASH(0x8dfceb8)~0x8d83564) thr#08B7F374
> > <- errstr= undef at DBI.pm line 584 via d:\Utils\App\time_to_close.exe
> line 60
> >DBI connect('db1;host=prodsys;sid=db1','tec',...) failed:
> >
> >
>
> ***
> > <> DESTROY ignored for outer handle DBI::db=HASH(0x8d83534) (inner
> DBI::db=HASH(0x8d82930))
> > -> DESTROY for DBD::Oracle::db (DBI::db=HASH(0x8d82930)~INNER)
> thr#08B7F374
> > DESTROY for DBI::db=HASH(0x8d82930) ignored - handle not
> initialised
> > <- DESTROY= undef
> > dbih_clearcom 0x8d83534 (com 0x8efae50, type 2) done.
> >
> >
RE: DBI.pm DBD::Oracle::db
Tim,
I installed an Oracle Client on a W2K Server, and everything works.
Does this make sense to you?
Thanks
Mei
-Original Message-
From: Tim Bunce [mailto:[EMAIL PROTECTED]
Sent: Friday, October 24, 2003 4:43 AM
To: Chang, Mei
Cc: '[EMAIL PROTECTED]'
Subject: Re: DBI.pm DBD::Oracle::db
No idea. Try a higher trace level (eg 9).
Tim.
On Thu, Oct 23, 2003 at 03:23:10PM -0600, Chang, Mei wrote:
> Users,
>
> I wrote a perl script and compiled it by perl2exe. I placed the exe file
to
> different machines, the results were different:
>
> Procedures:
>
> 1. ran from my pc, it worked fine (my PC is Win2K) - My pc has DBI module
> and perl 5.6 installed
> 2. placed the executable on server A (Win NT)and ran on it, it worked
fine.
> - This server happened to have perl 5.0.1 and oracle client installed.
> 3. placed on Server B (W2k) and ran on it, it failed on db-connect (please
> see the attached trace file)
> 4. Mapped to server B's drive with the executable there, and ran it from
my
> pc, and it worked.
> 5. Logged onto server B, and ran the executable on Server B again, it
still
> failed with the same error.
>
> The only problem seemed to be on the server B. but looking I could
not
> figure out what's wrong?
> (Note: The dsn, sid, db name, user id, password are all the same. )
>
> With the executable, I should not need the perl.exe on server B, and
> with DBI and DBD, I should not need Oracle client. What did I miss?
>
> Thanks in advance.
>
> M. Chang
>
>
> The two trace files were from server B .
>
> procedure #3's results
> <>
>
> procedures #4 results
> <>
>
>
>
> **
> This message, including any attachments, contains confidential information
intended for a specific individual and purpose, and is protected by law. If
you are not the intended recipient, please contact sender immediately by
reply e-mail and destroy all copies. You are hereby notified that any
disclosure, copying, or distribution of this message, or the taking of any
action based on it, is strictly prohibited.
> TIAA-CREF
> **
>
> NOT WORKING
>
>
>
> DBI 1.37-ithread dispatch trace level set to 4
> Note: perl is running without the recommended perl -w option
> -> DBI->connect(dbi:Oracle:db1;host=prodsys;sid=db1, tec, ,
HASH(0x8b7f0e4))
> -> DBI->install_driver(Oracle) for MSWin32 perl=5.006001 pid=2272
ruid=0 euid=0
>install_driver: DBD::Oracle version 1.06 loaded from
PERL2EXE_STORAGE/DBD/Oracle.pm
> New DBI::dr (for DBD::Oracle::dr, parent=, id=)
> dbih_setup_handle(DBI::dr=HASH(0x8dfceb8)=>DBI::dr=HASH(0x8d83564),
DBD::Oracle::dr, 0, Null!)
> dbih_make_com(Null!, , DBD::Oracle::dr, 84, )
thr#08B7F374
> <- install_driver= DBI::dr=HASH(0x8dfceb8)
> -> connect for DBD::Oracle::dr (DBI::dr=HASH(0x8dfceb8)~0x8d83564
'db1;host=prodsys;sid=db1' 'tec' HASH(0x8d8387c)) thr#08B7F374
> 1 -> debug in DBD::_::common for DBD::Oracle::dr
(DBI::dr=HASH(0x8d83564)~INNER) thr#08B7F374
> 1 <- debug= 4 at Oracle.pm line 90 via d:\Utils\App\time_to_close.exe
line 60
> New DBI::db (for DBD::Oracle::db, parent=DBI::dr=HASH(0x8d83564), id=)
> dbih_setup_handle(DBI::db=HASH(0x8d83534)=>DBI::db=HASH(0x8d82930),
DBD::Oracle::db, 8dfcc0c, Null!)
> dbih_make_com(DBI::dr=HASH(0x8d83564), 08D831E8, DBD::Oracle::db, 676,
) thr#08B7F374
>
>
*
> <- connect= undef at DBI.pm line 582 via
d:\Utils\App\time_to_close.exe
> line 60
> -> errstr in DBD::_::common for DBD::Oracle::dr
(DBI::dr=HASH(0x8dfceb8)~0x8d83564) thr#08B7F374
> <- errstr= undef at DBI.pm line 584 via d:\Utils\App\time_to_close.exe
line 60
>DBI connect('db1;host=prodsys;sid=db1','tec',...) failed:
>
>
***
> <> DESTROY ignored for outer handle DBI::db=HASH(0x8d83534) (inner
DBI::db=HASH(0x8d82930))
> -> DESTROY for DBD::Oracle::db (DBI::db=HASH(0x8d82930)~INNER)
thr#08B7F374
> DESTROY for DBI::db=HASH(0x8d82930) ignored - handle not
initialised
> <- DESTROY= undef
> dbih_clearcom 0x8d83534 (com 0x8efae50, type 2) done.
>
> -- DBI::END
> -> disconnect_all for DBD::Oracle::dr
(DBI::dr=HASH(0x8dfceb8)~0x8d83564) thr#08B7F374
> <- disconnect_all= '' at DBI.pm line 649 via
d:\Utils\App\time_to_close.exe line 0
> ! -> DESTROY for DBD::Oracle::dr (DBI::dr=HASH(0x8d83564)~INNER)
thr#08B7F374
> ! <- DESTROY= (not implemented) during global destruction
> dbih_clearcom 0x8dfceb8 (com 0x8d831e8, type 1) done.
>
> ! <> DESTROY for DBI::dr=HASH(0x8dfceb8) ignored (inner handle gone)
>WORKIGN
>
>
>
> DBI 1.37-ithread dispatch trace level set to 4
> Note: perl is runnin
Re: DBD::Sybase and Sybase::CTlib build problems w/ 5.8.1, Solaris, gcc 3.x
On Tue, Oct 21, 2003 at 03:00:58PM +0100, Alan Burlison wrote: > It would be really helpful if anyone who has seen this problem checks the > patch works for them, and then it can be given the all-clear to be > integrated into 5.8.2-to-be. Thanks! I'm waiting on someone saying that it works. Nicholas Clark
ANNOUNCE: DBD::ADO 2.76
file: $CPAN/authors/id/S/SG/SGOELDNER/DBD-ADO-2.76.tar.gz size: 45244 bytes md5: f1f3c6737f32c3f7e222ff9e7b43d502 Changes: Dropped auto-commit emulation (relying on ADO's default behavior instead). Fixed errors like 'Command cannot be issued within a transaction'. Improved transaction handling (begin_work). Added t/31txn.t to test transactions / auto-commit. Added t/02cxn.t to test a connection. Steffen
