>There is no compelling necessity to develop VFP application based on the only presumption that it will be moved to SQL-Server overnight. If client requests C/S application then I develop C/S application, if it requests file-server application then I develop file-server application. Period. Don't try to hide your ignorance behind scalability notion.
No, but as a developer, it makes most sense to make things as easy to port in the future as possible. This cna be accomplished in several ways. The best way, development with an n-tier environment, presents the strongest option - the layer most subject to effects from a change in the data engine, the data services layer, may require major redesign and recoding, but the effects should be relatively isolated to that layer, and as long as the interface to the data services layers remains intact, the scope of the damage from upsizing the data engine is isolated, if not minimized.
Using SQL as the basis for the data services layer further reduces the effects of the change, and makes it more likely that the data services layer interface will remain the same. Clearly, if one develops with the idea that views or recordsets are surfaced to the business objects and user interface layers, it'll be easier to transition to an environment where that is a requirement rather than a choice. Relying on index-oriented file operations as the basis for the entire application's data handling is less than optimal in the environments I deal with in most cases, and often the expression of data required as a statement of the problem being solved rather than a formula for solving it reveals new insights into the underlying data model.
IOW, there's no compelling reason
not to design with scalability and maintainability in mind up front.