datetime comparisons in T-SQL aren’t always a walk in the park. One of the most annoying things that someone would need to overcoming is filtering solely on the year, month, and day component of a datetime field. This is further complicated by how .NET initializes a DateTime object.

When a DateTime object is instantiated without secifying the time, it is set to 12:00AM (midnight). When you pass the DateTime object to an SqlParameter, the following is sent over the wire:

     exec GetContracts @CreationDate = 'Aug 13 2004 12:00:00:000AM'

A further complication is that even if you pass creationDate.ToShortDateString() (assuming of course that your DateTime object in code is ‘creationDate’) to the Value of your SqlParameter, the afortementioned value is still passed to the stored procedure. This is because the stored procedure parameter is typed as datetime. Now, how do you overcome this?

With values in the table such as ‘2004-08-13 13:02:44.767’, you’ll never be able to match ‘Aug 13 2004 12:00:00:000AM’, and therefore no rows will be returned. The way I have overcome this problem is to make use of DATEDIFF and the dayofyear DATEPART. By using the following in your WHERE clause:

     DATEDIFF(dayofyear, @CreationDate, Contracts.CreationDate) = 0

This will return 0 whenever the day of the year is the same in both the table, and the stored procedure parameter. Any other day will either cause DATEDIFF to return a non-zero value. You can also use this if you want everything from this date and on (or before) by changing the comparitor to > or < as appropriate. Sproc on!

The ability to page in SQL Server is one of those things that everyone wants, but can’t quite seem to get from Microsoft. Many ideas have been posted, each claiming to be _the_ way to do it. In the spirit of mine is better than yours, I’ve implemented my own paging scheme.

A feature that is in the upcoming version of SQL Server is the ability to supply a variable to the TOP keyword. Well, as it turns out, this functionality does exist in SQL Server 2000. The only difference is the syntax. To limit the number of rows returned from a query based on a variable is to use SET ROWCOUNT @Foo. Don’t forget, however, to reverse that after the query by setting ROWCOUNT to 0.

The principle of which this works is that I return all of the primary keys in a table into a table datatype up to and including the record that i want to start at. Then I grab that value by selecting the TOP 1 from that temp table, ordering by the value, descending. Now I have the starting primary key value.

At this point, it’s a matter of looping through the records, row by row until I have filled my cache table with a single page’s worth of data. Once that is complete, I return the contents of the cache table. In addition, in the form of an OUTPUT param, I return the total number of rows in the table. I have this value as a result of a sanity check that stops the proc if we are requesting a page of data that is past the end of the table.

I hope this sproc finds you well.

5. Dan Black Belt

Your skills as a both a teacher and practicioner of MT-Do are now at a level few people will reach. You are most likely a worthy contributor in spreading the noble practice of MT-Do to others.

Take the MT-Do test