>Guys,
>If you want another point of view (everyone has one):
>
>If you are going to do C/S with VFP and you do not at least consider SQLPT then you will miss the most flexible aspect of VFP C/S development.
>
>My company markets a web enabled C/S distributed database product. When we were evaluating tools for producing such a product, we required a RAD tool that leveraged a local database engine with enough power to handle tables with 250,000+ records and C/S development features that allowed full programmatic control over all server data sessions.
>
>At that point VFP3.0 was still in Beta, but initial tests proved that it possessed the local data engine that could handle the job (Historical Point: Many of our competitors at the time insisted that VB/Access was the RAD platform to accomplish the application...at this point they are no longer in business or the survivors have switched development platforms).
>
>At first view, the client/server development features of VFP3 were a bit disappointing; remote views were too inflexible to provide the product as designed. More research revealed that SQLPT exposed most of the flexibility that was missing from the remote view approach (the balance of the functionality was obtained via a C API).
>
>Each approach has its point of sanity. If the level of remote access that a view provides is sufficient, then it is....but by all means do not dismiss SQLPT without a careful evaluation.
>
>
>NOTE: Using SQL Server or any RDBMS w/o leveraging stored procedures is analogous to using tables without indexes (if the power is available...use it).
>
>
>Greetings,
>
>ED

ED,

I agree with your assessment, however, remote views can have quite a bit of flexibility if you code them by hand. Any remote view should be parameterized and optimized with SQL Prepare. For ad-hoc queries, SQL Passthrough is the way to go, and for situations where oodles of data munging is required to pass data forward or backward, a stored procedure is definately the way to go. I would use a combination of all of the above.

I would not limit myself to calling stored procedures to populate my UI controls. Beyond that, keeping track of all those stored procedures would be a bear. Basically, a stored procedure would have to be created for every cursor used in the application! If you have one database and several users writing different applications off the same database (our environment), well, you get the picture...