Skip to Content.
Sympa Menu

freetds - tds_process_result_tokens error handling

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Mark Schaal <mark AT champ.tstonramp.com>
  • To: freetds AT franklin.oit.unc.edu
  • Subject: tds_process_result_tokens error handling
  • Date: Thu, 12 Aug 1999 12:51:11 -0700 (PDT)



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



  • tds_process_result_tokens error handling, Mark Schaal, 08/12/1999

Archive powered by MHonArc 2.6.24.

Top of Page