> --- 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
