According to this thread and you many others, the main problem is you have no programming or problem solving skills. Giving you code will not help with your understanding. I think a better way to help you is to show an example of how to test code. The follow test sample uses a temp table to hold test data. You can add any test data you like. The script uses the temp table to exercise the logic. This is called unit testing.
The first test increments the Id.
If OBJECT_ID('tempdb..#Developer') IS NOT NULL
DROP TABLE #Developer
CREATE TABLE #Developer (
DeveloperId INT IDENTITY(10, 1) PRIMARY KEY,
Id INT NOT NULL,
[Year] INT NOT NULL,
CONSTRAINT uniqueId unique (Id, [Year])
)
--Test data
INSERT INTO #Developer (Id, [Year])
VALUES (1, 2022),(2, 2022),(3, 2022)
--View data
SELECT * FROM #Developer
ORDER BY [Year], Id
--INSERT logic
DECLARE @Id INT;
DECLARE @year INT;
SET @year = YEAR(GETDATE());
IF EXISTS (SELECT (1) FROM #Developer WHERE [Year] = @year)
SELECT @id = MAX(Id) + 1 FROM #Developer;
ELSE
SET @id = 1;
INSERT INTO #Developer (Id, [Year])
VALUES (@id, @year)
--View data
SELECT * FROM #Developer
ORDER BY [Year], Id
Simply change the data inserted into the #Developer table to test how the code handles a new year.
--Test data
INSERT INTO #Developer (Id, [Year])
VALUES (1, 2021),(2, 2021),(3, 2021)
This is the simplest approach I can think of . Keep in mind that I would use the Id and Year as the primary key but I think a composite key is beyond your capabilities.
Lastly, the PRINT command simply writes to the Message tab which is handy if you need to see a run-time variable. PRINT is helpful for debugging.
Anyway, happy programming and learn unit testing.