cLabs

So I'm running a simple insert statement to move a bunch of data between tables in SQL Server, and I run across this lovely piece of feedback:

String or binary data would be truncated.

What this means is that somewhere in the dataset I've got a 33 character string destined for a 30 character column, or somesuch. This is frustrating enough doing a single row insert, but doing a mass insert of 2,000+ rows into a table with 30+ columns -- how they hey am I supposed to know where the offending piece of data is coming from? Argh, this drives me nuts. SQL Server has to know where the problem is in order to detect it, but gives me no lead as to where to look. Maybe there's a reasonable technical reason, that somehow SQL Server's method for detecting a truncation actually doesn't contain detailed info of where exactly the problem is. I might could conceive a scenario like this, if I wasn't too busy being frustrated. And now I've got to stop down into a time sink to write some code on the source dataset to find the offending data.

Of course, being a developer, I've written some equally vague error messages in my time. It's always tempting to skimp on dumping out diagnostic info, especially when writing this'll-never-happen-but-I-should-trap-for-an-error-here-anyway-just-in-case handlers. Sure enough, the weird case will happen, and diagnosing the problem will be all the more difficult because of the lack of feedback.

I find myself doing this sort of thing in case statements:


case a_var
when TYPE_A then do_type_a_thing
when TYPE_B then do_type_b_thing
else raise 'unknown type'
end

... thinking, this is a rarely changing enumeration, the unknown type exception will only raise during development when I've expanded the enumeration and will be plenty of information to remind me this is another spot to check (and yes, I know, I should just use one of the many switch statement refactorings, but don't mess with my example here...). Sure enough, something weird happens in production, and all I get is the ‘unknown type’ message. Sure would be nice to know at runtime what the value of a_var is. Why not do this:


case a_var
when TYPE_A then do_type_a_thing
when TYPE_B then do_type_b_thing
else raise "unknown type <#{a_var.inspect}>"
end

That may give me a foot up in solving a bug in production that might have an easy workaround.

It's usually faster when writing software to skimp on quality feedback, but the absence of this feedback can cost a lot of time debugging problems. It's either time now or time later.

The SoftwareAppreciation moral? Software costs time, and this is one of those sniggling details that makes it that way.

tags: ComputersAndTechnology SoftwareAppreciation