Mike

Thanks for the synopsis. your point about the permanent connection had not been raised in all the fury and it is interesting. I'll have to think about that. Also worth considering that you can force (or accidentally allow) RVs to keep a connection open for each of them...

But there is an overhead in opening and closing connections repeatedly, especially over a wan, is there not?

I'd be interested to hear whether SP users open and close connections or establish and use them throughout a session. I've always done the latter.

I've learnt a lot from this thread.

Main points:

1) The oft-stated "performance" advantage of SP because of optimisation/compilation etc, may not be such a concern.
2) VFP's remote data access is not "lousy". VFP can use SPT, SP or RV. All have advantages.
3) As always, the professional approach assesses all options and chooses appropriately without following simplistic arbitrary paths.

Looking forward: the latest versions of our hospital apps eliminate ODBC from the client and use http to communicate with dcom servers that manage it all. In this environment the "advantages" and "disadvantages" of RV vs SP are significantly skewed. Examples of the 900 station/30 country app should possibly consider this technique whose maintenance is the easiest of all.

Finally, I'd like to pose a question for those doing (or interested in doing) web development.
On the web, submitting a form sends all the fields back (except blank checkboxes). This eliminates the "only changed fields get updated" advantage of a RV because it mimics the "all parameters passed back" behaviour of a SP.
HOWEVER, generic code in a web server can take passed fields, use eval and replace ( ) commands to populate a RV row and then simply tableupdate() it. I'd be interested to hear how people manage web servers using SPs without a blizzard of specific code for each form, as is the case with VB. I'm assuming people are dissatisfied with the scalability of ASP and need something better.

Regards

JR