FBOwnerMigrator looks like it will probably help me out with my owner
problems, but I'm not 100% sure of this. The database in question is
currently owned by sysdba. The system tables in the database are owned
by sysdba, but the other objects are either owned by user1 or user2. I
would like the database to be owned by user2 and all the objects within
it to have their creator set to user2.

There are a few complications here. Firstly, I think FBOwnerMigrator
assumes that one user is both the database owner and the creator of the
objects within that database. If I restore the database as user2 and
then tell FBOwnerMigrator to migrate from user1 to user2, will this end
up with all objects being owned by user2 (as desired) or will it get
confused by the fact that the system tables are owned by sysdba and that
some objects are already owned by user2?

Secondly, the user1 account that owns some of the objects has actually
been deleted. Will it be sufficient for me to simply create another
account with the same name and a known password?

Thanks,

Max

Thomas Steinmaurer wrote:

> Hi Max,
>
>> With Interbase 6.0, is there an easy way to change the creator of
>> tables, triggers etc? We have a database that was created by a user
>> that has now left. This database has now been taken over by another
>> user, but as he is not the creator of most of its objects, he can not do
>> things such as drop tables, alter tables, alter triggers etc. These
>> actions can only be performed by the creator, sysdba or users with o/s
>> root privileges. Granting the user sysdba or root is not an option, so
>> it looks like I must somehow change the object's creator to the new user.
>>
>> I originally thought I would be able to achieve this by changing the
>> database owner with a backup and restore. However, this does not change
>> any of the creator information. After much reading around, the only
>> possible way that I have found is to manually alter the RDB$OWNER_NAME
>> field in RDB$RELATIONS. However, I'm nervous about fiddling with the
>> system tables, and this situation isn't ideal anyway as a trigger is in
>> place to stop anyone other than the creator from modifying this field
>> (preventing sysdba from doing it!).
>>
>> Can anyone provide an alternate solution, or offer some guidance on
>> modifying RDB$RELATIONS in a safe way?
>
> Yes, by using our freely available FBOwnerMigrator tool. Request the
> download location by sending an email to me ("t . steinmaurer @
> upscene.com")
>
>
>> Thanks,
>>
>> Max Spicer

[Non-text portions of this message have been removed]