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:
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
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.
Suppose I have a query:
SELECT * from table1 tr where tr.start_time < &&starttime;
First time i execute the query, SQL Developer prompts me to enter the value for the substitution variable 'starttime' and is stored. Next time I run the script, it reuses the same value again, how do I reset/clear the stored value?
UNDEFINE starttime;
Just use above command.
Just use one ampersand at the start. You will be prompted to enter the value fresh. See the difference between & and &&
You can try these commands:
select &&v_value from table_name;
undefine v_value;
Is there a way to show the results of DDL statements such as CREATE/ALTER; after they are "run" in the query window?
By default it just shows "command(s) completed".
Is there a way to see something similar to the results Oracle shows from the same commands?
"command(s) completed" after a create table command is very similar to 'table created' oracle sql*plus message.
If you need a desc my_table you can execute sp_help my_table
Built-in? No, not that I know of. But you can easily do this with a SELECT to the respective catalog view to verify what you've just done. Something like this would work:
create login SomeTestLogin with password = 'password'
go
select *
from sys.server_principals
where name = 'SomeTestLogin'
go
You can also use sp_helptext my_sp for describe stored procedure, function, or view
i want to check select statement(string) is valid or not in c#.net, if select statement is right then retrieve data and fill dropdown list box else drop down should be empty
How often would the select statement be invalid? Seems like a simple try/catch block around the execution of the SQL might be sufficient.
As an aside, I hope you aren't making an app that would allow someone to type in arbitrary SQL into a box which you would then execute...
One approach which covers most scenarios is to execute the SQL with SET FMTONLY ON
e.g.
SET FMTONLY ON;
SELECT SomeField FROM ExampleQuery
From BOL, SET FMTONLY :
Returns only metadata to the client.
Can be used to test the format of the
response without actually running the
query.query.
That will error if the query is invalid. You can also check the result to determine what the schema of the resultset that is returned would be (i.e. no schema = not a SELECT statement).
Update:
In general terms when dealing with SQL that you want to protect against SQL injection there are other things you should be thinking about:
Avoid dynamic sql (concatenating user-entered values into an SQL string to be executed). Use parameterised SQL instead.
Encapsulate the query as a nested query. e.g.
SELECT * FROM (SELECT Something FROM ADynamicQueryThatsBeenGenerated) x
So if the query contains multiple commands, this would result in an error. i.e. this would result in an invalid query when encapsulated as a nested query:
SELECT SomethingFrom FROM MyTable;TRUNCATE TABLE MyTable