>>This is what pretty much I did; cut/commented the number of fields in half; then another half and so on. It only took me about 2-3 minutes to find the "offending" field. It would be nice, however, if SQL Server error message was more detailed.
>
>This blog post may help
>
>http://blogs.lessthandot.com/index.php/datamgmt/datadesign/how-to-find-what-column/

This is still a ridiculously complicated workaround for something that would take about six lines of code inside the SQL engine. Which M$ will never write. Friendly or even helpful error messages were never a deciding factor when selling a database engine, therefore M$ won't care.

And let's not get bogged down in this specific case. It's the same about any message concerning individual fields. Sometimes it happens that I do a join of a character field with integer, which works pretty much everywhere, and then it crashes on one instance of the database with a funny "error casting type char to int" - where there are no convert() or cast() calls anywhere. It takes some checking to realize it's an implied cast in the join, and it crashes because there's one record among 200000 which has the "DO NOT USE" in the character version of the field. And that SQL is utterly incapable of having a default (val("123blabla" would be 123, val("blabla321")=0 in fox, remember? - well, why not a null in TSQ?) no, it has to stop execution and refuse to say where did this happen. You've been a bad boy, go back to square one.

The only time I've seen it specific about a name is when it can't find it anywhere in its metadata. For anything else, make sure you got some hair to pull.