Subject | Re: [firebird-support] Re: GBAK - Restore Failure from 1.5 on Linux |
---|---|
Author | Helen Borrie |
Post date | 2007-01-04T14:32:44Z |
At 12:39 AM 5/01/2007, you wrote:
the server. At index restoration time, the server is looking for a
file that it needs to read from (or write to) for some part of the
index-building operation and, for some reason, it is receiving a
blank file name. If it knew what file it was looking for, there
would be a filespec between the double quotes, instead of a space character.
Now that you mention it is Superserver you have installed on the
Windows machines, the next obvious question to ask is which model you
have installed on the Posix machine and what syntax you are using
there for invoking gbak. Could you give it exactly, please?
>Have double checked and apart from the fact that the directory isYep, sorry for that.
>/opt/firebird/intl there should be no access issues.
>The GBAK completes if we add in the -i switch, but with all of theSure, GBAK is just a client application that is firing requests at
>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.
the server. At index restoration time, the server is looking for a
file that it needs to read from (or write to) for some part of the
index-building operation and, for some reason, it is receiving a
blank file name. If it knew what file it was looking for, there
would be a filespec between the double quotes, instead of a space character.
Now that you mention it is Superserver you have installed on the
Windows machines, the next obvious question to ask is which model you
have installed on the Posix machine and what syntax you are using
there for invoking gbak. Could you give it exactly, please?
>I cannot see any problems with the data, however when I tried toIt has to read and write indexes when performing DML.
>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./heLen
>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.