Skip to main content

Look, But Don't Touch

Joel Kallman had an interesting post about a customer who broke all of the rules and modified some constraints in the APEX_030200 schema.  In this case, there was a happy ending, as Joel went the extra mile to craft a custom patch to remedy the issue.  However, things don't always end up this way.

This reminds me of my early days with Oracle, when I used to work with the eBusiness Suite.  The first page of any documentation of the suite said something like this: "WARNING: Do not use SQL*Plus to modify any database object directly".  We used to laugh at this, as we used SQL*Plus & TOAD to modify these database objects several times a day, if not more frequently.

However, this was done on internal systems used to build demos.  If we messed something up - and boy did we ever - we could easily refresh the instance with little effort.

Fast-forward a few years to today:  FND & APPLSYS have been replaced by a single, much smaller schema called APEX_030200.  Despite this, the same rules apply:  NEVER modify anything in the APEX_030200 schema.  Period.  I always make it a point to emphasize this as much as possible during our training classes.

Now, if you MUST take a look at that schema - and many of you reading this will - please do it in a test environment that is not used for anything else.  This can easily be done by using VMWare or one of the many other virtual machine programs.  You can also do this in the Amazon Cloud.  It doesn't matter as much WHERE you set up a test instance, but rather that you DO set up a test instance, and then poke around there.  This way, nothing gets corrupted - now or in the future.

Comments

SydOracle said…
I recall amending Forms 3.0 inp files in an editor rather than through the application.

The point of rules is to make you think twice about what you are doing before you break them
January 30, 2010 at 10:32 PM
Byte64 said…
I agree in principle, however...

I mean, there should not be any need to stress the fact that who is changing things in the database using unsupported methods is embarking on an adventure of his own and there is no obligation for Oracle to restore things to a prior state. It's like saying if you jump off a cliff, you'd better off bringing your own parachute, don't expect the landing to be soft.

With this clear statement in mind, i spent most of the last 25 years "poking around" because that is the only way to understand things more deeply, it's the black box approach.

As you remarked however, this must be done in a controlled environment, where you can easily revert the system to its working state.

Clearly sometimes i happened to forgot to take a backup first... :-D
January 31, 2010 at 3:54 AM
Scott said…
I think we can all say that we've all modified something that we shouldn't have at some point in our careers. Sometimes it worked; others, well... not so much.

The main points that you both brought up is that

1) don't do it
2) when break rule #1, be REALLY careful and
3) understand that if you break it, you bought it, so to speak

As nice and good as the APEX team is, I don't think that they can afford to be in the business of writing custom patches to bail out customers time and time again.

- Scott -
January 31, 2010 at 10:24 AM
Anonymous said…
Thanks John for the interesting post. (and for your half of the excellent book "Pro Application Express).

I've recently encountered an issue within Apex which at the moment I can't see a way around without doing what you have said not to do!

I posted the question over on stackoverflow (http://stackoverflow.com/questions/2371115/what-options-do-i-have-to-change-wsdl-location-for-a-web-service-used-within-apex)

Is this the exception to the rule? or is there a better way to do this?
March 8, 2010 at 3:38 AM
Post a Comment

Popular posts from this blog

Custom Export to CSV

It's been a while since I've updated my blog. I've been quite busy lately, and just have not had the time that I used to. We're expecting our 1st child in just a few short weeks now, so most of my free time has been spent learning Lamaze breathing, making the weekly run to Babies R Us, and relocating my office from the larger room upstairs to the smaller one downstairs - which I do happen to like MUCH more than I had anticipated. I have everything I need within a short walk - a bathroom, beer fridge, and 52" HD TV. I only need to go upstairs to eat and sleep now, but alas, this will all change soon... Recently, I was asked if you could change the way Export to CSV in ApEx works. The short answer is, of course, no. But it's not too difficult to "roll your own" CSV export procedure. Why would you want to do this? Well, the customer's requirement was to manipulate some data when the Export link was clicked, and then export it to CSV in a forma...
76 comments
Read more

Manipulating Images with the... Database?

A recent thread on the OTN HTML DB Forum asked about how to determine the width & height of an image stored as a BLOB in an Oracle table. I mentioned in that thread that I have some code to manipulate an image stored in a BLOB column. This is particularly useful if you’re going to let users upload images, and you want to re-size them to display as a thumbnail. Thanks to Oracle interMedia , it is trivial to manipulate the width, height, and other attributes of images stored in an Oracle table. I’ve created a sample application here which demonstrates Oracle interMedia and HTML DB in action. Feel free to have a look. You can download this application from HTML DB Studio as well. Basically, this application allows you to upload images and perform an operation on the image as it is inserted into the PHOTO_CATALOG table. There are two places where some PL/SQL code is required: an After Submit process on page 2, and a procedure to display the images. Here is the PL/SQL for the After...
33 comments
Read more

Refreshing PL/SQL Regions in APEX

If you've been using APEX long enough, you've probably used a PL/SQL Region to render some sort of HTML that the APEX built-in components simply can't handle. Perhaps a complex chart or region that has a lot of custom content and/or layout. While best practices may be to use an APEX component, or if not, build a plugin, we all know that sometimes reality doesn't give us that kind of time or flexibility. While the PL/SQL Region is quite powerful, it still lacks a key feature: the ability to be refreshed by a Dynamic Action. This is true even in APEX 5. Fortunately, there's a simple workaround that only requires a small change to your code: change your procedure to a function and call it from a Classic Report region. In changing your procedure to a function, you'll likely only need to make one type of change: converting and htp.prn calls to instead populate and return a variable at the end of the function. Most, if not all of the rest of the code can rem...
5 comments
Read more