XPost: microsoft.public.sqlserver.programming   
   From: genew@ocis.net   
      
   On Wed, 13 Apr 2011 23:50:35 +0200, Erland Sommarskog   
    wrote:   
      
   >Gene Wirchenko (genew@ocis.net) writes:   
   >> 1) I call it up on one table, change one column value (not a key   
   >> column) from "Cheque" to "Check". When I try to exit the row, I get:   
   >>   
   >> No row was updated.   
   >>   
   >> The data in row 3 was not committed.   
   >> Error Source: Microsoft.SqlServer.Management.DataTools.   
   >> Error Message: The row value(s) updated or deleted either do not make   
   >> the row unique or they alter multiple rows(2 rows).   
   >>   
   >> Correct the errors and retry or press ESC to cancel the change(s).   
   >> and an OK button.   
   >   
   >I don't that grid, and make all my data modifications with scripts.   
    ^^^^^^^^^^^^^^^^^   
    A missing word?   
   >Scripts can be reusable. And trying to second-guess SSMS which has   
   >some funny quirks, is nothing I like.   
      
    Well, I have been running just scripts, blowing away the database   
   each time to minimise error possibilities. I thought that I would try   
   checking the checking with Edit Top 200 Rows, because it would be   
   easier. Yeah, right.>   
      
   >Hint: you learn more SQL, if you use scripts.   
      
    I know: it is my preference. And get bitten harder if you do   
   not?   
      
   >I can say whether the error message you got makes sense or not, since   
   >I don't know the table or the data.   
      
    It is a very simple table with one check for one column of "D" or   
   "C". It and two other columns get NiceString() done to them, but I   
   have the problem even when I reduce the trigger so that it is just   
   running through the cursor and writing it all without change.   
      
   >> 2) After I have run Edit Top 200 Row and have closed it, I can not   
   >> rerun my database creation script because the database is supposedly   
   >> in use.   
   >>   
   >> Have I done something wrong, or is this a bug?   
   >   
   >I would guess this is regular connection pooling. That is, the client   
   >API holds the connection for 60 seconds after disconnection so it   
   >can be resued. This is nothing specific to SSMS.   
   >   
   >The way out is   
   >   
   >ALTER DATBASE db SET SINGLE_USER WITH ROLLBACK IMMEDIATE   
   >   
   >That kills all connections against the database.   
      
    I may try that. I might just avoid Edit Top 200 Rows.   
      
    My scripts use explicit database selection, including select   
   master at the end to disconnect.   
    use Banking   
    go   
       
    use master   
    go   
   A pity I can not do this with Edit Top 200 Rows.   
      
   Sincerely,   
      
   Gene Wirchenko   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   
|