Discoverer 3.1.36.06 bug?

Dicoverer 3.1.36.06 Bug?
Hello,
I've been having trouble trying to setting privileges to User IDs in Discoverer 3.1.36.06 Administration Edition.
This seems to be a very basic problem that I'm sure lots of people have already detected it.
The problem is as follows: after you log on into Discoverer as the owner of a Business Area and load this one, I'd like to grant certain privileges to some others users. For this, you go to the Privileges Dialog (Tools -> Privileges or CTRL-P), and then as soon as I select a user from the User drop-down list the dialog closes immediately without letting me see what the privileges the selected user has. This is very weird. Does anybody how how to get aroung this?
Thank you in advance, and I'll really appreciate any suggestions.
null

I tried to recreate what you described above with my version of the Admin edition and could not reproduce it. I am currently using Admin Release 3.1.41 which is a patch to 3.1.36. It appears that your problem is fixed with a patch but you will want to look over the documentation to see exactly what the patch will fix for you. Hope this helps you. Good luck.

Similar Messages

Monstrous bug on iphone 3g 32 gb after upgrading to IOS 5.0.1

Hi all!!
I found a bug on IOS 5.0.1 almost monstrous after the upgrade on my 32 gb3gS happened to me that
I can not use the automatic locking as if I do, the iPhone after about 20 seconds that went into stand-
by then when the screen becomes dark, just after about 20 seconds, the iPhone is absolutely
necessary to turn it off and reset button with the home + sleep is really a monster .... Apple never had
this kind of problems .... but what happens!? steave where you ...!? :-( :-(
to some of the comunity ever!?
WITH PREVIOUS FIRMWARE I DO NOT HAPPENING! I HAVE USED ALL THE TIME AND I HAVE NEVER HAD 01.04 A PROBLEM ...
TANK YOU FOR YOUR COOPERATION.

prospero luca wrote:
4.1 then I made various upgrades to firmware 4.3.5 and it stopped for about a year! after which I upgraded to 5.0.1 and the bugs came out!
Now I have been more clear!?
YES, we understand that, but you are wrong! it is NOT A BUG. You don't understand what a "bug" means.
If you want to fix your phone RESTORE THE PHONE IN iTUNES.
If you don't want to fix your phone, but only want to declare yourself as discoverer of a non-existent bug, stop posting as you are only making a fool out of yourself.

Schedule report re-runs when opening

Hi,
I have a scheduled discover report in Discoverer 4.1.48 version, when opening that scheduled report its re-run the query again.
Please let me know, the reason.
BR,
Uma

Hi Uma
One of the reasons for this happening is that the query could be a fan trap. Discoverer will nearly always tell you that the results are invalid and suggest a rerun when there is a fan trap.
This was recognised as a bug but was only corrected in the 10.1.2.2 release of Discoverer. Many other scheduling bugs were fixed in this and subsequent releases. Have you considered upgrading?
Best wishes
Michael

Bluetooth not discoverable iOS 7 - bug or hardware problem?

Just got an iPhone 5c and Bluetooth is not discoverable at all. For example, in my car when searching for a device it does not find it. Likewise, if I seach for it on another iOS phone, it just doesn't exist.
I have an iPhone 5 with iOS 7 and that connects fine to the car with no problems at all. I'm thinking this could be a hardware problem, but just wanted to check if it's been reported as a bug by anyone else?

A bit more on this:
When Bluetooth was switched on, but Airdrop set to Contacts Only, the phone was discoverable by the car but did not work correctly - it connects via Bluetooth but the car display shows no signal and cannot make calls through in car audio.
With Bluetooth switched on but Airdrop set to Off, phone is no longer discoverable by the car
Frustatingly, I don't have access to both the phone and car to test the final scenario of Bluetooth on and Airdrop set to Everyone to confirm what I suspect will be the case.
If the final scenario does work, this has to be a pretty significant bug in the software, right?

Bug in Discoverer 3.1 ?!

Hi Guys, I am not sure whether I am doing sth wrong or whether I discovered a permanent bug in a query. I guess it is a bug. The problem is this:
I am using two databases with identical data except of the amount of data (one is used for test purposes = db2). When I am generating a query and asking for the year in db1 an error message pops up with the following message: ORA-01821: date format not recognized
The same query in db2 works (remember: same data).
If you compare now the SQL-command, you will find the word 'INV' added on the same kind of query.
SQL db1 (not working):
SELECT DECODE(FAKT."Auftragseingangsdatum",NULL,TO_DATE(NULL),TO_DATE(TO_CHAR(TRUNC(FAKT."Auftragseingangsdatum",'INV'),'')| |'190001','YYYYMM'))
FROM DATA.FAKT FAKT
sql db2 (working):
ELECT DECODE(FAKT2."Auftragseingangsdatum",NULL,TO_DATE(NULL),TO_DATE(TO_CHAR(TRUNC(FAKT2."Auftragseingangsdatum",'YYYY'),'YYYY')| |'01','YYYYMM'))
FROM DATA.FAKT2 FAKT2
What does the INV command do and how can I fix this problem?
Thanks for your help!!!
null

Not sure what version you are using... are you connecting to an Oracle 8.0.6 database? You may need to have your DBA check with Support to find out what he or she needs to patch..
i think the label was:
ST_RBMS-8.0.6.0.0_BACKPORT_700339
christopher

Discoverer 3.1.42 User Edition Bug? EUL Corruption?

We have applied the 3.1.42 patchset but are experiencing some serious buggy behaviour.
The worst problem appears in User Edition if a Parameter is used in a Calculation and there are also Totals on one or more columns. When first created, this situation may work for a while, but further manipulations usually cause the query to crash with a message like: "Internal EUL error: EULParseNodeType error in canonical formula" (apologies: I don't have the exact message in front of me here). Once that error occurs, it seems to always occur in that Worksheet when a Calculation involves a Parameter AND there is a Total declared.
Is this a known bug? Has anyone else run across this? Does the Worksheet get corrupted in the EUL?
This one problem (oh, there are several others) is causing some significant grief.
Help is appreciated.
null

I haven't seen what you are mentioning yet. However, if you create a calculation or parameter in 3.142 and one of your users still has 3.141, the user will get an error message: Invalid combination of filters or calculations, query cannot be resolved. Upgrading to 3.142 corrects this for the user.

Export to Excel in Discoverer - Is this a Bug ???

Hi all, thanks for all your helping and sharing thoughts.
I have one issue when exporting to EXcel:-
If you create a calculated field in Discoverer and 1 or more of the values used in the calculation has a NULL value, Discoverer will show a NULL value for the calculated field, which is correct. However when the report is exported to Excel, the calculation for this field is done as if the NULL is a zero causing the calculation to be incorrect. For example:
Ordered_Qty = 20,487
Contract_Amount = NULL
Calculation for new field 'Contract_amt_Remaining' is Contract_Amount - Ordered_ Qty = NULL (since you can not subtract something from nothing , ie NULL - 20,487= NULL) this is fine.
When the new field is exported to Excel the value shows -20,487 as if the Contract_Amt = 0 and not NULL, actually it supposed to show NULL, I don't know why its happening like this.
can anyone help me on this, that would be greatly appreciated.
Thanks in advance,
skat

Hi puppethead,
Thanks for your response,
Here what I am asking is, calculation working fine in Discoverer Plus lik the difference between 2 items, when it is null ie NULL - 3435= NULL this is working well and good in Disc PLUS, but when we export that worksheet to Excel it is giving as ie NULL-3435 = -3435 instead of NULL.
so you guys asking me to use CASE statement in Calculation, but this is not with our calculation part right in Disco Plus, coz we are getting correct result, only when we exporting to Excel getting incorrect value thats it.
Also i tried that CASE statement in calculation, saying syntax error, is that right syntax or not, i used as it is from this post.
Can you make sure that CASE statement is right or not in the above post, do you want me change anything over there, coz I am getting syntax Error.
Thanks again and for your helping.
--skat

Apparent kompare bug(s)

I apologise in advance for the length of this 1st-Arch-post-in-years. I value context more than brevity, I guess. Hopefully this is the longest post I'll throw at Arch for a long, long time.
I looked around (quite) a bit before filing this post. I've used Arch off-n-on since 0.4, know the Arch site, the basics about Arch, and most of the "gotcha's" farly well - but I'm no sysop, either.
I have a project I've been needing and meaning to work on for years (and which continues to compound itself while I don't); a huge set of backups on CD/DVD of all my data (my *life*, really) for well over a decade - letters, graphics, email, the first 40 pages of my book, you name it. Over the years this 'little' library has grown to over 10 GB compressed (30,000 files, *most* of them ARCHIVES). My guess is that 2-4 GB (compressed) of the data is important, some very much so.
My archive collection consists of many recursed archives themselves, and they're in about 8 or 10 different formats, to boot (even *.ice, LMAO). Many are further embedded several levels into the main archives (yes, I know that's a bad idea, but I didn't know that when I created them...). I BADLY need to unpack all this stuff, find and toss the duplicates, and truly organise (and efficiently backup) the remainder. This effort will obviously require a lot of automation (or else my heirs will either do it, or not).
I'd found a couple of useful tools in the Windows world years ago, but I don't buy software and the key piece of my suite was shareware that disabled itself after 30 days - not nearly enough time to plow through this boatload of bits.
A few months back I built a system with an Athlon XP 3500+ on an Asus A8N-E mobo w/512MB and 120 GB and 250 GB HD's. I'm hoping to go the RAID route soon - Linux software RAID, in fact. The 250 GB HD is running off an add-in PCI ATA card; both HD's have a UDMA channel all to themselves. The machine's got 4 extra fans, a nicely oversized 485W P/S, and the on-board sensors consistently show it running cool. I'm quite sure this isn't a H/W problem (I'm having no others; I built it myself...). This machine has been absolutely rock-solid in every other regard. I LOVE the system; now if I can simply use it for this one basically administrative project.
I finally have both the speed and the space required to tackle this now-monster project. When I "came home" to Arch a few months ago, I wanted to try several WMs/DMs; GNOME, KDE, E17, fluxbox and ratpoison (at least) are all loaded on my system, and I've booted most at least once. I'd assumed I'd have a LOT of options as to the tools to use.
I've been man-paging and googling and pacman -Q'ing (followed by more googling) for a couple of weeks through the course of my testing thus far, while trying various wrappers in various WMs. My concluson: Houston, we have a problem! <S>Maybe</S> Several.
In the past I've been partial to KDE (that's quickly changing), and it's what I started with this time around. As such, kompare seemed the obvious route to go, and had MOST (NOT all) of the functionality I needed (I also very much like it's GUI). Of course, kompare is simply a wrapper for diff (several diff variants, in fact, potentially). It's possible that diff is the problem. Hopefully further testing (and/or comments here) will make that determination more clearly.
Subsequent googling has revealed that the diff version shipped with Arch likely hasn't been completely functional at all levels in almost *5 YEARS* now. Diff's codefile timestamp is Sept. 3, *2002*! Version 2.8.1 (3.4 is current - just like *kompare*'s current version is 3.4). Additionally, directly below diff in that listing is diff3. Diff's codefile size is about 60K; diff3's is about 20K. *However*, they both have the same timestamp AND version # !!!
A *completely cosmetic* bug (http://bugs.kde.org/show_bug.cgi?id=138347) is fairly clearly the same bug as (https://bugs.launchpad.net/ubuntu/+source/kdesdk/+bug/45466 - 3-1/2 *YEARS* earlier!), and seemingly a trivial patch for a competent maintainer to create, at that. I've verified (w/o even trying) that this bug is resident in my system as we speak. Of course it is - the version of diff Arch is currently shipping was compiled almost a YEAR before the FIRST of the 2 bug reports above were filed! My Arch desktop O/S was installed less than a month ago using the 0.7.2 base ISO (kompare's timestamp is Jan. 20, 2007; version 3.4 - and it's a wrapper for a piece of code last compiled in 2002? What, the 2.0 kernel?). I've aggressively maintained my system current since my very recent install. See how well kompare/diff work on YOUR system...
Indeed, from the kompare bug page, it's hard to believe it's EVER been stable - or even used (see http://bugs.kde.org/simple_search.cgi?i … &offset=20 and just keep on clicking "View More Results" - or get yourself an energiser bunny to do it for you, maybe).
I copied the backups from CD's/DVD's to a clean, freshly-showered 64 GB (62.8, actually) ext3 partition (4K blocksize, defaults otherwise, journal included). I set up a top-level directory in this partition with 15 directories beneath it, one for each of my backup discs (whose contents range in size from 50 MB to 4.36 GB). I copied one archive to each directory, then unpacked them one at a time from the command line, removing the archive copy as I went. I ended up with about 15 GB of active data (25%).
I first configured kompare to use diff (w/no C/L options) running under KDE. As kdiff3 is kompare's preference, however, why is kdiff3 not already in the repos?
I'd not used it before, so I wasn't familiar with kompare's UI. I started out working with a few smaller subsets of the data I knew were near-perfect copies of each other and that wouldn't overload the filesystem. It seemed to act strangely; while I expected it to be well-optimised, both HD activity and CPU utilisation seemed extremely low for extended periods (and note my setup doesn't allow for a HDD LED for the HD on the controller card, where ALL the disk activity is going on).
After 3 runs in a row w/o a single errant file being found, I made a 2-byte mod to a small, non-critical text file that was part of the archive I was currently komparing, rebooting to make DAMNED sure cache was cleared, and reran kompare; identical results. The change STILL wasn't detected (the changed file still showed as being an exact copy of the original). The output I was getting was quite weird: usually, the 'kompare' would run at what seemed a rational speed; after a while a response screen would then open, *completely* devoid of data or messages. Immediately after that an odd dialogue box popped up; the title bar said "Error!", but the *message* was, basically, "No Duplicates Encountered." (or some such), or, more commonly, the same one I encountered repeatedly while searching the internet: "Could not parse diff output." (presumably because kompare still wasn't passing the proper parameters to diff). The program crashed about 1/2 the time (actually, give it a big enough block of data, and it'll crash every time). I was stunned 4 days later when ONE run (an exact duplicate of one I'd already attempted several times) resulted in "proper" output - *PERFECT*, with a complete and correct analysis - and completely unreproduceable, even after rebooting. It's ("It's" = proper analysis/output has) happened 3 times since, twice while working with data sets I would term 'trivial'.
So, in 2 weeks I got 3 runs w/o errors. I assure you I was trying at least 2 runs most days; a 1/2-dozen some days. By then, I also knew that kompare under KDE wasn't my only option - and I knew a bit more.
I use the "usual" repositories. When I finally checked diff's compile date, my jaw dropped: Sept. 3, *2002* !!! It's version 2.8.1; the current stable release is 3.4, and 3.5 is currently available for D/L (albeit not released). V. 2.8.1 works with the 2.6 kernel about as well as the original GWBasic compiler ('interpreter') does in WinXP...and may have been this way for a long time.
More research (difficult, given the age of what little kompare documentation is available on the web). The primary maintainer apparently got removed from maintaining the package in 2003 (and, I presume, other packages, as well) for what appeared to be 'apathy' (MY words). He 'forgot' to include an update after saying he would do so (a patch to pass the appropriate parameters to diff, hopefully fixing the "Could not parse diff output." message, and maybe even straighten out my anomolies, as well).
Kompare hasn't been updated since. Diff3 IS currently being maintained. Actually, even though diff3 has apparently replaced diff, *kompare* prefers kdiff3. For that matter, from my reading thus far, diff, diff3, vimdiff and cmp ALL may possibly be useable (the latter would require some scripting). Further, ALL the following may possibly be made able to work as wrappers (in decreasing order of likelihood, IMNSHO): kompare, krusader, meld, and emelFM2.
So, diff is broken, and it doesn't appear that it's going to be fixed...I personally was a bit consternated when I realised just how off-the-rails kompare was. I see a function such as that provided by kompare as both *critical* AND as a 'black box' function - it HAS to work. Just like the ALU MUST compute 2+2 = 4, or the 'computer' becomes a boat anchor...
So, I D/L'ed meld (for GNOME; it runs under KDE but no help is avalable), then emelFM2 (written for E17, I believe). I've spent the past week trying various combinations of (a) kompare, krusader, meld and emelFM2 as wrappers for diff under (b) KDE, GNOME, and E17. The results have been SO inconsistent it's scary. This includes both giving apparently proper results with a big job on rare occasion (but not consistently reproduceable), and VERY bizarrely, on one occasion, wiping a brand new, 64 *GB* ext3 partition CLEAN. I assure you the remainder of my testing will be on a dedicated partition! This HD is almost braad-new and has given me ZERO other trouble.
Meld was the most consistently performing diff setup I used (on any WM; it worked on them all).
I plan to spend the next 1-2 weeks doing some detailed and structured testing of all possible combos of wrapper/driver/WM, rather than just diff. I also plan to see if it's possible to pass command-line parameters to diff from kompare (if I have the time to spend ANY more w/kompare; kompare clearly isn't what I need - even though it had the . Yes, I *do* know how many combos of 4 wrappers, 4 drivers, and 3 WM's there are (48); my college major was statistics, LOL. And 48 test runs is adequate to test each combo, ONCE...
To me, this task is like big sort jobs were on mainframes a (human, not computer!) generation ago: potentially very large, critical tasks, the results of which aren't always easy to manually double-check. Surely many, if not most, users have a manner of doing this. Diff has apparently been broken for maybe 5 years and THAT wouldn't have gone unnoticed - am I one of the VERY few to even try to use kompare? What do the rest of you use?
Note that after locating and reading as much kompare documentation as possible (I read more BUG reports than anything), I made several important discoveries:
(a) kompare isn't really set up for binary files; it's intended for use with text files. You can specify an option to force a text-mode search, but you apparently canNOT do the reverse.
(b) It err'ed out comparing two M$ 'Word' files, stating they "were binary"...
(c) Worst of all, for me: These files have been archived to CD or DVD, usually repeatedly, and then copied back to disk (I've lost 3 good-sized archives this way - which does serve to somewhat justify my apparently obsessive need to backup files). Kompare does do individual file comparisons (ie, if you specify both files on the command line) byte-by-byte (block-by-block, whatever), but if you request that it compare *directories*, filename and size are all it considers (it appears from the sparse documentation I've seen that this is corrected in the *current* version, . The duplicate-file tool suite I used in Windows did an MD5 hash on *every* file, no matter the size; I *knew* when a bit error had creeped in, and usually knew fairly quickly. Not finding out you have a bad backup until it's the only copy of your data you have left is no good!
Anyone have any suggestions on doing this task efficiently and reliably in Arch?
Again, I believe this to be an upstream problem in a way, but my guess is that if we were using the *current* diffutils to match the KDE version (and a maintainer had done his job in a timely fashion) this bug would NOT exist. My advice, at least until Arch can get diff3 (or, preferably, kdiff3) packaged, STAY AWAY FROM kompare !!! At least with anything critical, at least until this issue is better understood.
Kompare (and diffutils, as well, IMO) needs to be removed from the 'public' repo's until it's close to fixed, at least. Just pkgbuild'ing the current diffutils version (or kdiff3!) is likely the easiest way out. Who knows, MAYBE I'll take a stab at that myself. No promises.
For ANYONE still reading, WOW! TIA. Really. Sorry for the tome.
Blue Skies...g
"It's a lot easier to throw grenades than it is to catch them!" -- Tim Russert

[intro, backups, bla...]I BADLY need to unpack all this stuff, find and toss the duplicates, and truly organise (and efficiently backup) the remainder.
Ok, that's what it's all about.
I'd found a couple of useful tools in the Windows world years ago, but I don't buy software and the key piece of my suite was shareware that disabled itself after 30 days - not nearly enough time to plow through this boatload of bits.
Total Commander rocks.
[killed half a dozen paragrahps or so] It's possible that diff is the problem.
Contratulations. You managed to post 3K of text but still failed to mention what the problem is.
Subsequent googling has revealed that the diff version shipped with Arch likely hasn't been completely functional at all levels in almost *5 YEARS* now. Diff's codefile timestamp is Sept. 3, *2002*! Version 2.8.1 (3.4 is current - just like *kompare*'s current version is 3.4).
http://www.archlinux.org/packages/search/?q=diffutils
You will notice that package isn't flagged out-of-date. That's because the (still current) upstream version is (tadaa!) 2.8.1. Please tell us where you found that 3.4 version.
Additionally, directly below diff in that listing is diff3. Diff's codefile size is about 60K; diff3's is about 20K. *However*, they both have the same timestamp AND version # !!!
WTF??? What listing? You know that diff and diff3 are different programs but still part of the same upstream sources, don't you?
[non-relevant nonsense...] See how well kompare/diff work on YOUR system...
They work fine.
[kompare bashing]
Take a look at the URL, bugs.kde.org, not bugs.archlinux.org. Got it?
I copied the backups from CD's/DVD's to a clean, freshly-showered 64 GB (62.8, actually) ext3 partition (4K blocksize, defaults otherwise, journal included). I set up a top-level directory in this partition with 15 directories beneath it, one for each of my backup discs (whose contents range in size from 50 MB to 4.36 GB). I copied one archive to each directory, then unpacked them one at a time from the command line, removing the archive copy as I went. I ended up with about 15 GB of active data (25%).
I think I could rest my case already at this point.
I first configured kompare to use diff (w/no C/L options) running under KDE. As kdiff3 is kompare's preference, however, why is kdiff3 not already in the repos?
It is: community/kdiff3 0.9.91-1
(I will skip some paragraphs about the actual kompare usage and come back to that at the very end.)
I use the "usual" repositories. When I finally checked diff's compile date, my jaw dropped: Sept. 3, *2002* !!! It's version 2.8.1; the current stable release is 3.4, and 3.5 is currently available for D/L (albeit not released). V. 2.8.1 works with the 2.6 kernel about as well as the original GWBasic compiler ('interpreter') does in WinXP...and may have been this way for a long time.
Please quit that bullshit and show us version 3.4 of the GNU diffutils.
Kompare hasn't been updated since. Diff3 IS currently being maintained. Actually, even though diff3 has apparently replaced diff, *kompare* prefers kdiff3. For that matter, from my reading thus far, diff, diff3, vimdiff and cmp ALL may possibly be useable (the latter would require some scripting). Further, ALL the following may possibly be made able to work as wrappers (in decreasing order of likelihood, IMNSHO): kompare, krusader, meld, and emelFM2.
Check http://websvn.kde.org/ to follow the development progress of kompare, it's part of kdesdk. diff3 is from diffutils 2.8.1 and I wouldn't call that "maintained", but you already know that. It is obviously not a replacement for diff, did you ever read the manpages? And wow, a KDE program prefers to use another KDE program!
[killed quite a bit]Diff has apparently been broken for maybe 5 years and THAT wouldn't have gone unnoticed - am I one of the VERY few to even try to use kompare? What do the rest of you use?
Again, diff is fine and I'm using kompare (or kdiff3?) almost daily, in krusader.
(a) kompare isn't really set up for binary files; it's intended for use with text files. You can specify an option to force a text-mode search, but you apparently canNOT do the reverse.
(b) It err'ed out comparing two M$ 'Word' files, stating they "were binary"...
Genius. Comparing binary files is useless. If you used MS Office you're hosed, that simple. More useful advice at the end.
Anyone have any suggestions on doing this task efficiently and reliably in Arch?
Yep.
Again, I believe this to be an upstream problem in a way, but my guess is that if we were using the *current* diffutils to match the KDE version (and a maintainer had done his job in a timely fashion) this bug would NOT exist. My advice, at least until Arch can get diff3 (or, preferably, kdiff3) packaged, STAY AWAY FROM kompare !!! At least with anything critical, at least until this issue is better understood.
Upstream, right... diffutils have nothing to do with KDE at all... Arch has diff3 and kdiff3 packaged ... it's no 'issue' at all.
Okay, I apologize for that 'tone' of mine but I get pissed easily when wasting so much time on something as this.
I know your problem very well as I'm constantly backing up stuff, comparing directories and hunting duplicates.
After unpacking everything the first step to take is to run a comprehensive check for binary duplicates. My tool of choice for that task is Total Commander (Win32 shareware, no timeout, just a minor nag screen on start, works fine with Wine). Just a few random keyboard shortcuts you might find handy (see the help file for explanations): ctrl-b, ctrl-f1(-f6), ctrl-c,y, alt-f7
After killing them, go on to compare ("synchronize") similar directories, either with Total Commander, Krusader, rsync, diff -R, whatever.
If you encounter similar named files, check the dates and kill the older ones, or compare them if they're not binary.
And so on... you know best what kind of data you got and how to split it up.
Throwing plain diff on a set of thousands of files, possibly gigabytes is a huge waste of time and computing/power resources. Adding a frontend will make it crash most of the time, especially with binary files. I think using kdiff3 to compare the Arch Linux 0.8 base beta1 iso to the beta2 one alone should suffice. A few more gigabytes of RAM might help though.

How to include optimizer hints in Discoverer

We have a Discoverer report which used to run fine prior to DB migration from (9.2.0.6 to 10G Rac 10.2.0.4).
Since the database is migrated to 10g RAC same reports is running for longer time and failes with ROW_ID error,
we ran the sql generated by the report in SQL Plus with below optimizer hint.
Select /*+ optimizer_features_enable('9.2.0') */
this query ran well with optimizer hint, but i am wondering how to use the optimizer hint in Discoverer Plus/Desktop.
Select /*+ optimizer_features_enable('9.2.0') */
C.EMPLOYEE_NUMBER||' '||A.EMPLOYEE_NAME, A.REPORTS_TO, C.SERVICE_CODE, COUNT(B.ACCOUNT_NUMBER)
FROM PSTAGE.NEW_EMPLOYEE_MASTER A,
PSTAGE.NEW_ALL_WORK_ORDER_MASTER B,
PSTAGE.NEW_ALL_WORK_ORDER_DETAIL C
WHERE ( ( B.WORK_ORDER_NUMBER = C.WORK_ORDER_NUMBER AND B.SITE_ID = C.SITE_ID )
AND ( A.EMPLOYEE_NUMBER = C.EMPLOYEE_NUMBER AND A.SITE_ID = C.SITE_ID ) )
AND ( B.WO_STATUS <> 'CN' )
AND ( C.EMPLOYEE_NUMBER = ANY(SELECT S254_200018.EMPLOYEE_NUMBER
FROM PSTAGE.NEW_EMPLOYEE_MASTER S254_199317,
PSTAGE.NEW_ALL_WORK_ORDER_MASTER S254_199854,
PSTAGE.NEW_ALL_WORK_O
Thanks in advance

Hi Sunil
In the Administrator tool, you can add hints to the driving folder used in your query. A first glance at your report seems to indicate that B might be the driver.
If you launch the Administrator tool, open the business area then right-click on the folder in question you can select Properties. The second to last property is called Optimizer hints. Try setting the same hint in here exactly the way you would do it inside SQL.
I am not 100% sure whether this would take as this isn't a folder hint per se, but it is worth a try. You might also want to look at this thread: how to design Optimizer hints to the generated SQL
Another thing to check is to look at the code that is being generated by your Discoverer worksheets. Do you by chance see a NOREWRITE hint being added? This is a common issue with newer systems. This hint tells the database that the query cannot be rewritten which in most cases will cause poor performance. If this is happening to you I advise you to disable that hint. This is done by editing the pref.txt and adding a new preference called
Out of the box, Discoverer Plus will sometimes add the NOREWRITE hint. This will cause Plus worksheets to operate much slower than Desktop worksheets. You can disable the NOREWRITE hint by adding a new preference called UseNoRewriteHint to pref.txt in the Database section. After you have done this you will have to run the apply preferences script.
[Database]
UseNoRewriteHint = 0
Be sure to close all of your IE windows so that a new JVM is loaded.
For example, you might turn on UseNoRewriteHint (i.e. set it to 1) if you want users to always query against the latest data (e.g. created today), even though this might be slower than querying the summary data (e.g. created yesterday). The NOREWRITE hint instructs the optimizer to disable query rewrite for the query block, which overrides the setting of the parameter QUERY_REWRITE_ENABLED.
Default Value: 0
Valid Values
0 = Do not add the NOREWRITE hint. This is the one I recommend.
1 = Do add the NOREWRITE hint.
Another possible area is with query prediction. This is taken from an Oracle Note: Under some circumstance when you run a query against an Oracle 10g database, the queryprediction might take up the majority of time and CPU may hit 100%.
The cause for this is an an Oracle10g (10.1) database issue but seeing as you are on 10.2 this might not be an issue any more. I throw it out there just in case you still hvae issues and want to raise this with Oracle. The last I heard is that the root cause was still under investigation in an unpublished Bug:4024370. There was a workaround to the issue:
1. Disable Query Prediction (strongly recommended anyway):
For Plus/Viewer:
Edit pref.txt on the middle-tier server and set QPPEnable=0
Run the applypreferences script (.sh or .bat)
For Desktop:
Edit the registry and set QPPEnable=0
HKEY_CURRENT_USERS\Software\ORACLE\Discoverer <version>\Database
2. If you still wish to use Query Prediction while the database issue is being investigate, then you can configure the Query Predictor to use the Explain Plan method rather than the Dynamic Views method.
For Plus/Viewer:
Edit pref.txt on the middle-tier server and set QPPObtainCostMethod=0
Run the applypreferences script (.sh or .bat)
For Desktop:
Edit the registry and set QPPObtainCostMethod=0
HKEY_CURRENT_USERS\Software\ORACLE\Discoverer <version>\Database
Hope this helps
Best wishes
Michael

Discoverer Desktop Graphing Questions

I have several questions about the graphing tool in Discoverer Desktop:
1. I'm bringing in a customer id field which I convert with a to_char in the query from a numeric field. Most of them are 5-digit, but some are 4. I notice in the x-axis the customer id's appear only for the 5 digit id's, and for the 4-digit ones the identifier appears. i.e. if the 5th record has an id of 1508, instead of displaying 1508 it displays 5. Does anyone know how to correct this?
2. In the y-axis values, is it possible to display more than 5 decimal places? (We're dealing with very small percentages). When I try to enter 6 or higher as the decimal value in Options, it says invalid number.
3. When I open an existing workbook, it readjusts the y-axis scale to a max of 1, when I've set it to .0001. How I can I make this retain my scale values?
4. Is it possible to display the y-values in the graph area itself next to the plot points?
Thanks for any help!!!!

Hi paul,
Its a good idea to upgrade from 4i to 10g 4i is no more used by many and their are some issues or bugs with it.The latest version is 11g which has been released 1 week back.If not go with 10g version available.
1) Do all reports have to be stored on the database to allow them to be accessed by Plus or Viewer? Can only the 10G client version open files from a local hardrive or shared network drive?Yes they have to stored in the database so any ened user can access them from plus or viewer.
Can only one report be open at any given time with Plus or Viewer? In client it is possible to have 2 reports open at the same time to facilitate easier comparisons.Yes,if the reports are registered as different reports and if the end user has access to both the reports thn he can open and compare it OR if both reports are in same workbook as different sheets than its easy to view or compare.
NULL values are still showing the word "NULL" even though in Tools Options we have set it to show blank, existing reports are still using the NULL value.It should show blank,might be some problem.In discoverer 10g i think you will not find this issues.
Hope this helps you.
Best Wishes,
kranthi.

Discoverer Desktop Report issue

Hi,
One of my user is facing a format issue while running the report in Oracle Discoverer 10g. The report produces the following out put.
count(Col A)     Col B     Col C     Col D
12          A     200709     12-Sep-07
11          A     200709     21-Sep-07
24          B     200709     11-Sep-07
32          B     200709     13-Sep-07
10          B     200710     15-Oct-07
Col A is of number data type, Col B character, Col C is number and Col D is date
if Col D is removed from the report, the user is getting the result in following format
count(Col A)     Col B     Col C
23          A     401418
56          B     401418
10          B     200710
i.e. col C displays the sum of the value based in Col B instead of displaying it as 200709.
but when I ran the report from my end I'm getting the result in a proper manner.
count(Col A)     Col B     Col C
23          A     200709
56          B     200709
10          B     200710
Please help me in sorting out this issue.
Environment Details:
Oracle Discoverer Admin 10g(9.0.4)
Oracle Discoverer Desktop 10g (9.0.4)
End User Layer 5.0.2
Thanks in Advance.
Regards,
SS

@Himanshu3jul:
I'm not using any Oracle Application secure views. Also, the data that are being displayed is proper if Col D is not removed. If user removes Col D, the result is getting aggregated based on Col B but for me it is showing in a perfect manner.
@puppethead:
I'm afraid I may not be able to the check the registry on user machine since user is sitting at a different location.
@Rod West:
The default Aggregate property for Col C is set to <none> and it is grayed out. I'm not able to change it too. Also, if it is a bug then I should get the result as what user receives but I'm not facing any issues in that report but only user is.
Please let me know what can be done next to figure it out.
Also, I have the screen shots from my machine and from user’s. if you think that it will really help then I can post it. please let me know where and how I can post it so that you can have a look at it.
Thanks,
SS

Discoverer 10G Plus Questions

Hi
We're in the process of upgrading from Discoverer 4 (APPS EUL) to 10G. We're doing away with the Desktop client. Most users will be given access to Discoverer Viewer and other users will be given access to Plus. We have recently upgraded or DEV instance and there are a few "questions" (i.e. gripes) that users have come back to me with:
1) Do all reports have to be stored on the database to allow them to be accessed by Plus or Viewer? Can only the 10G client version open files from a local hardrive or shared network drive?
2) Can only one report be open at any given time with Plus or Viewer? In client it is possible to have 2 reports open at the same time to facilitate easier comparisons.
3) NULL values are still showing the word "NULL" even though in Tools Options we have set it to show blank, existing reports are still using the NULL value.
I'd very much appreciate feedback on any of the 3 points above.
Thanks.
Paul.

Hi paul,
Its a good idea to upgrade from 4i to 10g 4i is no more used by many and their are some issues or bugs with it.The latest version is 11g which has been released 1 week back.If not go with 10g version available.
1) Do all reports have to be stored on the database to allow them to be accessed by Plus or Viewer? Can only the 10G client version open files from a local hardrive or shared network drive?Yes they have to stored in the database so any ened user can access them from plus or viewer.
Can only one report be open at any given time with Plus or Viewer? In client it is possible to have 2 reports open at the same time to facilitate easier comparisons.Yes,if the reports are registered as different reports and if the end user has access to both the reports thn he can open and compare it OR if both reports are in same workbook as different sheets than its easy to view or compare.
NULL values are still showing the word "NULL" even though in Tools Options we have set it to show blank, existing reports are still using the NULL value.It should show blank,might be some problem.In discoverer 10g i think you will not find this issues.
Hope this helps you.
Best Wishes,
kranthi.

Question regarding using links in Discoverer 10g

Hi All,
I have a workbook which uses links. The 1st worksheet is connected to the second worksheet using a simple parameter and link. It works fine.
But when a users saves this report and tries to use the link, Discoverer tries to open the work sheet from the query which I had created and not the one from the worksheet which the user has saved.
I am not sure if that the regular feature of the Link functionality or if there is a bug/workaround.
Is it possible to set these reports to open the worksheet from the saved workbook instead of the original one.
Any help is appreciated. Please let me know if I have confused you.
Thanks.

Hi,
I've had a look at this on Metalink and there seems to be lots of different bugs with manage links on 10g.
We build our reports under one user and share it with all other users, easier to manage. We've built some reports exactly has you have and it also works fine. I'll try to resave this as another user and see if we have the same problem.
For info there are links to several different bugs related to lots of scenarios Here (You'll need metalink access).
Couldn't find your exact problem in there so you want to raise it with Oracle.
Regards,
Lloyd

Discoverer printing issues

I must say, having tried to print a simple (nice looking) report in Discoverer desktop, plus, and viewer, I'm thoroughly disgusted with all 3. I've been told by Oracle to use Viewer to format and print reports, but I've run into a major bug that I'll report here (and leave desktop and plus completely out of the picture due to major problems).
I include the page item in the Title at the top of a crosstab report. When I print or export to PDF, a new crosstab displays on each page (in this case page by city, which is the page item). However, the inserted page item in the title doesn't change on each page. The first city displayed remains in the title on each page.
Why do all 3 apps print differently, with different features, with different bugs?

Hi,
Discoverer is an ad-hoc reporting tool and as such isn't designed to produce quality printed reports. The printing features in Discoverer are basic but OK if you are just interested in content rather than layout. If you want to produce quality reports you should consider using XML Publisher which can be integrated with Discoverer.
Rod West

Excel 2013 BeforeRightClick Event fails on Windows 8.1 Tablet (it's an Excel 2013 tablet touch screen interface bug)

I have developed customized table context menus in an Excel 2013 workbook on my Laptop. They work just fine on my laptop and my work desktop. But when I try to run them on my tablet PC the Worksheet_BeforeRightClick event in Excel 2013 never fires. Other
worksheet events appear to work okay. I have fully reinstalled Office 2013 Pro and that does not make any difference.
I have read other comments regarding this same problem going back to 2013, but have never seen Microsoft respond to this issue. Nor have I been able to find a resolution. Has anyone else run into this and found a solution?
Additional Discoveries: Testing on my tablet shows that adding one custom CommandBarButton to either the top or the bottom of the default "List Range Popup" context menu causes the Worksheet_BeforeRightClick event to fail. The basic context
menu commands still show up, but the default dropdown button for additional context menu commands disappears. The event is perhaps firing, but any customized code for the context menu is not being handled properly by Excel. This does appear to be a bug and
not a question of coding error. Perhaps someone else with a tablet PC running WIndows 8.1 could test this.
Based on comments
here this bug was introduced in Excel 2013 because others find the problem does not exist when using Excel 2010 on a tablet PC. Note that all the commenters on the linked thread that are experiencing this problem are using tablet PCs.
Update 3-13-15: I stand corrected. The Worksheet_BeforeRightClick does work on Excel 2013 Windows 8.1 tablets. I happen to own an Asus VivoTab Note 8, which comes with a Wacom stylus. If I use the Wacom sylus to right click on an Excel 2013 worksheet cell,
the Worksheet_BeforeRightClick event fires and modified context menu code runs just fine. But the code will not run if one uses their finger to right click a worksheet cell. This explains why this problem only shows up on tablet PCs. So the "bug"
introduced in Excel 2013 is a general user touch screen interface bug and not an Excel events programming bug.
Update 3-21-15: Switched to a Toshiba Protege laptop with touch screen. Same issue with finger touch screen interface on the Toshiba touch screen as with the Asus VivoTab touch screen.
Laptop: Toshiba Protege (with touch screen), Windows 8.1 64bit and MSOffice 2013 Pro 32bit
Tablet: Asus VivoTab Note 8, Windows 8.1 32bit and MSOffice 2013 Pro 32 bit
Desktop: Generic, Windows 7 64bit and MSOffice 2013 Pro 64bit
phillfri

Hello Phil,
Command bars were deprecated and shouldn't be used any longer. Instead, you need to use the Fluent UI (aka Ribbon UI) instead. You can read more about the new UI in the following series of articles in MSDN:
Customizing Context Menus in Office 2010
Customizing the 2007 Office Fluent Ribbon for Developers (Part 1 of 3)
Customizing the 2007 Office Fluent Ribbon for Developers (Part 2 of 3)
Customizing the 2007 Office Fluent Ribbon for Developers (Part 3 of 3)
As a workaround you can add a custom control to the context
menu with the getEnabled or getVisible callback which will be invoked before the context menu is shown.

Discoverer 3.1.36.06 bug?

Similar Messages

Maybe you are looking for