Partager via


Problèmes courants

Power Query

Conservation du 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 cette opération peut, en fait, sembler fonctionner. Toutefois, 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 vers des sources de données (qui peuvent avoir leur propre comportement d’ordre unique), l’ordre de tri n’est pas garanti pour être conservé par le biais d’agrégations (par exemple), de fusions (telles Table.Groupque Table.NestedJoin) ou de suppression en double (par exemple Table.Distinct).

Il existe plusieurs façons 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 qui illustre cette approche : Table.Group(Sales_SalesPerson, {"TerritoryID"}, {{"SortedRows", each Table.Sort(_, {"SalesYTD", Order.Descending})}})
  • Mettre en mémoire tampon les données (à l’aide de 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 pouvez ordonner par les colonnes contenant les valeurs dupliquées, classer en fonction d'une colonne de départage (comme modified_date), puis filtrer pour conserver uniquement les lignes de rang numéro 1.

Inférence de 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 déduit 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 sont en quelque sorte différentes des données après la ligne 200, Power Query peut finir par choisir le type incorrect. (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 qui contient des entiers dans les 200 premières lignes (telles que tous les zéros), mais contient 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.

Ou imaginez une colonne qui contient 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 comme étant Date. Cette inférence conduit à ce que les valeurs textuelles non liées à une date soient traitées comme des erreurs de conversion de type.

Étant donné que la détection de type fonctionne sur les 200 premières lignes, mais que le profilage des données peut fonctionner sur l’ensemble du jeu de données, vous pouvez envisager d’utiliser la fonctionnalité de profilage des données pour obtenir une indication anticipée dans l’Éditeur de requête sur les erreurs (à partir de la détection de type ou d’un nombre quelconque d’autres raisons) au-delà des lignes N principales.

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

Lorsque vous vous connectez à différentes API, vous pouvez recevoir 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 probablement d’un problème réseau. En règle générale, les premières personnes à vérifier sont les propriétaires de la source de données à laquelle vous tentez de vous connecter. S’ils ne pensent pas qu’ils sont ceux qui ferment la connexion, il est possible que quelque chose le long de la route soit (par exemple, un serveur proxy, des routeurs/passerelles intermédiaires, etc.).

Que cela se reproduise uniquement avec des données ou des tailles de données plus grandes, il est probable qu’il existe un délai d’expiration réseau quelque part sur l’itinéraire. S’il ne s’agit que de données plus volumineuses, les clients doivent consulter le propriétaire de la source de données pour voir si leurs API prennent en charge la pagination, afin qu’ils puissent fractionner leurs demandes en blocs plus petits. En cas d'échec, il convient de suivre les méthodes alternatives d'extraction des données de l'API, en suivant les meilleures pratiques des 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 »

La liste suivante est les suites de chiffrement prises en charge :

  • « 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.

Ce sont les suites de chiffrement que le serveur auquel vous vous connectez doit prendre en charge pour la connexion depuis Power Query Online ou 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 de scanneur TLS. Un exemple peut ê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, consultezGérer la sécurité de la couche de transport (TLS).

Révocation de certificat

Une version à venir de Power BI Desktop provoque une défaillance des connexions SSL à partir de Power BI Desktop lorsque des certificats de la chaîne SSL ne disposent pas de statut de révocation des certificats. Il s’agit d’une modification de l’état actuel, où la révocation a provoqué uniquement l’échec de connexion dans le cas où le certificat a été révoqué explicitement. D’autres problèmes de certificat peuvent inclure des signatures non valides et 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, dans les situations où les informations de révocation sont supprimées dans certains cas, de continuer à fonctionner sans compromettre totalement la sécurité.

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. Lorsque cette erreur se produit, le moteur Mashup ne peut pas trouver le nom de la 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 elle-même.
  • 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 : Les machines de passerelle doivent être jointes à un domaine 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 à un domaine. Cela s’applique aux connexions configurées avec l’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 OAuth2 multi-locataire n’est pas prise en charge dans le service Power BI

Si vous souhaitez vous connecter à une source de données à partir du service Power BI à l’aide d’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 possibilité d’utiliser un point de terminaison d’authentification Ad FS (Active Directory Federation Services) personnalisé n’est pas prise en charge dans le service Power BI. Les utilisateurs peuvent rencontrer l’erreur suivante : le service de jeton signalé par la ressource n’est pas approuvé.

Limitation : 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 actuellement pas prise en charge.

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

Les erreurs de dépassement de pile peuvent être provoquées par un bogue dans votre code M. Par exemple, la fonction suivante produit un dépassement de capacité de pile, car elle revient à plusieurs reprises en elle-même sans aucun type de 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 pile dans votre code M.

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

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

Les erreurs « hors mémoire » (ou OOMs) peuvent être provoquées par trop d’opérations intensives en mémoire sur de grandes tables. Par exemple, le code M suivant produit un 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 gourmandes en mémoire, telles que les tris, les jointures, le regroupement et les distincts en s’assurant qu’elles se plient à la source ou en les supprimant dans la mesure du possible. Les tris, par exemple, sont souvent inutiles.

Power Query Online ne peut pas se connecter via un point de terminaison public lorsqu’un point de terminaison privé est configuré sur un stockage

Lorsqu’un point de terminaison privé vers un compte de stockage est configuré, Power Query Online résout toujours l’adresse de liaison privée et ne peut pas se connecter via l’Internet public, même si l’accès public est défini sur « Autorisé » dans la configuration du point de terminaison privé.

Ce comportement se produit parce que le point de terminaison privé est prioritaire sur la connectivité publique. Par conséquent, toute tentative de connexion sans passerelle échoue.

Flux de données

Annuler l’actualisation du flux de données

Parfois, vous démarrez une actualisation du flux de données, mais après le démarrage, vous réalisez que vous souhaitez modifier une autre 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, puisque le processus travaille déjà à l’obtention des données et à la mise à jour des tables dans votre espace de travail ou environnement, n'est pas pris en charge actuellement.

Nous prévoyons d’ajouter la prise en charge de l’annulation d’une actualisation du flux de données à l’avenir.