Issue Details (XML | Word | Printable)

Key: CORE-3772
Type: Bug Bug
Status: Closed Closed
Resolution: Won't Fix
Priority: Major Major
Assignee: Unassigned
Reporter: Peter Vandel
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Firebird Core

Firebird 2.5 GBak Restore does not create a required USERS table when backing up and restoring a Fb2.0-formatted database.

Created: 24/Feb/12 05:06 PM   Updated: 25/Feb/12 08:47 AM
Component/s: GBAK
Affects Version/s: 2.5.1
Fix Version/s: None

Time Tracking:
Not Specified

Environment: Firebird 2.5.1 on Windows (7, Vista and XP)

Planning Status: Unspecified


 Description  « Hide
To reproduce:
  Use Firebird 2.5.1 utility gbak.exe to backup a Firebird database which has an old 2.0 format.
  Use Firebird 2.5.1 utility gbak.exe to restore from the backup file made above.

The converted database does contain the new (2.1) Monitor tables (like MON$ATTACHMENTS, etc.)
HOWEVER, the same database does not contain a USERS (or RDB$USERS) table.

The USERS table is required by gsec.exe to add co-admins users to a custom database.
GSec reports the following if USERS does not exist.
"gsec -user sysdba -pass <pw> -database <database name/alias>"
GSEC> disp
gesec reports the following error: "invalid request BLR at offset 37 table USERS is not defined".

A workaround can be to create the table yourself in the database.

Ok, I hope this isue can be solved soon.

Thanks in advance,
Peter Vandel.





Firebird 2.5 GBak Restore does not create a USERS or RDB$USERS table when restoring a 2.0-formatted database

 All   Comments   Work Log   Change History   Version Control   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Dmitry Yemanov added a comment - 24/Feb/12 05:30 PM
USERS is not a system table per se and it's not a part of the Firebird ODS. It exists in security2.fdb only and GSEC requires it being present there. But it *should not* exist in any other database. And GSEC *is not* intended to work with security in user databases.

Thus I see no issue here and IMO this ticket must be rejected.