Is this a DBD::Ingres bug ?

Is this a DBD::Ingres bug ?

Post by Mark Buck » Thu, 21 Nov 2002 20:19:40



I have a generic script to copy data sets around different databases, ie
select from one table, insert into another.  I've got problems on ingres
with this.


on prepared insert statements that use place-holders, where one or more of
the values is null ( ie a perl undef 'value').
DBD::Oracle has no problem with the same statement, presumably because it
handles everything as strings.

I could live with that, but when I try to use the alternative workaround :-
$sth->bind_param($n, $array_of_values[$n-1], { TYPE =>
$sth_select->{TYPE}[$n] } to set the data_type from the data_type
'discovered'
from the original select statement DBD::Ingres throws an error for columns
with datatype 9 ( which is the date type ).  If I hard-code 12 as the type (
varchar )
everything works fine for char/varchar/date/ integer columns types  ( I
haven't checked floats yet ).

I've achieved a workaround, so I suppose the problem is 'solved', but it's
irritating that the column datatype returned by ingres in the $sth->{TYPE}
array is not valid
as the datatype to supply to bind_param in the optional %_attr parameter.

Cheers, Mark.

**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

 
 
 

Is this a DBD::Ingres bug ?

Post by Mark Buck » Thu, 21 Nov 2002 23:44:46


Thanks, Henrik.
If interfacing perl and C were not so tangled and twisted, I'd have a go
myself. !!!
Roll-on Perl 6 !
Mark.

-----Original Message-----

Sent: 20 November 2002 11:53
To: Mark Buckle


Subject: Re: Is this a DBD::Ingres bug ?


> I have a generic script to copy data sets around different databases, ie
> select from one table, insert into another.  I've got problems on ingres
> with this.


> on prepared insert statements that use place-holders, where one or more
> of the values is null ( ie a perl undef 'value').

> DBD::Oracle has no problem with the same statement, presumably because
> it handles everything as strings.

Correct. Ingres wants numbers to be numeric not strings.

> I could live with that, but when I try to use the alternative workaround
> :-
> $sth->bind_param($n, $array_of_values[$n-1], { TYPE =>
> $sth_select->{TYPE}[$n] } to set the data_type from the data_type
> 'discovered'

> from the original select statement DBD::Ingres throws an error for
> columns with datatype 9 ( which is the date type ).  If I hard-code 12
> as the type ( varchar )

> everything works fine for char/varchar/date/ integer columns types  ( I
> haven't checked floats yet ).

Thanks. Thats a bug in DBD::Ingres!

The relevant part of the code reads:
        switch (sql_type) {
        case SQL_INTEGER:
        case SQL_SMALLINT:
            type = 1; break;
        case SQL_FLOAT:
        case SQL_REAL:
        case SQL_DOUBLE:
        case SQL_NUMERIC:
        case SQL_DECIMAL:
            type = 2; break;
        case SQL_CHAR:
        case SQL_VARCHAR:
            type = 3; break;
        default:
            croak("DBD::Ingres::bind_param: Unknown TYPE: %d, param_no %d",
                sql_type, param_no);
        }
where SQL_DATE clearly is missing, but it is the only one.

I'll patch it and get a new version out asap.

Btw. I have problems with prepared statements and placeholders.
Sometimes Ingres seems to forget the prepared statement.
I have not been able to pin down where the problem is.

--
Henrik Tougaard.

**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************


 
 
 

1. DBI-1.37 and DBD-Ingres

David Coulthart skrev:

This pussles me, as did the tr.cpan bug report. I have just tried to install
Ingres2.6, perl 5.8.0, DBI 1.37 and DBD::Ingres 0.36 on a clean Linux box.
No problems - at all.
But looking at the DBI docs I can see that $dbh->{Statement} should be
read-only, which rules out my setting a value on it.
Why doesn't it fail for me, but for you? I just don't get it!
What OS, Ingres and perl versions do you use? - That might give a clue.

Henrik Tougaard, DBD::Ingres maintainer, Copenhagen, Denmark.

2. sketch patterning a solid to modelize a chain

3. 400K drive repair ?

4. DBD-Ingres problem on Solaris - SOLUTION plus followup questi on

5. boot disk swapping

6. DBD-Ingres problem on Solaris

7. Forcing CCITT V25 1300Hz Tone

8. DBD and Ingres II make test failure

9. sco unixware/Ingres II 2.5 DBD make errors - help !

10. DBD-Ingres Installation problem

11. FW: Installing DBD::Ingres on another machine than OpenIngres DBM S

12. Problems while compiling DBD-Ingres-0.32