I would disagree with that having done it several times. If a program is reasonably structured to begin with it is not too hard to retro-fit transaction logic. In the example given simply putting the transaction inside of the loop rather than outside would have solved the problem.
The first step in using transaction logic needs to be defining the transaction. Again, using the batch program mentioned before the transaction is probably the update done on each record not the entire batch. If not then transaction sets are probably not the way to go. You also need to keep in mind that U2 does not allow for nested transactions like SQL/ADO programming does. Rich Taylor | Senior Programmer/Analyst| VERTIS 250 W. Pratt Street | Baltimore, MD 21201 P 410.361.8688 | F 410.528.0319 [EMAIL PROTECTED] | http://www.vertisinc.com Vertis is the premier provider of targeted advertising, media, and marketing services that drive consumers to marketers more effectively. "The more they complicate the plumbing the easier it is to stop up the drain" - Montgomery Scott NCC-1701 > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:owner-u2- > [EMAIL PROTECTED] On Behalf Of Stevenson, Charles > Sent: Thursday, June 23, 2005 10:37 AM > To: [email protected] > Subject: RE: [U2] Best practice for Sequential IDs using TRANSACTION START > & COMMIT/RO... > > In my opinion... > > NO : Retrofitting TRANSACTIONs into existing programs would be a > nightmare. > > YES: Definitely use them when writing a new application from scratch and > even a new sub-system enhancement if it is pretty much self-contained > with limited, well-defined interfaces that write into the parent system. > > NO : I would caution against writing them into new programs that are > enhancements to existing (sub-)systems. > > cds > > From: Les Hewkin > > we had a batch process that processed lots of data and I mean ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
