Oracle SQL Developer v3.2.1 Now Available
- by thatjeffsmith
Oracle SQL Developer version 3.2.1 is now available. I recommend that everyone now upgrade to this release. It features more than 200 bug fixes, tweaks, and polish applied to the 3.2 edition. The high profile bug fixes submitted by customers and users on our forums are listed in all their glory for your review.
I want to highlight a few of the changes though, as I recognize many of you lack the time and/or patience to ‘read the docs.’ That would include me, which is why I enjoy writing these kinds of blog posts. I’m lazy – just like you!
No more artificial line breaks between CREATE OR REPLACE and your PL/SQL
In versions 3.2 and older, when you pull up your stored procedural objects in our editor, you would see a line break inserted between the CREATE OR REPLACE and then the body of your code. In version 3.2.1, we have removed the line break.
3.1
3.2.1
Trivia Did You Know? The database doesn’t store the ‘CREATE’ or ‘CREATE OR REPLACE’ bit of your PL/SQL code in the database. If we look at the USER_SOURCE view, we can see that the code begins with the object name.
So the CREATE OR REPLACE bit is ‘artificial’
The intent is to give you the code necessary to recreate your object – and have it ‘compile’ into the database. We pretty much HAVE to add the ‘CREATE OR REPLACE.’ From now on it will appear inline with the first line of your code.
Exporting Tables & Views
When exporting data from your tables or views, previous versions of SQL Developer presented a 3 step wizard. It allows you to choose your columns and apply data filters for what is exported.
This was kind of redundant.
The grids already allowed you to select your columns and apply filters. Wouldn’t it be more intuitive AND efficient to just make the grids behave in a What You See Is What You Get (WYSIWYG) fashion? In version 3.2.1, that is exactly what will happen. The wizard now only has two steps and the grid will export the data and columns as defined in the visible grid.
Let the grid properties define what is actually exported!
And here is what is pasted into my worksheet:
"BREWERY"|"CITY"
"3 Brewers Restaurant Micro-Brewery"|"Toronto"
"Amsterdam Brewing Co."|"Toronto"
"Ball Brewing Company Ltd."|"Toronto"
"Big Ram Brewing Company"|"Toronto"
"Black Creek Historic Brewery"|"Toronto"
"Black Oak Brewing"|"Toronto"
"C'est What?"|"Toronto"
"Cool Beer Brewing Company"|"Toronto"
"Denison's Brewing"|"Toronto"
"Duggan's Brewery"|"Toronto"
"Feathers"|"Toronto"
"Fermentations! - Danforth"|"Toronto"
"Fermentations! - Mount Pleasant"|"Toronto"
"Granite Brewery & Restaurant"|"Toronto"
"Labatt's Breweries of Canada"|"Toronto"
"Mill Street Brew Pub"|"Toronto"
"Mill Street Brewery"|"Toronto"
"Molson Breweries of Canada"|"Toronto"
"Molson Brewery at Air Canada Centre"|"Toronto"
"Pioneer Brewery Ltd."|"Toronto"
"Post-Production Bistro"|"Toronto"
"Rotterdam Brewing"|"Toronto"
"Steam Whistle Brewing"|"Toronto"
"Strand Brasserie"|"Toronto"
"Upper Canada Brewing"|"Toronto"
JUST what I wanted
And One Last Thing
Speaking of export, sometimes I want to send data to Excel. And sometimes I want to send multiple objects to Excel – to a single Excel file that is. In version 3.2.1 you can now do that. Let’s export the bulk of the HR schema to Excel, with each table going to it’s own workbook in the same worksheet.
Select many tables, put them in in a single Excel worksheet
If you try this in previous versions of SQL Developer it will just write the first table to the Excel file. This is one of the bugs we addressed in v3.2.1. Here is what the output Excel file looks like now:
Many tables - Many workbooks in an Excel Worksheet
I have a sneaky suspicion that this will be a frequently used feature going forward. Excel seems to be the cornerstone of many of our popular features. Imagine that!
