This is pretty much a continuation of my earlier question involving
getting the database to see NULL in a float column. Basically, I'm trying
to set some columns as undef in order to get them to be NULL. When I do
that, if I have executed my statement handle that does the insert once,
the second time I get a SEGV signal.
Here's what I'm doing:
I've instantiated an object which contains 3 database handles and 3
statement handles, amongst other things.
$record = Record->new();
$record->{dbh1} = DBI::connect...
$record->{dbh2} = DBI::connect...
$record->{dbh3} = DBI::connect...
$record->{sth1} = $record->{dbh1}->prepare( <<EOF
select * from owner.table1
where column1 = ?
EOF
);
$record->{sth2} = $record->{dbh2}->prepare( <<EOF
select * from owner.table2
where column1 = ? and column2 = ?
EOF
);
$record->{sth3} = $record->{dbh3}->prepare( <<EOF
insert into owner.table3
(column1, column2, column3, column4....)
values (?, ?, ?, ?.....)
EOF
);
Database handles 1 and 3 point to the same database. I did this because
Sybase was complaining that I was trying to use 2 statement handles on the
same database handle with AutoCommit turned off. I need AutoCommit on to
control commit/rollback.
After the main object is instantiated and the database handles and
statement handles are prepared, I instantiate a second object and third
object using Class:Struct. These represent the input and output records
I'm handling and the $record object is related to these 2 through a HAS-A
type relationship.
As I loop through the input file, I undef the input file object:
@{$record->{inObj}} = ();
Then fill the object using data from the input file
@{$record->{inObj}} = unpack($fmtout, pack($fmtin, $inrec));
Next the output object is undef'd and data from the input is mapped to the
output object... this is where I use the 1st and 2nd statement handles.
Finally, the output object is written to the database
$record->{sth3}->execute(@{$record->{outObj}}) or die...
$record->{sth3}->finish(); ###Put in to see if it would help the problem
And we repeat the procedure until all records are read.
As a debugging aid, I did a print on the object as an array and a dumper
as an object:
print join("::", @{$record->{outObj}}), "\n\n";
print Dumper($record->{outObj}), "\n\n";
The Dumpers look as follows:
$VAR1 = bless( [
20010321,
111,
'012345',
'NULL',
'NULL',
'NULL',
'NULL',
'0123',
'NULL',
967711234,
undef,
'000000000010000',
undef,
undef,
undef,
undef,
undef,
undef,
20010321,
'010',
'020',
1,
'ABDC',
20010321,
'ABCDEFGH'
], 'outObj' );
This is successfully inserted in the database just as I want. The print
join... statement generates 14 'Use of uninitialized value at...' warnings
when I would only expect 7, the number of undefs in the object.
The next time around, the dumper looks like:
$VAR1 = bless( [
20010321,
789,
'012345',
'NULL',
'NULL',
'NULL',
'NULL',
123456789,
undef,
undef,
'0000000000290000'
undef,
undef,
undef,
undef,
undef,
20010321,
'010',
'050',
2,
'EFGH',
20010321,
'XYZABCDQWE',
], 'outObj' );
This time around the print reports 7 'Use of uninitialized value at...' as
I would expect. However, the database insert immediately croaks and
part way through the Carp.pm routine it calls I get:
Signal SEGV @ test.pl line 129
Abort(coredump)
If I use "NULL" or something else other than undef, the program works fine
other than the float columns won't be set to NULL. I am totally baffled
as to why it'll work once and not a second time. It doesn't matter if the
first pass contains undefs or not, it simply fails if the statement handle
that inserts is executed at least once and a subsequent call passes an
undef.
I know what I've provided is probably a little sketchy, but it's the most
thorough description I can give w/o attaching ALL of the code. I'm just
hoping someone has run into this situation before or can see what it is
I'm missing.
Again, the system I'm on is a SunOS 5.6 box running the vendor's version
of Perl 5.00404/DBI 1.13/DBD::Sybase 0.21 and Sybase 11.1.1. I would like
to upgrade, but I do not think the client would permit this.
Thanks,
Curt Crandall
