Press "Enter" to skip to content

Category: Myth-Busting

Extensions Are Important

Published 2015-12-02 by Kevin Feasel

Kenneth Fisher on database file extensions:

So what does this mean? Should we start naming our database files whatever we want? No, absolutely not! It means that you need to be extra careful when specifying the name of the files. You really don’t want to use non-standard file names. The confusion! The misunderstandings! Do you really want the operating system to think your database file is a really big picture? Or even worse (and while I realize this sounds like a stretch I’ve had it happen) you accidentally give your file a .bak extension. Then one day your automated process that deletes old bak files runs as the same time your instance is down. Bye bye database file.

You can use whatever extension you want, but be smart about it.  Also check out Sean McCown’s dirty fun trick.

Comments closed

Error Handling

Published 2015-11-27 by Kevin Feasel

Continuing my “classics” series, Erland Sommarskog has a three-part series (with three appendices) on error handling that will take up your entire weekend:

Why do we have error handling in our code? There are many reasons. In a forms application we validate the user input and inform the users of their mistakes. These user mistakes are anticipated errors. But we also need to handle unanticipated errors. That is, errors that occur because we overlooked something when we wrote our code. A simple strategy is to abort execution or at least revert to a point where we know that we have full control. Whatever we do, simply ignoring an unanticipated error is something we should never permit us. This can have grave consequences and cause the application to present incorrect information to the user or even worse to persist incorrect data in the database. It is also important to communicate that an error has occurred, lest that the user thinks that the operation went fine, when your code in fact performed nothing at all.

Error handling is a crucial part of development.  And given that SQL Server has…peculiarities…when it comes to error handling, I highly recommend reading this series.

Comments closed

Nested Transactions Aren’t

Published 2015-11-06 by Kevin Feasel

Friends don’t let friends nest transactions:

Before getting into the details, I need to make one thing clear. Nested transactions are a lie. They do not exist in SQL Server.

This is part 1 of a three-part series by Gail Shaw.  Read the whole thing.  Also read Paul Randal:

Nested transactions do not actually behave the way the syntax would have you believe. I have no idea why they were coded this way in SQL Server – all I can think of is someone from the dim and distant past is continually thumbing their nose at the SQL Server community and going “ha – fooled you!!”.

Nested transactions are somebody’s attempt at trolling.  They succeeded.

Comments closed

Clustered Indexes Do Not Guarantee Physical Order

Published 2015-11-06 by Kevin Feasel

Gail Shaw on how clustered indexes do not guarantee physical order:

Do indexes (clustered or non-clustered) define the physical storage order of the rows?

No, absolutely not.

What indexes do is provide a logical ordering, a collection of pointers, that allow the storage engine to retrieve data from an index ordered by the index key, but that’s logical ordering, it specified nothing regarding the physical ordering.

Read the whole thing.

Comments closed