RE: db or file access?
-Original Message- From: Ron Savage [mailto:[EMAIL PROTECTED] Sent: 13 April 2005 11:07 To: Perl - DBI users Subject: Re: db or file access? * Replies will be sent through Spamex to [EMAIL PROTECTED] * For additional info click - http://www.spamex.com/i/?v=3D6273067 On Tue, 12 Apr 2005 10:46:06 +0200, Christian Merz wrote: Hi Folks Well, I thought I'd better put my keyboard where my mouth is, so I wrote an article on this: http://savage.net.au/Ron/html/images-in-files.html This is relevant, but tangential to something I am doing. see http://perlmonks.org/?node_id=448191 In particular, the idea of how we mark up an image in POD is pertinent, and has a bearing on how one specifies an image viz Referencing a file.
disconnect invalidates 1 active statement handle when closing cursor
I turned on the Tracing at got this.
2005-04-18 09:34:21 Connected to Oracle [DBI:Oracle:TMHP2] Successfully...
DBI::db=HASH(0x2035ba68) trace level set to 0x0/9 (DBI @ 0x0/0) in DBI
1.45-ithread (p
id 679972)
- prepare for DBD::Oracle::db (DBI::db=HASH(0x20358688)~0x2035ba68 '
BEGIN
Package.Procedure(:p1,:out_cursor);
END;
') thr#20019bb8
dbih_setup_handle(DBI::st=HASH(0x2035bb70)=DBI::st=HASH(0x2035bc54),
DBD::Oracle::st,
2035bb7c, Null!)
dbih_make_com(DBI::db=HASH(0x2035ba68), 2035c398, DBD::Oracle::st, 208,
0) thr#20019bb
8
dbih_setup_attrib(DBI::st=HASH(0x2035bc54), Err,
DBI::db=HASH(0x2035ba68)) SCALAR(0x20
19948c) (already defined)
dbih_setup_attrib(DBI::st=HASH(0x2035bc54), State,
DBI::db=HASH(0x2035ba68)) SCALAR(0x
201994ec) (already defined)
dbih_setup_attrib(DBI::st=HASH(0x2035bc54), Errstr,
DBI::db=HASH(0x2035ba68)) SCALAR(0
x201994bc) (already defined)
dbih_setup_attrib(DBI::st=HASH(0x2035bc54), TraceLevel,
DBI::db=HASH(0x2035ba68)) 9 (a
lready defined)
dbih_setup_attrib(DBI::st=HASH(0x2035bc54), FetchHashKeyName,
DBI::db=HASH(0x2035ba68)
) 'NAME' (already defined)
dbih_setup_attrib(DBI::st=HASH(0x2035bc54), HandleSetErr,
DBI::db=HASH(0x2035ba68)) un
def (not defined)
dbih_setup_attrib(DBI::st=HASH(0x2035bc54), HandleError,
DBI::db=HASH(0x2035ba68)) und
ef (not defined)
dbd_preparse scanned 2 distinct placeholders
OCIHandleAlloc(20395078,20471298,OCI_HTYPE_STMT,0,0)=SUCCESS
OCIStmtPrepare(203acec0,203a4f08,'
BEGIN
Package.Procedure(:p1,:out_cursor);
END;
',96,1,0)=SUCCESS
OCIAttrGet(203acec0,OCI_HTYPE_STMT,2047129c,0,24,203a4f08)=SUCCESS
dbd_st_prepare'd sql BEGIN (pl1, auto_lob1, check_sql1)
dbd_describe skipped for BEGIN
- prepare= DBI::st=HASH(0x2035bb70) at getdata.pl line 69
- bind_param for DBD::Oracle::st (DBI::st=HASH(0x2035bb70)~0x2035bc54
':p1' '50401559
2131100.x12') thr#20019bb8
bind :p1 == '504015592131100.x12' (type 0)
rebinding :p1 (not-utf8, ftype 1, csid 0, csform 0, inout 0)
bind :p1 == '504015592131100.x12' (size 19/20/0, ptype 4, otype 1)
bind :p1 == '504015592131100.x12' (size 19/19, otype 1, indp 0,
at_exec 1)
OCIBindByName(203acec0,204048ec,203a4f08,:p1,3,203
c2808,19,1,204048fe,0,204048fc
,0,0,2)=SUCCESS
OCIBindDynamic(203acb98,203a4f08,204048c8,2023ab70,204048c8,2023ab7c)=SUCCESS
OCIAttrGet(203acb98,OCI_HTYPE_BIND,204048d8,0,31,203a4f08)=SUCCESS
bind :p1 == '504015592131100.x12' (in, not-utf8, csid 1-0-1,
ftype 1, csform 0-
0, maxlen 19, maxdata_size 0)
OCIAttrSet(203acb98,OCI_HTYPE_BIND,2ff2240a,0,31,203a4f08)=SUCCESS
- bind_param= 1 at getdata.pl line 70
- bind_param_inout for DBD::Oracle::st
(DBI::st=HASH(0x2035bb70)~0x2035bc54 ':out_cur
sor' SCALAR(0x2034c338) 0 HASH(0x2035bc48)) thr#20019bb8
bind :out_cursor == undef (type 0, inout 0x2034c338, maxlen 0,
attribs: HASH(0x203
5bc48))
rebinding :out_cursor (not-utf8, ftype 116, csid 0, csform 0, inout
1)
bind :out_cursor done with ftype 116
- bind_param_inout= 1 at getdata.pl line 71
- execute for DBD::Oracle::st (DBI::st=HASH(0x2035bb70)~0x2035bc54)
thr#20019bb8
dbd_st_execute BEGIN (out1, lob0)...
bind :out_cursor - allocating new sth...
OCIHandleAlloc(20395078,20471320,OCI_HTYPE_STMT,0,0)=SUCCESS
OCIBindByName(203acec0,2047131c,203a4f08,:out_cursor,11,20471320,0,116,0,0,0,0,0
,0)=SUCCESS
FETCH DISPATCH (DBI::db=HASH(0x2035ba68) rc2/3 @2 g0 ima404
pid#679972) at /u
sr/opt/perl5/lib/site_perl/5.8.0/aix-thread-multi/DBI.pm line 1143 via
FETCH= 'DBD::Oracle::db' ('ImplementorClass' from cache) at
/usr/opt/perl5/lib/site
_perl/5.8.0/aix-thread-multi/DBI.pm line 1143 via getdata.pl line 72
dbih_setup_handle(DBI::st=HASH(0x203583ac)=DBI::st=HASH(0x2035bc48),
DBD::Oracle::st,
2035bb10, Null!)
dbih_make_com(DBI::db=HASH(0x2035ba68), 2035c398, DBD::Oracle::st, 208,
0) thr#20019bb
8
dbih_setup_attrib(DBI::st=HASH(0x2035bc48), Err,
DBI::db=HASH(0x2035ba68)) SCALAR(0x20
19948c) (already defined)
dbih_setup_attrib(DBI::st=HASH(0x2035bc48), State,
DBI::db=HASH(0x2035ba68)) SCALAR(0x
201994ec) (already defined)
dbih_setup_attrib(DBI::st=HASH(0x2035bc48), Errstr,
DBI::db=HASH(0x2035ba68)) SCALAR(0
x201994bc) (already defined)
dbih_setup_attrib(DBI::st=HASH(0x2035bc48), TraceLevel,
DBI::db=HASH(0x2035ba68)) 9 (a
lready defined)
dbih_setup_attrib(DBI::st=HASH(0x2035bc48), FetchHashKeyName,
DBI::db=HASH(0x2035ba68)
) 'NAME' (already defined)
dbih_setup_attrib(DBI::st=HASH(0x2035bc48), HandleSetErr,
DBI::db=HASH(0x2035ba68)) un
def (not defined)
dbih_setup_attrib(DBI::st=HASH(0x2035bc48), HandleError,
DBI::db=HASH(0x2035ba68)) und
ef (not defined)
bind :out_cursor - allocated DBI::st=HASH(0x203583ac)...
in ':p1' [0,0]: len 19, ind 0
OCIStmtExecute(203a4de0,203acec0,203a4f08,1,0,0,0,0)=SUCCESS
Re: Calling Stored Procedure using REF CURSORS
I tried with and without closing it and got the following error:
Is there something more I needed to add?
Without Closing:
DBI::db=HASH(0x2035aef0)-disconnect invalidates 1 active statement handle
(either destroy
statement handles or call finish on them before disconnecting)
With Closing:
DBI::db=HASH(0x2035b630)-disconnect invalidates 1 active statement handle
(either destroy
statement handles or call finish on them before disconnecting)
This is what I have:
$dbh = TMH::dbConnect(*LOGFILE);
my $IN_FILE_NM = TEST;
my $out_cursor;
$sql = qq(
BEGIN
Package.Procedure(:p1,:out_cursor);
END;
);
my $func = $dbh-prepare($sql);
$func-bind_param(:p1,$IN_FILE_NM);
$func-bind_param_inout(:out_cursor, \$out_cursor, 0,{ ora_type=ORA_RSET
} );
$func-execute;
$dbh-commit;
my $sql = $dbh-prepare('BEGIN close :out_cursor; END;');
$sql-bind_param(:out_cursor,$out_cursor, {ora_type =
DBD::Oracle::ORA_RSET()});
$sql-execute;
TMH::dbDisconnect(*LOGFILE, $dbh);
Thilo Planz
[EMAIL PROTECTED] To: Denesa K Shaw [EMAIL
PROTECTED]
ax.co.jpcc: dbi-users@perl.org
Subject: Re: Calling Stored
Procedure using REF CURSORS
04/17/2005 07:21
PM
Denesa,
(cc to dbi-users, hope you don't mind)
glad it worked.
Now I'm trying to close the
cursor, Would I close the cursor similar to the code below (does not
work
by the way)?
I don't really understand that code below...
According to the DBD::Oracle docs, you have to close a ref cursor like
so:
my $sql = $conn-prepare('BEGIN close :curref; END;');
$sql-bind_param(:curref, $sth, {ora_type =
DBD::Oracle::ORA_RSET()});
$sql-execute;
( $sth is the ref cursor )
There was recently a discussion on this mailing list, whether this is
really necessary.
Someone, who seemed to know what they were talking about, claimed that
once you release the parent statement handle (the one that produced the
cursor), the ref cursor will also be freed.
That would be nice.
Has a final verdict on this been reached ?
Thilo
Re: Calling Stored Procedure using REF CURSORS
On 4/18/05, Denesa K Shaw [EMAIL PROTECTED] wrote: DBI::db=HASH(0x2035aef0)-disconnect invalidates 1 active statement handle (either destroy statement handles or call finish on them before disconnecting) Well, you need either destroy statement handles or call finish on them before disconnecting. Something like: $func-finish; after $func-execute and $sql-finish after $sql-execute. There's nothing wrong with that: it is a warning that maybe you would prefer to be more explicit with dismissing the statements. Regards, Adriano.
Re: Calling Stored Procedure using REF CURSORS
I have put the $func-finish; after the execute .. for the record after I inserted the code to loop through my cursor, I stopped getting the error. Thanks for all your help! Adriano Ferreira [EMAIL PROTECTED] To: Denesa K Shaw [EMAIL PROTECTED] ail.com cc: Subject: Re: Calling Stored Procedure using REF CURSORS 04/18/2005 02:04 PM Please respond to Adriano Ferreira On 4/18/05, Denesa K Shaw [EMAIL PROTECTED] wrote: DBI::db=HASH(0x2035aef0)-disconnect invalidates 1 active statement handle (either destroy statement handles or call finish on them before disconnecting) Well, you need either destroy statement handles or call finish on them before disconnecting. Something like: $func-finish; after $func-execute and $sql-finish after $sql-execute. There's nothing wrong with that: it is a warning that maybe you would prefer to be more explicit with dismissing the statements. Regards, Adriano.
disconnect invalidates 1 active statement handle when closing cursor
I also called $func-finish; prior to disconnecting and I still got the
error.
Denesa Shaw
713-207-5928
[EMAIL PROTECTED]
- Forwarded by Denesa K Shaw/ADM/Corp on 04/18/2005 10:01 AM -
Denesa K Shaw
To: [EMAIL PROTECTED]
04/18/2005 09:44 cc: dbi-users@perl.org
AM Subject: disconnect invalidates
1 active statement handle when
closing cursor
I turned on the Tracing at got this.
2005-04-18 09:34:21 Connected to Oracle [DBI:Oracle:TMHP2] Successfully...
DBI::db=HASH(0x2035ba68) trace level set to 0x0/9 (DBI @ 0x0/0) in DBI
1.45-ithread (p
id 679972)
- prepare for DBD::Oracle::db (DBI::db=HASH(0x20358688)~0x2035ba68 '
BEGIN
Package.Procedure(:p1,:out_cursor);
END;
') thr#20019bb8
dbih_setup_handle(DBI::st=HASH(0x2035bb70)=DBI::st=HASH(0x2035bc54),
DBD::Oracle::st,
2035bb7c, Null!)
dbih_make_com(DBI::db=HASH(0x2035ba68), 2035c398, DBD::Oracle::st, 208,
0) thr#20019bb
8
dbih_setup_attrib(DBI::st=HASH(0x2035bc54), Err,
DBI::db=HASH(0x2035ba68)) SCALAR(0x20
19948c) (already defined)
dbih_setup_attrib(DBI::st=HASH(0x2035bc54), State,
DBI::db=HASH(0x2035ba68)) SCALAR(0x
201994ec) (already defined)
dbih_setup_attrib(DBI::st=HASH(0x2035bc54), Errstr,
DBI::db=HASH(0x2035ba68)) SCALAR(0
x201994bc) (already defined)
dbih_setup_attrib(DBI::st=HASH(0x2035bc54), TraceLevel,
DBI::db=HASH(0x2035ba68)) 9 (a
lready defined)
dbih_setup_attrib(DBI::st=HASH(0x2035bc54), FetchHashKeyName,
DBI::db=HASH(0x2035ba68)
) 'NAME' (already defined)
dbih_setup_attrib(DBI::st=HASH(0x2035bc54), HandleSetErr,
DBI::db=HASH(0x2035ba68)) un
def (not defined)
dbih_setup_attrib(DBI::st=HASH(0x2035bc54), HandleError,
DBI::db=HASH(0x2035ba68)) und
ef (not defined)
dbd_preparse scanned 2 distinct placeholders
OCIHandleAlloc(20395078,20471298,OCI_HTYPE_STMT,0,0)=SUCCESS
OCIStmtPrepare(203acec0,203a4f08,'
BEGIN
Package.Procedure(:p1,:out_cursor);
END;
',96,1,0)=SUCCESS
OCIAttrGet(203acec0,OCI_HTYPE_STMT,2047129c,0,24,203a4f08)=SUCCESS
dbd_st_prepare'd sql BEGIN (pl1, auto_lob1, check_sql1)
dbd_describe skipped for BEGIN
- prepare= DBI::st=HASH(0x2035bb70) at getdata.pl line 69
- bind_param for DBD::Oracle::st (DBI::st=HASH(0x2035bb70)~0x2035bc54
':p1' '50401559
2131100.x12') thr#20019bb8
bind :p1 == '504015592131100.x12' (type 0)
rebinding :p1 (not-utf8, ftype 1, csid 0, csform 0, inout 0)
bind :p1 == '504015592131100.x12' (size 19/20/0, ptype 4, otype 1)
bind :p1 == '504015592131100.x12' (size 19/19, otype 1, indp 0,
at_exec 1)
OCIBindByName(203acec0,204048ec,203a4f08,:p1,3,203
c2808,19,1,204048fe,0,204048fc
,0,0,2)=SUCCESS
OCIBindDynamic(203acb98,203a4f08,204048c8,2023ab70,204048c8,2023ab7c)=SUCCESS
OCIAttrGet(203acb98,OCI_HTYPE_BIND,204048d8,0,31,203a4f08)=SUCCESS
bind :p1 == '504015592131100.x12' (in, not-utf8, csid 1-0-1,
ftype 1, csform 0-
0, maxlen 19, maxdata_size 0)
OCIAttrSet(203acb98,OCI_HTYPE_BIND,2ff2240a,0,31,203a4f08)=SUCCESS
- bind_param= 1 at getdata.pl line 70
- bind_param_inout for DBD::Oracle::st
(DBI::st=HASH(0x2035bb70)~0x2035bc54 ':out_cur
sor' SCALAR(0x2034c338) 0 HASH(0x2035bc48)) thr#20019bb8
bind :out_cursor == undef (type 0, inout 0x2034c338, maxlen 0,
attribs: HASH(0x203
5bc48))
rebinding :out_cursor (not-utf8, ftype 116, csid 0, csform 0, inout
1)
bind :out_cursor done with ftype 116
- bind_param_inout= 1 at getdata.pl line 71
- execute for DBD::Oracle::st (DBI::st=HASH(0x2035bb70)~0x2035bc54)
thr#20019bb8
dbd_st_execute BEGIN (out1, lob0)...
bind :out_cursor - allocating new sth...
OCIHandleAlloc(20395078,20471320,OCI_HTYPE_STMT,0,0)=SUCCESS
OCIBindByName(203acec0,2047131c,203a4f08,:out_cursor,11,20471320,0,116,0,0,0,0,0
,0)=SUCCESS
FETCH DISPATCH (DBI::db=HASH(0x2035ba68) rc2/3 @2 g0 ima404
pid#679972) at /u
sr/opt/perl5/lib/site_perl/5.8.0/aix-thread-multi/DBI.pm line 1143 via
FETCH= 'DBD::Oracle::db' ('ImplementorClass' from cache) at
/usr/opt/perl5/lib/site
_perl/5.8.0/aix-thread-multi/DBI.pm line 1143 via getdata.pl line 72
dbih_setup_handle(DBI::st=HASH(0x203583ac)=DBI::st=HASH(0x2035bc48),
DBD::Oracle::st,
2035bb10, Null!)
dbih_make_com(DBI::db=HASH(0x2035ba68), 2035c398, DBD::Oracle::st, 208,
0) thr#20019bb
8
Describe table
I'm using DBI and DBD::Oracle. I'd like to be able to describe a table, but 'describe table' fails no matter how I try to pass it to DBI. I feel certain that this is a FAQ and so apologise in advance. I have tried to track down an answer, but describe and table are hard words to seach for. Can anyone help me out? I just want the info describing the table that I can see in sqlplus. Mike Scott QA Software Developer BBC News Interactive White City London UK +44 20875 27288 http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this.
RE: Describe table
Describe is a SQL*Plus command, not SQL. If you want to see the columns and data types in a table, select from either DBA_TABLES, ALL_TABLES, or USER_TABLES. - Ron Reidy Lead DBA Array BioPharma, Inc. -Original Message- From: Mike Scott [mailto:[EMAIL PROTECTED] Sent: Monday, April 18, 2005 11:50 AM To: dbi-users@perl.org Subject: Describe table I'm using DBI and DBD::Oracle. I'd like to be able to describe a table, but 'describe table' fails no matter how I try to pass it to DBI. I feel certain that this is a FAQ and so apologise in advance. I have tried to track down an answer, but describe and table are hard words to seach for. Can anyone help me out? I just want the info describing the table that I can see in sqlplus. Mike Scott QA Software Developer BBC News Interactive White City London UK +44 20875 27288 http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. This electronic message transmission is a PRIVATE communication which contains information which may be confidential or privileged. The information is intended to be for the use of the individual or entity named above. If you are not the intended recipient, please be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. Please notify the sender of the delivery error by replying to this message, or notify us by telephone (877-633-2436, ext. 0), and then delete it from your system.
RE: Describe table
I don't have it in front of me, but I know that there are several SQL scripts out there that can duplicate the results of the SQL*Plus DESCRIBE command. Google for oracle +describe and you find a bundle. HTH, Mike -Original Message- From: Reidy, Ron [mailto:[EMAIL PROTECTED] Sent: Monday, April 18, 2005 11:10 AM To: Mike Scott; dbi-users@perl.org Subject: RE: Describe table Describe is a SQL*Plus command, not SQL. If you want to see the columns and data types in a table, select from either DBA_TABLES, ALL_TABLES, or USER_TABLES. - Ron Reidy Lead DBA Array BioPharma, Inc. -Original Message- From: Mike Scott [mailto:[EMAIL PROTECTED] Sent: Monday, April 18, 2005 11:50 AM To: dbi-users@perl.org Subject: Describe table I'm using DBI and DBD::Oracle. I'd like to be able to describe a table, but 'describe table' fails no matter how I try to pass it to DBI. I feel certain that this is a FAQ and so apologise in advance. I have tried to track down an answer, but describe and table are hard words to seach for. Can anyone help me out? I just want the info describing the table that I can see in sqlplus. Mike Scott QA Software Developer BBC News Interactive White City London UK +44 20875 27288 http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. This electronic message transmission is a PRIVATE communication which contains information which may be confidential or privileged. The information is intended to be for the use of the individual or entity named above. If you are not the intended recipient, please be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. Please notify the sender of the delivery error by replying to this message, or notify us by telephone (877-633-2436, ext. 0), and then delete it from your system.
Re: Describe table
DESCribe is a SQL*Plus command. You can probably find what you are looking for by selecting from sys.all_tab_columns. There may be a DBA view that does the same thing, but I'm not up on them. HTH, Dave On Apr 18, Mike Scott scribed: I'm using DBI and DBD::Oracle. I'd like to be able to describe a table, but 'describe table' fails no matter how I try to pass it to DBI. I feel certain that this is a FAQ and so apologise in advance. I have tried to track down an answer, but describe and table are hard words to seach for. Can anyone help me out? I just want the info describing the table that I can see in sqlplus. Mike Scott QA Software Developer BBC News Interactive White City London UK +44 20875 27288 http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this.
RE: Install Issues With Perl DBD For Informix
The saga continues. Does anyone recogize the error below. We have reinstalled the 32 bit SDK client and attempted to compile the DBD module. *** ExtUtils::AutoInstall version 0.61 *** Checking for dependencies... [Core Features] - DBI ...loaded. (1.48 = 1.38) [High Resolution Timing] - Time::HiRes ...loaded. (1.66) [POD Format Testing] - Test::Pod ...loaded. (1.20) *** ExtUtils::AutoInstall configuration finished. Subroutine main::WriteMakefile redefined at /opt/perl5/lib/site_perl/5.8.6/ExtUtils/AutoInstall.pm line 487. Configuring IBM Informix Database Driver for Perl DBI Version 2005.01 (2005-03-14) (aka DBD::Informix) You are using DBI version 1.48 and Perl version 5.008006 Remember to actually read the README file! Perl: perl v5.008006 PA-RISC2.0 dl_hpux.xs System: hp-ux l02 b.11.11 u 9000800 135901537 unlimited-user license Using INFORMIXDIR=/home/informix/iif2000/ids_9.40_FC3 and ESQL/C compiler esql Using IBM Informix CSDK Version 2.81, IBM Informix-ESQL Version 9.53.HC2 from /home/informix/iif2000/ids_9.40_FC3 Beware: DBD::Informix is not yet aware of all the new IUS data types. Assert macro will be disabled! lib/DBD/Informix/Defaults.pm written OK esqlvrsn.h written OK esqlinfo.h written OK Testing whether your Informix test environment will work... gcc: +DS2.0: No such file or directory gcc: +DA1.1: No such file or directory Failed to compile esqltest.ec to esqltest.o # Looks like your test died before it could output anything. Any help would be greatly appreciated. Thanks, Cory -Original Message- From: Jonathan Leffler [mailto:[EMAIL PROTECTED] Sent: Thursday, April 07, 2005 10:28 PM To: Cory Cox Cc: dbi-users@perl.org; Guardian of DBD::Informix Subject: Re: Install Issues With Perl DBD For Informix Cory Cox wrote: Jonathan, Q1 * Version of IDS (or SE, XPS, OnLine) - though that is not going to material this time. Q1A - The database server is running on another machine on the network. OK - it doesn't matter. Q2 This is the output of 'perl Makefile.PL' for DBD::Informix Perl: perl v5.008006 PA-RISC2.0 dl_hpux.xs System: hp-ux l02 b.11.11 u 9000800 135901537 unlimited-user license Using INFORMIXDIR=/home/harbinger/tle/6_0/odbcHPUX and ESQL/C compiler esql Using IBM Informix CSDK Version 2.81, IBM Informix-ESQL Version 9.53.FC1 from /home/harbinger/tle/6_0/odbcHPUX So, you're using CSDK 2.81.FC1, not 2.81.HC1 as previously asserted. That letter is all-important - FC1 is a 64-bit version of CSDK, but your Perl and GCC by default use 32-bit, and we haven't worked out how to turn on a 64-bit compilation. (This is why I ask to see the original output - it tells me answers to questions that people don't know the answer too.) [...snip...] Q3 export INFORMIXC=gcc -mpa-risc-2-0 esql -o esqlbasic -DESQLC_VERSION=953 esqlbasic.ec esqlc_v6.ec QA3 l02:/home/edi/wlsedi/perl/DBD-Informix-2005.01# sudo esql -c esqlbasic -DESQLC_VERSION=953 esqlbasic.ec esqlc_v6.ec Woah! sudo? Well, on your own head be it. But I don't like having to run compilations as root - and never do. Q4 l02:/home/edi/wlsedi/perl/DBD-Informix-2005.01# file $INFORMIXDIR/lib/esql/checkapi.o esqlbasic.o /home/harbinger/tle/6_0/odbcHPUX/lib/esql/checkapi.o: ELF-64 relocatable object file - PA-RISC 2.0 (LP64) esqlbasic.o:PA-RISC2.0 relocatable object Yes, it does help - a lot (though the CSDK version number tells the same story). As you can see, there's a huge difference between the file types. Clearly, checkapi.o is a 64-bit file; by inference, esqlbasic.o is not. Those two do not mix. Since the server is not even on the local machine, I'd simply go and get the 32-bit (2.81.UC2) version of CSDK installed and run with that. You might also remember that one of the very first things we did was modify (a copy of) the esql script to remove flags peculiar to the HP C compiler. You might think it worthwhile to make a copy of the esql script in $INFORMIXDIR/bin, and then edit the file there, instead of making a copy in DBD::Informix's build directory. OTOH, it may still be better to work out the kinks on a local copy before modifying the version in $INFORMIXDIR/bin. You need to do this to avoid the problems with GCC wittering about +DS2.0 not being found. -- Jonathan Leffler ([EMAIL PROTECTED], [EMAIL PROTECTED]) #include disclaimer.h Guardian of DBD::Informix v2005.01 -- http://dbi.perl.org/
Re: Describe table
On 04/18/2005 10:49 AM, Mike Scott said: I'm using DBI and DBD::Oracle. I'd like to be able to describe a table, but 'describe table' fails no matter how I try to pass it to DBI. I feel certain that this is a FAQ and so apologise in advance. I have tried to track down an answer, but describe and table are hard words to seach for. Can anyone help me out? I just want the info describing the table that I can see in sqlplus. You've gotten several responses that query Oracle metadata tables. A more portable method is to use the DBI methods. http://search.cpan.org/dist/DBI/DBI.pm#Catalog_Methods Search for the individual method names (e.g., column_info) for more details. -- 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: Install Issues With Perl DBD For Informix
On 4/18/05, Cory Cox [EMAIL PROTECTED] wrote:
The saga continues. Does anyone recogize the error below.
Oh yes...
We have reinstalled the 32 bit SDK client and attempted to compile the DBD
module.
*** ExtUtils::AutoInstall version 0.61
*** Checking for dependencies...
[Core Features]
- DBI ...loaded. (1.48 = 1.38)
[High Resolution Timing]
- Time::HiRes ...loaded. (1.66)
[POD Format Testing]
- Test::Pod ...loaded. (1.20)
*** ExtUtils::AutoInstall configuration finished.
Subroutine main::WriteMakefile redefined at
/opt/perl5/lib/site_perl/5.8.6/ExtUtils/AutoInstall.pm line 487.
Configuring IBM Informix Database Driver for Perl DBI Version 2005.01
(2005-03-14) (aka DBD::Informix)
You are using DBI version 1.48 and Perl version 5.008006
Remember to actually read the README file!
Perl: perl v5.008006 PA-RISC2.0 dl_hpux.xs
System: hp-ux l02 b.11.11 u 9000800 135901537 unlimited-user license
Using INFORMIXDIR=/home/informix/iif2000/ids_9.40_FC3 and ESQL/C compiler esql
Using IBM Informix CSDK Version 2.81, IBM Informix-ESQL Version 9.53.HC2 from
/home/informix/iif2000/ids_9.40_FC3
Beware: DBD::Informix is not yet aware of all the new IUS data types.
Assert macro will be disabled!
lib/DBD/Informix/Defaults.pm written OK
esqlvrsn.h written OK
esqlinfo.h written OK
Testing whether your Informix test environment will work...
gcc: +DS2.0: No such file or directory
gcc: +DA1.1: No such file or directory
Failed to compile esqltest.ec to esqltest.o
# Looks like your test died before it could output anything.
ESQL/C is configured to use the HP ANSI C compiler. Those options are
meaningful to that compiler and not to GCC.
To work around this, you are going to need to:
1, Add the DBD::Informix directory to your PATH ahead of $INFORMIXDIR/bin.
2. Copy $INFORMIXDIR/bin/esql to the DBD::Informix directory.
3. Edit it so that the ANSI C compiler options are translated to
equivalent GCC options.
You can decide, instead, to omit them if the GCC compiler will produce
the correct code.
FYI: I spent a certain amount of time building a 64-bit GCC compiler
for HP-UX 11.11 on Friday and today. It's a somewhat painful process.
One area to watch for is that the object file test fails. However,
it seems that the trouble is simply that the object file contains a
time stamp or thereabouts:
echo int main(void){return 0;} x.c
cc -c x.c
mv x.o x1.o
sleep 3
cc -c x.c
mv x.o x2.o
cmp -l x[12].o
The two output files differ (one or two bytes for me). If you do 'cc
-o x1.o x.c' and ' cc -o x2.o x.c', you get more differences.
I happened to be building a 64-bit GCC; I've not yet worked out how to
make it generate 32-bit code (but it was far from being my only
occupation today). Ah well, ...
Any help would be greatly appreciated.
Thanks,
Cory
-Original Message-
From: Jonathan Leffler [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 07, 2005 10:28 PM
To: Cory Cox
Cc: dbi-users@perl.org; Guardian of DBD::Informix
Subject: Re: Install Issues With Perl DBD For Informix
Cory Cox wrote:
Jonathan,
Q1
* Version of IDS (or SE, XPS, OnLine) - though that is not going to
material this time.
Q1A - The database server is running on another machine on the network.
OK - it doesn't matter.
Q2
This is the output of 'perl Makefile.PL' for DBD::Informix
Perl: perl v5.008006 PA-RISC2.0 dl_hpux.xs
System: hp-ux l02 b.11.11 u 9000800 135901537 unlimited-user license
Using INFORMIXDIR=/home/harbinger/tle/6_0/odbcHPUX and ESQL/C compiler esql
Using IBM Informix CSDK Version 2.81, IBM Informix-ESQL Version 9.53.FC1
from /home/harbinger/tle/6_0/odbcHPUX
So, you're using CSDK 2.81.FC1, not 2.81.HC1 as previously asserted.
That letter is all-important - FC1 is a 64-bit version of CSDK, but your
Perl and GCC by default use 32-bit, and we haven't worked out how to
turn on a 64-bit compilation. (This is why I ask to see the original
output - it tells me answers to questions that people don't know the
answer too.)
[...snip...]
Q3
export INFORMIXC=gcc -mpa-risc-2-0
esql -o esqlbasic -DESQLC_VERSION=953 esqlbasic.ec esqlc_v6.ec
QA3
l02:/home/edi/wlsedi/perl/DBD-Informix-2005.01# sudo esql -c esqlbasic
-DESQLC_VERSION=953 esqlbasic.ec esqlc_v6.ec
Woah! sudo? Well, on your own head be it. But I don't like having to
run compilations as root - and never do.
Q4
l02:/home/edi/wlsedi/perl/DBD-Informix-2005.01# file
$INFORMIXDIR/lib/esql/checkapi.o esqlbasic.o
/home/harbinger/tle/6_0/odbcHPUX/lib/esql/checkapi.o: ELF-64 relocatable
object file - PA-RISC 2.0 (LP64)
esqlbasic.o:PA-RISC2.0 relocatable object
Yes, it does help - a lot (though the CSDK version number tells the same
story). As you can see, there's a huge difference between the file
types. Clearly, checkapi.o is a 64-bit file; by inference, esqlbasic.o
is not. Those two do not mix.
Since
