Discussion :

[seabs]

Bonjour,
J’ai une installation assez ancienne qui s’appuie sur INTERBASE version XE7 update 4. Au fil des modifications successives, il apparaît que des tables sont la propriété de différents utilisateurs. En réalité 2 utilisateurs, dont SYSDBA.
Je voudrais restructurer cette base pour que toutes les tables soient la propriété du même Owner.

Si l’opération avec SYSDBA comme propriétaire de la base de données ne pose aucun souci particulier, il n’en est pas même si j’effectue la création de la base avec un autre utilisateur.
J’ai parcouru internet dans tous les sens et, de même pour la documentation Interbase qui est très copieuse. Après 3 jours, j’ai décidé de faire appel à vos connaissances, car il doit y avoir un point qui m’échappe complètement.
Dans toute la documentation , il est question du SYSDBA ou du propriétaire de la base. Mais, pour ce dernier aucune explication sur la définition de ce fameux propriétaire.
Si s’effectue la création de la base avec un autre utilisateur, la base est bien créée et les tables sont bien affectées au bon utilisateur. Tout se complique avec les privilèges. Au départ, l'user possède bien les droits sur la table créée. Par contre, je supprime ce privilège (exemple : insert), il est impossible d’en effectuer la restitution, car je ne possède pas les droits. Le message qui s’affiche est :

This operation is not defined for system tables.
unsuccessful metadata update.
no I privilege with grant option on table/view T_CLIENT.

Toutes mes recherches sont vaines et je ne sais pas comment définir cette opération dans les tables systèmes.

Ma question est « Comment créer une base de données ayant un autre propriétaire que SYSDBA et qui possède toutes les prérogatives de SYSDBA ». Un examen de FIREBIRD m’a permis de constater que le transfert à un autre utilisateur de toutes les options qui existent, pour SYSDBA, sont transférables et clairement expliquées dans la documentation (Firebird version 3.00 et plus). Pour INTERBASE, tout semble plus compliqué.

D’avance merci pour votre éclairage.

[seabs]

Bonjour,
Mon message n'enregistre pas un franc succès.
Je vais contourner la difficulté, car il est maintenant possible d'utiliser un mot de passe jusqu'à 32 caractères avec Interbase. Cependant, cette nouvelle possibilité ne résout pas le cas de déplacement de la base sur un autre ordinateur.
Par contre, si nous utilisons le stockage des administrateurs et utilisateurs dans la base au lieu de "Admin.ib", le transfert sur un autre ordinateur continue de bloquer l'ouverture. C'est dans cette situation où je voudrais pouvoir transférer l'ensemble des droits SYSDBA vers un autre administrateur.
Il y a certainement un point que je n'ai pas compris, malgré des recherches importantes. En plus tout ceci est anglais, ce qui ne simplifie pas la recherche.

Merci pour ceux qui ont pris le temps de regarder mon problème, même s'ils ne m'ont apporté aucun d'éclaircissement.

A++

[SergioMaster]

Bonjour,

Mon message n'enregistre pas un franc succès.

Le fait est que j'ai abandonné Interbase au profit de Firebird.
J'aurai pu répondre de regarder comment c'est fait avec Firebird mais

Un examen de FIREBIRD m’a permis de constater que le transfert à un autre utilisateur de toutes les options qui existent, pour SYSDBA, sont transférables et clairement expliquées dans la documentation (Firebird version 3.00 et plus).

c'est déjà fait, voilà pourquoi je n'avais pas répondu au premier message.

Par contre, si nous utilisons le stockage des administrateurs et utilisateurs dans la base au lieu de "Admin.ib", le transfert sur un autre ordinateur continue de bloquer l'ouverture.

là je ne saisi pas vraiment

C'est dans cette situation où je voudrais pouvoir transférer l'ensemble des droits SYSDBA vers un autre administrateur.

Est-ce qu'interbase à des ROLE, AMHA certainement et c'est la piste que je propose créer puis utiliser à bon escient un role qui autorise la création des tables. Si j'ai déjà utilisé les roles pour protéger certaines colonnes ou table, je n'ai jamais fait ce genre d'utilisation, mais AMHA c'est possible.
Je ne crois pas que l'on puisse modifier une table système RDB$relations pour modifier RDB$owner_name directement du style

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
UPDATE RDB$relations set RDB$owner_name='proprio' where RDB$relation_name='unetable'

du moins est-ce interdit maintenant avec les versions FB 3 et plus (des "mécanismes SQL" particuliers sont mis en place)