Subject | Re: GBAK - Restore Failure from 1.5 on Linux |
---|---|
Author | dr_john_mp |
Post date | 2007-01-04T13:39:10Z |
--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@...> wrote:
Have double checked and apart from the fact that the directory is
/opt/firebird/intl there should be no access issues.
The GBAK completes if we add in the -i switch, but with all of the
indexes INACTIVE. If I then try and activate one of the ones that
previous failed, or delete it and try and add it, I again get the
I/O error for file ""
message.
This seems to imply its the Firebird engine rather than GBAK itself.
I cannot see any problems with the data, however when I tried to
delete all of the data to try the index on an empty table the
DELETE FROM MRP
failed with the same I/O error
I had identified that a field 'COMMENT' in the original may now be a
reserved word and changed it in the original before doing a
copy/restore - dont think there are any more.
Again the file backs up and runs happily on my desktop and my laptop -
both are Windows 2.0 Superservers.
>indexes?
> At 09:12 PM 4/01/2007, you wrote:
> >upgading a database from 1.5.2 on one Linux server to 2.0 on a
> >different server fails with errors shown below
> >
> >The same backup file does restore into a new file under 1.5.2 on the
> >original Linux server and into 2.0.0 on a Win XP desktop.
> >
> >I have also tried taking a backup on the Win 2.0 PC an restoring that
> >on the Linux 2.0 server with similar results.
> >
> >Ths index's that fail are simple, eg
> >
> >CREATE INDEX MRP_IDX1 ON MRP (STOCK_CODE);
> >CREATE INDEX MRP_IDX2 ON MRP (STOCK_CODE, PROGRESS);
> >where
> > STOCK_CODE VARCHAR(20) CHARACTER SET WIN1252 NOT NULL,
> > PROGRESS INTEGER DEFAULT 0 NOT NULL,
> >
> >All the data appears to have transferred so if pushed I could delete
> >the index's, do the backup/restore and then restore the index's,
> >
> >Any clues appreciated
> >
> >Dr John
> >
> >
> >
> >gbak: activating and creating deferred index MRPSELECT_IDX1
> >gbak: activating and creating deferred index MRPSELECT_IDX4
> >gbak: activating and creating deferred index MRP_IDX1
> >gbak:cannot commit index MRP_IDX1
> >gbak: ERROR:I/O error for file ""
> >gbak: ERROR: Error while trying to open file
> >gbak: ERROR: No such file or directory
> >gbak: activating and creating deferred index MRP_IDX2
> >gbak:cannot commit index MRP_IDX2
> >gbak: ERROR:I/O error for file ""
> >gbak: ERROR: Error while trying to open file
> >gbak: ERROR: No such file or directory
> >gbak: activating and creating deferred index MRP_IDX3
> >gbak:cannot commit index MRP_IDX3
> >gbak: ERROR:I/O error for file ""
> >gbak: ERROR: Error while trying to open file
> >gbak: ERROR: No such file or directory
> >gbak: activating and creating deferred index PK_MRP
> >gbak:cannot commit index PK_MRP
> >gbak: ERROR:I/O error for file ""
> >gbak: ERROR: Error while trying to open file
> >gbak: ERROR: No such file or directory
> >gbak: ERROR:action cancelled by trigger (3) to preserve data integrity
> >gbak: ERROR: Cannot deactivate index used by a PRIMARY/UNIQUE
> >constraint
> >gbak:Exiting before completion due to errors
>
> Is the server (user 'firebird') able to find/access the /opt/intl
> directory and the file fbintl? It needs to do so in order to read
> the collation rules for the character set. Check the permissions.
>
> Did you know that there is a switch ( -i) in gbak to restore without
>Thanks for the response
> ./heLen
>
Have double checked and apart from the fact that the directory is
/opt/firebird/intl there should be no access issues.
The GBAK completes if we add in the -i switch, but with all of the
indexes INACTIVE. If I then try and activate one of the ones that
previous failed, or delete it and try and add it, I again get the
I/O error for file ""
message.
This seems to imply its the Firebird engine rather than GBAK itself.
I cannot see any problems with the data, however when I tried to
delete all of the data to try the index on an empty table the
DELETE FROM MRP
failed with the same I/O error
I had identified that a field 'COMMENT' in the original may now be a
reserved word and changed it in the original before doing a
copy/restore - dont think there are any more.
Again the file backs up and runs happily on my desktop and my laptop -
both are Windows 2.0 Superservers.