Everything Oracle

Locations keep losing their passwords

Q: Why do locations keep losing their passwords? If I set the password, go out of the editor and back in it’s still there, but if I exit the Design Center and come back in then it’s gone, and I’ve saved all my data before exiting?

Yes, this is a very annoying “security feature”. To solve the problem and keep your passwords from evaporating into the “digital ether”, from the menu select

Tools

Preferences

Within “Preferences”, select “Security Parameters”. There you’ll find a property called “Persist location password in metadata”. Tick the check box, and then press the “OK” button to exit. Now you won’t have to re-enter all your location passwords every time you re-enter the “Design Center”.

However, to confuse matters still further, ticking this check box will not affect existing passwords – unexpectedly, the change is not retrospective. If you have a password set for a location, check the “persist password” option, exit the Design Center and re-enter, then the password will still be lost. But if you set the “persist password” option first, set the location password, exit the Design Center and re-enter, then the password will be preserved.

What’s particularly odd about OWB’s “touch of Alzheimer’s” with regard to location passwords is that the “Default Metadata Security Policy” is set to “Minimum Security”. With this setting you might expect that passwords would be preserved in order to make OWB more user-friendly. The unanimous verdict on this “boojum” – bad design choice.

Can’t delete a location or change its properties

Q: Sometimes I can’t delete a location. The delete option just disappears from the task list?

Normally the task list for a location displays a “Delete” task (just after “Copy”). When the “Delete” task disappears you’ll also notice that all the items that appear in the editor are greyed-out and can’t be changed (apart from the “Password” item).

The reason for this “curmudgeonly” behaviour is that the location in question has been registered with the “Control Center”. If you like, the location has been reserved for deploying objects to a target and by preventing you from changing the location properties OWB is making sure the objects don’t get deployed to the wrong location.

The solution to this problem is to deregister the location with the “Control Center”. Select a project by highlighting its node to make sure the “Control Center” is available. Then, from the menu, select

Tools

Control Center Manager

to bring up the “Control Center” window. In the “View” pane, on the left-hand side, right-click on the location that is “reluctant to be deleted” and select the “Unregister” task. You’ll get a warning message telling you that deployment information will be removed should you proceed. If you decide to proceed, click on the “OK” button, and then close the “Control Center”. You’ll find that the location items can now be edited and that the location can be deleted (there is a small bug here in that the “Delete” option may not reappear immediately on the task list; if so, navigate back and forth to other objects a few times and it should reappear).

It would have been more helpful if, in these circumstances, Oracle had indicated in the editor and on the task list that the location was currently registered, giving developers an indication of why the standard functionality was unavailable and what could be done to reinstate it.

Can’t delete a project

Q: I’ve created two projects in the Design Center. When I right-click on one of them the delete task is shown, but on the other it’s absent. I’ve clicked back and forth between the two project nodes but I can’t get the missing delete task to reappear.

This is a bug in the Design Center. To reproduce it click on

Design

New

and create a project “P1”. Then repeat the process creating a project “P2”. Expand project “P1” by clicking on the “+” sign to the left of the project node. Navigate around a few nodes. Collapse “P1” by clicking on the “-” sign to the left of the project node. Right-click on “P1” and note that the “Delete” task is absent from the task sheet. Right-click on “P2” and note that the “Delete” task is present on the task sheet. Right-click on “P1” again and note that the “Delete” task is still absent from the task sheet. It seems as though you have no way to delete project “P1”.

The problem occurs because (1) OWB is a rather “needy” piece of software and insists on having at least one project per workspace (remember that project MY_PROJECT is automatically created when a workspace is created), and (2) clicking on a project node does not change the project context. To change the project context you have to expand the project tree.

So, to change the context from project “P1” to project “P2”, expand and then collapse project “P2”. Now if you right-click on project “P1”, the “Delete” task will have reappeared, but it will have disappeared from project “P2”.

A more developer-friendly OWB would display the “Delete” task for all projects as long as there were at least two projects present in the workspace.

Invalid upgrade plan

Q: When I try to upgrade a table I get an error message about an invalid upgrade plan?

You’ve created a table in OWB, deployed it to a target schema, and added some data to the table. Then you decide you want to change the structure of the table, by, say, adding a column, without losing the existing table data. So you modify the table in OWB, and then try to deploy it with a deploy action of “upgrade”. But you get an error message:

RTC-5270: Invalid upgrade plan. The deployment has been aborted due to a problem generating a valid upgrade plan.

Not very informative – wouldn’t it be nice if you could always click on an error message and have OWB tell you what you needed to do to remedy the matter? But in this case OWB is actually quite helpful. If you click on the job name in the “Control Center Jobs” pane, the “Job Details” window will appear and proclaim your “sins of omission”, telling you that you must run script:

<OWB-HOME>/owb/rtp/sql/grant_upgrade_privileges username

If you dig this script out of the specified directory and display it in a text editor you’ll find it must be run in account SYS on the target schema – upgrading a table requires additional privileges not needed for deploy actions of “create”, “drop”, or “replace”.

Run the script, return to the Control Center, try the upgrade deployment again, and this time it should succeed (you’ll still get a warning message about the target account lacking DBA privileges).

This issue illustrates yet another instance of a disease that seems endemic to most Oracle products, namely “scriptitsis”: a requirement to dig scripts out of obscure installation directories at regular intervals to solve configuration problems that have not been adequately addressed by the product in question.

Now, you’ll notice in the locations editor a useful “Test Connection” button that allows you to see whether or not the connection is working before you start to deploy objects to the target location – well done OWB Design Team! Since upgrading requires extra privileges on the target account, it would be nice to have an additional button, “Test Upgrade Privileges”, to determine if upgrading to the target location is possible, and, if not, to provide a screen to logon as SYS and then grant these privileges without having to perform an archaeological excavation on the relevant Oracle Home – come on OWB Design Team, you can do better!

Everything Oracle

Home

Everything Oracle

FAQ	Design	Center

A collection of bugs, boojums and Oracle oopsies!