George,


>>I understand that a total transparency is very difficult, if not impossible:
>>I could handle a whole SQL-table by using a remote view (with background fetching) though the indexes attached are unreachable, so this makes a difference, yes. A significant one ? Maybe..
>
>As with all things, it depends on the circumstances.

True, but i *can* close the gap a little in thos circumstances.

>But they're fundamentally different at their respective core (unless, as I mentioned) you're using a p-view.

Yes I know, I'm aware that not all technical differences are going to be solved (at least in the near future), but it might be wise to take a step in this direction.

>I for one wouldn't like to see the above differences changed. I can still use one query (rather than 14 or so).

Im not talking about changes, I'd like to see enhancments. By no means I want to get a situation that VFP x code is not compatible with VFP x+1 code, because of these enhancements.

>>but the processing is always done on the ODBC client, not the location where it is stored. IMO, we would gain much, if it only where posible to let the processing done on the server instead of the client. It's hard for me to imagine that this would be a difficult task for the VFP team to implement. In this way we really would have a VFP-xBase server, (though its comunication language still is SQL), which is capable to overcome network bandwidth issues. This would avoid a lot of WEB, DCOM implementations.

>As I pointed out earlier on, without some additional costs on the server, you still have problems (for example, latency causing table corruption). If you're going to spend the necessary money to have the appropriate hardware (RAID drives, etc.) then the extra expense of SQL Server is worth the cost, simple you get things like the transaction log along with it.

Yeah, so .. ? Likely the database would also be on a heavy server. The majority of my apps run on a network server with RAID controlers onboard, regular backup schemes, etc.

Wat's that about latency ? Do you mean the disk write latency ? Yes of course, we still have this problem in all VFP applications. I don't see this as an attempt to get a full featured database server. As I know there is a lot more to it than just remote processing of DML commands. However it would be really nice to see at least remote DML processing being possible without:
1. Buying extra solutions to get ready for the WEB etc.
2. Writing a massive amount of custom code
3. To install and maintain (besides an ODBC driver) extra software
but with the abbility to make this as transparent as possible. If I can USE a SQL-view of VFP data which SQL is processed remotely transparent to the users, we've won a massive battle IMO.

Again, Why can we do this with SQL-server data and not with VFP data ?

>Fox native tables are made for the desktop. If folks need a backend server, then get a real one not a pseudo-one.

So no need for MSDE ? No, I just don't agree. The VFP backend server might not be comparable with other DBMSs like SQL-server and Oracle etc when it comes to security, data protection, scalability etc, but it can be a great solution for those (like me) who occasionally have to get VFP data run a simple DS program over a wan. I've got a few (standard) software packages which run on a 512 kps WAN with a bad performance. I can't get the client to install and SQL-server because of massive costs in licensing (100+ users) and maintenance.

A VFP server solution would have its place in the land of database software. I've bought a accounting system which runs on a MSDE database. The performance of this baby is sometimes real bad (Runs on a Intel PIII 700 Mhz, 128 MB workstation). MSDE crashed ones after which I had to reinstall my W98 machine, because I could not figure out how to either repair it or reinstal it. For these purposes I see application for a VFP accounting database on the server.

Walter,