Hello Peter, reading this thread, and following it, I feel I too must comment on a few of your subjects..

>
>Yesterday I found this thread, which started at 20-09,
below is a response to all of it.
>
>Why this would be needed ?
- My Updated Response.
I have been thinking about this issue for a few days, and maybe came up with a slightly different response.

Maybe Microsoft does not need to create yet another Server Database. But, VFP is a fine tool as a front end tool to work with any Backend server.
So be it.
If VFP connection tools to odbc or ole-db or whatever someone wanted to use to connect to 'other' datsources in VFP were improved. the VFP product could be thought of and used as a true FRONT end tool of choice for database developers.

as an example. what if you wanted to create tables on a server, Sure you could do this in code, but why not graphically. ? right inside VFP.

a command could be build like

set database to mydatabase remote && Mydatabase could be pointed somehow
to an odbc database. using DSN ..

then what about use mytable alias mylocaltable && which resides on thes server.
a backend command could create the necessary command, to do something like
select * from mytable limit 0,0
and then send the command behind the scenes to the server.
what you now have is an empty read write cursor.

you then issue browse
and the same command, fetches 50 or 100 records.
sounds like remote views. but I ask why have to bother with remote views. ?

cant VFP be programed to create the concept of remote views on the fly, without having to program them.. ???

sqlexec can get a list of tables on the fly, can get field names from a odbc database.. ? why cant is just create the cursors necessary on the fly. no need for the vfp coder to create these things called remote views.? Isn't that what the server is for anyway. Stored proceedures. ?

I can use a server 'view' from a remote server, and the backend process what joins I need.... Why does VFP have to duplicate that functionality on local tables and cursors. I ask why not just add those type of features to VFP data engine... and let it fly.

Sure building remote tables, (sql tables) have rules which DBF dont require. Like adding PK to a table is a requirment ...

But the more I think about this. VFP could be BOLTED onto an ODBC datasource, and then let the data fly... Form fields connected to VFP cursors built on the fly, with something as simple as

set datasession to remote [dsn]

Why not ?

Bob Lee

In the beginning, there was a command prompt, and all was well.