alternative for alter session set week_start in snowflake - session

I need to set week start from sunday as default in snowflake
i used
alter session set WEEK_START = 7;
when querying in snowflake worksheet it works fine but when using the same query via api it has no effect.
is there any way to set WEEK_START from sunday without using alter session.
thanks in advance..

You could submit multipe statements per request:
Specifying Multiple SQL Statements in the Request and separate them with semicolon.
alter session set WEEK_START = 7; SELECT DAYOFWEEK()
is there any way to set WEEK_START from sunday without using alter session.
Setting the parameter on USER level that is used for making the API call.
ALTER USER <user_name_here> SET WEEK_START = 7;
Related Parameter Hierarchy and Types

Try using EXECUTE AS CALLER in SP.

Related

Oracle 12c - Find if temporary objects created before TEMP_UNDO_ENABLED is set

Database : Oracle 12c (12.1.0.2) - Enterprise Edition with RAC
I'm trying to reduce REDO and archive logs generated for my application and measure using V$SYSSTAT and corresponding archive logs using DBA_HIST* views.
In my application code on DB side, I'm using the session level setting of TEMP_UNDO_ENABLED to direct UNDO for gtt into temporary tablespace. The specific feature noted here.
ALTER SESSION SET TEMP_UNDO_ENABLED = TRUE;
INSERT INTO my_gtt VALUES...
Note the documentation has this quote:
..if the session already has temporary objects using regular undo, setting this parameter will have no effect
If I use a pure database session, I can ascertain that since no other temporary tables have been created/used before setting the parameter, the REDO logs generated are minimal. I can use a simple (select value from V$SYSSTAT where name= 'redo size') to see the difference.
However the actual application (Java) triggers this code through a JDBC session. As such, I'm unable to ascertain if before the call to 'ALTER SESSION..' there were any GTT or other temporary objects previously created/used in the session. The consequence of this is, if say a GTT was already used, then the call to 'ALTER SESSION SET TEMP_UNDO_ENABLED = TRUE' simply ignores the setting without an indication. The code will continue logging UNDO & REDO in the normal tablespace, which is unintended.
Is there any way to query if this parameter TEMP_UNDO_ENABLED is already set/unset within the session, so that before I do a ALTER SESSION SET TEMP_UNDO_ENABLED = TRUE I'll know for sure this will or will not have an effect?
Thanks in advance for inputs.
There is no holistic way to do this satisfying all cases. Posting some options I got as answer elsewhere:
Assumptions :
Both options work only if:
Only GTT is concerned (excluding WITH and other temporary objects)
COMMIT/ROLLBACK has not already been done including from SAVEPOINTS
or other methods
Option 1 : Use v$tempseg_usage, to check if any segment created in DATA, instead of TEMP_UNDO
select count(*)
from v$tempseg_usage
where contents = 'TEMPORARY'
and segtype = 'DATA'
and session_addr =
(select saddr
from v$session
where sid = sys_context('userenv', 'sid'));
Option 2 : Use gv$transaction as below, ubafil = 0 if for temp_undo, else ubafil = undo tablespace file id:
select count(*)
from gv$transaction
where ses_addr = (select saddr
from v$session
where sid = sys_context('userenv', 'sid'))
and ubafil <> 0;
On other note for thought, I still think, there should have been a parameter or an indication elsewhere that simply indicates the setting of TEMP_UNDO_ENABLED has not had an effect, within the scope of a SESSION, not having to touch views that would otherwise be considered as administrative.
I'm open to answers if someone finds a better approach.
Although this does not answer your question directly but this link may help you.
In 12c temporary undo concept has been added
" Oracle 12c introduced the concept of Temporary Undo, allowing the
undo for a GTT to be written to the temporary tablespace, thereby
reducing undo and redo."

Setting NLS_DATE_FORMAT on Adminer

I am using Adminer 4.7.3 connecting to an oracle DB and I want to display dates in a different format from what the default is ('DD-MON-YY'). I tried using the command
ALTER SESSION SET NLS_DATE_FORMAT = 'DD-MON-YYYY HH:MI:SS' but it only lasts for that query, and it goes back to the old date format once I open the table again. Is there a better way to force the date to show up in a different format?
You have a few options. First, you can perform an
ALTER SESSION SET NLS_DATE_FORMAT = 'DD-MON-YYYY HH:MI:SS'
every time you log on. If you don't want to do this you can:
If you're using *nix:
setenv NLS_DATE_FORMAT "dd-mon-yyyy hh:mi:ss"
If you're using Windows:
Control Panel-System-Advanced System Settings-Environment Variables, and create the NLS_DATE_FORMAT environment variable with the appropriate setting.
If you want an entirely database-dependent solution, you can use an ON LOGON trigger similar to the following:
CREATE OR REPLACE TRIGGER DATABASE_AFTER_LOGON
AFTER LOGON
ON DATABASE
BEGIN
EXECUTE IMMEDIATE 'ALTER SESSION SET NLS_DATE_FORMAT = ''DD-MON-YYYY HH:MI:SS''';
END DATABASE_AFTER_LOGON;

How do I change the default NLS parameters for date format through Toad?

I have a NLS date format as DD-MON-RR. This gives me the underlying date format as YY while I want to change it to YYYY. I tried using the following query and it ran successfully
DECLARE
v_date DATE := sysdate;
BEGIN
DBMS_OUTPUT.put_line(TO_CHAR(v_date, 'MM/DD/YYYY'));
END;
But that didn't change the default format.
for some context, I am trying to import data from Oracle to Tableau. Unfortunately when I try to export a crosstab from Tableau server it looks at the underlying data rather than whats on the view. This causes the date that I have as 25-Jun-2017 to change to 25-Jun-17 in the excel.
The only workaround I have been able to understand is to change the default format of the underlying/source data which in this case is Oracle DB.
I am using TOAD and am trying to understand how can I change it to possibly DD/MON/RRRR format or something similar with 4 digits in the year column.
Any workaround is also appreciated
As already given in other answers you can set NLS_DATE_FORMAT by ALTER SESSION.
In order to set it only for you local PC, open Registry Editor and navigate to HKLM\SOFTWARE\Wow6432Node\ORACLE\KEY_%ORACLE_HOME_NAME%, resp. HKLM\SOFTWARE\ORACLE\KEY_%ORACLE_HOME_NAME%.
There you can add a String Value NLS_DATE_FORMAT, for example:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_OraClient11g_home1]
"NLS_TIMESTAMP_FORMAT"="YYYY-MM-DD HH24:MI:SSfmXFF3"
"NLS_TIMESTAMP_TZ_FORMAT"="YYYY-MM-DD HH24:MI:SSfmXFF3 fmTZH:TZM"
"NLS_DATE_FORMAT"="YYYY-MM-DD HH24:MI:SS"
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ORACLE\KEY_OraClient11g_home1]
"NLS_TIMESTAMP_FORMAT"="YYYY-MM-DD HH24:MI:SSfmXFF3"
"NLS_TIMESTAMP_TZ_FORMAT"="YYYY-MM-DD HH24:MI:SSfmXFF3 fmTZH:TZM"
"NLS_DATE_FORMAT"="YYYY-MM-DD HH24:MI:SS"
You can set NLS_DATE_FORMAT also as an Environment Variable in Windows Settings.
alter session set nls_date_format='DD/MON/RRRR' programmatically in the application or
CREATE OR REPLACE TRIGGER trg_after_logon AFTER LOGON ON DATABASE
BEGIN
execute immediate 'alter session set NLS_DATE_FORMAT=''DD/MON/RRRR''';
END;
in system or sys schema.
Alternatively, you may use
alter system set NLS_DATE_FORMAT='DD/MON/RRRR' scope = both
provided you're in system or sys, again.
Manage your date format masking using the most reasonable approach
First of all, I agree with Alex regarding using to_char. This would be my first choice for modifying date masks for specific requirements.
In Toad on an ad hoc basis, you could just invoke the alter session command as needed:
ALTER SESSION SET nls_date_format='DD/MON/RRRR';
If you are partial to a specific date format mask (and you see yourself often issuing the command, ALTER SESSION SET NLS...) then perhaps you might want to consider changing your user login settings.
If you just modify your specific user preference login file, login.sql (see here ), your session will adhere to the date format mask of your choosing at the beginning of your session. I am partial to creating the environment variable, SQLPATH, and placing my login script there.
Toad will honor your login.sql file settings (e.g. see this post).
Since this is driven by specific requirements or personal preferences, I would never think of modifying this from default at the site level.

Dynamic Schema name in SQL based on database-name Oracle

I have a DML statement "Simple update statement" that i need to execute in Different Oracle Environment (DEV,SIT,QA,PROD). As of Now im hard coding the Schema Name in Alter Session Command and Running the DML statement. So i need to maintain 4 different scripts across the environment.
Is there a way i can get the Database name on which the script is Running, from the database Name i can use If Else Condition to Choose between the Schema and assign it to the ALTER SESSION COMMAND?
You can query the name from the v$database view. How you translate that to an alter session command depends on your client and how you're connecting.
For example, in SQL*Plus you could do:
column x_schema new_value y_schema noprint
set termout off
select case name
when 'DEVDB' then 'DEVSCHEMA'
when 'PRODDB' then 'PRODSCHEMA'
...
end as x_schema
from v$database;
alter session set current_schema = &y_schema;
set termout on
The first query uses the DB name to determine a schema name; the column command makes that column alias x_schema available later as substitution variable &y_schema. Then that is used in the alter. The set termout is optional but will hide the query if it's run as part of a script (though then I guess the noprint is a bit pointless).
You could base your case on global_name.global_name if you prefer, or even sys_context('USERENV', 'SERVICE_NAME').
Of course, you could also just pass the schema name in as a positional parameter when you run the DML script instead. It's unusual, I think, for the schema name to be different for the same application in different databases, but this should work if that is the situation you have.
To get the current schema name:
select user from dual
Is this what you're after?

Unable to insert date and time when using date datatype

I am hitting a bit of a problem when using the date datatype. When trying to save a row to the table where the field it throws an error ora 01830 and complains about converting the date format picture ends...etc. Now when I do the insert, I use the to_date function with the format of "dd-mon-yyyy hh24:mi:ss". Of course, when I remove the time element, everything is perfect.
Checking sysdate, I noticed that the time element wasn't be displayed, and I used alter session set nls_date_format to set the date and time I want to save to the table, which worked!
I used alter system set nls_date_format ="dd-mon-yyyy hh24:mi:ss" scope=spfile; This showed that it was altered, and I can see the setting in the enterprise management console. In sqlplus, I shutdown the database, and restarted with startup mount; alter database open; and then selecting sysdate, it still shows the date as dd-mon-yy, and still no time! Checking the enterprise management, and looking up the nls_date_format the setting is still shown as "dd-mon-yyyy hh24:mi:ss".
So, my question is this - what am I doing wrong? Why can't save date and time using date in Oracle 11g?????
Thanks
Dates are stored with "second" granularity in Oracle.
Display formats are dependent on the system and session. In your case, since you are connecting with sqlplus, you are using a default session format from the client that does not include time. You need to execute an:
ALTER SESSION SET nls_date_format ="dd-mon-yyyy hh24:mi:ss";
when you start up your sqlplus client in order to change the default display. There is a client side file (glogin.sql?) that sqlplus will run on startup. You can place this kind of command in there if you want it to be executed each you start that client. I'm pretty sure the sqlplus client sends an "alter session set nls_date..." on start up.
In general, when outputting dates, I think it is better to just be explicit on the format by doing a TO_CHAR(myDateColumn, "dd-mon-yyyy hh24:mi:ss"). If you are reading dates programatically, you don't need to worry about it since you are dealing with internal formats, not display formats.
I've seen this error when the input data did not match the date format used. check your, data would be my suggestion.

Resources