From what you describe, I see no reason at all to move from VFP to .NET for what you want to do. Updating for the sake of updating serves no purpose.

Perhaps look at developing add-on applications for your core business in .Net and become familiar with it. But if VFP does what you want, why change?

1) You've proven that speed will (may) not improve.
2) Your costs will go up - VFP DB's do not cost $$, while SQL Server licenses do.
3) You have expertise with VFP - and none with .Net or SQL. Your indirect costs of development will by all means increase because it will take longer to develop things.



>Like a lot of other people, we have started to explore Sequel and .NET.
>
>Our business revolves around receiving large amounts of data in text files, processing them and placing the results in datatables. We process many files a day and files can contain 100,000+ records each. Thus speed is very important to us.
>
>I've condensed our processing down to bare minimums in order to perform equitable timing tests and can't get MS SQL to come anywhere close to FoxPro. We've accessed MS SQL tables in a variety of ways from both FoxPro and .NET. At its fastest configuration, it is still 8 times slower processing the same number of records as using FoxPro's seeks. This relationship between the speed of FoxPro and SQL remains consistent across multiple servers, whether run from FoxPro or .NET and whether the data tables are on the local machine running the tests or a remote server.
>
>We're much more proficient at FoxPro than SQL so we may be missing a way to get more speed out of SQL. We have run the SQL Index Optimizer and have placed all sql processing into a single SQL stored procedure.
>
>Is there anything else we need to be looking at to speed up SQL? Is this type of speed relationship normal by other peoples experiences? Or do we just need to accept that if we change from FP to SQL databases that processing that used to take 1 hour is now going to take 8 hours?