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.


Gary Myers 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
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
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 -
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 (

Is this the exception to the rule? or is there a better way to do this?

Popular posts from this blog

Thanks, ODC (Oracle Developer Community)!

I owe a lot of thanks to the ODC - which stands for Oracle Developer Community.  What is ODC?  You may remember it as OTN, or the Oracle Technology Network.  Same people, different name.  Why they changed it I can't say.  People just liked it better that way... (love that song)

In any case, what am I thankful for?  A lot.  To start, the tools that I use day in and day out: SQL Developer, ORDS, Oracle Data Modeler, SQLcl and - of course - APEX.  Without these tools, I'm likely on a completely different career path, perhaps even one that aligns more closely with my degree in television management.

While the tools are great, it's really the people that make up the community that make ODC stand out. From the folks who run ODC and the Oracle ACE program to the developers and product managers who are behind the awesome tools, the ODC community is one of, if not the greatest asset of being involved with Oracle's products.

If you have yet to get more involved with this communi…

Spaced Out

A while back, I wrote about how to give the Universal Theme a face lift.  If you follow the steps in that post, the base font for an APEX application with the Universal Theme can easily be changed.

While that's all well and good, sometimes you only want to change the font for a report, not the entire page.  One of the applications that I'm building contains a number of IRs based mostly on log data.  Thus, having that data in a monospaced font would make it a whole lot easier to read.

You can search Google Fonts for monospaced fonts by selecting only that option on the right-side menubar.  You can also opt for the standard yet kinda boring Courier and achieve the same thing.

To implement this in your application, follow the steps in my other post, but stop shy of the final step.  Instead of pasting in the text that I specify, paste in the following to the Custom CSS field in Theme Roller, using the name of the font you selected for the font-family:

.a-IRR-table tr td { font-fam…

Whose Deck is it Anyways?

This year at KScope, we're going to try something new.  And fun.  And funny to watch - we hope.  It's called "Whose Deck is it Anyways?", and will occur on Sunday at 8:30pm.  It's only 30 minutes, but it will likely be the best 30 minutes of the conference.  Or at least the most embarrassing.

Here's what we're going to do: the will be four 5-minute presentations - one on each of the following: BI, EPM, Database & APEX.

Sound interesting?  Probably not.  We get that, too.  So here's what we did.

Each 5-minute session will be presented by a non-expert.  For example, it's highly likely that I'll be presenting on BI or EPM.

To make it even better, each slide deck will be prepared by the corresponding expert.  So again, it's highly likely that my slide deck's creator will be either Stewart Bryson or Edward Roske.  If nothing else, this session will be a crash course in how not to make cohesive, easy to read slides.

Interested now?  Ya,…