Hi Marc.
I have done something similar in VFP, and also implemented on dot net.
I would suggest a mixture of keeping some selects for the very large tables (assuming you have a key and searching should be fast) but for smaller tables, store them in memory (e.g. in Dot Net dictionary, where you have a Pair (Code and value)
Things like Vat Rates , Discount rates etc could easility be stored in a Dictionary , and the difference in speed of accessing a dictionary (memory based) as opposed to going out to the database will be very significant, partculalry if you have to iterate through all say 100 lines if there has been a change in just one of the lines
Regards,
Gerard



>>>Thanks Gregory, it's an option. But it would not solve my main problem, being that I need the document to come up faster as well, and that my current rather slow routine delays it in a way that has been deemed unacceptable by the client.
>>>
>>>You can imagine the insult for an ex VFP programmer, can't you? :)
>>>
>>>
>>Can you return two datasets - one the table with data and another with totals and then utilize Gregory's idea?
>
>I think that would be more complex and intricate than to generate a sql. In this way I just need to replace the "calculate" method, and no other events are involved.