Skip Menu |
 

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the DBD-Oracle CPAN distribution.

Report information
The Basics
Id: 76695
Status: resolved
Priority: 0/
Queue: DBD-Oracle

People
Owner: Nobody in particular
Requestors: DAMI [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: 1.45_00



Subject: OCI_FETCH_RELATIVE is "sticky" (affects the following fetches)
Download (untitled) / with headers
text/plain 815b
Something related to ticket 76410, but nevertheless a bit different : the relative step specified by OCI_FETCH_RELATIVE seems to be "sticky"; it affects the following cals to ->fetch(). my $sth = $dbh->prepare($sql, {ora_exe_mode => OCI_STMT_SCROLLABLE_READONLY}); $sth->execute; my @r1 = @{$sth->ora_fetch_scroll(OCI_FETCH_RELATIVE, 4)}; my @r2 = @{$sth->fetch}; # this is record 8, not record 5 !! my @r3 = @{$sth->fetch}; # this is record 12, not record 6 !! Together with ticket 76410, this seems to indicate that scrollable cursors are incompatible with regular methods of the fetch_* family; the only way to get correct data is to use various calls to ora_fetch_scroll(). This is quite unfortunate because we have to recreate by hand all the variants for fetching arrayrefs, hashrefs, slices, etc.
Download (untitled) / with headers
text/plain 1.2k
On Thu Apr 19 05:58:03 2012, DAMI wrote: Show quoted text
> Something related to ticket 76410, but nevertheless a bit different : > the relative step specified by OCI_FETCH_RELATIVE seems to be
"sticky"; Show quoted text
> it affects the following cals to ->fetch(). > > my $sth = $dbh->prepare($sql, {ora_exe_mode => > OCI_STMT_SCROLLABLE_READONLY}); > $sth->execute; > > my @r1 = @{$sth->ora_fetch_scroll(OCI_FETCH_RELATIVE, 4)}; > my @r2 = @{$sth->fetch}; # this is record 8, not record 5 !! > my @r3 = @{$sth->fetch}; # this is record 12, not record 6 !! > > Together with ticket 76410, this seems to indicate that scrollable > cursors are incompatible with regular methods of the fetch_* family; > the only way to get correct data is to use various calls to > ora_fetch_scroll(). > > This is quite unfortunate because we have to recreate by hand all the > variants for fetching arrayrefs, hashrefs, slices, etc.
Are you suggesting that the fetch method when used after fetch_scroll should ignore the previous relative fetch and fetch the next row? If so, this should be easy to change. I didn't write the scrollable cursor support and until now, I'm not aware of anyone actually using it so may be you have a chance to help us fine tune it. Martin -- Martin J. Evans Wetherby, UK
Subject: Re: [rt.cpan.org #76695] OCI_FETCH_RELATIVE is "sticky" (affects the following fetches)
Date: Sat, 21 Apr 2012 14:02:01 +0200
To: bug-DBD-Oracle [...] rt.cpan.org
From: laurent dami <laurent.dami [...] free.fr>
Download (untitled) / with headers
text/plain 982b
Le 20.04.2012 09:53, Martin J Evans via RT a écrit : Show quoted text
> Are you suggesting that the fetch method when used after fetch_scroll > should ignore the previous relative fetch and fetch the next row? If > so, this should be easy to change. I didn't write the scrollable > cursor support and until now, I'm not aware of anyone actually using > it so may be you have a chance to help us fine tune it. Martin
Yes, that's what I understand when I read the DBD::Oracle doc which says : "When the statement is executed you will then be able to use 'ora_fetch_scroll' method to get a row or you can still use any of the other fetch methods but with a poorer response time than if you used a non-scrolling cursor." So it seems to me that one should be able to use any of the ora_fetch_scroll variants to go to one specific position within the result set; after that, any of the regular fetch_* methods should just return the next rows which follow the current ora_scroll_position().
Download (untitled) / with headers
text/plain 1.2k
On Sat Apr 21 08:02:02 2012, laurent.dami@free.fr wrote: Show quoted text
> Le 20.04.2012 09:53, Martin J Evans via RT a écrit :
> > Are you suggesting that the fetch method when used after fetch_scroll > > should ignore the previous relative fetch and fetch the next row? If > > so, this should be easy to change. I didn't write the scrollable > > cursor support and until now, I'm not aware of anyone actually using > > it so may be you have a chance to help us fine tune it. Martin
> Yes, that's what I understand when I read the DBD::Oracle doc which says : > > "When the statement is executed you will then be able to use > 'ora_fetch_scroll' method to get a row or you can still use any of the > other fetch methods but with a poorer response time than if you used a > non-scrolling cursor." > > So it seems to me that one should be able to use any of the > ora_fetch_scroll variants to go to one specific position within the > result set; after that, any of the regular fetch_* methods should just > return the next rows which follow the current ora_scroll_position().
I'll have a go at making that change. By all means nag me via my CPAN email address at mjevans@cpan.org if you don't hear something by the middle of next week. Martin -- Martin J. Evans Wetherby, UK
Download (untitled) / with headers
text/plain 138b
Should be fixed in the subversion trunk which you can find a reference to in the DBD::Oracle pod. Martin -- Martin J. Evans Wetherby, UK


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.