>The E-mail goes like this:
>
>Team,
>
>Allow me to reiterate some points regarding this issue. First of all I would like to reiterate that I.S. is not trying to make things difficult for all but rather would like to actively support your projects for the good of PLDT.
>
>The issue of not supporting Foxpro is not because of license cost but rather one of infrastructure efficiency. This development environment as advised by Microsoft was not meant for developing enterprise-wide applications. Running a Foxpro program over the wide area network hugs network bandwidth over the WAN links. This causes slower access and response times not only for your application but other systems running on the network links as well. Foxpro was really meant to support applications over a local area network only.
>
>If you really want to roll-out CDAS, TOBS, or your other systems throughout PLDT there are more efficient application development tools and systems designs like Visual Basic, InterDev, SQL Server or Oracle, active-X, transaction server, Web-technologies, and the like.
>

I'm not having a good day so this may come off more ascerbic than I want but here goes.

This I.S. person is an idiot!! Saying that running a FoxPro application over a WAN that was designed to run either locally or on a small LAN will be slow is like saying it will be cold in Antarctica. DUH!! The same can be said WRT to running a VB application using Access as the back-end. While he didn't use Access in his example, he was probably thinking it.

As others have said, distributed applciations require a different mind set when designing them. The application should use SQL filtering to create smaller data sets for the end user. More processing should be done on the server by the back-end (SQL Server or Oracle) or via COM objects. The server is better suited to handle this because of its superior power (usually) and its proximity to the data. VFP is very capable of utililizing either technique.