Depuis la mise à jour de Windows 10 à 1803, j'ai commencé à recevoir cette erreur chaque fois que j'exécutais une requête EF qui se connecte à une fonction table qui prend un paramètre scalaire.
Message: Le flux de protocole d'appel de procédure distante du flux de données tabulaire (TDS) (RPC) est incorrect. Paramètre 2 (""): Le type de données 0x00 Est inconnu.
Trace de pile: à System.Data.SqlClient.SqlCommand. <> C.b__180_0 (résultat Task1 ) À System.Threading.Tasks.ContinuationResultTaskFromResultTask`2.InnerInvoke () at System.Threading.Tasks.Task.Execute () --- Trace de fin de pile de l'emplacement précédent où une exception a été levée --- à System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw ( ) à System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (Tâche ) à System.Data.Entity.Core.EntityClient.Internal.EntityCommandDeignature.demand).
J'utilise Entity Framework version 6.2 dans des projets d'infrastructure .NET 4.6. J'ai vérifié que le même code était exécuté sans problème sur un autre ordinateur sous Windows 10 1709. J'ai mis à jour l'ordinateur sous Windows 10 1803 sans autre modification et j'ai commencé à obtenir l'erreur ci-dessus. Code à l'origine de l'erreur:
var query = from fs in db.ViewWithInformation
join e in db.GetEventsForPerson(personnelId) on fs.Event_Id equals e.Event_Id
where !fs.Is_Deleted
select fs;
return await query.ToArrayAsync();
Si je supprime la jointure contre db.GetEventsForPerson, la requête est exécutée. Le code SQL généré par la requête EF ci-dessus fonctionne correctement dans SSMS.
Edit 5/15/2018: J'ai confirmé que cela est spécifiquement causé par .NET Framework 4.7.2. J'ai installé manaully .NET 4.7.2 sur mon ordinateur Windows 10 1709 et l'erreur a redémarré.
Je m'appelle Peter Carlin et je travaille dans l'équipe SQL Server. Je tiens tout d'abord à m'excuser pour cet incident et l'impact sur les utilisateurs de .NET Framework 4.7.2. Je veux ensuite expliquer ce qui s’est passé et comment Microsoft le résout plus en détail.
Ces problèmes sont dus aux améliorations apportées à la fonctionnalité Always Encrypted dans SQL. Ces améliorations étendent l'ensemble des opérations pouvant être effectuées dans Always Encrypted, mais elles ne sont pas encore prêtes à être utilisées par les applications. Ces améliorations impliquent des modifications à la fois sur SqlClient et sur le serveur SQL. Nous avons introduit une erreur dans .NET Framework 4.7.2 telle que, dans certaines circonstances (liées à MARS), SqlClient pense à tort que la fonctionnalité ajoutée est utilisée et envoie des requêtes non valides à SQL. SQL rejette ceux avec les messages d'erreur vus dans ce fil. Cela se produit uniquement si vous êtes connecté à un serveur SQL prenant également en charge la fonctionnalité ajoutée. SQL DB est le premier à obtenir les dernières modifications SQL et a récemment déployé la fonctionnalité ajoutée.
Notre solution immédiate consiste à nous assurer que la base de données SQL agit comme si elle ne possédait pas la fonctionnalité ajoutée. Ainsi, le bogue côté SqlClient dans la version 4.7.2 n’est pas rencontré. C'est pourquoi nous sommes en mesure de résoudre le problème avec une modification du côté de la base de données SQL.
Nous travaillons aussi vite que sage/sûr pour déployer, valider, le correctif. À ce stade, le correctif est déployé à environ 10% de notre capacité de production et devrait être terminé le lundi 21 mai.
Solution de contournement temporaire: PerChainbridgeTechmodifie MultipleActiveResultSets de TRUE à FALSE dans la chaîne de connexion et l'erreur s'arrête.
Cela a été rapporté et est en cours de travail. Ils ont encore besoin d'une repro et je travaille toujours sur l'isolation de données partageables que je peux rendre publiques:
https://github.com/Microsoft/dotnet/issues/749
Problème en double de Erreur TDS sur les appels SQL d'Azure Entity Framework après la mise à jour de Windows 10, avril 2018
Nous étudions cela comme une possible régression sur SqlClient sur .NET Framework. Quiconque peut fournir un projet de repro, postez-le sur https://github.com/Microsoft/dotnet/issues/749 .
Microsoft étudie activement ce problème. D'après ce que nous savons jusqu'à présent, le problème est lié à .NET Framework 4.7.2 avec MARS (ensembles de résultats actifs multiples) lorsque vous utilisez async/wait.
Les solutions de contournement connues incluent l'annulation de la mise à jour de Windows/.NET, de ne pas utiliser MARS ou de ne pas utiliser async/wait.
Si vous avez des informations supplémentaires qui peuvent nous aider à les réduire, veuillez les ajouter au rapport de problème à l’adresse https://github.com/Microsoft/dotnet/issues/749 .
La solution pour moi était de convertir la requête qui était en train de mourir d’utiliser .Include en .IncludeOptimized et cela fonctionne maintenant.