Skip to Content.
Sympa Menu

freetds - RE: mssql_query not updating mssql_get_last_message on php4.1.2 and freetds 0.53

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Tom Sillence" <freetds AT sillence.co.uk>
  • To: freetds AT franklin.oit.unc.edu
  • Subject: RE: mssql_query not updating mssql_get_last_message on php4.1.2 and freetds 0.53
  • Date: Wed, 29 May 2002 15:24:21 -0400


I believe I have found a bug related to this issue in freeTDS's handling
of messages back from the server. I am new to this mailing list so please
correct me if I am wrong:

(1) The symptom is that no matter what errors are raised in the database
(MS SQL Server 7 and 2000), only the first message on any connection is
returned by mssql_get_last_message. It appears that the error string
stored by php is simply never updated apart from the first time.

(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.

(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.

Please forgive me if this has been fixed since 0.53. If not I suggest that
msg_number is expanded to a 32 bit int. I will look into this further. If
I am right about the problem I will write a patch which should be ready
tomorrow.




Archive powered by MHonArc 2.6.24.

Top of Page