Order of Predicates and Joins in a where Clause

I always specify the join conditions and then predicates in where clause . But when i placed the predicates first and then joins the response was quicker . I compared the execution plan and each has a different approach .
Is it true in all cases or it doesn't matter ? Which one is better ? In the following examples I usually follow the first approach but when i tried the second one it was faster .
Query 1
select t1.something from
table1 t1 , table2 t2
where t1.id=t2.id
and t1.year = 2009
Query 2
select t1.something from
table1 t1 , table2 t2
where t1.year = 2009and
and t1.id=t2.id
Edited by: user561066 on Sep 24, 2010 11:57 AM

Welcome to the forum.
As SomeoneElse already asked: mentioning your database version is crucial when it comes to these types of questions.
So just be default always post the result of:
SQL> select * from v$version;when asking a question.
Find more information here, it explains clearly what information is needed from you to post:
How to post a SQL statement tuning request HOW TO: Post a SQL statement tuning request - template posting
Execution plans, database version, optimizer settings....

Similar Messages

  • Complex Inner Join and subquery on outer where clause on inner join?

    The DDL for this post was too big and I had to put on my website:
    My goal is to create a report of sales data for 116 stores containing daily sales and guest count to last years. My challenge is I'm pulling data from the same table but with different dates to get data from last year and Week to date data from last year.
    Dates used for reports are:
    SalesDate = 6/4/2009
    SalesDateForLastYear = 6/5/2008
    SalesDateBeginningOfWeek = 6/1/2009
    SalesDateBginningOFWeekLastYear = 6/2/2008
    ---======= DOLLAR VARIANCE = You Said you have $100 worth of meat(inventory) but you only have $50 worth of meat
        BUSI_DATE as BusinessDate,
        ORACLE_KEY as StoreID,
        FIELD1  as Sales,
        FIELD2  as GuestCount,
        FIELD3  as DollarVariance,
        FIELD4  as Cars
    WHERE Busi_date = SalesDate
       AND ORACLE_KEY IN (SELECT StoreID From MyStores);
    -======= ONLY Guest count and Sales are needed in comparisons against last year   
    ---======    Last YEar dates = corresponding dates for this year ie Tuesday of this
    week matched to Tuesday of last year (except for leap year)
        ORACLE_KEY as StoreID
        FIELD1  as SalesLastYear
        FIELD2  as GuestCountLastYear  
    WHERE Busi_date = SalesDateForLastYear
       AND ORACLE_KEY IN (SELECT StoreID From MyStores);
        ORACLE_KEY as StoreID
        SUM(FIELD1)  as WeekToDateSales
        SUM(FIELD2)  as WeekToDateGuestCount 
    WHERE Busi_date BETWEEN SalesDateBeginningOfWeek and SalesDate
       AND ORACLE_KEY IN (SELECT StoreID From MyStores)
        ORACLE_KEY as StoreID
        SUM(FIELD1)  as WeekToDateSalesLastYear
        SUM(FIELD2)  as WeekToDateGuestCountLastYear 
    WHERE Busi_date BETWEEN SalesDateBeginningOfWeekLastYear and SalesDateLastYear
       AND ORACLE_KEY IN (SELECT StoreID From MyStores)
    GROUP BY ORACLE_KEY   Question: Since they all use the same store nbrs, do I need to specify on each query? CAn't i jsut specify once on outer query Where clause?
    Also How would I integrate the following script from HOEK:
    See How do I set 1 field based on another field's value
    It gets a record for each store of the 116 stores from inventory database. There were 2 situations that were addressed by Hoeks code:
    For each of the 116 stores in store table, there must be 1 and only
    1 inventory record to match the MyStoreTotals record. However, sometimes there will be no inventory record.
    and sometimes there will be 2 (in a case where a manager updates database
    after daily processing) records. if so, the record with Is_posted = 1
    is the one that should be included in query. The following accomplishes this:
    -- chr(39) is single quote
    Select StoreId,
      from   (select store.storeid,
                              when inv.storeid is null then 'None'
                              when inv.is_posted = 0 then 'NP'
                              else chr(39)||inv.total_dol_var||chr(39)
                        end as DollarVariance,
                        row_number() over (partition by store.storeid order by inv.is_posted desc) rn 
                   from  myInven inv
                   right outer join mystores  store
                                  on store.storeid = inv.fk_str_main_id
                                  and inv.busi_date = to_date(SalesDate, 'dd-mon-yyyy'))
          where rn = 1;      Do I put this query on the where clause of the outer query of do I put it on a JOIN clause?

    Here is Part 2: The Insert for totals table
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',21,3163.79,189.83,0,-190.7);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',22,2747.25,255.37,0,-235.95);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',23,4182.74,388.74,0,-248.47);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',24,4551.5,423.05,0,-467.46);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',25,2785.13,258.8,0,-199.85);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',27,3409.31,317,0,-175.18);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',28,3808.61,228.6,0,-233.04);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',29,3416.97,239.35,0,-110.77);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',30,2133.4,128.13,0,-178.37);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',31,2261.27,210.14,0,-272.39);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',32,2258.18,135.6,0,-83.01);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',33,3908.26,312.71,0,-121.41);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',34,3035.45,273.38,0,-97.8);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',35,3088.44,185.5,0,-123.56);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',36,4255.4,395.48,0,-206.16);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',37,6331.13,380.01,0,-505.47);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',38,3552.78,319.94,0,-168.33);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',39,2991.44,277.96,0,-228.98);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',41,3825.03,355.49,0,-204.93);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',42,3843.16,357.16,0,-237.5);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',43,2981.78,179,0,-45.97);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',61,4504.6,270.32,0,-362.49);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',62,4034.46,242.1,0,-260.95);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',64,1811.58,168.39,0,-108.78);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',65,2271.46,211.04,0,-117.32);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',66,2336.32,217.02,0,-95.28);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',67,4208.13,410.39,0,-197.3);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',68,2803.55,273.31,0,-154.11);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',69,1702.81,153.46,0,-98.58);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',70,4098.3,399.51,0,-208.42);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',71,1952.1,190.26,0,-59.51);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',72,4716.07,283.07,0,-428.18);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',73,2897.56,269.43,0,-329.79);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',75,3438.59,319.84,0,-344.96);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',76,3016.7,280.67,0,-106.39);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',78,4228.31,253.73,0,-249.33);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',81,4152.43,249.33,0,-135.87);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',82,3772.42,350.69,0,-174.02);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',83,2594.06,241.02,0,-196.18);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',101,3868.21,232.21,0,-360.36);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',141,2246.55,134.92,0,-100.97);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',181,2357.75,219.07,0,-205.8);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',202,2724.47,163.47,0,-107.54);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',203,3225.11,193.67,0,-143.19);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',204,2641.28,158.55,0,-131.84);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',205,4644.56,278.72,0,-260.48);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',206,3859.62,231.76,0,-203.47);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',221,3647.04,355.53,0,-186.82);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',222,2446.59,227.42,0,-172.67);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',223,3439.52,319.61,0,-264.23);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',224,3121.7,290.07,0,-284.98);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',241,2858.38,228.81,0,-279.91);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',243,4983.38,299.22,0,-370.89);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',244,2970.69,178.37,0,-189.97);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',245,5829.93,349.97,0,-215.5);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',246,4344.78,260.79,0,-120.38);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',247,4154.77,249.52,0,-175.08);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',248,4875.21,292.58,0,-296.04);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',249,4041.39,242.6,0,-99.91);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',250,2933.45,176.04,0,-208.56);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',251,5448.82,327.13,0,-358.71);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',252,2429.18,224.88,0,-136.03);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',253,2884.63,173.14,0,-83.95);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',254,3708.4,222.64,0,-318.75);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',255,3722.19,346.22,0,-204.4);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',256,3834.23,230.16,0,-245.91);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',257,3456.4,321.22,0,-259.7);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',258,3018.22,181.16,0,-146.83);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',259,2807.65,260.97,0,-241.13);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',260,3424.99,318.21,0,-229.06);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',262,3782.55,351.66,0,-174.42);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',263,2570.84,239.08,0,-184.58);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',264,3904.8,234.22,0,-235.03);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',265,2853.7,286.29,0,-253.16);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',266,3246.72,194.76,0,-237.36);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',267,3712.25,417.97,0,-257.5);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',268,4141.22,248.53,0,-68.98);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',269,3693.64,221.77,0,-228.45);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',271,3775.03,226.8,0,-213.14);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',272,2870.1,172.27,0,-514.23);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',273,3132.8,188.22,0,-148.05);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',274,2454.86,147.31,0,-142.1);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',276,3627.72,337.17,0,-232.38);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',277,3118.79,187.21,0,-152.68);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',278,3360.09,302.7,0,-220.63);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',279,2478.11,230.44,0,-192.49);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',280,3252.54,302.38,0,-213.72);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',281,3654.62,219.44,0,-164.95);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',282,3159.75,189.72,0,-168.68);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',285,2839.63,241.67,0,-238.7);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',286,3468.01,322.29,0,-186.25);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',287,3546.42,329.74,0,-160.14);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',289,2331.57,174.44,0,-293.47);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',290,1702.25,131.62,0,-101.72);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',291,3969.8,369.02,0,-253.26);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',292,2265.99,210.52,0,-182.05);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',293,3234.72,258.74,0,-137.08);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',294,3932.19,354.24,0,-201.15);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',295,3754.2,225.46,0,-307.99);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',296,3885.37,235.24,0,-293.24);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',298,2479.43,148.86,0,-207.68);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',321,3542.26,212.71,0,-206.25);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',362,1540.87,142.53,0,-101.3);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',363,2798.87,314.66,0,-356.52);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',364,2658.94,212.7,0,-159.29);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',381,3155.66,189.48,0,-229.18);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',441,1389.79,98.92,0,-77.94);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',461,1874.39,149.82,0,-298.2);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',462,2539.64,161.32,0,-206.73);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',501,3861.36,357.29,0,-286.17);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',521,3449.41,318.93,0,-182.83);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',522,2938.99,176.51,0,-149.65);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',523,4352.54,261.29,0,-333.7);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',524,4163.36,385.54,0,-352.01);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',544,2481.37,260.53,0,-29.9);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',564,2344.38,211.07,0,-153.02);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-08',624,3136.78,188.29,0,-199.51);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',21,3250.89,195.13,0,-161.39);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',22,2595.78,241.23,0,-159.05);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',23,4533.49,421.43,0,-348.07);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',24,5337.24,496.17,0,-475.37);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',25,3328.26,309.42,0,-172.65);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',27,3680.53,342.16,0,-159.81);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',28,3850.95,231.21,0,-343.33);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',29,3470.75,243.07,0,-112.19);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',30,2799.58,168.14,0,-321.17);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',31,2241.6,208.23,0,-249.08);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',32,2744.05,164.74,0,-138.96);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',33,3987.38,319.11,0,-111.6);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',34,2996.06,269.94,0,-135.31);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',35,3502.73,210.32,0,-100.55);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',36,3553.27,330.15,0,-176.07);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',37,6387.03,383.52,0,-497.73);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',38,3295.64,296.86,0,-183.05);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',39,2891.77,268.67,0,-79.79);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',41,3806.24,354.67,0,-183.84);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',42,3572.47,332.13,0,-176.78);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',43,3231.48,193.91,0,-101.76);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',61,4812.72,289.03,0,-309.85);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',62,4245.8,254.83,0,-241.36);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',64,1925.79,179.05,0,-81.31);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',65,2350.08,218.44,0,-49.03);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',66,2440.74,226.71,0,-103.36);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',67,4154.7,405.04,0,-142.79);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',68,3177.54,309.78,0,-203.25);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',69,1602.51,144.48,0,-89.2);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',70,4332.09,422.2,0,-279.47);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',71,2266.95,220.94,0,-147.58);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',72,5270.73,316.57,0,-636.12);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',73,2982.05,277.08,0,-292.33);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',75,3708.11,344.64,0,-537.87);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',76,2984.98,277.59,0,-163.33);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',78,4308.12,258.69,0,-242.15);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',81,4122.56,247.58,0,-201.33);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',82,3816.69,354.86,0,-219.83);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',83,2587.89,240.53,0,-225.54);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',101,4369.67,262.3,0,-206.67);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',141,2603.25,156.3,0,-101.35);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',181,2147.47,199.55,0,-216.75);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',202,2622.75,157.5,0,-135.47);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',203,3574.63,214.73,0,-219.38);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',204,2906.92,174.56,0,-110.08);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',205,4895.05,293.87,0,-277.18);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',206,3520.21,211.2,0,-269.1);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',221,4079.8,397.83,0,-135.79);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',222,2420.63,225.04,0,-218.93);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',223,3071.77,285.46,0,-204.44);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',224,3162.39,293.88,0,-364.17);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',241,3207.99,256.68,0,-150.69);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',243,5195.78,311.98,0,-257.23);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',244,3297.07,198.05,0,-174.03);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',245,5968.82,358.41,0,-319.01);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',246,4200.59,252.23,0,-158.47);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',247,4070,244.44,0,-192.64);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',248,4968.23,298.1,0,-230.1);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',249,4693.38,281.83,0,-51.24);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',250,3101.72,186.19,0,-65.67);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',251,5772.54,346.49,0,-370.65);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',252,2616.47,242.24,0,-313.94);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',253,3471.22,208.33,0,-125.65);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',254,3878.21,232.87,0,-148.1);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',255,3863.12,359.29,0,-259.09);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',256,3710.4,222.76,0,-158.92);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',257,2998.68,278.72,0,-209.98);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',258,3589.82,215.49,0,-146.1);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',259,2767.48,257.21,0,-196.7);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',260,2973.28,276.2,0,-199.43);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',262,3859.64,358.89,0,-400.09);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',263,2812.9,261.43,0,-180.02);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',264,3916.29,234.97,0,-129.04);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',265,2756.12,276.52,0,-100.22);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',266,3164.38,190.06,0,-166.11);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',267,3510.19,395.32,0,-419.08);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',268,4404.09,264.47,0,-119.09);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',269,3719.31,223.16,0,-233.2);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',271,4072.41,244.37,0,-337.97);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',272,3547.26,212.98,0,-242.38);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',273,3055.74,183.41,0,-250.05);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',274,2494.52,149.72,0,-118.34);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',276,3547.39,329.69,0,-254.4);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',277,2904.89,174.45,0,-169.73);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',278,3437.7,309.83,0,-221.15);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',279,3142.29,292.08,0,-247.97);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',280,3470.57,322.59,0,-286.45);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',281,4075.15,244.63,0,-313.42);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',282,2873,172.52,0,-150.44);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',285,2951.56,251.12,0,-294.04);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',286,3803.64,353.56,0,-244.53);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',287,3402.96,316.4,0,-164.22);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',289,2514.92,188.12,0,-238.77);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',290,1797.42,138.89,0,-196.18);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',291,3904.15,362.83,0,-246.27);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',292,2414.91,224.34,0,-109.66);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',293,3336.49,266.85,0,-232.16);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',294,3761.44,338.74,0,-179.55);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',295,4363.6,262.12,0,-319.81);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',296,4274.18,258.43,0,-222.11);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',298,2823.18,169.51,0,-315.66);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',321,4000.01,240.05,0,-191.67);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',362,1944.95,179.72,0,-191.07);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',363,3171.3,356.66,0,-363.11);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',364,3057.67,244.75,0,-124.49);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',381,3140.8,188.58,0,-251.87);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',441,1507.47,107.24,0,-62.57);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',461,1609.21,128.6,0,-289.64);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',462,2660.68,168.81,0,-253.25);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',501,4140.65,383.21,0,-525.13);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',521,3801.87,352.02,0,-325.62);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',522,3456.49,207.58,0,-282.41);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',523,4413.29,264.6,0,-417.35);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',524,4502.73,416.91,0,-429.19);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',544,2800.89,294.13,0,-31.98);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',564,2632.22,237.14,0,-174.72);
    INSERT INTO MYDAILYTOTALS VALUES('03-JUN-08',624,3006.17,180.49,0,-186.61);
    INSERT INTO MYDAILYTOTALS VALUES('01-JUN-09',21,3313.37,198.82,501.41,148.71);
    INSERT INTO MYDAILYTOTALS VALUES('01-JUN-09',32,2233.4,134.06,529.18,81.52);
    INSERT INTO MYDAILYTOTALS VALUES('01-JUN-09',39,3151.53,292.94,445.76,200.74);
    INSERT INTO MYDAILYTOTALS VALUES('01-JUN-09',43,3260.15,195.77,708.43,138.56);
    INSERT INTO MYDAILYTOTALS VALUES('01-JUN-09',66,2968.89,275.97,541.77,329.89);
    INSERT INTO MYDAILYTOTALS VALUES('01-JUN-09',69,2227.11,200.54,378.5,62.78);
    INSERT INTO MYDAILYTOTALS VALUES('01-JUN-09',73,2596.94,241.55,353.28,62.28);
    INSERT INTO MYDAILYTOTALS VALUES('01-JUN-09',101,4263.98,255.93,555.08,339.94);
    INSERT INTO MYDAILYTOTALS VALUES('01-JUN-09',141,2326.62,139.65,514.13,18.35);
    INSERT INTO MYDAILYTOTALS VALUES('01-JUN-09',202,2663.65,159.94,650.3,98.32);
    INSERT INTO MYDAILYTOTALS VALUES('01-JUN-09',206,3862.53,231.85,700.72,135.09);
    INSERT INTO MYDAILYTOTALS VALUES('01-JUN-09',221,3458,337.07,537.24,111.94);
    INSERT INTO MYDAILYTOTALS VALUES('01-JUN-09',223,3244.05,301.4,504.12,78.03);
    INSERT INTO MYDAILYTOTALS VALUES('01-JUN-09',224,3271.02,304.12,488.82,142.74);
    INSERT INTO MYDAILYTOTALS VALUES('01-JUN-09',243,4582.04,275.73,757.99,173.21);
    INSERT INTO MYDAILYTOTALS VALUES('01-JUN-09',244,3075.06,184.7,559.75,254.56);
    INSERT INTO MYDAILYTOTALS VALUES('01-JUN-09',245,5770.79,346.51,745.04,232.29);
    INSERT INTO MYDAILYTOTALS VALUES('01-JUN-09',247,4445.29,266.95,707.99,148.44);
    INSERT INTO MYDAILYTOTALS VALUES('01-JUN-09',250,2993.46,179.71,716.03,77.52);
    INSERT INTO MYDAILYTOTALS VALUES('01-JUN-09',254,3439.15,206.53,455.68,103.27);
    INSERT INTO MYDAILYTOTALS VALUES('01-JUN-09',258,3199.55,192.22,656.15,380.93);
    INSERT INTO MYDAILYTOTALS VALUES('01-JUN-09',262,3863.19,359.27,530.18,57.15);
    INSERT INTO MYDAILYTOTALS VALUES('01-JUN-09',264,4014.15,241.09,715.7,210.46);
    INSERT INTO MYDAILYTOTALS VALUES('01-JUN-09',267,3508.58,394.9,622.73,109.92);
    INSERT INTO MYDAILYTOTALS VALUES('01-JUN-09',271,4334.5,260.16,607.84,322.44);
    INSERT INTO MYDAILYTOTALS VALUES('01-JUN-09',272,3402.47,204.25,504.9,230.47);
    INSERT INTO MYDAILYTOTALS VALUES('01-JUN-09',273,3260.08,195.81,620.68,203.57);
    INSERT INTO MYDAILYTOTALS VALUES('01-JUN-09',282,3182.51,191.16,557.39,177.95);
    INSERT INTO MYDAILYTOTALS VALUES('01-JUN-09',292,2103.39,195.46,366.92,95.33);
    INSERT INTO MYDAILYTOTALS VALUES('01-JUN-09',298,2997.51,179.87,452.71,210.64);
    INSERT INTO MYDAILYTOTALS VALUES('01-JUN-09',362,1614.2,149.22,329.87,141.86);
    INSERT INTO MYDAILYTOTALS VALUES('01-JUN-09',363,3058.98,344.1,523.53,259.03);
    INSERT INTO MYDAILYTOTALS VALUES('01-JUN-09',523,3776.49,226.8,533.46,376.94);
    INSERT INTO MYDAILYTOTALS VALUES('01-JUN-09',524,4720.08,437.05,554.55,320.96);
    INSERT INTO MYDAILYTOTALS VALUES('01-JUN-09',564,2725.49,245.4,419.73,134.96);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-09',22,2482.4,230.46,1126.91,42.33);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-09',23,4907.83,456.19,1254.74,305.28);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-09',27,3170.7,294.64,990.07,74.02);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-09',34,2660.45,239.48,1046.41,64.37);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-09',43,3459.94,207.57,1349.89,114.96);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-09',62,4515.62,271.13,1234.8,125.26);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-09',65,2196.06,204.05,1010.08,60.71);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-09',66,2558.77,237.84,1031.84,76.4);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-09',68,2677.87,261.12,950.73,184.17);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-09',69,2165.68,195.01,786.06,62.33);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-09',78,4562.37,274.06,1386.15,135.12);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-09',141,2690.6,161.65,1118.96,36.43);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-09',181,2321.7,215.62,827.14,50.56);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-09',244,3312.27,198.84,1099.22,235.38);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-09',251,6012.15,360.89,1786.03,489.65);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-09',252,1823.33,164.16,702.65,78.91);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-09',260,3030.32,281.47,958.58,90.78);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-09',262,4198.03,390.37,1111.2,57.21);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-09',263,2463.36,229.01,1010.05,39.46);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-09',271,4571.16,274.35,1256.94,162.23);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-09',276,3244.67,301.41,926.42,70.05);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-09',277,3650.92,219.3,1225.24,184.51);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-09',281,3915.25,235.15,1364.07,207.56);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-09',282,3207.09,192.59,1279.52,116.07);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-09',289,2509.67,187.63,1156.46,129.59);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-09',290,1840.89,133.03,885.45,166.21);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-09',291,3860.49,358.79,1157.38,86.91);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-09',295,3989.96,239.65,1258.06,239.39);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-09',298,2748.82,165.08,979.23,290.44);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-09',321,3626.59,217.84,1547.6,186.81);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-09',381,3030.78,181.96,977.68,246.34);
    INSERT INTO MYDAILYTOTALS VALUES('02-JUN-09',521,3349.57,310.04,1184.6,87.48);

  • AND and OR operations in WHERE clause

    Hello, Dear Oracle professionals.
    In WHERE clause when I use AND or OR operations, is there any way of working ORACLE server to select rows?
    For example
    WHERE con1 and con2 and con3 and con4 and con5OR
    WHERE con1 or con2 or con3 or con4 or con5How oracle checks this conditions ? From the begining to the end ? in order ?
    May be I should put some more probable TRUE condition to the end(or to the begin).
    Whant to know how oracle thinks.
    Thanks in advance.

    Khayyam wrote:
    Hello, Dear Oracle professionals.
    In WHERE clause when I use AND or OR operations, is there any way of working ORACLE server to select rows?
    For example
    WHERE con1 and con2 and con3 and con4 and con5OR
    WHERE con1 or con2 or con3 or con4 or con5How oracle checks this conditions ? From the begining to the end ? in order ?It evalauates the one that is likely to make the most difference first. In the case of AND, that means the condition that is least likely to be true (as far as the optimizer can predict).
    May be I should put some more probable TRUE condition to the end(or to the begin).It doesn't matter to the optimizer. Do whatever you find easier to read and debug.
    In ancient times, using the rule-based optimizer, order did matter, but there's no reason to be using the rule-based optimizer now. Oracle 11 doesn't even have the option.
    By the way, be careful not to mix AND and OR without parentheses. That is, never say:
    WHERE  x AND y OR z    -- ***** No!  Wrong!  ******Instead say
    WHERE  (x AND y) OR z   or
    WHERE  x AND (y OR z)   depending on what you want. If you don't use partentheses, then there are rules about how the expresssion is evaluated, but it's a waste of your time to learn them.

  • Outer join with a WHERE clause

    hi, this is driving me round the bend. I thought i was ok with sql joins and the like, but im really struggling on this one.
    I have table A (for argument sake tblRegion) and table B (tblBranch). if i want to return everything i would do something like this:-
    select * from tblRegion join tblBranch on tblRegion.id=tblBranch.reg_id.
    If i wanted to return all regions even if they do have a branch associated i would do something like this:-
    select * from tblRegion left outer join tblBranch on tblRegion.id=tblBranch.reg_id.
    My problem is, I want to return all Regions and use a WHERE clause to narrow the Branch results.
    I've tried something like this but it doesnt work
    select * from tblRegion left outer join tblBranch on tblRegion.id=tblBranch.reg_id WHERE branch.name like 'LONDON%'
    Is there anyway i can return all branches where name is like LONDON, and STILL return all Region if there is no data for that Region?
    Do i need to use a nested select statement maybe?
    Many thanks in anticipation somebody will save me from my current madness. David

    Check this link. It explains the most common problem/coding error while using outer join.
    Effectively in your case you need the following condition in your where clause
    where nvl(branch.name,'LONDON') like 'LONDON%'
    Hope that helps.

  • How to change operator of join conditions in where clause?

    I have a situation... I want to change the operator between each join conditions in the where clause when these join conditions are not from the same join..
    For example, I have the following schema:
    Dim1 ------ DimA -------Fact1
    Dim1-------DimB -----Fact1
    So DimA and DimB are aliasas of one dim table, but the join is different.
    Now if I run this model, what I will get in the where clause of the query is:
    Where Dim1 = DimA and Dim1 = DimB and DimA= Fact1 and DimB = fact1.
    Is there a way I can change these "and" operator to "OR", so that the where clause would look like this: Where Dim1 = DimA and Dim1 = DimB and DimA= Fact1 OR DimB = fact1?
    This is different from simply changing the join operator within the same join, because these are different joins and I'd like to control how they relate to each other..
    Please help

    Sometimes, business rules are complex, so there isn't always a way to simplify things.  Is your issue that it's complex and error prone, or is it performance due to the OR clauses?
    One possibility that will at least make it easier to test and debug is something like this:  (pseudocode)
    From Table1 Inner join Table2 on x=y etc.etc.
    (Select case when a=b and (c=d or e=f) then 1 else 0 end) as Situation1
    , case when h=i or j = k then 1 else 0 end) as situation2
    , case when l = m then 1 else 0 end) as situation 3
    ) as CA_Logic_Simplifier
    Where situation1 = 1 and situation2 = 1 and situation3 = 1
    Although you could say, "Hey, this is basically doing the same thing as before", this approach would be far easier to test and debug, because you can at a glance look at the values for situation1, 2, 3, etc. to see where errors are being introduced. 
    The cross apply makes the columns situation1/2/3 "instantiated", so they are usable in the where clause. Divide and conquer.  

  • Order of fields in Primary key in where clause

    Does order of fields(complete primary key) in where condition matters with the performance or using of index ?
    Here is an example -
    BKPF has primary key - bukrs, gjahr, belnr.
    1. select single awkey into lv_awkey
      from bkpf where bukrs = p_bukrs
                  and gjahr = p_gjahr
                  and belnr = p_belnr.
    2. select single awkey into lv_awkey from bkpf
                                  where bukrs = p_bukrs and
                                            belnr = p_belnr and
                                            gjahr = p_gjahr.
    Does it make any difference in performance point of view with above two kinds ? Is that same applicable when accessing based on secondary index ?

    Hi Nagarjuna,
    the order of the fields does not influence the performance of the execution of the statements. This is true for primary key and secondary key accesses. In the statement cache (SAP and DB) two different statemens have to be maintained (parsing, space, ...) but their execution time is the same.
    Kind regards,

  • CBO and functions in the WHERE clause

    Can anyone point me to any documents describing how the cost based optimizer treats functions in a WHERE clause?
    For example, in
    select ...
    from   ...
    where  ...
    and    my_package.my_function( t.some_column ) = 'Y'
    ...does the CBO treat "my_package.my_function" as a black box or does it go into the body of "my_package.my_function" and take into consideration the associated costs of all the SELECT statements in the function?
    I've tried a few simple tests to answer the question, but I've received conflicting results. Has anyone had any experience with this?
    Thanks in advance for your help.

    Thanks for the info. Justin.
    I think I've solved my problem, but I'll repeat it here in case it helps anyone else. Here is a very simplified example of what I was seeing.
    A query like this:
          a.party_id, b.cust_account_id
          hz_parties a,
          hz_cust_accounts b
          a.party_id = b.party_id
          and mis_hz_merge_veto_pkg.party_merge_will_be_vetoed(a.party_id) = 'N'was returning a drastically different execution plan than this
          a.party_id, b.cust_account_id
          hz_parties a,
          hz_cust_accounts b
          a.party_id = b.party_id
          and mis_hz_merge_veto_pkg.account_merge_will_be_vetoed(b.cust_account_id) = 'N'I initially thought the difference was due to the fact that I was using different functions in the last line, but then I tried this version
          a.party_id, b.cust_account_id
          hz_parties a,
          hz_cust_accounts b
          a.party_id = b.party_id
          and mis_hz_merge_veto_pkg.party_merge_will_be_vetoed(b.party_id) = 'N'and found that it gave me a different execution plan than the first SELECT as well, even though it used the same function. The difference seems to stem from the columns I use in the function parameter and not the choice of function.

  • How can define an outer join in the where clause of a flowr statement?

    Hi- In the sample below I'm joining two views based on username but in this case what I really want to use is an outer join instead. What is the syntax for that? I tried the (+) notation but that didn't seem to work..
    CREATE OR REPLACE PROCEDURE proc_ctsi_all is
    XMLdoc XMLType;
    SELECT XMLQuery(
    {for $c in ora:view("CTSI_INVEST_NONPHS_SOURCE_V"),
    $cphs in ora:view("CTSI_INVEST_PHS_SOURCE_V")
      let $username  := $c/ROW/COMMONS_USERNAME/text(),
    $expertise  := $c/ROW/AREA_OF_EXPERTISE/text(),
    $phsorg  := $cphs/ROW/PHS_ORGANIZATION/text(),
    $activitycode  := $cphs/ROW/ACTIVITY_CODE/text(),
    $username2  := $cphs/ROW/COMMONS_USERNAME/text()
    where $username eq $username2
    IF(DBMS_XDB.CREATERESOURCE('/public/CTSI/ctsi_all_rpt1.xml', XMLdoc)) THEN
    DBMS_OUTPUT.PUT_LINE('Resource is created');
    DBMS_OUTPUT.PUT_LINE('Cannot create resource');
    END IF;

    What you could do is use query within an XMLTable syntax. Via the COLUMNS parameter you then pass the "column" as XMLType to the following XMLtable statement.
    little bit like the following
    select hdjfdf
    from xmltable
        COLUMNS xmlfrag xmltype path 'xxx'
       ) a
    ,  xmltable
       ({the other stuff you need}
        PASSING a.xmlfrag
      ...etc                 I guess something simular can be done via XQuery straight away as well

  • Select Statement -- Where Clause Execution Order

    What is the order of execution of the "AND" and "OR" in the WHERE clause of a Select statement?
    Are the "AND"'s executed from the top down, left to right? Is it the same for the "OR"'s execution?
    Thanks for any help...

    Not clear why you care. There is an order in which the optimizer parses the SQL (which may change from ver to ver), but this is a fairly quick operation. The order in which tables are visited and predicates evaluated is dependent on what the op[timizer does with the SQL.

  • Order of Where clause

    Hello GURUs
    I have doubt about following. Please can all help me.
    1. Does the order of table in from clause make difference. what should be the order. . largest to snmallest.
    2. Does where clause order make difference. also left side to right side of equality comaprision. table row column on left and table column with less row on right.?
    3. in USE_NL order of table make difference or not.? which one should be first one with less row or one with more rows. ?
    4. Somtimes i have seen that USE_NL(table name) with only one table. in what condition that will be used. Larger or the smaller and then will the where clause make difference on that with USE_NL HINT.?
    Message was edited by:

    Ok, because you insist :-)
    I think you shouldn't care that much about these subjects, really. Oracle has an excellent cost based optimizer (cbo) that does all the work for you. It decides which predicate to apply first, the order of the tables and much more. But, and this is an important but, the cbo must have recent statistics of all the objects involved in your queries. So make sure you analyze regularly or use monitoring to stay up to date.
    Applying hints like USE_NL is like saying: "I know way better than the cost based optimizer how to get the results quicker, so you should always use this access path".
    Most of the time, however, something else is wrong, and by applying some hints you may (temporarily) fix the symptoms of your problem, but you are not addressing the root cause. So in case you feel the need to apply such a hint, please don't and start investigating what is really causing your problems.
    Hope this helps.

  • ADF/UIX where clause and VO on different pages

    i have a VO called Periods which contains Periods and their statuses. On one page for entering data i use the periods VO in LOV mode with a where clause limiting the user to selecting periods with open status.
    I have another page which is for maintaining the period statuses. The problem is that when i move between entry and setup pages the where clause takes affect in both pages ie. the maintain periods page only shows periods with status Open!!
    To get around this on the maintain periods prepare model i tried doing this:
    actionContext.getBindingContainer().getApplicationModule().findViewObject("PeriodsView1").executeQuery();this works, however it causes bizarre behaviour on some records when i change values in the UIX editable table. The UIX editable table works fine if i remove the above code snippet (and dont go to the page that sets the where clause on the view object). The behaviour is that i cant select some rows in the UIX table properly and the updated values arent effected.
    can someone advise pn the proper way of doing this?

    Brenden, instead of setting the where clause to null, try setting it to an empty string (eg. "") or something dumb like "1=1".
    In turn place JDeveloper into debug mode by selecting your project properties, profiles, development, runner, and changing the java options to: -Djbo.debugoutput=console
    With this option turned on, you'll see your actual SQL going to the database with your where clause. You should be able to see the where clause of your underlying query that you just set, and if you use something dumb like 1=1 you'll note the setWhereClause module is working.
    Hope this helps.

  • The mechanics of the WHERE clause

    I’ve been out in industry for over 10 years now doing DB work most of that time. Lately I’ve been doing some work that is starting to challenge my long held assumptions about the internal workings of SQL Server, specifically what exactly is happening when
    I do joins and where clauses.
    I was explaining to someone that when doing a join putting in a where clause limits the amount of records that are available to do the join on thereby making the query faster. My thought was if a table has 100MM records but only 50MM of those meet the WHERE
    criteria then the JOIN clause wouldn’t try matching the 50MM records that don’t meet the WHERE clause.
    I did some work that afternoon and the empirical results didn’t match the expected outcome of a query I had written in terms of execution time. I don’t think my understanding of what goes on during a JOIN is correct. Can someone educate me?

    Here is how a SELECT works in SQL ... at least in theory.  Real products will optimize things, but the code has to produce the same results. 
     a) Effectively materialize the CTEs in the optional WITH clause. CTE's come into existence in the order they are declared so only backward references are
    alllowed. A CTE can be recursive. Think of them as VIEWs that exist only in the scope of the query. In practice, if they are used once then they are implemented as an in-line macro.
     b) Start in the FROM clause and build a working table from all of the joins, unions, intersections, and whatever other table constructors are there.  The <table expression> AS <correlation name> option allows you give a name to this working
    table which you then have to use for the rest of the containing query.  Ther are UNIONB, INTERSECT and EXCEPT set construtors, LATERAL tables, table-valued funcitosn and all kinds of things happening in here. 
     c) Go to the WHERE clause and remove rows that do not pass criteria; that is, that do not test to TRUE (i.e. reject UNKNOWN and FALSE).  The WHERE clause is applied to the working set in the FROM clause.  
     d) Go to the optional GROUP BY clause, partiton the original table into groups and reduce each grouping to a *single* row, replacing the original working table with the new grouped table. The rows of a grouped table must be only group characteristics:
    (1) a grouping column (2) a statistic about the group (i.e. aggregate functions) (3) a function or constant(4) an expression made up of only those three items.  The original table no longer exists and you cannot reference anything in it (this was an error
    in early Sybase products).  
     e) Go to the optional HAVING clause and apply it against the grouped working table; if there was no GROUP BY clause, treat the entire table as one group. 
     f) Go to the SELECT clause and construct the expressions in the list. This means that the scalar subqueries, function calls and expressions in the SELECT are done after all the other clauses are done.  The AS operator can also give names to expressions
    in the SELECT list.  These new names come into existence all at once, but after the WHERE clause, GROUP BY clause and HAVING clause have been executed; you cannot use them in the SELECT list or the WHERE clause for that reason. 
    If there is a SELECT DISTINCT, then redundant duplicate rows are removed.  For purposes of defining a duplicate row, NULLs are treated as matching (just like in the GROUP BY).  
     g) Nested query expressions follow the usual scoping rules you would expect from a block structured language like C, Pascal, Algol, etc.  Namely, the innermost queries can reference columns and tables in the queries in which they are contained.  
     h) The ORDER BY clause is part of a cursor, not a query. The result set is passed to the cursor, which can only see the names in the SELECT clause list, and the sorting is done there.  The ORDER BY clause cannot have expression in it, or references
    to other columns because the result set has been converted into a sequential file structure and that is what is being sorted.  
    As you can see, things happen "all at once" in SQL, not "from left to right" as they would in a sequential file/procedural language model. In those languages, these two statements produce different results:
      READ (a, b, c) FROM File_X;
      READ (c, a, b) FROM File_X;
    while these two statements return the same data:
    SELECT a, b, c FROM Table_X;
    SELECT c, a, b FROM Table_X;
    Think about what a confused mess this statement is in the SQL model.
    SELECT f(c2) AS c1, f(c1) AS c2 FROM Foobar;
    That is why such nonsense is illegal syntax.
    --CELKO-- Books in Celko Series for Morgan-Kaufmann Publishing: Analytics and OLAP in SQL / Data and Databases: Concepts in Practice Data / Measurements and Standards in SQL SQL for Smarties / SQL Programming Style / SQL Puzzles and Answers / Thinking
    in Sets / Trees and Hierarchies in SQL

  • How can you add a where clause using "OR" with applied ViewCriteria?

    [JDeveloper 10.1.3 SU4]
    [JHeadstart 10.1.3 build 78]
    I am using JHeadstart, but have a question probably more in the ADF area. On the JHeadstart forum I asked:
    "I am overriding JhsApplicationModule's advancedSearch in order to be able to search in childtables. I created transient attributes, display those in advanced search and in the overridden method I check if any of these are filled by the user and create a where clause like 'EXISTS (SELECT 1 FROM <childtable> WHERE <column in childtable> = <column in EO's table> AND <another column in childtable> LIKE '<value supplied by user>)'. I add this whereclause using ViewObject.setWhereClause.
    So far so good and it works. However, if the user selects 'Result matches any criteria', combining setWhereClause and the normal advancedSearch QueryByExample implementation using ViewCriteriaRow do not provide the desired result, since the ViewCriteria and the setWhereClause are AND-ed together, which is fine if the user selects the (default) "Results match all criteria" (everything is AND-ed) but not the "Result matches any criteria", since then every criterium is OR-ed together, except for the setwhereclause criteria and the set of ViewCriteriaRows, they are AND-ed.
    I looked if I could specify that a WhereClause will be OR-ed to existing applied ViewCriteria, but no luck. Do I have to rewrite also advancedSearch's ViewCriteria implementation and write an entire setWhereClause implementation to be able to "OR" every criterium? Or any other suggestions? Can I look at the entire Where clause and rewrite it (after applyCriteria and setWhereClause are called on the VO)?
    Sandra Muller (JHeadstart Team) told me today: "This sounds like a JDeveloper/ADF issue that is not related to JHeadstart. The question is: how can you add a where clause using "OR" if there are already one or more ViewCriteria applied?
    To simplify the test case, you could create a simple ADF BC test client class in a test Model project without JHeadstart (in the test class, use bc4jclient + Ctrl-Enter), in which you first apply a few ViewCriteriaRows to a View Object and also add a where clause.
    Can you please log a TAR at MetaLink ( http://metalink.oracle.com/ ), or ask this question at the JDeveloper forum at http://otn.oracle.com/discussionforums/jdev.html ? (This what I am doing now ;-))
    Sandra Muller
    JHeadstart Team
    Oracle Consulting"
    Anyone knowing the answer or am I asking for an enhancement?

    Can you SET your whereclause as follows ?
    ('Y' = <isAnd>
    and EXISTS (SELECT 1 FROM <childtable> WHERE <column in childtable> = <column in EO's table> AND <another column in childtable> LIKE '<value supplied by user>))
    OR ('N' = <isAnd>
    AND EXISTS (SELECT 1 FROM <childtable> WHERE <column in childtable> = <column in EO's table> OR <another column in childtable> LIKE '<value supplied by user>))

  • Using Date in where clause

    Hello all,
    I am new to Oracle, currently using 10G + aspvbscript.
    I've been trying to query data using date in where clause but nothing seems to work.
    The column is in date format.
    It gets printed out like this: 5/1/2010 11:21:19 AM
    I tried using this query:
    SELECT * from table where TRUNC(user_date) > to_date('FEB-01-2010:00:00:00','mm-dd-yyyy:HH24:MI:SS') order by user_date asc.
    It does return an output but it returns everything in table and does not take WHERE clause into consideration however, it does sort the date in ascending order.
    I've tried getting rid of TRUNC tried to format date in a different way but no such luck.
    Please point me to the right direction.

    Welcome to the forums!
    In cases like this it is helpful if you can provide the following information:
    1. Oracle version (SELECT * FROM V$VERSION)
    2. Sample data in the form of CREATE / INSERT statements.
    3. Expected output
    4. Explanation of expected output (A.K.A. "business logic")
    5. Use \ tags for #2 and #3. See FAQ (Link on top right side) for details.
    I'll try and take a stab at your request based on the data given. What your query says is that it will return all rows that have a date greater then 2/1/2010 (MM/DD/YYYY). If your query is returning all rows then maybe the possibility exists that all the dates in the table are greater then 2/1/2010. Have you checked all dates to see if this is the case?
    Also, one note about your TO_DATE() function.to_date('FEB-01-2010:00:00:00','mm-dd-yyyy:HH24:MI:SS')The date format does not match the string you are using with respect to month. Your string has 'FEB' but the format is 'MM' which is the numeric representation of the month. Although Oracle was able to convert it to the proper date on my system you should try and maintain consistency between the string and the date format used.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   

  • Where clause one query not being pushed down

    I am having a problem where I cannot get a certain "optional" parameter to be pushed down to a query. The parameter gets applied in memory after the result set is returned but not pushed down to the DB. The function is as follows:
    declare function getFoo($key as xs:string, $optinalInput as xs:string*) as element(b:bar)*
    for $foo in f:getFoo()
    where $key = $foo/key
    where not(exists($optinalInput)) or $foo/optional = $optinalInput<- does not get pushed down to the query
    return $foo
    If I make optinalInput an xs:string instead of xs:string * and the optional parameter will get pushed to the query. The problem is for this optional parameter I could get anywhere from 0-50 in the sequence. Seems like when the parameter is a sequence it doesn't get applied to the query. Is there any way around this?

    I understand the difference between * and ? and I was one of the people working on the "string-length not getting pushed" problem so I am very familiar with it. I tried you solution that you mentioned below and it still did not push the where clause to the query. I know I could achieve this with an ad-hoc query but I wanted to do a pure xquery implementation of this component because of the benefits it could have when interacting with other components in our ODSI project...such as SQL joining and potentially pushing additional where clause down from components that call this component. The only way I did get this to kind of work is to do this:
    for $o in $optinalInput
    for $foo in f:getFoo()
    where $key = $foo/key
    where $o = $foo/optional
    for $count in 1
    where not(exists($optinalInput))
    for $foo in f:getFoo()
    where $key = $foo/key
    By putting the optional parameter into a FOR statement above the table call it guarantees that at least one will exists and that's why the optional parameter gets pushed properly to the DB with a parameterized query. The problem with this is that even though a parameterized query gets pushed it will call the SQL statement multiple times!...not good.
    Another solution that was suggested to me would be to create the number of sequences for each item in the sequence and treat each item as it's own. For example if you know that the schema limits the sequence from 0..50 then you could make 50 items and 50 where clauses....probably not an optimal solution either but it would achieve properly pushing the where clause tot he DB.
    For now I am satisfied with this optional parameter not being pushed to the DB because the performance was still good but it would be nice if there was a maintainable pure xquery solution to this problem.
    Thanks for the help it's always appreciated!

Maybe you are looking for

  • Is there a way to create a smart playlist that lists my top 25 plays from a specific time period (i.e. - top plays from the last 90 days)?

    Is it possible to create an itunes smart playlist that lists my top 25 most played songs in a specific time period (i.e. - the last 90 days)?  It seems that any "most played" list I create counts every spin a track has had in it's history of being in

  • Displaying HTML file using IFrame

    Hi All, I have an HTML file in my par file. It is contained as dist\html\test.html. Now I want to display this inside an IFrame. If I try something like <iframe id="myIframe" src="html\test.html"  width=100% height=100% frameborder="0"></iframe> it f

  • Account determination for condition type

    Hi Guru, I have  requirement where I  need to assign G/l account in VKOA for condition type used for discount and markup same time. I know I can aasign trade discount to this condition type but how about markup. can we assign two diffeent account to

  • Saw.dll?BIEEHome&startPage=1 & ?Logoff HTML

    Hi, I'm new to OBIEE (11g) and basically, here's the problem we're having: We changed our header to include our new logo. The logo appears, but on the log on and log off page, the logo is the wrong width. Here's what I've found by simply viewing the

  • Filter By Total

    I am writing a BEx Query for accounts receivable and I only want to show documents that dont come back to zero e.g. outstanding debts. How do I filter out documents that do come back to zero. On rows I have allocation number and baseline date and in