Last week I wrote about using TRANSLATE to detect numbers in data Using The TRANSLATE() function...
Andrew Clarke at Radio Free Tooting pointed out the shortcomings of using TRANSLATE() to detect numbers.
As I said earlier, all I needed to do was detect if the characters in a string were all digits or not, and I wanted it to be very fast.
But Andrew's remarks got me thinking - could translate be used to detect more complex numbers?
Here's the short list of requirements:
* Detect integers
* Detect numbers with decimal point ( 4.6, 0.2, .7)
* Detect negative and positive ( leading + or - )
* Reject text with more than 1 '.', such as an IP address ( 127.0.0.1 )
* Reject anything with alpha text
As part of a presentation I'm preparing, I would like to get an idea of RMAN usage in the Oracle Community.
If you can spare a couple of minutes, please fill out this 10 question multiple choice survey: RMAN Usage Survey
It seems I made a poor choice of online Survey site.
To get more than 100 responses to this survey, a "Professional" version must be purchased. At a rate of 1 or 2 surveys a year (for me) that is not exactly practical.
Sharing the Survey results also requires the Professional version.
Here's a summary of the results in MS Excel.
A few small enhancements to exception handling/error messages. June 2004
A tutorial on loading XML files into relational tables. March 2006
While reading the book 'Deep Survival' (most kindly given to me at the UKOUG conference in Birmingham by Sir Graham Wood of Oracle after the fire in my house) I happened on a description on page 107 of a book called 'Normal Accidents' by a fellow named Perrow (get it? per row - a perfect name for database nerds).
Perrow's theses is that in any tightly coupled system - in which unexpected interactions can happen - accidents WILL happen, and they're NORMAL.
Also, he states that technological steps taken to remedy this will just make matters worse.
Perrow and IT systems
I have freely translated Perrow's thoughts into the following:
IT systems are tightly coupled. A change - a patch, a new application, or an upgrade - to a layer in the stack can cause accidents to happen, because they generate unexpected interactions between the components of the system.
Now and then some new angles and thoughts emerge in a field where a lot of people think there's not much new to be said.
1. James Morle told me a while ago, that he thinks all performance problems relate to skew, to latency, or to both. It's brilliant, I think. I hope James will one day write about it. He's a damn fine writer when he gets down to it.
2. This one from Dan Fink. Impressive piece, I think. Enjoy it.
When I emailed Dan and told him I admired his angle on this, he responded:
"I think it is a matter of keeping an open mind and knowing that you have friends and colleagues who are open to new ideas. Support is absolutely critical, even when you don't necessarily agree with what is being said. That keeps the flow of information open.