Have you tried stopping the interbase server and restarting it ?

----- Original Message -----
From: "Geoff Worboys" <geoff@...>
To: <ib-support@yahoogroups.com>
Sent: Thursday, 29 March 2001 04:24
Subject: [ib-support] gbak restore corruption


> 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
>
>
>
> To unsubscribe from this group, send an email to:
> ib-support-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>