I have a timestamp that looks like this:
2022-01-02T12:30:30.471395746-06
I tried running the following code:
alter session set timestamp_input_format = 'AUTO';
select s.$1, s.$2, to_timestamp_tz(s.$3), s.$4, s.$5
from #my_stage s limit 10;
This gives me an error saying:
Timestamp '2022-01-02T12:30:30.471395746-06' is not recognized
I also tried setting the format to
alter session set timestamp_input_format = 'YYYY-MM-DD"T"HH24:MI:SS.FF9';
alter session set timestamp_output_format = 'YYYY-MM-DD"T"HH24:MI:SS.FF9';
which did not work. Any suggestion would be appreicated!
You are missing the timezone part at the end, it should be specified in the timestamp format as TZH in your case.
The following should work:
alter session set timestamp_input_format = 'YYYY-MM-DDTHH24:MI:SS.FF9TZH';
or
select to_timestamp_tz('2022-01-02T12:30:30.471395746-06', 'YYYY-MM-DDTHH24:MI:SS.FF9TZH');
Output:
2022-01-02T12:30:30.471395746-06:00
Related
I need your small help. I have to use to_date('24-03-20','DD-MM-RR') Oracle function in snowflake. Both output should be matching. Could anyone please help me.
Be careful with YY, as RR in Oracle behaved differently than Snowflake's YY. RR in Oracle basically made two digit years into a "closest to the year 2000" model, e.g. RR string of 49 gave you 2049, RR string of 51 gave you 1951.
If you need RR "functionality", see the reference to the TWO_DIGIT_CENTURY_START session parameter at this link:
https://docs.snowflake.com/en/sql-reference/functions-conversion.html#date-and-time-formats-in-conversion-functions
That parameter is further defined here:
https://docs.snowflake.com/en/sql-reference/parameters.html#label-two-digit-century-start
So, you could use YY, but you'll need to run an ALTER SESSION command before you execute your select, examples as follows:
ALTER SESSION SET TWO_DIGIT_CENTURY_START = 1970; --the default
SELECT to_date('24-03-20', 'DD-MM-YY'); --2020-03-24
ALTER SESSION SET TWO_DIGIT_CENTURY_START = 1900; --not what you want
SELECT to_date('24-03-20', 'DD-MM-YY'); --1920-03-24
ALTER SESSION SET TWO_DIGIT_CENTURY_START = 1950; --RR like
SELECT to_date('24-03-20', 'DD-MM-YY'); --2020-03-24
SELECT to_date('24-03-49', 'DD-MM-YY'); --2049-03-24
SELECT to_date('24-03-50', 'DD-MM-YY'); --1950-03-24
I hope this helps...Rich
I've used XP_READREG to read registry keys before and it's worked great. Now I need to read the default value for a key. What is the syntax to read "(Default)" from a registry key?
I have tried setting #value_name to '' or '.' or '(Default)' without success.
I can run the query without #value_name and I get back KeyExist = 1 indicating that the rootkey and key point correctly.
This is the general query that I'm using:
DECLARE #RegLoc VARCHAR(100)
select #RegLoc='TypeLib\{4BF5E120-AE37-4090-A83F-A1A8A5228371}\1.0\0\win64'
EXEC [master].[dbo].[xp_regread] #rootkey='HKEY_CLASSES_ROOT',
#key=#RegLoc,
#value_name=''
OK, #Alex K. pointed out the trick in the comment to the question, pass null for #value_name. I originally tried omitting it but the proc then defaults to an exists tests. Explicitly passing null causes xp_regread to return a registry keys default value. Like this:
DECLARE #RegLoc VARCHAR(100)
DECLARE #ValueName varchar(100) -- leave this unassigned to get the default value
select #RegLoc='TypeLib\{4BF5E120-AE37-4090-A83F-A1A8A5228371}\1.0\0\win64'
EXEC [master].[dbo].[xp_regread] #rootkey='HKEY_CLASSES_ROOT',
#key=#RegLoc,
#value_name = #ValueName
I'm trying to recover a table from Litespeed bakcup. The table is of schema SOURCE. Litespeed object recovery wizard fails with the error:: Table name must be specified in the format owner_name.table_name. I tried with the store procedure directly as well but it's giving the same error. Please help me fix this issue:
EXEC master.dbo.xp_objectrecovery
#filename = 'backup_file_name'
, #filenumber = 1
, #objectname = 'SOURCE.target_rpt_2016'
, #destinationdatabase = 'database_name'
,#destinationtable ='SOURCE.target_rpt_2016_restore'
, #tempdirectory = 'recovery_temp_dir'
I tried giving destinationtable without schema/dbo as well but it's throwing same error.
Atlast figured out the issue.
The owner of the schema Source is a domain account Dom\AXp0101. So when I changed the paramter #ObjectName to '[Dom\AXp0101].[source].[2016_target_rpt_2016]' the recovery completed. Read somewhere that as the owner of this particular schema is a domain account, there might be issues associated with demiliters so we have exclusively specify like above.
I'm trying to use apache camel (sql component) to update the DB. Problem is that the DB just doesn't get updated. The sql:update is working fine when i hard code the query, but when i try to use ${body[0][id]} it doesn't update required field. Any feedback on what might be going wrong?
from("direct:updateSql")
.to("sql:select * from mytable limit 1")
.log("update mytable set status = '100' where id = '${body[0][id]}'")
.to("sql:update mytable set status = '100' where id = '${body[0][id]}'")
.end();
Note that status and id are integer fields but if i remove the ' from the .to() then i throws some errors.
According to the docs you must use :# as the placeholder syntax
http://camel.apache.org/sql-component
So try with
.to("sql:update mytable set status = 100 where id = :#${body[0][id]}")
Below code worked too.
from("direct:updateSql")
.to("sql:select * from mytable limit 1")
.setHeader("id", simple("${body[0][id]}"))
.to("sql:update mytable set status_id = 100 where id = :#id")
.end();
I have Change Data Capture (CDC) activated on my MS SQL 2008 database and use the following code to add a new tabel to the data capture:
EXEC sys.sp_cdc_enable_table
#source_schema ='ordering',
#source_name ='Fields',
#role_name = NULL,
#supports_net_changes = 0;
However, whenever I try to select the changes from the tracking tables using the sys.fn_cdc_get_min_lsn(#TableName) function
SET #Begin_LSN = sys.fn_cdc_get_min_lsn('Fields')
I always get the zero value.
I tried adding the schema name using the following spelling:
SET #Begin_LSN = sys.fn_cdc_get_min_lsn('ordering.Fields')
but this didn't help.
My mystake was to assume that sys.fn_cdc_get_min_lsn() accepts the table name. I was mostly misguided by the examples in MSDN documentation, probably and didn't check the exact meaning of the parameters.
It turns out that the sys.fn_cdc_get_min_lsn() accepts the capture instance name, not table name!
A cursory glance at my current capture instances:
SELECT capture_instance FROM cdc.change_tables
returns the correct parameter name:
ordering_Fields
So, one should use underscore as schema separator, and not the dot notation as it is common in SQL Server.
I know this is mostly already explained in this post but I thought I would put together my evenings journey through CDC
This error:
"An insufficient number of arguments were supplied for the procedure or function cdc..."
Is probably caused by your low LSN being 0x00
This in turn might be because you put the wrong instance name in with fn_cdc_get_min_lsn.
Use SELECT * FROM cdc.change_tables to find it
Lastly make sure you use binary(10) to store your LSN. If you use just varbinary or binary, you will again get 0x00. This is clearly payback for me scoffing at all those noobs using varchar and wondering why their strings are truncated to one character.
Sample script:
declare #S binary(10)
declare #E binary(10)
SET #S = sys.fn_cdc_get_min_lsn('dbo_YourTable')
SET #E = sys.fn_cdc_get_max_lsn()
SELECT #S, #E
SELECT *
FROM [cdc].[fn_cdc_get_net_changes_dbo_issuedToken2]
(
#S,#E,'all'
)
The above answer is correct. Alternatively you can add an additional parameter capture_instance to the cdc enable
EXEC sys.sp_cdc_enable_table
#source_schema ='ordering',
#source_name ='Fields',
#capture_instance = 'dbo_Fields'
#role_name = NULL,
#supports_net_changes = 0;
then use the capture_instance string in the min_lsn function
SET #Begin_LSN = sys.fn_cdc_get_min_lsn('dbo_Fields')
will return the first LSN, and not 0x00000000000000000000.
This is partiularly useful when trying to solve the error
"An insufficient number of arguments were supplied for the procedure or function cdc..." from SQL when calling
cdc_get_net_changes_Fields(#Begin_LSN, sys.fn_cdc_get_max_lsn(), 'all')
Which simply means "LSN out of expected range"