>>Not necessarily. You should write the Remote View properly so that it pulls only the records you are interested in updating to begin with.
>>
>True. You could write the RV that way.
>
>>If you have a relatively weak SQL Server with a large amount of machines connecting to it doing heavy updates, you will definitely be better off using properly written remote views.
>
>SQL Server servers are generally faster, more capable machines that individual work stations. Any company not willing to devote a few bucks to a decent size hard drive and a bunch of memory gets what they deserve - poor performance. Sorry, I have no sympathy here.

True, but if you have several hundred individual machines running several hundreds of updates an hour each, and despite your neverending effort to improve your servers hardware you still have a lower-end server due to managements budgetary concerns, you can see how the servers resources can get taxed rather easily. I agree they should shell out the money for a decent server. Unfortunately not everyone has the ideal situation.

>
>>
>>Remote views also give you quite a bit more flexibility than SPT.
>
>I disagree with you, and strongly. RV's are constrained by the fact that they can only be one select statement. You cannot chain statements together. If the update has to hit more than one table - or there is any kind of conditional processing that needs to be done - RV's are out of the question.


All your individual points are correct - if you need the statement do be dynamic SPT is the best choice. We very rarely need to do this, but when we do we use SPT. I think we have 66 SPT views, compared to 993 remote. I was referring to setting view properties such as setting some fields updatable and not others, wheretype, fetchsize, maxrecords, fetchasneeded, etc. You can also reuse remote views without retyping it every time. Most of our remote views are used in between 8 and 23 different parts of the program.


>
>>
>>Sometimes SPT is the best solution. It depends on you server/client situation.
>
>RV's are very useful and they have their place, but at the end of the day they are still a VFP-specific mechanism. I would (and do) advocate SPT as the preferred choice because SP's can be used by any app that needs them.


The fastest mechanism is actually precompiled SQL Views and SPs. These are server-intensive and therefore kill our shop, but if you have a high-end server they might be the way to go. Of course with VFP the only way to call them is via remote views or SPT....

We use a mix of all 3 types, mostly rvs due to server constraints, and the fact that the entire program was originally written on a VFP backend.

-Justin