TFS 2010 - Impossible d'interroger certains utilisateurs

Il semble que nous ayons un problème avec notre installation de Team Foundation Server 2010 qui donne une erreur lorsque certains utilisateurs sont interrogés. Si nous les incluons dans le filtre 'AssignedTo', la requête se trompe instantanément avec les erreurs suivantes:

TF237161: Le fonctionnement du serveur a expiré ou le serveur n'a pas répondu. Réessayer.

Pour les autres utilisateurs, cela fonctionne bien et les fichiers TFS affectés à ces utilisateurs problématiques sont renvoyés dans les résultats des requêtes en cours. J'ai vérifié et cela ne semble pas être un problème de permission. Nous avions migré de Team Foundation Server 2008 vers TFS 2010 l'année dernière, mais les personnes concernées par cette situation pensent que cela s'est déjà produit avant.

Quelqu'un a-t-il une idée de l'endroit où commencer le dépannage? J'ai un accès complet au serveur et à la base de données, et j'ai commencé à essayer de répliquer la requête en SQL pour voir s'il s'agit d'une erreur dans la base de données, mais je n'ai pas encore beaucoup progressé.

Si quelqu'un a des suggestions, il serait grandement apprécié! Merci

J'ai finalement réussi à trouver la source du problème! Il s'avère que pour des raisons inconnues, les utilisateurs affectés sont apparus plus d'une fois dans la Constantstable (basée sur leur nom stocké dans la DisplayPartcolonne) qui réside dans notre TfsDefaultCollectionbase de données TFS. Cette requête a mis en évidence tous les enregistrements avec les doublons DisplayName:

SELECT * FROM Tfs_DefaultCollection.dbo.Constants
WHERE DisplayPart IN
(
    SELECT DisplayPart FROM dbo.Constants 
    GROUP BY DisplayPart
    HAVING COUNT(ConstID) > 1
)
ORDER BY DisplayPart ASC

Une requête utilisée par TFS lors de l'interrogation d'éléments TFS extrait un utilisateur ConstIDde cette table et ne fonctionne que lorsque son nom est unique:

declare @P3_1 int
select @P3_1 = ConstID from dbo.[Constants] where DisplayPart = @P3
if (@@rowcount > 1)
begin
        raiserror(600174, 16, 1) with seterror, nowait
        return
end
set @P3_1 = isnull(@P3_1,-2147483648);

Donc, parce qu'ils sont apparus plus d'une fois, la requête a échoué avec une erreur. Ainsi, pour résoudre ce problème, nous avons renommé les constantes en double avec les dernières ConstIDen quelque chose de différent (nous avons ajouté un? À la fin) , et hop! Cela a fonctionné encore.

Si jamais je découvre pourquoi cela est arrivé, je posterai une mise à jour. En attendant, j'espère que cela sera utile à toute personne confrontée au même problème gênant

Suivez ces instructions pour obtenir des informations de traçage détaillées sur ce qui se passe sur votre serveur TFS.

Notez que vous ne devez jamais manipuler directement vos données de cette façon. Cela mettrait votre système dans un état très difficile à gérer pour le groupe de produits TFS. Des noms affichés en double sont réellement attendus dans certains cas - généralement lorsque deux utilisateurs appartenant à des domaines différents ont été synchronisés dans TFS avec un nom complet partagé (par exemple, DOMAIN1 \ user et DOMAIN2 \ user ont tous les deux le nom complet "user").

La requête de suivi d'élément de travail que vous avez notée ci-dessus est optimisée pour le cas où il n'y a pas de noms d'affichage en double dans le système. En règle générale, l'erreur générée par l'extrait de code SQL que vous avez inclus génère une exception fortement typée sur le serveur. Cette exception est interceptée et un lot SQL moins optimal est généré pour gérer le cas de nom d'affichage en double. Ce n'est pas un modèle, clairement, et nous prévoyons de le nettoyer dans une prochaine version. Pour l’instant, c’est comme ça que les choses se passent ici.

Avec toute cette configuration, la cause principale de votre problème est probablement que les messages d'erreur de votre instance SQL ne sont pas installés correctement. Dans ce cas, l'erreur générée ne sera pas convertie correctement en l'exception fortement typée attendue par le code du serveur, et le second lot SQL moins optimal ne sera jamais généré, ce qui entraînera la défaillance que vous rencontriez ... Si Si vous corrigez l’installation du message d’erreur sur votre instance SQL, le problème doit être résolu et vos requêtes doivent à nouveau renvoyer les résultats appropriés aux utilisateurs dont le nom d’affichage est ambigu.