gbak: ERROR:validation error for column BOXNUMBER, value "*** null ***" gbak: ERROR: warning -- record could not be restored gbak:Exiting before completion due to errors
So, at some point prior to the backup someone had added this NOT NULL column, and hadn't gone round setting the values in the column. So yes, I do understand what initiated the problem. *** BUT *** this is a "you had one job" issue, isn't it? The one and only job of a backup utility is to create a backup that can be restored. If it doesn't do that it's failed. At its one and only job. Soooo many other approaches could have been taken, that wouldn't have lost my database for me, including but probably not limited to: (1) During backup, fail if the backup file being created is one that it won't be able to restore. (2) During restore ... er, just restore it anyway? - in its previous state the database was, strictly speaking, illegal[#], but it was, in real life, working fine. If gbak took this option, with a warning, then I'd be able to fix the data ... but as it is, I can't, because I can't restore the database. Yes I did discover no_validity, with which the restore did create *a* database, but it was a completely ****ing useless database as the NOT NULL constraints appeared to have been dropped everywhere, and who knows what other manglings had taken place (the documentation doesn't list them explicitly, it just says "deletes validity constraints from restored metadata"). Which means that gbak had a third option to get it right: (3) Provide a restore option that warns about validity checking errors, rather than failing them, but doesn't actually delete the checks from the database. So, please, how am I expected to get my database back? OK OK, so I don't actually need the data in the one table causing the problem (there aren't millions of foreign keys pointing at it from all over the shop), so -o -v worked, only losing the data in the one table that I didn't care about anyway, but that's only because I happen to be lucky with the data structures, it won't be a solution in general. [#] Yes, well, there's then the question about how come you're allowed to get a database into such an illegal state in the first place, isn't there. -- Tim Ward
