Ignore those. They are related to a change in DBI 1.29 that I'll revert
in 1.20, but it's obscure and very unlikely to affect your code.

Tim.

On Wed, Jul 17, 2002 at 06:29:26PM +0200, Jan Matejka wrote:
> Platform: Windows 2000, Oracle 8.1.7, ActiveState Perl 5.6.1 build 629
> 
> It looks better, but still some tests fail ...
> 
> With using DBI-1.28 I have absolutely no problems at all - all test pass.
> 
> When using DBI-1.29 with  [POSSIBLE FIX]: Oracle 1.12 fails some t\long
> tests:
> 
> C:\temp\DBD-Oracle-1.12>nmake test
> 
> Microsoft (R) Program Maintenance Utility   Version 6.00.8168.0
> Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
> 
> 
> 
>       C:\bin\Perl\bin\Perl.exe -Mblib -IC:\bin\Perl\lib -IC:\bin\Perl\lib -e
> "
> use Test::Harness qw(&runtests $verbose); $verbose=0; runtests @ARGV;"
> t\base.t
> t\general.t t\long.t t\ph_type.t t\plsql.t t\reauth.t
> Using C:/temp/DBD-Oracle-1.12/blib
> t\base.......ok
> t\general....ok
> t\long.......ok 14/143# failed test 16 at line 175. (DBI::errstr undefined)
> t\long.......ok 49/143# failed test 51 at line 175. (DBI::errstr undefined)
> t\long.......ok 84/143# failed test 86 at line 175. (DBI::errstr undefined)
> t\long.......ok 117/143# failed test 121 at line 175. (DBI::errstr
> undefined)
> t\long.......ok 140/143
> Some tests for LONG data type handling failed. These are generally Oracle
> bugs.
> Please report this to the dbi-users mailing list, and include the
> Oracle version number of both the client and the server.
> Please also include the output of the 'perl -V' command.
> (If you can, please study t/long.t to investigate the cause.
> Feel free to edit the tests to see what's happening in more detail.
> t\long.......ok 142/143Especially by adding trace() calls around the failing
> tes
> ts.
> Run the tests manually using the command "perl -Mblib t/long.t")
> Meanwhile, if the other tests have passed you can use DBD::Oracle.
> 
> t\long.......FAILED tests 16, 51, 86, 121
>         Failed 4/143 tests, 97.20% okay
> t\ph_type....ok
> t\plsql......ok
> t\reauth.....skipped
>         all skipped: no reason given
> Failed Test Stat Wstat Total Fail  Failed  List of Failed
> ----------------------------------------------------------------------------
> ---
> t\long.t                 143    4   2.80%  16 51 86 121
> 1 test skipped.
> Failed 1/6 test scripts, 83.33% okay. 4/281 subtests failed, 98.58% okay.
> NMAKE : fatal error U1077: 'C:\bin\Perl\bin\Perl.exe' : return code '0xff'
> Stop.
> 
> MaT
> 
> > -----Original Message-----
> > From: Tim Bunce [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, July 17, 2002 6:00 PM
> > To: Stphane Peiry
> > Cc: [EMAIL PROTECTED]; Philip Molter
> > Subject: Re: DBI 1.29 not working correctly with Oracle 1.12
> > [POSSIBLE FIX]
> >
> >
> > Try adding this line
> >
> >     void *xxx = PL_markstack_ptr++;
> >
> > as the *first* line (just above the dXSARGS;) line of the
> > dbixst_bounce_method() function in the Driver_xst.h file.
> >
> > Either edit the file in the DBI 1.29 source directory and
> > reinstall, or edit the installed copy.
> >
> > Can everyone else who's had a "Can't call method prepare" problem
> > with DBI 1.29 please try this.
> >
> > Tim.
> >
> > On Wed, Jul 17, 2002 at 04:18:10PM +0200, Stphane Peiry wrote:
> > >
> > > Althaugh Im not subscribed to this list I was wanted to add to this
> > > thread that I had the exact same problem (t\general....ok 9/17Can't
> > > call method "prepare" ) on a Linux machine (x86 RedHat 6.1) running
> > > Oracle 8i, as well as on an installation that had  Oracle 9i Server
> > > (on Solaris) and the DBI clients on a RedHat 7.3 (DBD::Oracle  1.12
> > > compiled against Oracle 9i libraries).
> > >
> > > Since I had a previous installation of DBI running against
> > Oracle 8i,
> > > I checked the DBI version there (a 1.21), and went on downgrading to
> > > this DBI 1.21 on my current setups.  Afther that, "test problems"
> > > just disappeared.
> > >
> > > Actually I noticed that DBI 1.28 runs all the tests smoothly (but as
> > > soon as DBI is 1.29 the problems comes back).  While
> > testing I noticed
> > > that running one single 'selectall_arrayref' works fine,
> > but as soon as
> > > I have two such queries in a row, then the second one fails
> > with "Can't
> > > call method prepare ...".
> > >
> > > Regards,
> > > Stphane
> > >
> >
> 

Reply via email to