Действительно ли эта хранимая процедура ориентирована на многопотоковое исполнение? (или независимо от того, что equiv находится на SQL Server),

CREATE PROCEDURE [dbo].[usp_NewTicketNumber]
    @NewID int OUTPUT
AS
BEGIN
    SET NOCOUNT ON;
    BEGIN TRY
        BEGIN TRANSACTION
        INSERT INTO 
            [dbo].[TicketNumber] ([CreatedDateTime], [CreatedBy])
        VALUES
            (GETDATE(), SUSER_SNAME())

        SET @NewID = SCOPE_IDENTITY()

        COMMIT TRANSACTION;
    END TRY
    BEGIN CATCH
        IF XACT_STATE() <> 0
            ROLLBACK TRANSACTION;
        SET @NewID = NULL;
    END CATCH
END

I would not use RETURN for meaningful use data: either recordset or output parameter. RETURN would normally be used for error states (like system stored procs do in most cases):

EXEC @rtn = EXEC dbo.uspFoo
IF @rtn <> 0
    --do error stuff

You can also use the OUTPUT clause to return a recordset instead.

This is "thread safe", that is it can be run concurrently.

First off - why don't you just return the new ticket number instead of 0 all the time? Any particular reason for that?

Secondly, to be absolutely sure, you should wrap your INSERT and SELECT statement into a TRANSACTION so that nothing from the outside can intervene.

Thirdly, with SQL Server 2005 and up, I'd wrap my statements into a TRY....CATCH block and roll back the transaction if it fails.

Next, I would try to avoid specifying the database server (TestDB42) in my procedures whenever possible - what if you want to deploy that proc to a new server (TestDB43) ??

And lastly, I'd never use a SET NOCOUNT in a stored procedure - it can cause the caller to erroneously think the stored proc failed (see my comment to gbn below - this is a potential problem if you're using ADO.NET SqlDataAdapter objects only; see the MSDN docs on how to modify ADO.NET data with SqlDataAdapter for more explanations).

So my suggestion for your stored proc would be:

CREATE PROCEDURE [dbo].[usp_NewTicketNumber]
AS
BEGIN
  DECLARE @NewID INT

  BEGIN TRANSACTION
  BEGIN TRY
    INSERT INTO 
      [dbo].[TicketNumber]([CreatedDateTime], [CreatedBy])
    VALUES
      (GETDATE(), SUSER_SNAME())

    SET @NewID = SCOPE_IDENTITY()

    COMMIT TRANSACTION
  END TRY
  BEGIN CATCH
    ROLLBACK TRANSACTION
    SET @NewID = -1
  END CATCH

  RETURN @NewID
END

Marc

Я согласен с ответом Дэвида Холла, я просто хочу немного рассказать о том, почему в данной ситуации IDENT_CURRENT абсолютно не подходит.

У нас был разработчик, который его использовал. Вставка из клиентского приложения произошла в то же время, когда база данных импортировала миллионы записей посредством автоматического импорта. Возвращенный ему id был из одной из записей, импортированных моим процессом. Он использовал этот идентификатор для создания записей для некоторых дочерних таблиц, которые теперь были прикреплены не к той записи. Что еще хуже, сейчас мы не знаем, сколько раз это происходило, прежде чем кто-то не мог найти информацию, которая должна была быть в дочерних таблицах (его изменение производилось в течение нескольких месяцев). Мой автоматический импорт мог не только повлиять на его код, но другой пользователь, вставивший запись в это время, мог бы сделать то же самое. Ident_current никогда не следует использовать для возврата идентификатора только что вставленной записи, поскольку он не ограничен процессом, который ее вызывает.