That trick works for any part of the date (ms, seconds, minutes, hours, days...)

SELECT DATEADD(hh, DATEDIFF(hh, 0, '2007-01-03 09:00:00.000') + 1, 0)

UNION ALL

SELECT DATEADD(hh, DATEDIFF(hh, 0, '2007-01-03 09:10:35.000') + 1,...

If no specific collation is specified for the column, the default for the database will be used.  You'll have to check your db setting to be sure of your collation.

Assuming that the function returns a scalar value :

SELECT dbo.fnFindPositionSupervisor (PositionID) FROM Employee WHERE  ID = 5

BTW it is considered a bad (if not worst) pratice to call a...

USE SSC

GO

create table MyTable

( Mychar varchar(20))

go

insert Mytable select 'Apple'

insert Mytable select 'ant'

insert Mytable select 'Ball'

go

Select * from MyTable where Mychar like '[^a]%'

Select * from MyTable where Mychar COLLATE Latin1_General_CS_AS like...

Can we see the code of those sps please.

TIA.

Lol that problem was more complexe than I expected. Anyone can figure out a better solution? I can't imagine that none exists (especially in 2k5). Solution other than...

Why, because this is really the last ditch effort for me.  And I'm not out of other solutions yet.

If you insist, but just remember that I didn't put you there!

Well I'm out of ideas then...

BTW, why can't you run that command on a dev server??

This might work better :

DECLARE

@strSQL nvarchar(1000)

,@dataSource varchar(100)

SET @dataSource = 'SomeDB'

SELECT @strSQL = 'SELECT s.ShowID, sd.ContactName, sd.ContactEmail, ' + @dataSource + '

FROM show s

INNER JOIN [' +...

How about this if you're not on a production server :

sp_updatestats

DBCC DROPCLEANBUFFERS

DBCC FREEPROCCACHE

Rerun both queries.

Good idea on the intern, cause my version would be something like this :

ctrl - a, ctrl - c, fire up note pad, ctrl - v, ctrl - s,...

Stab in the dark here :

Have you tried it with this column instead : rowcnt

No need to have a calculated field.  This value will never change so there's no point in recalculating it over and over and over and over and over and over...

While I don't pretend to know what are the exact limits of the optimiser to switch from seek to scan, I can say with some certitude that it will always...