FreeTDS Development Group

["Lowden, James K" <LowdenJK AT bernstein.com>]

> From: Tom Sillence [mailto:freetds AT sillence.co.uk]
> Sent: May 29, 2002 3:24 PM
> 
> I believe I have found a bug related to this issue in 
> freeTDS's handling of messages back from the server. 

Tom, 

Welcome, and thanks for your diligent problem report.  

Both items you cited have been discussed here, as you know.  I don't think
they're solved yet.  

If you're tempted to write a patch, please work with the nightly snapshot
(ftp://ftp.ibiblio.org/pub/Linux/ALPHA/freetds/freetds-current.tgz).  The
current snapshot is so far away from 0.53 that a patch to 0.53 would be hard
to apply.  You happen to have joined us just as we're discussing what goes
in the next release and what number it gets.  

> (2) PHP does not set php_sybase_module.server_message in 
> php_sybase_db.c
> when it receives an error. It only does this when it receives 
> a message
> (tds marker 0xab), so if an error packet (marker 0xaa in tds) 
> is returned,
> php will display a warning but there is no way to access the 
> error message
> subsequently. I don't know why the php people have chosen to 
> implement it
> this way, any ideas? Altering this behaviour so that
> php_sybase_error_handler mirrors the behaviour of
> php_sybase_message_handler is trivial and has the desired effect.

I think this has been reported to PHP; I don't know anything about the
status.  I know it sounds weird, but if you or someone else does have a PHP
patch, it would be helpful to post it to
http://sourceforge.net/projects/freetds/, so we can offer it to FreeTDS PHP
users until it's incorporated in their release.  

> (3) There is a second problem, this time in freeTDS. 
> token.c takes the tds message number (the first four bytes after the
> header of an error or message packet) and stores it in
> tds->msg_info->msg_number. Subsequently, messages are not passed up
> through the dblib layer if tds->msg_info->msg_number is less than 0.
> 
> HOWEVER, the msg_number field of msg_info is a TDS_SMALLINT, 
> which is a
> typedef to a 16 bit short. The assignment from the (32 bit) 
> message number
> into this field causes truncation. MSSQL system error messages are
> probably never greater than 32767 so the truncation is not often a
> problem, however the default message number for an error caused by the
> MSSQL raiserror command is 50000. This obviously truncates to 
> 0, and thus
> the subsequent check [dbutil.c:  if( 
> tds->msg_info->msg_number > 0)] is
> failed and the packet is ignored.

I remember discussing this (at least, I think it's the same thing) with Mark
Gruetzner on May 17.   I don't remember seeing a fix.  It's pretty clear
that stuffing 32 bits into 15 is not going to work on most hardware
architectures, given current technology. ;)  A patch would be much
appreciated.  

Brian and I are both intending to ignore perfectly good sunshine this
weekend in favor of indoor hacking, so if you post something this week it's
got a good shot at being applied by Monday.  

Regards, 

--jkl