No Thomas, in this case I know what I said, and I meant it that way. See Mike's reply also, as a case study. Corporations did not like the idea that a dbf could be opened by another program like Excel. I am stating this from my experience in several corps where the viability of DBF based software was discussed.

>Perry,
>
>>First, I'll help you out a little. DBF's don't lend themselves well to large systems. For the last 10 yrs or so many IT depts of large corporations have put VFP/DBase, etc. on the not approved list. DBF's being the main reason.
>
>NO, dbf/fpt/cdx is not the reason - it is file server based vs. "real" client server database. It might have been possible to grow a real client server using the dbf *format* (enhancing it to 2**31 or 2**63 recs and 2**63 B file size ) and adding the other goodies of real client server DB's. Others had problems as well - just let me mention page locking in SQL server<bg>. I am almost certain you mean the access pattern as well, but written this way it muddies further discussion <g>.
>>
>>For the rest, you're going to have to do some keyboarding yourself. Try finding a comparison of SQL Server, Oracle, DB2 and tell me how Foxpro fits into that equation.
>
>No argument here. But Vfp might have been a great alternative to the last two letters in LAMP, WAMP and so on: earlier versions of MySql being slammed as being useful mostly in Read-Heavy Web-Apps sounds fitting even for file based access if housed on a web server <bg>. But that water under the bridge has already rained again a few times from before ASP to the development of ASP - and with ASP.Net MS is beginning to gain real traction in that market...
>
>regards
>
>thomas