> --- In firebird-support@yahoogroups.com, Thomas Steinmaurer<ts@...> wrote:
>>
>>> --- In firebird-support@yahoogroups.com, Doug Chamberlin<chamberlin.doug@> wrote:
>>>>
>>>> On 2/29/12 2:50 PM, todderamaa wrote:
>>>>> Maybe with the possibility of corruption, I should tell him to exclude
>>>>> the database files from backup entirely and only backup the gbk files
>>>>> that are created in the evening.
>>>> This is the usual way to backup Firebird databases in situations like
>>>> your clients have. Operating on the live database files is a quick way
>>>> to corrupted backup copies. If you have not experienced corruption
>>>> either you have been lucky or have not actually tried restoring from
>>>> many of those backup copies.
>>>>
>>>> The client network admins should be aware of this special case when
>>>> databases are being used. For this reason some database vendors have an
>>>> API that backup software can use to ensure the database activity does
>>>> not interfere with the backup operation. The vendors of backup systems
>>>> usually charge extra for these modules that handle various databases.
>>>> Firebird, however, does not have such an API.
>>>>
>>>> Steps for a safe, reliable Firebird backup:
>>>> 1) Run GBAK
>>>> 2) Copy the GBAK output to your backup media
>>>> 3) Periodically restore from the GBAK output to a test database to
>>>> ensure there are no errors.
>>>>
>>>
>>> I agree.
>>>
>>> But with this latest issue, we needed the database file and not the backup. The restore of the backup failed, because we had a stored procedure that was selectable that didn't include a 'suspend' statement. I think this must be something that was allowed in Firebird 2.0 but not with 2.1.
>>
>> This is another reason to perform a backup/restore cycle when upgrading
>> to a newer server version. A sanity check and upgrading the ODS to
>> activate all good new stuff. ;-)
>>
>
> We had done backup/restore of this database many times since the upgrade. It seems the problem started when we 'altered' this stored procedure. We had been going through our procedures, removing any UDF function calls that could be replace with internal function calls. Seems the problem started occuring after we altered the procedure on the client site.
>
> Does this make sense?

I think you get into your described situation, when you are using the
stored procedure as a selectable SP ala:

SELECT * FROM YOURPROC


when the SP doesn't have a SUSPEND somewhere.

Regards,
Thomas