Hi,

At July 19, 2004, 15:44, clementdoss wrote:

> There are less than 100000 records (91700).
> Well.. fetching 7000 records is not the intention.

But, that is a part of your stored procedure. That's why I asked what
was the performance of that query by itself. And, as Alexandre asked:
What is the plan of the query, when you execute it by itself? Also, do
you have an index on that field(BLN_CALC)? If in most cases, the
search condition is BLN_CALC='N' and that would be a small number
everytime, then you could try to create an index on that field to see
if there is a difference.

> I would like to
> update the balance field.
> You see, this application was build in paradox (by me), and working
> over a network (25 users). Now the pdx tech is old, and a
> client/server would be great for them. I am building the application
> using FB. I just did a test to calculate the balance of one account.
> And the same account, on the same network... well I'm sorry to say,
> but my old application kicked the new one butt.

Which development environment are you using?
Which connection components are you using?

> And I am using this
> stored procedure to calculate. I just don't understand. Is should be
> much faster since it all the calculation is done at the server.

Unfortunately, not everything will be faster than Paradox, but most of
it will be, but that might also depend on how you use Firebird and
which components you are using to connect. The same reasoning can be
applied to other database servers.

Also, can you give us the database header stats, this will give us the
transaction stats? You can use the command-line tool GSTAT. And, do
you have long running transactions? This can make a difference in the
performance, since there can be a lot of record versions that might
have to be dealt with, when running this stored procedure.

--
Best regards,
Daniel Rail
Senior System Engineer
ACCRA Group Inc. (www.accra.ca)
ACCRA Med Software Inc. (www.filopto.com)