All, Historically, we backup and restore security classes with names not starting with 'SQL'. Regular security classes are SQL-based and they're recreated at the commit (DFW) time, so there's really no sense in transporting them back and forth. So I suppose that backup/restore support is present for some kind of manually created security classes. However, I failed to find such things in QLI, maybe it presented in GDEF in the past days.
So, unless someone knows any good reason to see non-SQL security classes in our databases, I'd suggest to remove security classes from backups (avoid adding them to backup and skip them during restore). Rationale is simple: changes in ACLs are unlikely to be backward compatible. If we bump ACL_version, the ACL transmitted from the newer engine will throw a bugcheck in the older engine. If we don't bump ACL_version, a bugcheck will be thrown anyway as soon as the older engine notices a new ACL item. And, unlike similar situation with BLR, new ACL item could appear (e.g. be created during restore) for the existing metadata objects in the newer engine. So I suggest to treat ACLs as a private part of the ODS and avoid migrating ACLs between different FB versions, including backup/restore. Provided that ACLs *seem* to not being migrated now anyway, I don't foresee any compatibility issues. But I could be missing something. Comments anyone? Dmitry ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
