freetds AT lists.ibiblio.org
Subject: FreeTDS Development Group
List archive
- From: Chris Kings-Lynne <Chris.Kings-Lynne AT navitas.com>
- To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
- Subject: Re: [freetds] Problem with message handler
- Date: Sat, 14 Sep 2013 06:59:52 +0000
Hi James,
I am aware of what you say below (having studied the Tenderfoor as well as
the tsql.c source. I too wish to suppress the SYBEMSG error, and instead
print the preceeding message. In fact, that's what the PHP library is
attempting to do, however the msgno being sent to the handler is _never_
SYBEMSG?
Chris
-----Original Message-----
From: freetds-bounces AT lists.ibiblio.org
[mailto:freetds-bounces AT lists.ibiblio.org] On Behalf Of James K. Lowden
Sent: Saturday, 14 September 2013 9:58 AM
To: freetds AT lists.ibiblio.org
Subject: Re: [freetds] Problem with message handl
On Fri, 13 Sep 2013 06:51:53 +0000
Chris Kings-Lynne <Chris.Kings-Lynne AT navitas.com> wrote:
> I'm trying to fix the PHP pdo_dblib driver. The issue is it never
> returns the actual database error message. It always says "Check SQL
> server messages". I've identified the problem in the message handler
> code here:
>
> https://github.com/php/php-src/blob/master/ext/pdo_dblib/pdo_dblib.c#L
> 140
Hmm, they did leave room for improvement, eh? The handler is called with
msgno, severity, text, server name, procedure name, and line number, but the
function keeps only the text.
It's also possible to get more than one message, but the function
unilaterally discards any it finds.
Disregarding messages with serverity 0 isn't very general. People have been
known to use the T-SQL PRINT statement, but they're uniformly suppressed.
I know, there are messages no one really wants to see. I've handled that in
libraries I've written by maintaining a do-not-print list of message numbers.
That way the application programmer has control over which messages the
handler handles.
> The problem is that the msgno always comes through as the correct
> underlying sql error number (eg. 208), instead of the magic one that's
> being expected (20018).
I think there may be some confusion on this point. What you're calling the
"correct" msgno is attached to a *message* from the server. It's not
necessarily an error. It may be helpful to think of them as runtime errors,
because in principle they can be caused by things under the user's control.
Usually the connection remains viable even if the query fails. Messages are
handled by the message handler.
The numbers your referred to in dblib.c are db-lib *errors*. These are
caused by using db-lib incorrectly, and originate from the library, not the
server. They are logic errors made by the programmer or environmental issues
(such as network failures) that the user has no control over. Depending on
how badly things went awry, the connection may be broken and/or the data
corrupted. Errors are handled by the error handler.
There's a special class of server message that represents an error condition,
where the server is experiencing heartburn. Table corruption, disk failure,
or maybe the DBA killed the spid that was executing the user's query. These
kinds of errors have high serverity (where "high" is over 10 IIRC). In such
cases, the server will send its message per usual, and db-lib will call the
message handler, per usual. Then, just to make sure you got the message (as
it were) it calls the error handler too, with your friend and mine SYBEMSG.
I ususally suppress SYBEMSG, because I make very sure to have printed the
message that preceded it.
It's like the secretary leaving a "while you were out" message slip on your
desk. We used to have people whose job it was to answer phones and take
messages. The phone was attached to the wall by a wire, so you couldn't just
carry it around. Oh, never mind. We had offices, too.
--jkl
_______________________________________________
FreeTDS mailing list
FreeTDS AT lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds
--
Message protected by MailGuard: e-mail anti-virus, anti-spam and content
filtering.http://www.mailguard.com.au/mg
Click here to report this message as spam:
https://login.mailguard.com.au/report/1HYf05wudM/2skSUbTQO7hu0VBfBfnmUm/0
-
[freetds] Problem with message handler,
Chris Kings-Lynne, 09/13/2013
-
Re: [freetds] Problem with message handler,
James K. Lowden, 09/13/2013
-
Re: [freetds] Problem with message handler,
Chris Kings-Lynne, 09/14/2013
-
Re: [freetds] Problem with message handler,
Frediano Ziglio, 09/14/2013
- Re: [freetds] Problem with message handler, Chris Kings-Lynne, 09/15/2013
-
Re: [freetds] Problem with message handler,
Chris Kings-Lynne, 09/15/2013
-
Re: [freetds] Problem with message handler,
James K. Lowden, 09/16/2013
-
Re: [freetds] Problem with message handler,
Chris Kings-Lynne, 09/19/2013
- Re: [freetds] Problem with message handler, Chris Kings-Lynne, 09/30/2013
- Re: [freetds] Problem with message handler, James K. Lowden, 09/30/2013
-
Re: [freetds] Problem with message handler,
Chris Kings-Lynne, 09/19/2013
-
Re: [freetds] Problem with message handler,
James K. Lowden, 09/16/2013
-
Re: [freetds] Problem with message handler,
Frediano Ziglio, 09/14/2013
-
Re: [freetds] Problem with message handler,
Chris Kings-Lynne, 09/14/2013
-
Re: [freetds] Problem with message handler,
James K. Lowden, 09/13/2013
Archive powered by MHonArc 2.6.24.