So maybe there is a failed mass-insert after all. Anyway, again, this is nothing you should waste your time on. Seriously.

Without knowledge of the table it is impossible to give a good answer. You can always do:

JOIN (SELECT *,

...

Do you have any reason to believe that this is related to SQL Server? On the surface it seems that you should look for a forum elsewhere for help.

Take a look at sys.dm_db_task_space_usage

Have a look at sys.dm_os_sys_info.

IDENTITY can give you gaps, and if gaps are a concern, you should not use IDENTITY. You use IDENTITY (or sequences in SQL 2012) to improve concurrency. Because IDENTITY is...

Eh, why? Deadlocks are nothing to be alarmed of as long as they are only occasional. If you have a deadlock each and every minute, you have a problem, but...

This is more likely to happen in SQL 2012 where they have changed caching for IDENTITY, so numbers may skip more abruptly when SQL Server is restarted. But there are...

It only locks one table at a time (and I don't think it locks the full table either, but only the smallest index).

Then again, there should rarely be any reason...

This is easily achieved with CTE that numbers the rows and then you can filter on rowno = 1:

; WITH numbering AS (

SELECT RecID, DateEntered, Status,

...

You can view possible suspects in the view sys.server_triggers. Beside being created manually, server triggers can also be added by Policy-Based Management.

Although, I would place my bets on that this...

If you try this on SQL 2000:

CREATE TABLE [dbo].[sequence_number](

[table_name] [varchar](50) NOT NULL,

[last_number] [decimal](15, 0) NOT NULL)

go

INSERT sequence_number(table_name, last_number) VALUES ('project_assignment', 99)

DECLARE @pak decimal(2,0)

UPDATE sequence_number

SET @pak=last_number=last_number+10

WHERE table_name='project_assignment'

SELECT...

There is no quick answer to this one. Luis gave you a query, but it has nothing to do with the last seven days. It just gives you a dump...

The solution is to install the most recent Service Pack. This particular warning with failure ID 29 is no longer produced.

SELECT * FROM tbl WHERE ltrim(rtrim(col)) NOT LIKE '%[^0-9]%'

Although this will also spit out negative numbers.

On SQL 2012 this is easier where you can use

SELECT * FROM tbl WHERE try_convert(int,...