FreeTDS Development Group

["Lowden, James K" <LowdenJK AT bernstein.com>]

> From: Mark Gruetzner [mailto:mgruetzner AT rw3.com]
> Sent: May 17, 2002 4:28 PM

OK, that helps.  

> Yes, my first instinct, as well, was to widen the message variable to 32
> bits to store the message number.  Not being very familiar with the code
and
> the specs, I was more afraid of breaking something by doing that....but, I
> agree, this would be getting to the real root of the problem...

Well, I always say that, for what we're being paid, we might as well try to
do it right.  I haven't diddled with that code, either, but we can't do too
much harm to something that's already broken, the way I see it.    

> As for the "2 sets of database results" (which I now know is only 1 set +
> out of band data for the message), I was simply looking at the freetds.log
> file (which works very well for debugging by the way) and found that I was
> receiving both my query results and the message from raiserror in response
> to my call to mssql_query--but the php code was only getting the query
> results with the first call to dbresults() and the message was not getting
> processed.  

>From your description, it sounds like php may not be doing this right.  

I'm not surprised that the results and the message show up back-to-back in
the log (where else would they be?) but I think close examination of the TDS
stream would show that they're not 2 results.  Mind, I'm not arguing with
you and I don't know what the error is; I'm just saying the server didn't
stuff your OOB message into your query's results.  

> In this case, where there is out-of-band data following the
> query results, the first call to dbresults() returns SUCCESS (rather than
> NO_MORE_RESULTS), and so I call it again (after processing all the rows
with
> dbnextrow) which will then return NO_MORE_RESULTS

That's normal, raiserror or no.  The first call (for a successfully
processed query) to dbresults() should be SUCCEED.  Then the rows are
processed, as you say, with dbnextrow() until it returns NO_MORE_ROWS.  Then
dbresults() should be consulted again, in case there are multiple result
sets.  dbresults() will keep returning SUCCEED until in fact there are
NO_MORE_RESULTS.   

Your query had one result set, so you got 1 SUCCEED, 1 set of rows, and 1
NO_MORE_RESULTS.  

> and cause the message to
> get processed--which in turn causes the PHP callback to get called by
> freetds, where PHP stores the message for subsequent calls to
> mssql_get_last_message.  

What you're saying here is that the message arrives after the result set,
and is processed in turn (something has to happen first and something
second, after all, unless the client is multi-threaded).  That conforms to
my experience: in your query, the raiserror follows the select statement,
and the server dutifully sends you the results first, followed by the
message.  

> (By the way, PHP calls dbmsghandle to register its
> callback function which freetds calls when it processes a message--then,
in
> the callback function, PHP simply stores the message in a global variable
so
> it can return it when the PHP function msssql_get_last_message() is
called)

If I understand correctly, PHP was not calling dbresults() until
NO_MORE_RESULTS.  That left your result-set processing unfinished, so
FreeTDS never got around to calling PHP's dbmsghandle callback function.  No
call to the callback, no message to the client.  Yes?  Or did I lose track
of something?  

> I'd be interested in looking at an actual spec. since I have been solely
> relying on looking at the source code and the freetds.log file...

The only TDS spec we have is Brian's, but in this case the "spec" I'm using
is Microsoft's dblib documentation.  FreeTDS has to behave as described
there, until and unless we find behavior in exception to the documentation,
at which point we'd have to decide on "bug for bug" emulation or not.  

++++

Based on my understanding of what you said, we have to examine FreeTDS's
message number variable width, and eliminate any bad 16-bitness.  And it
sounds like you have a patch for the PHP boys, to boot.  If that's not an
argument for being able to read the source code, I don't know what is!

Regards, 

--jkl