Hi Jim,

>>>I am going to keep this restricted to VFP databases and tables only (some reasoning given below).
>>>Others of course should feel free to submit wish(es) for similar things to address SQL Server, Oracle, Sybase, etc.
>>
>>I'll have to agree with George on some points. The complexity involved in such action would be too great to handle. The difficult part IMO is that the GUI and the Data Engine are to interweaven that it simply too difficult to get the most out of it.
>
>I'd like to get one thing clarified... Are you saying that this complexity is too great only for "external" table types (i.e. non-VFP) or for all table types including VFP databases/tables?

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.

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.

Walter,