RE: MVC Architecture and transactions

Wow, what a statement!

"This I don't buy. If you have people doing "unexpected" things to your
database that could cause transactions to fail, then you have completely
lost control of your database. And at that point, no amount of commitment
control will save you; it will in fact be a false sense of security."

Really Joe, you need to get out in the real world more often... People doing unexpected things to the database is unfortunately a common occurance, at least in MY experience. These issues have only increased as more transactions are distributed across the networks. I won't try to make excuses for soft code, but I will say that time constraints placed on projects significantly limit the developer's ability to "harden" their applications. These common pressures result in immature code that is prone to failure. (This is, of course, an issue for management to address...)

We've all heard the old mantra "if it ain't broke, then don't fix it".... As always, the real trouble comes from how you interpret "broke". The code might be a shambles of two dozen different contractors over the last ten years, but if it somehow makes its way through its processes without puking its guts out, then "it ain't broke". Of course, this leads to "unexpected" things happening to the database.....

Sorry,
Eric