Pourquoi ne puis-je pas me connecter à une instance partagée SQL Server 2012 LocalDB?
J'essaie de configurer une instance partagée SQL Server 2012 LocalDB (RTM, x64) sur ma machine Windows 7 x64 et je n'arrive pas à me connecter à l'instance partagée. J'utilise une invite de commande administrateur pour toute la configuration. Voici comment je crée l'instance:
sqllocaldb create MyInstance
Ce qui donne la réponse:
LocalDB instance "MyInstance" created with version 11.0.
Jusqu'ici tout va bien. Maintenant, je partage l'instance:
sqllocaldb share "MyInstance" "MySharedInstance"
Ce qui se traduit par:
Private LocalDB instance "MyInstance" shared with the shared name: "MySharedInstance".
Toujours bien. À ce stade, la commande info donne:
.\MySharedInstance
MyInstance
v11.0
La connexion à l'instance à partir du compte propriétaire (qui est un administrateur) à l'aide d'une invite de commande administrateur ou non administrateur semble fonctionner correctement. Cependant, les choses se décrochent lorsque je me connecte en tant qu'utilisateur normal (pas en tant qu'administrateur Windows) et que j'essaie de me connecter:
sqlcmd -S (localdb)\.\MySharedInstance
résulte en:
Sqlcmd: Error: Microsoft SQL Server Native Client 11.0 : Named Pipes Provider: Could not open a connection to SQL Server [2]. .
Sqlcmd: Error: Microsoft SQL Server Native Client 11.0 : Login timeout expired.
Sqlcmd: Error: Microsoft SQL Server Native Client 11.0 : A network-related or instance-specific error has occurred while establishing a connection to SQL Server. Server is not found or not accessible. Check if instance name is correct and if SQL Server is configured to allow remote connections. For more information see SQL Server Books Online..
L'augmentation du délai de connexion à l'aide du commutateur "-l" n'aide pas. Je peux me connecter à l'instance v11.0 par défaut, qui n'est pas partagée. La commande info pour l'utilisateur non administrateur donne la même chose que ci-dessus, sauf sans "MyInstance" car il s'agit d'une instance nommée appartenant à l'utilisateur administrateur. La commande suivante (qui fonctionne pour l'utilisateur admin/propriétaire d'instance):
sqllocaldb info ".\MySharedInstance"
entraîne également une erreur:
Windows API call "FileTimeToSystemTime" returned error code: -2147024809.
La question est donc de savoir pourquoi mon utilisateur non administrateur ne peut pas se connecter à mon instance partagée? Cela semble aller à l'encontre de l'objectif des instances partagées. Et qu'en est-il de la commande "sqllocaldb info" qui génère une erreur lorsque j'essaie d'interroger sur l'instance partagée?
UNE AUTRE MODIFICATION
Cory, si vous avez installé des versions précédentes de SQL Server (par exemple 2008), c'est la version de sqlcmd que 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 cette version de sqlcmd sont disponibles pour les utilisateurs qui ont seulement installé 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 l'essayer à fond. Mais faites-moi savoir si l'appel explicite de 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 110 versions viennent en premier (ce qui à mon humble avis devrait être le cas automatiquement).
Le FileTimeToSystemTime a été confirmé comme bogue par l'un des collègues de Krzysztof. Il n'y a donc toujours pas de correctif à ma connaissance pour que les non-propriétaires se connectent via sqllocaldb. Mais j'ai montré que SSMS et sqlcmd peuvent fonctionner, donc j'espère que cela vous rapprochera de la course.
[~ # ~] modifier [~ # ~]
Vous devez ajouter des utilisateurs non propriétaires à l'instance, par exemple CREATE LOGIN [MyDomain\OtherUser] FROM WINDOWS; et toutes les autorisations appropriées également. 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 faites cela, vous le ferez pourrez vous connecter depuis le deuxième utilisateur utilisant Management Studio avec cette connexion (la seule que j'ai essayée):
(localdb)\.\MySharedInstance
Mais à partir de sqlcmd, je reçois 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 les rendements:
HResult 0xFFFFFFFF, niveau 16, état 1 Interfaces réseau SQL Server:
Erreur de localisation du serveur/de l'instance spécifiée [xFFFFFFFF].
Sqlcmd: Erreur: Microsoft SQL Server Native Client 10.0: une erreur liée au réseau ou spécifique à l'instance s'est produite lors de l'établissement d'une connexion à SQL Server. Le serveur est introuvable ou inaccessible. Vérifiez si le nom de l'instance est correct et si SQL Server est configuré pour autoriser les connexions à distance. Pour plus d'informations, consultez la documentation en ligne de SQL Server.
Sqlcmd: Erreur: Microsoft SQL Server Native Client 10.0: le délai de connexion a expiré.
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 traverser.
Et en ce qui concerne l'exe sqllocaldb, comment cela suit-il une logique? Je peux voir que l'instance est là via info, j'obtiens un message d'erreur approprié lorsque j'essaye de l'arrêter, je reçois un message indiquant qu'elle est [déjà] démarrée lorsque j'essaye de la démarrer, mais je peux ' t vous y connecter?
Donc, sauf si vous besoinsqlcmd 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 articles.
Concernant la mise à jour 4.0.2, de http://connect.Microsoft.com/SQLServer/feedback/details/723737/smo-cant-connect-to-localdb-instances :
Nous avons explicitement décidé de ne pas inclure .NET Framework 4.0.2 dans le programme d'installation de LocalDB. L'installation de la mise à jour de .NET Framework augmenterait la taille du programme d'installation de LocalDB et provoquerait un redémarrage probable. Étant donné que LocalDB est conçu pour être indépendant du .NET, nous ne pensions pas que nous devrions prendre ce coût pour chaque installation de LocalDB. Les futures versions de .NET (y compris .NET 4.5, maintenant dans CTP) prendront en charge LocalDB prêt à l'emploi. Certains développeurs peuvent également souhaiter opter pour ODBC, PHP Driver/PDO, et probablement JDBC à l'avenir. Ces développeurs ne seront pas intéressés par la mise à jour de .NET.
Comme le post original le suggérait, ce n'était pas aussi simple que prévu, mais j'ai finalement pu me connecter via le canal nommé.
CETTE RÉPONSE SUPPRIME LA SUPPRESSION DE L'INSTANCE IS OK.
c'est-à-dire: toutes vos données auront disparu et ce n'est pas grave.
J'avais le même problème, après la mise à niveau de mon SSMS.
sqllocaldb i
.\MyCustomInstance
sqllocaldb d
LocalDb instance ".\MyCustomInstance" does not exist!
sqllocaldb i .\MyCustomInstance
Windows API call "FileTimeToSystemTime" returned error code: -2147024809.
Afin de me débarrasser de l'instance incriminée, j'ai dû créer un autre MyCustomInstance qui, je suppose, écrasera ce qui existe déjà, et maintenant vous pouvez le supprimer
sqllocaldb c MyCustomInstance
LocalDB instance "MyCustomInstance" created with version 11.0.
sqllocaldb d .\MyCustomInstance
LocalDB instance ".\Octopus" deleted.
Ensuite, démarrez l'instance et partagez-la. Vous devez impérativement démarrer l'instance en premier.
sqllocaldb s MyCustomInstance
LocalDB instance "MyCustomInstance" started.
sqllocaldb h MyCustomInstance MyCustomInstance
Private LocalDB instance "MyCustomInstance" shared with the shared name: "MyCustomInstance".
Maintenant, lorsque vous devez vous connecter, vous vous connectez avec (localdb)\.\MyCustomInstance
Installez le .NET Framework 4.5.2 complet ou ultérieur, puis redémarrez, vous devriez alors pouvoir vous connecter en utilisant:
sqlcmd -S (localdb)\.\MySharedInstance
J'ai constaté que les canaux nommés génèrent un nouveau hachage lorsque la machine est redémarrée, l'instance partagée nommée persistera après les redémarrages.
Il est important de noter que cela ne fonctionnera qu'après un redémarrage.