Partager via

Problèmes courants

  • Article

Power Query

Conservation de l’ordre de tri

Vous pouvez supposer que si vous triez vos données, toutes les opérations en aval conservent l’ordre de tri.

Par exemple, si vous triez une table des ventes afin que la plus grande vente de chaque magasin soit affichée en premier, vous pouvez vous attendre à ce que l’opération « Supprimer les doublons » retourne uniquement la vente la plus élevée pour chaque magasin. Et de fait, cette opération pourrait sembler fonctionner. Pourtant, ce comportement n’est pas garanti.

En raison de la façon dont Power Query optimise certaines opérations, notamment en les ignorant ou en les déchargeant dans des sources de données (qui peuvent avoir leur propre comportement d’ordonnancement), il n’est pas garanti que l’ordre de tri sera conservé au fil des opérations d’agrégation (comme Table.Group), de fusion (comme Table.NestedJoin), ou de suppression de doublons (comme Table.Distinct).

Il existe plusieurs moyens de contourner ce problème. Voici quelques suggestions :

  • Effectuez un tri après l’application de l’opération en aval. Par exemple, lors du regroupement de lignes, triez la table imbriquée dans chaque groupe avant d’appliquer d’autres étapes. Voici un exemple de code M illustrant cette approche : Table.Group(Sales_SalesPerson, {"TerritoryID"}, {{"SortedRows", each Table.Sort(_, {"SalesYTD", Order.Descending})}})
  • Mettez en mémoire tampon les données (en utilisant Table.Buffer) avant d’appliquer l’opération en aval. Dans certains cas, cette opération entraîne la conservation de l’ordre de tri mis en mémoire tampon.
  • Utilisez le classement . Par exemple, au lieu d’utiliser Table.Distinct, vous pourriez ordonner par la(les) colonne(s) contenant les valeurs dupliquées, classer sur la base d’une colonne de départage (par exemple modified_date), puis filtrer pour ne conserver que les lignes de rang 1.

Inférence du type de données

Parfois, Power Query peut détecter incorrectement le type de données d’une colonne. Cela est dû au fait que Power Query infère les types de données en utilisant uniquement les 200 premières lignes de données. Si les données des 200 premières lignes diffèrent de quelque façon des données après la ligne 200, il se peut que Power Query finisse par choisir le mauvais type. (N’oubliez pas qu’un type incorrect ne produit pas toujours d’erreurs. Parfois, les valeurs résultantes sont simplement incorrectes, ce qui rend le problème plus difficile à détecter.)

Par exemple, imaginez une colonne contenant des nombres entiers dans les 200 premières lignes (comme tous des zéros), mais des nombres décimaux après la ligne 200. Dans ce cas, Power Query déduit le type de données de la colonne en nombre entier (Int64.Type). Cette inférence entraîne la troncation des parties décimales des nombres non entiers tronqués.

Ou bien imaginez une colonne contenant des valeurs de date textuelles dans les 200 premières lignes, et d’autres types de valeurs de texte après la ligne 200. Dans ce cas, Power Query déduit le type de données de la colonne à Date. Cette inférence entraîne le traitement des valeurs de texte non date comme des erreurs de conversion de type.

Étant donné que la détection de type opère sur les 200 premières lignes, mais que le profilage des données peut opérer sur le jeu de données tout entier, vous pouvez envisager d’utiliser la fonctionnalité de profilage des données pour obtenir dans l’éditeur de requêtes une indication précoce concernant les erreurs (de détection de type ou autres) au-delà des N premières lignes.

Connexions fermées de force par l’hôte distant

Lorsque vous vous connectez à différentes API, il se peut que vous receviez l’avertissement suivant :

Data source error: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host

Si vous rencontrez cette erreur, il s’agit très probablement d’un problème de mise en réseau. En règle générale, les premières personnes à interroger sont les propriétaires de la source de données à laquelle vous tentez de vous connecter. S’ils ne pensent pas être à l’origine de la fermeture de la connexion, il est possible que quelque chose le long du chemin le soit (par exemple, un serveur proxy, des routeurs/passerelles intermédiaires, etc.).

Que ce problème survienne avec n’importe quelles données ou seulement avec des données volumineuses, il est probable qu’un dépassement de délai d’expiration réseau se produit quelque part en chemin. Si cela n’arrive qu’avec des données volumineuses, le mieux est de consulter le propriétaire de la source de données pour voir si ses API prennent en charge la pagination, afin de pouvoir fractionner les demandes en blocs plus petits. À défaut, il convient de recourir à d’autres méthodes d’extraction de données de l’API (dans le respect des meilleures pratiques en matière de sources de données).

Les suites de chiffrement TLS RSA sont obsolètes

À compter du 30 octobre 2020, les suites de chiffrement suivantes sont devenues obsolètes sur nos serveurs.

  • "TLS_RSA_WITH_AES_256_GCM_SHA384”
  • "TLS_RSA_WITH_AES_128_GCM_SHA256”
  • "TLS_RSA_WITH_AES_256_CBC_SHA256”
  • "TLS_RSA_WITH_AES_128_CBC_SHA256”

Les suites de chiffrement prises en charge sont les suivantes :

  • "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256"
  • "TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384"
  • "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"
  • "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"
  • "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256"
  • "TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384"
  • "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256"
  • "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384"

Les suites de chiffrement servent à chiffrer les messages afin de sécuriser une connexion réseau entre clients et serveurs et d’autres serveurs. Nous supprimons la liste ci-dessus de suites de chiffrement pour nous conformer à nos protocoles de sécurité actuels. À compter du 1er mars 2021, les clients ne pourront utiliser que nos suites de chiffrement standard.

Il s’agit des suites de chiffrement que le serveur auquel vous vous connectez doit prendre en charge pour les connexions à partir de Power Query Online ou de Power BI.

Dans Power Query Desktop (Power BI, Excel), nous ne contrôlons pas vos suites de chiffrement. Si vous essayez de vous connecter à Power Platform (par exemple, les flux de données Power Platform) ou le service Power BI, vous avez besoin de l’une de ces suites de chiffrement activées sur votre système d’exploitation. Vous pouvez soit mettre à jour la version Windows ou mettre à jour le Registre Windows TLS pour vous assurer que votre point de terminaison de serveur prend en charge l’un de ces chiffrements.

Pour vérifier que votre serveur est conforme au protocole de sécurité, vous pouvez effectuer un test à l’aide d’un outil de chiffrement et d’analyse TLS. Ce pourrait être SSLLABS.

Les clients doivent mettre à niveau leurs serveurs avant le 1er mars 2021. Pour plus d’informations sur la configuration de l’ordre de la suite de chiffrement TLS, voir Gestion de Transport Layer Security (TLS).

Révocation de certificat

Une version à venir de Power BI Desktop provoque une défaillance des connexions SSL à partir de Desktop quand des certificats de la chaîne SSL sont manquants d’état de révocation de certificats. Il s’agit d’une modification de l’état actuel, où la révocation n’entraîne d’échec de connexion que si le certificat a été explicitement révoqué. D’autres problèmes de certificat peuvent résulter de signatures non valides et de l’expiration du certificat.

Comme il existe des configurations dans lesquelles l’état de révocation peut être supprimé, par exemple avec les serveurs proxy d’entreprise, nous fournirons une autre option pour ignorer les certificats qui n’ont pas d’informations de révocation. Cette option permet aux situations où les informations de révocation sont supprimées dans certains cas, mais que vous ne souhaitez pas réduire entièrement la sécurité, pour continuer à fonctionner.

Il n’est pas recommandé, mais les utilisateurs peuvent continuer à désactiver entièrement les vérifications de révocation.

Erreur : L’évaluation a été annulée

Power Query retourne le message « Évaluation a été annulée » lorsque l’analyse en arrière-plan est désactivée et que l’utilisateur bascule entre les requêtes ou ferme l’Éditeur de requête pendant qu’une requête est en cours d’actualisation.

Erreur : La clé ne correspond à aucune ligne de la table

Il existe de nombreuses raisons pour lesquelles Power Query peut renvoyer une erreur indiquant que la clé ne correspondait à aucune ligne de la table. Quand cette erreur se produit, le moteur Mashup ne parvient pas à trouver le nom de table qu’il recherche. Les raisons pour lesquelles cette erreur peut se produire sont les suivantes :

  • Le nom de la table a été modifié, par exemple dans la source de données proprement dite.
  • Le compte utilisé pour accéder à la table ne dispose pas de privilèges suffisants pour lire la table.
  • Il peut y avoir plusieurs informations d’identification pour une seule source de données, qui n’est pas prise en charge dans le service Power BI lors de l’utilisation de connexions cloud personnelles. Cette erreur peut se produire, par exemple, lorsque la source de données est une source de données cloud et que plusieurs comptes sont utilisés pour accéder à la source de données en même temps avec des informations d’identification différentes. Si la source de données est locale, vous devez utiliser la passerelle de données locale.

Limitation : exigence de jointure au domaine des ordinateurs de passerelle lors de l’utilisation de l’Authentification Windows

L’utilisation de l’Authentification Windows avec une passerelle locale nécessite que l’ordinateur de passerelle soit joint au domaine. Cela s’applique aux connexions configurées avec « Authentification Windows via la passerelle*. Les comptes Windows utilisés pour accéder à une source de données peuvent nécessiter un accès en lecture aux composants partagés dans le répertoire Windows et l’installation de la passerelle.

Limitation : l’actualisation d’OAuth2 inter-locataires n’est pas prise en charge dans le service Power BI

Si vous voulez vous connecter à une source de données à partir du service Power BI en utilisant OAuth2, la source de données doit se trouver dans le même locataire que le service Power BI. Actuellement, les scénarios de connexion multilocataire ne sont pas pris en charge avec OAuth2.

Limitation : Le point de terminaison d’authentification AD FS personnalisé n’est pas pris en charge dans le service Power BI

La capacité d’utiliser un point de terminaison d’authentification de Services de fédération Active Directory (AD FS) n’est pas prise en charge dans le service Power BI. Les utilisateurs pourraient rencontrer l’erreur suivante : Le service de jeton signalé par la ressource n’est pas approuvé.

Limite : les comptes invités ne sont pas pris en charge

L’utilisation de comptes invités d’un locataire pour se connecter aux données à l’aide de connecteurs Power Query n’est pas prise en charge actuellement.

Expression.Erreur : l’évaluation a entraîné un dépassement de la capacité de la pile et ne peut pas continuer

Les erreurs de dépassement de la capacité de la pile peuvent être provoquées par un bogue dans votre code M. Par exemple, la fonction suivante produit un dépassement de la capacité de la pile parce qu’elle s’appelle elle-même de façon répétée sans aucune condition de fin.. Une fonction qui s’appelle elle-même comme celle-ci est appelée fonction « récursive ».

let f = (x) => @f(x + 1) in f(0)

Voici quelques façons courantes de résoudre un dépassement de la capacité de la pile dans votre code M.

  • Assurez-vous que vos fonctions récursives s’arrêtent réellement lorsque la condition de fin attendue est atteinte.
  • Remplacez la récurrence par l’itération (par exemple, à l’aide de fonctions telles que List.Transform, List.Generate ou List.Accumulate).

Expression.Erreur : l’évaluation a manqué de mémoire et ne peut pas continuer

Les erreurs de « Mémoire insuffisante » (ou ooMs) peuvent être provoquées par un trop grand nombre d’opérations utilisant beaucoup de mémoire sur des tables très volumineuses. Par exemple, le code M suivant produit une OOM, car il tente de charger un milliard de lignes en mémoire à la fois.

Table.Buffer(Table.FromList({1..1000000000}, Splitter.SplitByNothing()))

Pour résoudre les erreurs de mémoire, optimisez les opérations qui utilisent beaucoup de mémoire, notamment les tris, les jointures, les regroupements et les différenciations en veillant à ce qu’elles se plient sur la source ou en les supprimant complètement si c’est possible. Les tris, par exemple, sont souvent inutiles.

Flux de données

Annuler l’actualisation du flux de données

Il arrive que vous lanciez une actualisation du flux de données, mais ensuite vous vous rendez compte que vous vouliez modifier une dernière chose avant d’actualiser vos données. Dans ce cas, vous devez attendre la fin de l’actualisation. L’arrêt d’une actualisation à mi-chemin, alors que le processus est déjà en train d’obtenir les données et de mettre à jour les tables dans votre espace de travail ou votre environnement, n’est pas pris en charge pour l’instant.

Nous prévoyons d’ajouter prochainement la possibilité d’annuler l’actualisation d’un flux de données.