Wednesday, October 7, 2009

SQL Developer 2.1 Early Adopter -- Still More Impressions

Holy Memory Leak, Batman. The good news is that although my memory usage on SQLDeveloper has crept up to 775MB this morning before getting slow enough to have to kill it, it did manage to save the file and somewhat interact at that point. It used to be that once it had crept up to about 600MB that it would just go blank and be useless. So, now it seems to tolerate the memory problems better, but still has a problem with memory consumption gradually creeping up to intolerable levels as time goes on.

So, what was I doing that cost all this memory?
I had 5 text files open (not huge files, mind you -- all less than 1000 lines), no database connections open, and I was editing one of the files (Search and Replace, Ctrl-G to go to a line, edit, save, copy paste -- just normal editing). That's it.

Looks like I will have to kill from the Task Manager, as it didn't shut itself down all the way.

SQL Developer has always done this to me. I'm a Developer, so I open the tool in the morning and keep it open. Originally, I had to kill around 2 in the afternoon. With version 1.5.5, I had to kill around 11 in the morning and 2 in the afternoon. With the new version, it looks like I still have to kill, but it manages to use even more memory before I have to kill it.

I've been trying to get my company to switch from TOAD to SQLDeveloper, but nobody else can stand all the bugs. TOAD is a hog, too, and I haven't used it seriously for a couple of years, but the TOAD guys aren't having to kill twice a day. One of the guys on the team really wants to use SQLDeveloper, but he's on Vista and SQLDev is absolutely unbearable on Vista.

Makes me wonder if I'm an idiot for continuing to be a SQLDeveloper junkie. I love the tool, but it's never been smooth, seamless, or reliable. Kinda like driving a DeLorean or something. Well, maybe more like a Yugo. No, it's way cooler and more useful than a Yugo, but certainly not as sleek or fast as a DeLorean. Hmmm.....how about an old Dodge 4x4 truck. Love it to death, it's powerful, cheap and useful, does way cool stuff, but it might die any minute. Maybe I like it because I have a Gambler streak in me and just want to see if I can beat the odds.




Tuesday, October 6, 2009

SQL Developer 2.1 Early Adopter -- More Impressions

I like the new SQL Formatter changes. I really like the live previewer so that you can test a setting and see if it does what you think it's going to do. Very nice. My one complaint that I've always had with the SQL Formatter is that it seems to be less aware of PL/SQL. It handles SQL beautifully. Actually, this is a complaint I've had about Oracle products in general for years. SQL Developer has, in a lot of ways, been the answer to that void. However, the formatter still seems somewhat ignorant of PL/SQL. Interestingly, the formatter settings didn't migrate from the previous version very well until I went in and edited the settings, saved them as SQL and then restarted. The tabbing is weird. I have mine set at 4. Half of the tabbing works correctly at 4, but a bunch of other tabbing switches over to the default tab size of 2. Hope that gets fixed. If I use the "tabulator" (never have figured out what that means), then the indentation mostly disappears entirely -- one line works, then the rest move 4 spaces to the left of where they should be. There are a zillion options in the formatter. Tough to find documents, though. I really wish that the formatter would format DECODE statements correctly. Namely, that there be one value/translation pair per line.

Ctrl-Enter -- no longer runs a Select statement. Has to be F9 now. Also, a statement no longer runs with & as a prompted parameter, but if you run it as a script, it will. Using a ':' as the bind variable seems to work fine. Seriously, though, after all these years of making me learn to use Ctrl-Enter, we now switch to F9?

Case switching works a lot better with Ctrl-Quote now. It used to require clicking the mouse option first. And, there's a button now.

There's a button for an unshared worksheet now -- locking it into the current connection. That might be useful.

More later...











SQLDeveloper 2.1 Early Adopter -- second impression

130 MB memory -- seems smaller. We'll see if it creeps up to 600MB and then hangs like it always has in the past.

It feels a lot faster. Maybe I'm just too excited.

One of the things I have to check is the Excel import/export. I also need to try out the Data Modeler viewer. However, I should probably do some work...

Ya know, it's kinda sad to see what kind of things get me excited. And, should I be on an Early Adopter version? Probably not for production work, but I just can't really help myself. :)

SQLDeveloper 2.1 Early Adopter -- First Impression

It knew where to pick up my previous settings!! I'm already in love.

SQLDeveloper -- I'm so outdated

Early Adopter version 2.1 has been out since the 24th of September and I'm just loading it now. I'll whine about it later......

Wednesday, September 16, 2009

JDeveloper

I got a comment from someone from the Oracle team that works on the JDev Modeler on my past post. I was just going to post another comment, but hey, since I actually got some attention on my lame little blog, it probably deserves a full post.

Dai responded and was wondering what was giving me problems with generating from JDev. First of all, I have to say that I'm totally flattered that he read the post and responded -- especially since I was just whining into the Black Hole of the Internet.

First, let me say that I'm totally flattered that you read my whining -- "I'm not worthy..." The JDev Modeler ROCKS.

Here's the trouble that I end up having with the generating (in version 11.1.1.0.0).
I have to choose between 'CREATE, REPLACE or ALTER.' Thus, if I've created a table and made a change to a different table, I have to generate them separately. I'd prefer that it check the connection and generate a delta. Actually, this has been my only frustration. And, if I were working on one table at a time, it wouldn't be a big deal. Yesterday, I was attempting to do just that -- create foreign keys to two existing tables, alter some other existing tables and create several new ones. Basically, I pulled in a few tables into a database diagram, made some changes and enhancements and tried to implement them. What I ended up doing was dropping the two tables that I meant to create foreign keys to and then failing to create the full set of objects. Happily, this was in Dev.

Which brings me to one of my FAVORITE features in JDev Modeler. I love that it generates the sql script. However, I would prefer to get the script always -- even when it fails to run. That way, I can look at the script and fix the script. The reason that this is my favorite feature is that I love the point and click way of rolling out changes -- but only in Development. For Production, it should be from a script.

In fact, this is one of my favorite features in SQLDeveloper as well. They have been very good to (almost) always providing a way to see a script of any change that you are making through the UI. This is a fantastic feature. As I've mentioned, i feel strongly that the script is the only way to roll the code into test and production.

At this point, I should probably confess that I've spent a few years developing with Designer. So, I was spoiled by being able to point the generator at a database connection, have it generate a delta script WITHOUT applying it, then I could go apply and test the script. Nice feature.

But again, as a former Designer user, I LOVE the JDev er. Don't tell the SQLDeveloper er team, but I like the JDev version better. Yes, it does less. However, I love that it will create a sequence and trigger for a Primary Key column with the click of a button. That's just ONE example of how the JDev Modeler is more usable. Another confession -- I stopped using SQLDeveloper er once I found out that they were going to charge for it (and since I knew that JDev already had one that rocks for free). I've been a Contractor several times and I find that it pays to be able to use as many free tools as possible, especially in an environment where a company is paying MEGABUCKS for their Enterprise Oracle license and doesn't want to hear about another Oracle license fee.

Dai, I want you to know that despite my complaints, I LOVE JDev er. I love SQLDeveloper as well (have I mentioned that it hangs a couple of times a day and I have to kill it?).

Of course, now I'm comparing my own whining with my previous post about User Expectations. Developers are probably the hardest crowd to please as far as User Expectations go. Not only do I want the custom street rod, but I want it for free, too. :)

Thanks for reading -- "I'm not worthy..." :)



Tuesday, September 15, 2009

SQLDeveloper -- Continued Whining

OK, so SQLDeveloper is a free tool from Oracle. I really like it, but am still waiting to see some wrinkles ironed out. For example, it hangs at least twice a day and has to be killed. The PL/SQL formatting still has a LOT to be desired (in fact, the tool seems to be just treat PL/SQL as if it were straight SQL). It still has problems with the File Navigator, importing and exporting Excel spreadsheets, etc. The great thing was that until a year ago, SQLDeveloper was making fairly steady progress. So, if you saw a bug, there was some hope that it would get fixed -- at least partially -- in the next release.

SQLDeveloper is built from JDeveloper -- also free. JDeveloper is fine for Java, but not so hot for PL/SQL (hence, SQLDeveloper, which does better with SQL but still struggles with PL/SQL).

JDeveloper has a data modeler. It's actually quite nice, but has a few quirks -- like the fact that generating is a pain in the butt.

SQLDeveloper Data Modeler is not free, is not built from JDeveloper's data modeler, and is not part of SQLDeveloper. In fact, it appears to be totally unrelated. In testing the pre-release version, it looked like it was some dead Oracle product that got revived and assigned.

And the really crappy thing? Well, it appears that the SQLDeveloper team has been so busy building the SQLDeveloper Data Modeler (instead of just integrating the one that's already in JDeveloper), that each new version of SQLDeveloper has almost nothing in it.

And why are they doing this? Apparently so they can charge for SQLDeveloper Data Modeler. Did I mention that JDeveloper has a free Data Modeler?

??????????

Oracle, you confuse me.


Tuesday, September 1, 2009

Computer Code and User Expectations

I sling code for a living. However, what I've realized is that users expect
  1. The Code should anticipate their needs and "just do the right thing."
  2. It should be as custom, fast and beautiful as a hand-built street rod.
  3. It should be as cheap, reliable and efficient as a Honda Civic.
  4. Every project should be delivered on time, no matter how many times the custom requirements change.
If you can't meet those expectation, then you're an idiot. However, the only people that can explain why all of that is so impossible are the very ones that are saying it is impossible. Thus, nobody believes them. It's kinda like the people who don't believe that NASA put a man on the moon because the only verification available is through NASA.

Here's the weird thing. Writing computer programs is still very much in its infancy. When you look at cars, even thirty years ago, they weren't expected to go more than 100,000 miles without major issues. Now, 200,000 without major issues is the expectation.

Cars can be mass-produced mostly because pretty much all cars are solving the same problem. How to get people and stuff from one location to another. There are variations as to how fast , how efficiently, or how stylishly the people and stuff will get moved around, but all those automobiles are really just solving the same problem. However, computer programs are being written to solve any problem that anyone can think of. Kinda tough to mass-produce that. Thus, as long as we are solving new problems, the technology to automatically solve them will be somewhat flaky, unreliable and buggy. Once we have been solving the same problem for over 100 years (like we do with cars), then it should be pretty easy to reliably solve that problem. Kind of a boring problem, but easy to solve.

Keep using your brain, it's only going to get more valuable.

--Og