I have an update statement which updates a table. And there is a column that records the last modified time. If data in a specific row has not been changed, I don't want to change the last modified date time.
What is the best way to check whether an update statement will change the row of data or not.
Thanks,
Check the old vs. new data in your code instead of doing it in a query.
No need to bother the DB layer unnecessarily if data didn't change at all.
In short, if data didn't change, don't send the UPDATE statement.
One way is to start a transaction, select the contents of the row and compare it to what you're going to update it to. If they don't match, then do the update and end the transaction. If they match, rollback the transaction.
Sounds like you are going through a table and modifying some rows, then you want to go BACK through the table a second time and update the timestamp for the rows that were just changed.
Don't do it in two passes. Just update the date/time at the same time as you update whatever other columns you are changing:
UPDATE myTable
SET retailprice = wholesaleprice * 1.10,
lastmodified = GetDate()
WHERE ...
Or are you issuing an update statement on ALL rows, but for most rows, it just sets it to the value it already has? Don't do that. Exclude those rows that wouldn't be modified in your where clause:
UPDATE myTable
SET retailprice = wholesaleprice * 1.10,
lastmodified = GetDate()
WHERE retailprice <> wholesaleprice * 1.10
If you want to do this preemptively, the only way I can think of that you will do this is to modify the WHERE clause of the update statement to compare the existing value vs the new value (for EVERY value). If ANY of them are not equal, then the update should take place.
That's when a DAL is handy. It keeps track of all colums so if none changed then I don't even send an UPDATE statement to the database.
It depends on whether you have control of the data or not. Seb above is correct in saying you should check the old data against the new data before doing the update. But what if the data is not under your control?
Say you are a webservice being asked to do an update. Then the only way to check would be to query the existing data and compare it to the new data.
Don't know of any SQL functionality that would detect whether the update has actually changed any data or not.
There are ways in SQL to detect how many rows have been included in an update statement. Don't know of a way to detect whether an update statement actually changed any data, that would be interesting to know.
If you are using sql 2005/2008 then you can do as follows in the stored procedure.
update newTable
set readKey='1'
output inserted.id,
inserted.readKey as readKey,
deleted.readKey as prevReadKey
into #tempTable
where id = '1111'
Then you can select from #tempTable to verify if the prevReadKey and readKey has similar value if both has similar value you can reset your last modified datetime.
This way you don't have to fire multiple queries on the table in the case when a value is actually changing. But yes in the case when the value is not changing, this will be firing two update statements where none is required. This should be OK if those cases are rare.
P.S. NOTE:- The query given might be syntactically wrong as it is not tested. But this is the way your problem can be solved. I have done it in following way using OUTPUT clause with Merge statement in one of my project and it can be done with update statement too. Here is the reference of OUTPUT Clause
You COULD write an INSTEAD OF UPDATE trigger in T-SQL, where you could do what has been suggested above in the DAL layer -- compare the values in the existing record vs. the values in the update statement and either apply the update or not. You could use the Columns_Updated() function in the trigger to see if anything had been updated, and proceed accordingly.
It's not particularly efficient from the machine's point of view, but you could write it once and it would handle this situation no matter which application, stored procedure or other process was trying to update the record.
Related
I am quite novice to LINQ, but I have the impression that when updating tables, LINQ creates some SQL code like this:
UPDATE table_name
SET column1=value1,column2=value2,...
WHERE some_column=some_value;
And I guess that the primary key is used within the WHERE clause. Let's suppose my tables/objects have a timestamp column and I want to check if the timestamp has changed since last time I read a particular row. I.e., my UPDATE statement would be:
UPDATE table_name
SET column1=value1,column2=value2,...
WHERE some_column=some_value AND timestamp=my_timestamp;
Obviously the purpose is to abort updates when the timestamp has changed (meaning that another user has updated this row and my data is outdated).
Does LINQ support something like this?
I recommend that you look into using the built in concurrency functionality for LINQ to SQL:
http://msdn.microsoft.com/en-us/library/bb399373%28v=vs.110%29.aspx
Read through that and then I'd bet that you're going to need to use this:
http://msdn.microsoft.com/en-us/library/system.data.linq.mapping.updatecheck%28v=vs.110%29.aspx
I would like to know what is the best approach for creating a historical table for some table and automatically move deleted rows to this new table with same columns + deleted time.
For example:
When I delete a row from a PRODUCT table it will move to PRODUCT_H table with deleted time column.
Thank you for your time.
The best option is set trigger in database something like that :
CREATE TRIGGER movetohistorical
ON dbo.PRODUCT
FOR DELETE
AS
INSERT Product_H
SELECT * FROM dbo.PRODUCT
WHERE PRODUCT.id IN(SELECT deleted.id FROM deleted)
GO
The easisest way to do it is to implement a trigger in the database.
You can create the trigger using CREATE TRIGGER.
You don't have to worry about the trigger in your application code.
The trigger should be an AFTER DELETE trigger, which will execute whenever a row (or several rows) is (are) deleted.
You can read this article which implements nearly what you need (it implements a history table, but doesn't record the current datetime): SQL Server: Coding the After Delete Trigger in SQL Server. In fact, you have to make only a little change. In the sample, the insertion in the histroy table uses SELECT * FROM .... To do what you need, you simply have to add the GETDATE() function like this: SELECT *, GETDATE() FROM .... of course the destination table must have this date column at the end (if something goes wrong, simply specify the column names, instead of using the star).
Any other option will imply adding code to your application, and will require extra communication between your app and the SQL Server.
I have a situation where there is one record in database table i.e. 'abcde'. And User 'X','Y' and "Z' tries to update that record at the same time.
'X' modify abcde to abcdd
'Y' modify abcde to abddd
'Z' modify abcde to abeee
All changes should persist in database table.
Is it possible than please provide the solution.
If you want to persist all changes, then you will need at least one more database table that keeps track of all these changes...a log/history table.
The question is, how do you want to handle concurrency? If you don't care about it and you only want to keep the last modification in this single record table, then you don't need any further action, except the "logging" functionality that keeps track of all changes.
But, if you do care about concurrency and want to handle it in a different then you should look at running transactions with the isolation level that best suits your needs
As you want to log the updated records only for the concurrent case . Have a column of DateTime in the table and when you display the record to keep the track of datetime. So here is the use case.
First User updated the record -> Update the original record withchange in DateTime column value also.
When Second User try to update you found that datetime has been changed , it means it is no more Update , it will be an inset statement.
It will be similar case of 2 for third user.
Now you are left with all the three records in the database.Remember in this case Primary key need to have some incremented column also otherwise it will throw an error.
You can use Trigger and save records in another Table for every operation. Capture data Change(CDC) will also work in your situation.
For updating records, instead of querying the context and updating each record individually,
we currently use code that does DeleteAllOnSubmit on existing set of rows and InsertAllOnSubmit on new set of rows.
This worked fine for majority of our scenarios, as in if the same row (content) is being inserted/deleted, it gets removed even though we have an insert and a delete in the ChangeSet. Also, if the primary key is the same, and the records have different content, it converts it to a single update. The problem we have is the primary key’s match in a case insensitive manner, like say ‘abc’ and ‘Abc’, Linq thinks they are different keys and then tries to run the Insert first followed by the delete next which fails due to primary key violation, since for our database settings, both the primary keys are considered equal. Is there a way where we could make Linq use a case insensitive comparison, when it determines an update from the inserts and deletes in ChangeSet?
I am aware that the other way would be to query the database, and if the record is present, do a update instead of a insert and a delete. But we do have this logic for multiple objects and we would like to see if there are other options that work.
Thanks for the responses.
Let me try to explain the issue we have with a example.
Say we have two tables a Bank and a Branch where a Bank can have multiple Branches.
We are given a set of branches that need to set in the table. So the logic would be to delete all branches for that bank and set it to the set of branches we have.
The current code we have does something
DataContext dc = new DataContext();
var destBranches = dc.Branches.Where(b => b.BankID.Equals("123"));
dc.Users.DeleteAllOnSubmit(destBranches);
dc.Branches.InsertAllOnSubmit(branches);
If we went with the update route, for each branch, we have to see if it exists in dest, then modify its properties, if not insert it, and finally if any dest branch is not in the set of branches, delete it. We have lots of tables that this change needs to be made.
If you have SQL 2008 look into using the MERGE statement. It performs an update/insert in one shot. SQL 2008 s'procs also accept table-value parameters which would make this trivial.
You may also try Plinqo. It does all the batch update dirty work for you.
How would I get the primary key ID number from a Table without making a second trip to the database in LINQ To SQL?
Right now, I submit the data to a table, and make another trip to figure out what id was assigned to the new field (in an auto increment id field). I want to do this in LINQ To SQL and not in Raw SQL (I no longer use Raw SQL).
Also, second part of my question is: I am always careful to know the ID of a user that's online because I'd rather call their information in various tables using their ID as opposed to using a GUID or a username, which are all long strings. I do this because I think that SQL Server doing a numeric compare is much (?) more efficient than doing a username (string) or even a guid (very long string) compare. My questions is, am I more concerned than I should be? Is the difference worth always keeping the userid (int32) in say, session state?
#RedFilter provided some interesting/promising leads for the first question, because I am at this stage unable to try them, if anyone knows or can confirm these changes that he recommended in the comments section of his answer?
If you have a reference to the object, you can just use that reference and call the primary key after you call db.SubmitChanges(). The LINQ object will automatically update its (Identifier) primary key field to reflect the new one assigned to it via SQL Server.
Example (vb.net):
Dim db As New NorthwindDataContext
Dim prod As New Product
prod.ProductName = "cheese!"
db.Products.InsertOnSubmit(prod)
db.SubmitChanges()
MessageBox.Show(prod.ProductID)
You could probably include the above code in a function and return the ProductID (or equivalent primary key) and use it somewhere else.
EDIT: If you are not doing atomic updates, you could add each new product to a separate Collection and iterate through it after you call SubmitChanges. I wish LINQ provided a 'database sneak peek' like a dataset would.
Unless you are doing something out of the ordinary, you should not need to do anything extra to retrieve the primary key that is generated.
When you call SubmitChanges on your Linq-to-SQL datacontext, it automatically updates the primary key values for your objects.
Regarding your second question - there may be a small performance improvement by doing a scan on a numeric field as opposed to something like varchar() but you will see much better performance either way by ensuring that you have the correct columns in your database indexed. And, with SQL Server if you create a primary key using an identity column, it will by default have a clustered index over it.
Linq to SQL automatically sets the identity value of your class with the ID generated when you insert a new record. Just access the property. I don't know if it uses a separate query for this or not, having never used it, but it is not unusual for ORMs to require another query to get back the last inserted ID.
Two ways you can do this independent of Linq To SQL (that may work with it):
1) If you are using SQL Server 2005 or higher, you can use the OUTPUT clause:
Returns information from, or
expressions based on, each row
affected by an INSERT, UPDATE, or
DELETE statement. These results can be
returned to the processing application
for use in such things as confirmation
messages, archiving, and other such
application requirements.
Alternatively, results can be inserted
into a table or table variable.
2) Alternately, you can construct a batch INSERT statement like this:
insert into MyTable
(field1)
values
('xxx');
select scope_identity();
which works at least as far back as SQL Server 2000.
In T-SQL, you could use the OUTPUT clause, saying:
INSERT table (columns...)
OUTPUT inserted.ID
SELECT columns...
So if you can configure LINQ to use that construct for doing inserts, then you can probably get it back easily. But whether LINQ can get a value back from an insert, I'll let someone else answer that.
Calling a stored procedure from LINQ that returns the ID as an output parameter is probably the easiest approach.