I would like to create a function for a table that has three columns amongst others as follows:
insertDate datetime
updateDate datetime
activity integer
I want to update the activity column by taking the difference of the two date columns...basically updateDate - insertDate = how many days of activity in the activity column. I have no idea how to start this and it needs to run whenever a new insertDate or updateDate is inserted.
You can populate the [InsertDate] with a default value of GETDATE() and populate [UpdateDate] with the current date when you update the column (because you're using procedures (wink), this is really easy to control). If you aren't using procedures and want to control. the [UpdateDate] column, you can use a trigger to populate that column.
Let the Activity column be a calculated field:
DATEDIFF(day, [InsertDate], [UpdateDate])
DATEDIFF
Computed Columns
From MSDNabout computed columns:
Unless otherwise specified, computed columns are virtual columns that are
not physically stored in the table. Their values are recalculated every
time they are referenced in a query. The Database Engine uses the PERSISTED
keyword in the CREATE TABLE and ALTER TABLE statements to physically store
computed columns in the table. Their values are updated when any columns
that are part of their calculation change. By marking a computed column as
PERSISTED, you can create an index on a computed column that is
deterministic but not precise.
Since all the data required for this is in the same row of the table, you could create a computed column. If you want to have an actual column value that is updated whenever the row is updated then you need to look at triggers.
Place this code in a trigger.
update MyTable
set updateDate = GETDATE()
, activity = select (DATEDIFF(DAY, insertDate, GETDATE()))
Related
I created a new column [LastLoginDate-NoTime] with the data type Date. I already have another column [LastLoginDate] that is of Datetime datatype.
Columns with the values
I am trying to copy values from the LastLoginDate column to the LastLoginDate-NoTime column using this query:
UPDATE [dbo].[SapUsersExt]
SET [LastLoginDate] = [LastLoginDate-NoTime]
But the problem I am having is that when I execute this query, it sets the data to null in the original column.
Screenshot: Error
I am also trying to convert the data from the LastLoginDate to just date format in the new column LastLoginDate-NoTime so that I can use it in my application. How would I do that?
I am trying to copy values from the LastLoginDate column to the LastLoginDate-NoTime column using this query
In that case, you're doing it exactly backwards - you should use this SQL instead:
UPDATE [dbo].[SapUsersExt]
SET [LastLoginDate-NoTime] = [LastLoginDate]
The first column - right after the SET - is the target column into which your values will be written.
The second column, after the = symbol, is where the data comes from (column or expression).
You had it backwards - setting the column with the actual values, to all NULL ....
This of course only works for a "one time" update - this will not keep your columns in sync over time, when new data is being inserted. For such a case, you'd need a computed column
ALTER TABLE dbo.SapUsersExt
ADD LastLoginDateOnly AS CAST(LastLoginDate AS DATE) PERSISTED;
or a trigger.
Or maybe, you don't even really need to actually store that date-only value - just use
SELECT
CAST(LastLoginDate AS DATE),
.......
if you need to date-only value from LastLoginDate
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.
I need to create a column age in a SQL Server database.
The values of this column should be calculated based on the values of the column DOB.
Also its values should increment as Age increases.
You should use a computed column to solve this problem. Something with a definition similar to this:
ALTER TABLE Customers ADD Age AS datediff(year, DOB ,getdate())
Original statement taken from and further information available at BlackWasp.
Edit:
MSDN explains computed columns as:
A computed column is computed from an expression that can use other
columns in the same table. The expression can be a noncomputed column
name, constant, function, and any combination of these connected by
one or more operators. The expression cannot be a subquery.
Unless otherwise specified, computed columns are virtual columns that
are not physically stored in the table. Their values are recalculated
every time they are referenced in a query. The Database Engine uses
the PERSISTED keyword in the CREATE TABLE and ALTER TABLE statements
to physically store computed columns in the table. Their values are
updated when any columns that are part of their calculation change. By
marking a computed column as PERSISTED, you can create an index on a
computed column that is deterministic but not precise. Additionally,
if a computed column references a CLR function, the Database Engine
cannot verify whether the function is truly deterministic. In this
case, the computed column must be PERSISTED so that indexes can be
created on it. For more information, see Creating Indexes on Computed
Columns.
Computed columns can be used in select lists, WHERE clauses, ORDER BY
clauses, or any other locations in which regular expressions can be
used, with the following exceptions:
Computed columns used as CHECK, FOREIGN KEY, or NOT NULL constraints must be marked
PERSISTED. A computed column can be used as a key column in an index or as part of any
PRIMARY KEY or UNIQUE constraint if the computed column value is defined by a
deterministic expression and the data type of the result is allowed in index
columns.
For example, if the table has integer columns a and b, the computed column a + b can be
indexed, but computed column a + DATEPART(dd, GETDATE()) cannot be indexed because the
value may change > in subsequent invocations.
A computed column cannot be the target of an INSERT or UPDATE statement.
The Database Engine automatically determines the nullability of
computed columns based on the expressions used. The result of most
expressions is considered nullable even if only nonnullable columns
are present, because possible underflows or overflows will produce
null results as well. Use the COLUMNPROPERTY function with the
AllowsNull property to investigate the nullability of any computed
column in a table. An expression that is nullable can be turned into a
nonnullable one by specifying ISNULL(check_expression, constant),
where the constant is a nonnull value substituted for any null result.
Source: MSDN - Computed Columns
Code snippet
ALTER TABLE
TheTable
ADD
DOB AS
CASE
WHEN
MONTH(Birth) > MONTH(ISNULL(Death, SYSDATETIME()))
OR (
MONTH(Birth) = MONTH(ISNULL(Death, SYSDATETIME()))
AND DAY(Birth) >= DAY(ISNULL(Death, SYSDATETIME()))
)
THEN
DATEDIFF(YEAR, Birth, ISNULL(Death, SYSDATETIME())) - 1
ELSE
DATEDIFF(YEAR, Birth, ISNULL(Death, SYSDATETIME()))
END
Create Table with auto-generated column,
CREATE TABLE Person2
(Id int IDENTITY(1,1) NOT NULL, Name nvarchar(50),
DOB date, Age AS DATEDIFF(YEAR, DOB ,GETDATE()) )
This is the correct way of getting the age:
alter table <yourtable> add age as datediff(year, DOB, getdate())- case when month(DOB)*32 + day(DOB) > month(getdate()) * 32 + day(getdate()) then 1 else 0 end
I know when you insert a value into db, it set that column value as current datetime,
does it apply to it when you run a update statement?
e.g.
table schema:
Id, Name, CreatedDate(getdate())
when i insert into table id = 1 , name = 'john' it will set createdDate = current date
if i run an update statement
update table set name="john2" where id =1
Will it update the createdDate?
No, a DEFAULT CONSTRAINT is only invoked on INSERT, and only when (a) combined with a NOT NULL constraint or (b) using DEFAULT VALUES. For an UPDATE, SQL Server is not going to look at your DEFAULT CONSTRAINT at all. Currently you need a trigger ( see How do I add a "last updated" column in a SQL Server 2008 R2 table? ), but there have been multiple requests for this functionality to be built in.
I've blogged about a way to trick SQL Server into doing this using temporal tables:
Maintaining LastModified Without Triggers
But this is full of caveats and limitations and was really only making light of multiple other similar posts:
A System-Maintained LastModifiedDate Column
Tracking Row Changes With Temporal
Columns
How to add “created” and “updated” timestamps without triggers
Need a datetime column that automatically updates
wow - hard to understand...
i think NO based on the clues.
if you insert a record with a NULL in a column, and that column has a default value defined, then the default value will be stored instead of null.
update will only update the columns specified in the statement.
UNLESS you have a trigger that does the special logic - in which case, you need to look at the trigger code to know the answer.
if your update statement tell to update a column with getfate() it will, but if you just update a name for example and you have a createdate column (which was inserted with getdate()), this columns wont be affected.
You can achieve this using DEFAULT constraint like i did it with OrderDate field in below statement.
CREATE TABLE Orders
(
O_Id int NOT NULL,
OrderNo int NOT NULL,
P_Id int,
OrderDate date DEFAULT GETDATE()
)
certain fields in our database contain calculated functions e.g.
select lastname + ', ' + firstname as fullname from contact where contact.id =$contact$
when viewing the field the correct data is shown (i assume this is because when you open the record, the calculation is executed). however, the data is not 'stored' to the field, and therefore is null until the record is opened. is it possible to 'store' the result to the field, making it possible to search the data?
many thanks
james
EDIT
it is not possible for me to create computed_columns using our software.
the above field is a text feild where either 1) a user can manual type in the required data or 2) the database can generate the answer for you (but only whilst you are looking at the record). i know that if I run the following:
Select * from contact where contact.id =$contact$ for xml auto
i only get lastname, firstname - so i know that the fullname field does not retain its information.
If you are using computed columns in sql server, the column is already searchable regardless of whether the calculation result is stored or not. However, if you would like to make it so that the calculation is not run each time you read the row, you can change that under row properties in your Modify Table GUI.
Use the PERSISTED key word when you create the column
From BOL:
PERSISTED
Specifies that the SQL Server Database Engine will physically store the computed values in the table, and update the values when any other columns on which the computed column depends are updated. Marking a computed column as PERSISTED lets you create an index on a computed column that is deterministic, but not precise. For more information, see Creating Indexes on Computed Columns. Any computed columns that are used as partitioning columns of a partitioned table must be explicitly marked PERSISTED. computed_column_expression must be deterministic when PERSISTED is specified.
This isn't the way computed columns work in SQL Server, so I suspect this is something your client application is doing. How are you looking at the data when the value is computed correctly? Does it work when you view the data in SSMS?
Take a look at http://msdn.microsoft.com/en-us/library/ms191250(v=SQL.90).aspx to see how to create computed columns properly.
eg.
create table TestTable
(a int,
b int,
c as a + b)
insert into TestTable (a,b)
values (1,2)
select * from TestTable
where c = 3
This query is based on the computed column and it returns the row that's been inserted.
You need to use the PERSISTED option on a column when you use CREATE TABLE e.g.
CREATE TABLE test (col_a INT, col_b INT, col_c AS col_A * col_B PERSISTED)