Walter,

SNIP
>
>Both I think. This has to do with the way VFP handles data. The info that requires the backend to do its job can come from different machines with different user rights paths, networkdrives etc. Solving this alone would be a major PITA. Honestly I don't think it can be done without having to make consessions about transparency. And that is one of the major thing we want to achieve.

Well I don't see why user rights, paths, network drives, etc. should be any different in a VFP-only implementation than it is today. Basically it is up to the user to make sure that rights are in place. I see it exactly the same in this scenario of 'servers' for VFP data.
>
>For example: If a SQL SELECT * FROM MyTable INTO DBF MyCopyOfMyTable is issued, where is it going to store the MyCopyOfMyTable ? Local or remote ?
>if Local (default dir), How it is going to execute a subsequent SELECT * FROM MyCopyOfMyTable Remotely ?
>If remote, This violates the rule that it would be stored in the Default dir, making existing programs fail in certain circumstances because they look for the DBF in the default dir.

Here I would see that INTO's (and similar) would go to the destination as directed by the program, as done today. There might be something that could be done with the addition of 'server' (support) code to add capabilities, but I sure don't see it as mandatory.
As for a subsequent SELECT * FROM MyCopyOfMyTable I see this really as a 'server' design issue that needs to be solved anyway for this wish - when a mix of local and 'server'-controlled tables are involved in any query the logic would have to (evaluate and) decide (perhaps with user-control override in the 'server') where to actually execute the query.

By the way, I don't think this is "easy" by any means. But I do think it is worthwhile, like OLEDB Provider and Intellisense clearly were.

Jim

>
>Walter,