Why is calling T-SQL INSERT with SELECT @@IDENTITY inserting duplicates?

I could have sworn I’ve done this kind of thing before without a duplicate row being created, but maybe something has changed, or I’m simply doing something weird?

Anyway, I have a table with the following definition:

CREATE TABLE [dbo].[speech](
    [id] [int] IDENTITY(1,1) NOT NULL,
    [speaker] [int] NOT NULL,
    [speech_date] [date] NOT NULL,
    [subject] [varchar](250) NULL,
 CONSTRAINT [PK_speech] PRIMARY KEY CLUSTERED 
(
    [id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]

When adding a new speech, I am using this stored procedure:

CREATE PROCEDURE [dbo].[add_speech] 
      @speaker int
    , @speak_date date
    , @subject varchar(250)
AS
BEGIN
    INSERT INTO [dbo].[speech]
               ([speaker]
               ,[speech_date]
               ,[subject])
         VALUES
               (@speaker
               ,@speak_date
               ,@subject);

    SELECT CAST(@@IDENTITY AS int);
END

If I run the SProc from SSMS only one insert occurs, and the new Identity key is returned as expected. But when I run the following code in my application, two duplicate rows are inserted! With different identity keys of course, and the identity returned is the second one.

affectedCount = command.ExecuteNonQuery();

if (affectedCount > 0) 
{ 
    succeeded = true;
    newID = (int)command.ExecuteScalar();
}

BUT, if I don’t execute the command.ExecuteScalar() in the C# code to get the @@IDENTITY a duplicate is NOT created!

What is going on?

Edit to Add: What is going on is that I forgot how to get the @@IDENTITY (or SCOPE_IDENTITY) and now I feel very dumb that I posted this here. Feel free to vote to close this question. I am embarrassed having posted it, but if I hadn’t, it might have taken me days to figure out what the problem was. I don’t think I am starting to suffer from Alzheimers, but it’s always a possibility!

>Solution :

You executed it twice – once via ExecuteNonQuery and once via ExecuteScalar. Don’t do that! Just use ExecuteScalar (since it returns one row and one column). If you explicitly need the rowcount, ExecuteReader provides that via RecordsAffected – or select @@rowcount as a second column (but then you still can’t use ExecuteScalar, because: 2 columns)