FreeTDS Development Group

[Mark Schaal <mark AT champ.tstonramp.com>]

Currently when tds_process_result_tokens() sees an error message it
immediately returns TDS_FAIL.  (If an error handler resets the
msg_info structure like dblib does, then this is ignored.)

Problem #1 - It doesn't process the following TDS_END_TOKEN, which
  leaves the result stream one token out of sync with where I would
  expect it to be.

Problem #2 - If multiple error messages are returned for one result set,
  it doesn't process any beyond the first and leaves them in the result
  stream.

My assumption (based on limited testing) is that if the query generates
an error then the server will return a result set containing only (but
perhaps multiple) error messages followed by an end token.  My current
thinking then is to not return TDS_FAIL immediately but move the check
   if (tds->msg_info->priv_msg_type==1)
          return TDS_FAIL;
to the end of the function.  (Well, this also led me to change around
end token and more_result stuff, but that's the basic idea.)

Caveat #1:  If a result set can return an error message and then a valid row,
this would hide the valid row.  This scenario doesn't make any sense to me
and I couldn't produce it in testing.

Caveat #2:  If a result set can return an error message and then an non-error
message, the priv_msg_type will be turned off and the error hidden.  This
scenario seems unlikely, but is easy to correct for if necessary.

Caveat #3:  This might break the client libraries depending on how
they deal with the current behavior.  I looked at dblib, ctlib, and 
odbc and it looks like they should be okay, but I don't use them so
no guarantees.  (Should ctlib call tds_reset_msg_info in its error
handler like dblib does?)

I'll try to get a patch out today with my specific changes.

Mark
-- 
Mark J. Schaal                                  Phone:      (909) 620-7724
TST On Ramp                                     Fax:        (909) 620-8174
System Administrator                            E-Mail: mark AT tstonramp.com