FreeTDS Development Group

[Brian Bruns <camber AT umcc.ais.org>]

I seems to me there were certain cases where we need to respect END3 (Row
processing for instance), but it should be ignored in the normal flow.
However, the code doesn't seem to agree with my recollection.  We do
ignore it in process_login_tokens() and there are several extraneous ones
there.  BTW, 254 is for stored proc and 253 shows up for ad hoc queries if
that's any help. I never have been clear about what 255 (0xFF) does.

Brian

On Mon, 21 Dec 1998, Gregg Jensen wrote:

> I have come across something new that the FreeTDS protocol didn't handle
> correctly (I hesitate to use that word) .  I am not sure what the proper
> handling is, but would like to throw it out and see if anyone has an
> idea.  The issue is the marker 255 or TDS_END3_TOKEN.    When this
> marker is encountered, the process flow essentially stops, as it is
> treated like TDS_END_TOKEN in tds_process_result_tokens.  I changed it
> so that TDS_END3_TOKEN would act just like the default case in that
> function, so it wouldn't stop processing.  So far it hasn't broken
> anything else, but would be curious to know if anyone had any further
> ideas about this particular marker.
> 
> The reason I ran across this, was that I had to execute a stored
> procedure on MSSQL 6.5, and the output of the procedure was just a
> simple print statement of either a "Y" or "N".  That is, there weren't
> any rows returned or anything.  The replied ended up in the text portion
> of a information message from the server (ie, it gets printed out with
> the msg_handling routine).  One of the keys to get this out, was to
> allow the processing to get past the TDS_END3_TOKEN (and then some
> tweaking on the info_handling function, and tds_process_result_token
> function).
> 
> To further define what is returned to provide more info,
> send the command: Active_Circuit_Test 2230     (ie, stored procedure
> name arg1 expect Y or N)
> markers received:
> marker[255]
> marker[255]
> marker[171]
> marker[255]
> marker[255]
> marker[121]
> marker[254]
> 
> where marker:
> 255 - TDS_END3_TOKEN
> 171 - TDS_MSG_TOKEN
> 121 - TDS_RET_STAT_TOKEN
> 254 - TDS_END2_TOKEN
> 
> Basically, I changed it so that TDS_END3_TOKEN was ignored (for now) and
> then processing would stop at TDS_END2_TOKEN (254) in the above
> scenario.  So, it would essentially skip of the two TDS_END3_TOKEN
> process the message with TDS_MSG_TOKEN(171) spit out my output and then
> continue.
> 
> If anyone has ANY further info about this, I would appreciate some
> input.
> 
> Thanks
> Gregg Jensen
> greggj AT savvis.com
> 
> 
>