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

History Show all quoted text
  Thu Apr 19 05:58:03 2012 DAMI [...] cpan.org - Ticket created
Subject: OCI_FETCH_RELATIVE is "sticky" (affects the following fetches)
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.
  Thu Apr 19 11:22:15 2012 DAMI [...] cpan.org - Reference to ticket #76410 added
  Fri Apr 20 03:53:04 2012 bohica [...] ntlworld.com - Correspondence added
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
  Fri Apr 20 03:53:06 2012 The RT System itself - Status changed from 'new' to 'open'
  Sat Apr 21 08:02:02 2012 laurent.dami [...] free.fr - Correspondence added
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>
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().
  Sat Apr 21 08:59:58 2012 bohica [...] ntlworld.com - Correspondence added
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
  Sun Apr 22 04:09:13 2012 bohica [...] ntlworld.com - Correspondence added
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
  Sun Apr 22 04:09:14 2012 bohica [...] ntlworld.com - Status changed from 'open' to 'patched'
  Sun Jun 24 04:43:32 2012 bohica [...] ntlworld.com - Status changed from 'patched' to 'resolved'
  Sun Jun 24 04:43:32 2012 bohica [...] ntlworld.com - Fixed in 1.45_00 added