I am using Teradata JDBC 16.20 in Datagrip.
Whenever I try to do anything with date, it returns 1 day less.
For instance: SELECT date'2017-08-01' returns 2017-07-31 in Datagrip and in Teradata SQL Assistant it returns correctly 01/08/2017.
Does anyone know why?
We have the same issue using DataGrip with a Vertica database. My hunch is that the date is being shifted twice. When I select current_timestamp (which on Vertica is timestamp with timezone) the date is correct (typically one day earlier than the current date), but when I select current_date, I get the previous day (my timezone is US/Pacific). What I think is happening is the JDBC driver is adjusting the date based on the two timezones, and then DataGrip is then adjusting it a second time.
We don't have issues using the same Vertica database with the same JDBC driver, but a different SQL Client (DbVisualizer).
The only workaround I can offer using DataGrip is to install a much older version. DataGrip 2016.3.4, Build #DB-163.13906.13, built on February 21, 2017 seems to handle date columns correctly.
Adding -Duser.timezone=UTC to VM options seems to solve the problem.
Related
We have a web application which we store a date from the user. The date is stored on an Oracle 19c database as a date field.
The problem we have is that when we select the date it's coming with different hours, like it's taking into account the timezone or something. So, for example one person can see the date 2021-05-20T13:00:00Z while another somewhere else can see 2021-05-20T12:00:00Z.
Is there a way to prevent this behavior, and have everybody get the same date and time?
Update
Most likely the problem resides in Oracle Apex, not Oracle database!
We use a very old version of Apex, 1.x it seems so maybe this problem doesn't happen on newer versions.
That is often problem when you use, for example, java.util.Timezone,java.sql.Date or java.util.Date type in java instead of oracle.sql.Date
Today I was using datagrip with the new view of MariaDB, and at executing
SELECT DATE('2018-03-01');
return '2018-02-28'. Meanwhile on MySQL view return the same Date that I put as String version.
I use MariaDB 10.1.26 with XAMP, Datagrip 2018.1.
It's the first time that make this.
Try use the CONVERT_TZ() because your problem is probably related to timezone, who are different their two instances (Maria and My), or update the timezone in the instances to be the same.
To check the timezone:
select ##system_time_zone;
TL;DR - Is it possible to change the date format Sqoop uses?
I am importing data from a SQL Server using Sqoop (version 1.4.6) and am specifying a datetime column as my --check-column.
Sqoop is querying the database using dates in the format yyyy-MM-ddd hh:mm:ss.SSS. However, since SQL server is configured to use British dmy date format, it, counterintuitively, interprets a date beginning with a year as having the day in the second position rather than the month (wtf?!).
E.g SELECT ... WHERE modified < '2017-01-31 00:00:00.000' is interpreted as selecting the data where modified is less than the 1st day of the 31st month 2017 which obviously throws an error.
Is it possible to change the date format Sqoop uses?
A quick scan of the Sqoop documentation did not reveal a way to change the date format. The Microsoft Support article here suggests that you could avoid the problem by issuing a
SET DATEFORMAT 'ymd'
statement immediately after opening the connection, but it appears that Sqoop only supports that sort of operation for Oracle (oraoop-site-template.xml) and not for other JDBC drivers.
There is an mssql-jdbc pull request that, if accepted, would let you add ;connectionDateformat=ymd to your Sqoop connection URL. In the meantime you may just have to change the default language of the SQL login for your Sqoop job from "British English" to (US) "English":
So this is the problem, I have a Oracle table, just a normal table with let's say 300 rows of data.
I need to figure out how that data looked like at least 100 days before, who made changes and timestamp would be nice also.
Thing is, I do have a schedule backup, but I believe someone changed data and removed backup, so I am trying to find out this change over system records.
I did google this and for results I got now, I didn't got what I needed.
select * from dba_hist_sqltext - it gives me results for current session only
SELECT SCN_TO_TIMESTAMP(ORA_ROWSCN) - specified number is not a valid system change number
Oracle SQL info -
Java(TM) Platform 1.7.0_51
Oracle IDE 4.0.0.13.80
Versioning Support 4.0.0.13.80
Do you guys have any other idea?
Thank you in advance
You may use flashback: Using Oracle Flashback Technology
With that, you can query using the AS OF TIMESTAMP clause, like this:
SELECT * FROM yourtable
AS OF TIMESTAMP TO_TIMESTAMP('2004-04-04 09:30:00', 'YYYY-MM-DD HH:MI:SS');
This has to be enabled though, and there is a certain (configurable) size limit, so there is no guarantee that you can still query those records of 100 days ago. On a busy database the history may go back only a couple of minutes.
The end of my select query is:
and logoff_time > to_date('2013-11-27 14:18:42','yyyy-mm-dd hh24:mi:ss');
yet this is returning (in SQL Developer) rows with times in logoff_time before the specified time - e.g. 3am.
Is this problem something to do with timezones? I'm in GMT and so is the server, although I don't know what timezone it thinks it is in.
This logoff_time column is an Oracle system audit column, by the way. (Actually, I've attempted to reconstruct it by a subquery directly on the underlying audit table.)
My mistake. The times were in fact newer. I was just confused by the fact that I had set them to display as HH:MI:SS instead of HH24:MI:SS in the SQL Developer preferences, so I was looking at 03 and thinking that meant 3am instead of 3pm.