When running a test with the following query, HSQLDB mistakes the table alias as a schema.
SELECT c.country_ml2country as CTRY_PK, c.name as CTRY_NAME,
l.name as LANGUAGE_NAME, l.code as LANGUAGE_CODE
FROM country_ml as c, language as l
WHERE c.language(+) = l.id and c.country_ml2country(+) = ?
ORDER BY l.name ASC;
Has anyone experienced this before? If "yes", then what is the fix?
Note that if I change FROM country_ml as c to FROM country_ml as bob, then the error message changes accordingly to invalid schema name: BOB.
The problem is the non-standard Oracle-style OUTER JOIN syntax, which is specific to Oracle and not supported by other SQL dialects.
WHERE c.language(+) = l.id and c.country_ml2country(+) = ?
You should use instead the following standard syntax, which Oracle also supports:
SELECT c.country_ml2country as CTRY_PK, c.name as CTRY_NAME,
l.name as LANGUAGE_NAME, l.code as LANGUAGE_CODE
FROM country_ml as c RIGHT OUTER JOIN language as l
ON c.language = l.id and c.country_ml2country = ?
ORDER BY l.name ASC
Related
Using WSO2AM-2.1.0-update12 (carbon-apomgt tag v6.2.108) normally works well with mysql. We intend to switch the underlying database to Oracle DB (11g as far I know), looks simple.
Wen creating an API the apim throws an SQLException
ORA-00907: missing right parenthesis
we traced the exception to
org.wso2.carbon.apimgt.impl.dao.ApiMgtDAO:7652
executing following query:
SELECT
A.SCOPE_ID, A.NAME, A.DISPLAY_NAME,
A.DESCRIPTION, C.SCOPE_BINDING
FROM
((IDN_OAUTH2_SCOPE AS A INNER JOIN AM_API_SCOPES AS B ON A.SCOPE_ID = B.SCOPE_ID)
INNER JOIN IDN_OAUTH2_SCOPE_BINDING AS C ON B.SCOPE_ID = C.SCOPE_ID )
WHERE B.API_ID = 1;
Running this query itself against the APIM database indeed reproduces the exception, so the code hasn't been properly tested. For some customizations we rather try to fix the code if possible than migrate to a newer version (where we have no ensurance the issue is fixed or our customizations will work)
I suspect the query as been not tested as at all and correct query may look like
SELECT
A.SCOPE_ID, A.NAME, A.DISPLAY_NAME,
A.DESCRIPTION, C.SCOPE_BINDING
FROM
IDN_OAUTH2_SCOPE A INNER JOIN AM_API_SCOPES B ON A.SCOPE_ID = B.SCOPE_ID
INNER JOIN IDN_OAUTH2_SCOPE_BINDING C ON B.SCOPE_ID = C.SCOPE_ID
WHERE B.API_ID = 1;
I'd like to validate and correct me if the query is syntactically and semantically not equivalent
Could you please try the following?
SELECT A.SCOPE_ID, A.NAME, A.DISPLAY_NAME, A.DESCRIPTION, C.SCOPE_BINDING FROM ((IDN_OAUTH2_SCOPE A INNER JOIN AM_API_SCOPES B ON A.SCOPE_ID = B.SCOPE_ID) INNER JOIN IDN_OAUTH2_SCOPE_BINDING C ON B.SCOPE_ID = C.SCOPE_ID ) WHERE B.API_ID = ?
You can find this corrected query in https://github.com/wso2/carbon-apimgt/blob/6.x/components/apimgt/org.wso2.carbon.apimgt.impl/src/main/java/org/wso2/carbon/apimgt/impl/dao/constants/SQLConstants.java#L2068
please can someone help with a SQL problem?
I have a query which currently accepts an external parameter which can be null or a single value such as 'STR1' .
This is handled by a query in format below:
select a.refe_id from a, b, c
where a.owln_code = c.code
and c.con_id = b.pers_id
and b.con_abbrv = nvl(:PARAM, b.con_abbrv)
and a.status = '01'
In the future the external parameter can have a single value, null, or multiple values separated by pipes e.g STR1|STR2|STR3|
I am now at the stage below in accomodating this but have lost the nvl test that allows a match through all rows in table b if the parameter is null.
Please can someone help with how to do this? I have searched the net and tried to do it myself. Thanks very much in advance.
select a.refe_id from a, b, c
where a.owln_code = c.code
and c.con_id = b.pers_id
and regexp_like(:PARAM, '(^|)' || b.con_abbrv|| '(|$)')
and a.status = '01'
I'd recommend something like this:
select a.refe_id from a, b, c
where a.owln_code = c.code
and c.con_id = b.pers_id
and (:PARAM IS NULL OR regexp_like(:PARAM, '(^|)' || b.con_abbrv|| '(|$)'))
and a.status = '01'
Not related, but I'd also recommend using explicit join syntax: I think you'll find it makes the query easier to read because it separates the JOIN logic from the WHERE logic:
select a.refe_id from a
join c on a.owln_code = c.code
join b on c.con_id = b.pers_id
where (:PARAM IS NULL OR regexp_like(:PARAM, '(^|)' || b.con_abbrv|| '(|$)'))
and a.status = '01'
I need help to convert the following query to Linq
SELECT c.Code, c.Name
from tblCodes as c
where c.code not in
(select Code from npConsultant where ConsultantName = 'X')
and c.Code < 'AA.0000'
When I try in Linqpad it doesn't seem to understand the into or defaultifempty. Maybe these are inproper methods for what I need to do
Simple answer is use the "let" keyword and generate a sub-query that supports your conditional set for the main entity.
var Objlist= from u in tblCodes
let ces = from ce in npConsultant
select ce.code
where !ces.Contains(u.code)
select u;
try something like that:
var query =
from c in Customers
where !(from n in npConsultant
where n.ConsultantName='X'
select n.Code)
.Contains(c.Code)
&& c.Code < 'AA.0000'
select c.Code, c.Name;
I just do not get how Code can be less than 'AA.0000' ....
I am facing some issue while joining multiple tables in oracle.
Here are the table structs:
TName : custac
acno - FK (acno custacdetails)
acbal
bid
Tname : custacdetails
custid - FK (custid custdetails)
acno - PK
actype
Tname : custdetails
custid - PK
fname
lname
Tname : branchdetails
bid
bname
I want to view all customers acno, acbal, branchname, fname, lname whose custid is 11111 and actype is 'SA'
I am using this query but i am getting wrong result
select a.acno,c.fname,c.lname,b.bname,a.acbal
from branch_details b,
custac a,
custacdetails d,
custdetails c
where c.custid=11111
and a.acno=d.acno
and a.branchid=b.bid
and actype='SA';
As per Tony891206 saying, you'Re doing a cartesian product. To avoid it, you need to tell how to join both tables together.
d.custid = c.custid
As follows:
select a.acno,c.fname,c.lname,b.bname,a.acbal
from branch_details b,
custac a,
custacdetails d,
custdetails c
where d.custid = c.custid
and c.custid=11111
and a.acno=d.acno
and a.branchid=b.bid
and actype='SA';
All credit goes to Tony891206.
This being said, as stated by a_horse_with_no_name:
Another good example why using explicit JOIN operators is better than the (outdated) implicit join in the where clause: you can't forget the join condition.
So the correct query should be written as follows.
select a.acno, c.fname, c.lname, b.bname, a.acbal
from branch_details b
join custac a on a.bid = b.bid
join custacdetails d on d.acno = a.acno
join custdetails c on c.custid = d.custid
where c.custid = 11111
and d.actype = 'SA'
This last query makes the relationship between the tables glaringly obvious, and allows for room in the where clause to specify only filter criterion.
If you want to know more about SQL syntaxes, please visit the followings:
Bad habits to kick : using old-style JOINs
Why isn't SQL ANSI-92 standard better adopted over ANSI-89?
Join (SQL)
In short, you would have had better chances to solve your problem by yourself using the SQL-92 join syntax over the SQL-89 one, since you would have had no other choice than to ask yourself how your tables may get joined together while writing the join clauses.
In addition to it, some say that there is a slight improvement on the performance using SQL-92 syntax, which I personally doubt. Besides, I do evangelize SQL-92 join syntax for it is easier to read than the SQL-89.
I know there are lots of questions like these, but my question is not how to get rid of this error but to know how this worked earlier in 9-th version of Oracle.
I've got an old sources written in Ruby and Oracle DB which recently was upgraded to version=11.
I cannot edit data in Oracle DB, only read. so there are two tables lets say: table A(id, name, type, customer) and table B(id,a_id,type,person)
so. there is a query in the source code:
select a.id,b.id from a join b on a.id = b.a_id where type = 'A'
so in Oracle 9 this worked perfectly but now i've got "column ambiguously defined" error.
What i'd like to know is:
where type = 'A'
is the same as
where a.type = 'A' AND b.type = 'A'
or
where a.type = 'A' OR b.type = 'A'
?
I think this was a bug with the ANSI style join. Use DBMS_XPLAN to find which table was being filtered in the old database.
Or better still, work out from the business logic what they query SHOULD have been.
No, and that's the problem: It could mean
where a.type = 'A'
or it could mean
where b.type = 'A'
with potentially different results; hence the error saying it is ambiguously defined.
I think you should test in Oracle 9 (where you say it works) and compare the output of the ambiguous query:
--- Base
select a.id,b.id from a join b on a.id = b.a_id where type = 'A'
with both the non-ambiguous ones:
--- QueryA
select a.id,b.id from a join b on a.id = b.a_id where a.type = 'A'
and:
--- QueryB
select a.id,b.id from a join b on a.id = b.a_id where b.type = 'A'
Something like this would do:
select a.id,b.id from a join b on a.id = b.a_id where type = 'A'
MINUS
select a.id,b.id from a join b on a.id = b.a_id where a.type = 'A'
(in short):
(Base)
MINUS
(QueryA)
and then:
(QueryA)
MINUS
(Base)
If both of the above MINUS queries return 0 rows, then BASE query is interpreted as QueryA.
Check similarly and compare Base with QueryB.
Another plausible reason for this error is that during (or about the same period with ) the migration, a type column was added in the 2nd table. Do you have old versions of the database tables' definitions to check that?
All - keep in mind there was a major change to the optimization engine for 11g. If you set your query optimizer level to 10.2.x on your 11g instance I bet the query would start working again.
That being said you should provide the alias for it so it's not ambiguous to the database server or the DBA / Developer coming behind you. :)