Howto Fix Firebird Corruption

what to do when get message "internal gds software consistency check (can't
continue after bugcheck)"
Such a message can occur because of database corruption .

This can happen with the stand-alone default installation or
with the network Firebird Server configuration. It is usually
casued when the database file is directly accessed when something
else is already supposed to be the only thing to access it. dir=ltr " ">
For example, corruption may occur if using stand-along installation o

f AyaNova if you copy the AyaNova database while you are presently
logged into the program
Or another example, if you are using the netowrk Firebird Server

configuration, is that you directly copy the AyaNova database
while the Firebird Server is supposed to be the only one ever
accessing it.
A possible way to fix this is that you need to perform a

Firebird backup and a Firebird restore, and the restored
database may have the corruption repaired.
If you are using a stand-alone default installation of

AyaNova, send the following to [email protected] if you
do not have the Firebird Server 1.5 installed and running:
-identify the error message you receive, and exactly what you are doing that
results in this message. For example, if you receive this error trying to delete a
client, tell us that plus the name of the actual client you trying to delete.
-zip up your AYANOVA.FDB database file using WinZip and attach to your email
-include in your email the AyaNova Administrator username and password
-also zip up the ayalog.txt file using WinZip and attach as well
Otherwise, if you do have the Firebird Server 1.5 installed and running (or
Firebird 2 if using AyaNova 4):
1. First, run a gfix against the database to confirm it shows errors (similar to
below, but enter your own path and your own user and password for Firebird)
gfix -v -full C:\AyaNovaData\AYANOVA.FDB -user SYSDBA -password masterkey
If there are errors, they will show such as
Summary of validation errors

Number of record level errors : 1
Number of database page errors : 49
If there are not errors, than you know the database is not corrupted.
2. If the database shows errors and is corrupted, perform a backup of the

AYANOVA.FDB database (refer to the AyaNova v3 Manual section "Backing up using the
network Firebird server" page 587 or the AyaNova 4 Help section if using AyaNova 4)
3. Then perform a restore of the database. (refer to the AyaNova v3 Manual section
"Restore the database with a network Firebird server" page 590 or the AyaNova 4
Help section if using AyaNova 4)
4. Now run the gfix as outlined above again. If errors no longer show, than the
database corruption has been fixed. If errors continue to show, backup and restore
again. If errors continue to show, than the database is not recoverable and you
will need to restore from your backup from before the corruption occurred.
Firebird Home Firebird Home Prev: Command Line OptionsFirebird

Documentation IndexUp: Gfix - Database HousekeepingNext: Shadow Files
Gfix Commands
Note
In the following discussion, I use the full parameter names in all examples. This
is not necessary as each command can be abbreviated. When the command is shown with
'[' and ']' in the name then these are the optional characters.
For example, the command -validate is shown as -v[alidate] and so can be specified
as -v, -va, -val and so on up to the full -validate version.
For almost all of the options in the following sections, two of the above command
line options will be required. These are -u[ser] and -pa[ssword]. These can be
supplied for every command as parameters on the command line, or can be configured
once in a pair of environment variables.
-?
This switch displays the command line options and switches. It replaces the old
method in which you had to supply an invalid switch (such as -help) in order to see
the list of valid ones.
Note
Firebird 2.5 onwards.
-FE[TCH_PASSWORD] <password file name> | stdin | /dev/tty
This switch causes the password for the appropriate user to be read from a file as
opposed to being specified on the command line. The file name supplied is not in
quotes and must be readable by the user running gfix. If the file name is specified
as stdin, then the user will be prompted for a password. On POSIX systems, the file
name /dev/tty will also result in a prompt for the password.
Note
Firebird 2.5 onwards.
-u[ser] username
Allows the username of the SYSDBA user, or the owner of the database to be
specified This need not be supplied if the ISC_USER environment variable has been
defined and has the correct value.
-pa[ssword] password
Supplies the password for the username specified above. This need not be supplied
if the ISC_PASSWORD environment variable has been defined and have the correct
value.
Note
Up until Firebird 2, any utility which was executed with a password on the command
line could result in other users of the server seeing that password using a command
like ps -efx | grep -i pass. From Firebird 2 onwards, this is no longer the case as
the password on the command line can no longer be seen by the ps (or other)
commands.
To define the username and password as environment variables on a Linux system:
linux> export ISC_USER=sysdba

linux> export ISC_PASSWORD=masterkey
Alternatively, on Windows:
C:\> set ISC_USER=sysdba

C:\> set ISC_PASSWORD=masterkey
Warning
This is very insecure as it allows anyone who can access your session the ability
to perform DBA functions that you might not want to allow.
-u[ser] default user name
-pa[ssword] default password
If you have not defined the above environment variables, some commands will not
work unless you supply -u[ser] and -pa[ssword] on the command line. For example:
linux> gfix -validate my_employee

linux> Unable to perform operation. You must be either SYSDBA -
or owner of the database
Note
The line that starts with 'Unable to perform' above, has had to be split to fit on
the page of the PDF file. In reality, it is a single line.
However, passing the username and password works:
linux> gfix -validate my_employee -user sysdba -password masterkey

You will notice, hopefully, that some commands do not give any printed output at
all. gfix, in the main, only reports when problems are encountered. Always check
the response code returned by gfix to be sure that it worked. However, see the
caveats section below for details because it looks like the response code is always
zero - at least up until Firebird 2.0.
Note
When logging into a database on a remote server, you will always be required to
pass the -u[ser] and -pa[ssword] parameters.

Howto Fix Firebird Corruption

Uploaded by

Copyright:

Available Formats

Howto Fix Firebird Corruption

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Howto Fix Firebird Corruption

Uploaded by

Copyright:

Available Formats

what to do when get message "internal gds software consistency check (can't

continue after bugcheck)"

Such a message can occur because of database corruption .

For example, corruption may occur if using stand-along installation o

Or another example, if you are using the netowrk Firebird Server

A possible way to fix this is that you need to perform a

If you are using a stand-alone default installation of

gfix -v -full C:\AyaNovaData\AYANOVA.FDB -user SYSDBA -password masterkey

If there are errors, they will show such as

Summary of validation errors

2. If the database shows errors and is corrupted, perform a backup of the

Firebird Home Firebird Home Prev: Command Line OptionsFirebird

Firebird 2.5 onwards.

-FE[TCH_PASSWORD] <password file name> | stdin | /dev/tty

Firebird 2.5 onwards.

To define the username and password as environment variables on a Linux system:

linux> export ISC_USER=sysdba

C:\> set ISC_USER=sysdba

-u[ser] default user name

-pa[ssword] default password

linux> gfix -validate my_employee

However, passing the username and password works:

linux> gfix -validate my_employee -user sysdba -password masterkey

You might also like