Hi John,

just a few words of support. <s> Especially about xCase. A tool I wrote takes xCase, creates all the parameterized (on FK's, PK's, and FIND fields) views, moves everything to the Visual ProMatrix DD; then I create the remote model (or modify it on subsequent passes) from xCase; then the same tool I wrote creates all the remote views identical to the local views. ProMatrix, on a data-driven basis, makes the switch at runtime. Very sweet.

But if I had to massage large amounts of data, as contrasted with form processing, SPT would be the way to go. As would it be when on-the-fly views had to be created (although I'm likely to create a "close to" view in xCase, and then, because this is unlikely to be a modifiable view, select a cursor against it based on whatever constraints).

Using RV's is, it seems to me, going with the Fox, rather than against it.

Hank

>George
>
>I completely agree with "the right tool for the right job". We have a few Oracle SPs at one customer because data is so fragmented in some crazy pursuit of perfect relational structure that we preferred not to get involved and asked for a "black box" SP that they can manage.
>
>We use SPT in our Report Generator, also for site-specific interfaces to other apps.
>
>RVs are reserved for standard views against our own databases, especially for large rows where only one or two fields may change. Our new release includes the whole views dbc in the .exe and opens views using the VFP7 CONSTRING parameter; the connection string is encrypted in an ini file at each client. VFP graciously ignores CONNSTRING for local tables so we preserve backend independence. And it's secure. And it completely erases the contention issues that caused some parties to abandon RVs.
>
>Speaking of tools, xcase is a "must have" imho, especially if backend tables are in flux. The latest xcase makes it easy to synchronise tables and attendant views, no matter what backend. We have no worries at all about RVs as long as the changes are made using the CASE tool and synchronised with the dbc and backend.
>
>Regards
>
>JR