I have numerous applications that run days on end without freezing. Some of them are multi-threaded and handle
substantial volumes of data.

First thing people need to do is code to ensure transactions are all ended. While IBO takes care of most cases for you, I
clearly document that transaction handling is something you need to be explicit about in your applications. I am in all of
mine.

There's really very little I can do with the information I have. Is it possible you are running out of memory due to buffering
data and/or blob contents? I really need more to go on here.

I'd like to get this resolved so I'm willing to spend some time on the phone with you or in private reviewing your code to
see if I can spot anything amiss in how you are using IBO.

Let me know.

Regards,
Jason Wharton


--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
Jason,

We are getting two types of freezes. Both are driving our users nuts
and majority are threatening to throw the stuff out. We have managed to
reproduce both ourselves. Only a couple of times each and only when
hammering ther server. For example 10 instances of the app on three
diff PCs, each doing the process that is hardest on transactions and
network traffic. Unfortunately the clients can do it twice a day.

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.


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.


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 I have no idea why this could happen.

If the users can identify which PC instigated it and kill the app on it
then all others recover and continue. Sometimes, they cannot figure out
who was first and have to run around to 20 to 30 pcs killing the app or
rebooting the pc.

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.

Any help or hints are gratefully received.

Regards.

jwharton@... wrote:

> Please provide a better description of the problem.
> When you say freezing, what exactly do you mean.
> Have you traced or generated log entries to pinpoint where it is
> freezing in code?
>
> PS. I'm a bit under the weather right now, but I'll do my best to help.
>
> Jason