Subject | Re: Restore problem on firebird 1.03 |
---|---|
Author | Alexander V.Nevsky |
Post date | 2004-02-18T10:22:32Z |
--- In firebird-support@yahoogroups.com, "dnasmyth2000" <smyth@d...>
wrote:
1. One of the young hackers among schoolboys made experiments with DML
statements on tables rdb$user_privileges or rdb$security_classes :)
First is more simple to find
Select * from rdb$user_privileges
where rdb$object_type=0 /*tables*/
and rdb$field_name is null
and not exists
(Select 1 from rdb$relations
where rdb$relations.rdb$relation_name=
rdb$user_privileges.rdb$relation_name)
will show grants on non-existing tables
Select * from rdb$user_privileges
where rdb$object_type=0
and rdb$field_name is not null
and not exists
(Select 1 from rdb$relation_fields
where rdb$relation_fields.rdb$relation_name=
rdb$user_privileges.rdb$relation_name
and rdb$relation_fields.rdb$field_name=
rdb$user_privileges.rdb$field_name)
will show grants on no-existing columns,
Select * from rdb$user_privileges
where rdb$object_type=5 /*procedures*/
and rdb$field_name is null
and not exists
(Select 1 from rdb$procedures
where rdb$procedures.rdb$procedure_name=
rdb$user_privileges.rdb$relation_name)
will show grants on non-existing procedures. I'm not on a short hand
with views, but it is possible to check them too studying system
tables structure and building another query of mentioned kind.
2. I recall reports that sometimes similar troubles are caused by
granting the same user the same right on entire table and on one of
it's columns. If this is the reason, simply revoke column-level grant.
Best regards,
Alexander.
wrote:
> A school I work with called me with the following problem. theyMore ideas in addition to Helen:
> could not add a grant for a particular user. they got a message
> about not finding column GRANT. I had them dump and reload the
> database and they got the following error on restoring. Their
> database runs on Linux. I got a copy of their database and did the
> same thing with the same error in WinXP. I validated the database no
> errors. Has anybody seen this before? Any Ideas?
>
> gbak: restoring privilege for user LFERGUSON
> fmRestoreDB.RestoreService:
> Unsuccessful execution caused by system error that does not preclude
> successful execution of subsequent statements.
> action cancelled by trigger (1) to preserve data integrity.
> could not find column for GRANT.
>
> Restore completed
>
> the rest of the restore is not completed.
1. One of the young hackers among schoolboys made experiments with DML
statements on tables rdb$user_privileges or rdb$security_classes :)
First is more simple to find
Select * from rdb$user_privileges
where rdb$object_type=0 /*tables*/
and rdb$field_name is null
and not exists
(Select 1 from rdb$relations
where rdb$relations.rdb$relation_name=
rdb$user_privileges.rdb$relation_name)
will show grants on non-existing tables
Select * from rdb$user_privileges
where rdb$object_type=0
and rdb$field_name is not null
and not exists
(Select 1 from rdb$relation_fields
where rdb$relation_fields.rdb$relation_name=
rdb$user_privileges.rdb$relation_name
and rdb$relation_fields.rdb$field_name=
rdb$user_privileges.rdb$field_name)
will show grants on no-existing columns,
Select * from rdb$user_privileges
where rdb$object_type=5 /*procedures*/
and rdb$field_name is null
and not exists
(Select 1 from rdb$procedures
where rdb$procedures.rdb$procedure_name=
rdb$user_privileges.rdb$relation_name)
will show grants on non-existing procedures. I'm not on a short hand
with views, but it is possible to check them too studying system
tables structure and building another query of mentioned kind.
2. I recall reports that sometimes similar troubles are caused by
granting the same user the same right on entire table and on one of
it's columns. If this is the reason, simply revoke column-level grant.
Best regards,
Alexander.