I would gowith the general hash pass in as some DB have stuff like commit,
delete etc orthers are just simple commands
as well some do not have offsets
so for ORacle I would just have two params
fetch_orient and fetch_offset
so the code would look like this
while (my ( $i,$c
)=$sth->fetch_scroll({fetch_orient=>OCI_FETCH_NEXT,fetch_offset=>0})){...}
in the case of oracle
fetch_orient could be any of the following
OCI_DEFAULT - has the same effect as OCI_FETCH_NEXT
OCI_FETCH_CURRENT - gets the current row.
OCI_FETCH_NEXT - gets the next row from the current position. It is the
default (has the same effect as OCI_DEFAULT). Use for a non-scrollable
statement handle.
OCI_FETCH_FIRST - gets the first row in the result set.
OCI_FETCH_LAST - gets the last row in the result set.
OCI_FETCH_PRIOR - gets the previous row from the current row in the result
set.
OCI_FETCH_ABSOLUTE will fetch the row number (specified by fetchOffset
parameter) in the result set using absolute positioning.
OCI_FETCH_RELATIVE will fetch the row number (specified by fetchOffset
parameter) in the result set using relative positioning.
cheers
John Scoles
> On Fri, Mar 14, 2008 at 5:53 AM, <[EMAIL PROTECTED]> wrote:
>
>> I have been playing about with scrollable result sets (Cursors)
>> in Oracle/OCI and have noticed that there has been some discussion
>> about
>> it before on the list
>>
>>
>> You can find the discussion here
>>
>>
>> http://perl.markmail.org/search/?q=list%3Aorg.perl.dbi-dev+fetch_scroll#query:list%3Aorg.perl.dbi-dev%20fetch_scroll+page:1+mid:xqwmgau3zesiyo7n+state:results
>>
>> and here
>>
>>
>> http://perl.markmail.org/search/?q=from%3A%22Tim+Bunce%22+scroll+cursor#query:from%3A%22Tim%20Bunce%22%20scroll%20cursor+page:1+mid:t3xvtu3rcqarszsx+state:results
>>
>>
>> Reading through these I see that basically each Database has its own
>> flavour or scrollable results set from a select i.e.
>>
>> Informix Scrollable and updateable
>> MySQL semi Scrollable
>> Oracle Scrollable and read only
>> SQLServer Scrollable and read only
>> Scrollable and updateable
>>
>> So my proposal is to stub in
>>
>> fetch_scroll
>>
>> in DBI
>>
>> and let the DBD drivers write their own implementation
>>
>> This would be the same as "bind_param_inout_array" which is stubbed in
>> but
>> not implemented in DBI
>>
>> The proposed sub would be like this
>>
>> bind_param_inout_array => { U =>[1,2,'[, \%attr]'] }
>>
>> so there will be an attribute param to pass in any commands/setting that
>> are needed for the fetch.
>>
>> The advantage of this is we get something that would be customized for
>> each DBD implementation of course the disadvantage is we do not have a
>> pure Perl implementation of his functionality.
>>
>> Any thoughts,comments or even insults;) are welcome
>>
>
> Sounds good to me. Will there be a standard set of 'scroll actions'?
>
> FETCH_NEXT
> FETCH_PREV
> FETCH_FIRST
> FETCH_LAST
> FETCH_CURRENT
> FETCH_RELATIVE
> FETCH_ABSOLUTE
>
> (Any others? That's the set for Informix.)
>
> $sth->fetch_scroll(FETCH_xxx [, $offset]);
>
> Or do we need a more general hash to pass values in?
>
>
>
> --
> Jonathan Leffler <[EMAIL PROTECTED]> #include <disclaimer.h>
> Guardian of DBD::Informix - v2008.0229 - http://dbi.perl.org
> "Blessed are we who can laugh at ourselves, for we shall never cease to be
> amused."
>
