[PHP-DB] Sybase CALL statement problems
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, , 0, , 0, , '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. ANY thoughts on this matter would be appreciated. Anthony Robins Using PHP 4.3.4 on Windows 2000 Server. -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Sybase CALL statement problems
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, , 0, , 0, , '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
Re: [PHP-DB] Sybase CALL statement problems
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 (brbr); 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: [EMAIL PROTECTED] To: php-db@lists.php.net Subject: Re: [PHP-DB] 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, , 0, , 0, , '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
Re: [PHP-DB] Sybase CALL statement problems
Anthony Robins wrote: 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 (brbr); 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. [snip] (silly question) a flush() does nothing? You could also try turning on output buffering, and then just ob_flush()'ing when done (and turn it back off). http://www.php.net/manual/en/function.flush.php mentions some caveats (specifically - some that may apply to you - w32 servers, and mod_gzip). The fact that adding whitespace 'helps' really screams it's a buffering problem IMO. http://www.php.net/odbc_longreadlen mentions truncation, but it's talking about TEXT/BLOB and the likes, since you *can* get the full results, I doubt this is meaningful. 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
