On Sat, Jul 03, 2004 at 04:33:21PM -0700, Henri Asseily wrote:
> I've been running DBD::Sybase with the following patch since version
> 1.01, which could remotely have an impact for you. This is the 1.02
> patch, but should work fine in 1.04. FYI in DBD::Sybase version 1.04,
> the modified line is dbdimp.c:2987.
>
> Here's the issue in syb_st_finish() ( when $sth->finish is called):
>
> finish() is called. If flush_finish, then while the statement is active
> and the connect isn't dead, fetch all the rows one after the other
> until the return value is null.
> Now in the case where there's an error in the dbh, you risk an infinite
> loop because the dbh isn't dead, the statement is still active, and
> you're trying to fetch all the rows. On every fetch the db connect
> returns the same dbh error that isn't doing you any good and isn't
> triggering any of the exit statements.
>
> This case can and does happen in some arcane setups such as when using
> openswitch which doesn't kill your dbh but invalidates it. All we need
> to do is put a check for a dbh error.
>
> --- DBD-Sybase-1.02/dbdimp.c.orig 2003-10-28 13:21:27.000000000
> -0800
> +++ DBD-Sybase-1.02/dbdimp.c 2003-10-28 13:25:26.000000000 -0800
> @@ -2762,7 +2762,8 @@
> connection = imp_sth->connection ? imp_sth->connection :
> imp_dbh->connection;
>
> - if (imp_dbh->flushFinish) {
> + if (imp_dbh->flushFinish && !(SvOK(DBIc_ERR(imp_dbh)))) {
> + /* only flush if there is no error, otherwise we risk an infinite loop */
That SvOK() should probably be SvTRUE. Unless you want info and warning
status to have the same effect as an error.
Tim.
> On Jul 2, 2004, at 10:56 PM, Michael Peppler wrote:
>
> >On Fri, 2004-07-02 at 22:06, David Good wrote:
> >>On Fri, Jul 02, 2004 at 08:37:43PM +0200, Michael Peppler
> >><[EMAIL PROTECTED]> wrote:
> >>>On Fri, 2004-07-02 at 20:19, David Good wrote:
> >>>>I'm having trouble with DBD::Sybase 1.04 on ActivePerl 5.8.4 (build
> >>>>810)
> >>>>on Windows. It seems to hang when connecting. Here's a sample
> >>>>script
> >>>>that exercises the problem:
> >>>
> >>>>>>DESTROY DISPATCH (DBI::st=HASH(0x1c1ca7c) rc1/1 @1 g0 ima4
> >>>>>>pid#2184) at c:/Perl/site/lib/DBD/Sybase.pm line 99 via foo line
> >>>>>>10
> >>>> -> DESTROY for DBD::Sybase::st (DBI::st=HASH(0x1c1ca7c)~INNER)
> >>>>thr#15d4a54
> >>>> syb_st_finish() -> ct_cancel(CS_CANCEL_ALL)
> >>>
> >>>I don't know why, but the ct_cancel() call often causes problems - in
> >>>particular if the client and the server aren't on the same network
> >>>(i.e.
> >>>firewalls, routers, etc.)
> >>>
> >>>Try adding the syb_flush_finish => 1 attribute in the connect() call,
> >>>and read about this attribute in the DBD::Sybase docs.
> >>
> >>Well, that fixed it, but the client and server are on the same
> >>network, so
> >>I'm not sure what the deal is. Oh well, as long as it works :-)
> >
> >It might also be a bug in the ct_cancel() implementation on Windows for
> >this version of the SDK.
> >
> >Michael
> >--
> >Michael Peppler Data Migrations, Inc.
> >[EMAIL PROTECTED] http://www.peppler.org/
> >Sybase T-SQL/OpenClient/OpenServer/C/Perl developer available for short
> >or long term contract positions - http://www.peppler.org/resume.html
> >
>
