I am using oracle report and have problem with "SELECT ALL" here is my query
SELECT * FROM company A, seller B
WHERE a.id = b.id
&(P)Company_id
and in my after parameter in oracle report i use
begin
if (:(V)Company_id is not null and :(V)Company_id<> '0')
:(P)Company_id:= ' and a.id ='||:(V)Company_id;
end if;
return (true)`
end;
if the id is all digit like 000123 works fine, but if id like ([L]00123) the result is show all data. need help with my lexical parameter.
Information you post is misleading. I've been using Oracle Reports for ages, and I've never seen syntax you use. Code you wrote doesn't even compile; how would it work, then (which is what you claim)? There's no (V)something syntax at all.
Anyway, from my point of view, you don't need a lexical parameter but a simple OR condition, e.g.
select *
from company a join seller b on b.id = a.id
where (a.id = :par_company_id or :par_company_id is null)
the first part of it, a.id = :par_company_id will return rows whose ID is equal to value you enter in the parameter form
the second part, or :par_company_id is null will return all rows if you leave the parameter value empty
I would have thought you'd get an error from that rather than all data, but maybe Reports does something weird in that scenario. Anyway, it looks like you just need to enclose the passed-in value in single quotes, which you will need to escape; so instead of this line:
:(P)Company_id:= ' and a.id ='||:(V)Company_id;
use:
:(P)Company_id:= ' and a.id = ''' || :(V)Company_id || '''';
although it would be better if you could keep it as a bind variable. I'm not familiar with Reports but something like this might work:
select *
from company A
join seller B
on a.id = b.id
where &(V)Company_id is null or a.id = &(V)Company_id
(I've switched to ANSI join syntax as well...)
Related
I am trying to assing a result to a local variable in stored procedure sql.
For example
Select c.parm_val from Cusomter.name c where c.id = '102';
The above query gives me a result like 36,1508,4399,4403,4405,4407,4409,4411,4419
I want to assign it to a local variable
So I created in stored procedure like below
DECLARE
values VARCHAR2(500 BYTE);
BEGIN
Select into values c.parm_val from Cusomter.name c where c.id = '102';
END
When I execute this I get different errors each time
Something like PL/SQL: ORA-00936: missing expression
I want to assign those result a variable. I don't know if I can use INSERT as it not a table.
Can someone help me how to assign it to a variable.
I'm not sure about the syntax you are using. The FROM clause requires a table name like Customer, not Customer.name, which seems to be a column.
Starting with 11g Release 2 you can use the LISTAGG function to concatenate a column from the result rows into a single string.
SELECT LISTAGG(c.name, ',') WITHIN GROUP (ORDER BY c.name) INTO "values"
FROM Customer c
WHERE c.id = '102';
If c.id has a numeric type, drop the quotes: WHERE c.id = 102.
According to your comment, you probably want something like
SELECT c.name INTO "values"
FROM Customer c
WHERE c.id = '102';
See: PL/SQL SELECT INTO
Also, VALUES is a reserved word in SQL. Therefore, either choose another name, or escape it as "values" (in the declaration as well).
INTO comes after the field list:
Select c.parm_val into values from Cusomter.name c where c.id = '102';
Below is is some Oracle PL/SQL code to join tables without using actual JOIN keywords. This looks like a cross join? How would I convert to Netezza SQL code? That's where I'm stuck.
SELECT COUNT(*)
FROM TABLE_A A, TABLE_A B
WHERE A.X = 'Y' AND A.PATH LIKE '/A/A/A'
AND B.X = 'Z' AND B.PATH LIKE '/B/B/B';
Oracle Cross Join:
http://www.sqlguides.com/sql_cross_join.php
Here's what I tried so far:
SELECT *
from TABLE_A A
cross join (
select * from TABLE_A
) B
WHERE
A.X = 'Y' AND A.PATH LIKE '/A/A/A'
AND B.X = 'Z' AND B.PATH LIKE '/B/B/B';
EDIT:
a_horse_with_no_name:
When I use either syntax in Netezza for the COUNT(*) in the very beginning, it works and returns a count of 60, which matches the first query above when running in Oracle. Without the WHERE clause in Netezza returns 125316 results, which matches the first query above when running in Oracle. When I use either syntax in Netezza for the SELECT * in the very beginning, I get error
ERROR [HY000] ERROR: Record size 70418 exceeds internal limit of 65535 bytes'
Had to use explicit columns in Netezza when doing a CROSS JOIN. Using SELECT * throws the error as indicated in my question EDIT. Also had to escape the '%' character by escaping nothing. Thank you a_horse_with_no_name. Cheers! "Where everybody knows your name." ;-)
select A.CODE, B.CODE, LOWER(A.DIM), LOWER(B.DIM)
FROM TABLE_A A
cross join TABLE_A B
WHERE A.PATH LIKE '\A\A\A%' ESCAPE '' AND A.X = 'Y'
AND B.PATH LIKE '\B\B\B%' ESCAPE '' AND B.X = 'Y'
I am trying to execute a sql script from file using ScriptUtils.readScript method:
sql = ScriptUtils.readScript(fileReader,
ScriptUtils.DEFAULT_COMMENT_PREFIX,
ScriptUtils.DEFAULT_STATEMENT_SEPARATOR);
getJdbcTemplate().update(sql);
But I get the error org.springframework.jdbc.BadSqlGrammarException: StatementCallback; bad SQL grammar and from the logs I see that semicolon * in the sql statement is not ignored even I am using ScriptUtils.DEFAULT_STATEMENT_SEPARATOR why it isn't working? What's wrong here?
Edit: I know that I can solve this by using:
getJdbcTemplate().update(sql.replace(";", ""));
but maybe there is another solution?
Edit2: Here is example of sql that I need to execute:
INSERT
INTO MYTABLE
(
ID,
MYNUMBER,
MYVALUE
)
SELECT
ID,
0,
B.MYVALUE
FROM ATABLE A,
BTABLE B
WHERE A.ID = B.ID
AND NOT EXISTS
(SELECT 1 FROM MYTABLE M WHERE M.ID = A.ID
);
I don't think you're using ScriptUtils.readScript the right way. The javadocs themselves state:
Mainly for internal use within the framework.
Looking at the source code, it seems that all this function does is load all the lines from a file into a single string, with some logic around comments. The use of the separator in this method is minor and appears only to be relevant if there is a whitespace at the end of it.
If you want to ignore the separator, you'll need to remove it the way that you suggested (with a replace).
I dont want to use the "loop" related keyword, how can I implement loop with basic sql command in oracle ?
I have two table :
A:
ID, Color
B,
ID, AID, Type
I want to loop all records in B, and if ID = AID, then set the A.Color = B.Type
Thanks in advance !
Looping is, by definition, a procedural construct.
SQL is declarative: tell the database what you want done, not how to do it.
If you're absolutely convinced that you need to program such a thing, then write it in PL/SQL, Oracle's procedural language.
Bu I'm sure that it's possible to do what you want in SQL using an UPDATE with a WHERE clause.
Something like this (corrected per NullUserException):
UPDATE A SET A.Color = (SELECT B.Type FROM B WHERE A.ID = B.AID)
An alternate method:
MERGE INTO a
USING b
ON (b.aid = a.id)
WHEN MATCHED THEN UPDATE SET a.color = b.type;
You could just do:
UPDATE tablea a
SET a.color = (SELECT b.type
FROM tableb b
WHERE b.aid = a.id)
See this SQL script.
To do that you will have to write a stored procedure using PL/SQL. Here is the oracle page with some info and papers on the topic.
As others pointed out, you can probably solve your problem with a normal DML statement, without any looping involved. But to give you some basics on how to accomplish what you asked for in PL/SQL, here's an example...
DECLARE
CURSOR c IS
SELECT id, aid, type FROM b;
statement VARCHAR2(200);
BEGIN
FOR iterator IN c LOOP
IF iterator.id = iterator.aid THEN
statement := 'UPDATE a SET color = ' || iterator.type || 'WHERE id = ' || iterator.id;
EXECUTE IMMEDIATE statement;
END IF;
END LOOP;
END;
This anonymous PL/SQL block will iterate through each record in table b, and if b.id = b.aid, it will update table a and set a.color = b.type where a.id = b.id.
This seems to be what you were asking for. It's not exactly an efficient way to go about doing things, since you're firing off one DML statement per row in table b that has b.id=b.aid. But I wanted more to give this as a syntax example. This is just one way to iterate through a cursor by the way; you can also explicitly open cursors and fetch records, but it's easier this way if you don't need to do anything but iterate over the entire result set.
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. :)