Hope this makes sense.
Greg, thank you very much for taking the time with your detail answer. The example that I brought up, was with a scenario that I had previously had to do in Delphi and SQL. And I had done it exactly as you said in the second strategy. I didn't use SProc, but I used SQL statement where I'd pass the old Salesrep and the new one to a method that would generate SQL on the fly and all the processing was done on DB Server. Now why did I ask this question, is another question, since I had done the solution before.
Ok, I was reading an article on LINQ that was explaining the actual statements of LINQ don't get executed (delayed execution) until you are iterating through the result sets (that's another subject of it's own), but to the naked eyes, the way you would update the 500 customers in LINQ,
is done in the first style that you mentioned, client side and then LINQ turns around and packages it and creates a parameter SQL and does the job on DB server.
Then I started to think of this new project, how I should approach a bunch of "batch" jobs, NOW that they can easily be converted to LINQ style for the future, without much change to the approach.
So, my question of wrapping the 500 updates within a transaction was prompted by that thought. I still want to think this through that I can easily swap all the SQL codes with LINQ codes for the future.
Do I make sense?
Thanks for your input!
..ßen