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
Related
I am new to plsql and trying to use oracle sql developer, I try to run a simple procedure with dbms output line and i get the following error,
ora-00904
, the code is
create or replace PROCEDURE proc_101 IS
v_string_tx VARCHAR2(256) := 'Hello World';
BEGIN
dbms_output.put_line(v_string_tx);
END;
whether i click the run(green colour) or debug(red colour) i get the same error.
You can see from the above code, procedure doesn't access any objects but still i get the same error.
Your procedure is fine. You may not have permissions to be able to Create a Procedure. If this is the case test your procedure/code without actually Creating it in the Database first. For example, when I'm testing code in my Production database my oracle user cannot Create Procedures, Packages, Tables etc... And so I test my Procedures within my Own PL/SQL Blocks. When the code is good to go I can get a database administrator to Create the Procedures and/or Packages for me.
The below screenshot is code that simply tests the Procedure:
The below screenshot is code that does much more and tests the Procedure from within a PL/SQL Block
For more advanced situations this allows you to do so much more as you can create all sorts of Procedures/Functions and/or Cursors and test them immediately without needing to CREATE these objects in your Oracle Database.
I'd say that there's some other code in the worksheet which raises that error, not just the CREATE PROCEDURE you posted. For example, something like this SQL*Plus example (just to show what's going on - you'd get the same result in SQL Developer):
SQL> select pixie from dual;
select pixie from dual
*
ERROR at line 1:
ORA-00904: "PIXIE": invalid identifier
SQL>
SQL> create or replace PROCEDURE proc_101 IS
2 v_string_tx VARCHAR2(256) := 'Hello World';
3 BEGIN
4 dbms_output.put_line(v_string_tx);
5 END;
6 /
Procedure created.
SQL>
See? The first part raised ORA-00904 as there's no PIXIE column in DUAL, while the procedure is created correctly.
So - remove code which fails and everything should be OK.
Check with your DBA to make sure the dbms_output package has been installed on your database, and that you have permissions on it.
We have a Java app that will remotely query all the SQL files in a directory and output the CSV files. It works great if the SQL files have just the SELECT command. However, in order to get the datetimes in the right format, I want to use the ALTER session command. This produces an error in the Java app as it treats each command as a new file. Unfortunately, I don't have access to the code base of the Java app. Essentially, the SQL files each look like the following:
alter session set nls_date_format = 'yyyy-mm-dd hh24:mi:ss';
SELECT * from sample_table
Is there any way to run the edit a SQL file to run as a single executed query?
alter session set nls_date_format = 'yyyy-mm-dd hh24:mi:ss'; is a DDL statement. You cannot execute that as a DML statement. Your Java Statement class won't work to execute this ALTER SESSION ... query.
Moreover, if talking from the Database connection perspective, it is valid only up to that session in which it is applied, next time it won't hold still the same value.
This change can't be made permanently using this approach, there is a different approach, which is off-topic here (I know because once I also felt the same need, but came to know the things after struggling for a few days).
The way how you're trying to achieve your result is incorrect.
Format the content into whatever format you want your date-time to be displayed in, you don't need an ALTER SESSION command alongwith a SELECT query.
Use to_char(yourDate, 'YYYY-MM-DD HH24:MI:SS') as customDate and try adjusting to your main select query.
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 seen people use GO statement between batches of SQL code, but AFAICS it is not mandatory (SQL Server 2008). What are the benefits using GO statements between batches/sets of SQL statements?
They're not strictly required - they're just instructions for the SQL Server Management Studio to execute the statements up to this point now and then keep on going. GO is not a T-SQL keyword or anything - it's just an instruction that works in SSMS.
Sometimes, you need a GO - e.g. if you add a column to a table, and then want to select it again, you need to have a GO between the adding of the column, and the query of it.
E.g. if you try to execute this, you'll get errors from SSMS:
ALTER TABLE (sometable) ADD DateTimeStamp DATETIME
SELECT ID, DateTimeStamp FROM (sometable) WHERE ID > 5
Results in:
Msg 207, Level 16, State 1, Line 9
Invalid column name 'datetimestamp'.
The point is: SSMS is trying to verify the whole statement at once, but on the SELECT statement, it will complain about the missing DateTimeStamp column.
ALTER TABLE (sometable) ADD DateTimeStamp DATETIME
GO
SELECT ID, DateTimeStamp FROM (sometable) WHERE ID > 5
If you put a GO between the two statements, it'll work, because SSMS won't parse and verify the whole statement ahead of time - it will do the first part, and then only parse the second (after the GO).
But other than situations like this one, GO is hardly ever required.
It's only mandatory in SQL tools to tell SSMS where the batch start and end is. It's also required for some statements such as CREATE TRIGGER which must the first in the batch
For example, in a c# to SQL Server call it has no meaning
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.