Jim,

>The benefits of such a component are numerous.

>My hot-button is data security. The 'server' component(s) could be located in a secure room with UPS power and managed by IT professionals, and since it could be arranged that all updating would actually be done on the 'server' then the incidence of damaged or corrupted tables would virtually disappear.

Not to forget that authorisation of the RDBMS (e.g. SQL server) can be inherited so that unauthorised persons cannot access the database. However new Errormessage have to be introduced indicating that authorisation has refused (Read and/or write) acces.

>There are also performance advantages with such a capability.

This would be a major step forward for those who want to access their database on a WAN via RAS (In my experience a growing requirement).

>There would also be new opportunities for those performing remote processing.

>The above is the proposal to be discussed. Following is one idea as to a possible implementation:

>A separate 'server' component with full VFP I/O capabilities would be installed on a centralize, secure machine also housing VFP .DBCs and .DBFs and related tables. This 'server' would have user-control through .INI (or other) specifications naming applicable databases/tables and other relevant control specifications.

Making VFP a kind of SQL-Server platform. This indeed would be very nice.

>Regular VFP applications would have an optional new SET command, say "SET SOURCES TO" that operates much like the "SET CLASSLIB TO" and "SET PROCEURE TO" etc.
>In this new SET command one could specify "Local" and/or network machine names (where the 'server' component is installed and ready for action).
>Whenever a SET DATABASE or USE command (explicit or implied, as with SQL-type commands) is executed, internal logic would locate the specific entity to do what is required to ready it for I/O operations.

<snip>
I think there is more to it. VFP is a great tool to integrate data from different sources. So it must be possible to use different engines transparent from eachother. I think about just opening different databases: remote and local ones.

Example: two tables (A en B) are opened in the application where Table A is stored locally and Table B on SQL server. If somehow (by utilisation of SQL indexes) it is possible to set a relation (SET RELATION) between the two. If a REPLACE Table1.atribute WITH Table2.Artibute, you've two choices: Process it locally of remotely.

Locally: The data must be send from the backend to the frontend, match the relation and the modified data send back to the server.

Remotely: This is more difficult, To succesfully execute it remotely it will have to upload table 2 and process it remotely. However since Table2 can be large a more intelligent form has to be invented.

Things get really get complicated, if not impossible, when local VFP functions OR complex FOR Clauses (with local and remote restrictions) get involved: the cohession of of the two components get so strong that this overcomplicates the issue and likely will result in too much complexity for the VFP team to solve.

IMO, The first step that has to be taken is to make remote processing possible for these cases that are obvious: Executing remote DML commands that fully rely on remote data (not parameters, which can be passed), such in :
- SQL SELECT commands where the tables are all remote.
- SQL SELECT .. INTO CURSOR, DBF, ARRAY etc.
- REPLACE ... WITH .... FOR....
- SEEK(), INDEXSEEK(), KEYMATCH(), SET NEAR, SET ORDER
- LOCATE
- SQL - INSERT, APPEND BLANK, GATHER, SCATTER, APPEND FROM,
- GO, GO BOTTOM, SKIP, SET RELATION, SET FIELDS, SET FILTER, SET KEY
- USE, SELECT < Workarea >, CLOSE DATA

And when this data is going to be printed, exported OR displayed(Browse or grid), the application downloads the data from the server with all the VFP xBase (b.t.w. I LOVE this word) settings. All changes (in a browse or grid) are directly written back (with respect to the buffering setting).

If in a given DML command both remote and local data is going to be involved, I think the only possible way is to execute it locally, by downloading the remote data.

To achieve the above, I think it is neccesary to have a REMOTE clause indicating a DML command should be executed locally or remotely. If a REMOTE clause is involved it should be possible to raise a warning (a SETting, maybe only for debugging) if it is not possible to execute it remotely and therefore reverts to local processing.

Walter,