I have a TIMESTAMP(6) field in Oracle db. Value of this field is in format
DD/MM/YYYY HH:MM:SS.000000000 PM
How to update this value to the current timestamp?
[a link to a similar question:] update date value in oracle
I followed this link, but following query is taking very long time to execute.
update table_name set start_time = to_char(to_date(start_time, 'yyyy/mm/dd-hh:mi:ss:ff3'), '2012/10/10-19:30:00:00') where column='Q'
A timestamp is a point in time, it has no format. To update such a field to the current timestamp, use SYSTIMESTAMP or CURRENT_TIMESTAMP (respectively the date/time of the server and the date/time of the session):
UPDATE your_table
SET your_column = systimestamp
WHERE ...
If the query takes an abnormal amount of time (much longer than a comparable SELECT with the same WHERE clause), the mostly likely causes are:
The rows that your are updating are locked by another session (doing a SELECT FOR UPDATE NOWAIT on these rows will make sure that you have the lock).
You have triggers that perform additional work,
You're updating a column referenced by a non-indexed foreign key.
Why you don't just
update table_name
set start_date = systimestamp
where column='Q'
If you suspect there are locks on the table, there are some tables to check: dba_locks, v$session, v$session_blockers etc. These are useful when a user blocked something with an accidental update without a commit or rollback, but you should be able to see if can exists blocking locks from the architecture of your application. You should just simulate on paper all the scenarios.
Related
I would like to append two timestamp columns to an existing table.
CREATED_TSTMP would be populated with the current timestamp when a record is inserted and LAST_UPD_TSTMP would be updated automatically when a record in the table gets updated.
I would like to do this without having to modify existing queries.
I have the following DDL statements:
ALTER TABLE XXX ADD CREATED_TSTMP TIMESTAMP NOT NULL WITH DEFAULT CURRENT TIMESTAMP ;
alter table XXX add column LAST_UPD_TSTMP timestamp not null generated by default for each row on update as row change timestamp ;
However once the columns are appended, this will cause an existing query with the following syntax:
INSERT INTO XXX VALUES(?,?,?,?,?,?,?,?,?,?)
to fail with
The number of values assigned is not the same as the number of
specified or implied columns or variables..
Is there any way around this problem without having to inspect all of the existing queries (there are hundreds of them...)
If you add the IMPLICITLY HIDDEN option when creating the columns, they will be ignored by the SQL statements unless you explicitly mention these columns.
PS. I'm assuming you are on a sufficiently recent version of DB2, because of your using row change timestamp. To avoid ambiguity, you should indicate the DB2 version and platform in question.
my problem is that i have a field in novels table timestamp,on update
CURRENT_TIMESTAMP,no,CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP.
I am using CURRENT_TIMESTAMP at the time of inserting into sql but I noticed that value of all my posts showing 21-02-2014. Any help?
ON UPDATE CURRENT_TIMESTAMP means that CURRENT_TIMESTAMP fields updates when the values of that field change, not when they stay same (OR) not when you update some other field(s) other than the timestamp field and this behavior is by design.
probably you can do something like this to update it
UPDATE <your_table>
SET <your_current_timestamp> = null,
WHERE <some_condition>
I am using MS SQL Server 2008 and I have an sql table with some data that is inserted daily at 6 am by an sql job. The problem I have is that some data has been inserted separately into the job and I need to know when this data was added.
Is there a query I can run that will show me this?
I think the short answer is NO, there's no magic, ad hoc SQL query that will let you go back after the fact and find out when a row was inserted.
If you want to know when a row is inserted, the easiest thing would be to simply add a date or timestamp field with a default value (like getDate()) that automatically fills in the date/time when the row is inserted.
There are, of course, SQL logs available that will let you track when rows are inserted, updated, deleted, etc., but those require set up and maintenance.
Third option would be to have the program that's inserting the data perform some logging.
Add a date field to the table. You can give it a default value of GETDATE()
Then ORDER BY that field.
SELECT Column1, Column2, NewDateColumn
FROM YourTable
ORDER BY NewDateColumn
what i would do is :
/* add new column to keep inserted row date */
ALTER TABLE [schemaName].[tableName] ADD [RecTime] DATETIME;
/* update the existing rows with the current date since there is no way to guess their insertion date */
UPDATE [schemaName].[tableName] SET [RecTime] = GETDATE();
/* and set a constraint to the RecTime column to set current date on every new row added */
ALTER TABLE [schemaName].[tableName] ADD CONSTRAINT [DF_tableName_RecTime] DEFAULT (GETDATE()) FOR [RecTime]
then you can get those rows like :
SELECT *
FROM [schemaName].[tableName]
WHERE NOT(DATEPART(hh, RecTime) = 6 AND DATEPART(mi, RecTime) <= 20)
you can 'play' with '20' if you know how long sql job run
you probably need to look at SQL CREATE TRIGGER to add the logic to know when the data is being added and log that info in another table for further actions. Without further details I am not sure we can say more than that.
As you're referring to data which has already been inserted, the answer is No, unless you already have a datetime column which has a default value of GETDATE(). The best you can manage after the event has occurred is to look at the sequence of rows and determine that it was between two known times.
Is it possible to get last updated time and date of the row using MYSQL server.
Well there is no inbuild feature exists with MySQL. Though you can get the same effect by adding a timestamp column:
ALTER TABLE NAMEYOURTABLE
ADD COLUMN last_update TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
using above to create timestamp with name last_update column will make it pretty much automatically managed and updated. Now you can select from NAMEYOURTABLE the last updated row based on the timestamp.
Bakground:
I've got a legacy app I'm working on that uses DATE types for most time storage in the database. I'd like to try update some of these tables so that they can utilize time zones since this is causing problems with users in different areas from where the db is(see A below). This is for Oracle 10g.
Quetions:
1) Can I migrate this "in place." That is can I convert like so
DATE_COL = type:DATE => DATE_COL = type:TIMESTAMP
...or will I have to use a different column name?
Keep in mind that data needs to be retained. If this can be done semi-easily in a migration script it will work for my purposes.
2) Will this type of conversion be backwards compatible? We likely have some scripts or reports that will hit this table that we may not know about. We can probably deal with it but I'd like to know what sort of hornet's nest I'm walking into.
3) What pitfalls should I be on the lookout for?
Thanks,
EDIT:
(partly in response to Gary)
I'm fine with a multi-step process.
1) move data to a new Timestamp column (caled TEMP) with some sort of conversion
2) drop old column (we'll call it MY_DATE)
3) create new timestamp column with the old date column name (MY_DATE)
4) move data to the MY_DATE column
5) drop TEMP column
A Gary also wanted clarification on the specific timezone issue. I copied my answer from below to keep it more readable.
Basically the data will be accessed from several different areas. We need to be able to convert to/from the local time zone as needed. We also have triggers that use sysdate further complicating things. timestamp with time zone alleviates a lot of this pain.
Oh and thanks for the answers so far.
You could just run:
ALTER TABLE your_table MODIFY your_date_column TIMESTAMP WITH TIME ZONE;
But I would recommend adding a TIMESTAMP column to the table, using an UPDATE statement to populate, and drop the original date column if you so choose:
ALTER TABLE your_table ADD date_as_timestamp TIMESTAMP WITH TIME ZONE;
UPDATE your_table
SET date_as_timestamp = CAST(date_column AS TIMESTAMP WITH TIME ZONE);
The conversion is backwards compatible - you can switch back & forth as you like.
Simple enough to demonstrate
SQL> create table x (y date);
Table created.
SQL> insert into x select sysdate from dual;
1 row created.
SQL> commit;
Commit complete.
SQL> alter table x modify y timestamp;
Table altered.
SQL> select * from x;
Y
---------------------------------------------------------------------------
03/NOV/09 12:49:03.000000 PM
SQL> alter table x modify y date;
Table altered.
SQL> select * from x;
Y
---------
03/NOV/09
SQL> alter table x modify y timestamp with time zone;
alter table x modify y timestamp with time zone
ERROR at line 1:
ORA-01439: column to be modified must be empty to change datatype
SQL> alter table x modify y timestamp with local time zone;
Table altered.
SQL> alter table x modify y date;
Table altered.
So you can go from date to timestamp (or timestamp with local timezone) and back again, but not for timestamp with time zone (ie where the offset is persisted).
You'd have to add another column, and copy the existing data over (with a default for the appropriate time zone).
"causing problems with users in different areas from where the db is".
Might help to be a bit more specific. Is it sufficient to convert the dates (or timestamps) from the database timezone to the user's timezone when inserted/changed/queried, or do you actually need to persist the fact that the record was created at 3:00pm in a specific timezone.