Version imprimable
Bonjour,
nous sommes passées sur l'authentification windows...enfin.
seulement voila, chaque personne qui à les droits de créer ou de lancer des process se retrouve avec les tables créées avec leur login, du coup les process se cassent la gueule, il faut les repasser en dbo.matable
je voudrais savoir comment et surtout peut'on que chaque personne ou process par defaut crééer la table en dbo ?
Merci par avance
Ch.
Tout d'abord quelle est votre version ? 2000, 2005, 2008 ??? Parce que les choses changent grandement entre les deux (2000 d'un côté et 2005/8 de l'autre).
Ensuite sachez que la notion de owner n'est pas bonne, il ne s'agit pas de propriétaire, mais de schéma SQL.
Lisez ce que j'ai écrit à ce sujet :
http://blog.developpez.com/sqlpro/p5...es-schema-sql/
http://blog.developpez.com/sqlpro/p7...et-utilisateu/
A +
C'est SQL 2005/08.
Oui c'est du schema mais justement je vais aller lire les articles tout de suite car cela permet beaucoup de chose.
Ch.
Pour ma part j'ai créé un rôle auquel j'ai affectés des individus (users) et auquel j'ai donné des droits (select, update, ect...)
je pense qu'il faut que je laisse tomber cette methode et que je fasse la meme chose via un schema !
Les rôles étant plutôt cantonné à des droits spécifiques (serveur, ...)
j'ai pas encore trouver comment faire pour résoudre mon probleme...:(
En pratique les utilisateurs "ordinaires" de la base ne devraient pas avoir besoin de créer des tables, fonctions ou procédure.
C'est pourquoi il faut distinguer les comptes de connexion des développeurs de ceux des utilisateurs applicatifs.
A +
en fait pour etre plus précis.
la base est une base de travail, pourn importer des fichiers ...
dans cette base des groupes windows peuvent travailler, donc creer manipuler des données importées.
et justement quand je rentre directement le login c'est bon chaque table créée à bien dbo.matable.
mais en fait j'utilise des groupe windows et c'est dans ce cas précis, que dbo.matable se transforme en domaine\login.matable et c'est la que ça pose un probleme.
le groupe est dbowner de la base.
quelle est la difference entre le groupe et l'utilisateur pour que sql change dbo ?
et surtout comment y remedier parce que mettre tout les logins dans SQL ça va pas etre tres pratique.
ch.
bon ben voila mes derniers essais...
Impossible d'utiliser la clause DEFAULT_SCHEMA avec un groupe Windows ou des entités de sécurité mappées à des certificats ou des clés asymétriques.
y'a encore un truc qu'on pige pas avec l'admin systeme.
pourquoi un admin local est directement dbo et non domaine\login.matable ?
exemple je suis admin local de la machine, je dois donc rentrer dans le groupe builtin\admibistrators et là je n'ai pas mon domaine\login.matable
mais bel est bien dbo.matable ?
est-ce lié au privilege de l'admin ?
ne peut'on pas reproduire la meme chose pour un utilisateur simple ?
est-ce qu'un trigger DDL est une bonne idée.
en gros sur chaque creation d'object <> du schema dbo.
et bien il le transforme dn dbo.monobject ?
L'administrateur est toujours associé au schéma dbo pour une base de données.Citation:
y'a encore un truc qu'on pige pas avec l'admin systeme.
pourquoi un admin local est directement dbo et non domaine\login.matable ?
En principe à partir de SQL Server 2005, un utilisateur se voit affecter le schéma dbo par défaut.L'option DEFAULT_SCHEMA des commandes CREATE / ALTER USER permettent de changer ce comportementCitation:
est-ce lié au privilege de l'admin ?
ne peut'on pas reproduire la meme chose pour un utilisateur simple ?
++
oui j'ai vu ça, le default_schema toutefois quand cela vient d'un groupe windows ben on ne peut pas en mettre et à la premiere creation de table il créé le schema [domaine\login] et affecte la table à ce schema...c'est ça que j'aimerais changer.
alors avec un trigger de base de donnée, j'ai reussi mais je trouve ça moins propre, et surtout pour ma culture personnelle, j'ai pas reussi a faire ce que je voulais...enfin apparemment c'est pas trop possible... ?