Je configure un ordinateur portable pour les entretiens de développeurs prêts à être des tests de codage. Je souhaite créer une base de données pour chaque candidat, mais bien avant l'entretien même. Ma préparation va comme ça: p>
tel que lorsque je me connecte à Windows comme candidat, s'ils ouvrent SSMS, ils ne peuvent voir que leur propre base de données dans l'explorateur d'objet. P>
Je veux le faire de cette façon, car il n'ya souvent pas assez de temps entre les entretiens pour sauvegarder / détacher la base de données du candidat précédent et créer la base de données du candidat suivant (la machine est lifueuse, alors puis-vous déconnecter / redevenir à nouveau. etc. prend du temps). P>
est-ce possible, et si oui, comment? P>
Merci beaucoup d'avance. P>
4 Réponses :
Il apparaît qu'il y a une option dans SQL Server 2005+ pouvant répondre à vos besoins ici. Il semble que votre exigence soit que l'utilisateur ne soit pas Comment masquer les bases de données dans SQL Server met en évidence le Ce fil de forum MSDN (voir la plupart des postes de bas) suggère qu'une combinaison de nier la base de données de voir Un utilisateur et une autorisation de donner est une solution possible. P> J'ai répliqué cela sur une machine SQL Server 2008, mais utilise l'authentification SQL Server dans ce test rapide. Il a fonctionné comme décrit: Tous les DB ont été cachés à partir de la connexion, enregistrez celui spécifié ci-dessous. P> Voir n'importe quelle base de données code> Permission. Il peut être utile dans cette situation où la base de données X doit être masquée à tous les utilisateurs autres que Windows User X. P>
USE <customersdatabase>
ALTER AUTHORIZATION ON DATABASE::<customerdatabase> to <customerlogin>
USE MASTER
DENY VIEW ANY DATABASE TO <customerlogin>
connectez-vous à SSMS. P>
Cliquez sur sur les bases de données, cliquez sur la base de données que vous avez créée. P>
Développer la sécurité, cliquez sur Utilisateurs et ajoutez la connexion Windows à cette base de données. Assurez-vous de ne pas l'ajouter au serveur en tant que trou. P>
Ensuite, vos candidats peuvent se connecter à l'aide de la sécurité intégrée et ne voient que leur base de données ou au moins elles ne peuvent accéder qu'à celui-là. P>
Personnellement, je le ferais légèrement différemment - je ne voudrais pas mettre en place un compte Windows séparé pour chaque candidat, mais j'utiliserais uniquement le compte Windows Windows et configureriez un SQL Login Strong> pour chacun. Révoquer le De cette façon, vous pouvez avoir la machine connectée lorsque chaque candidat arrive, tout ce qu'ils ont à faire est de se connecter à l'instance SQL à l'aide des informations de connexion SQL que vous fournissez. P> Voir n'importe quelle base de données code> selon la réponse de p.cambell em>, puis ajoutez simplement chaque connexion SQL en tant qu'utilisateur à leur base de données respective. P>
Ouais, mais j'ai un problème différent - chaque candidat finit par ouvrir Visual Studio et à obtenir les projets de candidats précédents visibles. Différentes logons Windows isole ceux-ci (et avec NTFS, ils ne peuvent même pas arriver aux dossiers de documents des autres).
@Neil, c'est un bon point, mais un script de lot simple peut résoudre ce problème.
En fait je suis en désaccord. Un script de lot ne sera pas capable de s'assurer que les listes de MRU et la page de démarrage VS2010, etc. sont toutes "propres" et n'ont pas de référence aux projets précédents.
avec SQL Server, vous pouvez séparer et joindre des bases de données. Donc, vous pourriez le laisser connecté en tant que candidats normaux et entre candidats, détachez simplement la base de données précédente des candidats et joignez la suivante. P>
Avec le projet Visual Studio précédent, vous pouvez la sélectionner avec un mot de passe. P>