On Thu, 08 May 2008 14:52:56 +0200, Jerry Stuckle
<jstucklex@attglobal.net> wrote:

> Rik Wasmus wrote:
>> On Thu, 08 May 2008 03:26:24 +0200, Rik Wasmus
>> <luiheidsgoeroe@hotmail.com> wrote:
>>
>>> On Wed, 07 May 2008 20:43:45 +0200, <FeelLikeANut@gmail.com> wrote:
>>>
>>>> I'm using the example on the following page for selecting and fetching
>>>> a large data object. <http://publib.boulder.ibm.com/infocenter/db2luw/
>>>> v9/index.jsp?topic=/com.ibm.db2.udb.apdv.php.doc/doc/t0023504.htm>
>>>>
>>>> Here's what I've tried:
>>>>
>>>>
>>>> $avatarFile = tempnam('', '');
>>>> $avatarSteam = fopen($avatarFile, 'wb');
>>>>
>>>> $stmt = $dbh->prepare('SELECT user_avatar FROM users WHERE user_id =
>>>> 29');
>>>> $stmt->execute();
>>>> $stmt->bindColumn('user_avatar', $avatarSteam, PDO::PARAM_LOB);
>>>> $stmt->fetch(PDO::FETCH_BOUND);
>>>>
>>>> var_dump($coverSteam);
>>>>
>>>> Ideally, $coverSteam should be a stream to a temporary file containing
>>>> the large data, but instead it's coming out as a string. And holding
>>>> the large data as a string in memory is exactly what I'm trying to
>>>> avoid. What am I doing wrong and how do I fix it? (I'm using SQLite,
>>>> in case it matters.)
>>>
>>> I'll see if I can reproduce this tomorrow, in the mean while: a big
>>> report that isn't yet solved seems to be filed:
>>> http://bugs.php.net/bug.php?id=40913
>> s/big/bug/
>> It's late.....
>
> Hmmm, over a year old and just assigned? Doesn't seem to be a very high
> priority with them. Or maybe it's really tough to fix.

Indeed. Just verified it here, it still doesn't work in 5.2.4. A shame, I
was just going to use it in a project next week... It seems almost every
PDO driver has had this issue, however, for MySQL it's not fixed.

Perhaps the OP can abuse INTO DUMPFILE in MySQL if both webserver &
database are on the same machine.
--
Rik Wasmus