Re: here's a good one from dizwell on the recent product launch

On Jul 17, 3:35 pm, "Jonathan Lewis" <jonat..._at_jlcomp.demon.co.uk> wrote:

> > I've yet to see you mention a single problem though I've invited
> > you to do so.

Like I said, Daniel: I won't do your homework.

> > Rather than spitting into the wind pick the three bugs that bug
> > you the most and send me code that will demo the problem.

No. You pick your browser and go to Metalink, search for problems where I mentioned them, and inspect the test cases there.

> In reply to a comment on a recent blog entryhttp://dbasrus.blogspot.com/2007/07/vs-b-grand-final.html
>
> Nuno gave me bug 5092688.8

Ah, you got it! Sorry, I wasn't sure you had seen the reply. Thanks, Jonathan.

> This bug is marked as an important issue.
> Versions confirmed as being affected 10.1.0.5, 10.2.0.2
> Description: Wrong results are possible if a function based index exists on
> a table used in a query.

Actually there is a similar bug in 9i, different number. I hit it a couple of years ago. Not nice that it isn't fixed yet in 10g, let alone 9i!
Not nice at all!
What I meant when I said it is completely unacceptable that egregious bugs like this, on features released YEARS ago, are STILL not fixed!

> Workaround: Set "_disable_function_based_index"=TRUE
> Fixed in: 10.2.0.3 (Server Patch Set)
> Note the description - this means that if you are on 10.2.0.2
> you MUST upgrade to 10.2.0.3 or you MUST disable
> all function based indexes. (There is currently no separate
> patch reported for the problem).

In other words: if you are using Peopletools 8.48, which for the FIRST time tries to make use of FBIs - I wonder why, given they have been available since 8i, could it be Oracle knew of the problems and told no one? - you'll be up the proverbial creek without a paddle!

Meanwhile, if you are a sucker like me and have tried to design a full-on application making extensive use of said indexes in anything before 10.2.0.3, you might as well have been shooting yourself in the foot when it comes to providing stability and reliability.

Given that those two requirements might be somewhat essential to one's reputation as a designer and dba, don't make me explain further how *pissed off* I am at this and other little pearls of new functionality that just plain do NOT work or are flaky as heck...

> If Oracle has managed to patch the problem (in a full release),
> why can't they describe the problem properly so that we can
> decide whether to patch it or ignore it as irrelevant. And why
> should I believe that a full patch release isn't going to introduce
> other problems on my system - I just want to fix the problem
> I know I have.

I don't want to flog this one much further, but indeed there is a patch to this problem. For 10.2.0.2. Now, given that other patches I have installed to solve similar problems with FBI have ALL failed to deliver, what guarantees to me that I won't be having incorrect rersults in my queries? It's *only* the payroll system of a 65 billion dollar company, what the heck: they can afford this sort of risk?

> Given the nature of many large organisations today - how often
> do you think people would notice if they got results which were
> a 'little bit' wrong ? How many people run reports and create
> screens which have guaranteed consistency checks built in so
> that a wrong answer has to appear twice in exactly the same
> way before it can get past audit ?

Well, try to explain to a payroll manager that her results might not be correct and you don't know exactly when or why or how?

And it's this sort of rubbish nonsense that I have had to cope with for YEARS!

Any wonder I'm royally PISSED OFF with Oracle and their "glory moments" for 11g developers? Received on Tue Jul 17 2007 - 18:43:19 CDT