Hi,

At February 4, 2004, 06:34, Rohit Gupta wrote:

> There is no pattern (as yet). The larger the site (ie the more users)
> the more frequent the problem. The problme is not OIT/OAT and sweep is
> not the problem.

> We had two replies on the firebird forum who blamed ibo saying that they
> changed over to something else, which is why this got posted here as well.

It all depends on how you use IBO given the tasks/circumstances that
your application has to perform. Sometimes you can't rely on
autocommit and have to take control of the transaction yourself.
Also, it depends on the type of transaction that you are
using(i.e: committed or concurrency), because the transactions behave
differently.

> 1. Where the app just freezes.... doing things it does all the time, at
> random. The database is accessible to other users, the tcpip stack has
> not crashed (a problem in an early gds32/firebird combination),
> everything else runs on the client and sever, no resource is being
> hogged, cpu is not 100%, firebird is not busy. It is not confined to a
> particular site, server os or client os.

> My guess at present is that either ibo or firebird are waiting for the
> other side to respond. Which is strange as I would have expected both
> to time out in case of no response.

> The app can be killed in the task manager and a fresh copy might run for
> days before freezing.

Have you tried to trace the code? Maybe with a profiler or an
exception handler(i.e.: MadExcept from www.madshit.net ) that detects
when an application freezes. The profiler should give you a good
indication as to what is going on in your code. If the application
actually freezes, then the profiler should give a general indication
as to where it is freezing.

> 2. Where one WS freezes sometimes with no exceptions, sometimes with an
> exception in gds32. Once this happens, all other connections to the
> database stop. The database is not accesible to other users. The
> server is. There is no resource hogging, tcpip stack is intact, no cpu
> is at 100%. It has no preference for hw/ or os.

Here too, either tool mentioned above would help. Maybe a combination
of both is what you need, for your test environment. And, have the
exception handler compiled in the application that your users are
using, this saved me a lot of time investigating bug reports due to
exception errors.

> We are in the process of trying out FB1.5. However we need to go thru a
> few small sites first to ensure there are no sideeffects before giving
> the larger sites more grief.

I have all of my clients on FB 1.5 without problems. I have a few with
over 20 concurrent users. I did have some problems/performance hits
with FB 1.0 with sites above 8 users, when some intensive
process/report was running.

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