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: "Lowden, James K" <LowdenJK AT bernstein.com>
  • To: "'TDS Development Group'" <freetds AT franklin.metalab.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 17:09:55 -0400


> 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




Archive powered by MHonArc 2.6.24.

Top of Page