Opps my night for boo-boos
Anyway here is my whole message
Ok one bigger patch to DBI comming up
I guess I can use the following for
SQL_FETCH_NEXT
SQL_FETCH_PRIOR
SQL_FETCH_FIRST
SQL_FETCH_LAST
SQL_FETCH_ABSOLUTE
SQL_FETCH_RELATIVE
which are generic enough for almost every Database
Again like my first proposal we could have these entered in as attribs or
we could have a simple two param sub like this
fetch_scroll($oreinetation,$offset);
or a three one like this
fetch_scroll($oreinetation,$offset,{attribs});
I will work both out and get back to the list one it the only proble I see
is knowning were one is in the cusor
cheers
>
>
>
>> On Fri, Mar 14, 2008 at 08:53:04AM -0400, John Scoles wrote:
>>>
>>> So my proposal is to stub in
>>> fetch_scroll
>>> in DBI
>>> and let the DBD drivers write their own implementation
>>
>> I'd _much_ rather one or driver implemented the functionality as
>> driver-private methods before we try to define the DBI by guesswork.
>>
>> I'd also _much_ rather fetch_scroll() wasn't added until a fallback
>> implementation existed for it in the DBI. In the same way that
>> execute_array() and related methods weren't added until there was a
>> fallback implementation in the DBI.
>>
>> It can't be that hard to add read-only cursor support.
>> The guts of it would be something like...
>> - A $sth->{FetchedRows} attribute containing an array ref
>> - dbih_get_fbav() would see that attribute and instead of
>> reusing the same row buffer would allocate a new one and push it
>> on the end of the $sth->{FetchedRows} array.
>> - fetch_scroll() then just needs to have a concept of 'current row'
>> and can use $sth->{Active} to tell if there may be more to fetch.
>>
>>> This would be the same as "bind_param_inout_array" which is stubbed in
>>> but
>>> not implemented in DBI
>>
>> That's an (unfortunate) exception to the rule :)
>>
>> Tim.
>>
>
>
>
