Why Apply a Patch?

---

This question has been posed by many people when they realize that Apps 11i can become a patch hungry monster. The argument has been made that it does not look like it is broken. "We are not having any problems." "We are stable." "Why introduce the chance of something breaking?" "We never have to patch Windows <insert version here> or any of our other software." "Oracle just releases buggy unstable products."

Every company releases buggy software. There is no way that a company can foresee all of the ways that a company will use its software or test every combination of situations under which it will be run. With a product as powerful, flexible, and complex as Oracle E-Business Suite, this is particularly the case. The simple number of different combinations of products that a company can license together combined with the number of OSs under which they can be run (not to mention the different ways that it can be customized to meet specific needs) means that even trying to test all of the eventualities would take a team of dozens of people working full-time at testing and the product would never come to market. The best that can be hoped for is that the testers will find the biggest bugs that the majority of the eventual users will likely run into and fix those. But what happens when a client company discovers a shortcoming in a set of reports and requests an enhancement? What happens when a company discovers a bug that only presents itself under a certain set of circumstances?

What happens? Patches happen.

You apply patches to stay current on new features and bug fixes. I do not suggest that you rush right out and apply every one-off patch that comes out for every product that you have installed. Sending these patches through the whole process would mean that not only would you have to have an Apps DBA dedicated to nothing but patching applications, but also functional people and developers whose jobs it is to do nothing but test the effects and side effects of installing all of the patches that might be able to be applied to a system. This is particularly true if you have a significant number of modules implemented at your business.

Oracle releases patches regularly. You can be sure that if you set yourself up on a quarterly patching schedule, you will have several patches, even if you have a minimal number of products licensed, to apply every quarter. If you keep up with just the minipacks that are released every quarter, you will have sufficient practice with ADPATCH and patching in general to keep you on your toes.

Is this just an exercise in practicing patching and keeping on your toes? Not really. Remember, a maintenance pack rolls up all of the minipack changes that have occurred since the last maintenance pack along with that previous version and packages it together for ease of installation at your site. ADPATCH determines what versions of files you have on site, checks tables in the database to determine what minipacks you have applied, determines what it needs to apply in your particular environment to bring you up to the current release number, and applies it. You can severely limit the work that ADPATCH has to do and, by extension, the time that needs to be set aside for a migration to the next release number if you stay current or even nearly current on the products that you have installed and their minipack releases.

---