The following code sets program configuration values to an Oracle table in our
software. These can potentially be long text fields, so the value datatype has
to be CLOB. My test data here is very short but still illustrates the problem.
sub SetConfigValue {
my($self,$var,$value) = @_;
$db->do('DELETE FROM config WHERE module = ? AND variable =
?',undef,$self->GetProperty('fqid'),$var);
my $st = $db->prepare_cached('INSERT INTO config (module, variable,
value) VALUES (?,?,?)');
$st->bind_param(1, $self->GetProperty('fqid'));
$st->bind_param(2, $var);
$st->bind_param(3, $value, {ora_type=>ORA_CLOB, ora_field=>'value'});
$st->execute;
# For debugging
my $st2 = $db->prepare('SELECT value FROM config WHERE module = ? AND variable =
?');
$st2->execute($self->GetProperty('fqid'),$var);
my $dbvalue = $st2->fetch->[0];
die "wtf: supposedly wrote '$value' to database but query returned
'$dbvalue'" if $dbvalue ne $value;
}
What's happening is that the CLOB bind param does not appear to be getting
rebound on successive runs of this routine. In this particular case one
variable gets set to 'KS' and the next one should be set to '1', but it instead
writes 'KS', which was the value from the *last* execution. After adding the
"For debugging" code to requery the database after writing the new value, this
is confirmed:
Fatal Error: wtf: supposedly wrote '1' to database but query returned 'KS'
I can't decipher why it's not resetting the value, or why it only does it at
this point (there were about 20 successful sets before it hits this erroneous
one). I've attached the complete trace log (level 9) -- perhaps someone more
apt at staring at OCI calls can figure it out.
--
Stephen Clouse <[EMAIL PROTECTED]>
Senior Programmer, IQ Coordinator Project Lead
The IQ Group, Inc. <http://www.theiqgroup.com/>
error.log.gz
PGP signature
