Hi Rod

> I need a lot of latitude I guess :)

Don't we all :)

>We might also benefit from the fact that the database systems we work on don't really have that many updates.

This may be the issue in your case. I just saw the possibility of high-contention issues with the kind of locking techniques you outlined.

>AS a matter of fact I would posit that most database applications are read and insert heavy with relatively small amounts of updates.

Again this is down to the kind of systems you work with. Many systems that I have worked on have a high amount of inserts and updates so my experience is contra to your assertion.

>I believe that SQL server does a full write of the row every time anyway. If you see how triggers behave in SQL server they have an Inserted cursor and a Deleted Cursor when it does updates. Each of these cursors have the entirity of the row in them.

I think the issue with sending a full row is not particularly whether SQL server can handle it. For me, the main issue with doing targeted updates, the kind of update that could be done with dynamic SQL where only the affected columns are passed back to the SQL server, is one of network bandwidth.

I am not against sprocs in any way. However, sending a complete row that may consist of any number of columns but lets say, for argument's sake, 30-50 columns, where only a single column value has changed is definately wasting network bandwidth. If you have a high transaction system doing many updates, the network load probably increases exponentially (anecdotally, of course). This isn't a factor solely with DataClass as the use of sprocs is a "standard" approach when using SQL back-ends. If you use sprocs for CRUD, you get everything. Whilst I don't use it, LLBLGen Pro dropped the support of sprocs in its latest version and does only dynamic SQL generation for doing extremely targeted updates to SQL servers. This is a very highly performant process and one I like very much

Notwithstanding, the last enterprise-wide system I developed in .NET solely used stored procedures. Whilst they were generally built with a very powerfull code generation tool (developed in house), schema changes in the extremely large and complex database system were a nightmare because of the impact on and subsequent need to re-sync the sprocs - replicate this over development and test environments and I can tell you, it was a nightmare. If I could have used dynamically generated SQL, it would have save an immeasurable amount of time and complexity.

There are obviously advantages/disadvantages to the various approaches that have to be weighed against the requirement - one size doesn't generally fit all.

Cheers