SqlBulkCopy "column too short" error messages could be improved #1990
Description
Is your feature request related to a problem? Please describe.
When using SqlBulkCopy to bulk insert into a SQL Azure table, we occasionally get an exception message that states "The given value of type String from the data source cannot be converted to type nvarchar of the specified target column.". This exception contains an inner exception that further states "String or binary data would be truncated." Obviously, this type of error is received when using SqlBulkCopy to insert a value into a table row/columns that exceeds the length of what the table definition supports.
The problem is that in actual customer environments, there is frequently no way to further-diagnose the issue; we are usually not permitted to access the data our app attempted to insert, and even in the cases where we do have access, it's an extremely time-consuming process to save off the data in a portable format such as .csv, download it to a developer's machine, and use Excel or some other tool to get max lengths on every possible column in the data set (there sometimes being dozens or low hundreds to comb through).
If the exception message simply told us which column was affected and the length of the data we attempted to load into that column, debugging this type of issue would go from an hours-long process to seconds.
Describe the solution you'd like
The error message could be reworded similar to "The given value of type String and length {actualDataLengthHere} from the data source cannot be converted to type nvarchar of the specified target column, {targetColumnNameHere}."
Describe alternatives you've considered
We've considered building a mechanism that, upon receiving this exception, manually re-iterates through the data calculating the max length of each row and each column, in an attempt to achieve an exception message more similar to what is proposed above. However, in addition to being slow to run, this shouldn't fundamentally be needed; the built in error message should really just be improved.
Additional context
We are running both .NET Framework 4.8.1 and .NET 7, but are mainly interested in .NET 8+ at this point.