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