New and Improved!

   The SQL Developer Exchange , http://sqldeveloper.oracle.com,  has been out there almost since the beginning of the tool.  It's our way to allow users to log requests and have other vote on them.  Then we each release pick off some and put them into the product.  It's been basically unchanged since day 1.  This week I've built a new set of screens which hopefully look better and are easier to use.   We have implemented over 400 requests from users.  The exchange is have a bit of a facelift and if anyone would like to test out the new Exchange go here https://apex.oracle.com/pls/apex/f?p=43135:1 .  This is the same tables and data underpinnings so if you log or rate a request it will show in both place.

SQL Developer 3.0, XE 11.2 Beta, Developer Days

It is said things happen in threes.

1) SQL Developer 3.0 was release on Tuesday.  Some of the major new/revamped things include migration from Sybase,  Data Miner, Spatial, and Scheduler.  There's a longer list of new things we added which can be read here.  If you have not already, it's downloadable here.

2) OTN Developer Days in Toronto.  We had a great crowd in Toronto.  Chicago is the next stop on April 25th registration is here .  This is a great way to talk with people from development.  We have folks from TimesTen, XML, Java, PHP, Jdev, and .NET all at the event.

3) Rounding out the week.  Oracle XE 11.2 Beta.  After a long wait, it's finally arrived.  It can be downloaded here .  The documentation can be found here. There is a dedicated forum here for any questions or issues you may find.

PL/SQL Unit testing in the builds

At the OTN Dev Day in Dallas last week, I asked how many people unit tested PL/SQL.  The response was a kind of group chuckle acknowledging it should be done but isn't being done.  This was not really surprising since it's the same response I get everywhere I ask.  The difference is that in this event the attendees did a hands on lab and made tests.  The exact same lab that is in the Oracle Learning Library.  After doing the lab people realized how easy it actually is to test their PL/SQL.

Now what's not in the lab is how to schedule them for an automated nightly run or as a part of a system build out.  For that, there is a command line to kick off a test.  In the sqldeveloper/bin, there's a ututil.sh and ututil.bat.  Simply run these and you get the syntax.

sqldeveloper/bin$ ./ututil.sh 

Oracle SQL Developer
 Copyright (c) 1997, 2011, Oracle and/or its affiliates. All rights reserved. 

ututil -run ?
ututil -exp ?
ututil -imp ?

There's 3 choices. Export a test to an xml file, Import the test from the xml file, and Run the test. I'll focus on the run option.

./ututil.sh -run -?

Oracle SQL Developer
 Copyright (c) 1997, 2011, Oracle and/or its affiliates. All rights reserved. 

ututil -run -test (-id <id>|-name <name>} -repo <connection name>
  -db <connection name>
ututil -run -suite (-id <id>|-name <name>} -repo <connection name>
  -db <connection name> 

 Since there's a command line, it can be integrated into existing build procedures very quickly.  There's a few switches needed to run the test or suite of tests.

First, the obvious one is of course the test or suite of tests.

Second, the what repository to connect to for the tests.  All tests are stored in a central repository.  This allows  developers or QA or any group to create and manage the tests in a central place.  The repository is also where all results are stored.

Third, what database to target for the running of the tests.  With all the tests in a central repository, they can be run against any database.  This allows the tests to run with ZERO setup on any targeted database.  All you need is a login and the testing can begin.  The results are also stored in the central repository, test runs against various systems can be compared.  Which makes it very easy to see what tests work on which systems and not on others.  This is useful for the cases where some development code works properly yet when deployed to an integration environment it does not.  The central repository can also make it easy to compare timings of the test runs.  For example, something I've heard many times is on a development system with limited data code runs very fast yet when deployed against a larger dataset it is less than desirable speeds.

OTN Developer Day VM March '11 Edition

The Database VM was just updated.  You can get it here: http://www.oracle.com/technetwork/database/enterprise-edition/databaseappdev-vm-161299.html

Quick reminder that this VM is only-a-sandbox.  All passwords are oracle, for that an other reasons this is never to be used for any purposed other than a sandbox.

The main changes in this VM are:
- New OBEs!
- Upgraded DB to 11.2.0.2
- SQL Developer 3.0 EA3
- Application Express Listener 1.1
- Application Express 4.0.2
- Times Ten 11.2


Also, Todd suggested I outline the steps to create this VM incase other wanted to make a custom one.  These are my steps for this.  If anyone has better suggestions, please let me know and I can use that in the next revamp.


1) Use Default wizards for new VM with 1 drive for the OS.

2) Install OEL

3) Remove some things like printing to save space.

4) Install the VirtualBox tools

5) Create a 2nd harddrive for the database install.  I mount this new drive to /home/oracle.  Then add the oracle user with that has his home directory.

6) Next clean up some space before exporting the VM by running these commands:
    dd if=dev/zero of=/bigemptyfile
    dd if=dev/zero of=/oracle_mount/bigemptyfile
- This zeros out the unused space which I've found helps with the export sizes.

7) Remove those files.

8) Shutdown and Export the appliance.

9) Share with anyone who'd like it.

After this the result is what you see on OTN, a 4.3G download that is everything setup and configured.  The best thing about this is that the VM is a sandbox so when it's messed up for any reason.  Delete and Reimport the VM and it's back to square one.

Application Express Views - Key discovery part 2

Yesterday, I showed how the new Foreign Key discovery works on a subset of dba views.  The only catch was that the end result had T_DBA_  prefixes for the names.  It's really easy to change that.

Once you import the views and convert them to tables, delete the views.  What you are left with is a bunch of tables prefixed with T_ .  Now right click on the relational model in the tree and choose Change Object Names Prefix.

This is a simple dialog, much like a search and replace.  Enter the old, the new, and what object types it applies to and everything is back to the base names you'd expect in a diagram.

The end result is a model of all the APEX_ views for 4.0.

Oracle Application Express Views