This content has been marked as final. Show 12 replies
I am happy and sad to see that we are not the only ones waiting for a version without new bugs.
You'll be waiting until the U.S. balances its budget and snow falls in Phoenix on July 4th. It isn't going to happen. They don't care enough about testing to make it happen.
Wow, this is a thread I like >>:]
I agree that stability has gone down (relatively - in comparison with 10g) while the scope has increased exponentionally. Adding stuff seems more important than sanitizing the basis.
Christian, that's basically what I told my class today. Oracle apparently feels the need (and understandably so) to compare feature-for-feature against its competition, so adding the newest slick functionality seems to take precendence over either (a) making the basics work properly, or (b) making sure that a patch doesn't break stuff that previously worked perfectly well, or (c) fixing the stuff that they broke. Broken stuff can, and does, stay broken a LONG time, over many patches. An example is the fact that the display of the Alert symbol on a dashboard worked fine in 126.96.36.199 and 188.8.131.52, but Oracle broke it in 184.108.40.206.2 BP1, and they declined to patch the 32-bit Windows version for at least 6 months. It really makes their development team look incompetent (which they aren't) when I have to tell a classroom full of students that this bug was introduced 3 patch versions back and that Oracle has chosen to not fix it yet.
Perhaps 220.127.116.11.6 will fix some of the more than 50 shortcomings that I've documented, from installation to usage, but at the same time I have no confidence that it won't introduce other bugs that I have to document in my classroom materials and for which I have to try to find workarounds. So far, without fail, each patch set that I've installed has introduced its own set of problems. And I blame that directly on a lack of testing. I don't blame it on Matt Abrams and the OBIEE team. Matt has a limiited number of resources, and they bust their tails to try to please everyone. No, I blame it directly on the guy at the top, O.R.A.C.L.E. Larry has about 30 billion resources that he could devote to adequate testing. He chooses to buy boats and airplanes instead.
Ding-ding-ding-ding!!! We have a winner, boys and girls!!!
See this thread for the first thing that I have found that the 18.104.22.168.6 patch set breaks.
WARNING! OBIEE 22.214.171.124.6 patch set destroys map configurations
There also is a GUID bug which for some users means you cannot log into 126.96.36.199.6. after applying the patch-set
We now just have to decide which bugs of which release cause the lowest business impact.
Well, thank goodness I haven't seen that one yet. Is it something different than the typical out-of-sync GUIDS situation that can be repaired easily using the method that's been around for a couple of years?
MOS team confirmed most of the below issues will be fixed by upcoming obiee188.8.131.52.0 (stable version)
"Most". "Most" will be fixed. Not "All".
I wonder how I would feel if I was a bug and, release after release, year after year, Oracle ignored me, said I was not important enough to be repaired. Poor bugs. I'll bet they are the little runty ones that wear thick glasses and corrective shoes. Sounds like discrimination to me.
We have been dealing with issues relating to GUID synchronization for many months. We have also opened numerous issues that existing functionality present in 10g which is not working in 11g. Currently we're on 184.108.40.206.5 and just received this 'recommendation' from Oracle:
The Service Request is assigned to me. I got response from the dev team saying that the same issue is logged in bug 14257626. The fix for this issue is included in OBIEE 220.127.116.11.6 release. They are suggesting to upgrade to latest available release - 18.104.22.168.7.
The 'issue' they're referring to is that when setting up account names, they have to be a specific length - OR IT CORRUPTS THE CATALOG!
To date, I don’t believe there is a stable version of OBIEE. I for one cannot continue to recommend this product to any future clients. Oracle, you better start paying attention and stop arranging the deck chairs as your ship sinks…..
I feel your pain. My particular pet peeve concerns the bugs that have existed since DAY 1 of the beta program. There's one in particular related to gauges that don't display the needles that fall above or below the custom range limits, something that worked perfectly well in 10g, which simply pegged the needles at the far left or far right, which is the correct behavior. So let's see... the initial release was Summer 2010, and the beta started a year before that, so we're talking about known problems that have gone unaddressed for 3.5 YEARS. Basic functionality that is BROKEN. Yet in the 22.214.171.124.7 patch set, they addressed issues such as axis labels not displaying clearly when presented at a 45 degree angle. That is a COSMETIC problem that does not adversely affect the useability of the graph. In contrast, the problem with the gauges makes them USELESS.
Many of the problems that they have simply ignored since day 1 are FUNCTIONAL problems, yet they choose to devote resources to cosmetics, to fluff, to things that do not compromise the functionality of the product. A missing gauge needle compromises the basic functionality of gauges. A 45-degree label that is a little hard to read does NOT.
I would be really curious to learn how the prioritization of bugs is performed. In my opinion, a prioritization process that elevates minor cosmetic issues for repair, while ignoring problems that compromise basic product functionality, is a flawed process.