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.
Related
I've created a few tables all of which had a column of datatype datetime. Recently, I think after the daylight savings adjustment, for some reason all the dates have shifted by a few hours i.e. '2022-01-01 00:00:00' has changed to '2021-12-31 18:00:00'.
My guess is that it has something to do with the daylight savings and some server setting related to that but I can't figure out how to revert it back.
Edit:
As suggested in the comments, it might have something to do with the sqoop-export i.e. what I'm using to transfer data from hdfs to sql server. So, the question really is how could I look at what is being inserted into the table. Is there a way I can redirect all insert statements to a log file before being sent over to sql server?
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
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.
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.
I have a query that is something like
select * from myTable where [date] < 'YYYY-MM-DD'
However sql server is interpreting this in the format YYYY-DD-MM (I thought the YYYY-MM-DD format was used as it shouldn't be unambiguous, but obliviously this isn't the case!)
It would be good to know why this has happened (I haven't expereinced this before with sql server, and what the best practice is when dealing with dates.
There are three formats that are (and have been for a long time) unambiguous. These are:
YYYYMMDD
YYYY-MM-DD'T'hh:mm:ss
YYYY-MM-DD'T'hh:mm:ss.mil
Some other formats may be unambiguous on newer versions of SQL Server and/or working with the newer datetime2, date and time types, but you can always rely on the above 3. So just either use YYYYMMDD or, if possible, avoid passing strings to SQL Server when you want to deal with dates.
(Or, option 3, use CONVERT and specify exactly what format you're actually using)
I would start with two things to check:
How this date is passed to SQL Server (it can depends on date
settings on client -- i.e. Windows settings). I saw a code (in VB6)
which passes date like '2014-10-08' as 8th Oct 2014 or 10th August
2014 depends on server settings (Polish, British, American).
How SQL Server recognizes the date passed as string -- i.e. 2014-10-08 (similar issue).