Hi Enrique,

VFP has two aspects -

1. the database
2. the data-driven middle-tier processing engine

I think that that database aspect of VFP (i.e. pos.#1) could not compete in size or any other data-volume specific positioning in contemporary enterpise. Todays requeriements are terabytes of data, true transaction processing, clustering, centrally managed security, etc... Well, VFP database itself is fast, but for "large" system it is irrelevant because VFP is no longer used there for mentioned above resons.

The second aspect - middle-tier processing engine - (i.e. pos.#2) is an interesting topic. The problem is that while VFP-based development stays file-server or client-server oriented (not because VFP limitations, but because VFP developers develop systems so) - these architectures are no longer considered to be sclable enough to support thousands and thousands of users. The 100% thin client web-based virtual applications (i.e. not a monolitic 30MB executable) is the only viable scenario in enterpise development. And VFP gives all the power to developers they need to create such systems - at Arnica (http://www.arnicacorp.com) we successfully compete with Java and PHP based platforms by offereing VFP-powered solutions based on contermorary implementation such as web portal, web reporting, identity management, etc. And the question in all these cases was: "how many users does the system support? how many visitors were? how many clicks did the site handle?" I think that these are the right measurements for the "how big" question, if we want the answer to mean anything today.

Igor.