I am using Oracle SQL Developer.
I am using parameters &TableName
My query comes back to me in the results with an OLD: tag before it, and again with a New: tag (the variable is replaced with the value that I have typed in) and then my results follow this.
How do I get rid of this annoying return and change it to just display my results?
In SQL*Plus I think you mean SET VERIFY OFF. I don't have SQL Developer to hand to check it's the same but I'd imagine so.
Edited to add example and confirm it does work in SQL Developer too.
define tmpVar='test'
set verify on
select '&tmpVar' from dual;
set verify off
select '&tmpVar' from dual;
which produces:
old:select '&tmpVar' from dual
new:select 'test' from dual
'TEST'
------
test
'TEST'
------
test
The link #a_horse_with_no_name provided shows this too.
Related
I have an ETL process which executes dozens of SQL query tasks.
One specifically keeps throwing an error: "ORA-01843: not a valid month" to one of my queries, however the very same query runs normally on PL/SQL. I have even created a procedure with a version of the same query, it also runs smoothly, but calling this procedure from pentaho keeps throwing the same error. Please, anyone have any idea why is pentaho presenting a query error that PL/SQL is not? Thanks in advance!
If you do:
SELECT TO_DATE('01-FEB-03', 'DD-MON-RR') FROM DUAL;
Then, on an English database with the default settings, the query works
Then you change your session settings:
ALTER SESSION SET NLS_DATE_LANGUAGE = 'FRENCH';
ALTER SESSION SET NLS_DATE_FORMAT = 'DD-MON-RR';
And run the same query:
SELECT TO_DATE('01-FEB-03', 'DD-MON-RR') FROM DUAL;
You will get the error:
ORA-01843: not a valid month
There are three solutions to this:
Use the same settings for both queries - this is not a robust solution as you may specify the settings for some services and then it works for a while but then a new developer comes along and connects a new service and does not know of the required settings and suddenly everything is breaking.
Specify the settings to use in the query.
SELECT TO_DATE(
'01-FEB-03',
'DD-MON-RR', -- Specify the format
'NLS_DATE_LANGUAGE=English' -- Specify the language
)
FROM DUAL;
Use a date literal (which is agnostic of the settings):
SELECT DATE '2003-02-01' FROM DUAL;
db<>fiddle here
In SQL Developer,
I want to call a script like this:
#"path\to\script.sql" develop
and use the value develop in my script as a table prefix like this:
SELECT * FROM <parameter>_table; which should then evaluate to SELECT * FROM develop_table
Is something like this possible in SQL Developer?
See the article below. It will answer your question.
https://blogs.oracle.com/opal/sqlplus-101-substitution-variables#2_7
I'll make an example for you, based off that blog article.
Creating a dummy table:
CREATE TABLE t(x NUMBER, t VARCHAR2(255));
INSERT INTO t(x, t) VALUES (1, 'Example');
COMMIT;
The script below has been saved in C:\Users\William. The filename is example.sql.
SELECT *
FROM &1
;
Now, from SQL Developer, I execute:
#C:\Users\William\example.sql t
Note that when you pass a parameter to a script like this, you are passing the text value that is stored in implicitly-named substitution variables. The substitution variable is named according to its order (e.g., &1 then &2 then &3 etc.).
This is the script output:
old:SELECT *
FROM &1
new:SELECT *
FROM t
X T
-- ----------
1 Example
You should probably take some time to consider other solutions to the problem you are solving. You may not need to execute a script via SQL developer. Perhaps you'd be better off creating a procedure that generates dynamic SQL, based off parameters you feed to the procedure. You would then use EXECUTE IMMEDIATE on the dynamic SQL statement inside the procedure.
I personally might find that technique more useful when performing actions like ETL (as opposed to queries). Then again, I'm no expert, and there're probably even better solutions out there.
I'm a bit confused by the stored procedure syntax in Oracle.
I started with a simple:
select * from test_table;
It works, then I put it in a proc:
CREATE OR REPLACE PROCEDURE example
IS
BEGIN
select * from test_table;
END;
Doesn't work. Expected "INTO" is the error message I get. Now, I've seen syntax examples of SQL Server code that just shoves a select statement into a proc and it works instantly, but that doesn't seem to be the case here.
T-SQL and PL/SQL are completely different languages. In particular, for PL/SQL you have to select the result into some variable or cursor. Depending on what you plan to do with the record data - process in the procedure - or return to the caller, will drive what you have to do.
In your example, if you want to return the record set, you would do something like this:
CREATE OR REPLACE PROCEDURE example (
p_recordset OUT SYS_REFCURSOR) AS
BEGIN
OPEN p_recordset FOR
select * from test_table;
END example ;
See this link for examples.
Hello and welcome to SO.
I assume the full error you're seeing would be PLS-00428: an INTO clause is expected in this SELECT statement and it is correct, you must have an INTO statement in a stored procedure.
I recommend this link for syntax relating to the SELECT INTO statement.
For your code I recommend this (I've changed from your test_table example to dba_user):
CREATE OR REPLACE PROCEDURE example
IS
l_username VARCHAR(25);
BEGIN
select username INTO l_username from dba_users where user_id=1;
END;
/
Note: The INTO clause works with 1 column from 1 row. You cannot select multiple records or columns into this. You would need to reference the BULK COLLECT feature to do that. For examples of that feel free to read here.
select * from test_table;
SQL and PL/SQL are nor the same. To execute a SQL in a procedure, the parser expects an INTO clause to store the value returned by the sql statement. In PL/SQL, there is a reason to execute a SQL statement. You want to use the result set later to process. Not just retrieve and do nothing.
Also, it is a bad idea to use select * in any production system. You don't want to dump all the columns data of the table on an application screen. There are many other reasons, however, not in the scope of this question.
You need to modify your SQL like following -
SELECT column_name INTO variable FROM table_name
There are several ways to fetch the data via SQL statement in PL/SQL. You need to elaborate your requirement and narrow down to specific steps here.
If you are learning about these concepts, I would recommend you to start reading the Oracle documentation first. Try and understand the concepts, and if you find any issues, then prepare a test case, explain your issue in words and then post a question. Too broad questions are difficult to answer, and are mostly considered out of scope.
When I do a query SELECT t.NAME, t.SOME_DATE FROM MY_TABLE t in toad I get dates as 14-FEB-13 with no time information! In the table browser it gives full date and time. How can this be changed?
That is the default setting for a session. If you want to change it,
ALTER SESSION SET NLS_DATE_FORMAT='DD-MON-YYYY HH24:MI:SS';
Or, change your query to
SELECT t.NAME, to_char(t.SOME_DATE,'DD-MON-YYYY HH24:MI:SS') FROM MY_TABLE t
( the above is just an example, you can format whatever way you want in the format string, ie. 'MM/DD/YYYY, etc.)
If you want to see the same results as you see in the table browser when executing SQL directly (without changing your settings), use "Editor\Execute Statement (F9)" instead of "Editor\Execute as Script".
"Execute statement" displays data in a Toad grid, so the formatting will always be the same as the formatting you see in the table browser, while "Execute script" uses your session information, as explained in OldProgrammer's answer.
Execute statement:
Execute script:
I have a cursor which returns two values: one which I will use (and therefore will assign to an out variable) and another which I've only had returned to make the ROWNUM thing work.
If I run the cursor as a query, it works as expected. But if I execute the procedure the out variable comes empty. Is my approach somehow not supported? I mean, returning two values but only using one of them?
Here is my procedure code: (Don't delve too much on the query itself. It works, I know it's a bit ugly but it works. It was the only way I found to return the second-last row)
procedure retorna_infos_tabela_164(i_nip in varchar,
o_CODSDPANTERIOR out number) is
cursor c_tabela_164 is
select *
from(
select CODSDP,ROWNUM rn
from
(
select NRONIP,CODTIPOMOV,CODSDP
from TB164_HISTORICOMOVIMENTACOES
where NRONIP = i_nip and
CODTIPOMOV='S1'
order by DTHMOV desc
)
)
where rn=2;
v_temp_nr number;
begin
open c_tabela_164;
fetch c_tabela_164 into o_CODSDPANTERIOR,v_temp_nr;
close c_tabela_164;
end retorna_infos_tabela_164;
EDIT The way I've tried to run this procedure was by dbms_output.put_line(o_CODSDPANTERIOR) which didn't work. Then I googled a little bit and saw I should TO_CHAR() my var first and then have it output. Didn't work either.
There's no problem with passing a number to DBMS_OUTPUT.PUT_LINE. Oracle will silently convert other built-in types to VARCHAR2 using the default format. You only need to use TO_CHAR if you want to control the format used -- which is often a good idea, but not generally necessary.
One possibility, though, is that you are not seeing the output because you have not enabled it. If you are running your test in SQLPlus, make sure you SET SERVEROUTPUT ON before running code that includes DBMS_OUTPUT calls. If you are using some other client, consult its documentation for the proper way to enable DBMS_OUTPUT. (You can of course test if it's enabled by adding another call to output a string literal.)
There's nothing inherently wrong with the technique you're using to populate the out parameter. However, it's not necessary to return two columns from the cursor; your select * could simply be select CODSDP. You seem to be under the misconception that any column referenced in the predicates has to be in the select list, but that's not the case. In your innermost query, the select list does not need to include NRONIP or CODTIPOMOV, because they are not referenced in the outer blocks; the WHERE clause in that query can reference any column in the table, regardless of whether it is in the select list.
So, my first guess is that you simply don't have server output enabled. The only other possibility I can think of right now is that you're running your query and the procedure in two different sessions, and one of them has uncommitted transaction against the table, so they are actually seeing different data.
If those suggestions don't seem to be the problem, I'd suggest you run your tests of the standalone query and the procedure in a single SQLPlus session, then copy and paste the entire session here, so we can see exactly what you're doing.
I'm sorry I've had you guys take the time to answer me when the answer was something to do with the tool I'm using. I hope all you guys have learnt something.
The query does work for me at least, I've not come across any edge cases where it doesn't work, but I haven't tested it exhaustively.
The problem was that TOAD, the tool I'm using to run the procedures, sometimes populates the procedures with the parameters I tell it to but sometimes it doesn't. The issue here was that I was trying to execute the procedure with no parameters, yielding no results...
Lesson Learnt: double check the generated procedure code when you run a Procedure using Right Click > Run Procedure on TOAD version 9.