FreeTDS Development Group

["Kall, Bruce A." <kall AT mayo.edu>]

My original problem was (using freetds, php and php_mssql):

>> I appear to be having this problem as a stored procedure returning
>> more than one result set results in the following error:
>> dblib.c:303: buffer_add_row: Assertion `row_size <=buf->element_size'

Lowden, James K wrote:
> > From: Kall, Bruce A.
> > Sent: Thursday, July 07, 2005 10:22 AM
> >
> > Just wondering if the problem described in my previous email is
> > fixed in 0.64?
>
>
> Yes.  I rewrote quite a bit of the buffering logic, and extended the
> unit tests for it.  I assert it works now.  
>
> I would be pleased if you would try out any recent nightly snapshot, in
> anticipation of the release.  If you discover any problems, I would like
> to know about them.  


I finally had a chance to get back to this.  I installed freetds from 
last nights build (freetds-0.64.dev.20050916 .. I made a rpm from it).

I no longer get the dblib.c:303: buffer_add_row: Assertion `row_size <= 
buf->element_size' error.  It acts like it works, but nothing is 
returned from my mssql_query() (used to fail inside the query) call:

e.g.,
$db_result = mssql_query("execute sp_get_codes @id=12345")


$db_result comes back as 'null'.

Other calls to stored procedures returning only one result set still 
work fine in 0.64.  Is there something I can turn on in freetds to get 
more debugging information? or some other way to see why nothing is 
being returned (the query works fine using tsql in both 0.62 and 
0.64-current).

Thanks,
Bruce





> --jkl
>
>
> > >From: Thompson, Bill D (London)
> > >> Sent: Wednesday, April 13, 2005 10:34 AM
> > >>
> > >> Bruce,
> > >>
> > >
> > >>> > Is this true?
> > >
> > >>
> > >> No. Not as far as I know.
> >
> >
> > Au contraire, mon ami.  I'm afraid it is.
> >
> > ISTR buffering has been broken for a while.  I just updated
> > src/dblib/unittests/t0002.c to demonstrate.  If the test is broken,
> > please say how.
> >
> > Right now, dbclrbuf() fails an assertion if there are no rows
> > buffered.  It shouldn't.  But if you move dbclrbuf() after the
> > dbnextrow() loop, you just get a different kind of error:
> >
> >         Failed.  Expected i to be 11, was 10
> >
> > Unfortunately, the buffering logic is a bear.
> >
> > --jkl