| Author |
Topic |
|
smsader
Starting Member
6 Posts |
Posted - 2007-06-11 : 10:35:56
|
| When I change some data in a row in my Results Pane and hit enter, I receive a message that "Data has changed since the Results pane was last retrieved." I click the yes button to "commit your changes to the database anyway," but then I get an error message telling me that my row was not updated. The message says "Error Message: The updated row has changed or been deleted since data was last retrieved. Correct the errors and retry or press ESC to cancel the change(s)." This time, the only option I have is to click the OK button. Can anyone give me some idea as to what I need to do to be able to update the row data in this way? Thanks. |
|
|
harsh_athalye
Master Smack Fu Yak Hacker
5581 Posts |
Posted - 2007-06-11 : 10:40:16
|
| I would say don't update records in the Results pane. Make use of UPDATE statement.Harsh AthalyeIndia."The IMPOSSIBLE is often UNTRIED" |
 |
|
|
madhivanan
Premature Yak Congratulator
22864 Posts |
Posted - 2007-06-11 : 10:48:13
|
| Query Analyser is specifically for doing thisDont use Enterprise ManagerMadhivananFailing to plan is Planning to fail |
 |
|
|
smsader
Starting Member
6 Posts |
Posted - 2007-06-11 : 10:50:29
|
quote: Originally posted by harsh_athalye I would say don't update records in the Results pane. Make use of UPDATE statement.
I have occasion to do mass updates that are not interrelated, which would mean I'd have to type hundreds of different SQL queries (one for each record). It's just not practical for some things. The ability to update directly in the tables is a great feature for non-DBA type people (like me) that was added with the SQL 2005 release. |
 |
|
|
madhivanan
Premature Yak Congratulator
22864 Posts |
Posted - 2007-06-11 : 11:02:22
|
<<The ability to update directly in the tables is a great feature for non-DBA type people (like me) that was added with the SQL 2005 release.>>Then why did you get the error? MadhivananFailing to plan is Planning to fail |
 |
|
|
smsader
Starting Member
6 Posts |
Posted - 2007-06-11 : 11:08:11
|
| Regardless of if I should use it or if it's indeed a good feature, it's something that is supposed to work and that I want to work. |
 |
|
|
smsader
Starting Member
6 Posts |
Posted - 2007-06-26 : 12:42:59
|
| I have lots of data that needs to be updated one row at a time, and being able to use this feature of SQL 2005 would save hours of time. Is anyone else familiar with this feature? Thanks! |
 |
|
|
smsader
Starting Member
6 Posts |
Posted - 2007-06-27 : 12:37:35
|
| I've found that I'm having the same error when I try to delete a row from this view. Argh!! |
 |
|
|
Maxer
Yak Posting Veteran
51 Posts |
Posted - 2007-06-27 : 12:44:01
|
| I never even knew you COULD do that... you say it used to work in the past? |
 |
|
|
smsader
Starting Member
6 Posts |
Posted - 2007-06-27 : 15:58:05
|
| Yes, you can even add or delete rows in the equivalent view of SQL 2000 as well. I guess no one does it, but it's much more practical for my usage than doing it all with SQL queries. |
 |
|
|
tkizer
Almighty SQL Goddess
38200 Posts |
Posted - 2007-06-27 : 16:06:33
|
| If doing it in SSMS or EM is more practical, then you aren't doing things correctly. You need to familiarize yourself with T-SQL. You can much more easily update data via T-SQL and it can be done in one script rather than having to do it per row.Tara Kizerhttp://weblogs.sqlteam.com/tarad/ |
 |
|
|
RocketScientist
Official SQLTeam Chef
85 Posts |
Posted - 2007-06-27 : 16:12:25
|
| That particular tool causes a lot of issues in databases. Specifically it holds locks, sometimes exclusive table locks, on the database. I really really wish they'd remove the feature. They probably won't, because they hate me. Seriously though, a more appropriate way to do this is:Take the mass of new data and upload it to an empty table in SQL Server.Write an update statement to perform the updatesDelete the empty tableThis resolves your main problem of not wanting to write a bunch of SQL Statements (you only have to write one), and also prevents the locking issue you haven't seen and the reliability issue you have. Done properly it would also help prevent future typographical errors from retyping all the data.I think that even (gasp) linking the table into Access would be less problematic than using the SQL Server tools if you don't want to go this route.rs. |
 |
|
|
|