Home/ Questions/Q 88061
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-10T22:30:02+00:00

I have a MS SQL DB with various tables, and one field in particular

  • 0

I have a MS SQL DB with various tables, and one field in particular is causing me grief.

The Data type is set to varchar(100), however the field is limited to 60 characters.

If I try to put any string with more than 60 characters into the field I get an exception, ‘String or binary data would be truncated’. Although the string is shorter than the explicitly set data type, it still throws an exception.

Is there perhaps a DB setting that does this? What could cause the explicitly set data type to be overwritten?

Edit:
The triggers do not copy the value or insert it into another table and they don’t use the data either. – (Incorrect)

Strings that are smaller than 60 chars work fine.

All the columns that have varchar(100) give the same problem, but all the other columns accept correct values. The varchar(10) column works fine.

Any row in this table throws the exception if I try to update the field with a string longer than 60 chars.

I am trying to insert the data directly into the field using SQL Server Management Studio.

There is no padding involved.

Answer:

There was a second table where the column was set to 60. The update trigger called a stored Procedure that inserts the data into the ‘Denormalised’ table.

Thanks for all the help.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. What does the metadata function COL_LENGTH say is the defined size of that column?

    Do you have any default length constraint on that column?

    Assuming from the previous answers that this is not a trigger problem or an nvarchar issue, and you think the truncation is at length 60, what does updating that single column with SUBSTRING of length 60 and then 61 do? This could validate or invalidate your theory.

    Alternatively it’s possible that the database collation and/or encoding settings have changed since the original data was inserted. This can lead to some peculiarities. You say this is a copy of the original database. Is it sitting on a different SQL Server instance? If so, do both SQL Server instances have the same collation and encoding settings?

    EDIT: Use of the ANSI_PADDING setting that you discuss is deprecated, and the setting will be permanently ON in future versions of SQL Server. But the fact that you’re looking at this suggests that the value you’re trying to insert is padded in some way, perhaps with trailing blanks. However, this isn’t consistent with your SUBSTRING experiment results, which shows a cut-off at 60 characters. So I’m not sure if this setting is relevant, especially as it is always ON for a nvarchar column.

    Does any string of 61 characters cause the update exception? Also, although you’ve checked the immediate table triggers, are there any cascaded (indirect) triggers that might be causing this exception?

    • 0