Hello, Sean,

>> This doesn't solve any of the problems. Currently, Firebird
>> allows you to copy database file and use this copy on the
>> same machine. This databases will have the same UID.
>> We have original database name in database header now
>> and it is no way worse than UID.

> A solution to this problem is to have store the UID's database name in
> the database along with the UID. If the name of the current database
> doesn't equal the name in the database, the engine could generate a new
> UID.

Yes, this can help against one of the rare possibilities, but it
doesn't help in most common cases. Example:
1. Admin copied database and firebird server directory somewhere
2. Backed up original database at original location.
3. Then he restored the system as it was at point 1
4. Backed up database at original location.
5. Now he restores database from backup and intermixes files from
point 2 and point 4.

How can your approach help in this situation ?

But if we also add backup UID and store it in the next level
backup header we'll close this possibility too.

-------------------------

But what if admin has cloned machine and moved database here
and accessed if from here and then intermixed backups from this
two clones ? Of course we can add UID for Firebird installation,
and track it relative serial numbers of hardware components, but
this creates a couple problems:
1) Change of NIC invalidates backup history
2) Doesn't help in case of virtual machines

-------------------------

I can continue. I think this all is a road to nowhere.
If admin mismatched backup this is his, admin's problem.
And if we can in 90-99% cases fail with graceful error
message in this case this is ok. My code already offers this
level of protection and I think adding UIDs is unnecessary.

Nickolay Samofatov