Skip to Content.
Sympa Menu

freetds - RE: [freetds] dbsetopt behaviour

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Brian Bruns <camber AT ais.org>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] dbsetopt behaviour
  • Date: Mon, 3 Mar 2003 15:52:10 -0500 (EST)

On Mon, 3 Mar 2003, Lowden, James K wrote:

> > From: Brian Bruns [mailto:camber AT ais.org]
> > Sent: March 3, 2003 1:31 PM
> >
> > DBPROCESS *dbproc = 0;
> > dbinit();
> > dbsetopt(dbproc, ...);
> >
> > which core dumps because dbsetopt() accesses the null pointer
> > of 'dbproc'.
> ...
> >
> > I have a local patch that
> > applies the option to all open dbproc's but I suspect that is wrong.
>
> I suspect it's right. Microsoft says the same thing Sybase does: "If dbproc
> is NULL, the option is set for all active DBPROCESS structures." It goes
> on:
>
> "This function does not immediately set the options specified. They are not
> set until the command buffer is sent to SQL Server (by invoking the
> dbsqlexec function). An additional result for each option set is returned
> through the dbresults function."
>
> If your patch detects a null dbproc and iterates over the active ones when
> it sees one, I'd say it's right. As best I can tell, that would conform to
> the documentation.
>
> I'd do it recursively in dbsetopt():
>
> if dbproc == NULL
> foreach connection
> dbsetopt g_dblib_ctx.connection_list[i] ...
>

Yeah that's pretty much it. I'd like to get confirmation on behaviour
before going ahead with the patch; I'll try to wrap up a test case to run
on OpenClient before I do.

Brian




Archive powered by MHonArc 2.6.24.

Top of Page