If all you want to do is have GETDATE() return a time of midnight no matter what the time is, this will do...

SELECT DATEADD(dd,DATEDIFF(dd,0,GETDATE()),0)

I agree with JeffB... outer join, search for the nulls... haven't tested for speed but seems that it would be faster than either the correlated subquery or the concatenate method......

...and it's not just LEN... Try these in your order by...

'     '+CtrlCode

... or ...

REPLACE(CtrlCode,'T','')

Looks like a genuine Microsoft Bug... gee... that's never happened before... bet the boys in Redmond will...

Cory,

Using the data that JeffB originally posted, here's a couple of solutions that observe your 17:00 start and end times for reporting purposes... the first solution is similar to Tim's...

Just a couple of thoughts, folks...

I'm thinkin' that no-one considered the fact that it is possible to have a day with no faxes.  I'm also not seeing anything that considers...

Yes... and the reason why they are triggering each other is because of the setting I mentioned... normally, triggers do not trigger each other.

Check the database setting for recursive triggers... it's usually "death by SQL" to have this setting enabled.  Use the following to determine if it's on...

sp_dboption 'dbname','recursive triggers'

Obviously, you need to...

Man, I know what you mean with picking up other people's mess   Guess that's why this forum is so popular

Ermmm... nope... that's his posting status... "Rookie" is about 40 more than "Newbie"

Tim,

I don't understand why the use of an IDENTITY column would require 100 singleton inserts in the scenario you've given... also, why would you build a system that requires blocks...

yep... that'll work Tim... most folks don't come close to that level of correct simplicity when using a sequence table.  In light of IDENTITY's, though, I still can't see anyone intentionally...

If you have that many, you need to fire the 3rd party butt first out of a cannon into a stone wall

I did...

Forgot to mention... I changed the name of the table to TestTable to keep anyone from accidently wiping out a production table... just in case...

You'd probably get a faster response (a better one, too), if you posted the offending code, the table(s) schema, and give us a hint on the table size.

I absolutely agree with Richard and Tim... if you have dupes in a table, something is usually wrong.  However, it might not be your fault because of data you receive...