Paul

> It's the same with equipment, if your complaining that your
> connection is up and down like the seat on the only toilet in a pub,
> then they can find the problem, and maybe replace or repair the
> equipment so that the problem goes away.

The only point I am trying to get across is that unless you have a dedicated
connection belonging only to you, or dedicated only to you then there WILL be
packets dropped. Interbase 5.6 could not cope - Interbase 6 can do better -
but we as programmers need to be aware that there is a problem and cater for
it. We can badger the service provider if we are getting 'droppouts' every
hour or so, but I am only getting a couple a day - usually late afternoon -
when I lose 10 to 15 remote sites. I just handle that and 'reset' the
connection. With IB5.6 that was enough to require a shutdown every other day
- unless it hit at the wrong time - when I got 100Mb growth in 30 minutes (
on 5Mb of data ) and had to bring the system down fast to restore operation.
Since Xmas that site has only been restored a couple of times for maintenence
reasons, running IB6, IBO - 24/7.

I've given up waiting for others to do their jobs. My customers expect me to
perform, and IBO and IB6 can do that even with problem connections.

From Jason

> > In all cases, some means of reseting the Interbase connection is required

to

> > maintain operation. I believe this is the area that Jason has been

working on

> > for IBO4.
>
> I'm afraid there is only so much I will be able to do here. I would only be

> able to recover under certain circumstances. If you were in the middle of a

> transaction there is nothing I would be able to do for you.

I just designed the updates so that I was not expecting to hold the
transaction. I really must look at CachedUpdate and see if it can do the same
job as my custom code just as most of my other custom code has been deleted
now I am using IBO properly.

--
Lester Caine
-----------------------------
L.S.Caine Electronic Services