 | |||
|
|
||
| |||
| |||
| |
|
Home > Oracle Database / Applications News > Oracle developer tips: Ten things you should never do |
| |
|
|
|
|
| Oracle Database / Applications News: |
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||
WORCESTER, Mass. -- For the Oracle developer, customizing Oracle E-Business Suite applications can be very dangerous, especially if that Oracle developer is prone to making common rookie errors, experts say. Oracle developers attending the New England Oracle Applications Users Group (NEOAUG) conference Monday got a quick refresher on some of those mistakes from Sridhar Bogelli, the founder and chief executive officer of Apps Associates, a Southborough, Mass.-based application development consultancy. Bogelli, a former Oracle employee whose background includes 13 years of working with Oracle applications as a developer, DBA, functional consultant and project manager, said that by heeding his "Do Not Do" list, developers will avoid production-related problems that can really hurt a business. Don't run non-select commands in production without testing first Occasionally developers need to run non-select commands on standard tables, such as an update on an insert, Bogelli said. The consultant said developers should never do this without testing the commands first on DEV or Test Instance. "Make sure it works, and then run it in production," Bogelli said. Never change the definition of a standard database object "You never should have a need to change a standard table," Bogelli said. "If you change a standard table, it's definite that the next relevant Patch you apply is going to break the system." Occasionally, he added, developers may need to change a standard package to customize an application. Folks that need to do that should begin by creating a new package. "But if you do change a standard package, I would say that in a 1,000-line standard package if you add five lines, make sure you add clear comments before the five lines you have added," he said. Don't leave open update commands in code editors When developers have an open update command sitting in the Toad editor, there is a risk of running that update unintentionally, he added. "Have only your Select commands open in an editor," he said. "When you have an update, just comment it out. When you need to run it, just uncomment it for those few seconds." Bogelli added that all data manipulation commands will have to be built as scripts and tested thoroughly by the time they are run in production.
Don't execute scripts in production by yourself When developers are faced with the task of running something in a production instance, it's always good to ask a colleague to sit next to you and watch out for any mistakes. Two pairs of eyes are better than one, he said. Don't forget how to deal with commands that take a long time to execute Bogelli said that any command expected to take more than five minutes to execute will need to be built as a concurrent program or run under the VNC editor. "Don't run [time-consuming commands] on a Toad or a SQL*Plus session," he said. "It's good to run it in the background." Don't forget to protect passwords Bogelli said it's important not to give out production passwords to anyone unauthorized in the company or outside the company. Do not leave your desk when you have a connection open on production Before leaving the desk, execute the script needed and close the connection immediately. In addition to the obvious security concerns, leaving a connection open and unattended can cause developers to forget the context of the session when they return. "You might come back and start typing in commands thinking that it's a development instance [when it's not]," Bogelli said. Don't give out customer data Never give the data (financial numbers, credit cards, customer list, etc.) to anyone other than the authorized client personnel, especially via e-mail, Bogelli said. Don't forget to maintain version control Maintain a good version control for all your code and document at least the essential details about your programs, he said. "Don't let the production instance be the only source of version control," he said. Develop Prod-sensitive connections to third party interfaces Oracle systems have live connectivity with third party systems like POS, 3PLs, payment systems etc., Bogelli said. "Make sure that these interfaces get inactivated when production databases are copied to other instances," he explained. "One way to do is to check for the SID name from the v$session table and inactivate the connection if it is not a production one."
|
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
 |  |  | |  | |  | |  | |  | |  | |  | |  | |
|
|
About Us | Contact Us | For Advertisers | For Business Partners | Site Index | RSS |
|
|
||
|
|||||||
