>>I know he is working exclusively with Fox and Oracle now.

What?! JVP?! Surely you Jest!!!!!!!!!!!!

>>uses stored procs exclusively. Like all sql server apps should.
>>yeah yeah ;-) but come on, what about editing huge datasets where a user >>might change just one field (e.g. gender, 1 byte) out of 250 displayed >>fields from a row that maxes out the SQL Server max record size of just >>over 8000 bytes. Either you write mucho code at both ends (one of the >>slaps against SQL Passthrough) or you have HUGE parameter saves just to >>update that one field. Yes I have heard of something called "dataclas" >>that may help a little ;-) but there are are other viable ways! And IME, >>words like "all" and "always" are just *inviting* a negative example that >>forces a defence rather than a discussion ;-)

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

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.

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.

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

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.

>>Yup just the one for now.
>>Does JVP know you're saying all this?!
I don't generally clear what I say through him. If he has done other .NET work then I may not know about it. You'll need to ask him.

>>As for being an authority. I consider John as much an authority as anyone >>here. John's experience in the enterprise counts for a lot.


>>Sure. I wish he'd talk about Oracle or stuff he has really got stuck into.
Don't know what to say here. Maybe he'll help with Oracle if he chooses to.

>>How does his question of what happened to the market related to either of your last questions ?

>>Well, if SQL server is "always" better than dbfs, then we'll have to >>recommend SQL Server to mom and pop, right? Or could it be an >>Orwellian "SQL Server is always better, except when it's not?" ;-)

You know what. Creating an application that uses dbf's is a pretty simple deal. I have apps that are around 9yrs old that still use them. Would I use them now ? No.

It is pretty easy to setup SQL server at a customer site. Me and Duff have been working on a commercial shrink wrap piece of software that uses MSDE as its base. This app (built in VB6) is designed to be easy to install by a user. We spent a great deal of time helping build that interface. It is also fully scalable from desktop to enterprise with NO code changes. It can be done. I know this because we did it.

Was it easy ? No. It took some time to get right. Primarility because we put the MSDE installer in our installer and that was a PITA. If we had been able to install SQL Server seperately it would have been a heck of a lot easier.

I have worked on some other shrink wrap programs with sql server and it has not really been that big a deal.

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

Thanks
Rodman