------=_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-thread-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/CORE"
-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 <jonathan.leffler@gmail.com> #include <disclaimer.h>
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--

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.

------=_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 <jonathan.leffler@gmail.com>
Date: Thu, Apr 3, 2008 at 5:49 PM
Subject: Re: Blank inserted with varchar copy using prepare
To: "Rutherdale, Will" <Will.Rutherdale@sciatl.com>




On Thu, Apr 3, 2008 at 3:34 PM, Rutherdale, Will <Will.Rutherdale@sciatl.com>
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 <jonathan.leffler@gmail.com> #include <disclaimer.h>
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 <jonathan.leffler@gmail.com> #include <disclaimer.h>
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--