ORACLENERD twitter/oraclenerd view chet justice's profile on LinkedIn feed oraclenerd t-shirts Unemployment Clock:

  Carl Backstrom
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.

Labels:

 
  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.

Labels:

 
  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.

Labels: ,

 
  %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.

Pros


  1. Strongly typed declarations

  2. 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


  1. 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.

  2. Too much typing - I love to type. Seriously. I'm going to say it...this is too much typing.

  3. 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.

Wow, I guess that's not much of a list is it?

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.

Labels: ,

 
  Go Rays!
From chester_james


Rayhawks all the Rage!

Labels: ,

 


Guest Authors

How To

Popular

Previous Posts

Code Projects

Archives
August 2007 / September 2007 / October 2007 / November 2007 / December 2007 / January 2008 / February 2008 / March 2008 / April 2008 / May 2008 / June 2008 / July 2008 / August 2008 / September 2008 / October 2008 / November 2008 / December 2008 / January 2009 / February 2009 / March 2009 / April 2009 / May 2009 / June 2009 / July 2009 / August 2009 / September 2009 / October 2009 / November 2009 / December 2009 / January 2010 / February 2010 / March 2010 /


Aggregated by OraNA