Using transactions when inserting records in the Database with C#

I never have used SQL transactions, and in my case I know that I really will have to use them. One of the features of my App, is to convert an Excel file to a Database.

So I get the values from the Excel, build an array of strings with the arguments (to be sent to the SP) and some of the values I will insert directly in the main table, and others I will insert in secondary tables, and then I will get id's who will be in place of those values in the main table. What I am saying is that I have foreign keys, and it's why I do this.

So I think I am doing this perfectly but without transactions. But if anything goes wrong when I am inserting the values in the tables I will have to do the rollback.

So in the process I am using 5 stored procedures, one for each table. These SP's aren't exclusive to this process. They will be used in the App to insert records.

But I need help in where to use transaction. Shou开发者_如何学运维ld I do it in C# (app side) or in SQL Server (server side)?

For now I am using the SqlTransaction object from C# and it works in some way, because if I do the rollback he really cancels all the inserts, but the ID's that I have used in the transaction aren't available anymore. Only if I drop all the tables and create them again will those ID's be available again.

So I think that I am not using the transaction well and it's why I need help, to know how and where is better to use the transaction.

I think you are on the right track with how you are using transactions, the issue is that the seed for IDENTITY columns is not rolled back.

I'm guessing you are using MS SQL Server? To reset the IDENTITY columns without recreating the tables, you can use DBCC CHECKIDENT.

DBCC CHECKIDENT (table_name, RESEED, 99);

This would reset the seed so that the next identity value assigned would be 100. You of course have to record the highest identity value for the table prior to the BEGIN TRANSACTION.

I would only use this if there is a single writer process. In a multiple writers situation, it is likely to make things go BOOM unless you do some serious table locking first. In the case of multiple writers I think you are much better off writing the rest o the code so "holes" in the identity column values are acceptable.

If you are not using the Identity column for some other purpose, and don't absolutely require it to be sequential, try to get used to the idea that it will have "missing" values. They are not really missing, as they just provide a way to give each record a cheap unique key. You will get gaps when a record is deleted too, and therefore should not depend on the Identity column as a record counter either.

It's nice for our mind to see sequential numbers when we look at the table, but the cost is extra work for yourself and the database engine. It took me months to accept it.

The reason the value does not get reused is to help provide database integrity when that column is used as a foreign key.