Utiliser User Instance signifie que SQL Server crée une copie spéciale de ce fichier de base de données à utiliser par votre programme. Si vous avez deux programmes différents utilisant la même chaîne de connexion, ils obtiennent deux copies entièrement différentes de la base de données. Cela conduit à un beaucoup de confusion, car les utilisateurs testeront la mise à jour des données avec leur programme, puis se connecteront à une autre copie de leur base de données dans Management Studio et se plaindront que leur mise à jour ne fonctionne pas. Cela les envoie à travers une série imparfaite d'étapes de chasse à l'oie sauvage essayant de résoudre le mauvais problème.
Cet article explique plus en détail comment utiliser cette fonctionnalité, mais tenez compte de la toute première remarque :l'User Instance la fonctionnalité est obsolète . Dans SQL Server 2012, les alternatives préférées sont (dans cet ordre, à mon humble avis) :
-
Créez ou attachez votre base de données à une instance réelle de SQL Server. Votre chaîne de connexion devra alors simplement spécifier le nom de l'instance, le nom de la base de données et les informations d'identification. Il n'y aura pas de confusion car Management Studio, Visual Studio et votre ou vos programmes se connecteront tous à une seule copie de la base de données.
-
Utilisez
SqlLocalDbpour le développement local. Je crois que je vous ai signalé cet article hier :"Premiers pas avec SQL Server 2012 Express LocalDB." - Utilisez SQL Server Compact. J'aime le moins cette option parce que la fonctionnalité et la syntaxe ne sont pas les mêmes - donc elle ne vous fournira pas nécessairement toutes les fonctionnalités que vous voudrez finalement déployer. L'édition compacte est également obsolète, donc voilà.
Bien sûr si vous utilisez une version AttachDbFileName .
MODIF : J'ai blogué à ce sujet ici :
- Mauvaises habitudes :utiliser AttachDBFileName
