Its a conspiracy I tells ya!

I had problems with a gbak in a previous database built using IB5.6,
where the backup of a valid database would restore corrupted. It is a
big system and I could not cut the problem down to something
demonstratable - so I ignored it :-)Backups are done externally - not
ideal, but other DBMS have to live with such shortcomings.

I am now reconstructing the system to run with IB6. I thought it
would be nice if gbak worked with this new version. At every step
along the way I have tested gbak using backup, restore and then
validation processing and all appeared to be going well. And then I
came to try and open a particular table immediately after establishing
connection and the server falls in a heap.


To try and be more coherent...

Development environment is Windows 2000 Pro, with SP1. Running the
Interbase as local.

Problem occurs in both Borland IB601 and Firebird 0.9.4
Both report the following error on termination

ibserver.exe: terminated abnormally (-1073741819)


No errors or warnings are issued by the backup or restore processing
logs (always done in verbose).


Everything was OK prior to performing the backup/restore (the database
had just been built via script and then import of required data). I
kept a copy from before the backup/restore (as always since my earlier
experiences with gbak) and the original copy does not experience the
problem.

The problem only occurs when I open this particular table first thing
after connecting to the database. If I open another table first I can
then successfully open the problem table and read all its data, if
any. The problem occurs even if there is no data in the problem
table.


Of course the problem table is one of the last defined out of 100+
tables, so it is very hard to cut the system back to something more
manageable for demonstration purposes. This is one of the simplest
tables in the database, it has a primary key and only one foreign key.
No computed columns or other complexities. It does have quite a lot
of int64 columns (19) which are actually for foreign key values, but
the constraints are not defined to the metadata. (It is a high volume
table and I did not want to load it with lots of indexes.) Defining
the table on its own does not reproduce the problem.


Has anyone got any useful ideas or suggestions on how I might try to
isolate the problem?


At the moment I am considering dropping gbak altogether, the risks
just dont seem worth it. This current problem does not seem serious,
but who knows what is hiding underneath. I would have missed the
problem altogether, since the table in question would not normally be
opened as the first table, except that I was checking on my
datatransfer processing.


Geoff Worboys
Telesis Computing