Sorry Michel, but you can't. I went through this a couple of months ago. The only way is to drop the table and recreate it. So, instead of your script issuing DELETE FROM CT_PRIORITY, have your script DROP TABLE CT_PRIORITY and then CREATE TABLE CT_PRIORITY...
Not exactly elegant, and it obviously shouldn't be done while the database is in use since Murphy's Law says someone will try to hit the table exactly between the DROP and the CREATE!
Bummer, eh?
>One of our script to create the tables in SQL Server is defining the primary key field with IDENTITY. Then, there is another script which is populating the data into those tables. On the first run, it's ok as the primary key value starts from 1. On the second run, after we haved issued DELETE FROM CT_PRIORITY, the primary key is not starting from 1. Where do we have to go to reset that value?
"It is an important and popular fact that things are not always what they seem. For instance, on the planet Earth, man had always assumed that he was more intelligent than dolphins because he had achieved so much -- the wheel, New York, wars and so on -- whilst all the dolphins had ever done was muck about in the water having a good time. But conversely, the dolphins had always believed that they were far more intelligent than man -- for precisely the same reasons." - Douglas Adams
