Jason Wharton wrote:

>>>> It's efficient real-time processing.
>>> Thank you *very* much for your input, Jason.
>>> I suspect the above will be very useful.
>>>
>>> Regards,
>>>
>>> /Dany
>> Be sure to have a look at the IBS_Base.pas module. Much of
>> what I've talked
>> about is built-in to this base class service module.
>
> I should also add that in IBS_Base there are some methods designed to
> process queues (records fetched from a TIB_Cursor) and in one of them I use
> the equivalent of MaxRows to determine a "batch" size that will receive a
> Commit. It would be inefficient to commit for every item of a queue but it
> could also be too long to do an entire batch without ever doing a commit.
>

First of all I want to thank you, Jason, for the pointers to services
from when I last pitched into the RPL thread.

I am playing around with the sample and I have a question.

<code>
procedure TsvcUCCSync.DoServiceLoopException( E: Exception );
begin
// Check if the problem is actually to do with a broken connection.
// If it is, set a flag so that the connection can be reset.
// It is not wise to do it directly here but in the service loop itself.
if E is EIB_ISCError then
with E as EIB_ISCError do
if ConnectionLostErrcode( ERRCODE ) then
KillCon := true;
inherited DoServiceLoopException( E );
end;
</code>

In the handler above it is very important that the KillCon flag is set
to true. Otherwise the service will just continue to try to use a broken
connection. OK.

In IBS_Base, SysExecuteService then repeat loop looks like this (pseudo)

<code>
try
... flags and stuff...
try
DoServiceItems;
except
on E: Exception do
HandleProblem( 'Problem in DoServiceItems', E );
end;
...more stuff...
except
on E: Exception do
DoServiceLoopException( E );
end;
</code>

So... when there is an exception in (for example) DoServiceItems the
DoServiceException handler is never called because the exception is
handled one level above. KillCon never gets set and the connection is
not Disconnected/Connected.

Maybe all I have to do is substitute
<Code>
HandleProblem( 'Problem in DoServiceItems', E );
</code>
with
<code>
begin
LogItem( 'Problem in DoServiceItems' );
DoServiceLoopException( E );
end;
</code>
in the inner try except block. Just curious as to the design. Am I
missing something?

Another question about the sample is if you use the WakeupThread. I can
not seem get my head around the TIB_RPL_Sync internals (which I'm not
going to use anyway) and whether there *is* an event "waking up" the
worker thread or if DoServiceItems together with DoServiceCanSleep is
considered enough.

A further small comment about having an IB_Event connected to the
WakeupThread would be very much appreciated.

And finally;

The GDS511 stuff. Is that for older versions of IB. I'm using FB 1.5.3
but have had problems with software unloading after using a localhost
TCP/IP connection wiht events.

Thanks a lot!

/Dany