freetds AT lists.ibiblio.org
Subject: FreeTDS Development Group
List archive
- From: Michael Peppler <mpeppler AT peppler.org>
- To: "TDS Development Group" <freetds AT franklin.oit.unc.edu>
- Subject: Re: DBD::Sybase main.t crash
- Date: Thu, 26 Aug 1999 07:11:17 -0700 (PDT)
Brian Bruns writes:
>
>
> On Wed, 25 Aug 1999, Mark Schaal wrote:
>
> > >
> > > Mark Schaal writes:
> > > > >
> > > > > Actually that's changed and checked in. I found the same
> > > thing...but I
> > > > > still get main.t to crash. That's against a Sybase 11.x server
> > > (the JDBC
> > > > > server at Sybase)
> > > > >
> > > > > Brian
> > > >
> > > > I think you should be saving the data in the buffer and not the
> > > buffer
> > > > itself. I could be wrong...
> > >
> > > I don't think so.
> > >
> > > I sort of figured that you only store the pointer to the buffer that
> > > is passed in, and it's length. Otherwise, when the app changes the
> > > data in that buffer it won't be reflected in the CS_USERDATA buffer.
> > >
> > > Michael
> >
> > <*sigh*> If only we had ctlib documentation.
> >
>
> I've got dblib/cslib/ctlib/server lib manuals :P
>
> Seriously, you can go to sybooks.sybase.com and all the manuals are on
> line, although sqml to html garbage they use is slow enough to drive you
> crazy.
>
> The doc states *buffer is 'user allocated data'. Although a little vague
> it seems to indicate that the user is responsible for keeping the data
> and releasing it...If I was at work I could test it fairly simply, just
> store it change it and then ask for it back.
I think so. And it's similar to the dbsetuserdata() call in the DBlib
side. I think the explanation of the dbsetuserdata() functionality
(and teh deadlock example code that is included there) explains this
functionality well.
In DBD::Sybase I definitely expect the buffer returned by the
CS_USERDATA property to be the same buffer that I passed in earlier -
its elements can change and the action I take in the server or client
callbacks depend on those values (typically whether to call a perl
callback from the C error handler or not).
Michael
--
Michael Peppler -||- Data Migrations Inc.
mpeppler AT peppler.org -||- http://www.mbay.net/~mpeppler
Int. Sybase User Group -||- http://www.isug.com
Sybase on Linux mailing list: ase-linux-list AT isug.com
-
Re: DBD::Sybase main.t crash,
Brian Bruns, 08/25/1999
- <Possible follow-up(s)>
- Re: DBD::Sybase main.t crash, Mark Schaal, 08/25/1999
- Re: DBD::Sybase main.t crash, Michael Peppler, 08/25/1999
- Re: DBD::Sybase main.t crash, Mark Schaal, 08/25/1999
- Re: DBD::Sybase main.t crash, Brian Bruns, 08/25/1999
- Re: DBD::Sybase main.t crash, Michael Peppler, 08/26/1999
- Re: DBD::Sybase main.t crash, Mark Schaal, 08/26/1999
- Re: DBD::Sybase main.t crash, Michael Peppler, 08/26/1999
- Re: DBD::Sybase main.t crash, Michael Peppler, 08/26/1999
- Re: DBD::Sybase main.t crash, Michael Peppler, 08/26/1999
- Re: DBD::Sybase main.t crash, Brian Bruns, 08/26/1999
- Re: DBD::Sybase main.t crash, Mark Schaal, 08/27/1999
- Re: DBD::Sybase main.t crash, Brian Bruns, 08/28/1999
- Re: DBD::Sybase main.t crash, Bill Tutt, 08/28/1999
- Re: DBD::Sybase main.t crash, Brian Bruns, 08/28/1999
- Re: DBD::Sybase main.t crash, Bill Tutt, 08/29/1999
Archive powered by MHonArc 2.6.24.