Hi Walter,

You and Alex W. have both raised the idea of other RDBMSs and my comments that precipitated this wish began in a message regarding a SET ENGINE (TO SQLSERVER) wish expressed by Alejandro Sosa.

I deliberately kept my 'formal' thread (this one) for my variation of his idea limited to VFP databases and tables mainly to avoid the possibility of corrupting Alejandro's original idea. His was very curtly stated and I think it deserves additional discussion too. But I also have too little knowledge of SQL Server (or Oracle or other products) to feel comfortable discussing them, especially when it comes to the subtle details of those products. I can ask questions if knowledgeable people contribute comments but I sure can't offer solutions or alternatives.

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 admit that my tendancy is to let it be another wish, but I do practise democracy.

More comments follow yours below:

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

This now should wait for the decision above.

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

This, again, needs the decision on the first question posed in this reply.

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

Assuming for the moment that we are talking a strictly native VFP capability, I would be ready to have some very specific restrictions imposed in such a facility if the VFP Team encountered such design difficulties.

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

Assuming this list to not be exhaustive (for instance object ControlSource handling would be a requirement), such an implementation strategy would be fine with me. The idea is to have a very very useful set of native VFP I/O commands operate indistinguishably on local and 'remote' 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).

I dislike the xBase term because I always have the feeling that its usage in print is in a disparaging context.
I agree about updating changes immediately.

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

I see this as an implementation detail and however it is finally done it will hopefully be documented (at least to discuss performance implications).

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

Another implementation detail, I think. I must say that I would *hope* that no additional clauses would have to be added to existing commands/functions though.

Jim

>
>Walter,