|
-----Original Message----- From: Leif Svalgaard <leif@leif.org> To: midrange-l@midrange.com <midrange-l@midrange.com> Date: Monday, August 20, 2001 2:48 PM Subject: Re: triggers within commit cycles >the point is that the business rules are only turned off for the repairing >program >not for the production programs. The 'repairing' program could also be a >program >that is testing a new business rule. We may not have a disaster. My point is >that using triggers is too much of an all-or-nothing approach. There are, of >course, many other advantages to use an I/O module instead of raw, native >I/O performed directly by the application programs. I hope we don't need to >have a discussion about that. you test new business rules in the production environment? Is there no hope for you? <vbg> yes, the trigger is all or nothing. Journals are all or nothing. The idea of a transaction IS all or nothing. Everything else is architecture. It sounds like you want the "do maybe" opcode re-instated... ;-) =========================================================== R. Bruce Hoffman, Jr. -- IBM Certified Specialist - AS/400 Administrator -- IBM Certified Specialist - RPG IV Developer "America is the land that fought for freedom and then began passing laws to get rid of it." - Alfred E. Neuman
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.