#25777 [Com]: char and varchar fields are being rtrimmed (and also ltrimmed?) using freetds
ID: 25777 Comment by: jfitz at gmx dot net 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: Why has this bug been closed? The fact that the error lies in the underlying MS library is inconsequential - the bug still actively affects PHP developers and should be tracked whilst the solution is a 'work-in-progress'. Previous Comments: [2004-06-25 00:13:31] [EMAIL PROTECTED] Inserting 'john ' into a char(10) filed should return 'john ' (6 spaces) as the filed is a fixed length column. PHP should return the value that way and that's how it works now. The database allows the user to insert a value that is shorter than the required length. The problem is with empty char or varchar values. The DB library used to build the extension on returns the same value for '' (empty) and ' ' (one space). Fixing it and not fixing it is both wrong. The only real fix is to get a version of DBLIB that does not have this bug. That part is in the works with the help of FreeTDS on win32. [2004-06-24 23:54:31] john dot g at envent dot co dot za I agree with berni... besides, it's important for programmers to retrieve data from the database in the same format as they submit it. If I submit 'John' to a field called Name, I expect 'John' to be returned to me on request... not 'John '. I've managed to implement a simple workaround due to the fact that I use a DB abstraction layer, but others may not be as lucky. When can this be fixed? [2004-06-03 14:04:49] berni at starsucker dot net As it is not very easy to revert these changes transparently in php, it would be nice to have a php.ini Setting to turn the trimming back on. Besides, I think it is very naive to try to get the data as it is from sql server. Microsofties are telling me that the DBLib is old and nobody with a brain uses it anymore: You can not tell a difference between varchar or char fields. You can not get more than 255 bytes from a var-* field. You have to convert the field to text, and it is not a problem to append something if you really want all the spaces: mssql_query (SELECT convert(text, Field + '!')); php_mssql.dll is not the place to get the data as it is because it is in no way compatible to COM-based Clients like ADO. It is also not compatible with FreeTDS by the way. The simple meaning is: Of course, PHP has to process the Output of DBLib / FreeTDS. As these 2 Libraries are behind the same extension, PHP should do even more processing on their output in order to make them compatible! What I really want to say: Introduce a new php.ini Setting for the trimming. Activate it by default. [2004-04-23 15:54:34] cbunk at arescorporation dot com The fix for this bug has caused a new bug. When querying a MSSQL db and the a field's value is empty a space gets returned, not an empty string as expected. This is causing lots off problems with scripts I have that check to see if a value is empty to determine if to display some stuff. The bug report http://bugs.php.net/bug.php?id=26996 got listed as bogus but it was a correct report. I'm not sure I think I may try submitting another bug report in hopes it will be noticed. [2004-03-30 06:22:35] arion_ at msn dot com Description: If a field is empty it returns one blank space character. Reproduce code: --- ?php $host=XXX; $usuario=User; $password=Password; $bbdd=BBDD; $conexion=mssql_connect($host,$usuario,$password); $qry=SELECT Field FROM dbo.Table; $handle=mssql_query($qry); $registro=mssql_fetch_row($handle); $Nothing=$registro[0]; echo A .$Nothing. B; ? Expected result: AB Actual result: -- A B I reported this here http://bugs.php.net/bug.php?id=26996 and I have wait for the new release to solve this problem. I've just test with 4.3.5 and doesn't works yet. 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/25777 -- Edit this bug report at http://bugs.php.net/?id=25777edit=1
#25777 [Com]: char and varchar fields are being rtrimmed (and also ltrimmed?) using freetds
ID: 25777 Comment by: john dot g at envent dot co dot za 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: I agree with berni... besides, it's important for programmers to retrieve data from the database in the same format as they submit it. If I submit 'John' to a field called Name, I expect 'John' to be returned to me on request... not 'John '. I've managed to implement a simple workaround due to the fact that I use a DB abstraction layer, but others may not be as lucky. When can this be fixed? Previous Comments: [2004-06-03 14:04:49] berni at starsucker dot net As it is not very easy to revert these changes transparently in php, it would be nice to have a php.ini Setting to turn the trimming back on. Besides, I think it is very naive to try to get the data as it is from sql server. Microsofties are telling me that the DBLib is old and nobody with a brain uses it anymore: You can not tell a difference between varchar or char fields. You can not get more than 255 bytes from a var-* field. You have to convert the field to text, and it is not a problem to append something if you really want all the spaces: mssql_query (SELECT convert(text, Field + '!')); php_mssql.dll is not the place to get the data as it is because it is in no way compatible to COM-based Clients like ADO. It is also not compatible with FreeTDS by the way. The simple meaning is: Of course, PHP has to process the Output of DBLib / FreeTDS. As these 2 Libraries are behind the same extension, PHP should do even more processing on their output in order to make them compatible! What I really want to say: Introduce a new php.ini Setting for the trimming. Activate it by default. [2004-04-23 15:54:34] cbunk at arescorporation dot com The fix for this bug has caused a new bug. When querying a MSSQL db and the a field's value is empty a space gets returned, not an empty string as expected. This is causing lots off problems with scripts I have that check to see if a value is empty to determine if to display some stuff. The bug report http://bugs.php.net/bug.php?id=26996 got listed as bogus but it was a correct report. I'm not sure I think I may try submitting another bug report in hopes it will be noticed. [2004-03-30 06:22:35] arion_ at msn dot com Description: If a field is empty it returns one blank space character. Reproduce code: --- ?php $host=XXX; $usuario=User; $password=Password; $bbdd=BBDD; $conexion=mssql_connect($host,$usuario,$password); $qry=SELECT Field FROM dbo.Table; $handle=mssql_query($qry); $registro=mssql_fetch_row($handle); $Nothing=$registro[0]; echo A .$Nothing. B; ? Expected result: AB Actual result: -- A B I reported this here http://bugs.php.net/bug.php?id=26996 and I have wait for the new release to solve this problem. I've just test with 4.3.5 and doesn't works yet. [2003-11-17 18:14:15] [EMAIL PROTECTED] 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. [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 hicoming 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. 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
#25777 [Com]: char and varchar fields are being rtrimmed (and also ltrimmed?) using freetds
ID: 25777 Comment by: berni at starsucker dot net 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: As it is not very easy to revert these changes transparently in php, it would be nice to have a php.ini Setting to turn the trimming back on. Besides, I think it is very naive to try to get the data as it is from sql server. Microsofties are telling me that the DBLib is old and nobody with a brain uses it anymore: You can not tell a difference between varchar or char fields. You can not get more than 255 bytes from a var-* field. You have to convert the field to text, and it is not a problem to append something if you really want all the spaces: mssql_query (SELECT convert(text, Field + '!')); php_mssql.dll is not the place to get the data as it is because it is in no way compatible to COM-based Clients like ADO. It is also not compatible with FreeTDS by the way. The simple meaning is: Of course, PHP has to process the Output of DBLib / FreeTDS. As these 2 Libraries are behind the same extension, PHP should do even more processing on their output in order to make them compatible! What I really want to say: Introduce a new php.ini Setting for the trimming. Activate it by default. Previous Comments: [2004-04-23 15:54:34] cbunk at arescorporation dot com The fix for this bug has caused a new bug. When querying a MSSQL db and the a field's value is empty a space gets returned, not an empty string as expected. This is causing lots off problems with scripts I have that check to see if a value is empty to determine if to display some stuff. The bug report http://bugs.php.net/bug.php?id=26996 got listed as bogus but it was a correct report. I'm not sure I think I may try submitting another bug report in hopes it will be noticed. [2004-03-30 06:22:35] arion_ at msn dot com Description: If a field is empty it returns one blank space character. Reproduce code: --- ?php $host=XXX; $usuario=User; $password=Password; $bbdd=BBDD; $conexion=mssql_connect($host,$usuario,$password); $qry=SELECT Field FROM dbo.Table; $handle=mssql_query($qry); $registro=mssql_fetch_row($handle); $Nothing=$registro[0]; echo A .$Nothing. B; ? Expected result: AB Actual result: -- A B I reported this here http://bugs.php.net/bug.php?id=26996 and I have wait for the new release to solve this problem. I've just test with 4.3.5 and doesn't works yet. [2003-11-17 18:14:15] [EMAIL PROTECTED] 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. [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 hicoming 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. The remainder of the comments for this report are too long. To
#25777 [Com]: char and varchar fields are being rtrimmed (and also ltrimmed?) using freetds
ID: 25777 Comment by: cbunk at arescorporation dot com 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 fix for this bug has caused a new bug. When querying a MSSQL db and the a field's value is empty a space gets returned, not an empty string as expected. This is causing lots off problems with scripts I have that check to see if a value is empty to determine if to display some stuff. The bug report http://bugs.php.net/bug.php?id=26996 got listed as bogus but it was a correct report. I'm not sure I think I may try submitting another bug report in hopes it will be noticed. Previous Comments: [2004-03-30 06:22:35] arion_ at msn dot com Description: If a field is empty it returns one blank space character. Reproduce code: --- ?php $host=XXX; $usuario=User; $password=Password; $bbdd=BBDD; $conexion=mssql_connect($host,$usuario,$password); $qry=SELECT Field FROM dbo.Table; $handle=mssql_query($qry); $registro=mssql_fetch_row($handle); $Nothing=$registro[0]; echo A .$Nothing. B; ? Expected result: AB Actual result: -- A B I reported this here http://bugs.php.net/bug.php?id=26996 and I have wait for the new release to solve this problem. I've just test with 4.3.5 and doesn't works yet. [2003-11-17 18:14:15] [EMAIL PROTECTED] 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. [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 hicoming 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' 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/25777 -- Edit this bug report at http://bugs.php.net/?id=25777edit=1
#25777 [Com]: char and varchar fields are being rtrimmed (and also ltrimmed?) using freetds
ID: 25777 Comment by: arion_ at msn dot com 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: Description: If a field is empty it returns one blank space character. Reproduce code: --- ?php $host=XXX; $usuario=User; $password=Password; $bbdd=BBDD; $conexion=mssql_connect($host,$usuario,$password); $qry=SELECT Field FROM dbo.Table; $handle=mssql_query($qry); $registro=mssql_fetch_row($handle); $Nothing=$registro[0]; echo A .$Nothing. B; ? Expected result: AB Actual result: -- A B I reported this here http://bugs.php.net/bug.php?id=26996 and I have wait for the new release to solve this problem. I've just test with 4.3.5 and doesn't works yet. Previous Comments: [2003-11-17 18:14:15] [EMAIL PROTECTED] 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. [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 hicoming 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? 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/25777 -- Edit this bug report at http://bugs.php.net/?id=25777edit=1
#25777 [Com]: char and varchar fields are being rtrimmed (and also ltrimmed?) using freetds
ID: 25777
Comment by: klaus dot albert at techconsult dot ie
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:
Description
---
mssql_fetch_row and mssql_fetch_array return a single space
for columns that contain an empty string
Reproduce
-
$db=mssql_pconnect('server','user','pass');
$result=mssql_query(UPDATE table SET column='' WHERE
id='1',$db);
$result=mssql_query(SELECT column FROM table WHERE
id='1',$db);
echo strlen($result[0]);
Expected result
---
Expected length is 0, gotten result is 1 (a single space).
PHP 4.3.2 returns correct empty result.
Enviroment
--
Win2000 SP4, IIS5, MSSQL 2000
also reproducable on WinNT SP6, IIS5, MSSQL 7
Remarks
---
see Bug #9854
Previous Comments:
[2003-11-17 18:14:15] [EMAIL PROTECTED]
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.
[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 hicoming 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?
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/25777
--
Edit this bug report at http://bugs.php.net/?id=25777edit=1
#25777 [Com]: char and varchar fields are being rtrimmed (and also ltrimmed?) using freetds
ID: 25777
Comment by: cquincy at whitewave dot com
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:
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 hicoming 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.
Previous Comments:
[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 '%
