Whenever I've had a problem with a process taking excessive amounts of time
and locking out other access to the cpu it has been to improperly indexed
tables. I will usually take each query in the process and execute just that
query to see if the results are reasonable and then analyze the plan for
those that take more time than they should. Unfortunately, it is difficult
to time queries and sub processes in stored procedures.

I wouldn't significantly change the way you are doing things yet until you
are able to identify exactly what is taking up the time and are unable to
resolve it with IB/FB.

HTH

Bill Meaney

>> > Our application has some processes that run for an extended period of
>> > time(up to 4 or 5 hours) as there is alot of complicated calculations.
>> > These processes are written with Stored Procedures (One main
>> > procedure that may call many other procedures.)
>> >
>> > We are experiencing problems where when these procedures are running,
>> > they take over the server. IBServer shows it is taking 99% of the CPU
>> > causing all other users to virtually stop when trying to access the
>> > server.
>> >
>> > We experience a similiar problem when users run complicated queries.
>> >
>> > 1) Is it adviseable to process these types of calculations in Stored
>> > Procedures or should they be written in C++?
>>