...and thank you for the feedback...

Or... don't let it default to INT...

declare @DateOfInterest datetime,

        @EpochDate datetime

set @DateOfInterest = '12/11/1962'

set @EpochDate      = '1/1/1970 03:00'

select CAST((@DateOfInterest - @EpochDate) AS DECIMAL(24)) *24 *60 *60 *1000  as n

Short, simple, nasty fast because there are no VARCHAR conversions...

SELECT DATEADD(mm,DATEDIFF(mm,0,GETDATE()),0)-1

I agree... I always spell them out all the way...

I don't believe BOL calls them "alias names" though.

The scripts offered will certainly work (although you may want to add WHERE so.XTYPE = 'U' to filter on tables only), but tell me please... why would you want to...

Not quite true... JOIN is an acceptable shortcut for INNER JOIN.  Additionally, LEFT JOIN, RIGHT JOIN, and FULL JOIN are acceptable shortcuts for the similarly named OUTER counterparts...

    USE Northwind

 SELECT...

Ben,

Why not make the ConsultancyBookingNumber column in the Consultancy table and IDENTITY column instead of using MAX+1?  Then, you wouldn't even need this procedure as the column would be auto-numbering...

Nicely done... You should publish this in the "scripts" section of this forum.

Although the DATEADD/DATEDIFF method will sometimes return a faster duration, it is slower than "convert(datetime,convert(int,GetDate()-.5))" if you consider actual resources used like CPU Seconds and DIsk Reads and Writes.  Here's...

I just can't bring myself to trust anything in an article where the author makes mistakes like the following...

"Remember that the BETWEEN clause retrieves values that are equal...

David wrote... "If I was to use the static table approach I would probably stick it in its own database so that it wouldn't artificially inflate the backups."

Yep, I know...

Thank you for the very nice compliment... I only hope it does what you need

Well done, David.  It's nice to see it when someone takes multiple methods and does a really good performance comparison.

It seems that generating a range of numbers in a temporary...

...and thank you for the feedback...

By the way, if you do put such an index on the table, you will never have duplicates again.

I only count 2 extra rows but that may be due to a simple lack of coffee...

Anyway... I think this might be what...