Raptor SQL Formatter Issue…

It looks like there are some outstanding issues with the Raptor SQL formatter. It doesn’t appear to work at all when editing a package, but it will work for a procedure or an SQL statement. When it does work it appears to have some odd ideas about how PL/SQL variables should be defined. This example shows one case:

-- Before
CREATE OR REPLACE PROCEDURE dummy_proc AS
l_dummy_1 dual.dummy%type;
l_dummy_2 dual.dummy%type;
BEGIN
l_dummy_1 := 'x';
DBMS_OUTPUT.PUT_LINE('l_dummy_1=' || l_dummy_1);
l_dummy_2 := 'x';
DBMS_OUTPUT.PUT_LINE('l_dummy_2=' || l_dummy_2);
END;

-- After
CREATE OR REPLACE PROCEDURE dummy_proc AS l_dummy_1 dual.dummy % type;
l_dummy_2 dual.dummy % type;
BEGIN
l_dummy_1 := 'x';
DBMS_OUTPUT.PUT_LINE('l_dummy_1=' || l_dummy_1);
l_dummy_2 := 'x';
DBMS_OUTPUT.PUT_LINE('l_dummy_2=' || l_dummy_2);
END;

It seems to be a little confused by the declaration section of the procedure. I’ve posted this on the support forum. I hope this gets fixed before the production release.

In addition to this, the SQL formatter is a little lacking in configuration options.

Cheers

Tim…

Raptor. It does what it says on the tin…

I guess everyone knows by now that Raptor has arrived now. I downloaded it and had a little play and here are my first impressions:

  • It takes an age to start up. No doubt this is due to it being based on the JDeveloper framework. The words “Java” and “Fast” are rarely used in the same sentence where GUI applications are concerned.
  • Once loaded, the application is quite quick and responsive.
  • The look and feel is clean and simple, not dissimilar to PL/SQL Developer. Not at all like the “junk-yard” that is TOAD.
  • There are a few nice touches. When dealing with large numbers of objects, expanding the navigator does not list all of them. Instead, it lists the first few and gives you the option for more. This is much better than waiting around for ages, especially when you’ve expanded the wrong node 🙂
  • I’m not totally sure the editor window deals with fonts correctly. On my installation 12pt looks really chunky, but 10pt requires a magnifying glass to read. I usually use 8pt for my regular text editor, so something is a little fishy here.
  • It has all the things you would expect for a PL/SQL development tool, like syntax highlighting, debugger, PL/SQL beautifier etc. In addition it has a reporting tab that allows you to produce predefined and user defined reports. This is a nice touch for those people that have an endless array of custom scripts.

My initial impression is very positive, although it will be the New Year before I get to use the product in anger. I’m glad Oracle have resisted the temptation to build an “all things to all people” product. I find most IDEs annoying because of the shear volume of junk included. If Oracle keep it simple and keep it free this is going to be a bigtime winner.

I see no reason to pay for a product like PL/SQL Developer when you can use Raptor for free. TOAD may be a different matter though. Personally, I prefer Raptor’s clean interface to the clutter of TOAD, but if you are somebody that uses all the rubbish included in TOAD, then Raptor is probably not for you.

Over the last few months I’ve seen myself slip into a very negative frame of mind regarding Oracle products. Perhaps Raptor is a turning point. Keep up the good work!

Cheers

Tim…

PL/SQL Beautifier…

I think Oracle should include an SQL and PL/SQL beautifier (formatter) in the next version of the engine. I know there are lots of third party tools to do this, but it would be nice to produce readable output from queries against the v$ views, rather than having to cut & paste blocks of SQL output into a 3rd party tool to format it.

Why put it in the engine?

Remember the days when everyone and their dog had scripts to pull out object definintions from the database by querying the data dictionary? It became a real pain keeping them up to date, so Oracle released the DBMS_METADATA package so each version of the engine had the correct method for returning the object definintions.

In the same way, each version of the engine comes with new and modified syntax, which will often require modifications to beautifier code. Put it on the database, and let external tools access it. Added to that, it would solve my problem that prompted this post.

I’m sure they already have the code in Raptor. If they don’t want to write it in PL/SQL, they could always wrap up the Java code as a Java Stored procedure and make it available from the engine.

Cheers

Tim…

Disaster Recovery Testing Update…

So far it’s been a very long and very tiring week. Lots of standing up in very cold server rooms.

The disaster recovery testing has highlighted quite a few interesting points about our kit and our backup and recovery approach. I think this session will stand us in good stead for the second round of testing in a few weeks. By then I’m sure we will have ironed out some of the creases 🙂

One more day to go, then home…

Cheers

Tim…

Disaster Recovery Testing and stuff…

I’m off to HP for the rest of the week to help test our disaster recovery strategy, so I guess things will be a little quiet here for a few days.

OEM Grid Control Update:
So far things look pretty good. The agents still use a stack of memory, just under 1 Gig resident for the Grid Agent and IAS Console together on a Release 1 AS 10g server. Personally I think this is more than a little excessive, but the CPU load isn’t too bad at all, not like the previous version…

I knocked up a quick example of DBMS_PIPE in answer to a question on my forum. Personally, I use AQ for all my messaging these days, but each to their own 🙂

Cheers

Tim…

DBMS_ASSERT and stuff…

I saw a post about the DBMS_ASSERT package on Pete Finnigan’s Oracle security weblog and I couldn’t find any documentation about it, so I thought I’d have a little play and write something about it:

DBMS_ASSERT – Sanitize User Input to Help Prevent SQL Injection

I’m not sure I’ll find a use for it, but it’s always good to know what new bits have been added 🙂

This made me laugh: Counterfeiters send jammed printer for repair

Cheers

Tim…

Oracle 10g Release 2 Grid Control Installation On Red Hat Enterprise Linux and CentOS…

I’ve been having a play with the latest version of the Grid Control:

Oracle 10g Release 2 Grid Control Installation On Red Hat Enterprise Linux and CentOS

It installed no problem and appears to be working right out of the box.

The big question is, does it soak up all the CPU and memory on my servers?

The first version of the Grid Control was a complete nightmare for me. The agents worked fine on the database nodes, but they gobbled up loads of memory and CPU on the application servers, making them unusable. I raised a TAR and was told it was a bug that was fixed in the next release.

I’ve only installed an agent on one development application server at the moment. I’ll add a few more to non-critical servers tomorrow and see how it gets on. Fingers crossed! I’ll post the outcome of this test in a few days.

Cheers

Tim…

Exit mobile version