Actually you need to trap the rowcount before the commit, otherwise the
rowcount is back to either zero or 1. uisng SQL%ROWCOUNT works with both
implicit and explicit cursors.
"Richard Elliott" <richard.a.elliott_at_williams.com> wrote in message
news:8c132b3c.0310311220.10c3903c_at_posting.google.com...
> "Alkos" <azerty_at_nospam.org> wrote in message
news:<bntof1$m9i3_at_news.rd.francetelecom.fr>...
> > What about using a implicit cursor within a PL/SQL proc ?
> > Cursors have a fancy property called %ROWCOUNT
> >
> > On the other hand, what about enlarging your RBS (if you can) ?
> >
> > "Richard Elliott" <richard.a.elliott_at_williams.com> a écrit dans le
message
> > news: 8c132b3c.0310310519.2963db99_at_posting.google.com...
> > > I know the data is there somewhere. I'm running an update loop (5k
> > > rows/commit) to avoid the rollback segment too small issue. It works
> > > fine, but I have to do a count of the remaining rows to see if I need
> > > to loop again. It would be much faster if I could just see if the
> > > previous commit did 5k rows or not. How do I trap the "# of rows
> > > affected" from the commit ?
> > >
> > > Thanks !
>
> Let me add some more detail to explain why I ask the question and
> haven't considered the obvious. What I am doing is setting a flag in
> each row based on other values in the row. The table has 48 Million
> rows, and I expect to update about 5 million of them. No rollback
> segment is going to allow that to happen as one transaction. I am
> using a pl/sql procedure, ,but not a cursor. I don't think, (but I
> will try it), I can cursor up that many rows (5 million). The column
> is a new one and will be maintained by the ins/upd trigger going
> forward. Just need to get it initilized to start with. Thanks for all
> the feedback !
>
> Thanks for all the
Received on Sun Nov 02 2003 - 07:13:38 CST
