Re: Sybase CALL statement problems

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I have checked my logfiles, and everything seems to be running
smoothly and error free.  The truncation occurs wether I use the
odbc_result_all function or something like:

WHILE( odbc_fetch_row( $CallTest ) ):
	FOR( $ii = 1; $ii <= odbc_num_fields( $CallTest ); ++$ii ):
		PRINT (odbc_field_name( $CallTest, $ii ) ." = ". odbc_result(
$CallTest, odbc_field_name( $CallTest, $ii ) ) . "<br>");
	ENDFOR;
	PRINT ("<br><br>");
ENDWHILE;


So it is not a problem with odbc_result_all.  I have compared the
source of the resulting page with the output buffering generated file
and it is definitely truncating, no <-- or <span display="none"> or
anything similar... In one case, the browser page source was 12,196
characters in length compared to 37,127 characters in the output
buffer file. 

As you said, there are some 'hackish' things that I have tried such
as tacking on several thousand characters of whitespace to the end of
the output, which still truncates, but ends up truncating in the
middle of the whitespace...  I refuse to resort to something like
this.

The parameters for mladselmeans? nothing too fancy, just passing it a
bunch of minimum and maximum values for various lookups and
calculations that the CALLed statement does...

Anthony Robins

---- Original Message ----
From: martin.norland@xxxxxxxxxx
To: php-db@xxxxxxxxxxxxx
Subject: Re:  Sybase CALL statement problems
Date: Tue, 29 Mar 2005 09:33:53 -0600

>Anthony Robins wrote:
>> When retrieving ODBC results from Sybase SQL Anywhere 6 and 9 from
>a
>> CALLed procedure, the output to the browser is being arbitrarily
>> truncated. 
>> 
>> <?php 
>> $DataSourceUserID = "user";
>> $DataSourcePassword = "pass";
>> $DataSourceName = "source";
>> 
>> $ODBCConnect =
>>
>odbc_connect($DataSourceName,$DataSourceUserID,$DataSourcePassword);
>> $CallSQL = "CALL mladselmeans( '', 0, 9999, 0, 99999999, 0,
>99999999,
>> 'mladsite', 1 )";
>> $CallTest = odbc_exec( $ODBCConnect, $CallSQL );
>> odbc_result_all($CallTest);
>> ?>
>> 
>> The resulting output does contain proper data, but as I said, it
>> simply gets chopped off at a seemingly random point (I have had it
>> chop anywhere from 1500-25000 characters off).  The amount of
>> truncation seems to vary depending on the results of the CALL, and
>> when the results are the same, the truncation is the same.  Perhaps
>> the strangest thing is that I know for a fact that all of the data
>is
>> being returned by Sybase... If I use output buffering and send the
>> contents of the buffer to a file before the end of the script, all
>of
>> the data makes it into the file, but still not to the browser. 
>> Trying to free the odbc resource or close the connection results in
>> no output at all.
>
>A number of possibilities come to mind - some hackish unfortunately. 
>You  say with output buffering the contents make it into the file,
>but 
>not the web browser.  Have you checked your logfiles to see if there
>is 
>anything - perhaps the script is terminating early, etc.  Print 
>something after the table as well, see if that doesn't help.  It 
>certainly sounds like something is being buffered.  There are reports
>
>that this function doesn't return the total number of rows correctly,
>
>but nothing more on that as to whether that indicates a problem or
>not.
>
>http://www.php.net/manual/en/function.odbc-result-all.php
>
>Also - you may want to view the source, or open that output buffering
>
>generated file in a web browser - and see if the same problem
>persists. 
>  It could just be bad data inside the database that's causing for
>e.g. 
><!-- or <span display="none"> or who knows what - to make it *appear*
>
>that the content is truncated.
>
>Obviously - you could try something hackish where you output buffer
>to a 
>file, then emit the file to the browser - but if its all getting into
>
>the file I'd say the problem lies elsewhere, and that *shouldn't*
>work 
>anyway, or if it does it's just a buffering problem in the first
>place.
>
>definitely check all logs. twice.
>
>Incidentally, what is with the parameters to mladselmeans - it looks 
>very strange :)
>
>cheers,
>-- 
>- Martin Norland, Sys Admin / Database / Web Developer, International
>
>Outreach x3257
>The opinion(s) contained within this email do not necessarily
>represent 
>those of St. Jude Children's Research Hospital.
>
>-- 
>PHP Database Mailing List (http://www.php.net/)
>To unsubscribe, visit: http://www.php.net/unsub.php
>

-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



[Index of Archives]     [PHP Home]     [PHP Users]     [Postgresql Discussion]     [Kernel Newbies]     [Postgresql]     [Yosemite News]

  Powered by Linux