I write the following code in psql.

WHEN GDSCODE 335544349, GDSCODE 335544350 DO

BEGIN

INSERT INTO ERROR_LOG VALUES (GDSCODE);

EXCEPTION;

END



But, Firebird showed: Invalid token.

Dynamic SQL Error.

SQL error code = -104.

Token unknown - line 9, column 18.

335544349.





_____

From: firebird-support@yahoogroups.com
[mailto:firebird-support@yahoogroups.com] On Behalf Of Robert martin
Sent: Friday, September 21, 2007 08:21
To: firebird-support@yahoogroups.com
Subject: Re: [firebird-support] Re: Corrupt database



Hi Adam

Yes it is ridiculous, with have consistently begged them to fix their
hardware but they are re-structuring at present and 'no decisions can be
made'.

Will try -g though. It is on my list :)

Rob Martin
Software Engineer

phone +64 03 377 0495
fax +64 03 377 0496
web www.chreos.com

Wild Software Ltd

Adam wrote:

> Hi Rob,
>
>
>> This morning the DB was corrupt, people got IO and 'internal GDS'
>>
> errors
>
>> trying log in. I don't have access to their system so I have tried
>> talking staff through the following process.
>>
>> Shut down FB server and restart.
>> Copy DB to the fb\Bin dir
>> Run Gfix -mend
>> I got 17 record errors and 2 blob errors.
>> Run GBak to create a backup of the db
>> This failed
>> (it has worked for me in the past)
>>
>
> Alarm bells should be ringing. Database corruption should not be a
> regular event on reliable hardware using a stable build of Firebird
> and taking the recommended precautions and safe database file
> management practices.
>
>
>> with some error
>> (sorry staff not good at reporting errors). I will try and get it from
>> them.
>>
>> so I
>> Ran Gfix -mend again
>> I got 13 record errors
>>
>> Re running Gfix -mend seems to always return the same number of errors.
>> Running Gbak again failed with the same (?) error message.
>>
>> I tried Gfix -two_phase (Just ready to try anything)
>> This returned no errors but a further gBak failed anyway.
>>
>> What are peoples other suggestions? The most recent backup they
>>
> have is
>
>> 2 days old. There backups have been failing and they have not noticed.
>>
>>
>
> Step 1: Burn the database file to a CD and lock it in a safe. Database
> recovery can cause further damage, so it is essential you can 'go
> back' if needed.
>
> You mention the backup is failing, do you mean the backup process
> fails or do you mean the backup process appears to succeed but you
> can't restore the file?
>
> Find out the output of gbak when it fails. If it is an index or
> constraint, you may be able to simply drop it to make a successful backup.
>
> Also (if you are lucky) gbak with -g option may work. It just depends
> where the corruption is. Otherwise, you can try a data pump tool to
> extract the good records.
>
> My other suggestions relate to stressing the importance of validating
> every backup of mission critical data and to make environmental
> choices to minimise the chance of corruption (UPS / forced writes /
> don't copy database files that are in use / exclude fdb file from
> scanner paths).
>
> Adam
>
>
>
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Visit http://www.firebird <http://www.firebirdsql.org> sql.org and click

the Resources item

> on the main (top) menu. Try Knowledgebase and FAQ links !
>
> Also search the knowledgebases at http://www.ibphoeni

<http://www.ibphoenix.com> x.com

>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Yahoo! Groups Links
>
>
>
>
>
>

[Non-text portions of this message have been removed]