Jim,

here are some comments to your comments

>I would disagree with you here, the "navigagtional model" is a developer >oriented model of seeing data and has nothing to do with point of sale or >customer identfication. A real user in a Point fo sale situation does not want >to be scrolling through 100s or 1000s of customers to find the one that is >standing right in front of them. They want a rapid and simple search screen >that let's them enter the name, phone number, driver's license number, or some >other identifier that the customer has readily available and find that customer >immediately, no browse, no grid, no list box involved.
>

The user wont be "scrolling thru 100s or 1000s of records" but he or she may want incremental searching capabilities, or sometimes he or she may want this plain "previous-next" functionality (data entry situations where a specific change must be done in a series of records), sometimes the tabular view of the data in many situations is more user friendly ... As a matter of fact i dont see the reason for having to argue for something that is so evident for me. At the other hand we don't make any good to vfp community if we try to reject a proven functionality in order to justify some weaknesses of the product.
Finally, speaking of "navigational" as a developer oriented model you mean that we us developers wont mind to make our job done easier ???, which many times is using the "navigational model".


>The folks who developed the logistics management system for the US Military hat was used for Desert Sheild and Desert Storm might argue that point with you. Also the team that developed the security system for teh Eurotunnel might have some things to say as well.
>
>>What is needed is a robust transaction oriented, database centric application development tool, which should contain:
>
>>Real transaction logging capabilities for its local database machine but at the same time manageability (one could optionally select this capability)
>
>VFP's transactions are fully imnplemented and do not fail to do their job on system failures.

Everybody knows that if something happens to the File Server or to the workstation (because in a file server situation the workstation has the energetic part -so to say - of the relationship, the presaved data logically reside as buffers in the workstion), during the commit statement, data may (and will) be lost. What is needed is another level of caching in non-volatile (disk) memory, in addition with the existing buffering levels. Very very generally when a transaction fails during the commit statement, the next VFP session could be rollback the unfinished transaction
.
>Of course if you ae using a
file server then that file server might fail to do its job, but that is fully outside the scope of responsibility of the application
running on the workstation.

I do not get this. I don't separate the workstation from the server side of the application, in non client -server but of course in a multi user situation .

>Using a database server instead of a file server is the only way to solve
that problem.

This is my point: using a DBMS Server should not be the only way to implement a mission critical db application (and i don't think this is the only way to go. Again i don't thing we serve our business if we are rejecting a needed functionality, with aphorisms like the above ...)

This argument is also in conflict with the above described situations (Desert Sheild and Desert
Storm, Eurotunnel), which are proving the fact that mission critical application are needed (and we make attempts to implement them appart some inherent dificulties) in a non DBMS environment

> Why, as soon as the controls become "real windows" controls the inherent data binding capabilities go right out the
window (no pun intended). ONe of the nicest things about VFP for developers is the natural data binding it has without
righting code to get data from some place all the time.

I don't see why making the controls window-based would mean abandoning the VFP binding capabilities. After all, we all know the weakneses concerning for instance the when and valid events - still the controls beeing bitmap based.

>VFP already happily merges remote data with local data and the promise for the future is that this ability will get better.
>
I hope so, but still there are some application development systems which are considered more suitable for client server development, where i believe VFP could have been, (in the intel platform), a kind of Powerbuilder killer application.



>As I have said above the only folks who really find teh DBF format a weakness are those that have developed the code and techniques for exploiting the power of the dbf format. The unversalaity of teh dbf format is easily shut off by putting the table in a dbc with ingetrity rules. The dbc rules can even prevent the tables from being used at all unless a certain application is the thing trying to access them.

What this argument prove is a weekness in the dbc-organised database and not the no need of having a real dbms, which could have been made with or with out dbc, but off cource with a kind of dictionary...


>
>I don't see or hear anyone saying to forget the business needs, I do hear alot of people who are in a position to know saying that the internet and the ntranet are technologies of the future because they put the little business on the same playing field with the big business. The internet opens the size of a market for a business at an extremely low cost. Customer's are beginning to check a potential vendor out on the internet first and if that vendor doesn't have a site, well they just may not get the business.
>
>All these predictions and decsriptions are saying that if we, as developers, want to remain employeed and in demand over the next 5- 10 years, we had better get up to speed with the technologies of the inter and intra nets or else we will be left in the dust at some point.
>
>None of this is saying that we need to stop all the development we are doing now and suddenly switch to web based everything. It is saying start reading, start expeimenting, start playing with web stuff, because if you don't you will find, a short time down the road, that you are among those saying "Hey, how come ther's no work for a BlahBlah developer. Every add for work says Inter/Intranet experience essential."
>
>>After all, how many at the present time are making real money from the Internet ?
>
>Many many developers are making very comfortable livings doing strictly internet work, and the number is going to grow as time passes. Right now one of the jobs that is very easy to get and is high paying is Web designer (that is with experience).
>
>All that said, the line of business applications are always going to be needed.
> Those apps may or may not be directly related to the internet. But I feel very confident that those apps are going to find a requirement in their specs that says certain output and input opreaions must be capable of being accomplished on teh internet showing up gradually over the next few years.


I aggree with this one. My argument was a kind of rhetoric due to the facts that:
there are certain situations where , for some companies, the expectation of making quick money by using the Internet did not fulfiled
there are very few mature business applications, due to the lack of internet oriented development systems, which at the same time would focuse on the business and the functionality, and would help us to develop real business applications for the Net. I hope the next version of VFP will be such a tool
we many times oversee the essential in favor of the fancy and ephemeral ...