UNE AUTRE MODIFICATION
Cory, si vous avez installé des versions précédentes de SQL Server (par exemple, 2008), il s'agit de la version de sqlcmd vous utilisez. Pour vous connecter à LocalDb, vous devez utiliser la version SQL Server 2012 de sqlcmd . Vos instructions à vos utilisateurs doivent donc garantir qu'ils utilisent la version SQL Server 2012 en exécutant :
C:\Program Files\Microsoft SQL Server\110\Tools\Binn\sqlcmd -S "(localdb)\.\InstanceName"
Cela a fonctionné pour moi. Ce que je n'ai pas vérifié, c'est si ce chemin et la version de sqlcmd est disponible pour les utilisateurs qui ont uniquement installé le sqllocaldb.msi. Désolé mais je n'ai pas de machines nues sans SQL Server 2012 installé (ou avec seulement les versions précédentes installées) pour essayer cela à fond. Mais s'il vous plaît faites le moi savoir si vous appelez explicitement la version 110 de sqlcmd fait l'affaire.
Je pense que vous pourrez également demander aux utilisateurs de modifier leurs variables système afin que les versions 110 viennent en premier (ce qui, à mon humble avis, devrait être le cas automatiquement).
Le FileTimeToSystemTime a été confirmé comme étant un bogue par l'un des collègues de Krzysztof. Il n'y a donc toujours pas de solution que je connaisse pour que les non-propriétaires se connectent via sqllocaldb . Mais j'ai montré que SSMS et sqlcmd peut être fait pour fonctionner, alors j'espère que cela vous rapprochera de la course.
MODIFIER
Vous devez ajouter tous les utilisateurs non propriétaires à l'instance, par ex. CREATE LOGIN [MyDomain\OtherUser] FROM WINDOWS; ainsi que toutes les autorisations appropriées. Dans mon test, la connexion échouait et générait le mauvais message d'erreur (le message d'erreur "FileTimeToSystemTime" est un bogue). Vous devez également GRANT CONNECT . Une fois que vous aurez fait cela, vous serez pouvoir se connecter depuis le deuxième utilisateur à l'aide de Management Studio avec cette connexion (la seule que j'ai essayée) :
(localdb)\.\MySharedInstance
Mais depuis sqlcmd , j'obtiens toujours une erreur, peu importe comment j'essaie de me connecter :
sqlcmd -S "(localdb)\.\MySharedInstance"
sqlcmd -S ".\MySharedInstance"
sqlcmd -S "(localdb)\MySharedInstance"
sqlcmd -S "GREENHORNET\MySharedInstance"
sqlcmd -S ".\LOCALDB#SH04FF8A"
sqlcmd -S "GREENHORNET\LOCALDB#SH04FF8A"
Tous donnent :
Bien que j'ai vérifié que l'instance est configurée pour accepter les connexions à distance. Il y a donc un autre cerceau que sqlcmd doit passer.
Et concernant le sqllocaldb exe, comment cela suit-il une logique? Je peux voir que l'instance est là via info , je reçois un message d'erreur approprié lorsque j'essaie de l'arrêter, je reçois un message indiquant qu'il est [déjà] démarré lorsque j'essaie de le démarrer, mais je ne peux pas m'y connecter ?
Donc, à moins que vous n'ayez besoin sqlcmd accès, à court terme, je demanderais aux utilisateurs secondaires de faire leur travail avec SSMS (une fois que vous avez accordé les autorisations adéquates) et j'espère que Krzysztof aura plus d'informations sur les autres éléments.
Concernant la mise à jour 4.0.2, depuis http://connect.microsoft.com/SQLServer/feedback/details/723737/smo-cant-connect-to-localdb-instances :
