"string or binary data would be truncated" when deleting row

Im using Microsoft SQL Server Management St开发者_开发知识库udio Express to connect to our SQL Server 2005 (think its 2005, its version 9.000 something something). I have a table with one column that saves a lot of text. I have set the column type to text. When i have a row with lots of text in this column i cannot delete it. I get the message "string or binary data would be truncated" when i try to delete it. If i try to edit the row i get the same message. What do i do?

Considerable : i fix it by drop table and create it again, but i wanna a Solution!

Though I'm late to the party, when I review the original poster's description of the problem, it sounds like they are trying to delete the row from within the table editor interface. I just encountered this same issue with a table containing a "text" column with long text, and it appears that the issue may in fact be tied to a limitation in the editor itself. From my own investigation, it appears that you will not be able to edit a row in which a text column exceeds 4000 characters. I tested with SSMS 2008 R2.

Hopefully this will help anyone else encountering this error.

I had same problem and solved ... after selecting top 200 row of your table, click the "Show Criteria Pane"(left side of toolbar) now uncheck your ntext column (the column holding a big text you was talking about) now you can delete or update any row :)

Normally this kind of error happens when you're inserting a long value into the column that can't store it. Check whether you don't have any triggers or any related logic that could do that on your behalf when you're deleting the row (e.g. for logging purposes / audit trail)

I changed my data type to nvarchar(MAX) and was able to edit and delete as I saw fit.

I discovered there was a trigger that audited changes to the record (thanks Tomas Vana), but the target audit record had a limited varchar field for the action report (varchar(1000)). It was trying to audit the deletion of records that had varchar(max) fields...duh!

I changed the action report field in the log to varchar(max) and that fixed it... bloody obvious really...:)