I have an application which potentially does thousands of inserts to a SQL Server 2005 database. If an insert fails for any reason (foreign key constraint, field length, etc
You have proved your data is OK beyond all reasonable doubt.
FWIW,
I would prefer to move the insert into a SPROC and don't use the transaction at all.
If you need the UI to be responsive, use a background worker to do the database grunt.
To me, a transaction is for interrelated activities, not a time saving device.
The insertion cost has to be paid somewhere along the line.
I recently used ANTS profiler on a database application and was amazed to see intermittant SQlClient exceptions showing in solidly performing code. The errors are deep in the framework when opening a connection. They never make it to the surface and aren't detectable by the client code.
So...
The point?
It is not all rock solid out there, move the heavy work off the U.I. and accept the cost.
HTH
Bob