一般的な問題

Power Query

並べ替えの保持

データを並べ替えた場合は、その並べ替え順序がすべてのダウンストリーム操作で保持されると見なされる可能性があります。

たとえば、各店舗の最大の売上が最初に表示されるように売上テーブルを並べ替えた場合は、[重複部分の削除] 操作の実行によって、各店舗の上位の売上のみが返されると期待される可能性があります。 また、実際に、この操作が機能するように見えることがあります。 しかし、この動作は保証されません。

各操作のスキップやデータ ソースへのオフロード (これによって固有の順序付け動作が行われる可能性があります) など、Power Query で特定の操作が最適化される方法のために、集計 (Table.Group など)、マージ (Table.NestedJoin など)、重複除去 (Table.Distinct など) を通して並べ替え順序が保持されることは保証されません。

これを回避する方法がいくつかあります。 以下はその提案です:

  • ダウンストリーム操作を適用した 後に 並べ替えを実行します。 たとえば、行をグループ化する場合は、各グループ内の入れ子になったテーブルを並べ替えてから、それ以上の手順を適用します。 このアプローチを示すサンプルの M コードとして Table.Group(Sales_SalesPerson, {"TerritoryID"}, {{"SortedRows", each Table.Sort(_, {"SalesYTD", Order.Descending})}}) があります。
  • ダウンストリーム操作を適用する前に (Table.Buffer を使用して) データをバッファリングします。 場合によっては、この操作により、バッファリングされた並べ替え順序がダウンストリーム操作で保持されます。
  • ランク付けを使用します。 たとえば、Table.Distinct を使用する代わりに、重複する値を含む列を並べ替え、タイ ブレーカー列 (modified_date など) に基づいてランクを付け、ランク 1 の行のみを保持するようにフィルター処理することができます。

データ型の推論

Power Query では、列のデータ型が誤って検出される場合があります。 これは、Power Query では、データの最初の 200 行のみを使用してデータ型を推測しているためです。 最初の 200 行のデータが 200 行より後のデータと何らかの点で異なっていると、最終的に Power Query によって間違った型が選択される可能性があります。 (型が正しくない場合に必ずエラーが発生するとは限りません。その結果として得られる値が正しくなくなり、問題の検出が困難になる場合があります)。

たとえば、最初の 200 行には整数 (すべて 0 など) が含まれているが、200 行より後には 10 進数が含まれている列があるとします。 この場合、Power Query では、その列のデータ型を整数 (Int64.Type) であると推測します。 この推論により、整数以外のすべての数値の小数部分が切り捨てられることになります。

または、最初の 200 行にはテキストの日付値が含まれ、200 行より後にはその他の種類のテキスト値が含まれている列があるとします。 この場合、Power Query では、その列のデータ型を日付であると推測します。 この推論により、日付以外のテキスト値が型変換エラーとして処理されることになります。

型の検出は最初の 200 行に対して機能しますが、データ プロファイリングはデータ セット全体に対して実行できるため、データ プロファイリング機能を使用して、クエリ エディターで最初の N 行を超えた (型の検出またはその他の任意の数の理由による) エラーに関する早い兆候を得ることを検討できます。

リモート ホストによって強制的に閉じられた接続

各種の API に接続していると、次の警告が表示される場合があります。

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

このエラーが発生した場合、最も可能性が高いのはネットワークの問題です。 一般には、まず、接続しようとしているデータ ソースの所有者に確認します。 その所有者が接続を閉じていないと考えている場合は、そこまでの途中にある何か (プロキシ サーバー、中間のルーターまたはゲートウェイなど) が原因である可能性があります。

これが何らかのデータでのみ、または大きなデータ サイズでのみ再現されるかどうかにかかわらず、ルート上のどこかでネットワーク タイムアウトが発生している可能性があります。 大きなデータでのみ発生する場合、お客様は要求をより小さなチャンクに分割できるように、データ ソースの所有者にその API でページングがサポートされているかどうかを確認する必要があります。 それがうまくいかない場合は、API からデータを抽出するための (データ ソースのベスト プラクティスに従った) 代わりの方法に従う必要があります。

TLS RSA 暗号スイートは非推奨です

2020 年 10 月 30 日より、次の暗号スイートは当社サーバーから非推奨になります。

  • "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”

サポートされている暗号スイートの一覧を次に示します。

  • "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"

暗号スイートは、メッセージを暗号化して、クライアント/サーバーと他のサーバー間のネットワーク接続を保護するために使用されます。 現在のセキュリティ プロトコルに準拠するため、上記の暗号スイートのリストを削除します。 2021 年 3 月 1 日以降、お客様は当社の 標準の暗号スイート のみを使用できます。

これらは、接続先のサーバーが Power Query Online または Power BI から接続するためにサポートする必要のある暗号スイートです。

Power Query Desktop (Power BI、Excel) では、暗号スイートを制御しません。 Power Platform (Power Platform データフローなど) または Power BI サービスに接続しようとしている場合は、OS でこれらの暗号スイートのいずれかが有効になっている必要があります。 Windows のバージョンをアップグレードするか、Windows TLS レジストリを更新し、サーバー エンドポイントがこれらの暗号の 1 つをサポートしていることを確認します。

サーバーがセキュリティ プロトコルに準拠していることを確認するには、TLS 暗号化とスキャナー ツールを使用してテストを実行できます。 その 1 つの例として SSLLABS があります。

お客様は、2021 年 3 月 1 日までにサーバーをアップグレードする必要があります。 TLS 暗号スイートの注文の構成の詳細については、トランスポート層セキュリティ (TLS) の管理 を参照してください。

証明書の失効

Power BI Desktop の今後予定されているバージョンでは、SSL チェーン内のいずれかの証明書に証明書の失効状態がない場合、デスクトップからの SSL 接続が失敗します。 これは、証明書が明示的に失効された場合は失効によってのみ接続エラーが発生していた現在の状態からの変更です。 その他の証明書の問題として、無効な署名や証明書の有効期限が含まれることがあります。

失効状態が削除される可能性のある構成 (企業のプロキシ サーバーの場合など) が存在するため、失効情報を含んでいない証明書を無視するための別のオプションを提供する予定です。 このオプションでは、特定の場合に失効情報が削除されるが、作業を続行するためにセキュリティを完全には低下させたくない状況が許可されます。

これは推奨されませんが、ユーザーは引き続き、失効確認を完全に無効にすることができます。

エラー: 評価が取り消されました

Power Query では、バックグラウンド分析が無効になっており、クエリの更新中にユーザーがクエリを切り替えるか、またはクエリ エディターを閉じた場合、"評価が取り消されました" というメッセージを返します。

エラー: キーがテーブルのどの行とも一致しませんでした

Power Query がキーがテーブルのどの行とも一致しませんでしたというエラーを返す可能性のある原因はたくさんあります。 このエラーが発生すると、マッシュアップ エンジンでは、検索しているテーブル名を見つけることができません。 このエラーが発生する可能性のある原因には次のものがあります。

  • テーブル名が (たとえば、データ ソース自体で) 変更された。
  • テーブルへのアクセスに使用されるアカウントに、そのテーブルを読み取るための十分な特権がない。
  • 1 つのデータ ソースに対して複数の資格情報が存在する可能性がある。これは Power BI サービスではサポートされていません。 このエラーは、たとえば、データ ソースがクラウド データ ソースであり、データ ソースにアクセスするために複数のアカウントが異なる資格情報で同時に使用されている場合に発生する可能性があります。 データ ソースがオンプレミスにある場合は、オンプレミス データ ゲートウェイを使用する必要があります。

制限: Windows 認証を使用している場合のゲートウェイ マシンのドメイン参加の要件

オンプレミス ゲートウェイで Windows 認証を使用するには、そのゲートウェイ マシンがドメインに参加している必要があります。 これは、"ゲートウェイ経由の Windows 認証" で設定されているすべての接続に適用されます。 データ ソースへのアクセスに使用される Windows アカウントには、Windows ディレクトリ内の共有コンポーネントやゲートウェイのインストールへの読み取りアクセスが必要になることがあります。

制限事項: Power BI サービスでのクロス テナント OAuth2 更新はサポートされていません

OAuth2 を使用して Power BI サービスからデータ ソースに接続する場合は、データソースが Power BI サービスと同じテナントに存在している必要があります。 現在、OAuth2 を使用したマルチテナント接続のシナリオは、サポートされていません。

制限事項: カスタム AD FS 認証エンドポイントは Power BI サービスでサポートされていません

カスタム Active Directory フェデレーション サービス (AD FS) 認証エンドポイントを使用する機能は、Power BI サービスでサポートされていません。 次のエラーを発生する可能性があります: リソースによって報告されたトークン サービスが信頼されていません

制限事項: ゲスト アカウントはサポートされていません

テナントのゲスト アカウントを使用して、Power Query コネクタを使用しているデータに接続することは、現在サポートされていません。

Expression.Error: 評価でスタック オーバーフローが発生したため、続行できません

スタック オーバーフロー エラーは、M コードのバグによって発生する可能性があります。 たとえば、次の関数は、終了条件なしで自身へのコールバックを繰り返すため、スタック オーバーフローを生成します。 このような自身を呼び出す関数を "再帰" 関数といいます。

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

M コードのスタック オーバーフローを解決する一般的な方法を次に示します。

  • 予期される終了条件に達したときに、再帰関数が実際に終了することを確認します。
  • 再帰を反復に置き換えます (たとえば、List.TransformList.GenerateList.Accumulate などの関数を使用します)。

Expression.Error: 評価でメモリが不足するため、続行できません

"メモリ不足" (OOM) エラーは、非常に大きなテーブルに対してメモリを大量に消費する操作が多すぎることが原因で発生する可能性があります。 たとえば、次の M コードでは、一度に 10 億行をメモリに読み込もうとするため、OOM が発生します。

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

メモリ不足エラーを解決するには、ソースにフォールドするか、可能な限り完全に削除することで、並べ替え、結合、グループ化、重複排除などのメモリを多く消費する操作を最適化します。 たとえば、並べ替えは多くの場合不要です。

データフロー

データフローの更新をキャンセルする

まれに、データフローの更新を開始した後に、データを更新する前にもう 1 つ変更することがあったことに気づくことがあります。 その場合は、更新が完了するまで待つ必要があります。 データの取得とワークスペースまたは環境内のテーブルの更新をプロセスで既に実行している最中に、更新を停止することは現在サポートされていません。

今後、データフロー更新のキャンセルのサポートを追加する予定です。