No subject
Fri May 2 19:13:14 EDT 2003
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
More information about the FreeTDS
mailing list