ID: 25777 Updated by: [EMAIL PROTECTED] Reported By: duh at dowebwedo dot com Status: Closed Bug Type: MSSQL related Operating System: Debian GNU/Linux 3.0 PHP Version: 4.3.4RC1 New Comment:
The sybase and mssql extensions do not handle returned data the exact same way, and it might be that we need to readd the rtrim code to the sybase extensions. It seams like the dbconvert() finctions are implemented differently. You could also try the native mssql extension. That will work with FreeTDS as well, and give you more functions. Previous Comments: ------------------------------------------------------------------------ [2003-11-17 17:29:18] cquincy at whitewave dot com I think I have run into a problem related to this bug fix. I am using sybase/freetds to interact with mssql on my company intranet like the orginator of this bug. Now with version 4.3.4 numbers, whether integer of floating points are coming back with spaces on the right side. i.e. you put "123" in the database, then when you mssql_fetch* you get back "123 ". Note that the originator of the bug was only concerned with char and varchar fields. 4.3.3 did not have this problem with numbers. So, it seems the "fix" has created an unforseen problem with numbers which is worse in my opinion than "hi " coming back as "hi". Obviously I expect to get exactly the same data that is stored in the database instead of right padded data. Expected result: ---------------- Put 123 in the database get back 123, not '123 '. Put 123.456 in the database get back 123.45, not '123.456 ' Thanks for your efforts. ------------------------------------------------------------------------ [2003-10-14 23:32:13] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. ------------------------------------------------------------------------ [2003-10-10 06:12:57] duh at dowebwedo dot com the configure line is: './configure' '--with-mysql' '--with-apxs=/www/bin/apxs' '--with-gd=/usr/local' '--with-png-dir' '--with-freetype-dir' '--with-pear' '--with-zlib-dir' '--enable-track-vars' '--enable-trans-sid' '--disable-posix-threads' '--enable-shared' '--with-pgsql=/usr' '--with-unixODBC=/usr/local/easysoft/unixODBC' '--with-mssql=/usr/local' ------------------------------------------------------------------------ [2003-10-07 19:09:27] [EMAIL PROTECTED] What was the configure line used to configure PHP? ------------------------------------------------------------------------ [2003-10-07 09:43:10] duh at dowebwedo dot com Description: ------------ I am busy developing a new improved version of our intranet running on Apache/php/Debian and moved in this version from ODBC to MSSQL/Sybase connections (ODBC gave a lot of overhead and appeared being quite slow). In several intranet functions we aquire data from the Exact financial suite (http://www.exactsoftware.com) which is largely used in The Netherlands and abroad and which currently uses MSSQL as a database backend. In the most recent versions of exact you can still see their MS-DOS history (exact used btrieve and several other MS-DOS databases in the old days) because several columns are still padded to the maximum column width. Hence the word "hi" in a varchar(8) would be stored as "hi " (hi+6 spaces). Now when using mssql_* functions in php over freetds all selected values are right trimmed, so SELECT hi FROM table will return "hi" instead of the actual data in the table "hi ". I have currently only tried selecting, i don't know what happens when inserting (probably the same?). Obviously, this is not what I want since this would lead to data inconsistency (in your financial system!) and an unuseable financial system (which ofcourse is the worst that could happen to a company). At first I thought it was due to the fact that sybase used to right trim these values so freetds does it as well for compatibility's sake. But when I executed a query command line through the tsql (/usr/local/bin/tsql) application it appeared that then the values were NOT being right trimmed. So appearantly the interface between freetds and my application (which in my opinion can only be php) does the trimming of values with spaces. Ofcourse one could say that I need to trim or append spaces to these values myself, but since most data and software is dynamic and only some (var)char fields will get appended and some don't, there is no way of telling which columns should be appended (or prepended) and which shouldn't. For the sake of data consistency I would either like to see this bug fixed, or -if it is no bug but a feature- see a configuration option being introduced to overrule this trimming. Reproduce code: --------------- In php the following code will return trimmed values: $db = mssql_connect('server','user','pass'); $result= mssql_query("SELECT TOP 1 medewerker FROM Efw_001.[dbo].Prres1 WHERE medewerker IS NOT NULL AND medewerker LIKE '% %'"); $a = mssql_fetch_assoc($result); print_r($a); but commandline this values are not being trimmed: # tsql -S server -U user -P pass locale is "C" charset is "ANSI_X3.4-1968" Msg 5703, Level 0, State 1, Server NTS1, Line 0 Changed language setting to us_english. 1> SELECT TOP 1 medewerker FROM Efw_001.[dbo].Prres1 WHERE medewerker IS NOT NULL AND medewerker LIKE '% %' 2> go medewerker '100 ' (size=8) 1> SELECT TOP 1 rtrim(medewerker) as trimmed_medewerker FROM Efw_001.[dbo].Prres1 WHERE medewerker IS NOT NULL AND medewerker LIKE '% %' 2> go trimmed_medewerker '100' (size=3) (I added single quotes around the results and wrote the sizes behind it so you can see the difference between the two queries) Expected result: ---------------- Obviously I expect to get exactly the same data that is stored in the database instead of modified (trimmed) data. ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=25777&edit=1
