With Jason's help, I managed to find the cause and fix this:

First of all using IB_Monitor and bracketing the call to this Datapump
call with Monitor.Enabled:=True and Enabled:=False and looking at the
log file was essential.

The FB reference to a totally different table (Registry_Items) than what
was being operated on was the main clue we had. Jason suggested that
perhaps an Edit was still in progress. I looked above the call to the
datapump and sure enough found that I had just re-opened a table
(Registry_Items, although no Edit) that was supposed to be opened only
at the very end of the series of DB updates just before returning to the
main form. I simply moved that opening of Registry_Items to the end of
all the DB update routine calls, below the datapump, and the datapump
process worked without incident and without that bit of Registry_items
being in some limbo state in FB.

I want everyone to know that I could not have fixed this without Jason's
patient help. I am new to the Monitor log and how to interpret that
log. Been using these components to access FireBird (started with
Interbase) for so long I take them for granted. They are that good. Set
them up and forget them. The few issues I have seen using the 5.0 beta
he has addressed promptly and been gracious with his help for me who is
admittedly a parttime programmer and database user.

Long live IBObjects!

Thank you again, Jason,

Chuck

> Hello:
>
> I am finishing up going through my app's DB update routines after
> upgrading Delphi from 2007 to XE2 and IBO from 4.8.7 to 5.2.
>
> Already posted about some really weird errors. I found work arounds for
> them.
>
> Here is another (and it just happens to be the very last routine in the
> hundreds the precede it):
>
> I am using IB_Datapump to move one field's blob data from an import DB
> to the User DB. Tree_Defaults is a single record table.

[Non-text portions of this message have been removed]