Late this afternoon I went to check my tweets and saw a lot of traffic from those I follow about @carlback. It was all about trying to figure out if Carl had been killed in a car accident early Sunday morning.
I began my search of some of the Las Vegas papers but was unable to confirm. Then Justin Kestelyn and Eddie Awad confirmed it.
I never had the pleasure of meeting Carl in person.
I met him first through the Oracle ApEx forums more than 3 years ago. At the time I was a newbie but his responses (to me and others) were always patient and well thought out. I never once saw him condescend in the forums. He was a tremendous resource to the ApEx community and he will be sorely missed.
Of late he left comments on my blog or we went back and forth on Twitter. We've even traded a few emails here and there. I only new him through the 'tubes, but this has affected me more than I thought it would.
I had/have a great amount of respect for him.
My condolences go out to his friends and family.
Monday, October 27, 2008
Tuesday, October 21, 2008
JDeveloper, SQL Developer, Subversion and Tortoise
I've been trying for a month now to get JDeveloper, SQL Developer, Tortoise and Subversion to play nicely together. They don't really fight, but it seems JDev and SQLDev won't recognize versioned files if I check them out using Tortoise.
Very annoying because I like both tools.
So I went searching and found this document (online) in the help files. So I tried to put that DLL in the Tortoise bin directory, but of course that wouldn't work because they've renamed everything with a leading "T."
So I downloaded the actual SVN client from Subversion. Then put the dll in that directory...now I open up SQLDev and get this seay32.dll (or something like that) missing. Awesome.
Back to searching and I found this one. user594768 has only 2 posts but this one did the trick.
First, download the 1.2.0 SVNKit from here.
Then, do the following:
copy
- jna.jar
- svnkit-javahl.jar (rename into svnjavahl.jar)
- svnkit.jar
- svnkitsrc.zip
- trilead.jar
into your/sqldeveloper/jdev/extensions/oracle.jdeveloper.subversion/ directory. If you rename svnkit-javahl.jar correctly the first time, you won't have to suffer like me for another week.
Start SQL Developer and go to Tools --> Preferences --> Versioning and it should read:
Subversion Client
SVN/1.5.2 SVNKit/1.2.0 (http://svnkit.com/) r4949
This works for both JDeveloper and SQL Developer.
Very annoying because I like both tools.
So I went searching and found this document (online) in the help files. So I tried to put that DLL in the Tortoise bin directory, but of course that wouldn't work because they've renamed everything with a leading "T."
So I downloaded the actual SVN client from Subversion. Then put the dll in that directory...now I open up SQLDev and get this seay32.dll (or something like that) missing. Awesome.
Back to searching and I found this one. user594768 has only 2 posts but this one did the trick.
First, download the 1.2.0 SVNKit from here.
Then, do the following:
copy
- jna.jar
- svnkit-javahl.jar (rename into svnjavahl.jar)
- svnkit.jar
- svnkitsrc.zip
- trilead.jar
into your
Start SQL Developer and go to Tools --> Preferences --> Versioning and it should read:
Subversion Client
SVN/1.5.2 SVNKit/1.2.0 (http://svnkit.com/) r4949
This works for both JDeveloper and SQL Developer.
Saturday, October 18, 2008
Oracle and The Register
I found a great headline last week via syntaxi at twitter.
Oracle shareholders choke on Ellison's package
Oracle shareholders enhance Ellison's package
It seems Gavin Clark over at The Register has a pretty good sense of humor.
Oracle shareholders choke on Ellison's package
Oracle shareholders enhance Ellison's package
It seems Gavin Clark over at The Register has a pretty good sense of humor.
Wednesday, October 8, 2008
%TYPE, What's the Point?
As I started to read more and more I found many people were advocated the use of %TYPE in variable/parameter declarations. I thought, "Great, I should do that too!"
So after a few years of using them I have something of an opinion on them.
In a development situation or trying to spec something out, I can definitely see the value. Nothing is set in stone and needs to be somewhat fluid. But in a stable production environment? Is it really necessary? If you are going to change the data type or precision of a column, wouldn't you expect to make a few changes? For some reason I think of the need to change your Primary Key, and all references...
%TYPE has it's merits. But I think the love affair is over for me.
So after a few years of using them I have something of an opinion on them.
Pros
- Strongly typed declarations
- Inheritance - If the column data type changes, you don't have to change any of your packaged code (not really sure if that is different than #1)
Cons
- Difficult to debug - What data type was APPLICATION_DETAIL.FOOID or worse, what was SCHEMANAME.APPLICATION_DETAIL.FOOID? Is it a NUMBER, VARCHAR2, or something else? Off to SQL Developer or SQL*Plus to do a describe on the table...I once spent a full day trying to figure out which of the 30 passed in parameters (and their values) was throwing a data type error. Another developer finally found it.
- Too much typing - I love to type. Seriously. I'm going to say it...this is too much typing.
- It's Ugly - Alright, that's not really a con is it? I like my code pretty. Many times using the SCHEMANAME.APPLICATION_DETAIL.FOOID%TYPE takes me over 90 characters wide...it's just ugly.
In a development situation or trying to spec something out, I can definitely see the value. Nothing is set in stone and needs to be somewhat fluid. But in a stable production environment? Is it really necessary? If you are going to change the data type or precision of a column, wouldn't you expect to make a few changes? For some reason I think of the need to change your Primary Key, and all references...
%TYPE has it's merits. But I think the love affair is over for me.
Thursday, October 2, 2008
Subscribe to:
Posts (Atom)