Hi Jim,

>How do you (and Alex, please (and Alejandro certainly, if he's reading this)) think that this aspect should be handled? The possibilities that I see are:
>1) Integrate it into this wish completely.
>--- In this case I think that we will need some SQL Server (and other) competent folks to participate in the thread.
>2) Let it be it's own wish.
>--- It could, of course, refer to this wish (if it is submitted).

I don't know yet. I really like the idea of transparancy. However I'm aware that some complexity in behaviour of DML actions have to be solved. Sometimes its better to handle thing locally, sometimes remotely. IOW there should be a way to control this. One method is by adding clauses to the DML language.

I don't think it matter much whether the remote database is a VFP database or a SQL database. Sure, some functions and commands don't apply to SQL data, but i don't see a problem in raising an error or warning in these cases. I don't think other DBMSs are that different that it is impossible to write a piece of middleware which takes care of translating the xBase commands into SQL equivalents.

If we take a look at VFP now, we can see that a small part of this is already implemented with remote views via ODBC. Updates on remote views are translated to be processed on the SQL server. However I'd like to see that an SQL - SELECT command executed with SQL-passtrough (SQLEXEC() function) to be replaced with a normal SQL command. Maybe this wish can be accomplished in just extending the usage of the same ODBC connection.

The difference that have to be written is that VFP recognizes a remote table and directs VFP DML commands into a translation module which on its turn translates it into DBMS and ODBC equivalents.

Walter,