#4351 [Com]: Informix LVARCHAR fields returned from ifx_fetch_row() are too long

ID: 4351 Comment by: pkedro1@sears.com Reported By: alex.shepherd@cse.co.nz Status: Closed Bug Type: Other Operating System: Debian Linux 2.2.14 PHP Version: 4.0 Release Candidate 1 New Comment: //create connection $connection=ifx_connect("audit@ifmx00296") or die("Couldn't create connection."); //create SQL statement $sql="select * from pjktest where col1 matches '$hname'"; //execute SQL query and get result $sql_result=ifx_query($sql,$connection) or die("Couldn't execute query"); //format result in HTML table ifx_htmltbl_result($sql_result,"border=10"); Using Apache 1.3.22,PHP 4.2.2,Informx 9.21.UC2,ESQL 9.40,AIX 4.3.3.0. col1 type lvarchar is only column in table, query fails when row is NOT NULL This Bug was closed as fixed in PHP 4.0.0 but I still have the problem. Previous Comments: ------------------------------------------------------------------------ [2000-05-29 13:50:35] afalout@cvs.php.net Danny forgot to close this. ------------------------------------------------------------------------ [2000-05-27 22:20:51] danny@cvs.php.net The fix proposed by Alex has been added to the CVS on May 10 and is in the PHP 4.0.0 release. Danny --- ------------------------------------------------------------------------ [2000-05-08 22:07:39] alex.shepherd@cse.co.nz We are using PHP4RC1 with Informix 9.2 on Linux. I have just noticed something that was causing a problem when LVARCHAR fields are returned into a Row array. The PHP string that a LVARCHAR field is returned into seems to have two extra NULLs on the end which was causing some other problems in our application. I have tried CHAR(255) and VERCHAR(255) which seem to work fine as the add_assoc_string() function uses strlen() to determine its length where as LVARCHAR uses add_assoc_stringl() which relies upon the passed length parameter. To debug the problem I modified the following section of the code (lines 2116-2128 of ifx.ec) to cause a warning: case SQLLVARCHAR: ifx_var_flag(&lvar_tmp,1); EXEC SQL GET DESCRIPTOR :descrpid VALUE :i :lvar_tmp = DATA; fieldleng=ifx_var_getlen(&lvar_tmp); if ((char_data = (char *)emalloc(fieldleng + 1)) == NULL) { php_error(E_WARNING, "Out of memory"); RETURN_FALSE; } //----Begin Debug Code Here--------- php_error(E_WARNING,"ifx_fetch_row: SQLLVARCHAR ifx_var_getlen: %d strlen: %d", fieldleng, strlen( ifx_var_getdata(&lvar_tmp) ) ) ; //----End Debug Code Here--------- memcpy(char_data,ifx_var_getdata(&lvar_tmp),fieldleng); ifx_var_dealloc(&lvar_tmp); add_assoc_stringl(return_value, fieldname, char_data, fieldleng,0); break; This causes the following line to be displayed in the browser: Warning: ifx_fetch_row: SQLLVARCHAR ifx_var_getlen: 12 strlen: 10 in ifx_session.inc on line 110. I had a look around in the ESQL/C manuals etc and they say the the call ifx_var_getlen() returns the size of a buffer needed to store the field data. My guess is that this includs a 16bit length word as well as the actual string and whould explain the two extra NULL chars. To solve my imediate problem I have added 2 lines at line 2121 of ifx.ec: fieldleng=ifx_var_getlen(&lvar_tmp); //----Begin Hack to Fix Problem--------- if( fieldleng > 2 ) fieldleng -= 2 ; //----End Hack to Fix Problem--------- if ((char_data = (char *)emalloc(fieldleng + 1)) == NULL) { ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=4351&edit=1