Re: error during DBD::Oracle installation (was: error during DBI installation)

------=_Part_6037_22545193.1207194199772
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Looks like time to get the development stuff you need installed. The log
file says:

Reading /export/home/oracle/product/9Iclient/precomp/lib/env_precomp .mk

Attempting to discover Oracle OCI build rules
gcc -c -I. -I/export/home/oracle/product/9Iclient/precomp/public
-I/export/home/oracle/product/9Iclient/rdbms/public
-I/export/home/oracle/product/9Iclient/rdbms/demo
-I/export/home/oracle/product/9Iclient/plsql/public
-I/export/home/oracle/product/9Iclient/network/public
-I/export/home/oracle/product/9Iclient/rdbms/demo
-I/export/home/oracle/product/9Iclient/rdbms/demo
-I/opt/ActivePerl-5.8/lib/site_perl/5.8.7/sun4-solaris-threa d-multi/auto/DBI/
-D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -DUSE_SITECUSTOMIZE
-DNO_HASH_SEED -DBUILT_BY_ACTIVESTATE -fno-strict-aliasing -pipe
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O -DVERSION=\"1.16\"
-DXS_VERSION=\"1.16\" -fPIC
"-I/opt/ActivePerl-5.8/lib/5.8.7/sun4-solaris-thread-multi/C ORE"
-Wall -Wno-comment -DUTF8_SUPPORT -DNEW_OCI_INIT
-DORA_OCI_VERSION=\"9.2.0.1\" DBD_ORA_OBJ.c
by executing: [make -f
/export/home/oracle/product/9Iclient/precomp/demo/proc/demo_ proc.mk
build ECHODO=echo ECHO=echo GENCLNTSH='echo genclntsh' CC=true
OPTIMIZE= CCFLAGS= EXE=DBD_ORA_EXE OBJS=DBD_ORA_OBJ.o]
Oracle oci build command:
[true -o DBD_ORA_EXE DBD_ORA_OBJ.o
-L/export/home/oracle/product/9Iclient/lib/ -lclntsh `cat
/export/home/oracle/product/9Iclient/lib/ldflags` `cat
/export/home/oracle/product/9Iclient/lib/sysliblist`
-R/export/home/oracle/product/9Iclient/lib -laio -lposix4 -lm
-lthread]

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.
*********************************************************


It also says:

*** 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?)


So, which part of that is too hard to understand? You're running on ancient
Solaris (2.6 - not supported), and you have a fairly old version of Oracle
client -- did you check whether it is supported.

And DBD does not mean DBD::Oracle - there are lots of DBD::DBMS drivers.


On Wed, Apr 2, 2008 at 1:08 PM, Sasidharan, Radhakrishnan <
Radhakrishnan.Sasidharan@xerox.com> wrote:

> We are trying to run the DBD installation on a unix server. We are able to
> do the Makefile.PL but it failed on the subsequent make. Attached is the
> output of the two commands. Kindly help us to resolve this issue.
>



--
Jonathan Leffler #include
Guardian of DBD::Informix - v2008.0229 - http://dbi.perl.org
"Blessed are we who can laugh at ourselves, for we shall never cease to be
amused."

------=_Part_6037_22545193.1207194199772--

Blank inserted with varchar copy using prepare

Hi.

I am using Perl 5.8.8 on SunOS pnc 5.8 with Informix (Server Version
9.30) and DBI 1.51 and DBD::Informix 2005.2.

I try to copy a list of tables using DBI. I have found that a certain
column declared as varchar(64) is copied incorrectly when it contains an
empty string. The value in the target location is a string containing
one space instead of being empty.

Here is a code fragment copied from the actual script:

foreach my $tb ( @$table_list )
{
my ( $sel ) =3D $from_dbh->prepare( "SELECT * FROM $tb" );
$sel->execute();
my ( $cols, $val_str ) =3D ( $sel->{NUM_OF_FIELDS}, "()" );
$val_str =3D "(" . ("?," x ($cols-1)) . "?)" if ( $cols>0 );
my ( $ins ) =3D $to_dbh->prepare( "INSERT INTO $tb VALUES" . $val_str
);
my ( $fetch_tuple_sub ) =3D sub { $sel->fetchrow_arrayref };
my @tuple_status;
my ( $rc ) =3D $ins->execute_for_fetch( $fetch_tuple_sub,
\@tuple_status );
my ( @errors ) =3D grep { ref $_ } @tuple_status;
$sel->finish();
$ins->finish();
}

Is this a known bug? Is there a way I can get this code to faithfully
reproduce the data including blank strings of type varchar(64)?

-Will



- - - - - Appended by Scientific Atlanta, a Cisco company - - - - - =

This e-mail and any attachments may contain information which is confiden=
tial,
proprietary, privileged or otherwise protected by law. The information is=
solely
intended for the named addressee (or a person responsible for delivering =
it to
the addressee). If you are not the intended recipient of this message, yo=
u are
not authorized to read, print, retain, copy or disseminate this message o=
r any
part of it. If you have received this e-mail in error, please notify the =
sender
immediately by return e-mail and delete it from your computer.

Fwd: Blank inserted with varchar copy using prepare

------=_Part_5408_8005666.1207270249273
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Bother.

---------- Forwarded message ----------
From: Jonathan Leffler
Date: Thu, Apr 3, 2008 at 5:49 PM
Subject: Re: Blank inserted with varchar copy using prepare
To: "Rutherdale, Will"




On Thu, Apr 3, 2008 at 3:34 PM, Rutherdale, Will
wrote:

> I am using Perl 5.8.8 on SunOS pnc 5.8 with Informix (Server Version
> 9.30) and DBI 1.51 and DBD::Informix 2005.2.
>
> I try to copy a list of tables using DBI. I have found that a certain
> column declared as varchar(64) is copied incorrectly when it contains an
> empty string. The value in the target location is a string containing
> one space instead of being empty.
>
> Here is a code fragment copied from the actual script:
>
> foreach my $tb ( @$table_list )
> {
> my ( $sel ) = $from_dbh->prepare( "SELECT * FROM $tb" );
> $sel->execute();
> my ( $cols, $val_str ) = ( $sel->{NUM_OF_FIELDS}, "()" );
> $val_str = "(" . ("?," x ($cols-1)) . "?)" if ( $cols>0 );
> my ( $ins ) = $to_dbh->prepare( "INSERT INTO $tb VALUES" . $val_str
> );
> my ( $fetch_tuple_sub ) = sub { $sel->fetchrow_arrayref };
> my @tuple_status;
> my ( $rc ) = $ins->execute_for_fetch( $fetch_tuple_sub,
> \@tuple_status );
> my ( @errors ) = grep { ref $_ } @tuple_status;
> $sel->finish();
> $ins->finish();
> }
>
> Is this a known bug? Is there a way I can get this code to faithfully
> reproduce the data including blank strings of type varchar(64)?
>

Perl 5.10.0 on Solaris 10, DBI 1.604, DBD::Informix 2008.0229, ESQL/C
3.00.UC2.

#!/bin/perl -w
use strict;
use DBD::Informix::TestHarness;

my($dbh) = connect_to_test_database({RaiseError => 1});

my($tbl1) = "dbd_ix_something_1";
my($tbl2) = "dbd_ix_something_2";
$dbh->do("create {temp} table $tbl1 ( col VARCHAR(64) NOT NULL)");
$dbh->do("create {temp} table $tbl2 ( col VARCHAR(64) NOT NULL)");
$dbh->do("INSERT INTO $tbl1 VALUES('a')"); # Non-blank VARCHAR
$dbh->do("INSERT INTO $tbl1 VALUES(' ')"); # Single-blank VARCHAR
$dbh->do("INSERT INTO $tbl1 VALUES('')"); # Empty (non-null) VARCHAR

my($from_dbh) = $dbh;
my($to_dbh) = $dbh;

my($table_list) = [ $tbl1 ];

foreach my $tb ( @$table_list )
{
my ( $sel ) = $from_dbh->prepare( "SELECT * FROM $tb" );
$sel->execute();
my ( $cols, $val_str ) = ( $sel->{NUM_OF_FIELDS}, "()" );
$val_str = "(" . ("?," x ($cols-1)) . "?)" if ( $cols>0 );
my ($new) = $tb;
$new =~ s/1/2/;
my ( $ins ) = $to_dbh->prepare( "INSERT INTO $new VALUES" . $val_str);
my ( $fetch_tuple_sub ) = sub { $sel->fetchrow_arrayref };
my @tuple_status;
my ( $rc ) = $ins->execute_for_fetch( $fetch_tuple_sub,
\@tuple_status );
my ( @errors ) = grep { ref $_ } @tuple_status;
$sel->finish();
$ins->finish();
}

Runs OK - first time.

Black JL: perl will.sciatl.pl
# DBI->connect('dbi:Informix:stores', '', '');
# Connect Attribute: RaiseError => 1
# Connect Attribute: ChopBlanks => 1
Black JL: sqlcmd -d stores -F unload -e 'select * from dbd_ix_something_1'
a|
|
\ |
Black JL: sqlcmd -d stores -F unload -e 'select * from dbd_ix_something_2'
a|
|
\ |
Black JL:

Basically, this code is copying the single blank and the empty but non-null
string accurately.

So, in the absence of a reproduction with DBD::Informix 2008.0229, I'm going
to claim "no longer a problem". There have been issues in the handling of
VARCHAR, both in ESQL/C and in DBD::Informix on occasion, but not
self-evidently on this occasion.

I assume there's a reason why you can't do:
INSERT INTO dbase2:tablename SELECT * FROM dbase1:tablename;
Probably related to error -999 (not implemented yet).

--
Jonathan Leffler #include
Guardian of DBD::Informix - v2008.0229 - http://dbi.perl.org
"Blessed are we who can laugh at ourselves, for we shall never cease to be
amused."



--
Jonathan Leffler #include
Guardian of DBD::Informix - v2008.0229 - http://dbi.perl.org
"Blessed are we who can laugh at ourselves, for we shall never cease to be
amused."

------=_Part_5408_8005666.1207270249273--

RE: Blank inserted with varchar copy using prepare

I confirmed the problem occurs on another machine I was wondering about.

I tried installing the latest DBI and DBD::Informix. DBI was okay, but
DBD::Informix started out giving me the following warnings on 'perl
Makefile.PL':

----
Using INFORMIX-ESQL Version 9.21.UC1 from /usr/informix
Please upgrade to a more recent version of ClientSDK.
DBD::Informix will probably work, but that is not guaranteed.
Note that bug RT#13708 (IBM CQ bug idsdb00139040) may affect you.
In particular, if test t/t931varchar.t detects problems, consider an
upgrade to CSDK 3.00 or later - it seems to be fixed there.
----

That sounds like it could be related to my problem. Do you think I
could report to management where I work that this known bug might be
causing the problem, and that CSDK 3.00 is recommended?

I also happened to fail in 'make test' on DBD::Informix, but I'll have
to get back to you later on that.

-Will




- - - - - Appended by Scientific Atlanta, a Cisco company - - - - - =

This e-mail and any attachments may contain information which is confiden=
tial,
proprietary, privileged or otherwise protected by law. The information is=
solely
intended for the named addressee (or a person responsible for delivering =
it to
the addressee). If you are not the intended recipient of this message, yo=
u are
not authorized to read, print, retain, copy or disseminate this message o=
r any
part of it. If you have received this e-mail in error, please notify the =
sender
immediately by return e-mail and delete it from your computer.

Re: Blank inserted with varchar copy using prepare

------=_Part_10284_21407766.1207339236244
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Fri, Apr 4, 2008 at 12:03 PM, Rutherdale, Will <
Will.Rutherdale@sciatl.com> wrote:

> I confirmed the problem occurs on another machine I was wondering about.
>
> I tried installing the latest DBI and DBD::Informix. DBI was okay, but
> DBD::Informix started out giving me the following warnings on 'perl
> Makefile.PL':
>
> ----
> Using INFORMIX-ESQL Version 9.21.UC1 from /usr/informix
> Please upgrade to a more recent version of ClientSDK.
> DBD::Informix will probably work, but that is not guaranteed.
> Note that bug RT#13708 (IBM CQ bug idsdb00139040) may affect you.
> In particular, if test t/t931varchar.t detects problems, consider an
> upgrade to CSDK 3.00 or later - it seems to be fixed there.
> ----
>

ESQL/C 9.21 was released as part of CSDK 2.30 in May 1999. I suppose it is
sad to make software retire before its tenth birthday, but in this case, it
is somewhat past time.



> That sounds like it could be related to my problem. Do you think I
> could report to management where I work that this known bug might be
> causing the problem, and that CSDK 3.00 is recommended?
>

That problem - RT#13708 - is to do with LVARCHAR and not VARCHAR.

Well, I tried to install CSDK 2.30 on my Solaris 10 machine. The install
worked; the software didn't. The network connections wouldn't work (that
appears to be a generic problem for my machine - on later testing; probably
needs a reboot), but the stream connections did. The compilation of
DBD::Informix 2008.0229 went fine, but the test failed horribly because it
couldn't find a symbol ifx_var_freevar().

Dropping back to DBD::Informix 2003.04, the compilation worked and tests ra=
n
mostly OK (IUS tests were dubious, but VARCHAR isn't an IUS feature).

Using the previously generated test script, I got erroneous output from the
VARCHAR data. So, the problem could be in CSDK 2.30 or in DBD::Informix
2003.04. Checking with a more recent CSDK (3.00.UC2), it appears that
DBD::Informix 2003.04 was not handling VARCHAR properly; it introduces the
blanks. So, between that version and 2008.0229, I fixed the problem,
somehow.

Looking at the ChangeLog, I find:

2005-07-28: Logged bug B173776 against ESQL/C - SQL DESCRIPTORS mishandle
zero-length non-null VARCHAR values. This prevents a solution
to a problem report from V=E0clav Ovs=EDk .

This would probably be the issue - you'd need a version of DBD::Informix
later than 2005.02 and a version of CSDK released after that. The relevant
database reports that the bug was fixed in CSDK 2.90.xC4 - so you need a
version of CSDK at least that recent.


I also happened to fail in 'make test' on DBD::Informix, but I'll have
> to get back to you later on that.
>

If the trouble is 'ifx_var_freevar()', then that is a (now) known and 'will
not be fixed' problem. CSDK 2.30 (ESQL/C 9.21) is officially unsupported b=
y
DBD::Informix.

--=20
Jonathan Leffler #include
Guardian of DBD::Informix - v2008.0229 - http://dbi.perl.org
"Blessed are we who can laugh at ourselves, for we shall never cease to be
amused."

------=_Part_10284_21407766.1207339236244--

RE: Blank inserted with varchar copy using prepare

------_=_NextPart_001_01C89696.E373B6CD
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Thank you very much Jonathan for that tremendous amount of help. I'll have=
to digest what you've said, but it sounds like I need a newer DBD::Informi=
x and possibly a newer CSDK.

I got the same failure on my system with the missing ifx_var_freevar duri=
ng the 'make test'.

From what you said, I would need to install a new DBD::Informix (newer th=
an 2005.02, probably 2008.0229), and CSDK at least 2.90.xC4.

That is, I would need these fixes in order to solve the table copying the=
way I showed you using the prepare and execute loop. However I might be a=
ble to find a better way to copy the tables that curcumvents this problem. =
On the other hand, the bug would still be there and could affect other ope=
rations that read those varchar columns.

-Will


-----Original Message-----
From: Jonathan Leffler [mailto:jonathan.leffler@gmail.com]
Sent: Friday 04 April 2008 16:01
To: Rutherdale, Will
Cc: DBI Users Mailing List
Subject: Re: Blank inserted with varchar copy using prepare




On Fri, Apr 4, 2008 at 12:03 PM, Rutherdale, Will l.com> wrote:


I confirmed the problem occurs on another machine I was wondering about=
..

I tried installing the latest DBI and DBD::Informix. DBI was okay, but
DBD::Informix started out giving me the following warnings on 'perl
Makefile.PL':

----
Using INFORMIX-ESQL Version 9.21.UC1 from /usr/informix
Please upgrade to a more recent version of ClientSDK.
DBD::Informix will probably work, but that is not guaranteed.
Note that bug RT#13708 (IBM CQ bug idsdb00139040) may affect you.
In particular, if test t/t931varchar.t detects problems, consider an
upgrade to CSDK 3.00 or later - it seems to be fixed there.
----



ESQL/C 9.21 was released as part of CSDK 2.30 in May 1999. I suppose it=
is sad to make software retire before its tenth birthday, but in this case=
, it is somewhat past time.



That sounds like it could be related to my problem. Do you think I
could report to management where I work that this known bug might be
causing the problem, and that CSDK 3.00 is recommended?



That problem - RT#13708 - is to do with LVARCHAR and not VARCHAR.

Well, I tried to install CSDK 2.30 on my Solaris 10 machine. The instal=
l worked; the software didn't. The network connections wouldn't work (that=
appears to be a generic problem for my machine - on later testing; probabl=
y needs a reboot), but the stream connections did. The compilation of DBD:=
:Informix 2008.0229 went fine, but the test failed horribly because it coul=
dn't find a symbol ifx_var_freevar().

Dropping back to DBD::Informix 2003.04, the compilation worked and tests=
ran mostly OK (IUS tests were dubious, but VARCHAR isn't an IUS feature).

Using the previously generated test script, I got erroneous output from =
the VARCHAR data. So, the problem could be in CSDK 2.30 or in DBD::Informi=
x 2003.04. Checking with a more recent CSDK (3.00.UC2), it appears that DB=
D::Informix 2003.04 was not handling VARCHAR properly; it introduces the bl=
anks. So, between that version and 2008.0229, I fixed the problem, somehow=
..

Looking at the ChangeLog, I find:

2005-07-28: Logged bug B173776 against ESQL/C - SQL DESCRIPTORS mishandl=
e
zero-length non-null VARCHAR values. This prevents a soluti=
on
to a problem report from V=E0clav Ovs=EDk >.

This would probably be the issue - you'd need a version of DBD::Informix=
later than 2005.02 and a version of CSDK released after that. The relevan=
t database reports that the bug was fixed in CSDK 2.90.xC4 - so you need a =
version of CSDK at least that recent.




I also happened to fail in 'make test' on DBD::Informix, but I'll have
to get back to you later on that.



If the trouble is 'ifx_var_freevar()', then that is a (now) known and 'w=
ill not be fixed' problem. CSDK 2.30 (ESQL/C 9.21) is officially unsupport=
ed by DBD::Informix.

--
Jonathan Leffler #include
Guardian of DBD::Informix - v2008.0229 - http://dbi.perl.org
"Blessed are we who can laugh at ourselves, for we shall never cease to =
be amused."





- - - - - Appended by Scientific Atlanta, a Cisco company - - - - - =

This e-mail and any attachments may contain information which is confiden=
tial,
proprietary, privileged or otherwise protected by law. The information is=
solely
intended for the named addressee (or a person responsible for delivering =
it to
the addressee). If you are not the intended recipient of this message, yo=
u are
not authorized to read, print, retain, copy or disseminate this message o=
r any
part of it. If you have received this e-mail in error, please notify the =
sender
immediately by return e-mail and delete it from your computer.
------_=_NextPart_001_01C89696.E373B6CD--