11 August 2006

I didn't know you could do that!

Have you ever used a tool for a while and then suddenly stumbled across something new? It's like opening a surprise gift or opening the window in the morning and seeing unexpected snow outside! Pure fun.

I started my day as normal by sorting out the bits of work I need to do and trashing unwanted mail and spam when I was distracted by a message about another product. I broke 2 'personal rules' one was to start playing with the piece of code and the other was to start working on something not on my list of things to do for the day! Well, it's Friday - that'll be my excuse.

The note was about handling external tables, so I thought I'd run the supplied code through SQL Developer, to see how well we handle it, and I found a whole new dialog! Maybe I shouldn't be admitting that, but I wondered if you'd like this little gem.

Creating an External Table and Loading Data

Here's some background first. Verbatim from the Oracle Documentation: "You create external tables using the ORGANIZATION EXTERNAL clause of the CREATE TABLE statement. You are not in fact creating a table; that is, an external table does not have any extents associated with it. Rather, you are creating metadata in the data dictionary that enables you to access external data."

In order for you to be able to replicate this exercise, I used the example offered by the Oracle database doc.

First you need these two files created and stored somewhere in a directory.

The file empxt1.dat contains the following sample data:


The file empxt2.dat contains the following sample data:


What we want to do is create a table that accesses this external data. i.e. an external table. Once created, the Oracle doc then moves the data from the external table into a table in the schema, to complete the exercise.

First we set up the directories. This syntax is not quite straight from the doc, but nearly. The only changes I made was to use my own directory structure and of course I'm using SQL Developer:

So now we need to create the external table for our HR schema. First, switch to the schema HR and then, using the context menu, invoke the Create Table dialog. This is the initial screen:

You can fill in the columns here, or just switch directly to the advanced dialog. Once you've switched you'll see the Table Types property. When I demo SQL Developer, I always highlight these options for users, but as I don't use external tables, I typically continue the demo by creating a regular table with constraints etc.

Once you select the Type External, your dialog changes. Now you can populate all the properties as
required. (The full code is below)

You can of course just copy and paste this code into the SQL Worksheet and execute it, but I challenge you to use the dialog, just this once. Here's the code:

CREATE TABLE admin_ext_employees
(employee_id NUMBER(4),
first_name VARCHAR2(20),
last_name VARCHAR2(25),
job_id VARCHAR2(10),
manager_id NUMBER(4),
hire_date DATE,
salary NUMBER(8,2),
commission_pct NUMBER(2,2),
department_id NUMBER(4),
email VARCHAR2(25)
records delimited by newline
badfile admin_bad_dir:'empxt%a_%p.bad'
logfile admin_log_dir:'empxt%a_%p.log'
fields terminated by ','
missing field values are null
( employee_id, first_name, last_name, job_id, manager_id,
hire_date char date_format date mask "dd-mon-yyyy",
salary, commission_pct, department_id, email
LOCATION ('empxt1.dat', 'empxt2.dat')

Checking the Data

Is the data there? Can you query it and access it as usual? Yes, yes and yes! Try this: Expand the Tables node in the Navigator and drag the ADMIN_EXT_EMPLOYEES table onto the SQL Worksheet and execute your query.

The Oracle doc finishes the exercise by copying the data from the external table into EMPLOYEES with the following command:

INSERT INTO employees (employee_id,
first_name, last_name, job_id, manager_id,
hire_date, salary, commission_pct, department_id, email)
SELECT * FROM admin_ext_employees;

You can finish off the exercise with that too if you fancy. Either way, you'll have done a small walk through External tables.

Now, back to work.


Niall said...

nice, though the interface for the access parameters is a little blank, a wizard or something might help..

one thing I didn't do was to get the scale of the columns right. So I chose edit from the context menu on my tables. this wasn't so good.

Paul MacMillan said...

There's a rather weird UI for precision & scale. They are both presented in the same scrolling region. The arrow buttons to the right of the Precision control aren't for incrementing/decrementing Precision, they're the ends of the scroll bar for this region. Scrolling down will bring the Scale control into view. Or you can increase the size of the whole dialog.

Agree on the lack of options for the Access Parameters - they're the tricky bit. Still, nice to see early support for External Tables, which are a great feature.

Sue said...

Niall, Paul,

Thanks for the feedback on this. It's useful to have the kind of feedback you have both given. I'll pass this on to the developers. While they might not be able to address the specific comments yet, knowing the sticking points is useful.


Sue said...

I'm never sure if you'll come back and read comments, as tme has passed, but in case you do. The scrolling region for the precision and scale happens in certain circumstances. If the real estate on your screen is limited then this area is squeezed a little and the scroll bar appears. All you need to do is resize the dialog slightly and that will go away. The reason this little region even has a scrolling bar, is becuase some complex datatypes have more vlaues and so you'd need to be able to move beyond the two.


jim said...

This could be helpful but for me the biggest headache is getting the order of the access parameters correct.

The "Cannot be NULL" checkbox seems a bit out of place on an external table dialog!