Skip to Content.
Sympa Menu

freetds - Re: [freetds] Problem with message handler

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • 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: Mon, 16 Sep 2013 00:32:25 +0000

That seems...dodgy? Can we always assume the error message is in English?

Chris

-----Original Message-----
From: freetds-bounces AT lists.ibiblio.org
[mailto:freetds-bounces AT lists.ibiblio.org] On Behalf Of Frediano Ziglio
Sent: Sunday, 15 September 2013 12:25 AM
To: FreeTDS Development Group
Subject: Re: [freetds] Problem with message handler

I think you want something like this
http://gitorious.org/freetds/freetds/commit/bc22b2ef817fb5d102bd758111ff3634b39a1319.
This is already in master branch.

Frediano


2013/9/14 Chris Kings-Lynne <Chris.Kings-Lynne AT navitas.com>:
> 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/2skSUbTQO7hu0VBfBfnmU
> m/0
>
>
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
_______________________________________________
FreeTDS mailing list
FreeTDS AT lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds





Archive powered by MHonArc 2.6.24.

Top of Page