|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
[2003-08-14 00:34 UTC] sniper@php.net
[2003-08-18 19:43 UTC] sniper@php.net
|
|||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Wed Oct 29 17:00:02 2025 UTC |
Description: ------------ Oracle 8.1.7 client on PHP server, PHP 4.2.3 talking to an Oracle 7.something server. I've found that when I loop through OCIFetchInfo to return all the rows of a query, that it gets to a particular row and then the OCIFetchInto() returns false indicating that there are no more rows. However - the exact same query via TOAD works fine. e.g. SELECT employee.swlogin, worklog.swworklogid, worklog.swobjecttype, worklog.swobjectid, worklog.swsubject, worklog.swnote, worklog.swaction, to_char(worklog.swdatecreated, 'yyyymmddhh24miss') as swdatecreated FROM sw_work_log worklog, sw_person employee WHERE worklog.swcreatedby = employee.swlogin AND employee.swlogin = 'mmccryst' AND worklog.swdatecreated >= to_date('20021003000000', 'yyyymmddhh24miss') AND worklog.swdatecreated < to_date('20021004000000', 'yyyymmddhh24miss') via PHP/OCI8 returns 6 rows. via TOAD returns 17 rows. When I add a line to the SQL to make it ignore the 7th result: AND worklog.swworklogid <> 268055 via PHP/OCI and TOAD it now returns 16 rows. The same phenomenon occurs if I try and pull back all the rows in one go via OCIFetchStatement(). If I reverse the <> to = so that I only want the row causing the problem (worklogid is unique) then TOAD gives me 1 row, PHP gives me none. The row isn't any different from any other row and only contains ASCII (swnote is a copy of the "export" command from a unix machine). Any thoughts?