FreeTDS Development Group

[Frediano Ziglio <freddy77 AT gmail.com>]

2016-09-16 22:39 GMT+01:00 Adam Baratz <adam.baratz AT gmail.com>:
>>
>> If you want to handle error messages from the server using db-library you
>> will have to define a message handler, using the db-library function
>> dbmsghandle()
>>
>
> I'm using a handler. It works correctly when I query on an invalid column
> name ("SELECT asdf"). That query comes back with an error token, which
> causes tds_process_default_tokens() to call tds_process_info(), which in
> turn calls the handler. The divide by zero query comes back with a result
> token, which causes tds_process_default_tokens() to call
> tds7_process_result(), which doesn't lead to the handler being called.
>

The two queries are completely different. The

  SELECT missing_field

is a syntax/compiler error, the server cannot generate/start a result and
give the error. For

   SELECT 0/1

or like

   SELECT 0/field_name FROM table_name

the server know that if has to generate a result and start a new table result

> The "divide by zero occurred" message is in the packet with the result
> token (see previous attachment). I tried looking at the response spec to
> see what was done with that section, but it didn't appear to be there. I
> also stepped through the application with gdb and that message appears to
> be skipped over.
>
> The log for the divide by zero query continued like this:
>
> token.c:540:processing result tokens.  marker is  81(TDS7_RESULT)
> token.c:1538:processing TDS7 result metadata.
> mem.c:644:tds_free_all_results()
> token.c:1563:set current_results (1 column) to tds->res_info
> token.c:1570:setting up 1 columns
> token.c:1507:tds7_get_data_info:
> colname =
> type = 38 (integer-null)
> server's type = 38 (integer-null)
> column_varint_size = 1
> column_size = 4 (4 on server)
> token.c:1579: name                 size/wsize      type/wtype      utype
> token.c:1580: -------------------- --------------- --------------- -------
> token.c:1585:                            4/4            38/38            0
> util.c:165:Changed query state from READING to PENDING
> dblib.c:4692:dbsqlok() found result token
> dblib.c:1700:dbresults(0x1e81e10)
> dblib.c:1705:dbresults: dbresults_state is 1 (_DB_RES_RESULTSET_EMPTY)
> token.c:525:tds_process_tokens(0x1e82690, 0x7fffffffa538, 0x7fffffffa53c,
> 0x6914)
> util.c:165:Changed query state from PENDING to READING
> token.c:540:processing result tokens.  marker is  d1(ROW)
> token.c:644:tds_process_tokens::SET_RETURN stopping on current token
> util.c:165:Changed query state from READING to PENDING
> dblib.c:1726:dbresults() tds_process_tokens returned 0 (TDS_SUCCESS),
> result_type TDS_ROW_RESULT
> dblib.c:1689:dbresults returning 1 (SUCCEED)
> dblib.c:2776:dbcount(0x1e81e10)
> dblib.c:1838:dbnumcols(0x1e81e10)
> dblib.c:2776:dbcount(0x1e81e10)
> dblib.c:1838:dbnumcols(0x1e81e10)
> dblib.c:1864:dbcolname(0x1e81e10, 1)
> dblib.c:3048:dbcollen(0x1e81e10, 1)
> dblib.c:1476:dbclose(0x1e81e10)
> dblib.c:241:dblib_del_connection(0x7fffebf5cb40, 0x1e82690)
> query.c:3796:tds_disconnect()
> util.c:165:Changed query state from PENDING to DEAD
> mem.c:644:tds_free_all_results()
> dblib.c:288:dblib_release_tds_ctx(1)
> dblib.c:5881:dbfreebuf(0x1e81e10)
> dblib.c:749:dbloginfree(0x1e21890)
> dblib.c:1543:dbexit(void)
> dblib.c:288:dblib_release_tds_ctx(1)
>

I don't see the issue. Would be worth seeing the server reply
entirely (some rows above if enabled) but if I remember there
should be the error inside the result.
It surprise a bit to see the ROW instead of ERROR/MSG but
probably there's a reason and surely the ROW came from the
server. However as the error came with the row(s) in this case
I don't see any dbnextrow call from the log.

> Thanks,
> Adam

Regards,
  Frediano