php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #19528 odbc_fetch_row() doesn't returned true if there is one row only
Submitted: 2002-09-20 12:38 UTC Modified: 2003-06-24 10:25 UTC
Votes:3
Avg. Score:3.7 ± 0.9
Reproduced:3 of 3 (100.0%)
Same Version:1 (33.3%)
Same OS:1 (33.3%)
From: scott at abcoa dot com Assigned:
Status: Closed Package: ODBC related
PHP Version: 4.2.2 OS: AIX (UNIX)
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: scott at abcoa dot com
New email:
PHP Version: OS:

 

 [2002-09-20 12:38 UTC] scott at abcoa dot com 
The odbc_fetch_row() function worked fine when I used PHP version 4.0.6 but when I upgraded PHP to 4.2.2, the odbc_fetch_row() doesn't work when there is 1 row.  

When I use the echo command to see the response to the odbc_fetch_row() before the while loop, it showed that it doesn't return True or anything when there is 1 row.

I made the workaround to the problem by including the "$bug_workaround" into the script, this is to be use as 'row number' as shown in the PHP manual at "http://www.php.net/manual/en/function.odbc-fetch-row.php".

I enclosed two clipping to point this out.  The 1st clipping is the one that don't work and the 2nd clipping showed the work-around to it.  In this script, you'll find the word, 'INQUIRIES', it is a table that contain number of companies and users.  What the script does is to display each user whenever the company is selected.  The cool thing about it is it won't display the data if there is no row for any user.

--clip--
$cid = odbc_connect('blah blah blah');
$ask7 = "SELECT * FROM INQUIRIES WHERE USER_ID = '38SCK3'";
$R7 = odbc_exec($cid,$ask7);
$result = odbc_result($R7,1);

echo "Result or No Result??? --> ".odbc_fetch_row($R7);

while (odbc_fetch_row($R7))
{
 odbc_fetch_into($R7,$inquiry,$inq_c);
 echo $inquiry[0], $inquiry[1];
}
--clip--

--clip--
$cid = odbc_connect('blah blah blah');
$ask7 = "SELECT * FROM INQUIRIES WHERE USER_ID = '38SCK3'";
$R7 = odbc_exec($cid,$ask7);
$result = odbc_result($R7,1);

echo "Result or No Result??? --> ".odbc_fetch_row($R7);

$bug_workaround=0;

while (odbc_fetch_row($R7,++$bug_workaround))
{
 odbc_fetch_into($R7,$inquiry,$inq_c);
 echo $inquiry[0], $inquiry[1];
}
--clip--

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-09-22 20:00 UTC] kalowsky@php.net 
Considering the code in question hasn't changed since 4.0.5, I don't think this is a bug in PHP.  Regardless what ODBC driver, and DB are you connecting to?

And are you sure you're not refering to odbc_fetch_into?  Because that prototype did change...
 [2002-09-23 08:39 UTC] scott at abcoa dot com 
The webserver is made of IBM RS/6000, use IBM AIX and use IBM DB2 for database.

The odbc_fetch_into() worked fine.  To test it the functionality of the odbc_fetch_row(), I do the echo command followed by 'Result or No Result??? -->' then the odbc_fetch_row().  This tell me whether the result is returned in form of data or not.  So, this showed the problem lie with odbc_fetch_into().

Because when there is two rows, it work okay and allow the odbc_fetch_into() to show two rows.  When I delete one row, the odbc_fetch_row() saw one row and it does not allow the odbc_fetch_into() to show the one row.
 [2002-09-23 08:41 UTC] scott at abcoa dot com 
Forget the last comment I made, I typed down the wrong function, so use this comment instead of hte last comment.  Should have read it once more time to make sure I don't overlook something.

-----------------------------------------------------------

The webserver is made of IBM RS/6000, use IBM AIX and use IBM DB2 for database.

The odbc_fetch_into() worked fine.  To test it the functionality of the odbc_fetch_row(), I do the echo command followed by 'Result or No Result??? -->' then the odbc_fetch_row().  This tell me whether the result is returned in form of data or not.  So, this showed the problem lie with odbc_fetch_row().

Because when there is two rows, it work okay and allow the odbc_fetch_into() to show two rows.  When I delete one row, the odbc_fetch_row() saw one row and it does not allow the odbc_fetch_into() to show the one row.
 [2002-09-26 10:32 UTC] scott at abcoa dot com 
I found one interesting observation when I write a short test script.  It showed that if I use the odbc_fetch_row() only, it work fine.  It showed that if I use the odbc_fetch_into() only, it work fine.  It showed that if I use both the odbc_fetch_row() and odbc_fetch_into(), it showed a minor problem, that is not being able to display one row if there is only one row.  But work fine when there's two rows or more.
 [2002-09-26 10:47 UTC] kalowsky@php.net 
can you please make a sql log file and post the results of this?  It would make debugging this a lot easier :)
 [2002-09-26 10:57 UTC] scott at abcoa dot com 
I have found no sql.log file on this webserver.  Any comments or suggestion?
 [2002-09-26 11:01 UTC] scott at abcoa dot com 
To my dismay, I thought that including hte counter as the 2nd paramater to the odbc_fetch_row() function would fix this problem but it turned out that it doesn't.  It turned out that it help a little bit but it is only an intermitted problem.
 [2002-09-26 11:11 UTC] scott at abcoa dot com 
Disregard my last comment, the bug workaround still work. I made the typo in the counter.  So, that leave the original bug as unchanged.
 [2002-09-26 11:46 UTC] kalowsky@php.net 
Creating a sql.log is typically defined in your odbc.ini file, per DSN.  You may have to alter that to turn on logging.  As per the specific lines, that depends upon your vendors specific implementation.
 [2002-09-26 11:56 UTC] scott at abcoa dot com 
Oh! That's what it is.  No, I do not use the iODBC or OpenLink or anything of that sort.  There is no such as odbc.ini feature for IBM DB2.  I use this configure command before compiling PHP.

--clip--
./configure 
   --with-apache=../apache_1.3.26
   --with-ibm-db2=/usr/lpp/db2_06_01
   --with-openssl=../openssl-0.9.6d
   --with-mcrypt=../libmcrypt-2.5.2
   --without-mysql
   --with-config-file-path=../../apache/conf
   --enable-track-vars
   --with-curl
   --with-xml
--clip--
 [2002-09-26 15:53 UTC] kalowsky@php.net 
I'm not intimately familiar with the DB2 system, but there has to be a way to turn on ODBC logging.  This is a fairly standard debugging method.  Can you please check your documentation for it... it would make tracking this bug down infinately easier.
 [2002-09-27 12:16 UTC] scott at abcoa dot com 
I looked at few IBM books and IBM website and could find no such documentation about sql.log.  I also tried typing in the command "find . -name '*log' -print" and got a few IBM DB2 logs but they aren't related to sql.log.  Right now, I'm out of luck.  Someone else will know more about it better than I do.
 [2002-10-02 12:06 UTC] kalowsky@php.net 
Updating summary
 [2003-01-27 14:37 UTC] ranson at ea dot com 
I am having trouble with this as well, and have put in the bug workaround.  It seeks to work but I have noticed that it skips my first row and duplicates my last row.
 [2003-03-04 10:36 UTC] kalowsky@php.net 
Any chance you can try building with unixODBC as the driver, and connecting via that?  It seems to be the recommended means from IBM for connecting to DB2 systems.
 [2003-03-05 14:37 UTC] scott at abcoa dot com 
I'm not sure if I would want to try it.  Seem that I would need to use the driver manager and the driver.  It reminded me of OpenLink that became too much and I threw it out in the past.

I like the idea of having PHP's ODBC to work with DB2 by using the '--with-ibm-db2' prefix because it give me fewer softwares to work with.  I mean DB2 is not only database I had to deal with, but of some different database softwares as well as some for Windows.  I mean no offense.

I didn't really have that problem way back in the past.  Maybe the problem will fix itself in the near future.  Who know!
 [2003-03-05 16:38 UTC] kalowsky@php.net 
To answer some of the comments in here, yes unixODBC is a Driver Manager much in the same vain as iODBC.

The reason for asking is that while PHP does support DB2, I (as the developer) have no direct access to a DB2 machine to test if anything at all works on it.  The unixODBC DM is actually the suggested and prefered method by IBM for connecting to a DB2 installation, not directly through library linking like you do in a --with-ibm-db2 option.  

The point of using a Driver Manager though is to remove the headaches of using a different database on a per machine basis.  


But again absolutely nothing has changed between odbc_fetch_row functionality from 4.0.6 and 4.2.3, hence I'm wondering if it's a driver issue.
 [2003-03-10 20:41 UTC] sniper@php.net 
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
 [2003-03-11 08:49 UTC] scott at abcoa dot com 
Lost track of time, so sorry about that.  What we're going to need is more people who are experiencing this problem.

In answer to your question, I'm not sure if it is a driver issue or not because I have not upgraded the AIX nor have I upgraded the DB2 driver nor have I upgraded the DB2 software.  I'm waiting for version 9.1 to come out and buy it, whew, it's a pretty expensive software.  

The only thing changes from that time of version 4.0.6 to 4.2.3 was the inclusion of the '--with-mcrypt' option to the configure command but this doesn't seem to be the cause of the problem because they are not related.  We had one other user in this bug report who reported this problem.

So, go ahead and put this bug in inactive status or something until someone can step forward with the problem.  I don't have a solution to this problem.

Thanks,
 Scott 

P.S.  I have noticed that PHP have a built-in programming script that allow PHP to create a formatting and datas into a PDF then generate a PDF file.  Maybe PHP developers can do that similar thing by coming up with some ideas to create a PHP Database or a PHP CVS file that can act as a database.  

The logic shouldn't be too difficult to come up with and it could help to depend less on the 3rd party database and instead more on the PHP.  It is just an idea but not a bad idea...  I would love to hear about it one day.
 [2003-06-20 11:24 UTC] scott at abcoa dot com 
I was going to close this bug until I saw that there is 3 people out of 3 who are able to reproduce this problem.  So, I decided to leave this open unless otherwise is closed by the developer at php.net because there are other people out there who are still struggling with this and are not as fortunate.

The reason I'm going to close this bug is because I'm dumping IBM DB2 and make the move to Relexus Linter (DB software in Russia).  It became appearant that it is a better software than IBM DB2 in many ways.  Linter is smaller, use less maintainance, less headache, cost less, less problem with license, use less memory and work much faster on the same machine regardless of whether the table in the database is very large or not.

Good Luck!
 Scott
 [2003-06-23 21:14 UTC] sniper@php.net 
Like Mr. Kalowsky said, people should be using 
 unixODBC anyway with IBM DB2 (if they even suggest that themselves too, we really should consider removing the not-so-good DB2 support altogether..?)

Closing this for now. If someone else thinks it's worth
to fix this, feel free to open new report..and donate some money to Dan. :)
 [2003-06-24 10:21 UTC] kalowsky@php.net 
Sniper you like me, you really like me :)


I won't open the can of worms that is remove the --with-ibm-db2 option until I have a more viable solution then what is currently enabled.  So for those of you reading this in the future, worry not (yet)!
 [2003-06-24 10:25 UTC] scott at abcoa dot com 
Then the matter is settled.  It would have been so cool to have table in text file where everything is arrange by x and y, just like the spreadsheet for an example.  If everyone use this then we wouldn't have much need for thousands of database softwares.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Thu Apr 25 19:01:33 2024 UTC