Good article.

I use temporary tables and table variables and have found that within transaction table variables are faster. However, if large amounts of data are being used then temporary...

In my apps I store inputted dates as char(8) with any unsupplied parts filled with zeros. My rationale for this is that my apps always record dates in the...

I use Aaron's method.

I only ever have transactions in top level procedures. All nested procedure calls write an error to a temporary error table. My top level procedures...

I use the following code:

SELECT CONVERT(char(8),GETDATE(),112) + CONVERT(char(2), GETDATE(),114) + SUBSTRING(CONVERT(char(5), GETDATE(),114),4,2)

I always perform read ahead checks on the values passed into a procedure to confirm that they won't cause any integrity violations. This can be a little time-consuming, especially...

I tend to find that multiplying the single quotes, whilst it works perfectly well, it can make the string harder to read. To solve this I use char(39) instead:

'SELECT...

In migrations I've done to SQL 2005 I've had collation issues where the collation of the tempDB is actually causing the problem. This usually manifests itself when using temporary...

In my databases I usually assign an identity integer as a primary key or a combination of integers. If I have a string that is a natural key, such...

I have a broadly similar situation in that I have approximately 100 clients using the same base application although the data is customised for each client, and the functionality is...

Steve,

It's a simple VB.NET command line tool that uses SMO/DMO to create databases and execute scripts. It takes connection details and an xml file that defines the scripts to...

We have most objects in their own file, the exception being the foreign keys. We use a VCS to record changes and our own tool to build databases based...

You could try adding a new field (TempID) to temporarily hold the values you currently have in your field, remove the old field and the add it back on to...

I agree that method two is better as it keeps the field names identifiable, especially if you use table aliases in queries. As to ID vs. PK I use...