I just introduced a new category for C4SC posts – Losing Your Street Cred. The other day after seeing a particularly alarming exception cross my inbox, I felt the need to share. This particular item is the inverse of the widely-known cliché, “Saving the Best for Last”. We’re actually starting with the best here as I don’t imagine I’ll run into anything as disturbing anytime soon. Moving forward, I will be using Losing Your Street Cred to call out things that don’t do a lot of good for your street cred as a professional software developer.

 

And now for the charter member of the Losing Your Street Cred category…

 

The following exception is courtesy of a recent check-in by one of our 3rd party development partners. I thought I’d share because I had never seen this exception in 8+ years of .NET development. NEVER. I’m sure most of you haven’t either. If this was an isolated incident, I might have thought it was just a simple mistake, an exclusion in the developer’s SQL Compare script or a hiccup in one of the new Entity Framework features that creates your DB schema for you. Unfortunately none of those were the case and we’ve been plagued by chronic rookie-like mistakes exactly like this one for the last few months. This one in particular was the worst so far…

 

Server Error in '/' Application.


Can't perform Create, Update, or Delete operations on 'Table(SomeTable)' because it has no primary key.

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details:
System.InvalidOperationException: Can't perform Create, Update, or Delete operations on 'Table(SomeTable)' because it has no primary key. 

 

Yep, that was a table without a primary key… It’s really not necessary to say much else here except that you’ll have little to no street cred left after a mistake like this. It’s amazing the type of issues you can prevent by actually testing a fix in an integration environment (or at a minimum, on your local machine) before considering something fixed. And please, if you ever make a mistake like this, just fix it instead of trying to explain it away. Your peers just might have a shorter memory that way…