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

It really depends on the sproc you build... if it returns a scalar value, as does a function, then there's no advantage to a sproc and it's easier to use...

BigInt should do just about anything you need. BigInt holds a huge number ((2^63) -1) and much less behind the scenes processing is done by SQL Server on the Int and...

SOMETIMES the performance is similar... SOMETIMES a table variable will absolutely kill performance... read the following to find out why... pay particular attention to "Q3" and "Q4"...

http://support.microsoft.com/default.aspx?scid=kb;en-us;305977&Product=sql2k