Comments on Sydney Oracle Lab: It's Enterprise and won't be cheap....

Just got SQL Developer 3.1 Now I can see RMAN back...

2011-10-11T20:58:53.096+11:00

Just got SQL Developer 3.1
Now I can see RMAN backups. It isn't just for developers now....

Hey, I love jetlag! It means I can post comments o...

2011-10-11T13:57:27.352+11:00

Hey, I love jetlag! It means I can post comments on Aussie blogs in a sensible time for you chaps.

Of course, how I'm going to get on in the office today is another matter ...

But of course I and others don't know what ...

2011-10-11T13:56:10.745+11:00
But of course I and others don't know what we're doing, according to some "ace experts" out there...

Of course you don't Noons. I keep telling you that ;-)

Some 'ace experts' are ok, though, trust me ... but I'm happy you keep rocking the boat and I really like Gary's post too because it raises some interesting questions that made it stand out from the OOW noise ....

Cheers,

Doug

Let's hope so. To be fair to SQL Developer: ...

2011-10-10T00:04:32.734+11:00
Let's hope so.
To be fair to SQL Developer: it IS a developer tool. NOT a end user tool.

Being a developer tool, its design makes the basic assumption the user is connected to a development instance. Which is not unreasonable!

The problem comes when folks use it against a production database, as an end user tool.

Classic situation: it puts a DDL lock on any table it has a cursor opened on. Basically, any window using that table.

Which means if a production process involves for example a DDL operation - eg drop/create an index (not entirely unreasonable in a BI/ETL environment?) - then it simply locks up production!

Until such time as someone - the "evil, expensive dba", of course - figures out WTH is going on...

Any wonder why I want it replaced by Apex anywhere I find it in use against production?

The fact that a SELECT...FOR UPDATE can lock a row...

2011-10-09T22:46:43.782+11:00
The fact that a SELECT...FOR UPDATE can lock a row and only needs SELECT privileges is a bummer.
Makes it damn near impossible to actually have a READ ONLY account even if that is all you want.

That said, if the 'cloud connection' for SQL Developer 3.1 only uses a stateless RESTful connection, that could be useful

Yeah, Forms is basically dead. Apex on the othe...

2011-10-09T22:14:16.499+11:00
Yeah, Forms is basically dead.

Apex on the other hand is finally being given the time of day.

Instead of the Java non-sense that has to be re-invented/"re-factored" every time someone wants a small change in a screen. Good for Fusion. Which took only, what, 8 years to see the light of day as a product? Why was I not surprised...

At work I finally got everyone in our BI and finance team using Apex.
Instead of - wait for it - SQLDeveloper! It's such a great tool for end users, SQLDeveloper, isn't it? Particularly when someone opens a change window on a critical table and proceeds to lock it for the entire day...

"The database is running slow, I can't run this truncate that used to run in 1 second!" and other such used to be the order of the day.

Now? No more complaints. And no more exclusive DDL locks either...

But of course I and others don't know what we're doing, according to some "ace experts" out there...