Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Microsoft's position on Visual FoxPro and .NET
Message
General information
Forum:
Visual FoxPro
Category:
Conferences & events
Miscellaneous
Thread ID:
00908177
Message ID:
00913117
Views:
48
>Can you give me a case where, under these circumstances, it would be more cost effective to use a completely use a .NET solution rather than including Fox in it? To my way of thinking, with Fox, I can create one query to properly generate these reports against a data set from SQL Server. If, however, I go with a completely .NET solution, I have to create 30 different stored procedures (unless, of course, I set the compatibility level at 6.5 for the database, which is a bad idea.) and have 60 trips back and forth over the line, not to mention the maintenance of them. Using Fox, I can reduce this to two trips and have one query to support.

I am using a hybrid approach for complex queries. Even though our front end is completly in .NET, the .NET UI writes to a DBF requsting the name of a query or report to be run, along with an XML list of parameters. A simple VFP8 EXE on the server polls the DBF then the runs the queries on the server. Queries are returned as an XML dataset for the front end to display,and reports are FoxPro reports printed to a PDF file on the server. This has the following advantages:
- I didn't have to re-write our FoxPro queries or reports when we moved to a .NET solution. A huge time saver
- this method prevents huge a amounts of data from being passed over the wire
- the workstations don't have to be very powerful anymore. Just fast enough to run IE5.5
- our Dual Xeon 2.8 GHZ server, combined with the fact the the data is on a local drive to Foxpro, instead of on a file server, our report execution times have dropped by an order of magnitude.
Previous
Reply
Map
View

Click here to load this message in the networking platform