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

Similar Messages

  • Discoverer Viewer - Drill down option

    Dear all
    I created a report in discoverer desktop, with drill down option for financial information.It works fine in Disco Desktop. All the drill down options are working fine as well. But the same report when run in disco viewer, it has got an option for drilling down further, then another option for collapse(with the blue button) - to view the summary value.
    When the collapse option is chosen, the blue color button disappears in Viewer and wouldnt know how to drill down back without reloging into the application.
    Could you please help me how to solve this problem, as I need to share this report with users who has viewer access only?We are using 9i at the moment.
    Thanks.

    Hi Russ
    I have heard folks having awful issues with IE 7. It seems to mess up everything Oracle. Sounds like Oracle and Microsoft have some hurdles to cross. For now I would advise everyone to either stay on IE 6 or use another browswer like Firefox.
    To answer the specific question posted here, it is possible that the user has hit one of the well known Discoverer bugs wherein Discoverer Viewer cannot properly execute workbooks created in Desktop. There are fixes and one-off patches available for this in MetaLink but these patches all require a password to download them. I would advise the raising of a service request and in the request spefically ask if there is a one-off patch that will fix this.
    Best wishes for now
    Michael

  • Oracle Discoverer - Unable to Login

    I was able to download and install the Oracle Discoverer 4.1.3 sucessfully. But at the time of logging in i'm unable to connect the database as i do not have the user-id password and the connect string. I would appreciate if you can help me out in doing the same and also plz send me some steps to log in and get connected to the database and how to start working on Oracle Discoverer
    Thanks

    Hi,
    You can try putting double quotes round the username, e.g. "DISC USER" but I think this may be a bug in Discoverer Plus/Viewer 10g. You would have to check with support.
    Rod West

  • Data model: single quote in default parameter value

    Hello,
    when I assign a default value to a parameter in my Data model, which includes a single quote (i.e. "It's a default value"), then the single quote is escaped with a backslash (i.e. "It\'s a default value") when I open the report associated with the data model. How can I get rid of the escape character when opening a report?
    Regards,
    Jure

    Hi Yogini,
    Thanks for your reply.
    When the customer name is selected, discoverer reports automatically enclose the customer names in single quotes. like 'ABC LTD', 'ABC's INC',
    I know how to change this single quote format. Also we don't want user to change the parameter selection criteria once selected.
    Also related to double quotes isn't it doubles are treated as column names in the SQL query and can not be used for any other purpose.
    Apologies, I haven't tried this but I think it will not work. Have you tried this with discoverer viewer.
    As mentioned intrusting things is when a customer name with single quote is selected in discoverer Plus it automatically formats the filter criteria to look like ['ABC LTD', 'ABC''s INC'] but this thing doesn't happen in viewer.
    I think this is a bug in discoverer viewer and think there must be some patch available to correct this problem.
    Sorry, don't have a solution yet but will certainly update the thread once I get the solution.
    Also please keep looking for a solution and let me know as well.
    Thanks a lot in advance.
    Best Regards,
    Manish

  • Single Quote in Parameter values...!

    Hi there,
    I am using oracle oracle disco. 10g
    In my report there are 2 parameters. First being the customer name and another being the transaction reference. Transaction reference parameter is based on the customer name(s) selected.
    The customer data contains a single quote [e.g. ABC's]. Thus, when the user selects the customer name [with a single quote] and tries to select the transaction reference - discoverer viewer returns an error message - 'Invalid Value'
    This does not happens in discoverer plus.
    Imp: We can not change the data - otherwise I would have remove the single quote from the customer name as part of my query.
    any ideas..!
    Any help would be really appreciated.
    Best Regards,
    Manish

    Hi Yogini,
    Thanks for your reply.
    When the customer name is selected, discoverer reports automatically enclose the customer names in single quotes. like 'ABC LTD', 'ABC's INC',
    I know how to change this single quote format. Also we don't want user to change the parameter selection criteria once selected.
    Also related to double quotes isn't it doubles are treated as column names in the SQL query and can not be used for any other purpose.
    Apologies, I haven't tried this but I think it will not work. Have you tried this with discoverer viewer.
    As mentioned intrusting things is when a customer name with single quote is selected in discoverer Plus it automatically formats the filter criteria to look like ['ABC LTD', 'ABC''s INC'] but this thing doesn't happen in viewer.
    I think this is a bug in discoverer viewer and think there must be some patch available to correct this problem.
    Sorry, don't have a solution yet but will certainly update the thread once I get the solution.
    Also please keep looking for a solution and let me know as well.
    Thanks a lot in advance.
    Best Regards,
    Manish

  • Levels not correctly visualized

    Hello, I'm using Discoverer v. 10.1.2, and my database version is 10g r. 1 (10.1.0.4.2). My olap objects are in CWM2 catalog.
    When I build a new crosstab, the levels of my dimensions are not correctly visualized: for example, a node of a level that has children shows his children correctly, but his son (that has children too) doesn't show his children.
    Is this a bug of Discoverer ? Is there a solution or patch ?
    Thanks a lot by your help

    Please check if you have any media connected to your iMac when you shut it down. Any volumes connected under /Volumes/?

  • Recently Used Workbook list

    Hello,
    Can anyone tell me why my "Recently Used Workbook" list is empty in relational Discoverer 10g. We are using version 10.1.2.0.2. Any assistance would be greatly appreciated.
    Thanks,
    Carl

    Hello,
    Can anyone tell me why my "Recently Used Workbook"
    list is empty in relational Discoverer 10g. We are
    using version 10.1.2.0.2. Any assistance would be
    greatly appreciated.
    This is a BUG in Discoverer but there is a workaround.
    Edit the $ORACLE_HOME/discoverer/.reg_key.dc file and find this location:
    [HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\WebDisco 10\Default\Application]
    Under this, put this:
    "MRU List Length"=D4:4:05,00,00,00
    It should be put just before this line:
    "MRUEnabled"=D4:4:01,00,00,00
    The MRU Enabled is in the Pref.txt file but the length of this list is default to 0 and it is not in the pref.txt. Each user can change their MRU List Length but that it is at the user level, not the server level. By adding the MRU List Length as I have shown above, all users will default to showing the last 5 Workbooks.

  • 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.

  • 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?

  • 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

Maybe you are looking for