Hi Walter,

>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?

Jim

>
>For example if you've got a form with a grid displaying records, a remote engine does not bring you advantages. If the form contains a combobox bound to a lookup table, still all lookup records have to be present at the local machine. Combining data from different source would be difficult, because of different userrights other relative paths: The data you can access from you workstation is not neccesaraly accessable from the server or just from another place. When executing SQL-views on the remote view, somehow the paramters have to come from either the server or the workstation: how does it know where to get it from ?
>
>IMO, there would be a lot more involved in making such application work transparent whether the engine is local or remote.
>
>I'm convinced, that there are ways to get this dream a bit more reality, and I see only ODBC play a role in this. As george said, we already have piece of this in the form of remote views. I think that any enhancements on transparency and ececuting remote code should go in this direction.
>
>*If* only VFP stored procedures could be called from an ODBC connection and processed remotely, I would be more than happy.
>
>Walter,