Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the DBD-Oracle CPAN distribution.

Report information
The Basics
Id: 64752
Status: resolved
Priority: 0/
Queue: DBD-Oracle

People
Owner: Nobody in particular
Requestors: dflewelling [...] epsilon.com
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: 1.24
Fixed in: (no value)



Subject: DBD ERROR: OCIStmtPrepare
AIX 6.1.0.0 Perl: v5.8.8 built for aix-thread-multi DBI Version:1.613 DBD::Oracle: 1.24 Oracle: 10.2.0.3 DBD Oracle seems to get corrupted if I am switching back/forth between an ODBC connection and Oracle connection. for example: I have a connection to an ODBC (netezza) database and Oracle database. I can prepare and execute a statement against the ODBC connection, but when I try to prepare a subsequent statement against the Oracle database, I get the following error: ORA-24373: invalid length specified for statement (DBD ERROR: OCIStmtPrepare) [for Statement "SELECT * FROM EXTRACT_ATTR"] However, if I reverse the order of the statements (e.g. Oracle first and ODBC second), both work fine.
From: dflewelling [...] epsilon.com
On Thu Jan 13 15:13:47 2011, dflewelling wrote: Show quoted text
> AIX 6.1.0.0 > Perl: v5.8.8 built for aix-thread-multi > DBI Version:1.613 > DBD::Oracle: 1.24 > Oracle: 10.2.0.3 > > DBD Oracle seems to get corrupted if I am switching back/forth
between Show quoted text
> an ODBC connection and Oracle connection. > > for example: I have a connection to an ODBC (netezza) database and > Oracle database. > > I can prepare and execute a statement against the ODBC connection,
but Show quoted text
> when I try to prepare a subsequent statement against the Oracle > database, I get the following error: > > ORA-24373: invalid length specified for statement (DBD ERROR: > OCIStmtPrepare) [for Statement "SELECT * FROM EXTRACT_ATTR"] > > However, if I reverse the order of the statements (e.g. Oracle first > and ODBC second), both work fine. >
additional information: as long as I prepare a statement against Oracle FIRST, everything seems to work fine...
On Fri Jan 14 11:43:21 2011, dflewelling wrote: Show quoted text
> On Thu Jan 13 15:13:47 2011, dflewelling wrote:
> > AIX 6.1.0.0 > > Perl: v5.8.8 built for aix-thread-multi > > DBI Version:1.613 > > DBD::Oracle: 1.24 > > Oracle: 10.2.0.3 > > > > DBD Oracle seems to get corrupted if I am switching back/forth
> between
> > an ODBC connection and Oracle connection. > > > > for example: I have a connection to an ODBC (netezza) database and > > Oracle database. > > > > I can prepare and execute a statement against the ODBC connection,
> but
> > when I try to prepare a subsequent statement against the Oracle > > database, I get the following error: > > > > ORA-24373: invalid length specified for statement (DBD ERROR: > > OCIStmtPrepare) [for Statement "SELECT * FROM EXTRACT_ATTR"] > > > > However, if I reverse the order of the statements (e.g. Oracle first > > and ODBC second), both work fine. > >
> additional information: > as long as I prepare a statement against Oracle FIRST, everything seems > to work fine... >
The only time I've seen this is when two connections use different shared objects but both contain the same symbol e.g., using DBD::ODBC with any ODBC driver and DBD::DB2 with their cli driver (they both contain SQLxxx fns). The solution in that case was to set PERL_DL_NONLAZY and export it before running the script. Martin -- Martin J. Evans Wetherby, UK
From: dflewelling [...] epsilon.com
On Tue Jan 18 04:30:38 2011, MJEVANS wrote: Show quoted text
> On Fri Jan 14 11:43:21 2011, dflewelling wrote:
> > On Thu Jan 13 15:13:47 2011, dflewelling wrote:
> > > AIX 6.1.0.0 > > > Perl: v5.8.8 built for aix-thread-multi > > > DBI Version:1.613 > > > DBD::Oracle: 1.24 > > > Oracle: 10.2.0.3 > > > > > > DBD Oracle seems to get corrupted if I am switching back/forth
> > between
> > > an ODBC connection and Oracle connection. > > > > > > for example: I have a connection to an ODBC (netezza) database
and Show quoted text
> > > Oracle database. > > > > > > I can prepare and execute a statement against the ODBC
connection, Show quoted text
> > but
> > > when I try to prepare a subsequent statement against the Oracle > > > database, I get the following error: > > > > > > ORA-24373: invalid length specified for statement (DBD ERROR: > > > OCIStmtPrepare) [for Statement "SELECT * FROM EXTRACT_ATTR"] > > > > > > However, if I reverse the order of the statements (e.g. Oracle
first Show quoted text
> > > and ODBC second), both work fine. > > >
> > additional information: > > as long as I prepare a statement against Oracle FIRST, everything
seems Show quoted text
> > to work fine... > >
> > The only time I've seen this is when two connections use different > shared objects but both contain the same symbol e.g., using DBD::ODBC > with any ODBC driver and DBD::DB2 with their cli driver (they both > contain SQLxxx fns). The solution in that case was to set > PERL_DL_NONLAZY and export it before running the script. > > Martin
Thanks for the suggestion. I just tried that and it made no difference. any ideas what code I should be looking at ? (I'm fairly new to perl and not sure where to start looking...) Thanks Dwight
On Tue Jan 18 09:33:12 2011, dflewelling wrote: Show quoted text
> On Tue Jan 18 04:30:38 2011, MJEVANS wrote:
> > On Fri Jan 14 11:43:21 2011, dflewelling wrote:
> > > On Thu Jan 13 15:13:47 2011, dflewelling wrote:
> > > > AIX 6.1.0.0 > > > > Perl: v5.8.8 built for aix-thread-multi > > > > DBI Version:1.613 > > > > DBD::Oracle: 1.24 > > > > Oracle: 10.2.0.3 > > > > > > > > DBD Oracle seems to get corrupted if I am switching back/forth
> > > between
> > > > an ODBC connection and Oracle connection. > > > > > > > > for example: I have a connection to an ODBC (netezza) database
> and
> > > > Oracle database. > > > > > > > > I can prepare and execute a statement against the ODBC
> connection,
> > > but
> > > > when I try to prepare a subsequent statement against the Oracle > > > > database, I get the following error: > > > > > > > > ORA-24373: invalid length specified for statement (DBD ERROR: > > > > OCIStmtPrepare) [for Statement "SELECT * FROM EXTRACT_ATTR"] > > > > > > > > However, if I reverse the order of the statements (e.g. Oracle
> first
> > > > and ODBC second), both work fine. > > > >
> > > additional information: > > > as long as I prepare a statement against Oracle FIRST, everything
> seems
> > > to work fine... > > >
> > > > The only time I've seen this is when two connections use different > > shared objects but both contain the same symbol e.g., using DBD::ODBC > > with any ODBC driver and DBD::DB2 with their cli driver (they both > > contain SQLxxx fns). The solution in that case was to set > > PERL_DL_NONLAZY and export it before running the script. > > > > Martin
> > Thanks for the suggestion. I just tried that and it made no > difference. any ideas what code I should be looking at ? (I'm fairly > new to perl and not sure where to start looking...) > > Thanks > Dwight >
I'm not saying it is definitely what I described but the only time I've seen it was when 2 libs under DBDs exported the same symbols in shared objects (.a files on AIX containing shared objects). If you set PERL_DL_NONLAZY and it did not make the problem go away them /maybe/ it is a different issue. We discovered it by running nm on the libs used by the Perl DBDs and seeing they exported the same symbols. PERL_DL_NONLAZY changes the way symbols are resolved (downwards) in groups. I've not got all of your databases so I cannot reproduce here and help diagnose - you may be on your own :-( Martin -- Martin J. Evans Wetherby, UK
On Tue Jan 18 15:13:23 2011, MJEVANS wrote: Show quoted text
> On Tue Jan 18 09:33:12 2011, dflewelling wrote:
> > On Tue Jan 18 04:30:38 2011, MJEVANS wrote:
> > > On Fri Jan 14 11:43:21 2011, dflewelling wrote:
> > > > On Thu Jan 13 15:13:47 2011, dflewelling wrote:
> > > > > AIX 6.1.0.0 > > > > > Perl: v5.8.8 built for aix-thread-multi > > > > > DBI Version:1.613 > > > > > DBD::Oracle: 1.24 > > > > > Oracle: 10.2.0.3 > > > > > > > > > > DBD Oracle seems to get corrupted if I am switching back/forth
> > > > between
> > > > > an ODBC connection and Oracle connection. > > > > > > > > > > for example: I have a connection to an ODBC (netezza) database
> > and
> > > > > Oracle database. > > > > > > > > > > I can prepare and execute a statement against the ODBC
> > connection,
> > > > but
> > > > > when I try to prepare a subsequent statement against the
Oracle Show quoted text
> > > > > database, I get the following error: > > > > > > > > > > ORA-24373: invalid length specified for statement (DBD ERROR: > > > > > OCIStmtPrepare) [for Statement "SELECT * FROM EXTRACT_ATTR"] > > > > > > > > > > However, if I reverse the order of the statements (e.g. Oracle
> > first
> > > > > and ODBC second), both work fine. > > > > >
> > > > additional information: > > > > as long as I prepare a statement against Oracle FIRST,
everything Show quoted text
> > seems
> > > > to work fine... > > > >
> > > > > > The only time I've seen this is when two connections use different > > > shared objects but both contain the same symbol e.g., using
DBD::ODBC Show quoted text
> > > with any ODBC driver and DBD::DB2 with their cli driver (they both > > > contain SQLxxx fns). The solution in that case was to set > > > PERL_DL_NONLAZY and export it before running the script. > > > > > > Martin
> > > > Thanks for the suggestion. I just tried that and it made no > > difference. any ideas what code I should be looking at ? (I'm
fairly Show quoted text
> > new to perl and not sure where to start looking...) > > > > Thanks > > Dwight > >
> > I'm not saying it is definitely what I described but the only time
I've Show quoted text
> seen it was when 2 libs under DBDs exported the same symbols in shared > objects (.a files on AIX containing shared objects). If you set > PERL_DL_NONLAZY and it did not make the problem go away them /maybe/
it Show quoted text
> is a different issue. We discovered it by running nm on the libs used
by Show quoted text
> the Perl DBDs and seeing they exported the same symbols.
PERL_DL_NONLAZY Show quoted text
> changes the way symbols are resolved (downwards) in groups. > > I've not got all of your databases so I cannot reproduce here and help > diagnose - you may be on your own :-( > > Martin
Did you get anywhere with this? Can we close this rt now? Martin -- Martin J. Evans Wetherby, UK
Subject: RE: [rt.cpan.org #64752] DBD ERROR: OCIStmtPrepare
Date: Wed, 6 Apr 2011 09:31:43 -0400
To: "bug-DBD-Oracle [...] rt.cpan.org" <bug-DBD-Oracle [...] rt.cpan.org>
From: "Flewelling, Dwight" <dflewelling [...] epsilon.com>
Never resolved it. But we have a work around... Show quoted text
-----Original Message----- From: Martin J Evans via RT [mailto:bug-DBD-Oracle@rt.cpan.org] Sent: Wednesday, April 06, 2011 9:31 AM To: Flewelling, Dwight Subject: [rt.cpan.org #64752] DBD ERROR: OCIStmtPrepare <URL: https://rt.cpan.org/Ticket/Display.html?id=64752 > On Tue Jan 18 15:13:23 2011, MJEVANS wrote:
> On Tue Jan 18 09:33:12 2011, dflewelling wrote:
> > On Tue Jan 18 04:30:38 2011, MJEVANS wrote:
> > > On Fri Jan 14 11:43:21 2011, dflewelling wrote:
> > > > On Thu Jan 13 15:13:47 2011, dflewelling wrote:
> > > > > AIX 6.1.0.0 > > > > > Perl: v5.8.8 built for aix-thread-multi > > > > > DBI Version:1.613 > > > > > DBD::Oracle: 1.24 > > > > > Oracle: 10.2.0.3 > > > > > > > > > > DBD Oracle seems to get corrupted if I am switching back/forth
> > > > between
> > > > > an ODBC connection and Oracle connection. > > > > > > > > > > for example: I have a connection to an ODBC (netezza) database
> > and
> > > > > Oracle database. > > > > > > > > > > I can prepare and execute a statement against the ODBC
> > connection,
> > > > but
> > > > > when I try to prepare a subsequent statement against the
Oracle
> > > > > database, I get the following error: > > > > > > > > > > ORA-24373: invalid length specified for statement (DBD ERROR: > > > > > OCIStmtPrepare) [for Statement "SELECT * FROM EXTRACT_ATTR"] > > > > > > > > > > However, if I reverse the order of the statements (e.g. Oracle
> > first
> > > > > and ODBC second), both work fine. > > > > >
> > > > additional information: > > > > as long as I prepare a statement against Oracle FIRST,
everything
> > seems
> > > > to work fine... > > > >
> > > > > > The only time I've seen this is when two connections use different > > > shared objects but both contain the same symbol e.g., using
DBD::ODBC
> > > with any ODBC driver and DBD::DB2 with their cli driver (they both > > > contain SQLxxx fns). The solution in that case was to set > > > PERL_DL_NONLAZY and export it before running the script. > > > > > > Martin
> > > > Thanks for the suggestion. I just tried that and it made no > > difference. any ideas what code I should be looking at ? (I'm
fairly
> > new to perl and not sure where to start looking...) > > > > Thanks > > Dwight > >
> > I'm not saying it is definitely what I described but the only time
I've
> seen it was when 2 libs under DBDs exported the same symbols in shared > objects (.a files on AIX containing shared objects). If you set > PERL_DL_NONLAZY and it did not make the problem go away them /maybe/
it
> is a different issue. We discovered it by running nm on the libs used
by
> the Perl DBDs and seeing they exported the same symbols.
PERL_DL_NONLAZY
> changes the way symbols are resolved (downwards) in groups. > > I've not got all of your databases so I cannot reproduce here and help > diagnose - you may be on your own :-( > > Martin
Did you get anywhere with this? Can we close this rt now? Martin -- Martin J. Evans Wetherby, UK This e-mail and files transmitted with it are confidential, and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you are not one of the named recipient(s) or otherwise have reason to believe that you received this message in error, please immediately notify sender by e-mail, and destroy the original message. Thank You.