ADO.NET SQL事务-仅1个对数据库的调用？

Question

I am reviewing some code which is inserting some data into a MSSQL Database (MSSQL2014) using a Stored Procedure.

Each row of data results in a call to that database.

This is obviously inefficient for a number of reasons; not least of which is the fact that a call has to be made over the network for each line of data.

I am surmising that if they simply wrap all these individual sqlcommand calls (ExecuteNonQuery) into a transaction then this will ultimately result in a "batch insert" of sorts. When you actually "COMMIT" the transaction, the call accross the connection is made.

Is this correct? Will this send all the sqlcommands to the server in a single call? I have not been able to find a diagram or documentation which outlines the communication between the client and server when a transaction is used.

--> Begin Transaction

-> ExecuteNonQuery
-> ExecuteNonQuery
-> ExecuteNonQuery
-> ExecuteNonQuery
-> ExecuteNonQuery
-> ExecuteNonQuery
-> ExecuteNonQuery
-> ...

--> Commit Transaction (my assumption is that each of the SqlCommands 
    are sent over the connection object at this point)

On a sidenote I am more inclined to recommend that the developer rewrites the routine to make use of SQLBulkCopy or TableValued Parameters. This would however necessitate the re-factoring of the database stored procedure.

Thanks in Advance

Answer 1

There will be no batch insert. Neither the client nor the server optimize across statements. ADO.NET has no machinery to understand the SQL that you are sending. It cannot optimize anything. The server could but does not.

There will be a performance gain by using a transaction like this because the inserts do not need to flush the log as long as the transaction is pending.

Answer 2

There will be no batch insert. All the transaction will do is give you the ability to commit the inserts so others would be able to see the changes. No performance gains and if anything a performance hit. Not knowing what you are wanting to do here it would be hard to give you a proper answer