|
Buck, Actually, developers really shouldn't have authority to any production object - bad programs can mess up production data just as quickly as a bad restore. i've been in different places where i've had full authority to everything to no authority at all and everywhere in between. I personally like having a free reign, and don't abuse the authority - I trust myself, and most of the folks i've done work for trusted me to do the right thing as well. But I have on the rare occasion accidently 'dirtied' production data and had to 'fix' it. It's not fun, but when i have that much power, I usually am very careful and deliberate and have plenty of CYA procedures in place. But I also realize that, for public companys, the users--> managers must have ownership and be accountable for all data in a system. I currenly have very little authority outside my own little world and with no change management/promotion/installation software in place, it makes my job tougher - especially when I'm trouble shooting production problems. but I understand the issue and know my place. :( rick -----original message--------- > Never name the trigger program the same as the file though. First time > you go to update the trigger program and you do a RSTOBJ, don't specify > *PGM, and end up also restoring the test data from the development machine > over the top of your production data, you learn fast. Another reason developers should not have authority to production database files? --buck
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.