I've run into a problem I've never had before. I've built a derived table with 4 result objects that, according to Universe Designer, works correctly. The table and all 4 objects are successfully parsed, when I run the table via the Table values option it returns exactly what I expect, in full agreement with the data our frontend is reporting. So far so good.
The issue I'm having is in Webi. When I bring any object from that table into a new report and run it I get the following error:
A database error occured. The database error text is: ORA-00903: invalid table name. (WIS 10901)
How is this possible? How can an object that Universe Designer and, I assume, our Oracle database both say works fine and returns data, give me this error when I use that object in Webi? I've rebuilt the table, rechecked all the table names and shortened them just in case, there are no unusual alphanumeric characters in any table name, what else can I do? Here's the code that works in the universe and fails in WebI:
SELECT distinct
to_number(p.ID) as person_id,
e.ID as EPISODE_ID,
et.DESCRIPTION as episode_type,
nvl(rfa.date_answer,e.start_date) as LAST_REVIEW_IN_PERIOD
FROM
PEOPLE p
INNER JOIN EPISODES ref_e on (p.id=ref_e.subject)
LEFT OUTER JOIN REPORT_FORM_ANSWERS ref_rfa on (ref_e.ID = ref_rfa.episode_id and ref_rfa.section_item_tag_id ='0AA384CC-DDD8-A85F-6B68-060CCD878DE9') -- Date of referral - Response and Rehabilitiation referral
LEFT OUTER JOIN EPISODE_OUTCOMES ref_eo on (ref_e.ID=ref_eo.EPISODE_ID)
LEFT OUTER JOIN EPISODES tri_e on (ref_eo.NEW_EPISODE_ID=tri_e.ID)
INNER JOIN EPISODES e ON p.ID=e.SUBJECT
LEFT OUTER JOIN #DerivedTable("DT_CA_RRRT_SUEligible") on (e.ID="DT_CA_RRRT_SUEligible".EPISODE_ID)
INNER JOIN EPISODE_TYPES et ON e.TYPE=et.TYPE
LEFT OUTER JOIN report_form_answers rfa on e.id=rfa.episode_id and rfa.section_item_tag_id in (
'C8AEC1B5-6115-20CC-E160-EC9CB3854752', -- End Date - Response and Rehabilitiation Assessment
'6DC97CE9-CA70-042A-3894-44CA551440DB' -- Assessment end date - RRRT Assessment of Care and Support Needs
)
LEFT OUTER JOIN #DerivedTable("DT_PBLTElementsWithDates") on (p.id="DT_PBLTElementsWithDates".PERSON_ID and "DT_PBLTElementsWithDates".service_start<ref_rfa.date_answer and ("DT_PBLTElementsWithDates".service_end>=add_months(ref_rfa.date_answer,-12) or "DT_PBLTElementsWithDates".service_end IS NULL))
WHERE
(et.DESCRIPTION in('Response and Rehabilitation Assessment'))
and
ref_e.id=dbo.f_workflow_first(e.ID,'RRRT Referrals')
AND
tri_e.TYPE='RRRTHOSTRI'
and
e.end_date IS NOT NULL
and
"DT_PBLTElementsWithDates".SERVICE_TYPE_ID IS NOT NULL
and
"DT_CA_RRRT_SUEligible".TEXT_ANSWER='Yes'
and
nvl(rfa.date_answer,e.start_date) <= #Prompt('Select reviews to','D',,mono,free)
I'm at a loss. What is going on, what am I missing?
Related
I have a query that consists of a join between two tables. When it is an inner join, the query works fine. However, when I change it to an outer join, it throws an error as if the secondary table was not defined in the query.
Here is what I mean:
select a.unit
, a.data_date
from (
select unit
, person
, data_date
from the_data
) a
join personnel b
on (
b.person = a.person
and b.first_date <= a.data_date
and b.last_date >= a.data_date
)
the_data and personnel are tables
This works as written, but if you change the join to a left join, it reports that a.data_date is an invalid identifier (and if you rewrite the ON clause so the top line is at the bottom, it will say that a.person is invalid).
I vaguely remember coming across this once before, and it turned out to be an internal Oracle bug.
The database is 64-bit version 11.2.0.4.0.
I'm getting this error no matter what I do with the INNER JOIN Statement
Here is my code:
SELECT Package_Code, Description, Duration, Site_Code
FROM tbl_Holiday_Details
INNER JOIN tbl_Site_Visted
ON tbl_Holiday_Details.Package_Code = tbl_Site_Visted.Package_Code
INNER JOIN tbl_Site_Visted
ON tbl_Site_Details.Site_Code = tbl_Site_Visted.Site_Code
I don't understand what is the problem.
ps. if needed i will provide more code
The immediate problem is that at least Package_Code and Site_Code exist in multiple tables but your select does not specify which table you want to return data from. Yes, you know that you're doing an inner join on those columns so it doesn't matter which table's value is returned but the SQL syntax doesn't allow Oracle to make that inference. Generally, I would advise that you always alias every column both so it is clear which table a particular attribute is coming from and so that you don't break code when you add an attribute to a different table that happens to have the same name.
SELECT tbl_Holiday_Details.Package_Code,
Description,
Duration,
tbl_Site_Visted.Site_Code
FROM tbl_Holiday_Details
INNER JOIN tbl_Site_Visted
ON tbl_Holiday_Details.Package_Code = tbl_Site_Visted.Package_Code
INNER JOIN tbl_Site_Visted
ON tbl_Site_Details.Site_Code = tbl_Site_Visted.Site_Code
will work assuming Description and Duration are defined only in one of the three tables. I would add aliases to Description and Duration as well but I don't know which of the tables should be used. Of course, I would generally use simpler aliases (say, tsv for tbl_Site_Visited) rather than the full table name.
If you want to avoid aliasing your columns, you could use the USING clause rather than the ON clause
SELECT Package_Code,
Description,
Duration,
Site_Code
FROM tbl_Holiday_Details
INNER JOIN tbl_Site_Visted
USING( Package_Code )
INNER JOIN tbl_Site_Visted
USING( Site_Code )
I see that running ANALYZE results in significantly poor performance on a particular JOIN I'm making between two tables.
Suppose the following schema:
CREATE TABLE a ( id INTEGER PRIMARY KEY, name TEXT );
CREATE TABLE b ( a NOT NULL REFERENCES a, value INTEGER, PRIMARY KEY(a, b) );
CREATE VIEW ab AS SELECT a.name, b.text, MAX(b.value)
FROM a
JOIN b ON b.a = a.id;
GROUP BY a.id
ORDER BY a.name
Table a is approximately 10K rows, table b is approximately 48K rows (~5 rows per row in table a).
Before ANALYZE
Now when I run the following query:
SELECT * FROM ab;
The query plan looks as follows:
1|0|0|SCAN TABLE b
1|1|1|SEARCH TABLE a USING INTEGER PRIMARY KEY (rowid=?)
This is a good plan, b is larger and I want it to be in the outer loop, making use of the index in table a. It finishes well within a second.
After ANALYZE
When I execute the same query again, the query plan results in two table scans:
1|0|1|SCAN TABLE a
1|1|0|SCAN TABLE b
This is far for optimal. For some reason the query planner thinks that an outer loop of 10K rows and an inner loop of 48K rows is a better fit. This takes about 1.5 minute to complete.
Should I adapt the index in table b to make it work after ANALYZE? Anything else to change to the indexing/schema?
I just try to understand the problem here. I worked around it using a CROSS JOIN, but that feels dirty and I don't really understand why the planner would go with a plan that is orders of magnitude slower than the un-analyzed plan. It seems to be related to GROUP BY, since the query planner puts table b in the outer loop without it (but that renders the query useless for what I want).
Accidentally found the answer by adjusting the GROUP BY clause in the view definition. Instead of joining on a.id, I group on b.a instead, although they have the same values.
CREATE VIEW ab AS SELECT a.name, b.text, MAX(b.value)
FROM a
JOIN b ON b.a = a.id;
GROUP BY b.a -- <== changed this from a.id to b.a
ORDER BY a.name
I'm still not entirely sure what the difference is, since it groups the same data.
This is the query i am running:
select /*+ index(V_AMV_PLG_ORDER_HISTORY_200_MS.orders.T0 IDX_ORDER_VERSION_3) */ *
from V_AMV_PLG_ORDER_HISTORY_200_MS
where EXCHANGE_SK = 32 and PRODUCT_SK = 1000169
And it uses a different index than the one i am ordering it to.
As you can see, I am querying from the view V_AMV_PLG_ORDER_HISTORY_200_MS, you can see its sql query here:
V_AMV_PLG_ORDER_HISTORY_200_MS view SQL Query:
SELECT AMV_PERF_PROFILES_FRONTEND.AMV_PLG_GET_SEGMENT(200, orders.ORDER_GLOBAL_DATE_TIME) AS ORDER_DATE_TIME,
SUM(orders.BASE_VOLUME) AS VOLUME,
SUM(orders.BASE_CURR_LIMIT_PRICE*orders.BASE_VOLUME)/SUM(orders.BASE_VOLUME) AS PRICE,
orders.PRODUCT_SK AS PRODUCT_SK,
orders.EXCHANGE_SK AS EXCHANGE_SK,
orders.DIRECTION_CD AS DIRECTION_CD,
orders.AGG_UNIT_CD AS AGG_UNIT_CD,
orders.TRADER_KEY AS EXECUTING_REPRESENTATIVE_KEY,
orders.ACCOUNT_KEY AS ACCOUNT_KEY,
a.BUSINESS_UNIT_CD AS BUSINESS_UNIT_CD
FROM AMV_PERF_PROFILES_FRONTEND.S_AMV_ORDER_VERSION_NEW orders
INNER JOIN AMV_PERF_PROFILES_FRONTEND.S_AMV_ACCOUNT a
ON a.ACCOUNT_KEY = orders.ACCOUNT_KEY
WHERE BASE_VOLUME > 0
GROUP BY AMV_PERF_PROFILES_FRONTEND.AMV_PLG_GET_SEGMENT(200, orders.ORDER_GLOBAL_DATE_TIME),
orders.PRODUCT_SK,
orders.EXCHANGE_SK,
orders.ACCOUNT_KEY,
a.BUSINESS_UNIT_CD,
orders.AGG_UNIT_CD,
orders.TRADER_KEY,
orders.DIRECTION_CD;
He is getting the data using the Synonym S_AMV_ORDER_VERSION_NEW, Which directs to another Scheme, to a view called V_AMV_ORDER_VERSION and refering to it as orders, its sql query here:
V_AMV_ORDER_VERSION view Sql query:
SELECT T1.ENTITY_KEY ,
T2.AGG_UNIT_CD ,
T0.BASE_CURR_LIMIT_PRICE ,
T7.DIRECTION_CD ,
T0.EXCHANGE_SK,
T0.ORDER_LOCAL_DATE_TIME ,
T0.PRODUCT_SK,
T18.ENTITY_KEY ,
T19.ENTITY_KEY ,
T0.NOTIONAL_VALUE2 ,
T0.NOTIONAL_VALUE ,
T0.ORDER_GLOBAL_DATE_TIME ,
T0.BASE_VOLUME ,
T31.TRANSACTION_STATUS_CD ,
T0.ORDER_VERSION_KEY
FROM ETS_UDM_CDS_NEW.ORDER_VERSION T0
LEFT OUTER JOIN ETS_UDM_CDS_NEW.ENTITY T1
ON T0.ACCOUNT_SK = T1.ENTITY_SK
LEFT OUTER JOIN ETS_UDM_CDS_NEW.AGG_UNIT T2
ON T0.AGG_UNIT_SK = T2.ENTITY_SK
LEFT OUTER JOIN ETS_UDM_CDS_NEW.DIRECTION T7
ON T0.DIRECTION_SK = T7.ENTITY_SK
LEFT OUTER JOIN ETS_UDM_CDS_NEW.ENTITY T18
ON T0.LOCAL_TIME_ZONE_SK = T18.ENTITY_SK
LEFT OUTER JOIN ETS_UDM_CDS_NEW.ENTITY T19
ON T0.TRADER_SK = T19.ENTITY_SK
LEFT OUTER JOIN ETS_UDM_CDS_NEW.TRANSACTION_STATUS T31
ON T0.TRANSACTION_STATUS_SK = T31.ENTITY_SK;
Which takes its data from a table called ORDER_VERSION and refers to it as T0
this table has an index called IDX_ORDER_VERSION
The problem is that oracle ignores my hint, And uses a different index, Now, I have managed to use a hint to make oracle use an index i wanted when i was querying a view that gets data from a table, But this time I am querying a view which gets his data from another view which gets his data from a table.
And also, The second view in the line is on a different Scheme and i am using a synonym, So perhaps that is why i am missing something Cuz i tried many combinations of possible solutions i found on google but nothing seems to be working...
I would say that if i go one step forward and query directly from V_AMV_ORDER_VERSION (Without the synonym) IT works and i can make oracle work with any index i want, so this query works perfect:
select /*+ index(orders.T0 IDX_ORDER_VERSION_5) */ * from V_AMV_ORDER_VERSION orders
where EXCHANGE_SK =32 and PRODUCT_SK = 1000169
Well me and our company's DBA looked at it for a while, it seems like an Oracle bug in the Global Hint manifestation, We have created the view V_AMV_PLG_ORDER_HISTORY_200_MS using a regular join rather than an ANSI join, and now it works properly:
V_AMV_PLG_ORDER_HISTORY_200_MS view SQL Query:
SELECT AMV_PERF_PROFILES_FRONTEND.AMV_PLG_GET_SEGMENT(200, orders.ORDER_GLOBAL_DATE_TIME) AS ORDER_DATE_TIME,
SUM(orders.BASE_VOLUME) AS VOLUME,
SUM(orders.BASE_CURR_LIMIT_PRICE*orders.BASE_VOLUME)/SUM(orders.BASE_VOLUME) AS PRICE,
orders.PRODUCT_SK AS PRODUCT_SK,
orders.EXCHANGE_SK AS EXCHANGE_SK,
orders.DIRECTION_CD AS DIRECTION_CD,
orders.AGG_UNIT_CD AS AGG_UNIT_CD,
orders.TRADER_KEY AS EXECUTING_REPRESENTATIVE_KEY,
orders.ACCOUNT_KEY AS ACCOUNT_KEY,
a.BUSINESS_UNIT_CD AS BUSINESS_UNIT_CD
FROM AMV_PERF_PROFILES_FRONTEND.S_AMV_ORDER_VERSION_NEW orders,
AMV_PERF_PROFILES_FRONTEND.S_AMV_ACCOUNT a
WHERE BASE_VOLUME > 0 AND a.ACCOUNT_KEY = orders.ACCOUNT_KEY
GROUP BY AMV_PERF_PROFILES_FRONTEND.AMV_PLG_GET_SEGMENT(200, orders.ORDER_GLOBAL_DATE_TIME),
orders.PRODUCT_SK,
orders.EXCHANGE_SK,
orders.ACCOUNT_KEY,
a.BUSINESS_UNIT_CD,
orders.AGG_UNIT_CD,
orders.TRADER_KEY,
orders.DIRECTION_CD;
I'm having difficulty modifying a script for this situation and wondering if someone maybe able to help:
I have an address table and a phone table both sharing the same column called id_number. So id_number = 2 on both tables refers to the same entity. Address and phone information used to be stored in one table (the address table) but it is now split into address and phone tables since we moved to Oracle 11g.
There is a 3rd table called both_ids. This table also has an id_number column in addition to an other_ids column storing SSN and some other ids.
Before the table was split into address and phone tables, I had this script:
(Written in Sybase)
INSERT INTO sometable_3 (
SELECT a.id_number, a.other_id,
NVL(a1.addr_type_code,0) home_addr_type_code,
NVL(a1.addr_status_code,0) home_addr_status_code,
NVL(a1.addr_pref_ind,0) home_addr_pref_ind,
NVL(a1.street1,0) home_street1,
NVL(a1.street2,0) home_street2,
NVL(a1.street3,0) home_street3,
NVL(a1.city,0) home_city,
NVL(a1.state_code,0) home_state_code,
NVL(a1.zipcode,0) home_zipcode,
NVL(a1.zip_suffix,0) home_zip_suffix,
NVL(a1.telephone_status_code,0) home_phone_status,
NVL(a1.area_code,0) home_area_code,
NVL(a1.telephone_number,0) home_phone_number,
NVL(a1.extension,0) home_phone_extension,
NVL(a1.date_modified,'') home_date_modified
FROM both_ids a, address a1
WHERE a.id_number = a1.id_number(+)
AND a1.addr_type_code = 'H');
Now that we moved to Oracle 11g, the address and phone information are split.
How can I modify the above script to generate the same result in Oracle 11g?
Do I have to first do INNER JOIN between address and phone tables and then do a LEFT OUTER JOIN to both_ids?
I tried the following and it did not work:
Insert Into..
select ...
FROM a1. address
INNER JOIN t.Phone ON a1.id_number = t.id_number
LEFT OUTER JOIN both_ids a ON a.id_number = a1.id_number
WHERE a1.adrr_type_code = 'H'
There is a syntax error in your query. You wrote in comment below that your query is:
..
FROM address a1 JOIN telephone t ON a1.id_number = t.id_number
AND RIGHT OUTER JOIN tt_gl_both_ids a ON a.id_number = a1.id_number
WHERE
..
Throw out AND and it will work. Also, replace right outer join with left outer join, since that's what you're trying to achieve (again, based on comments you wrote).