Hi Charles :)

>My clients are not Fortune 500 companies( I call them the Fortune 100,000 <s>) and my business solutions often have to be written while the client is using them <s> I seldom even have the luxury of a written spec, but just use very short iterative cycles to tune what I'm doing to what the client comes to realize he needs as he sees the app develop ( I was Extreme Programming before I knew what it was )
>
>But I stand by the idea that the framework is unparalleled as a RAD tool. The kind of apps you are talking about can be written at least as fast while you still have the power to write much more complex stuff with the same kind of efficiency.

>
>The framework lets me focus on the business issues, while using what I think of as a higher level VFP - features like security, data dictionary, easily switching data sources, form handling, toolbar handling, deployment as COM with no interface, integration with INTL, connection handling - all built in tested and pretty bullet-proof.

I understand your way. I do very simillar thing but in more focused (or reduced if you want) development pattern and with my own framework.
Reduced means that I don't have to bother to satisfy all possible outcomes(no COM, no WEB, no MSSQL). With less diversity, framework complexity in my case is much less. It is simply focused on Network App pattern and that is it.
When I am developing new stuff, I deploy pilot app very fast (hv my own form builders etc) then things start to develop by users interacting with it. Somebody called it Agile aproach. Sometime this is only way to gather *real requsts* and complete yr Business analysis. Menu solutions would have never been born, if there was not for doing it this way.

When I was younger, I actually tought that BA should be easy ; You go to Top Man (or Woman) and he/she should know everything <vbg>, but we both know this is not exactly the case ... :))

>
>The SQL backend is different from DBFs but is in many ways easier to administer. I can remotely connect to a clients database server and run a developer version of the app on my end to troubleshoot problems to decide if I am dealing with a programming bug or a data anomaly.


>
>Tell me this ( I realize that it has been so long since I've programmed a table based app that I may not be aware of some new technique )
>
>Common scenario - Customer table 10,000 records. Lots of fields, lots of child tables, everything very normalized. Orders - 100 per customer, line items 20 per order, payments 1000 per customer account.
>
>User on a workstation wants to edit orders ( yeah, I realize you proably wouldn't do this, just demonstrating parent-child-grandchild relation ) that match any of the following criteria = customer, customer location, order date range, order status, and make up ten others. Customer also has 6 other child tables that must sometimes be available during data entry, as lookup or validation. User may use all or none of the params. Network traffic a big issue. Remember, everything must be read-write, not jsut read only.
>
>Now design that with table vs views. How much wire traffic?
>
>Now have the user turn off his computer while using the app in the middle of an edit.

Absolutely no problems :)
All tables are buffered optimistically (5) and therefore detached really from disc at all times. Saving buffered tables is done (by generic method) in one go (milisecond?), wrapped in transaction band.
I very very rarely open/write table in unbuffered mode. Only case when I do is for counters/key generators. But that is single table per database.
I had single case of index corruption in almost 10 years now.

I understand point with sligthly reducing network traffic. But that is perhaps more important in networks where Sys Admins are your enemies <g> instead of actually working for you ;)

Cheers :)
Sergio