>>>Yeah, we use a parser class that builds the whole sql statement from objects created from metadata. ( I can't take credit for any of it, Mike and Toni wrote it all ) but it has the advantage of being very flexible and incorporating metadata props and any code you want to use in subclassed instances of the cursor, field or parameter objects.
>>
>>I remember most of it. Although it's now about six years since I last had my fingers in VFE, I still remember how many neat tricks were inside, made possible by the quite strict and straightforward OOP thinking applied.
>
>The design has held up very well as the framework has evolved since then. In the last three years Mike and Toni and I have been doing all our development against SQL server so there has been a lot of thought about that, especially about means of minimizing wire traffic. ( for example bizobjs that use two cursors - one for the list returned by the parameterized view for further selection - it contains only fields needed to pick a record - and a data entry cursor that contains only one record but all the fields. Makes a huge performance difference in some cases )
>
>What really amazes me is how many apps are being written in VFP that are table based rather than view based. that seems like the most masochistic implementation of Foxpro, but in almost every case where I questioned someone as to *why* they worked directly with tables the answer boiled down to they didn't know *how* to do it with views.

Hi Charles,
I don't understand your beef really.

I work with tables mostly and views occasionally.
Reason for that is very simple. Speed, simplicity of development and YES reliability.

If data volums are in VFP acceptable ranges (considering 2gig limit) then I see no point in cripling application by pushing it trough ODBC botleneck
just because your framework said so.
Ever since Optimistic Buffering and Transactions were introduced to VFP
with few other goodies (session object for instance) you can build
very clean and reliable apps that can work perfectly fine with native VFP dbcs/tables

I remember sadomasohistic attempt by company I was working for, to build everything CS back in mid nineties based on dev buzz back then. Remote views via ODBC! We will deploy VFP database to small clients and MSSQL to big ones. And all that was expected to work on W95 clients and NET 4.0 servers back then. Bwah ha ha ha :)

Well cool idea, if we were to have 90% of MSSQL back end implementations,
but instead we had 95% of SME clients being pi**ed of as hell by crippled underperforming CS mastodont ported on VFP database (RI inclusive)
via ODBC!
I never felt so embarrased in my entire life, watching dissapointed clients with CS app choking on saving 3, or retrieving 300 records...
I was just an employee on service calls, but will never forget that avelanges of embarrasement...

That prety much determined me to focus on developing solutions with
native VFP databases/tables. Believe me I never looked back. I am very happy with 4th generation of my own framework which is geared twds using native tables, and so are my users.

>>
>>>And this is my point - that too many VFP developers are not getting out of VFP what they could - especially in coupling it with the power of SQL Server back ends.

It took me almost 15 years to really need bigger back end then VFP native database. So I am just about to use one (Oracle) - Now! And of course will adopt my framework for it in VFP9, using all goodies that came along since VFP6 :)

Question:
If You manage to find/build sustainable solution that does the same (or much better) with native tables without ever forcing employer or client to use costly high level backends, don't you save them some money all along ??
That is what I understood was name of the game with implementing IT technologies/solutions.

Cheers :)
Sergio