Is there anything in the db metaschema or vst files that would uniquely identify a database ? I want to be able to uniquely identify a database, even if it is either procopied or backedup / restored.
I have found the _db-guid field in _db, but this survives a backup restore (both databases have the same _db-guid)
TIA
Inode?
Can be multi-platform (win/linux)
Dammit. No takers ? I was hoping that there was some super-secret field
You could always add one. Assuming that this is an in-house requirement, not a general purpose tool issue, then just create a table with the info you want and check that.
Of course, if you want to distinguish between databases, even though it has been backed up and restored, then you would have to have some procedure to update that record as a part of your processing.
For that kind of requirement, I wonder what could possibly satisfy the need. After all, if one crashes a database, restores it from backup, and applies the AI files, the whole intent is that is be *exactly* like what was crashed before the crash. Anything that was different about it would violate that principle. In fact, even the inode solution wouldn't work there since one would be likely to restore into the crashed structure and that would have the same inode.
What are you actually trying to accomplish here?
We have a customer that often restores (on the same machine) the database to test backups. What I don't want is someone screwing up and making the backup copy the "live" copy (it happened once. What a bugger to debug).
I was thinking of being able to check the uniqueid and compare that with a value stored a db field. If they don't match, I know that it not the live db and can stop someone from using it.
_DbStatus-CreateDate is changed when you restore or procopy. Not when you os-copy So I may combine that with some hash on the path of the db (it will always be different).
Curious. With the scripts I use for managing stuff on Unix, I can't imagine anyone making such an error. The tools are all there for doing the same kind of backup and restore ... in fact, customers will often restore a recent backup to a test location to use in testing out new procedures or code. but, if is always really clear which one is using.
One piece of this is to run a .p after a restore which can mark the database appropriately. I.e., change the display name from Fiscal to Tester or whatever. You could consider doing something like that.