Hi Walter!

I agree with you Walter.
I say more, I am sure that if an enterprise (Fox Software) still exists FoxPro would be a database server now, runnig also on LINUX box (what a sweet dreem isn't it).
As I remember on FPD 2.0 boxes was a sentence stating that such thing (server)was planned in future versions. (Maybe somebody have FPD 2.0 box)



>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..
>
>for validating the contents of tables, there are different approaches, not always applicable to both, but certainly there are coiches which are fairly simular. For example: you could let the business rules fire at the database level, which for both databases work fine.
>
>Frankly, if I think of it, I already use P-views in instances where I would use then in SQL also. In instances where I want to use native table, I see an equivalent in remote views with background fetching or fetch as needed (which by the way VFP also does with its native tables)
>
......
>
>Again, yes there are differences, but I don't see a problem in raising an error in these cases. I really see possibilities to close the gap of the design paradigms.
>
....
>
>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.
>
>Walter,