一般的な問題
データを並べ替える場合、ダウンストリームの操作で並べ替え順序が維持されると仮定する場合があります。
たとえば、各店舗の最大売上が最初に表示されるように販売テーブルを並べ替えると、"重複の削除" 操作を実行すると、各店舗の上位売上のみが返される可能性があります。 また、実際に、この操作が機能するように見えることがあります。 しかし、この動作は保証されません。
各操作のスキップやデータ ソースへのオフロード (これによって固有の順序付け動作が行われる可能性があります) など、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 からデータを抽出するための (データ ソースのベスト プラクティスに従った) 代わりの方法に従う必要があります。
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 ディレクトリとゲートウェイのインストール内の共有コンポーネントへの読み取りアクセスが必要になる場合があります。
OAuth2 を使用して Power BI サービスからデータ ソースに接続する場合は、データソースが Power BI サービスと同じテナントに存在している必要があります。 現在、OAuth2 を使用したマルチテナント接続のシナリオは、サポートされていません。
カスタム Active Directory フェデレーション サービス (AD FS) 認証エンドポイントを使用する機能は、Power BI サービスでサポートされていません。 次のエラーを発生する可能性があります: リソースによって報告されたトークン サービスが信頼されていません。
テナントのゲスト アカウントを使用して、Power Query コネクタを使用しているデータに接続することは、現在サポートされていません。
スタック オーバーフロー エラーは、M コードのバグによって発生する可能性があります。 たとえば、次の関数は、終了条件なしで自身へのコールバックを繰り返すため、スタック オーバーフローを生成します。 このような自身を呼び出す関数を "再帰" 関数といいます。
let f = (x) => @f(x + 1) in f(0)
M コードのスタック オーバーフローを解決する一般的な方法を次に示します。
- 予期される終了条件に達したときに、再帰関数が実際に終了することを確認します。
- 再帰を反復に置き換えます (たとえば、List.Transform、List.Generate、List.Accumulate などの関数を使用します)。
"メモリ不足" (OOM) エラーは、非常に大きなテーブルに対してメモリを大量に消費する操作が多すぎることが原因で発生する可能性があります。 たとえば、次の M コードでは、一度に 10 億行をメモリに読み込もうとするため、OOM が発生します。
Table.Buffer(Table.FromList({1..1000000000}, Splitter.SplitByNothing()))
メモリ不足エラーを解決するには、ソースにフォールドするか、可能な限り完全に削除することで、並べ替え、結合、グループ化、重複排除などのメモリを多く消費する操作を最適化します。 たとえば、並べ替えは多くの場合不要です。
まれに、データフローの更新を開始した後に、データを更新する前にもう 1 つ変更することがあったことに気づくことがあります。 その場合は、更新が完了するまで待つ必要があります。 データの取得とワークスペースまたは環境内のテーブルの更新をプロセスで既に実行している最中に、更新を停止することは現在サポートされていません。
今後、データフロー更新のキャンセルのサポートを追加する予定です。