OBIEE11g is not stability like obie10g every month releasing patch and version..upgrade some new bugs and some issues resolving but always very strange to work with obiee11g
1) Excel - Add in - Pivot table not working issue -bug
2) BI Composer - export option issue(if report less than 25 rows then export gone) - bug
3) BI - Date Filter not working issue (bug fix 184.108.40.206.0) -bug
4) Action link Space Behind issue on after applying patch (patch overwriting issue opened bug and MOS Dev team WIP)
5) After configure SSL - Job manager unable to Connect it (custom SSL - CA)
6) Unable to downgrade web catalog (220.127.116.11 to 18.104.22.168) - bug
7) Report exporting into excel size increased comparing actual size of the report csv format (excel size diff from other format this issue has been fixed in OBIEE 22.214.171.124) - bug
8) Action Link text is Exported to Excel issue -bug 12638186 (ref article 1450819.1 )
SR 3-3945805521 : Pivot table with Action link column downloading into excel o/p showing action link labled exported issue (invoking a Browser Script and Navigate to web page)
am waiting for v 126.96.36.199.0 ...(looking for obiee11g stable version)
Edited by: Devarasu on Nov 23, 2012 2:39 PM
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 188.8.131.52 and 184.108.40.206, but Oracle broke it in 220.127.116.11.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 18.104.22.168.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.
There also is a GUID bug which for some users means you cannot log into 22.214.171.124.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?
"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 126.96.36.199.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 188.8.131.52.6 release. They are suggesting to upgrade to latest available release - 184.108.40.206.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 220.127.116.11.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.