There are a lot of factors to consider! My competitors seem to be using a large ASCII file in a non-database format. Maintainence must be terrible! But somehow they know how to find the data in that monster.

The calcs seem to me to be simple enough in most cases- 3 to four values from different tables with an algebraic operator.

I've heard of a 3rd party called CodeBase? that allows C to directly access DBFs and that may help with your suggestion of dropping down to C from within Foxpro.

Thanks a lot for your help.

>Do you know what file structure they are using? There are some 3rd party 'C' libraries that are pretty fast. Also, what are the calculations like? The slowdown might be in your calcs, not your data access. It would make sense that a 'C' developer could get more performance out of their code if they work on it...it is a much lower level language, so they have a lot more control. If it is a big deal, maybe you should look at writing the routines in 'C' (possibly still keeping your FoxPro shell). I am also assuming you have tested these programs on the same machine...and the FoxPro files weren't fragmented. Also, I am assuming that both programs are similarly either set to allow multi-user access or set to single-user access. There are a lot of factors to consider.
>
>
>
>>Hello !
>>
>>We have developed a VFP5 program called the Factory Commander that gathers data about a manufacturing process and produces reports indicating production results.
>>
>>The calculation phase of this program takes about ten times longer than our competitors who use C and Smalltalk. We have about 15 related tables and use SCAN/SEEK and SQL Selects to process the data and I believe we are maximizing the Rushmore technology.
>>
>>Any ideas on why our competitors are beating us using a 'database from scratch' in C ?