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?