> -----Original Message----- > From: Robert Klemme [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 29, 2005 2:43 PM > To: maxdb > Subject: Re: COMMIT inside DBPROC? > > 2005/9/29, Anhaus, Thomas <[EMAIL PROTECTED]>: > > Robert Klemme wrote : > > > > >Hi, > > > > > >it seems COMMIT or COMMIT WORK are not allowed inside a DBPROC. Is > > >there a way to actually commit work inside a DBPROC? As > far as I can > > >see there is SUBTRANS but data is not finally commited until the > > >enclosing top level TX commits. Is this true or did I > miss something? > > > > > >After looking a bit closer at MaxDB TX log management it seems, I > > >don't need serveral transactions. I use them with Oracle because > > >rollback space is a circular buffer and inactive entries are > > >overwritten so it makes sense to keep TX small. But in > MaxDB log space > > >is freed only during log backup. So the strategy to split > up DELETE > > >operations that potentially delete a large number of > records does not > > >make sense with MaxDB anyway. Please correct me someone > if I'm wrong. > > > > > >Thanks a lot! > > > > > >Kind regards > > > > > >robert > > > > > >-- > > > > you can execute a COMMIT WORK from a DBPROC via dynamic sql : > > > > VAR > > COMMIT_STMT CHAR(20); > > > > COMMIT_STMT = 'COMMIT WORK' > > EXECUTE COMMIT_STMT; > > Duh! I didn't think of this solution. > > What about the other point - saving log space? >
On the logvolume only redo-information is written (the one you need for a rollforward in case of a recovery). Undoinformation is written in undofiles on the datavolumes. Therefore it makes sense that the undoinformation in the datavolumes grows not too much in order to not affect normal database operation. Kind regards, Martin -- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
