|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
[2015-10-12 19:31 UTC] ashnazg@php.net
[2015-10-12 20:26 UTC] ashnazg@php.net
[2015-10-13 02:05 UTC] sixd@php.net
-Status: Open
+Status: Feedback
-Assigned To:
+Assigned To: sixd
[2015-10-13 02:05 UTC] sixd@php.net
[2015-10-13 15:05 UTC] ashnazg@php.net
[2015-10-14 05:38 UTC] sixd@php.net
[2015-10-14 21:42 UTC] ashnazg@php.net
[2015-10-25 04:22 UTC] php-bugs at lists dot php dot net
[2015-10-29 15:36 UTC] ashnazg@php.net
[2015-11-02 18:15 UTC] sixd@php.net
-Status: No Feedback
+Status: Feedback
[2015-11-02 18:15 UTC] sixd@php.net
[2015-11-15 04:22 UTC] php-bugs at lists dot php dot net
[2017-01-25 00:05 UTC] sixd@php.net
-Status: No Feedback
+Status: Open
-Type: Bug
+Type: Documentation Problem
[2017-01-25 00:05 UTC] sixd@php.net
|
|||||||||||||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Sun Oct 26 09:00:01 2025 UTC |
Description: ------------ When using the "while !$lob->eof() { $lob->read($chunk); fwrite($chunk) }" loop to read the contents of a long CLOB that contains only single-byte characters, everything works fine (can get a 10,000,000 char clob no problem). However, if the CLOB contains mutibyte characters, it seems as though the size of the first LOB->read() call is as far as the loop will go. Thus, reading the LOB in chunks does not succeed, though no errors are given. A workaround is to use LOB->size() to determine the full size of the CLOB, and then do one LOB->read() on a larger size chunk (thus getting the entire CLOB in one single, huge read). I have to guess this is hard on memory usage when large CLOBs are in play, and is thus not a desirable workaround. Test script: --------------- (will provide a PHPT in a PR)