English > Support

Old Database Does Not Work

<< < (7/13) > >>

rick.ca:

--- Quote ---I am just waiting for some fix/miracle by nostra
--- End quote ---

Have you sent that backup to nostra so he might determine what the problem is?

Darwinek:

--- Quote from: rick.ca on July 06, 2009, 10:44:58 pm ---Have you sent that backup to nostra so he might determine what the problem is?
--- End quote ---

I will, just say me how can I do it, the file is about 45 MB large.

rick.ca:
Nostra will send you instructions. Or if he'd rather I did so, he'll send me instructions—I'm not sure how he manages the FTP access.

rschip2:
I am also having this issue.   I get the same error message:

"ProcVersionChanges ->9009000 -> unsuccessful metadata update
STORE RDB$RELATION_FIELDS failed
attempt to store duplicate value (visible to active transactions) in unique index "RDB$INDEX_15"
This operation is not defined for system tables.
Error Code: 31"

followed by

"failed to open database"

Have you had any luck with fixing the issue?  I downloaded the portable install as well with no luck.

I was  using version 0.9.8.20, tried out beta version 0.9.9.40 (i think), but went back to 0.9.8.20. I backed up my file repeatedly, but the back up I need has been touched by the beta, and won't work.  Two of my older backups work but they are really out of date.  I also have a large library (816).  And i'm not about to start re-entering, so if you have any suggestions let me know.  rschip2@gmail.com

rick.ca:
Welcome, rschip2.

As I understand it, there's no issue to be fixed. Unfortunately, if a database has been damaged by an early beta, then the damage is done and there's nothing the program can do about it. But what do I know... maybe it should detect and repair damage done by bugs in previous versions. 8)

There's still an issue, of course, but I'm not sure what should be done about it. Some like to live dangerously and use their only database in a beta without making backup. More are in the same situation as you—you made backup, but didn't realize your active database was damaged in this particular way for an extended period of time. I've done it myself.

Perhaps the program should be stricter about using databases from different major versions. It could automatically make a backup of a prior-version database before converting it, and refuse to open any database that has been opened in a subsequent version. The same thing could be done for any particular minor revision, if the risk was deemed high enough (e.g., early betas, where "big" changes are being made and bugs may not be found immediately). In hindsight, you would have been better off had you been forced to revert to your original database (i.e., that "untouched" by 0.9.9.x) when deciding to go back to 0.9.8.20.

If it weren't for this particular, perhaps unlikely problem, such precautions might seem like overkill. After all, database formats often change when a major revision is made to the program that creates them—so it's not possible to use the same database in different versions anyway. But it might be an effective way to prevent this sort of thing from happening again. It would also save users from themselves should they be so eager to try a new version they "forget" to make backup. ;)

Navigation

[0] Message Index

[#] Next page

[*] Previous page