>>>How have you dealt with this? [COST]
>>
>>Generally, the client provides the impetus for moving off the native platform; not all, or even the vast majority, of my system deployments use a backend to handle their data, especially when first implemented. If the application is not dependent on non-native-data file handling features for its basic operation, you can and should deploy with the native engine. My belief is that you want to take advantage of the SQL portions of the language in preference to the older procedural constructs; in most cases, it's less work to develop the data services layer this way. Doing this also helps later when you need to move to the backend environment; the same basic techniques and code style is used to manipulate the backend to extract and update data. I don't have to rethink the data services layer stratgey from a process-centric representation to a solution-set-centric representation.
>
>I agree that this approach make a lot of sense. I need to be able to go either direction depending on the client.
>
>I'm using Visual FoxExpress 5.0 which offers local views as an option. That makes it a lot easier to go to remote views. (I believe VFE 6.0 offers the same feature.) I chose to use local tables because I was new to VFP and there was so much else I had to learn. I think I made the right choice. Getting up to speed with O-O and visual programming in general was hard enough for me. (Don't learn as fast as I used to.)
>
>JVP, for one, doesn't like local views. What's your POV?
>
>BTW, Ed P. -- do you see the argument in my case (building a marketable app that can deploy with either VFP DE or SQL DE) for using lots of SQL and staying away from xBase only features?

As long as it's marketable, why not? You know my point here, C/S is known concept for years, all components available, it can be built in first place. Realistically speaking, VFP with SQL-features only will always be second-class tool in comparison with RDBMS.