simple rant: a CRUD day

i don't get all these trend about using stored procs for CRUD. i'm not a web app programmer, i mostly develop desktop apps. how to code stored procs for header and detail tables (textboxes above and datagridview below) ?

i would use stored procs for reports. but for desktop app CRUD routines? 怎么办 (how to do?)

using stored procs for simple database chores such as CRUD have an architecture astronaut ring to me. that's my impression of stored proc'd CRUDs

if there's a way to pass the delta of the dataset (header and detail tables) directly to just one stored proc (create procedure invoice_save @invoice_rec_id varchar, @invoice_header table, @invoice_detail table), i might use SP for CRUD

i learned that ms sql 2005 allow passing XML(passing list of rows is now allowed) to stored procs, so passing of header and detail to SP is now allowed, but then again, another problem persists, for datagrid's changes, does mssql 2005 accepts datatable's delta (datagrid's changes) through XML?

is enforcing business logic on C# middletier not elegant? Remoting and Webservices can also act as stored proc for rdbms(es) which don't have stored proc. it's also centrally managed, no need to re-distribute the business logic changes to other apps (desktop or otherwise). and also, these middle-tier stuffs are more amenable to horizontal scaling

in this age of B2B, do you think enterprise communicate to each other directly via stored procs? web services, ajax, remoting, etc also have these "centrally-managed" aspect in it

with all these great facilitators (dcom, rds, java rmi, .net web services, .net remoting) of centrally-managed code, would you still use stored procs?

why app programmers of the world, why do you code your CRUD on stored proc? do middletiers doesn't cut it?

P.S.
i will not convert my datagridview to to textboxes, users find datagrid editing very intuitive. would you like to earn the ire of my programs' users? :-)