Different slant...

EXEC sp_SpaceUsed yourtablenamehere

This may be a little faster... replace the #30 with the defined width of the column (or more)...

SELECT SUBSTRING(somevarcharcol,PATINDEX('%[^0]%',@String),30)

  FROM yourtable

Trys this instead...

SELECT CONVERT(VARCHAR(10),date,101)

... because the supbstring method on date castings will likely not five you the mm/dd/yyyy format that I think you're looking for.  And here's some other formating...

...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