The following script retrives a few columns from a table (via ODBC Visual Foxpro driver) including a field named 
"id" of SQL-type CHAR (length is 15) and a field named "desc" of SQL-type LONGVARCHAR, which is the interesting one:
<?
	$sql = "select * from thetable";
	$conn = odbc_connect("thesource", "", "");
	if (!$conn) {
		echo '<h2>Error connecting to database.</h2>';
	} else {
		$curs = odbc_exec($conn, $sql);
		if ($curs) {
			echo '<center><table border>
			<tr><th>ID<th>Description</tr>';
			while (odbc_fetch_row($curs)) {
				$id = odbc_result($curs, 'id');
				$desc = odbc_result($curs, 'desc');
				echo "<tr><td>" . $id . "</td><td>" . $desc . "</td></tr>\n";
			}
			echo '</table></center>';
		} else {
			echo 'Error querying datar.';
		}
	}
	odbc_close($conn);
?>
The "strange" behaviour is the following: Regardless how uodbc.defaultlrl and uodbc.defaultbinmode are set in php.ini,
the content of the field "desc" is inserted into output at the position of the line reading 
         $desc = odbc_result($curs, 'desc');
in my example. If odbc_result($curs, 'desc') is called once again, empty output until infinity is returned, whereas
subsequent calls to odbc_result($curs, 'id') work fine. I could not get PHP neither to assign the value of the field "desc" 
to a variable nor to pass it to a function (like rawurldecode()). I found reports on similar issues in the bug database
(bugs #330, #349 and #350), but they could not give me a valid hint. Then I read through some PHP source code, 
especially the function "void PHP3_UODBC_RESULT(INTERNAL_FUNCTION_PARAMETERS)" in file functions/unified_odbc.c, 
and I found out the following:
1. In line 1340 of unified_odbc.c, the data are returned via RETURN_STRINGL, but with duplicate set to 0. May, for some 
reason I could not figure out, this lead to an empty return string?
2. The passthru dump to the client is done in line 1382 (PHPWRITE...), and the function's return code is set via 
RETURN_TRUE - which results in a '1' if I use echo to output it. This part of code should only be reached if the preceding
switch()-block did not reach a RETURN_..., and with my "parameters" (field type LONGVARCHAR (I checked it!), 
binmode=2 and longreadlen=4096 (but the same with any other setting...), the code after the switch() block IS not reached;
it should execute the RETURN_STRINGL in line 1340. 
So I suspect the following: binmode and longreadlen are always 0 - they are initialized to these values in 
"int PHP3_RINIT_UODBC(INIT_FUNC_ARGS)" in line 298 and 299. 
"void php3_uodbc_fetch_attribs(INTERNAL_FUNCTION_PARAMETERS, int mode)", starting in line 474, should set them
to different values, but presumably does not.

The reason for the infinite output that occurs when I try to read the LONGVARCHAR field a second time may lie somwhere
in the ODBC driver - I suppose it does not reset some internal pointer. But that's not the problem - once I got it assigned
to a variable, I do not need to read it again.

So I hope this information helps you to find out, why PHP behaves this way.

Best regards, and thanks in advance
Michael Woecherl