>>I think the point is that all too often applications are built with crude substitutes for what would be regarded as a "real" database, only to discover at some later point that they shouldn't have punted this issue in the first place. One of the main reasons that this happens is that few programming languages have cleanly integrated facilities for DBMS functionality. FoxPro shines in this respect, because it is a powerful general purpose programming environment with integral DBMS features that were not merely added as an afterthought. Consider, for example, products like MS Outlook and Outlook Express. These products could really have benefited from being built on top of some sort of clean generic DBMS like Visual FoxPro, instead of the whatever-the-hell-it-is home grown data structures buried inside of them. Using a true database product to manage persistent data structures leverages the tremendous available power of modern DBMS software, and greatly facilitates application
>>integration. When you look at most real world applications, it's not hard to find persistent data structures of some sort that could benefit from residing in a real database, even if it's just a small one.
>>
>
>I think you need to realize that most of these apps do have a -real- DBMS interface via LDAP and ADO and automation; there are lots of things which benefit from a non-relational data model, and incurring the overhead of integration of a database into everything doesn't fly - anyone else remember PICK? There were many othr fail db-centric systems which failed.

And let's not forget about IBM's System 38, where the DBMS was built into the hardware. OK, that didn't work, and attempts to put the DMBS into the operating system haven't met with much success, but how about integrating a DBMS into a general purpose programming language? Visual FoxPro does that pretty well, don't you think? My point was that many, if not most real world apps can be done more easily and cleanly with a tool like VFP than some clumsy home-spun database-like thing (or even a real database) tacked onto a language like VB or VC++. VFP makes things so much easier, and the amazing thing is that it's also efficient. I hardly think that the database requirements of Outlook or Outlook Express would significantly tax the capabilities of VFP.

To the extent that these products do make appropriate use of generic database functions, those were poor choices to make my point. I guess I walked right into that, because I really don't know the first thing about them internally. From my simplistic perspective, I see them as nearly impenetrable black boxes with arcane APIs. This is a long way from the level of convenience of simply putting things into a visible VFP database.

I wouldn't say that VFP is the right tool for every application, or that one might not occasionally need to add a sprinkle of VB or VC++ here and there, but I think it's fair to say that more than 50% of real world Windows apps could be done better and more easily with VFP than any other programming tool. That's pretty impressive for a tool that most people haven't even heard of.

Mike