#18271 [Fbk->Opn]: Problems reading MSSQL data of type "real"

ID: 18271 User updated by: Brendan@callaghans.com.au Reported By: Brendan@callaghans.com.au -Status: Feedback +Status: Open Bug Type: MSSQL related Operating System: Win2000 PHP Version: 4.3.0 New Comment: And it's just a case of overwriting my current php_mssql.dll with the one in this archive? Previous Comments: ------------------------------------------------------------------------ [2003-01-15 03:56:40] sniper@php.net Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip There were some mssql fixes committed recently. ------------------------------------------------------------------------ [2003-01-15 00:19:05] Brendan@callaghans.com.au I've been on holidays for a while, so missed out on the request to use the CVS snapshot. However, yesterday I upgraded to 4.3.0, and the "real" data type problem became a whole lot worse. All my real data is currently being retreived by PHP as approximately 4.330e-304. For example, a particular cell that holds the value 0.09 is being retreived by PHP as 4.33060646217E-304. And it's not even consistent. Another cell in the same column which also contains 0.09 is coming back as 4.33041176821E-304. Nor is it proportionate. A cell containing 0.5 is reported as 4.33055085271E-304, which is actually *less* than the first 0.09 example! Just to test the other end of the range, I put the value 500 into a "real" cell, and this is what came back: 4.33041185318E-302. If there is a pattern to these infinitestmal numbers, I can't detect it. Apart from the 4.330 part, the rest appears essentially random, and doesn't appear to have any relationship to the actual data. I can still acquire the correct data using non-PHP technologies, such as looking at the data directly in SQL Server Query Tool, running linked tables from MS Access, using ODBC from Excel, etc etc. PHP appears to be working correctly with all other data types at this stage. Please let me know if a fix is likely in the near future. If it's not, I'll need to implement a workaround, or regress to an earlier PHP version. I tried the link you provided to the Win32 CVS snapshot, but I got a 403 Forbidden response. ------------------------------------------------------------------------ [2002-12-28 01:00:02] php-bugs@lists.php.net No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". ------------------------------------------------------------------------ [2002-12-07 01:42:06] iliaa@php.net Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip ------------------------------------------------------------------------ [2002-07-12 23:55:04] Brendan@callaghans.com.au I eventually figured out that the problem was related directly to the "kilometres" column of the table, which was of type real. I changed the data type of the column to "decimal" - this was more appropriate for the data anyway. The column contains odometer readings, numbers in the range 0 - 400000 which either had one decimal place or no fractional part at all. The problems instantly disappeared. It seems that something in the php_mssql extension has trouble with the real data type, in certain circumstances. Because I'm happy to use the decimal data type on this ocassion, my problem is solved, but I would still regard this as an open bug report. I'm happy to do more testing on demand, if it would help the cause. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/18271 -- Edit this bug report at http://bugs.php.net/?id=18271&edit=1