Solution 1 does not solve your problem, you also need to specify the names of the columns you want to populate with the insert.
For example:
SET IDENTITY_INSERT #Student on
insert into #Student (id, firstname, surname, joindate) values(5,'jh','hjf',GETDATE())
SET IDENTITY_INSERT #Student off
But as Jörgen Andersson states in his comment to your question - why do you want to insert a specific value for an identity column? It's not good practice.
Good practice is always to list the columns you are going to populate - it saves major reworks if there are changes to the table schema for a start. It also makes it more obvious that you are
not going to include the identity column :-) This is better:
insert into #Student (firstname, surname, joindate) values('jh1','hjf1',GETDATE())
What you may not have noticed is the effect of your override to the identity column. If you query my data after the two updates above I get
5 jh hjf 2018-02-01
6 jh1 hjf1 2018-02-01
SQL will not fill in that gap you created.
Worse than that, if I accidentally use an
id
that is already on the table I will not get any warning! This code
SET IDENTITY_INSERT #Student on
insert into #Student (id, firstname, surname, joindate) values(5,'jh3','hjf3',GETDATE())
SET IDENTITY_INSERT #Student off
results in
5 jh hjf 2018-02-01
6 jh1 hjf1 2018-02-01
5 jh3 hjf3 2018-02-01
If I have any processing that relies on
id
being unique, it's going to break. If I don't have any reason to have
id
as a unique number then why define it as an
identity
column in the first place?