タグ別アーカイブ: エラー

Power Queryに強くなる~M言語/コードに慣れましょう~ 第10回

【Power Queryはあくまでコードでできています。これが今回のポイントです】

Power Queryはとても便利です。メニューをクリック操作していくだけでかなりのことができます

但し、メニュー操作に慣れてしまうと、エラーが起こった時に対処方法が分からなかったりします

そして、もう一つ問題があります

Power Queryが登場してから数年が経ちました

他の方が作成したPower Queryをメンテナンスする機会も増えていくと思います

この時、コード自体を理解できないとメンテナンスは行いにくいです

ですので、これからはPower Queryで書かれているMコードを理解できることも重要になっていくと思います

私も他の方が作成したPower Queryを修正する仕事をしていますが、Mコードを直接理解できないと仕事になりません

今回の記事を通じて、Mコードに慣れる機会にして頂けると嬉しいです

但し、今回の記事ではMコードを書くことは意図していません

あくまで、Mコードを読めるように訓練していく必要性と、Mコードを読む勘所を掴んで頂きたいと思います

今回のポイント

Power QueryのMコードはStepが連なってできています

ここがM言語の最大のポイントです

しかも前後左右、Step間で整合性が取られています

このStepに慣れるとそのままM言語に慣れることができます

Stepの中身の確認

ここからは実際に同じように手を動かしてみて頂くと分かりやすいと思います

たとえば、以下の画像のような平均金額を計算したPower Queryがあるとします

もちろんStepは「ソース」からはじまっています

Stepの中身は2つの方法で見ることができます

一つは数式バーです

二つめは詳細エディターです

こちらはホームタブから見ることができます

詳細エディターをクリックするとコードを丸ごと見ることができます

コードの中身を見て頂くと前後、Stepがつながっているのが良くわかります

let
①ソース = Excel.CurrentWorkbook(){[Name=”売上データ”]}[Content],
②変更された型 = Table.TransformColumnTypes(①ソース,{{“日付”, type datetime}, {“客先”, type text}, {“商品”, type text}, {“売上金額”, Int64.Type}}),
③計算された平均 = List.Average(②変更された型[売上金額])
in
③計算された平均

Stepの意味合い

試しにこちらの数式の中身を「ソース」に変えてみます

画像に alt 属性が指定されていません。ファイル名: image-40.png

そうするとどうなるでしょう?

表示はソースStepの内容になります

つまり、Step名自体に意味があります

Step名そのものが「データテーブル」を意味します

よくあるエラー

ここからは実践的な内容として、よく起こるエラーと対策について紹介します

ソースの変更

ソースステップの数式を見てみましょう!

数式の中身は次のようになっています

= Excel.CurrentWorkbook(){[Name=”売上データ”]}[Content]

試しにデータソースとなっている「売上データ」を「売上データ2」に変えてみましょう!

すると次の画像のようなエラーが発生します

この手のエラーはよく発生します

この場合、元のテーブル名に戻すか次のように数式を変更します

そうすればエラーは解消されます

変更された型

今度はソースステップで列名を変更してみます

そうすると以下の画像のようなエラーがでます

こちらはよく起こるタイプのエラーです

ところで「変更された型」Stepとはなんでしょう?

= Table.TransformColumnTypes(#”名前が変更された列 “,{{“日付”, type datetime}, {“客先”, type text}, {“商品”, type text}, {“売上金額”, Int64.Type}})

この「変更された型」Stepでは、各列の形式を設定しています

ここで1つ前にStepも含めて「変更された型」Stepを見てみましょう!

①名前が変更された列 = Table.RenameColumns(ソース,{{“商品”, “商品2”}}),
変更された型 = Table.TransformColumnTypes(名前が変更された列,{{“日付”, type datetime}, {“客先”, type text}, {“商品”, type text}, {“売上金額”, Int64.Type}}),

①名前が変更された列Stepでは「商品」列を「商品2」列に列名を変更しています

次の①変更された型では「Table.TransformColumnTypes(名前が変更された列」となっているので、①の名前が変更された列のテーブルデータを引き継いでます

つまり、「商品2」の列名を持つテーブルデータを引き継いでます

でも、②変更された型Stepでは商品列を「type text」、文字列形式にしています

{“商品”, type text}

ということは、既に存在しない列名を文字列形式に変更しようとしています

ですので、前述のエラーメッセージが出るわけです

画像に alt 属性が指定されていません。ファイル名: image-49.png

ではどうやってエラーを解消したらいいでしょう?

一番シンプルなのは変更された型Stepを削除することです

これで、Step間の整合性が取れるからです

let
ソース = Excel.CurrentWorkbook(){[Name=”売上データ2″]}[Content],
名前が変更された列 = Table.RenameColumns(ソース,{{“商品”, “商品2”}}),
計算された平均 = List.Average(名前が変更された列[売上金額])
in
計算された平均

では、どうやって形式変更を行ったらいいでしょうか?

手動で各列を変更するか、すべての列を選択した上で「データ型の検出」を行います

ちなみに、「変更された型」の自動設定を解除したかったら、ファイルタブから「クエリのオプション」を選択します

次に開く画面で「データの読み込み」から「非構造化ソース・・・を検出しない」を設定しておきます

そうすれば、次から「変更された型」Stepは自動で設定されなくなります

<まとめ>

今回の記事では、M言語/コードに慣れるきっかけになるような事例を幾つか紹介させて頂きました

この記事だけで飛躍的にPower Queryの技術が向上するわけではないですが、コードに注目していけば継続的に技術が向上していくはずです

今回の記事は本当に触りだけですが、本格的にM言語を学びたい方はこちらの記事をぜひご利用ください

尚、Udemyで動画コース「Power Queryのメニューにはない裏技ができる! M関数を学んで使えるようになる講座」をリリースしています

期間限定ですが、無料クーポンを提供させて頂きますので、ぜひご利用ください!

終了したら、レビュー投稿の程よろしくお願いします!

今後の参考にさせて頂きます!!

にほんブログ村 資格ブログ ビジネススキルへ

にほんブログ村

にほんブログ村 IT技術ブログ VBAへ

Power Automateのフローがもし失敗したら~エラー対策~

【フローが失敗しても、気づかないまま・そんなことがないように対策を打ちましょう!】

エラー対策はPower Automateのようなローコードの開発でも重要です

Power Automateの場合は、トリガーが「ボタンを押す」以外のケースがほとんどなのでエラーが起こったことに気づきにくいです

今回は簡単な方法でエラー発生時に通知が来るようにしましょう!

ポイント

アクションの右上の三点リーダをクリックすると「実行条件の構成」というのが選べるのをご存じでしょうか?

実行条件の構成では、前ステップがエラーの場合のみアクションを動かすように設定を行うことができます

1段階目⇒単独実行

まず最初に、敢えてエラーを出すアクションを作成しましょう

データ操作コネクターの「作成」アクションで1÷0を指定します

数式はdivを使用します

割り算した時に分母が0なので必ずエラーになります

ここでポイントで解説した「実行条件の構成」を調整したフローを追加します

ここでは「メール通知を受け取る」アクションを使用します

このアクションは該当フローを作成したアカウントにメールを送信します

こちらのアクションの実行の構成を調整し、一つ前の「作成」アクションがエラーになった場合はメールの通知を行うようにします

これで「作成」アクションがエラーになったら「メール通知を受け取る」アクションが実行されます

逆に作成アクションをエラーにならないように中身を変えたらどうなるでしょうか?

この場合は、そもそもアクションが実行されません

2段階目⇒並列実行

前述のフローだと、エラーが発生しなければアクションは実行されません

ただ大抵の場合は、エラーが発生しない場合は後続処理を実行する必要があるケースが大半のはずです

その場合は「並列分岐の追加」を行います

これで、エラーが発生しない場合の後続処理を続けることができます

3段階目ー対象を複数アクションに拡大

前述の内容は、特定のアクションにてエラーが発生した場合のみエラー対策が実行されます

実際のフローではどこのアクションでエラーが発生するか分かりません

エラー対策のアクションを拡大する場合は「スコープ」アクションを使用します

こちらのアクションでは複数のアクションをまとめて活用できます

このスコープアクションを「実行条件の構成」の対象にすれば、スコープの中のどれか一つがエラーになるとエラー対策として設定したアクションが実行されます

エラー内容を知りたい場合

通知内容の中に「エラー内容」を入れたい場合は「actions関数」を使用します

上の画像のように()の中にエラー検知対象のアクションの名前を設定することにより、エラーの中身が取得できます

こちらが「メール通知を受け取る」アクションで通知された中身です

こちらだと情報が多すぎるという場合には、下の画像の黄色の部分に絞ってエラーの中身を抽出することができます

前述のactions関数に?を2つ続けます

actions(‘スコープ’)?[‘error’]?[‘message’]

これによりエラーメッセージの中身を絞り込むことができます

<まとめ>

今回は「実行条件の構成」を軸にPower Automateにおけるエラー対策について解説を行いました

Power Automateはローコードとはいえ、システム開発にエラー対策はつきものです

常にエラー対策は意識しておきましょう

にほんブログ村 資格ブログ ビジネススキルへ

にほんブログ村

にほんブログ村 IT技術ブログ VBAへ

独自の入力チェックを導入して、アプリ運営を効率化する方法

【入力チェックを効果的に行うことでアプリ運用を適切に行えるようにしましょう!】

アプリを実際に運用しだすと「こんな風に入力しないで・・・」という問題が必ずおきます。この問題はできるだけアプリ内で事前に防げるようにしましょう

ポイント

実はデータカード内にはエラーメッセージ表示用の仕組みがあります

例えば、入力必須の項目が未入力の場合には上記の画像の箇所/ErrorMessage・・・から表示されます

表示は「Parent.Error」で行われます

この記事ではこのParent.Errorをうまく使いこなせるようにします

Parent.Errorはあくまでエラーが発生した時にだけ表示されます

エラーが発生した時の「Parent.Errorのメッセージ」を活かしつつ、エラーが発生する前にもメッセージを表示するためにCoalesce関数という関数を使用します

この関数は空白でない文字列の最初のものを表示します

つまり、エラーが発生していない時は「Parent.Errorでないもの」を表示します

エラーが発生した時には「Parent.Error」を表示します

ちなみに「parent.Error」は上の画像のようにText欄に設定されます

入力必須の設定

入力チェックの一番の基本は「入力必須」です

こちらは下の画像の「詳細設定」で行います

詳細設定の「Required」をtrueにするとチェックが設定されます

「Required」をtrueにした箇所を空欄にしたままSubmit関数を実行するとエラーメッセージがでます

入力範囲のチェック

入力項目の中には「いくら以上で」とか「いくら未満で」といった風に、範囲を制限するケースがあります

このケースではCoalese関数とIF関数を組み合わせます

下は500以上の入力を必須にするケースです

Coalesce(Parent.Error,If((Value(DataCardValue2.Text)<500) && !IsBlank(DataCardValue2.Text),”500以上で入力してください”))

上の数式ではCoalese関数を使用することにより、エラーが実際には発生していない時にはIf関数の中身を表示します

IF関数内では条件を2つ、AND条件で設定しています

①(Value(DataCardValue2.Text)<500) && ②!IsBlank(DataCardValue2.Text)

①は値が500未満という数字の制限です

②は!(否定)を付けることで値がブランクでない場合という制限です

形式のチェック

数字形式の入力が必須の箇所で、文字列が入力されるとエラーが表示されるようにします

今回もCoalese関数とIf関数を組み合わせます

但し、IsMatch関数という関数も組み合わせて使用します

IsMatch関数では事前定義済みパターンというものを設定します

IsMatch関数内でパターンに一致しない場合にはメッセージを表示できるようにします

Coalesce(Parent.Error,If(!IsMatch(DataCardValue5.Text,Match.MultipleDigits) && !IsBlank(DataCardValue5.Text),”数字のみで入力してください”))

ちなみに上記のIF式内では「!(否定)」を使用して!IsMatch(~、つまり~が一致しない場合としています

今回はMultipleDigitsという事前定義済みパターンを使用しています

こちらのパターンは「1 桁以上の数と一致します」というパターンです

MultipleDigits以外にも様々なパターンがありますのでぜひこちらを確認してみてください⇒詳細

<まとめ>

今回はPower Appsで入力チェックを行う方法を解説しました

Parent.Errorと空欄を無視するCoalese関数をうまく活用するのがポイントです

作成したPower Appsを使用してもらっても、入力されたデータが不完全だとあまり意味がありません

今回の入力チェックの仕組みはぜひうまく使いこなしましょう!

にほんブログ村 資格ブログ ビジネススキルへ

にほんブログ村

にほんブログ村 IT技術ブログ VBAへ

Power automate desktopでエラーをうまく扱う方法

【RPAにエラーは付き物です。エラーをうまく扱えばRPAの扱いそのものを向上させることができます】

今回の記事では、エラーが発生した時の対象方法について複数解説します

エラー対策のツボである「原因を突き止めやすくしておく」、「エラーが発生した場合の影響を軽微にとどめる」工夫に活かしていただきたいと思います!

リトライを行う

Power automate desktopの各アクションでは下の画像のように、エラーが発生した時の対処が指定できるようになっています

上の画像の箇所をクリックすると下の画像の画面が開きます

デフォルトでは「エラーが発生した場合にアクションを再試行する(リトライ)」はオフになっています

リトライをオンに設定することで、エラー発生後も指定回数・間隔にて該当アクションを再実行できます

別ルートの実行

ラベルアクションを使用することで、エラー発生時の処理の流れを事前に指定した内容に変えることができます

まずはラベルをフローの適切な場所に設定しましょう

今回はラベルを「エラー発生」のメッセージを表示するアクションの前に置きます

こうすることで「Excelの起動アクション」がエラーになった場合、こちらのラベル:myErrorにフローが飛び、メッセージを表示できるようします

ラベルを設定したので、今度は「Excelの起動アクション」のエラー発生時の設定を変えます

「フロー実行を続行する」を選択したうえで、「ラベルに移動」を選択します

上の画像の「ラベルの選択」は先ほど設定したラベルを選択します

これでフローを実行してみます

本来は「エクセルの起動」アクションの箇所でエラーメッセージが出て止まります

今回はラベルを事前に仕込んであるので、フローの流れが変わり、ラベルから下が実行されるようになっています

エラーメッセージ表示

エラーメッセージそのものをフローの流れの中で表示したいときには「最後のエラーを取得」アクションを使用します

「最後のエラーを取得」アクションにてエラー内容を変数に格納することができます

こちらの変数(上記画像ではLastError)をメッセージボックスに格納すればOKです

これで前述のラベルと組み合わせればエラーメッセージがエラー発生時に表示できるようになります

まとめてエラー対策

今までの解説で「いちいちフローごとにエラー対策はできない・・・」と感じた方もいらっしゃると思います

その場合には「ブロックエラー発生時」アクションを使用します

このアクションで下の画像のように「End」の箇所までをまとめてエラー対策を行えます

まとめてエラー対策を行う方法としては「サブフロー」を実行する方法がおすすめです

まず事前にサブフローを作成しておきます

次に「ブロックエラー発生時」アクションの編集をクリックします

次に開いた画面では、以下の箇所をクリックします

ここで「サブフローの実行」を指定できるようになります

こちらで事前に作成したサブフローを指定してください

これでEndで囲んだブロック内でエラーが発生した場合は一括で同じ処理が適用されます

ログファイル作成

エラー対策を実行するのに有効な手段として、エラー発生履歴を管理しておくというのもあります

先ほどのブロックでのエラー対策にてサブフローを実行しました

こちらのサブフローに、上記の画像のような発生時間をファイル名にした「ログファイル」を出力するフローを作成します

ログファイルに入れる内容としては「エラー内容」「発生日時」になります

ですので「最後のエラーを取得」「現在の日時を取得」アクションで「エラー内容」と「現在時刻」を取得します

取得した現在時刻は「datetimeをテキストに変換」アクションでファイル名に盛り込める形に変換しておきます

取得した「エラー内容」、変換した「現在時刻」はリストに格納しておきます

次に空のCSVファイルを作成します

「Excelの起動アクション」で新規にファイルを作成し、変換した「現在時刻」を盛り込んだファイルパスにてCSVファイル形式で保存します

最後に「CSVファイルに書き込む」アクションで先ほど作成したリストを空のCSVファイルに書き込みます

これでエラー発生都度、ログファイルを作成するフローが完成です

にほんブログ村 資格ブログ ビジネススキルへ

にほんブログ村

にほんブログ村 IT技術ブログ VBAへ

【分析作業用】大量データを1目で把握する

 Power Queryには旧エクセルの「104万行」の壁がありません。ですから大量のデータも手軽に扱えるのが魅力です。ところが、Power Queryエディタ(以降、エディタ)では、旧エクセルのように、ショートカットキーを活用してデータ内を端から端まで散策するようなことができません。ですので、エディタ内ではデータ全体を把握しずらいのです。

しかも行数が1000行以上だと全ての行は表示されないようになっています

これは大量のデータがあっても、素早く動くようにするための工夫ですが、ユーザーにとっては不便です。

 但し「散策」できない点を補完する機能がエディタ内の「表示タブ」にあります。今回は「表示タブ」での「補完機能」について解説します

今回解説する補完機能の内容は次の3つになります

1.データの列数を1目で把握する

2.データの行数を1目で把握する

3.エラーの発生数を1目で把握する

 上の3つは、どれも「表示」タブ内の簡単な操作で把握できる内容になっています

では、今回解説する内容について紹介したところで、詳細な解説をはじめます

1.列数を把握する

「一体、このデータはどこまで右に続くのか?」

列数があまりに多いと、最終列を探す旅にでかけなくてはなりません

前述の表示タブでは、少なくとも「列数」はすぐに把握できます

表示タブの左下に列数が表示されています

こちは、行数についても「1,000行以下」であれば表示されています

続きを読む 【分析作業用】大量データを1目で把握する

エラー修正_処理ステップエラー~上級編5回目

こんにちは、Excellent仕事術ガッツ鶴岡です

Power Queryは従来のエクセルとは、使用の仕方が違います

ですのでエラーが発生した時の対処については、最初は戸惑います

 但し、Power Queryで発生するエラーは大きく分けて「処理のステップ」に関わるものと「データ自体」に関わるものの2つしかありません

エラーメッセージの内容を確認しながら、修正処理を進めていきましょう!

 「処理のステップ」に関わるエラーの中でも、発生頻度が多いのはファイルの保存先変更などに伴う「データソース取得のステップ」に関するものです

今回は、ファイルの保存先を変更した場合のエラーへの対処について解説します

目次

1.エラーの発見

2.データソースの変更

3.更新処理

<まとめ>

1.エラーの発見

クエリが参照しているファイルが見つからない時にクエリの更新処理を行うと、次のようなメッセージが出ます

上の画像は、クエリが参照しているファイルの保存フォルダを変更したために発生しています

このメッセージが出た場合には、エラーメッセージが出ているクエリの編集をPower Queryエディターで行います(今回はダウンロードは完了していません、のメッセージが出ているクエリで行います)

2.データソースの変更

Power Queryエディターを開くと、次の様なメッセージが出ているはずです

この場合には、画面上の右にある「データソース設定」ボタンをクリックします

データソース設定

次は、画面の左下にある「ソースの変更」をクリックするのですが、ボタンが小さくて分かりずらいので注意が必要です

後はデータソースの変更を、下のGIFのように進めてください

続きを読む エラー修正_処理ステップエラー~上級編5回目

途中のステップを削除した場合のエラー修正処理~上級編6回目

こんにちは、Excellent仕事術ガッツ鶴岡です

 Power Queryは便利だけど、通常のエクセルとは使用方法が違うので苦労する点も多いですよね

 特にPower Queryエディターは、これまでのエクセルとは画面自体が違うので「理解に苦しむ」人もいらっしゃると思います

 Power Queryエディターの画面右にある「ステップの適用」は通常のエクセルでいえば、ショートカットキー:Ctrl+Zに相当する箇所なのです

 こちらの「ステップの適用」は最初は難解に感じる人もいらっしゃるかもしれません

 今回は、「ステップの適用」にて途中のステップを削除した場合の修正方法について解説します

 今回の解説を通じて、Power Queryへの理解の一助になれば幸いです

1.ステップを削除する前の状態の説明

今回は、以前の回で使用したデータを使用します

この回では、下のGIFのように販売単価と販売個数の合計を乗算して、新たな列を作成しました

その後に、新しくできた列の名前を下の画像のように「乗算」から「売上金額」に変更しました

今回は、更に売上金額の列を10万円以上でフィルダーをかけます

すると、適用のステップには次の画像のように1つのステップが追加されます

では、この状態から本題の解説に入ります

2.1つ前のステップを削除

1.で追加してステップの1つ前を削除します

すると、次の画像のようにエラーメッセージが発生します

1.でフィルターを10万以上した際には、あくまで「売上金額」の列に対してフィルターをしています

そのフィルターをした「売上金額」の列が削除されてしまったのでエラーになっています

3.エラーの修正

このエラーを修正するには、2つの方法があります

1つは、フィルターされた行を削除し、列名を変えるところからやり直す方法です

2つ目については、解説を始める前にまず「フィルターされた行のステップ」の1つ前のステップ「挿入された乗算のステップ」をクリックしてみます

上のGIFのように1つ前のステップを選択するとエラーメッセージは消えました

これは、あくまで次のステップである「最後尾のステップ」からエラーになっているということです

ここからが2つめの修正方法の解説です

解説するのはエラーになっていないステップから修正をかける方法です

エラーが起こっていない、「最後尾のステップの1つ前」のステップにカーソルを置いたまま、列名を1.でフィルターをかけた時と同じ「売上金額」に変更します

すると、下のGIF画像のようにエラーが起きていた最後尾のステップ「フィルターされた行」をクリックしてもエラーメッセージは出ません

<まとめ>

 今回は、途中のステップを削除した場合のエラー修正について解説しました。このような場合には、必ずしもエラーが起きたステップを削除した後に「やり直し」処理が必要なわけでありません

 エラーが起きていないステップから再度修正をかける方法もあります

 とはいえ、極力は途中のステップはなるべく削除しないで済むようにはしておきましょう

 尚、解説を端折ってしまいましたが、途中のステップを削除すると必ずエラーが発生するわけではありません

 あくまで、途中のステップを削除することで前後の処理の流れに矛盾が起こる場合にエラーが発生しますので、その点だけ最後に追記させて頂きます

長文に最後までお付き合い頂き誠にありがとうございました

次回はデータ自体がエラーになっている場合について解説します

にほんブログ村 資格ブログ ビジネススキルへ
にほんブログ村 IT技術ブログ VBAへ

にほんブログ村

エラー修正_データ自体のエラー~上級編7回目

こんにちは、Excellent仕事術ガッツ鶴岡です

 今回は、上級編の5回目で事前にアナウンスしたようにPower Queryのエラーのうち、「データ自体」のエラーの修正方法について解説します

 解説に使うデータは5回目と同じく、中級編の2回目と同じデータを使用します

 中級編の1回目では上の2つの表を組み合わせて、下のテーブルを作成していました!

商品台帳の販売単価と売上台帳の販売個数を乗じて、「売上金額」を新たな列として追加してあります

目次

1.エラー内容の確認

2.修正作業

<まとめ>

1.エラー内容の確認

下のクエリのようにエラーが発見された、というところから解説をスタートします

次に、上の画像の「1つのエラーです。」をクリックします

 すると、Power Queryエディターが開き、下の画像のようにエラー箇所が表示されます

今回のエラーは、販売単価と売上金額にてエラーが発生しています

 売上金額は販売個数と「商品台帳.販売単価」を乗じているので、大元の商品台帳のクエリにて「データ自体」の「狂い」生じている可能性があります

 ですので、エラーが発生している可能性があるクエリの中味を確認するため、エディターの矢印マークをクリックします

 すると、下の図のようにクエリーの一覧が表示されます

では、「狂い」生じている可能性がある商品台帳クエリーをクリックします

すると上の画像のようにやはり「狂い」が生じている箇所がありました

では、「Error」の箇所をクリックしてみます

すると、やはり本来は数字が入っているべきところに「!!!」が入っていました

 エラーの中味を確認したら、画面右の「適用したステップ」に追加されたステップを削除して元の画面に戻ります

エラーの箇所が特定できたところで、ここから2つの修正方法を解説します

続きを読む エラー修正_データ自体のエラー~上級編7回目

#SPILLエラーについて~新関数に独自のエラー

こんにちは、Excellent仕事術ガッツ鶴岡です

 これまで、1つのセルへの入力で複数セルに出力する新関数について、複数の記事を書いてきました

 例えば、下のGIF画像はFILTER関数を使った検索付きのリストの例です

 C列にFILTER関数を仕込んであり、E列で検索文字「鈴木」が設定されるとA列のリストデータから「鈴木」を含むリストデータを出力します

 この新関数では独特のエラー「#SPILL」が出力される時があります

このエラーの意味について、今日は少し解説したいと思います

SPLLLエラー

見慣れないエラーですが、発生理由はシンプルです

 この新関数は複数のセルに出力を行いますが、出力範囲に何らかの入力がある場合にこのエラーは発生します

 

上の画像で言えば、!の文字が新関数の出力をブロックしてるのです

このブロックしている文字を取り除けば、このエラーは解消されます

 尚、ブロックしている文字のフォントが「白色」で人の目では見えない時にも同じエラーが発生するので注意が必要です

では、今回は以上です

最後までブログ記事を見て下さり、大変感謝しております!

にほんブログ村 資格ブログ ビジネススキルへ
にほんブログ村 IT技術ブログ VBAへ

にほんブログ村

エラー発生の予防/列のデータ形式変更と削除について~上級19回~

 Power Queryの便利な点は、普段から使い慣れたエクセルをAccessのようなデータベースとして活用できる点です。このページを訪問して頂いた方の中にもAccessは細かなルールが多くて不便と感じた方もいらっしゃったと思います。

 Power Queryは自動で、Accessの不便な点を補ってくれる機能があります。そのかわり、エラーが出やすい箇所があります

このエラーはPower Queryの2つの特徴と深く結びついています

 Power Queryの2つの特徴について解説しながら、「列名変更」に関するエラーの発生を防ぐ方法について解説します

 エラーの発生を防ぐ方法を理解した時には、「データ形式」も含めてPower Queryへの理解が一段と深まっているはずです!

ところで、

エクセルとAccessの違いとは何でしょう??

エクセルはあくまで表計算ソフトです

Accessはデータベースソフトです

 この2つの違いを、別な言い方で表現すると「データの構造化」ということになります

こちらが、Power Queryの特徴の1つ目の話しです

Accessでは、いきなりデータから入力はできないようになっています

 上の画像のように「データを入力する箱」をフィールド毎(エクセルでは列毎)に「フィールド名/見出し」「データ型」を設定しなくてはいけません

つまり、予め入力するデータの箱を「構造化」しておくわけです

 今回の解説では、上の画像についてはこれ以上は深入りしませんが、上で前述した「データの構造化」を意識して、以降の記事を読み進めてみてください!!

今回、解説に使用するデータは次の画像のデータです

 こちらの3列(売上日、商品コード、販売個数)からなるテーブルデータから、下の画像のように商品コードの1列を抽出するクエリを作成しておきます

そして、元のテーブルデータの「販売個数」の列名を変えます

すると、「商品コード」のみを抽出するクエリを更新するとエラーになります

 エラーの中味を見てみると、抽出する「商品コード」とは関係ない列の「名前変更」によりエラーが発生しています

実は、このエラーは前述の「データの構造化」が深く関係しています

では、こちらのエラーを回避する方法を以下、2パターンで解説します

1.ステップ「変更された型」の削除

まずは、前述のクエリの中味をPower Queryエディタ(以降、エディタ)で見てみます

適用したステップは3つあります

こちらの3つのステップを、上から順に各ステップの「数式」を見てみます

①ソース

こちらは、ファイル内の「売上台帳」テーブルをデータソースとして読み込んでいるのが分かります

②変更された型

こちらのステップでエラーが発生しているのが、よく分かります

こちらの数式に含まれる「販売個数」は、既に名前が変更されているのでエラーが発生しています

③削除された他の列

こちらのステップで「商品コード」列のみを抽出しています

 実際には、次の画像のように「商品コード」以外の列を削除してステップが作成されています

①~③のステップの中味を確認したところで、エラー原因となった②のステップを削除してみます

すると、エラーは消えます

仮に元の列名が「販売個数」の列名を、再度変更してもエラーは発生しません

これで、列名の変更でエラーが発生しないクエリに変更できました

ところで、

今回のエラー発生の原因となった「変更された型」のステップとはなんでしょうか?

エディタを開く時には、「変更された型」のステップは自動挿入されています

このステップは記事の冒頭で前述したPower Queryの1つ目の特徴である「データの構造化」と深くかかわっています

試しに下の画像のように、最初からクエリを作成してみます

開いたエディの中味を見ると、「変更された型」が前述のように自動追加されています

そして、各列も自動で「型式」が変更されています

例えば、商品コードの型式は元々は「文字列」でしたが、下の図のように「123」マークの「整数型式」に自動変換されています

下の図のように元のデータにて、数字かどうかを判定する数式「ISNUMBER」で判定するとFALSEになり、「文字列」だったことがよく分かります

記事の冒頭で前述したように、エクセルはあくまで表計算ソフトです

表計算ソフト内にあるデータは、データベースとしては構造化されていません

Power Queryでは、Accessとは違い、自動でエディタ内にて「構造化」の設定を行ってくれているのです

ちなみに、AccessのファイルをPower Queryで読み込むと「変更された型」のステップは発生しません

 AccessファイルをPower Queryで読み込む方法は過去の記事で紹介していますので、興味のある方は試してみてください

話をPower Queryの「構造化」に戻します

「構造化」は元データの全ての列に対して設定を行うので、エディタ内で削除した列も設定の対象です

しかも「構造化」は元の列名に対して行われます

ですので、一見、クエリに関係ない列の「名前の変更」が影響するのです

 但し、「商品コード」が文字列から「整数」に変換されたように、常に正しく「構造化」が行われるわけではないので注意が必要です

自動で変更された型を変更する場合には、下のGIF画像の箇所で調整を行います

下の図のように「文字列」は「テキスト」となっている点に注意してください

上の図の詳細な内容については、一覧でMicrosoft社のHP内で紹介されています

さて、

 エラー発生の対策をしたクエリからは「変更された型」のステップは削除されていますが、こちらのステップを後から追加することもできます

上の画像の黄色の箇所にある、変換タブ内の「データ型の検出」をクリックすると、「変更された型」のステップが追加されます

2.削除の仕方の変更

2.削除の仕方の変更では、1.とは別なアプローチでエラーを解決してみます

まず、エディタ内の画面左側から1.でエラーが発生しなくなったクエリを「複製」してみます

複製したクエリの最終ステップでは、前述のように「商品コード」以外の列を削除しています

画像に alt 属性が指定されていません。ファイル名: image-235.png

こちらのステップを削除して、次のGIF画像のように他の2つの列を1つ1つ削除します

2つの列を削除した後、エクセルシートに読込みます

次に、列名を「TEST2」から「TEST3」に変更すると複製したクエリはエラーになります

このエラーの原因は「列の削除の仕方」にあります

下の図のように、列名変更前の「TEST2」の列名を指定して「列の削除」をおこなっているからです

 こちらのエラーについては下の画像の黄色の箇所のように、列の削除の仕方を「列名」を指定しない方法(他の列の削除)で行えば発生しません

画像に alt 属性が指定されていません。ファイル名: image-235.png

このエラーはPower Queryの「ハードコード」という特徴と深く結びついています

Power Queryでは、エディタ内の操作がステップとして記録されます

このステップ内には、も記録されます

前述のエラーで言えば、「列名を変更する前」の列名です

こちらは、列名が変更になると「ハードコード」した列名と一致しなくなってしまい、エラーになったのです

<まとめ>

 今回は、エディタ内で削除した「列名」を後から修正した場合に発生するエラーの修正方法について2つ解説しました

 1つ目は「変更された型」という自動で追加されるステップを削除してエラーを回避できるようにしました

2つ目は列の削除の仕方を、削除する列名を特定しない方式に変更しました

2つの方法はそれぞれ、Power Queryの2つの特徴と深く結びついています

 1つ目の「変更された型」に関するエラーは「データの構造化」というPower Queryの特徴と結びついています

 エディタでデータを読み込む際に、全ての列を対象にして「見出し」「データ形式」を設定します

ですので、エディタ内で削除した列の「列名変更」がエラーの原因になります

 こちらの「変更された型」については、「変更された型」のステップを削除する方法ともう一つ、対処方法があります

データタブの「データの取得」をクリックすると一番下に「クエリオプション」が出てきます

こちらをクリックすると次の画像の画面が開きます

こちらの画面で、「非構造化ソースの列と型とヘッダーを検出しない」を指定しておくという方法もあります(自動で検出されていた部分が検出されなくなるので注意が必要です)

ここまでで、Power Queryの1つ目の特徴についての「まとめ」を解説しました

次は2つ目の特徴である「ハードコード」についてです

Power Queryではエディタ内の操作が「ステップ」として記録されます

こちらの「ステップ」には値も直接書き込まれます

ですので、前述の2.で列を削除した際には「列名」も値として記録されました

ですので、エディタ内で削除した列の「列名」が変更になると、列名の「不一致」が発生してエラーになったのです

下の画像で言えば、「TEST2」の列名の列を削除するように数式が設定されていましたが、既に「TEST3」に列名が変更になっていたのです

画像に alt 属性が指定されていません。ファイル名: image-248.png

 今回はPower Queryの2つの特徴について、理解を深める機会になったと思います

この2つの特徴を理解しておくと、Power Query自体への理解も深まります

 ぜひ今回を機会に「データの構造化」「ハードコード」について意識した上でPower Queryに取り組んでいきましょう!

では、今回は以上となります

参考までに今回使用したエクセルデータを添付します

長文に最後までお付き合い頂き、まことにありがとうございました

にほんブログ村 資格ブログ ビジネススキルへ
にほんブログ村 IT技術ブログ VBAへ

にほんブログ村