Dany,

It seems to me you don't understand the sequencing of things. When an API
call is made and an errcode is returned then IBO does a series of processing
prior to any exception being raised. Among that processing is the
opportunity to set a flag indicating that the connection was killed. Then,
when that pre-exception being raised processing is completed you get the
exception actually raised with the flag already set. In this way, in your
exception handling code you can incorporate that flag in your decision
making process.

HTH,
Jason

> -----Original Message-----
> From: IBObjects@yahoogroups.com [mailto:IBObjects@yahoogroups.com]On
> Behalf Of Dany M
> Sent: Friday, December 15, 2006 4:28 AM
> To: IBObjects@yahoogroups.com
> Subject: Re: [IBO] Which is faster? Select First 3000 or
> MaxRows = 3000
> ?
>
>
> 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