Query returninng different result

When I run this query:
create or replace
PROCEDURE PROC IS
BEGIN
insert into TEMP
*(aaa,bbb,ccc)*
*(SELECT aaa,bbb,ccc,instanceid*
FROM a, b
WHERE some conditions
and to_char(ddd,'DD-MON-YY') = (select to_char(sysdate-2)  from dual))
and a.instanceid not in (select TEMP.instanceid from TEMP  ));
commit;
END PROC;
I get 477 records
but when I run
(SELECT aaa,bbb,ccc,instanceid*
FROM a, b
WHERE some conditions
and to_char(ddd,'DD-MON-YY') = (select to_char(sysdate-2)  from dual))
and a.instanceid not in (select TEMP.instanceid from TEMP  ))
I get 489 records.
How can this happen, the two querie are different?
What I am trying to do is to have a procedure that is run every 10 min and inserts into table temp all records that have not been added since the last call of the procedure during same day.

first query to be run
select count() from a, b where((((a.a1 = 'P') or (a.a2 is not NULL))*
and a.a4 = 'EX'
and ((a.a3 = '3111')
or (a.a3 = '3311')
or (a.a3 = '3312')
or (a.a3 = '315')
or (a.a3 = '3131'))
OR
*(a.a1 = 'P'*
and a.a4 = 'IM'
and ((a.a5 = '3111')
or (a.a5 = '3311')
or (a.a5 = '3312')
or (a.a5 = '315')
or (a.a5 = '3131'))
*)) and ( a.instanceid = b.instanceid*
and to_char(date,'DD-MON-YY') = (select to_char(sysdate-2)  from dual)
and a.instanceid not in (select TEMP.instanceid from TEMP  ));
second query is the procedure
create or replace
PROCEDURE PROC IS
BEGIN
insert into TEMP
*(SELECT **
from a, b where((((a.a1 = 'P') or (a.a2 is not NULL))
and a.a4 = 'EX'
and ((a.a3 = '3111')
or (a.a3 = '3311')
or (a.a3 = '3312')
or (a.a3 = '315')
or (a.a3 = '3131'))
OR
*(a.a1 = 'P'*
and a.a4 = 'IM'
and ((a.a5 = '3111')
or (a.a5 = '3311')
or (a.a5 = '3312')
or (a.a5 = '315')
or (a.a5 = '3131'))
*)) and ( a.instanceid = b.instanceid*
and to_char(date,'DD-MON-YY') = (select to_char(sysdate-2)  from dual)
and a.instanceid not in (select TEMP.instanceid from TEMP  ));
commit;

Similar Messages

  • Same query giving different results

    Hi
    I m surprised to see the behaviour of oracle. I have two different sessions for same scheema on same server. In both sessions same query returns different results. The query involves some calculations like sum and divisions on number field.
    I have imported this data from another server using export / import utility available with 9i server. Before export every thing was going fine. Is there some problem with this utility.
    I m using Developer 6i as the front end for my client server application. The behaviour of my application is very surprizing as once it shows the correct data and if I close the screen and reopen, it shows wrong data.
    I m really stucked with the abnormal behaviour. Please tell me the possiblities and corrective action for these conditions.
    Regards
    Asad.

    There is nothing uncommitted in both the sessions. But still different results are returned.
    I m sending u the exact query and result returned in both sessions.
    Session 1:
    SQL> rollback;
    Rollback complete.
    SQL> SELECT CC.CREDIT_HRS,GP.GRADE_PTS
    2 FROM GRADE G, COURSE_CODE CC, GRADE_POLICY GP
    3 WHERE G.COURSE_CDE=CC.COURSE_CDE
    4 AND G.SELECTION_ID=45 AND G.GRADE_TYP=GP.GRADE_TYP
    5 AND G.TERM_PROG_ID=17 AND GP.TERM_ID=14
    6 /
    CREDIT_HRS GRADE_PTS
    3 4
    4 3.33
    4 3.33
    3 4
    3 4
    3 4
    3 4
    7 rows selected.
    SQL>
    SESSION 2:
    SQL> rollback;
    Rollback complete.
    SQL> SELECT CC.CREDIT_HRS,GP.GRADE_PTS
    2 FROM GRADE G, COURSE_CODE CC, GRADE_POLICY GP
    3 WHERE G.COURSE_CDE=CC.COURSE_CDE
    4 AND G.SELECTION_ID=45 AND G.GRADE_TYP=GP.GRADE_TYP
    5 AND G.TERM_PROG_ID=17 AND GP.TERM_ID=14
    6 /
    CREDIT_HRS GRADE_PTS
    3 4
    4 3.33
    3 4
    3 4
    3 4
    3 4
    6 rows selected.
    SQL>
    U can see in session 1, seven rows are returned while in session 2 six rows are returned. I have issued a rollback before query to be sure that data in both sessions is same.

  • Oracle function and query return different results

    Hi, I am using oracle 10g database.
    Function is :
    create or replace FUNCTION FUNC_FAAL(myCode number,firstDate date
    *, secondDate date)*
    RETURN INTEGER as
    rtr integer;
    BEGIN
    select count() into rtr*
    from myschema.my_table tbl where tbl.myDateColumn between firstDate and
    secondDate and tbl.kkct is null and tbl.myNumberColumn  = myCode ;
    return (rtr);
    END FUNC_FAAL;
    This function returns 117177 as result.
    But if I run same query in the function seperately ;
    select count()*
    from myschema.my_table tbl
    where tbl.myDateColumn between firstDate and secondDate
    and tbl.kkct is null and tbl.myNumberColumn  = myCode ;
    I get different result 11344 (which is the right one).
    Table and function are in the same schema.
    What can be the problem ?
    Thanks.

    1. i think ur parameter name and Column names are same Firstdate and seconddate try to choose different name
    2. try using Trunc function around your dates
    where trunc(tbl.myDateColumn) between trunc(firstDate) and trunc(secondDate)then compare the result....sometimes time elements comes into play.
    Baig
    [My Oracle Blog|http://baigsorcl.blogspot.com/]

  • SQL Query produces different results when inserting into a table

    I have an SQL query which produces different results when run as a simple query to when it is run as an INSERT INTO table SELECT ...
    The query is:
    SELECT   mhldr.account_number
    ,        NVL(MAX(DECODE(ap.party_sysid, mhldr.party_sysid,ap.empcat_code,NULL)),'UNKNWN') main_borrower_status
    ,        COUNT(1) num_apps
    FROM     app_parties ap
    SELECT   accsta.account_number
    ,        actply.party_sysid
    ,        RANK() OVER (PARTITION BY actply.table_sysid, actply.loanac_latype_code ORDER BY start_date, SYSID) ranking
    FROM     activity_players actply
    ,        account_status accsta
    WHERE    1 = 1
    AND      actply.table_id (+) = 'ACCGRP'
    AND      actply.acttyp_code (+) = 'MHLDRM'
    AND      NVL(actply.loanac_latype_code (+),TO_NUMBER(SUBSTR(accsta.account_number,9,2))) = TO_NUMBER(SUBSTR(accsta.account_number,9,2))
    AND      actply.table_sysid (+) = TO_NUMBER(SUBSTR(accsta.account_number,1,8))
    ) mhldr
    WHERE    1 = 1
    AND      ap.lenapp_account_number (+) = TO_NUMBER(SUBSTR(mhldr.account_number,1,8))
    GROUP BY mhldr.account_number;      The INSERT INTO code:
    TRUNCATE TABLE applicant_summary;
    INSERT /*+ APPEND */
    INTO     applicant_summary
    (  account_number
    ,  main_borrower_status
    ,  num_apps
    SELECT   mhldr.account_number
    ,        NVL(MAX(DECODE(ap.party_sysid, mhldr.party_sysid,ap.empcat_code,NULL)),'UNKNWN') main_borrower_status
    ,        COUNT(1) num_apps
    FROM     app_parties ap
    SELECT   accsta.account_number
    ,        actply.party_sysid
    ,        RANK() OVER (PARTITION BY actply.table_sysid, actply.loanac_latype_code ORDER BY start_date, SYSID) ranking
    FROM     activity_players actply
    ,        account_status accsta
    WHERE    1 = 1
    AND      actply.table_id (+) = 'ACCGRP'
    AND      actply.acttyp_code (+) = 'MHLDRM'
    AND      NVL(actply.loanac_latype_code (+),TO_NUMBER(SUBSTR(accsta.account_number,9,2))) = TO_NUMBER(SUBSTR(accsta.account_number,9,2))
    AND      actply.table_sysid (+) = TO_NUMBER(SUBSTR(accsta.account_number,1,8))
    ) mhldr
    WHERE    1 = 1
    AND      ap.lenapp_account_number (+) = TO_NUMBER(SUBSTR(mhldr.account_number,1,8))
    GROUP BY mhldr.account_number;      When run as a query, this code consistently returns 2 for the num_apps field (for a certain group of accounts), but when run as an INSERT INTO command, the num_apps field is logged as 1. I have secured the tables used within the query to ensure that nothing is changing the data in the underlying tables.
    If I run the query as a cursor for loop with an insert into the applicant_summary table within the loop, I get the same results in the table as I get when I run as a stand alone query.
    I would appreciate any suggestions for what could be causing this odd behaviour.
    Cheers,
    Steve
    Oracle database details:
    Oracle Database 10g Release 10.2.0.2.0 - Production
    PL/SQL Release 10.2.0.2.0 - Production
    CORE 10.2.0.2.0 Production
    TNS for 32-bit Windows: Version 10.2.0.2.0 - Production
    NLSRTL Version 10.2.0.2.0 - Production
    Edited by: stevensutcliffe on Oct 10, 2008 5:26 AM
    Edited by: stevensutcliffe on Oct 10, 2008 5:27 AM

    stevensutcliffe wrote:
    Yes, using COUNT(*) gives the same result as COUNT(1).
    I have found another example of this kind of behaviour:
    Running the following INSERT statements produce different values for the total_amount_invested and num_records fields. It appears that adding the additional aggregation (MAX(amount_invested)) is causing problems with the other aggregated values.
    Again, I have ensured that the source data and destination tables are not being accessed / changed by any other processes or users. Is this potentially a bug in Oracle?Just as a side note, these are not INSERT statements but CTAS statements.
    The only non-bug explanation for this behaviour would be a potential query rewrite happening only under particular circumstances (but not always) in the lower integrity modes "trusted" or "stale_tolerated". So if you're not aware of any corresponding materialized views, your QUERY_REWRITE_INTEGRITY parameter is set to the default of "enforced" and your explain plan doesn't show any "MAT_VIEW REWRITE ACCESS" lines, I would consider this as a bug.
    Since you're running on 10.2.0.2 it's not unlikely that you hit one of the various "wrong result" bugs that exist(ed) in Oracle. I'm aware of a particular one I've hit in 10.2.0.2 when performing a parallel NESTED LOOP ANTI operation which returned wrong results, but only in parallel execution. Serial execution was showing the correct results.
    If you're performing parallel ddl/dml/query operations, try to do the same in serial execution to check if it is related to the parallel feature.
    You could also test if omitting the "APPEND" hint changes anything but still these are just workarounds for a buggy behaviour.
    I suggest to consider installing the latest patch set 10.2.0.4 but this requires thorough testing because there were (more or less) subtle changes/bugs introduced with [10.2.0.3|http://oracle-randolf.blogspot.com/2008/02/nasty-bug-introduced-with-patch-set.html] and [10.2.0.4|http://oracle-randolf.blogspot.com/2008/04/overview-of-new-and-changed-features-in.html].
    You could also open a SR with Oracle and clarify if there is already a one-off patch available for your 10.2.0.2 platform release. If not it's quite unlikely that you are going to get a backport for 10.2.0.2.
    Regards,
    Randolf
    Oracle related stuff blog:
    http://oracle-randolf.blogspot.com/
    SQLTools++ for Oracle (Open source Oracle GUI for Windows):
    http://www.sqltools-plusplus.org:7676/
    http://sourceforge.net/projects/sqlt-pp/

  • Same Query returning different result (Different execution plan)

    Hi all,
    To day i have discovered a strange thing: a query that return a different result when using a different execution plan.
    The query :
    SELECT  *
      FROM schema.table@database a
    WHERE     column1 IN ('3')
           AND column2 = '101'
           AND EXISTS
                  (SELECT null
                     FROM schema.table2 c
                    WHERE a.column3 = SUBSTR (c.column1, 2, 12));where schema.table@database is a remote table.
    when executed with the hint /*+ ordered use_nl(a c) */ these query return no result and its execution plan is :
    Rows     Row Source Operation
          0  NESTED LOOPS  (cr=31 r=0 w=0 time=4894659 us)
       4323   SORT UNIQUE (cr=31 r=0 w=0 time=50835 us)
       4336    TABLE ACCESS FULL TABLE2 (cr=31 r=0 w=0 time=7607 us)
          0   REMOTE  (cr=0 r=0 w=0 time=130536 us)When i changed the execution plan with the hint /*+ use_hash(c a) */
    Rows     Row Source Operation
       3702  HASH JOIN SEMI (cr=35 r=0 w=0 time=497839 us)
      22556   REMOTE  (cr=0 r=0 w=0 time=401176 us)
       4336   TABLE ACCESS FULL TABLE2 (cr=35 r=0 w=0 time=7709 us)It seem that when the execution plan have changed the remote query return no result.
    It'is a bug or i have missed somthing ?
    PS: The two table are no subject to insert or update statement.
    Oracle version : 9.2.0.2.0
    System version : HP-UX v1
    Thanks.

    H.Mahmoud wrote:
    Oracle version : 9.2.0.2.0
    System version : HP-UX v1Hard to say. You're using a very old and deprecated version of the database, and one that was known to contain bugs.
    9.2.0.7 was really the lowest version of 9i that was considered to be 'stable', but even so, it's old and lacking in many ways.
    Consider upgrading to the latest database version at your earliest opportunity. (or at least apply patches up to the latest 9i version before querying if there is bugs in your really low buggy version)

  • Same query returning different result set

    hi all,
    i am using db 10g.
    i have a query like below
      SELECT SUM(EID_AMOUNT)amt,EID_INCR_CODE,EIH_EFF_DATE
         FROM EMP_INC_HEADER,EMP_INC_DETAILS
        WHERE EIH_EMP_CODE = EID_EMP_CODE
          AND EIH_EFF_DATE = EIH_EFF_DATE
          AND EIH_STATUS   = 'P'
          AND EID_EMP_CODE = '003848'
    GROUP BY EID_INCR_CODE,EIH_EFF_DATE
    ORDER BY EID_INCR_CODE,EIH_EFF_DATE;which is leading to the output
          AMT EID_INCR_CODE   EIH_EFF_D
         2000 BASIC           21-SEP-10
         2000 BASIC           23-SEP-10
         2000 BASIC           15-OCT-10
         2000 BASIC           21-OCT-10
         1200 HTRAN           21-SEP-10
         1200 HTRAN           23-SEP-10
         1200 HTRAN           15-OCT-10
         1200 HTRAN           21-OCT-10
          800 OTHERS          21-SEP-10
          800 OTHERS          23-SEP-10
          800 OTHERS          15-OCT-10
          800 OTHERS          21-OCT-10i have query
    SELECT SUM(EID_AMOUNT)amt,EID_INCR_CODE,EID_EFF_DATE
    FROM EMP_INC_HEADER,EMP_INC_DETAILS
    WHERE EIH_EMP_CODE = EID_EMP_CODE
    AND EIH_EFF_DATE = EID_EFF_DATE
    AND EIH_STATUS = 'P'
    AND EID_EMP_CODE = '003848'
    GROUP BY EID_INCR_CODE,EID_EFF_DATE
    ORDER BY EID_INCR_CODE,EID_EFF_DATE;
    leading to
          AMT EID_INCR_CODE   EID_EFF_D
          500 BASIC           21-SEP-10
          500 BASIC           23-SEP-10
          500 BASIC           15-OCT-10
          500 BASIC           21-OCT-10
          300 HTRAN           21-SEP-10
          300 HTRAN           23-SEP-10
          300 HTRAN           15-OCT-10
          300 HTRAN           21-OCT-10
          200 OTHERS          21-SEP-10
          200 OTHERS          23-SEP-10
          200 OTHERS          15-OCT-10
          200 OTHERS          21-OCT-10
    12 rows selected.what second query is returning is correct. as per the table.
    but my question what is the difference between my first and second query.
    in what way it is different(i am not getting any idea).
    if any one is having any clue please share with me.
    Thanks..

    what is the difference between my first and second queryLook like there's no difference.
    I think you really meant something like
    SELECT SUM(EID_AMOUNT) amt,EID_INCR_CODE,EIH_EFF_DATE
      FROM EMP_INC_HEADER EIH,
           EMP_INC_DETAILS EID
    WHERE EIH.EMP_CODE = EID.EMP_CODE
       AND EIH.EFF_DATE = EIH.EFF_DATE
       AND EIH.STATUS   = 'P'
       AND EID.EMP_CODE = '003848'
    GROUP BY EID.INCR_CODE,EIH.EFF_DATE
    ORDER BY EID.INCR_CODE,EIH.EFF_DATERegards
    Etbin

  • Report Query shows different result when executed manually

    Hi!
    When I run our report I'll get 7577 distinct rows.
    From here on I copied the SQL query with SQL inspector, then pasted it in Oracle SQL Developer and replaced the user variable with the same value I entered when I ran the report from within Oracle Discoverer Desktop.
    But when I run this query I'll get 10925 distinct rows.
    How is that even possible??? I think the SQL inspector is supposed to print the exact same query which he used to display the data in the report? Am I missing something here?
    Thanks in advance!

    I found my error.
    I queried v$sql to get the real quey sent to the database and then saw how it actually got processed. I'ts ok now.

  • Analytical query producing different result on joins

    Hi,
    The queries below should have the same output but the first one just does a left join instead of a full join. Can you please help me figure out why ?
    SELECT source_aa, source_bb, COUNT (*)
    FROM (SELECT *
    FROM (SELECT a_a.application_id,
    'In_APPLICATION' AS source_aa,
    RANK () OVER (PARTITION BY application_id ORDER BY date DESC) AS rank_aa
    FROM application a_a)
    WHERE rank_aa = 1) aa
    FULL JOIN
    (SELECT *
    FROM (SELECT b_b.application_id,
    'In_APPLICATION_ARCHV' AS source_bb,
    RANK () OVER (PARTITION BY application_id ORDER BY date DESC) AS rank_bb
    FROM application_archv b_b)
    WHERE rank_bb = 1) bb
    ON aa.application_id = bb.application_id
    GROUP BY source_aa, source_bb;
    SELECT source_aa, source_bb, COUNT (*)
    FROM (SELECT DISTINCT application_id,'In_APPLICATION' AS source_aa
    FROM application) aa
    FULL JOIN
    (SELECT DISTINCT application_id,'In_APPLICATION_ARCHV' AS source_bb
    FROM application_archv) bb
    ON aa.application_id = bb.application_id
    GROUP BY source_aa, source_bb;
    -----

    Both your query does a FULL JOIN. But in the first query you have extra filter condition. You are geting only the latest application_id. Check this
    <pre>
    SELECT *
    FROM (
    SELECT b_b.application_id
    , 'In_APPLICATION_ARCHV' AS source_bb
    <font color=red>
    , RANK () OVER (PARTITION BY application_id ORDER BY date DESC) AS rank_bb
    </font>
    FROM application_archv b_b
    <font color=red>
    WHERE rank_bb = 1
    </font>
    </pre>
    The the code in red is the once thats causing the difference in output.

  • Execute the same query twice, get two different results

    I have a query that returns two different results:
    Oracle Version : 10.2.0.1.0
    I am running the following query on the Oracle server in SQL*Plus Worksheet.
    SELECT COUNT(*)
    FROM AEJOURNAL_S1
    WHERE CHAR_TIME BETWEEN TO_DATE('12-AUG-10 01:17:39 PM','DD-MON-YY HH:MI:SS AM') AND
    TO_DATE('13-AUG-10 14:17:34','DD-MON-YY HH24:MI:SS')
    AND DESC2 LIKE '%'
    AND DESC1 LIKE '%'
    AND DESC2 LIKE '%'
    AND ETYPE LIKE '%'
    AND MODULE LIKE '%'
    AND LEVELL = '11-WARNING'
    ORDER BY ORDD DESC;
    The very first time the query is run, it will return a count of 259. The next time the query is run, lets say, 10 seconds later, it will return a count of 260. The above query is exemplary of the kind of thing I'm trying to do. It seems like the more fields filtered against '%', the more random the count return becomes. Sometime you have to execute the query three or four times before it levels out to a consistent number.
    I'm using '%' as the default for various fields, because this was the easiest thing to do to support a data-driven Web interface. Maybe I have to 'dynamically' build the entire where clause, instead of just parameterizing the elements and having default '%'. Anyway, to eliminate the web interface for the purpose of troubleshooting the above query was run directly on the Oracle server.
    This query runs against a view. The view does a transpose of data from a table.
    Below is the view AEJOURNAL_S1
    SELECT
    CHAR_TIME,
    CHAR_INST,
    BATCH_ID,
    MIN(DECODE(CHAR_ID,6543,CHAR_VALUE)) AS ORDD,
    MIN(DECODE(CHAR_ID,6528,CHAR_VALUE)) AS AREAA,
    MIN(DECODE(CHAR_ID,6529,CHAR_VALUE)) AS ATT,
    COALESCE(MIN(DECODE(CHAR_ID,6534,CHAR_VALUE)),'N/A') AS CATAGORY,
    MIN(DECODE(CHAR_ID,6535,CHAR_VALUE)) AS DESC1,
    MIN(DECODE(CHAR_ID,6536,CHAR_VALUE)) AS DESC2,
    MIN(DECODE(CHAR_ID,6537,CHAR_VALUE)) AS ETYPE,
    MIN(DECODE(CHAR_ID,6538,CHAR_VALUE)) AS LEVELL,
    MIN(DECODE(CHAR_ID,6539,CHAR_VALUE)) AS MODULE,
    MIN(DECODE(CHAR_ID,6540,CHAR_VALUE)) AS MODULE_DESCRIPTION,
    MIN(DECODE(CHAR_ID,6541,CHAR_VALUE)) AS NODE,
    MIN(DECODE(CHAR_ID,6542,CHAR_VALUE)) AS STATE,
    MIN(DECODE(CHAR_ID,6533,CHAR_VALUE)) AS UNIT
    FROM CHAR_BATCH_DATA
    WHERE subbatch_id = 1774
    GROUP BY CHAR_TIME, CHAR_INST, BATCH_ID
    So... why does the query omit rows on the first execution? Is this some sort of optimizer issue. Do I need to rebuild indexes? I looked at the indexes, they are all valid.
    Thanks for looking,
    Dan

    user2188367 wrote:
    I have a query that returns two different results:
    Oracle Version : 10.2.0.1.0
    I am running the following query on the Oracle server in SQL*Plus Worksheet.
    SELECT COUNT(*)
    FROM AEJOURNAL_S1
    WHERE CHAR_TIME BETWEEN TO_DATE('12-AUG-10 01:17:39 PM','DD-MON-YY HH:MI:SS AM') AND
    TO_DATE('13-AUG-10 14:17:34','DD-MON-YY HH24:MI:SS')
    AND DESC2 LIKE '%'
    AND DESC1 LIKE '%'
    AND DESC2 LIKE '%'
    AND ETYPE LIKE '%'
    AND MODULE LIKE '%'
    AND LEVELL = '11-WARNING'
    ORDER BY ORDD DESC;
    The very first time the query is run, it will return a count of 259. The next time the query is run, lets say, 10 seconds later, it will return a count of 260. The above query is exemplary of the kind of thing I'm trying to do. It seems like the more fields filtered against '%', the more random the count return becomes. Sometime you have to execute the query three or four times before it levels out to a consistent number.
    I'm using '%' as the default for various fields, because this was the easiest thing to do to support a data-driven Web interface. Maybe I have to 'dynamically' build the entire where clause, instead of just parameterizing the elements and having default '%'. Anyway, to eliminate the web interface for the purpose of troubleshooting the above query was run directly on the Oracle server.
    This query runs against a view. The view does a transpose of data from a table.
    Below is the view AEJOURNAL_S1
    SELECT
    CHAR_TIME,
    CHAR_INST,
    BATCH_ID,
    MIN(DECODE(CHAR_ID,6543,CHAR_VALUE)) AS ORDD,
    MIN(DECODE(CHAR_ID,6528,CHAR_VALUE)) AS AREAA,
    MIN(DECODE(CHAR_ID,6529,CHAR_VALUE)) AS ATT,
    COALESCE(MIN(DECODE(CHAR_ID,6534,CHAR_VALUE)),'N/A') AS CATAGORY,
    MIN(DECODE(CHAR_ID,6535,CHAR_VALUE)) AS DESC1,
    MIN(DECODE(CHAR_ID,6536,CHAR_VALUE)) AS DESC2,
    MIN(DECODE(CHAR_ID,6537,CHAR_VALUE)) AS ETYPE,
    MIN(DECODE(CHAR_ID,6538,CHAR_VALUE)) AS LEVELL,
    MIN(DECODE(CHAR_ID,6539,CHAR_VALUE)) AS MODULE,
    MIN(DECODE(CHAR_ID,6540,CHAR_VALUE)) AS MODULE_DESCRIPTION,
    MIN(DECODE(CHAR_ID,6541,CHAR_VALUE)) AS NODE,
    MIN(DECODE(CHAR_ID,6542,CHAR_VALUE)) AS STATE,
    MIN(DECODE(CHAR_ID,6533,CHAR_VALUE)) AS UNIT
    FROM CHAR_BATCH_DATA
    WHERE subbatch_id = 1774
    GROUP BY CHAR_TIME, CHAR_INST, BATCH_ID
    So... why does the query omit rows on the first execution? Is this some sort of optimizer issue. Do I need to rebuild indexes? I looked at the indexes, they are all valid.
    Thanks for looking,
    DanIn fact you the first time you ran the query the data has been retrived from disk to memory , in the second time the data is already in memory so the respnse time should be faster ,but if you chagne any condition or column or letter case the optimizer will do the first step (data will be retrived from disk to memory )

  • SQL Server 2012 Physical vs. Hyper-V Same Query Different Results

    I have a database that is on physical hardware (16 CPU's, 32GB Ram).
    I have a copy of the database that was attached to a virtual Hyper-V server (16 CPU's, 32GB Ram).
    Both Servers and SQL Servers are identical OS=2008R2 Standard, SQL Server 2012R2 Standard same patch level SP1 CU8.
    Same query run on both servers return same data set, but the time is much different 26 Sec on Physical, 5 minutes on virtual.
    Statistics are identical on both databases, query execution plane is identical on both queries.
    Indices are identical on both databases.
    When I use set statistics IO, I get different results between the two servers.
    One table in particular (366k rows) on physical shows logical reads of 15400, on Hyper-V reports logical reads of 418,000,000 that is four hundred eighteen million for the same table.
    When the query is run on the physical it uses no CPU, when run on the Hyper-V it takes 100% of all 16 processors.
    I have experimented with Maxdop and it does exactly what it should by limiting processors but it doesn't fix the issue.

    A massive difference in logical reads usually hints at differences in the query plan.
    When you compare query plans, it is essential that you look at actual query plans.
    Please note that if your server / Hyper-V supports parallelism (which is almost always nowadays), then you are likely to have two query plans: a parallel and a serial query plan. Of course the actual query plan will make clear which one is used in which
    case.
    To say this again, this is by far the most likely reason for your problem.
    There are other (unlikely) reasons that could be the case here:
    runaway parallel threads or other bugs in the optimizer or engine. Make sure you have installed the latest service pack
    Maybe the slow server (Hyper-V) has extreme fragmentation in the relevant tables
    As mentioned by Erland, you have much much more information about the query and query plan than we do. You already know whether or not parallelism is used, how many threads are being used in it, if you have no, one or several Loop Joins in the query (my
    bet is on at least one, possibly more), etc. etc.
    With the limited information you can share (or choose to share), involving PSS is probably your best course of action.
    Gert-Jan

  • Different results for same query on different servers

    1. database being converted from 7.3.4 to 9.2
    2. query is executed on both servers
    3. different results!
    The tables and data are the same, and indexes are setup on new server. EXPLAIN PLAN was run on both but with (predictably) widely different results.
    I know, not much detail here, but has anyone ever ran into anything like this?
    Thanks,
    Pat

    Folks,
    Here is the relevant information for this problem. The attributes have been changed for confidentiality. If you need any other information let me know.
    Thanks,
    Pat
    Query:
    SELECT
    one,two,three,four,a.five,six,seven,
    a.eight,a.nine,
    to_char(ten,'99999.99'),to_char(eleven,'99999.99'),
    to_char(twelve,'99999.99'),to_char(thirteen,'99999.99'),
    fourteen,fifteen,sixteen,seventeen,eighteen,
    nineteen,twenty,twentyone
    FROM
    table1 a,
    table2 b
    WHERE
    a.five = b.five
    AND one = 'X'
    AND six = ' '
    AND three != 12345
    AND three IN
    (SELECT DISTINCT
    three
    FROM table3
    WHERE
    one = 'X'
    AND twentytwo = 'XYZ'
    AND twentythree != 0
    AND twentyfour != 0
    AND twentyfive = 'Y'
    AND (a.five IN
    (SELECT DISTINCT
    five
    FROM table1
    WHERE
    one = 'X'
    AND three IN (12345)
    Table1:
    one          varchar2(1)     not null     PK
    two          varchar2(20)     not null     PK
    three          number(5)     not null     PK
    four          number(2)     not null     PK
    five          number(6)     not null     PK
    six          varchar2(4)     not null     PK
    seven          number(4)     not null
    eight          varchar2(8)     not null
    nine          date          not null
    ten          number(7,2)
    eleven     number(7,2)
    twelve     number(7,2)
    thirteen     number(7,2)
    Table2:
    five          number(6)     not null     PK
    fourteen     varchar2(5)     not null
    fifteen     varchar2(5)     not null
    sixteen     varchar2(2)     not null
    seventeen     varchar2(35)     not null
    eighteen     varchar2(4)     not null
    nineteen     varchar2(2)
    twenty     varchar2(1)
    twentyone     number(6)
    Table3:
    one          varchar2(1)     not null     PK
    twentytwo     varchar2(12)     not null     PK
    two          varchar2(20)     not null     PK
    three          number(5)     not null     PK
    four          number(2)     not null     PK
    twentysix     number(2)     not null     PK
    twentyfive     varchar2(1)     not null
    nine          date          not null
    twentythree     number(13,8)     not null
    twentyfour     number(12,8)     not null
    twentyseven     varchar2(1)     not null
    eight          varchar2(8)     not null
    Explain - Oracle9i (default, with CBO):
    SELECT STATEMENT
    RECURSIVE EXECUTION SYS_LE_3_0
    RECURSIVE EXECUTION SYS_LE_3_1
    TEMP TABLE TRANSFORMATION
    HASH JOIN
    HASH JOIN
    HASH JOIN
    TABLE ACCESS FULL SYS_TEMP_0FD9D6603_AB874A
    TABLE ACCESS BY INDEX ROWID TABLE1
    BITMAP CONVERSION TO ROWIDS
    BITMAP AND
    BITMAP MERGE
    BITMAP KEY ITERATION
    TABLE ACCESS FULL SYS_TEMP_0FD9D6603_AB874A
    BITMAP CONVERSION FROM ROWIDS
    INDEX RANGE SCAN TABLE1INDEX03
    BITMAP MERGE
    BITMAP KEY ITERATION
    TABLE ACCESS FULL SYS_TEMP_0FD9D6602_AB874A
    BITMAP CONVERSION FROM ROWIDS
    INDEX RANGE SCAN TABLE1INDEX04
    TABLE ACCESS FULL SYS_TEMP_0FD9D6602_AB874A
    TABLE ACCESS FULL TABLE2
    Query results - Oracle9i (with CBO):
    X|A | 1| 0| 22| | 1|08-MAR-02|XYZ | | 24.00| | |ABCDE|FGHIJ|AB|ABCDEFG |ABC | | | |
    X|B | 2| 1| 22| | 7|04-DEC-01|XYZ | | 3.25| 8.00| |ABCDE|FGHIJ|AB|ABCDEFG |ABC | | | |
    X|C | 3| 1| 22| | 1|14-AUG-02|XYZ | | 10.35| | |ABCDE|FGHIJ|AB|ABCDEFG |ABC | | | |
    X|D | 4| 1| 22| | 6|11-JUL-02|XYZ | | .00| 13.90| |ABCDE|FGHIJ|AB|ABCDEFG |ABC | | | |
    X|E | 5| 5| 23| | 1|22-FEB-01|XYZ | | 211.80| | |ABCDE|EFGHI|AB|HIJKLMN |DEF | | | |
    X|E | 5| 5| 23| | 1|22-FEB-01|XYZ | | 211.80| | |ABCDE|EFGHI|AB|HIJKLMN |DEF | | | |
    X|E | 5| 5| 23| | 1|22-FEB-01|XYZ | | 211.80| | |ABCDE|EFGHI|AB|HIJKLMN |DEF | | | |
    X|E | 5| 5| 23| | 1|22-FEB-01|XYZ | | 211.80| | |ABCDE|EFGHI|AB|HIJKLMN |DEF | | | |
    X|E | 5| 5| 23| | 1|22-FEB-01|XYZ | | 211.80| | |ABCDE|EFGHI|AB|HIJKLMN |DEF | | | |
    (approximately 4550 rows returned)
    Explain - Oracle9i (ALTER SESSION SET OPTIMIZER_METHOD=RULE;):
    SELECT STATEMENT
    MERGE JOIN
    SORT JOIN
    NESTED LOOPS
    NESTED LOOPS
    VIEW VW_NSO_1
    SORT UNIQUE
    TABLE ACCESS BY INDEX ROWID TABLE3
    INDEX RANGE SCAN TABLE3INDEXPK
    TABLE ACCESS BY INDEX ROWID TABLE1
    INDEX RANGE SCAN TABLE1INDEX03
    TABLE ACCESS BY INDEX ROWID TABLE2
    INDEX UNIQUE SCAN TABLE2INDEXPK
    SORT JOIN
    VIEW VW_NSO_2
    SORT UNIQUE
    TABLE ACCESS BY INDEX ROWID TABLE1
    INDEX RANGE SCAN TABLE1INDEX03
    Explain - Oracle 7.3.4:
    SELECT STATEMENT
    MERGE JOIN
    SORT JOIN
    NESTED LOOPS
    NESTED LOOPS
    VIEW
    SORT UNIQUE
    TABLE ACCESS BY ROWID TABLE3
    INDEX RANGE SCAN TABLE3INDEX03
    TABLE ACCESS BY ROWID TABLE1
    INDEX RANGE SCAN TABLE1INDEX03
    TABLE ACCESS BY ROWID TABLE2
    INDEX UNIQUE SCAN TABLE2INDEXPK
    SORT JOIN
    VIEW
    SORT UNIQUE
    TABLE ACCESS BY ROWID TABLE1
    INDEX RANGE SCAN TABLE1INDEX03
    Query results - Oracle 7.3.4:
    X|A | 1| 0| 22| | 1|08-MAR-02|XYZ | | 24.00| | |ABCDE|FGHIJ|AB|ABCDEFG |ABC | | | |
    X|B | 2| 1| 22| | 7|04-DEC-01|XYZ | | 3.25| 8.00| |ABCDE|FGHIJ|AB|ABCDEFG |ABC | | | |
    X|C | 3| 1| 22| | 1|14-AUG-02|XYZ | | 10.35| | |ABCDE|FGHIJ|AB|ABCDEFG |ABC | | | |
    X|D | 4| 1| 22| | 6|11-JUL-02|XYZ | | .00| 13.90| |ABCDE|FGHIJ|AB|ABCDEFG |ABC | | | |
    X|E | 5| 5| 23| | 1|22-FEB-01|XYZ | | 211.80| | |ABCDE|EFGHI|AB|HIJKLMN |DEF | | | |
    (approximately 1150 rows returned)
    Indexes (used):
    TABLE1INDEX03     (three)
    TABLE1INDEX04     (five)
    TABLE2INDEXPK     (five)
    TABLE3INDEXPK     (one,twentytwo,two,three,four,twentysix)
    Discussion:
    Notice the repeating result for X,E,5,5,23,.... in the Oracle9i retrieval using CBO.
    The execution of this query returned approximately four times the number of rows as
    Oracle 7.3.4 using RBO. This is a function of how many "fours" there are in table3
    that have matching "threes and fours" in table1. If you put a DISTINCT clause at the
    very front of the query (SELECT DISTINCT one,two,three ....) then the result is
    accurate and the same as Oracle 7.3.4. In one execution of this query, 27,000 rows
    are expected to be returned, but the server returned over 1 million rows!
    When RBO was used on Oracle9i, the results were identical to the ones on Oracle 7.3.4.

  • Strange query plans, and so different results from a view.

    In my database (11g), I have a currency exchange rate table, which contains all currencies and their exchange rate to USD. I need to have a number of different exchange rates - To GBP, EUR, etc...
    To accomplish this I have created a view, which has one union statement of all the USD exchange rates, with the same data joined back on itself to give the exchange rates based on their exchange rate to USD - ie: SELECT b1.Date, b1.Currency AS FromCurrency, b2.Currency as ToCurrency, b1.Rate/b2.Rate as Exchange Rate FROM Rates b1, Rates b2 on b1.Date = b2.Date
    This view works fine when I query it, and returns the data as I expect.
    I have a second view that is joined to this view to give a return of the amount in each currency for reporting. This view seems to work correctly when I narrow down the search requirements and have a small set of data.
    The issue I am having is when I query the second view and get it to return all the data. Instead of receiving 4 rows per transaction (I am only interested in 4 exchange rates for display) I typically receive up to 2 rows. The first record is for the conversion to USD, the second record is for the conversion to the supplied currency. The issue is that this exchange rate actually includes the aggregate for all 3 other requested currencies (not the USD).
    So instead of getting something like:
    Amt RC BC (Amt = Amount, RC = Reporting Currency. BC = Base Currency)
    60 GBP GBP
    80 EUR GBP
    100 USD GBP
    1000 ZAR GBP
    60 GBP USD
    80 EUR USD
    100 USD USD
    1000 ZAR USD
    I get the following set of results:
    1140 GBP GBP
    100 USD GBP
    100 USD USD
    Has anyone come accross something similar or have any ideas on how I can resolve this?
    Thanks
    PS: I can get both sets of results from the same view depending on the filter criteria. Also if I convert the exchange rates into a table, it then returns the correct results as expected.

    943081 wrote:
    The idea is to seek help in solving the problem. I was hoping that perhaps someone had experienced the same thing - different results for "effectively" the same query:Well, that's the issue... without additional info, it's not clear what issue you were seeing.
    SELECT * FROM view WHERE Date = '01 January, 2012'
    verse
    SELECT * FROM view WHERE Date > '31 December, 2011' ORDER BY DateNow it's a bit clearer. That second query is not "effectively" the same as the first query. If the date column is in DATE format, then you ought to have a to_date() around the date string to explicitly convert it into a date so you can do date-to-date comparisons correctly. Also, DATE datatype stores times as well as dates, so asking for data matching midnight of a specific date is different than asking for data greater than midnight of the previous day.
    If the date string is a string, then ... well, the string "31 December 2011" is greater than the string "31 August 2013", despite it being an earlier date. This is why making sure you're using the right datatype for the job is important - a date is different to a string that just happens to contain a date.
    DateID
    I have no objection to using a Date but always struggle to understand what someone means when they tell me "06/07/2012" - granted if the day is above 12 or the same day and month I don't have a problem - but it still leaves 121 days a year that are confusing. sure, but just because you find outputting the display (or rather, someone else's output) confusing doesn't mean you still shouldn't use the correct datatype. Store things as a date, and you can then output it in whatever format you like. Try doing that with a string or a number.
    Don't say it doesn't happen as I got a birthday card from a company in May this year when I have specifically entered my date of birth as being the 5 of a month (name drop down box on their website)!Just because someone else doesn't understand how to work with dates correctly doesn't mean you can't! It's not exactly rocket science, after all!*{;-)                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       

  • Variance Scaling in Query and Web Template Showing Different Results

    Hi experts,
    I have the following problem - variance scaling in my query and web template are showing different results.
    My variance in column is set as follows:
    Formula: NODIM(A % B)
    Scaling Factor: 1
    I have a structure in row that uses Scaling Factor of 1,000.
    Let say the value of Column A is 120 and Column B is 100.
    When I execute the query, it will show 0.02
    However, when I execute the web template it will show the correct scaling i.e. 20.
    May I know what can I do to correct above scaling error?
    Thank you!

    You can not remove the scalling factor, but once you check the checkbox below the dropdown menu, the scalling factor will go away.
    I checked at my end and when I set the scalling fact as 1, I was getting 9.9% while I was expecting 9900%. When I removed the scalling factor I started getting 9900%.
    I would let you know if I came across anything else.
    What about the unit of Column A and B. Are they same or different?
    - Danny
    Edited by: Danny Matt on Jun 22, 2009 1:54 PM

  • Filter expression producing different results after upgrade to 11.1.1.7

    Hello,
    We recently did an upgrade and noticed that on a number of reports where we're using the FILTER expression that the numbers are very inflated. Where we are not using the FILTER expression the numbers are as expected. In the example below we ran the 'Bookings' report in 10g and came up with one number and ran the same report in 11g (11.1.1.7.0) after the upgrade and got two different results. The data source is the same database for each envrionment. Also, in running the physical SQL generated by the 10g and 11g version of the report we get different the inflated numbers from the 11g SQL. Any ideas on what might be happening or causing the issue?
    10g report: 2016-Q3......Bookings..........72,017
    11g report: 2016-Q3......Bookings..........239,659
    This is the simple FILTER expression that is being used in the column formula on the report itself for this particular scenario which produces different results in 10g and 11g.
    FILTER("Fact - Opportunities"."Won Opportunity Amount" USING ("Opportunity Attributes"."Business Type" = 'New Business'))
    -------------- Physical SQL created by 10g report -------- results as expected --------------------------------------------
    WITH
    SAWITH0 AS (select sum(case when T33142.OPPORTUNITY_STATUS = 'Won-closed' then T33231.USD_LINE_AMOUNT else 0 end ) as c1,
    T28761.QUARTER_YEAR_NAME as c2,
    T28761.QUARTER_RANK as c3
    from
    XXFI.XXFI_GL_FISCAL_MONTHS_V T28761 /* Dim_Periods */ ,
    XXFI.XXFI_OSM_OPPTY_HEADER_ACCUM T33142 /* Fact_Opportunity_Headers(CloseDate) */ ,
    XXFI.XXFI_OSM_OPPTY_LINE_ACCUM T33231 /* Fact_Opportunity_Lines(CloseDate) */
    where ( T28761.PERIOD_NAME = T33142.CLOSE_PERIOD_NAME and T28761.QUARTER_YEAR_NAME = '2012-Q3' and T33142.LEAD_ID = T33231.LEAD_ID and T33231.LINES_BUSINESS_TYPE = 'New Business' and T33142.OPPORTUNITY_STATUS <> 'Duplicate' )
    group by T28761.QUARTER_YEAR_NAME, T28761.QUARTER_RANK)
    select distinct SAWITH0.c2 as c1,
    'Bookings10g' as c2,
    SAWITH0.c1 as c3,
    SAWITH0.c3 as c5,
    SAWITH0.c1 as c7
    from
    SAWITH0
    order by c1, c5
    -------------- Physical SQL created by the same report as above but in 11g (11.1.1.7.0) -------- results much higher --------------------------------------------
    WITH
    SAWITH0 AS (select sum(case when T33142.OPPORTUNITY_STATUS = 'Won-closed' then T33142.TOTAL_OPPORTUNITY_AMOUNT_USD else 0 end ) as c1,
    T28761.QUARTER_YEAR_NAME as c2,
    T28761.QUARTER_RANK as c3
    from
    XXFI.XXFI_GL_FISCAL_MONTHS_V T28761 /* Dim_Periods */ ,
    XXFI.XXFI_OSM_OPPTY_HEADER_ACCUM T33142 /* Fact_Opportunity_Headers(CloseDate) */ ,
    XXFI.XXFI_OSM_OPPTY_LINE_ACCUM T33231 /* Fact_Opportunity_Lines(CloseDate) */
    where ( T28761.PERIOD_NAME = T33142.CLOSE_PERIOD_NAME and T28761.QUARTER_YEAR_NAME = '2012-Q3' and T33142.LEAD_ID = T33231.LEAD_ID and T33231.LINES_BUSINESS_TYPE = 'New Business' and T33142.OPPORTUNITY_STATUS <> 'Duplicate' )
    group by T28761.QUARTER_YEAR_NAME, T28761.QUARTER_RANK),
    SAWITH1 AS (select distinct 0 as c1,
    D1.c2 as c2,
    'Bookings2' as c3,
    D1.c3 as c4,
    D1.c1 as c5
    from
    SAWITH0 D1),
    SAWITH2 AS (select D1.c1 as c1,
    D1.c2 as c2,
    D1.c3 as c3,
    D1.c4 as c4,
    D1.c5 as c5,
    sum(D1.c5) as c6
    from
    SAWITH1 D1
    group by D1.c1, D1.c2, D1.c3, D1.c4, D1.c5)
    select D1.c1 as c1, D1.c2 as c2, D1.c3 as c3, D1.c4 as c4, D1.c5 as c5, D1.c6 as c6 from ( select D1.c1 as c1,
    D1.c2 as c2,
    D1.c3 as c3,
    D1.c4 as c4,
    D1.c5 as c5,
    sum(D1.c6) over () as c6
    from
    SAWITH2 D1
    order by c1, c4, c3 ) D1 where rownum <= 2000001
    Thank you,
    Mike
    Edited by: Mike Jelen on Jun 7, 2013 2:05 PM

    Thank you for the info. They are definitely different values since ones on the header and the other is on the lines. As the "Won Opportunity" logical column is mapped to multiple LTS it appears the OBI 11 uses a different alogorthim to determine the most efficient table to use in the query generation vs 10g. I'll need to spend some time researching the impact to adding a 'sort' to the LTS. I'm hoping that there's a way to get OBI to use similar logic relative to 10g in how it generated the table priority.
    Thx again,
    Mike

  • SQL Query with wrong result

    Hello.
    I have a query with LEFT OUTER JOIN that I think returns invalid results. Here are the problem details:
    CREATE TABLE DOGERR(
    IdDog INTEGER,
    SfPdg CHAR(1),
    IdVpl INTEGER,
    SfVpGot INTEGER,
    SfZrr CHAR(1)
    INSERT INTO DOGERR(IdDog, SfPdg, IdVpl, SfVpGot, SfZrr) VALUES (1, 'S', 1, 1, '7');
    INSERT INTO DOGERR(IdDog, SfPdg, IdVpl, SfVpGot, SfZrr) VALUES (2, 'S', 1, 1, '7');
    INSERT INTO DOGERR(IdDog, SfPdg, IdVpl, SfVpGot, SfZrr) VALUES (3, '$', 1, 2, 'C');
    COMMIT;
    CREATE UNIQUE INDEX DOGERR_PK ON DOGERR(IdDog);
    And now the query:
    SELECT D.IdDog, D.SfPdg, D.IdVpl, D.SfVpGot, D.SfZrr, T.IdVpl AS IdVplJoin, T.SfVpGot AS SfVpGotJoin, T.SfZrr AS SfZrrJoin
    FROM DOGERR D
    LEFT OUTER JOIN (SELECT * FROM DOGERR WHERE SfPdg = 'S' OR SfPdg = 'S') T ON
    T.IdVpl = D.IdVpl AND T.SfVpGot = D.SfVpGot AND T.SfZrr = D.SfZrr
    WHERE
    D.IdDog = 3
    AND D.SfVpGot = 2
    AND D.SfZrr = 'C';
    This query should (by my understanding) return only one row in wich the joined subquery columns should be NULL. And indeed query returns only one row on Oracle Database 10g Release 10.2.0.1.0 - Production and on Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production:
    IDDOG = 3, SFPDG = "$", IDVPL = 1, SFVPGOT = 2, SFZRR = "C", IDVPLJOIN = NULL, SFVPGOTJOIN = NULL, SFZRRJOIN = NULL
    But on Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - 64bit Production it returns TWO rows:
    IDDOG = 3, SFPDG = "$", IDVPL = 1, SFVPGOT = 2, SFZRR = "C", IDVPLJOIN = 1, SFVPGOTJOIN = 1, SFZRRJOIN = "7"
    IDDOG = 3, SFPDG = "$", IDVPL = 1, SFVPGOT = 2, SFZRR = "C", IDVPLJOIN = 1, SFVPGOTJOIN = 1, SFZRRJOIN = "7"
    And now the interesting part: any of the following modified versions of query works even on Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - 64bit Production, although modifications should not modify the result set:
    -- Removed unnecessary WHERE conditions
    SELECT D.IdDog, D.SfPdg, D.IdVpl, D.SfVpGot, D.SfZrr, T.IdVpl AS IdVplJoin, T.SfVpGot AS SfVpGotJoin, T.SfZrr AS SfZrrJoin
    FROM DOGERR D
    LEFT OUTER JOIN (SELECT * FROM DOGERR WHERE SfPdg = 'S' OR SfPdg = 'S') T ON
    T.IdVpl = D.IdVpl AND T.SfVpGot = D.SfVpGot AND T.SfZrr = D.SfZrr
    WHERE
    D.IdDog = 3;
    -- Removed unnecessary OR condition in subquery
    SELECT D.IdDog, D.SfPdg, D.IdVpl, D.SfVpGot, D.SfZrr, T.IdVpl AS IdVplJoin, T.SfVpGot AS SfVpGotJoin, T.SfZrr AS SfZrrJoin
    FROM DOGERR D
    LEFT OUTER JOIN (SELECT * FROM DOGERR WHERE SfPdg = 'S') T ON
    T.IdVpl = D.IdVpl AND T.SfVpGot = D.SfVpGot AND T.SfZrr = D.SfZrr
    WHERE
    D.IdDog = 3
    AND D.SfVpGot = 2
    AND D.SfZrr = 'C';
    -- Removed columns from joined subquery from SELECT part
    SELECT D.IdDog, D.SfPdg, D.IdVpl, D.SfVpGot, D.SfZrr, T.IdVpl AS IdVplJoin, T.SfVpGot AS SfVpGotJoin
    FROM DOGERR D
    LEFT OUTER JOIN (SELECT * FROM DOGERR WHERE SfPdg = 'S' OR SfPdg = 'S') T ON
    T.IdVpl = D.IdVpl AND T.SfVpGot = D.SfVpGot AND T.SfZrr = D.SfZrr
    WHERE
    D.IdDog = 3
    AND D.SfVpGot = 2
    AND D.SfZrr = 'C';
    NOTE: the query itself is a little stupid but this is just to demonstrate the problem. We have faced this problem at a customer with our real-world query.
    So, my question is: why different results ?
    Thanks.
    David

    hi,
    welcome to the forum,
    don't have a solution, but I thought I'd let you know that the first SQL statement only returns 1 row on 10gR2
    SQL> SELECT D.IdDog, D.SfPdg, D.IdVpl, D.SfVpGot, D.SfZrr, T.IdVpl AS IdVplJoin, T.SfVpGot AS SfVpGo
    tJoin, T.SfZrr AS SfZrrJoin
      2  FROM DOGERR D
      3  LEFT OUTER JOIN (SELECT * FROM DOGERR WHERE SfPdg = 'S' OR SfPdg = 'S') T ON
      4  T.IdVpl = D.IdVpl AND T.SfVpGot = D.SfVpGot AND T.SfZrr = D.SfZrr
      5  WHERE
      6  D.IdDog = 3
      7  AND D.SfVpGot = 2
      8  AND D.SfZrr = 'C';
         IDDOG S      IDVPL    SFVPGOT S  IDVPLJOIN SFVPGOTJOIN S
             3 $          1          2 C
    SQL> select * from v$version;
    BANNER
    Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
    PL/SQL Release 10.2.0.4.0 - Production
    CORE    10.2.0.4.0      Production
    TNS for Solaris: Version 10.2.0.4.0 - Production
    NLSRTL Version 10.2.0.4.0 - Production

Maybe you are looking for

  • Function Module to convert date to week from Sunday to Saturday

    Hi, In BW the convertion date to week always give week from Monday(1) to Sunday(7) I'm looking for a function module to convert date to week from Sunday(1) to Saturday(7) Thanks Sebastien

  • Unwanted Double Keystrokes in Calendar (Yosemite)

    Hi everyone. I've searched all over, and can't seem to find this problem mentioned in another thread. I am using Calendar on Yosemite and frequently experience a weird glitch. While editing an entry, keystrokes will begin to double. For example if I

  • Major issues with buttons

    I'm having a bit of an issue right now.  In the image below, the blue buttons are supposed to be circles (you can see them in the middle of the line).  They ended up coming in with extra color on the sides that was not there in the original psd file.

  • Export to Compressor or Export to Quicktime then into Compressor

    Hi, Already for a long I am wondering whether it would make a significant difference when you export video directly to compressor from FCP or indirectly via Quicktime to Compressor. If you have any experience regarding this, please let me no know. Th

  • GZipStream Decompression only returns small portion of original file

    I've been trying to use GZipStream to decompress a file originally created with gzip (default settings).  The gzipped file inflates to one file of 5,120,001 KB (~5GB) using gzip -d.  There are no errors and the inflated file matches the original byte