I am using Exasol DB and to perform date operation, I am using SQL INTERVAL keyword with precision.
For example this query:
SELECT email_staging.ID, email_staging.CREATED_AT from EMAIL email_staging
WHERE email_staging.CREATED_AT > (CURRENT_DATE - (INTERVAL '5' DAY(3) ) ) )
Exasol requires the precision to sent i.e. suffix like '(3)' after DAY or else it won't allow querying for more that 99 days. But H2 Database doesn't support INTERVAL with precision.
Has anyone solved this as my integration tests which use H2 DB can't run.
Standard interval literals with leading field precision and/or fractional seconds precision are supported by H2 since the version 2.1.212.
Related
So I have this pipeline that migrates data from Oracle to Snowflake. There is one column in Oracle that has datatype NUMBER and I used NUMBER(38, 18) in Snowflake for it.
My pipeline started failing yesterday because that column in Oracle now has 21 digit numbers which NUMBER(38, 18) cannot handle in Snowflake. I switched to NUMBER(38, 17) and it worked for now.
Is there any NUMBER equivalent in Snowflake so that it can handle any value from Oracle? I cannot possibly change the Oracle table datatype.
A column defined as NUMBER in oracle (without scale or precision) doesn't have an equivalent in Snowflake unfortunately. It is some variable-length decimal format that isn't the same as a float.
If you are not 100% sure on what the scale / precision should be, you can try to use FLOAT in Snowflake but that could lead to rounding errors on big aggregations so you'll need to figure out if it is worth it or not.
I am trying to access PostgreSQL record from Oracle via ODBC, there is a severe problem when I try to read timestamp field, the precision of time in microsecond has been lost. For example: 2018-01-25 12:40:20.123456 in PostgreSQL will be 2018-01-25 12:40:20.000000 in the Oracle. To make sure, I have write PL/SQL to check the data, somehow all microsecond digits has been lost.
There's a documentation talking about connection string's parameter BTD - BIND TIMESTAMP AS DATE link
By default, this parameter should be "FALSE"
Bind TIMESTAMP as DATE (BTD Connect String)
Added the new connection option, Bind TIMESTAMP as DATE, that allows you to bind the ODBC driver SQL_TIMESTAMP data type to the Oracle DATE data type instead of to the Oracle TIMESTAMP data type (which is the default).
Here is my PL/SQL:
declare
v_timestamp timestamp(6);
begin
select max("MODIFIED_ON") into v_timestamp from "public"."DAS_ITEM"#PG_LINK;
dbms_output.put_line(v_timestamp);
end;
The result is: 19/JAN/18 08:59:42.000000 AM , it's missing microsecond, all 6-digit second fraction has been replace to zero.
On the other hand, on my PostgreSQL, the result is "2018-01-19 08:59:42.695166"
I also have tested with isql, it return timestamp value with whole precision, as a consequence, I believe that the main reason comes from Oracle.
The Oracle DATE datatype does not support fractions of seconds. You need to use TIMESTAMP for that. This also applies to any table columns or PL/SQL datatypes PostgreSQL timestamps go into; if the timestamps are passed into a DATE somewhere, fractions of seconds will be truncated.
I have a database on my local development machine and there is a database on our test server. Basically, the tables on my dev machine were copied over from the test machine.
However, I have found a difference in how the same date is treated by the to_char function. On my development machine if I run the following query:
select test_date, to_char(test_date, 'YYYY-MM-DD')
from test.table
where id = 'C0007784'
I get the following results:
31-DEC-99 1999-12-31
On the test server running the same query against the same schema and data I get the following:
31-DEC-99 1899-12-31
Could this difference in behaviour of to_char be due to a setting being different in the two Oracle instances?
If I run SELECT value FROM v$nls_parameters WHERE parameter ='NLS_DATE_FORMAT'; I get DD-MON-RR for both instances.
So you exported the contents of the table to a csv file using DD-MON-YY format. YY obviously causes ambiguity. I guess that when you were importing the file, 99 was interpreted as 1999 instead of 1899. I don't know the exact mechanism which is used by database to guess the full year, but anyway Oracle strongly recommends YYYY in date format:
Note: Oracle recommends that you use the 4-digit year element (YYYY)
instead of the shorter year elements for these reasons: The 4-digit
year element eliminates ambiguity.
The shorter year elements may affect query optimization because the
year is not known at query compile time and can only be determined at
run time.
When I connect to
jdbc:hsqldb:mem:lbw;sql.syntax_ora=true
the statement
SELECT CURRENT_DATE FROM dual
results in
2014-01-31 10:35:54
This is in opposite to connections without Oracle syntax mode, where CURRENT_DATE doesn't contain time.
As described in the HSQLDB documentation, DATE is interpreted as TIMESTAMP(0) in Oracle syntax mode. But in Oracle 10g itself, CURRENT_DATE behaves as expected (without time).
This difference seems to include DATE fields in general.
Why does HSQLDB behave this way?
Is there a way to disable the automatic conversion?
From the same HSQLDB documentation you linked to:
Datetime types
HSQLDB fully supports datetime and interval types and operations,
including all relevant optional features, as specified by the SQL
Standard since SQL-92. The two groups of types are complementary.
The DATE type represents a calendar date with YEAR, MONTH and DAY
fields.
The TIME type represents time of day with HOUR, MINUTE and SECOND
fields, plus an optional SECOND FRACTION field.
The TIMESTAMP type represents the combination of DATE and TIME types.
The Oracle compatibility section says:
The DATE type is interpreted as TIMESTAMP(0) in ORA syntax mode.
Oracle's DATE data type "contains the datetime fields YEAR, MONTH, DAY, HOUR, MINUTE, and SECOND". So it's equivalent to an HSQLDB TIMESTAMP(0) data type, and in Oracle mode it is treated as such.
Oracle dates always have a time component, even if it is all zeros for midnight. If your SQL client doesn't show it by default you can see that with select to_char(current_date, 'YYYY-MM-DD HH24:MI:SS'), as others have already pointed out.
In normal non-Oracle mode HSQLDB is just treating the value as an SQL-standard DATE and dropping the time portion; in Oracle mode it preserves the time. There doesn't seem to be any way to selectively enable some aspects of the Oracle mode, so you're stuck with the time - really not sure why that is an issue though since it's just reflecting the data you have in your database. If you want to ignore the time you could always select trunc(current_date), which will take the time back to midnight; but it will still show as 2014-01-31 00:00:00 because it's still going to be treated as TIMESTAMP(0).
I wrote a HQL query which seems to work fine on SQLServer but throws an exception on Oracle.
The query simply calculates the sum of durations of all tasks
SELECT SUM(second(t.endTime) - second(t.startTime)) FROM Task as t
Apparently you cannot get seconds from sysdate in Oracle. Is it possible to write a single HQL query that will work with both databases ? or should i handle oracle separately in this case ?
EDIT: I forgot to add that both endTIme and startTime are Date types.
And the exception i get is
Caused by: java.sql.SQLException: ORA-30076: invalid extract field for extract source
Yes you can, the syntax is just slightly different, which implies you'd have to do it differently.
It's extract(SECOND from ( endtime - starttime) ).
But, you can only extract seconds from a date. If you want seconds via this method then your column has to be a timestamp datetype.
Alternatively, and more useful as it'd work for you, I prefer the following. Oracle returns days from date-arithmetic, hence the multiplication at the end.
( endtime - starttime ) * 60 * 60 * 24