At 12:03 PM 6/10/2004 +0000, you wrote:

>Win XP SP2 (Firewall Off)
>delphi 6.02
>IBX 6.08
>Firebird 1.5.1 1.5.1.4481
>
>Hi
> I am having a problem with Firebird Events which almost exactly
>follows a closed bug.
>([ 943087 ] Events producing high CPU load under certain conditions)
>The symptoms are exactly the same but the cause may be slightly
>different. I have written a test app which does the following.
>
>1.) Connect to Server.
>2.) Register for events.
>3.) Call stored procedure event in a loop 20 times.
> for i := 0 to 19 do
> begin
> Transaction.StartTransaction ;
> IBSQL.Execquery ;
> Transaction.Commit ;
> end;
>4.) I have written Error handling code that uses
>IBDatabase.ForceClose. This forces the app to reset its connection
>data when the connection is lost.
>
>Now the following steps will reproduce the problem.
>1.) Run the app.
>2.) Pull out client machines network cable.
>3.) Run the app (Error).
>4.) Put the network cable back in.
>5.) Run the app. (Now the server should start to consume CPU time)
>
> This reproduces the problem in about 1 in 3 attempts. The
>difference between the bug now and the one in the original bug report
>is that it seems that if the server is asked to produce events just
>after the connection becomes active it starts to consume lots of CPU
>time.
> Of course, I don't plan to use Events like this but the problem
>seems to come up with an application that I have written which does
>use some events. The other key part is that there is one laptop
>machine with the client software on it that uses WiFi for its network
>connection. Occasionally this connection is lost and the firebird
>server starts to consume CPU cycles.
>
>Does anyone have any ideas on this. I can send a test app to anyone
>that is interested.

I don't want a test app - I don't use IBX.

However, I strongly recommend that you check the version of the client
library (gds32.dll) that is being accessed by your IBX components. If it
doesn't have the same 4-digit build number in its version string as the
equivalent number on the server executable, then that is your probable cause.

It might also (or instead) be the case that the point is reached where the
IBX components just are not 100% compatible with Firebird any more. The
"workaround" provided by the "compatibility client" solves only one source
of incompatibility, which is IBX's cute, hard-coded check on the internal
version string of the client library.

Since Borland's connections decline to accept any patches to accommodate
bugs that Firebird has fixed and InterBase hasn't, and Firebird core
development can't be concerned or informed about changes in InterBase, the
paths will continue to diverge as each follows its own path.

./heLen