php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #26555 lvarchar not recognized
Submitted: 2003-12-08 14:35 UTC Modified: 2005-12-29 01:00 UTC
Votes:4
Avg. Score:4.5 ± 0.9
Reproduced:3 of 3 (100.0%)
Same Version:2 (66.7%)
Same OS:2 (66.7%)
From: jkaufman at wamnetgov dot com Assigned: nobbie (profile)
Status: No Feedback Package: Informix related
PHP Version: 4CVS-2003-12-9 OS: Mandrake 9.1
Private report: No CVE-ID: None
 [2003-12-08 14:35 UTC] jkaufman at wamnetgov dot com
Description:
------------
Perhaps I have something misconfigured, but I discovered that doing a fetchInto after a query that retrieves a field that is defined as 'lvarchar 1000' causes PHP to die.

Looking at ext/ifx.ec near line 1732, I see this:
$ifdef HAVE_IFX_IUS;
        ifx_int8_t int8_var;
        lvarchar   *lvar_tmp;
$endif;

The compiled code in ifx.c has this:
#line 1733 "/usr/src/php-4.3.3/ext/informix/ifx.ec"
  ifx_int8_t int8_var;
#line 1734 "/usr/src/php-4.3.3/ext/informix/ifx.ec"
  void *lvar_tmp = 0;

To me, this looks like the system understands 'ifx_int8_t' as a datatype, but doesn't understand 'lvarchar'.




Reproduce code:
---------------
This is my code:

// Get status updates
$sql  = "select * from dmm_status ";
$sql .= "where dmm_status_master_id=$recordno";
$res = $dbh->query($sql);
if (DB::isError($res)) {
    die ($res->getDebugInfo() . " at line " . __line__ );
}

// Get the data. Will be 0+ rows.
while ($row = $res->fetchRow(DB_FETCHMODE_ASSOC)) {
    $status_note[] = $row['dmm_status_notes'];
    $status_date[] = $row['dmm_status_date'];
}

Table:

create table dmm_status(
   dmm_status_id              serial primary key,
   dmm_status_master_id       integer,
   dmm_status_user_id         integer,
   dmm_status_date            datetime year to minute,
   dmm_status_notes           lvarchar(1000)
) in appdbs
  extent size 20000 next size 5000
  lock mode row;


Expected result:
----------------
I expect to see data in the $status_note and $status_date arrays.

Actual result:
--------------
PHP exits, w/o any error message. This happens in DB/ifx.php in the fetchInto routine:

if (!$row = @ifx_fetch_row($result, $rownum)) {
    return null;
}

It never returns from the ifx_fetch_row instruction. I tried removing the '@' sign, but still no error message.


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-12-09 12:40 UTC] jkaufman at wamnetgov dot com
I built using the snapshot. First problem is that '--with-imap' did not include '-lssl', though php-4.3.3 did. I removed that option from my configure statement and rebuilt.

The problem is still present. ifx.c shows:

#line 1768 "/usr/src/php4-STABLE-200312091430/ext/informix/ifx.ec"
  ifx_int8_t int8_var;
#line 1769 "/usr/src/php4-STABLE-200312091430/ext/informix/ifx.ec"
  void *lvar_tmp = 0;
 [2003-12-09 14:41 UTC] sniper@php.net
What informix sdk do you have installed?

(and if your c-client, the imap thing, is linked with ssl, you need to use --with-imap-ssl)


 [2003-12-10 12:53 UTC] jkaufman at wamnetgov dot com
I don't *know* that the interpretation of lvarchar in ifx.c is wrong just because I see a void type, but I do know this. I modified my db schema and changed the lvarchar(1000) to char(500) and the query works fine. I would prefer the lvarchar approach (it uses less db space and I 500 characters is not enough for my app), but it does demonstrate that there is something amiss in the way php handles lvarchar.
 [2003-12-10 13:18 UTC] jkaufman at wamnetgov dot com
Forgot to mention that the informix sdk is:

IBM INFORMIX-Client SDK 2.81.UC1 PRODUCT RELEASE
INFORMIX-ESQL/C Version 9.53
DATE: 04 Feb 2003
 [2004-01-12 07:05 UTC] sniper@php.net
Assigned to the ext/informix maintainer, Corne'.

 [2005-12-21 21:55 UTC] sniper@php.net
Please try using this CVS snapshot:

  http://snaps.php.net/php5.1-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.1-win32-latest.zip


 [2005-12-29 01:00 UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, 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".
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Dec 03 01:01:29 2024 UTC