|RE: [IBO] Cursor unknown error -504
> >No - the error I get is "Cursor Unknown" just as Bob defines it. And youI don't think it's the commit phase that's the problem. It's the refresh
> >were one of the kind souls who argued that it was a missing or invalud
> >keylonks property which MAY be the cause.
> >It comes back fropm the
> >Transaction.Refresh(true) method - that much I am certain. It
> does NOT come
> >from any attempt to update.
> Transaction.Refresh (True) actually tries to commit all pending work and
> close all open datasets. An "open" dataset is one that the application
> thinks is active. I'd expect a Cursor Unknown error to happen where the
> connection had been lost while a dataset was in the state of
> having posted
> changes but not committed; or where the dataset itself was in Modified
> state but the changes hadn't been posted. Transaction.Refresh
> (True) isn't
> going to succeed on an idle machine if there is an exception, in
> any case,
> since there's no fallback for rolling back in case commit fails, as there
> is with Transaction.Close.
phase, ie. the datasets are getting their buffers filled again and IBO
want't to get back that record it was sitting on. It tries to use the
Keylink to get that record but it can't get a record because the KeyLink
value is not valid any more for some reason.
Now it gets the exception, but can quite happily continue on it's way with
the record already in the buffer (i.e. it doesn't do the last bit of putting
the current values back into the record where the buffer cursor is currently
>My connections are quite sound - no XP,... constant sockets are always left
> I continue to advise looking at what's happened to the network connection
> during the idle time. The server will poll the client and, if the client
> doesn't answer, eventually it will just time out the connection, as it's
> designed to do. Look at the Wake Up On LAN setting in the BIOS, as I've
> encountered this often enough disabled on boxes bought with pre-installed
> OEM XP to deduce that it's virtually a default. If this is disabled, a
> sleeping client won't respond to polling.
open during all this. e.g IBExpert is open to the server sometimes with
multiple DBs open. If a connection is dropped, IBEXpert will be another one
to complain very heavily about loosing it's connection and ask to reconnect.
It doesn't. Just IBO complains.