>>>>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 :)

I think you misunderstand what a view based application is. It does not require ODBC at all if addressing VFP tables. It just is a way of working with the data that allows for parameterizing and creating less network traffic, denormalizing tables for purposes of display and reporting etc. It also means a lot less vulnerability to crashes that lead to corrupted data.

Without a proper framework I have no idea how well views would work but without a proper framework ( one far more sophisticated than I would have ever built for myself ) I wouldn't' be working with VFP.

And once you know how to write a view based, truly n-tier application with a real data layer, business layer, and presentation layer moving to a sql server backend is not very difficult.

Of course you can write a bad view based app, but that doesn't mean professional view based apps against VFP DBC/DBFs are not more flexible than table based apps.

We all know what the problems were in creating sophisticated applications in FPw 2.6 without views. I can't imagine voluntarily doing that again.

If you like DBFs for data that's fine, but that doesn't mean not basing your data layer on local views.

And as to the cost - SQL Express is free and IMO a far better solution than DBFs.

It is difficult to concisely describe the development environment of VFE / Remote views / and SQL server but I have never shown it to anyone who was not amazed at how easy and powerful it is

Disclaimer : though I do training and project mentoring for F1 Technologies and am a long time friend of Mike and Toni Feltman I do not profit from VFE sales. I also have a lot of respect for Mere Mortals and Visual MaxFrame ( and the work Hank Fay has done with Visual ProMatrix ). Cetin did some amazing stuff with Foxy Classes and I've seen other frameworks that had a lot to offer. I am not sure any of them have taken development of their frameworks as far as the Feltmans have but there I have a definite prejudice as developing apps with VFE has made me a *lot* of money <g>

In any case, I really do believe most VFP developers don't realize how much of a productivity enhancement the proper use of a professionally developed framework is. And a lot of resistance to using Sql backends, working with views and writing truly n-tier apps I think is due to the fact that VFP right out of the box is really a very unfinished product. You can do great things with it, but first you need a framework. And it is very very very very unlikely a beginning VFP developer even knows how much he doesn't know about what a framework needs. I would no more build my own framework than build my own car.

And in answer to your question below, I don't think table based apps are a good idea, I don't think you are doing clients a service by creating them and I definitely don't think you are saving them money

( and again be clear that when I say table-based I mean binding to fields in dbfs as opposed to using local views - which requires a framework and something other than VFP's god awful view designer. )

SET RANT OFF <g>

>
>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