Je travaille sur SQL Server 2008 R2 Express, quand je suis en utilisant la fonction de débogage SQL Server à partir du PC client, cette erreur se produit:
L'autorisation EXECUTE a été refusée sur l'objet 'sp_enable_sql_debug', base de données 'mssqlsystemresource', schéma 'sys'. (Microsoft SQL Server, erreur: 229)
Mon nom d'utilisateur est 'Hali' et l'autorisation est de me attribué est 'public' et 'db_owner',
maintenant, après cette erreur j'ai attribué toutes les autorisations disponibles. Et tous les rôles serveur.
à ce moment je suis un nouveau message d'erreur,
Erreur HRESULT E_FAIL a été renvoyé par un appel à un composant COM. (Mscorlib)
Maintenant que la solution serait pour cette erreur.
3 Réponses :
Les quelques fois où je rencontre cette erreur, cela a toujours été lié au pare-feu. Travaillez-vous sur un serveur distant ou sur votre machine locale? (Parenthèses, soyez prudent attribuant tous les rôles possibles. Certains d'entre eux sont absolument que vous ne voulez absolument pas. Celui dont vous avez besoin pour le débogage SQL est Sysadmin - essayez de désactiver le reste des rôles que vous avez vérifié et de l'attribuer simplement celui-ci.) < / p>
Le débogage des processus est toujours une douleur. Cet ASP. Net Post m'a aidé considérablement il y a quelque temps.
J'ai désactivé le pare-feu sur le serveur et sur l'ordinateur client.
Avez-vous essayé de vérifier tous les rôles mais Sysadmin pour l'utilisateur qui débogage?
Je ne suis pas sûr que la désactivation du pare-feu suffit. Si l'utilisateur a des autorisations SysAdmin et que ce message d'erreur signifie que le client n'est pas capable de se connecter au serveur en mode de débogage. Vérifiez que ces ports TCP et UDP sont correctement ouverts.
Configuration de débogage à distance SQL
Je suis sûr que vous devez également avoir beaucoup de googled et essayé de découvrir les messages d'erreur.
Ce que j'ai trouvé jusqu'à présent, l'erreur dans l'OP que vous avez mentionnée est trompeuse et de cette erreur, nous ne pouvons pas dire ce qui ne va pas exactement ou quoi regarder ensuite. Mais comme vous avez répondu dans les commentaires, après avoir modifié pour activer le débogueur à distance; L'erreur mentionnée est plus claire et je pense que la permission appropriée est toujours un problème. Beaucoup d'autres suggestions que vous avez peut-être aussi essayées jusqu'à présent, mais si vous ne l'avez pas fait, essayons une fois de plus:
dans l'un des commentaires que je vous ai mentionné d'essayer de vous connecter à l'aide de l'utilisateur Windows.
Conservez maintenant les paramètres que vous avez déjà fait pour les ports TCP, l'exception du pare-feu, etc., a expliqué dans le lien ci-dessus.
Vous avez un serveur Windows 2012 où vous avez installé DB Server. et Windows 8 professeur où vous avez le client DB et vous connectez via SSMS. Maintenant, je crois que les deux machines sont dans le même domaine. disons le domaine XYZ. Vous devez disposer de Windows Connexion sur le serveur, disons que c'est "XYZ \ HALI" en utilisant lequel vous pouvez vous connecter au serveur Windows. Connectez-vous et assurez-vous que la connexion existe également sur SQL Server avec une autorisation Sysadmin. Étant donné que la machine client est également dans le même domaine, assurez-vous de vous connecter à la machine cliente à l'aide de la même utilisateur "XYZ \ HALI". Démarrez maintenant SSMS et choisissez l'authentification Windows au lieu de l'authentification SQL Server. Essayez de commencer à déboguer le code T-SQL maintenant.
Si le client et les machines de serveur ne sont pas dans le même domaine, nous devons enregistrer le nom du serveur sur la machine client comme serveur lié, impersonnez le login / utilisateur comme local, puis essayez le débogage.
Après avoir fait toutes les struff mentionnées dans le blog, les deux côtés, le serveur et le client, lorsque j'ai essayé de déboguer sur la clinique, cette erreur s'est produite, avant de créer une exception de pare-feu, je reçois une erreur différente, je reçois maintenant cette erreur -. . Impossible de démarrer le débogueur Transact-SQL, n'a pas pu se connecter à l'instance de moteurs de base de données 'xxxx'. Assurez-vous d'avoir activé les exceptions de pare-feu de débogage et utilisez un identifiant qui est membre du rôle Sysadmin Fixe Server. Cliquez sur Aide pour plus d'informations.
Quel système d'exploitation est sur le serveur et le client. De plus, lorsque vous vous connectez à SSMS sur le client, utilisez "ServerName \ InstanceName", pas d'adresse IP. Vous utilisez également "l'utilisateur d'authentification Windows" qui existe sur la fois sur la machine.
Oui sur le client I M Connexion avec le nom du serveur et j'utilise l'authentification SQL, dois-je utiliser l'adresse IP
Non, "ServerName \ InstanceCename" est bon. Pensez simplement que vous pouvez essayer avec l'utilisateur Windows qui existe sur le serveur et le client. Je me demande l'utilisateur SQL Server que vous utilisez peut avoir une question de permission.
Sur le serveur, nous avons le système de données Windows Server 2012 "et sur le client que nous avons" Windows 8 Pro "
Vérifiez l'édition1 sous la même réponse.
Lorsque j'essaie de vous connecter avec le message d'identification de Windows, THI se produit, la connexion a échoué. Le login provient d'un domaine non approuvé et ne peut pas être utilisé avec l'authentification Windows. (Microsoft SQL Server, erreur: 18452)
Si vous le faites bien et que vous devez vous assurer de voir l'image qui montre comment je vous connecterais à SQL Server à l'aide des informations d'identification Windows. Sinon, votre client et votre machine et votre serveur ne sont pas dans le même domaine. Et donc pour travailler avec l'authentification Windows, comme je l'ai mentionné, nous devons impercer cet utilisateur à l'aide de serveur lié. Je ne suis pas confiant à 100% d'utiliser l'authentification SQL Server, car cet utilisateur SQL nécessitera des autorisations système sur la machine serveur également que je ne suis pas au courant. Si vous avez une visionneuse d'équipe sur le système et que vous souhaitez vous déboguer, faites-le-moi savoir.
J'ai rencontré ce problème après avoir généré un script SQL 2012 et l'exécuter dans une base de données SQL 2008 R2.
Après quelques recherches, j'ai découvert que ma cible SQL 2008 R2 fonctionnait sur un système d'exploitation 32 bits qui prend en charge un fichier allant jusqu'à 2 Go de taille. J'ai donc sauvegardé le script comme c: \ myscript.sql et l'a exécuté avec succès dans une invite de commande avec ces étapes: p>
Ouvrez une fenêtre d'invite de commande. P> li>
Dans la fenêtre d'invite de commande, tapez: p>
sqlcmd -S myServer\instanceName –U yourUserName –P yourPassword -i C:\myScript.sql