SOUG: Tampa Oracle Day

Life has been busy and I haven't been to a meeting in a while. There's a good one coming up though. If you're in the area you should make plans. RSVP here.

Here are the rest of the details from the email blast:

I wanted to give everyone an early head's up that we have a whole day of Oracle info coming up next week on Thursday, November 8th. We will have the Tampa Oracle Day and Product Fair at Raymond James Stadium from 9am-4pm. Following a brief intermission, our November Suncoast Oracle Users Group meeting will begin at 6pm in our regular Rocky Point location.

The Oracle Day event will include separate tracks with 4 sessions each for Simplify IT, Social/Mobile/Cloud, and Customer Experience. There will also be a Solutions Pavilion/Demo Grounds, breakfast and lunch, and a couple of Keynotes. In one of the Keynotes, I'll be relating some of our experiences at Nielsen in Leveraging Exadata for Consolidation and Business Growth.

You can register for the Tampa Oracle Day by calling 800.820.5592 ext.10942 or online at : http://www.oracle.com/us/dm/06495-nafm12034228mpp041-oem-1844932.html.

One of the most recent additions to Oracle's ever growing line of Engineered systems is the Oracle Database Appliance. The ODA is a 2-node RAC cluster with 4TB of storage all buttoned up in a 2U chassis. They've combined this hardware with a slick web interface management layer that allows you to stand up a 2-node RAC cluster in less than an hour with just a few clicks of the mouse. For our SOUG meeting this month, we will have one of these boxes in hand for a live demo and further discussion of the technology.

The Thursday evening SOUG meeting begins with refreshments and an opportunity for networking with your peers from 6:00-6:30pm followed by a presentation from 6:30-8:30pm. The meeting will be held in the Knowledge Services facilities at:

3031 North Rocky Point Drive West, Suite 275
Tampa, FL 33607

Hope to see you there.

OBIEE: 14006 Unsupported Predicate

My favorite Admin tool error:



In one of our subject areas, we recently changed the physical source from one system to another. No big deal right?

One of my colleagues figured out this neat little trick using Fragmentation content on the Content table of a logical table source. Basically, if the date was yesterday or greater, use Table_A, if not, use Table_B. Worked like a charm.

With the change to the physical source, it no longer worked. WTH?

I suspected the Fragmentation content because the data types changed, well, one was no longer the driver, if that makes sense. See, we had to do this work-around because the original source system wasn't designed with date date types. We had to pass a string in the YYYY-MM-DD format.

With the new source, that was resolved. We now had a date data type, awesome.

Not so awesome, because it broke. By broke I mean all the facts were doubling for everything but the current day (today).

If you're wondering, here is the logic in the Fragmentation content section for Table_A:

"BMM"."Dim - Date"."YYYY-MM-DD Column" >= VALUEOF( "INIT_BLOCK"."YYYY-MM-DD" )

For Table B:

"BMM"."Dim - Date"."YYYY-MM-DD Column" < VALUEOF( "INIT_BLOCK"."YYYY-MM-DD" )

The only thing different is the operator.

Since we now had a true date data type, I tried to use that, which is how I came across the 14006 Unsupported Predicate issue. You see, now I didn't have to use a repository variable, I could simply use OBIEE date functions. I came up with this to mimic the same behavior:

"BMM"."Dim - Date"."Date (Data Type!)" < CAST( TIMESTAMPADD( SQL_TSI_DAY, -1, CURRENT_TIMESTAMP ) AS DATE )

Of course I changed the operator for each LTS. Save RPD, Transaction Update Failed. Check Consistency,



It's a valid formula. Works in Answers (or whatever it's called these days). Perhaps someone with far more experience can spot the mistake.

the katezilla t-shirt

Been thinking about doing this for a long time. No particular reason, just seems natural. Note the awesome font style I chose and how much it differs from the regular oraclenerd font. I'm very creative.

All proceeds go to support katezilla in all her awesomeness.

$25 (US Only, for now)

Erotic Problem Solving

by Michael O'Neill
Posts on oraclenerd, Twitter, Facebook

Writing code well is hard enough. Does it have to be boring too?

Business problems can be boring. This is perpetually true for the professional responsible for authoring the code to solve them who is technical-expertise-first and business-expertise-second. Emotional motivation and individual energy is a tremendous factor in the results of any problem solver.

In my career, I have repeatedly faced boring problems and successfully mucked through them with boring solutions. Sometimes though, I have faced interesting problems and unsuccessfully met them with boring solutions. Failure required a twist in my thoughts and energy to regain the upper hand on achieving a solution. Here is an example:

How do you code an effective solution with an ineffective domain model? Sophisticated social applications require a complex network model. Network models are difficult enough to document and even harder to conceptualize beyond a certain complexity. And when doubt creeps in on a modeling effort, the problem solver's all too frequent retreat is into previously reliable modeling techniques. Even if those techniques are an ill-fit at best. In a recent application, the problem ahead of me was building an intricate and robust human trust, credibility and reputation engine.

I experienced project-crippling difficulty during the initial modeling efforts. My mind was constantly circling the boring drain of popular technical trust models, like public-private keys and centralized certificate authorities. Every model fell apart eventually. My models required hierarchies that meant nothing in the real world of human trust. My models introduced single points of dependency that do not exist in human interactions.

I took a step back. I ended the boring. I turned myself on.

I imagined a small community of nonmonogamous individuals and their social sexual lives. How did they decide to hook up? How did they decide to break up? Did they like another, or like-like another? Were the states of those feelings returned? How did they decide whether to exchange bodily fluids or not? What were the layers, causes and watersheds of lust, love, trust, sacrifice, distrust? How was deceit employed? Did absolute trust exist? How did feelings of love affect everything?

I was able to configure a myriad of practical models, all intertwined based on a community of people I made up with my pencil. Right or wrong about how people work, it didn't matter. Its complexity and the energy I was able to pour into understanding the possibilities was what was valuable. It was adventure that proffered understanding of the solution required for my work. My intricate thoughts expressed in an exciting context was an excellent conversation with everyone I knew, eager every one of them to have themselves chatted up about sex. Each person I included in the discussion introduced a valuable complexity I was able to model. I remembered the what ifs shared over a pint were the reason I do what I do for a living.

I am not advocating having multiple simultaneous sexual partners to get through a modeling effort. Well, alright I am, but that is beside the point. Approaching a complicated business modeling problem required that I stop circling the boring drain and leverage the energy of thinking of all the complexities of people, emotions and how they interact - something in which I already had knowledge, intuition and interest.