>>I dont want to debate the merits of stored procs with you. But I'll jump in with a few comments here...

great parthian shot! ;-)

>>Users dont generally edit huge data sets. They generally edit one record at a time. An order, a line item, a customer note. The art of good client server design is to work with small data sets.

Sure. That's what I said; one large, displayed row; a big one. The customer says they want to be able to see everything and edit whatever field is required.

>>Also having a user navigate through 250 columns seems like a UI issue to me. I dont know too many users that would scroll through a grid with 250 columns. I may be reading into your comment a little too much though.

Well, I wouldn't use a Grid, though I know some users who swear by them... I'd use an entry form here. I'll see if I can get an example oustide a firewall so you can see. The one I'm thinking of is a very large page where several very busy people want to be able to see everything, edit just the fields that matter and slap the save button.

>>Even if you use remote views you are faced with the same design decisions about the amout of data you download to the server.

OK, since you raise RV, lets look at that... I referred to saving; the RV automatically sends back only the edited data. No extra code required. That's why I tried to distinguish between rapid-fire appends (use SP) versus frequent, even simultaneous edits of large rows (consider again).

>>Also, stored procedures IS a best practice among the SQL Server developers I know. Can you create queries and send them to the server. Sure. The SQL MVP's I know say that it is around 50/50 stored procs vs passed in queries that they see in the wild. But when they have a choice they choose stored procedures.

That's fine. When I have a choice I eat steak; does that mean steak is always best? For everybody? ;-)

>>It is pretty easy to setup SQL server at a customer site.

Sure. We first used SQL Server in 1995. I think we fired our last customer using local tables to store data, last year. We still use dbfs for lookups, though; it allows mobile breast screening vans to use a dial-up modem against the SQL server at home base with reasonable performance. With the lookups in SQL server the radiographers refused to use it. I suppose we could have done some sort of downloading and caching mechanism, but dbf lookups work very well and it seems counterintuitive not to use them because of some sort of principle.

>>FWIW, I don't generally deal with mom and pop enterprises. I have been lucky enough to deal with larger clients.

The world would be happier if everybody felt lucky ;-) I too deal with large organisations, though I cut my IT teeth with people who made their fortunes with smaller customers- e.g. check out http://www.soeidental.com/exactprof/default.htm . FYI these guys wrote their own proprietary data storage routines using C++ to read from/write to the disk directly in the early 1990s! From memory they moved to ? SQL server at some point for some of their stuff as well. Can't remember. But they are a listed company now and the main player in 2 continents serving even one-man-band-dentists, and right now coming to a dentist near you!