I don't think I've ever heard anyone say that they're moving from VFP to SQL Server because SQL Server is faster. Both products have their strengths.

It sounds like you're processing the files on the client and then using a series of INSERTs to load the data into SQL Server. In which case, the transaction log is probably your bottleneck. Have you tried using DTS or BCP to load the data? Try achieve an environment where you can do non-logged bulk operations. Check out the topic Logged and Minimally Logged Bulk Copy Operations in the BOL.

-Mike


>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?