I think you'll want to look for an alternative way to calculate the next available value (such as setting the column to auto-increment).

From the IDENT_CURRENT documentation, regarding empty tables:

When the IDENT_CURRENT value is NULL (because the table has never contained rows or has been truncated), the IDENT_CURRENT function returns the seed value.

It doesn't even seem all that reliable, especially if you end up designing an app that has more than one person writing to the table at the same time.

Be cautious about using IDENT_CURRENT to predict the next generated identity value. The actual generated value may be different from IDENT_CURRENT plus IDENT_INCR because of insertions performed by other sessions.

In case when your table will be empty then this query will work perfectly.

SELECT  CASE    WHEN (SELECT        COUNT(1)      FROM tablename) = 0 THEN 1    ELSE IDENT_CURRENT('tablename') + 1  END AS Current_Identity;

I know there is already an answer but it really irks me that all of my searches along the lines of "get next identity sql server" came up with flaky solutions (like merely selecting the current identity value and adding 1) or "it can't be reliably done".

There are a couple of ways to actually do this.

SQL Server >= 2012

CREATE SEQUENCE dbo.seq_FooId START WITH 1 INCREMENT BY 1GOCREATE TABLE dbo.Foos (    FooId int NOT NULL         DEFAULT (NEXT VALUE FOR dbo.seq_FooId)        PRIMARY KEY CLUSTERED )GO// Get the next identity before an insertDECLARE @next_id = NEXT VALUE FOR dbo.seq_FooId

SQL Server 2012 introduced the SEQUENCE object. In this case, the sequence will be incremented each time NEXT VALUE FOR is called, so you don't need to worry about concurrency.

SQL Server <= 2008

CREATE TABLE dbo.Foos (    FooId int NOT NULL         IDENTITY (1, 1)        PRIMARY KEY CLUSTERED )GO// Get the next identity before an insertBEGIN TRANSACTIONSELECT TOP 1 1 FROM dbo.Foos WITH (TABLOCKX, HOLDLOCK)DECLARE @next_id int = IDENT_CURRENT('dbo.Foos') + IDENT_INCR('dbo.Foos');DBCC CHECKIDENT('dbo.Foos', RESEED, @next_id)COMMIT TRANSACTION

You will probably want to encapsulate all of that in a stored procedure, especially because the DBCC statement requires elevated access and you probably won't want everyone having that kind of access.

Not anywhere near as elegant as NEXT VALUE FOR, but it should be reliable. Note that you will get 2 for your first value if there are no rows in the table, but if you intend to always use this method to get the next identity, you could seed the identity at 0 instead of 1 (with IDENTITY (0, 1)) if you are dead set on starting off with 1.

Why would anyone want to do this?

I cannot speak for the question poster, but the book 'Domain Driven Design' and the 'official' DDD sample uses this technique (or at least hints at it) as a way of enforcing that entities always have a valid identifier. If your entity has a bogus identifier (like -1 or default(int) or null) until it is INSERTed into the database, it is potentially leaking a persistence concern.