[freetds] 0.64 status and coverage

Frank M. Kromann frank at kromann.info
Fri Sep 16 14:41:10 EDT 2005


Hi Bruce,

Asuming you are using the mssql extention and not the sybase or subase_ct
version:

PHP's mssql_query() con only return multiple result sets if the first
result returns rows. (This is on my todo list to fix)

You can use mssql_init(), mssql_bind() and mssql_exec() to execute your
procedure and these should be able to return the results correct, by
skipping results without rows.

- Frank

> 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
> > 
> > 
> _______________________________________________
> FreeTDS mailing list
> FreeTDS at lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
> 





More information about the FreeTDS mailing list