Skip to Content.
Sympa Menu

freetds - Re: [freetds] 0.64 status and coverage

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Kall, Bruce A." <kall AT mayo.edu>
  • To: "Lowden, James K" <LowdenJK AT bernstein.com>, FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] 0.64 status and coverage
  • Date: Fri, 16 Sep 2005 13:31:19 -0500

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






Archive powered by MHonArc 2.6.24.

Top of Page