FreeTDS Development Group

[Chris Kings-Lynne <Chris.Kings-Lynne AT navitas.com>]

Actually Frediano, just trying to understand this.  This change is in 
dblib.c, and it happens BEFORE it executes the user-registered error handler, 
right?  So, as soon as I switch to this version of FreeTDS, the bug should 
just "fix itself" in PHP?   This is because it will always pass the SYBESMSG 
code to the PHP handler, hence fixing the error in PHP?

Has this commit made it into a release version yet?

Thanks,

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