Меню

Power query поиск ошибок

 

ArNikiTenS

Пользователь

Сообщений: 29
Регистрация: 29.02.2020

Добрый день,

мной был сформирован файл-консолидатор информации из множества других отчётов в power query. Эти отчёты готовят коллеги, структура не меняется, но всегда может появиться лишний столбец или ещё что-нибудь, что ломает итоговый запрос консолидатора. Итоговый запрос работает просто, объединяет все запросы в книге. Если один запрос некорректный, то итоговый запрос не загружается и найти прохвоста вручную ах как не просто (запросов очень много). Есть ли какая-то функция или ещё что-то, что поможет найти сбойный запрос и причину возникшей ошибки (каждый раз может быть разной). Также интересует узнать, сколько отрабатывает каждый запрос, как это можно сделать?

p.s. обсуждаем не проблему файла, а метод/подход, приложить файл нет возможности и надобности.

Изменено: Якубович29.02.2020 17:25:29

 

Murderface_

Пользователь

Сообщений: 517
Регистрация: 19.10.2016

#2

03.03.2020 13:43:10

Цитата
ArNikiTenS написал:
может появиться лишний столбец или ещё что-нибудь

Можно просто задать требуемое имя для столбцов в итоговом запросе. Таким образом, если появится лишний столбец, то вы его не увидите.

 

PooHkrd

Пользователь

Сообщений: 6602
Регистрация: 22.02.2017

Excel x64 О365 / 2016 / Online / Power BI

#3

03.03.2020 14:30:08

Якубович, что можно посоветовать, учитывая что с вашей точки зрения

Цитата
ArNikiTenS написал:
обсуждаем не проблему файла, а метод/подход

могу дать совет в стиле Тони Роббинса:

Это значит что делать запросы нужно так, чтобы либо объезжать возможные ошибки, либо чтобы их поиск был максимально упрощен. Для этого можно использовать конструкцию try … otherwise …, например.

Изменено: PooHkrd03.03.2020 14:30:45

Вот горшок пустой, он предмет простой…

 

Якубович

Пользователь

Сообщений: 29
Регистрация: 29.02.2020

#4

08.04.2020 19:54:22

Цитата
Murderface_ написал:
Можно просто задать требуемое имя для столбцов в итоговом запросе. Таким образом, если появится лишний столбец, то вы его не увидите.

Возможно не правильно сформулировал, предположим есть 20 запросов, они преобразуют файлы от 20 человек до 2 столбцов: Дата и Сумма. Так как заполняют люди, то всегда может всплыть косяк заполнения данных (например 30.02.2019.). Так как запросы сохраняются в модель данных, то выводится только итоговый запрос, который сконсолидировал данные всех 20 человек. Если хотя бы 1 запрос содержит некорректные данные, то весь запрос не исполнится и не загружается в таблицу.

Вопрос в том, что надо найти тот самый запрос, который не отработал. Есть какая-то фишка в PQ для быстрого поиска засбоивших запросов?

 

Михаил Л

Пользователь

Сообщений: 2598
Регистрация: 19.02.2020

#5

08.04.2020 21:36:06

Цитата
Якубович написал:
30.02.2019.
Якубович написал:
надо найти тот самый запрос, который не отработал

проверить каждый запрос
Как? Не знаю без примера

НА МЯСО В ПРОФИЛЕ

 

Якубович

Пользователь

Сообщений: 29
Регистрация: 29.02.2020

#6

08.04.2020 22:20:52

Цитата
Михаил Л написал:
Не знаю без примера

Ваша взяла, сектор приз на барабане, пример в студию!

Цитата
Михаил Л написал:
проверить каждый запрос

Так если их не 20,а 100, по 1000 строк минимум, глазами не найти. У PQ же определенно есть  логи исполнения запросов, в настройках есть некая «трассировка», может это она?

В приложенном файле 3 запроса, не понятно  кто нашкодил (3 запрос), итоговая таблица выдает ошибку.

Внимание, вопрос. Как не руками и не нажимая на каждый запрос определить, кто выдаёт ошибку.

Также интересует, как узнать скорость обработки запроса. Хочется мне понять, кто среди запросов самый медленный, как это можно сделать?

P.s. по правилам форума нельзя выкладывать файлы более 100 кб,  тогда как выкладывать «тяжёлые файлы»?
P.s.s. файл сформирован в 19 офисе, здесь выдается кол-во ошибок, на работе стоит 16 офис и в файле консолидаторе число ошибок не выдается.

Прикрепленные файлы

  • Приз.rar (198.59 КБ)

 

Андрей VG

Пользователь

Сообщений: 11878
Регистрация: 22.12.2012

Excel 2016, 365

#7

08.04.2020 23:39:43

Доброе время  суток.
Вариант запроса для вывода запросов с ошибкой вывода

Код
let
    Source = Record.ToTable(#shared),
    errorFilter = Table.SelectRows(Source, each let test = try _[Value] in test[HasError])
in
    errorFilter

Изменено: Андрей VG08.04.2020 23:40:46

 

Михаил Л

Пользователь

Сообщений: 2598
Регистрация: 19.02.2020

#8

09.04.2020 06:18:54

Цитата
Якубович написал:
Ваша взяла

Это не мне надо

Код
let
    Источник = {Таблица1, Таблица2, Таблица3},
    SelectErrors = List.Transform(Источник, Table.SelectRowsWithErrors),
    toTable = Table.FromList(SelectErrors, Splitter.SplitByNothing()),
    Add = Table.AddColumn(toTable, "Пользовательская", each Table.RowCount([Column1]))
in
    Add

НА МЯСО В ПРОФИЛЕ

 

quasarrr

Пользователь

Сообщений: 77
Регистрация: 03.02.2020

#9

09.04.2020 08:33:24

Добавил номера строк с ошибками

Код
let
    Источник = {Таблица1, Таблица2, Таблица3},
    Индекс = List.Transform(Источник, each Table.AddIndexColumn(_, "Строка", 1, 1)),
    Строка = List.Transform(Индекс, each Table.TransformColumnTypes(_,{{"Строка", type text}})),
    SelectErrors = List.Transform(Строка, Table.SelectRowsWithErrors),
    toTable = Table.FromList(SelectErrors, Splitter.SplitByNothing()),
    Add = Table.AddColumn(toTable, "Количество", each Table.RowCount([Column1])),
    Add2 = Table.AddColumn(Add, "Строки", each Text.Combine([Column1][Строка], ", "))
in
    Add2

Наверно, ещё можно названия таблиц прилепить, если они называются чуть хитрее, чем Таблица1, Таблица2, Таблица3…

 

Михаил Л

Пользователь

Сообщений: 2598
Регистрация: 19.02.2020

#10

09.04.2020 08:58:41

еще вариант

Код
let
    Источник = {Таблица1, Таблица2, Таблица3},
    SelectErrors = List.Transform(Источник, each Table.SelectRowsWithErrors(Table.AddIndexColumn(_,"id"))),
    toTable = Table.AddIndexColumn(Table.FromList(SelectErrors, Splitter.SplitByNothing()),"Id")
in  List.RemoveNulls(Table.AddColumn(toTable,"a", each [a="Таблица "&Text.From([Id]),b=Table.RowCount([Column1]),
    d=Text.Combine(List.Transform([Column1][id],Text.From),", "),c=if b=0 then null else a&"   "&d][c])[a])

НА МЯСО В ПРОФИЛЕ

 

Якубович

Пользователь

Сообщений: 29
Регистрация: 29.02.2020

#11

09.04.2020 11:48:26

Андрей VG, спасибо.

Как я понял, 2 строка выбирает все источники в книге (включая функции), нужно ли выбирать конкретные запросы или #sourse пойдет на вход.

А вот что делает третья строка? Можно объяснить синтаксис?

Код
let test = try _[Value] in test[HasError]

quasarrr,Михаил Л,  спасибо!

Считаю второй вариант Михаила наиболее точно решает поставленную задачу (В варианте Андрея еще не разобрался).

Осталось придумать, как запихнуть автоматизацию выборов запросов через #shared и получится великолепное и изящное решение.

Также висит вопрос по скорости отработки запросов, как нам искать улиток из семейства запросов? Возможно ли как-то рассчитать скорость не только всего запроса, но и его операторов в отдельности?

P.s. Как также красиво писать код на форуме?

Изменено: Якубович09.04.2020 15:15:28

 

Максим Зеленский

Пользователь

Сообщений: 4646
Регистрация: 11.06.2014

Microsoft MVP

#12

09.04.2020 13:11:48

Цитата
Якубович написал:
как запихнуть автоматизацию выборов запросов через #sourse и получится великолепное и изящное решение.

наверное вы имели ввиду #shared.
Смотря где вы планируете смотреть результат. Если только в редакторе запросов — то отобрать только таблицы из всего большого перечня  проверить их на ошибки можно так:

Код
// tester
let
    Источник = Record.ToTable(#shared),
    FilterSelfOut = Table.SelectRows(Источник, each [Name] <> "tester"),
    FilterTables = Table.SelectRows(FilterSelfOut, each Type.Is(Value.Type([Value]), type table)),
    RowsWithErrors = Table.AddColumn(FilterTables, "Errors", let guid = Text.NewGuid() in each let errs = Table.AddIndexColumn(Table.SelectRowsWithErrors([Value]), guid) in if Table.IsEmpty(errs) then null else errs, type table),
    FilterEmpty = Table.SelectRows(RowsWithErrors, each ([Errors] <> null)),
    Removed = Table.RemoveColumns(FilterEmpty,{"Value"})
in
    Removed

запрос называется tester, и в 4 строчке (2-й шаг) мы удаляем его из списка во избежание циркулярных ссылок.
Но, повторю, в таком виде — без явного перечисления названий запросов — будет работать только внутри редактора запросов Power Query

F1 творит чудеса

 

Якубович

Пользователь

Сообщений: 29
Регистрация: 29.02.2020

Максим Зеленский,

Максим, да, это то что нужно! Спасибо!

Задачу с ошибками решили, осталось разобраться со временем отработки запроса и его компонент.

P.s. Жаль не могу сказать «Вы выиграли автомобиль!»)

 

PooHkrd

Пользователь

Сообщений: 6602
Регистрация: 22.02.2017

Excel x64 О365 / 2016 / Online / Power BI

#14

09.04.2020 15:47:38

Якубович, время отработки можно замерить только у того запроса, который выводит информацию куда-то (в таблицу/ модель/ кэш сводной) при этом не получится вычленить скорость выполнения его составляющих (тех запросов, на которые он ссылается), т.к. интерпретатор не рассматривает ваши запросы как отдельные, для него это все — один большой запрос, результат которого куда-то выводится.

Вот горшок пустой, он предмет простой…

1 Power Query Ошибки №1. Измененный тип, Неверная фильтрация в UI Почему возникает ошибка Expression.Error Столбец таблицы не найден? Одна из причин — шаг Измененный тип.
Почему в вашей итоговой таблицы не все данные, которые должны там оказаться? Вероятно вы совершили ошибку неверной фильтрации в пользовательском интерфейсе. 2 Power Query Ошибки №2. Фиксированная ширина столбца Excel В этом уроке вы узнаете как отключить автоматическое определение ширины столбцов таблицы Excel при обновлении запроса Power Query. 3 Power Query Ошибки №3. Formula Firewall, запрос ссылается на… Вы работаете в Power Query, но при попытке обновить все возникает ошибка Formula Firewall, запрос ссылается на… Что делать? Как исправить? 4 Power Query Ошибки №4. Доступ к веб-содержимому В этом уроке вы узнаете как избавиться от надоедливого окна доступ к веб-содержимому. 5 Power Query Ошибки №5. Количество столбцов CSV При импорте CSV получается неверное количество столбцов. 6 Power Query Ошибки №6. Не получается изменить тип данных (DataFormat.Error) При попытке изменить тип данных с текстового на дату возникает ошибка DataFormat.Error. 7 Power Query Ошибки №7. Разные имена листов В этом уроке мы решим проблему, когда в ваших источниках нужные вам данные находятся всегда на листах с разными именами. 8 Power Query Ошибки №8. Разные имена листов 2 В этом уроке мы другими способами решим проблему, когда в ваших источниках нужные вам данные находятся всегда на листах с разными именами. 9 Power Query Ошибки №9. Разные имена столбцов, Table.TransformColumnNames В этом уроке мы разберем проблему, когда нам присылают файлы, в которых всегда столбцы названы по-разному. 10 Power Query Ошибки №10. Как развернуть все столбцы В этой задаче мы научимся разворачивать все столбцы табличного столбца не перечисляя каждый из них хардкодом. 11 Power Query Ошибки №11. Подключиться к последнему файлу В этом уроке мы научимся подключаться к самому свежему файлу из нужной нам папки с нужным названием. 12 Power Query Ошибки №12. Консолидация и MissingField.Type Бывает вы ходите выполнить добавление таблиц друг под другом с предварительной обработкой, но получаете ошибку Expression.Error: Столбец таблицы не найден. 13 Power Query Ошибки №13. Удалить пустые столбцы Как без хардкода автоматически удалить пустые столбцы в Power Query, которые есть в импортируемой таблицы. Разберем 2 способа. Один из них прост до безобразия, а для второго понадобится функция Table.Profile. 14 Power Query Ошибки №14. Удалить лишние пробелы В этом уроке мы разберем еще 1 способ удалить лишние пробелы в текстовом столбце Power Query. Для этого мы повторим и изучим несколько новых функций.
Text.SplitAny
List.Select
Character.FromNumber
Text.Combine 15 Power Query Ошибки №15. Плохо структурированный TXT Как быть, если текстовый файл разбивается на столбцы неправильно? 16 Power Query Ошибки №16. При округлении не совпадает общая сумма Разберем ошибку, которая возникает при необходимости разбить число на определенные доли, а результаты округлить до двух знаков после запятой. В такой ситуации может получиться, что сумма слагаемых не будет равняться исходному числу. 17 Power Query Ошибки №17. Удаление дубликатов, Подводные камни Table. Distinct Что может пойти не так при использовании функции удаления дубликатов. 18 Power Query Ошибки №18. Удаление дубликатов 2, Подводные камни Table. Distinct Что может пойти не так при использовании функции удаления дубликатов. Другое решение данной проблемы. 19 Power Query Ошибки №19. Неверная разбивка на столбцы При импорте данных из CSV или TXT разбивка на столбцы происходит неправильно. 20 Power Query Ошибки №20. Пустая таблица при импорте Excel (XLSX, XLS) Вы пытаетесь подключиться к книге Excel, но импортируется пустая таблица. 21 Power Query Ошибки №21. Подключение к PostgreSQL, Установка драйвера Вы пытаетесь подключиться к PostgreSQL и получаете ошибку «Перед использование этого соединителя необходимо установить один или несколько дополнительных компонентов»

В М можно вызвать и обработать ошибки во время выполнения. Если из других языков программирования вы знакомы с идеей исключения, обработка ошибок Power Query отличается по крайней мере одним существенным моментом.[1]

Предыдущая заметка     Следующая заметка

Рис. 1. Три поля записи error; чтобы увеличить изображение кликните на нем правой кнопкой мыши и выберите Открыть картинку в новой вкладке

Скачать заметку в формате Word или pdf, примеры в формате Excel

Сообщение об ошибке

В Power Query каждое выражение должно что-то возвращать. Как правило, это значение. Но выражение также может вызвать ошибку – особый способ указать, что не получилось вернуть значение. Один из способов вызвать ошибку – создать запись с ключевым словом error. Такая запись имеет три поля: причина, сообщение и подробности. Поля с любыми другими именами будут проигнорированы.

Листинг 1[2]

= error [

Reason = «Business Rule Violated»,

Message = «Item codes must start with a letter»,

Detail = «Non-conforming Item Code: 456»

]

Все три поля являются необязательными. Если поле Reason отсутствует, причина ошибки будет иметь значение по умолчанию – Expression.Error. Запись ошибки можно также создать с помощью функции Error.Record. В отличие от описанного выше подхода, в Error.Record атрибут Reason является обязательным.

Листинг 2

= error Error.Record(

«Business Rule Violated»,

«Item codes must start with a letter»,

«Non-conforming Item Code: 456»

)

Оба приведенных выше примера приводят к эквивалентной ошибке, изображенной на рис. 1 Глядя на рисунок, видно, как три поля/параметра соотносятся с отображаемым сообщением.

Вместо записи error также может принимать строку. Результирующее сообщение об ошибке будет иметь значение предоставленной строки, а его причина – значение Expression.Error.

Листинг 3

Рис. 2. Строка в error

Ярлык с многоточием

Существует также оператор быстрого доступа для создания ошибок, который пригодится во время разработки. Допустим, вы хотите протестировать запрос, часть кода которого еще не написана. Поскольку каждое выражение должно возвращать значение, или вызывать ошибку, вы не можете протестировать свой запрос, не поместив что-то в качестве заполнителя в нереализованные участки кода. Используйте оператор многоточия (…). При вызове … выдает ошибку Expression.Error: Значение не задано. Вот фрагмент кода, в котором не реализована ветвь else:

Листинг 4

let

a = 6,

Result = if a = 5 then true else ...

in

Result

Когда условие (а = 5) принимает значение false, вызывается «…», что приводит к ошибке. Обратите внимание, ключевое слово error не используется. Оператор многоточия как определяет, так и вызывает ошибку.

Особое поведение

Что именно происходит, когда возникает ошибка? Какое поведение возвращает ошибку, а не значение? Рассмотрим выражение:

В обычных условиях сначала выполняется функция GetValue(). Затем полученное значение передается в someFunction(), которая возвращает финальный результат. Предположим, GetValue() выдает ошибку. Дальнейшее выполнение выражения прекращается. someFunction() не вызывается. Ошибка GetValue() становится итогом выражения. Такое поведение также известно, как повышение. Ошибка передается тому шагу, с которого была вызвана someFunction().

Дальнейшее зависит от того, предусмотрено ли в коде появление ошибки. Если да, запрос продолжит выполнение. Если нет, возникнет ошибка верхнего уровня. Запрос завершит работу и вернет значение ошибки.

Сдерживание ошибок

Если ошибка возникает в выражении, которое что-то определяет (поле записи, ячейку таблицы, переменную в выражении let, …), ошибка содержится в этом чём-то. Последствия ошибки ограничены этим чем-то и логикой, которая пытается получить доступ к значению этого чего-то. Ниже последствия ошибки GetValue содержатся в той части запроса, на которую она повлияла. Ошибка не остановила выполнение запроса. Запрос завершился успешно и вернул запись. Два поля – FieldB и FieldC – вернули ошибку, потому что они являются чем-то, затронутым ошибкой.

Листинг 5

let

GetValue = () => error «Something bad happened!»,

DoSomething = (input) => input + 1,

Result = [

FieldA = 25,

FieldB = DoSomething(GetValue),

FieldC = FieldA + FieldB

]

in

Result

Рис. 3. Результат запроса

Сдерживание ошибок влечет за собой еще одну особенность. Ошибка сохраняется в чём-то, что ее содержит. Пока выполняется запрос, любая попытка получить доступ к значению этого чего-то приводит к повторному возникновению сохраненной ошибки. Когда происходит попытка доступа, логика, которая первоначально вызвала ошибку, не подвергается повторной оценке. Эта логика при повторном обращении могла бы вернуть допустимое значение. Но логика пропускается, и ранее сохраненная ошибка просто вызывается повторно.

Ниже функция GetDataFromWebService() вычисляется один раз, даже если к самим данным обращаются дважды. Если первое обращение вернуло ошибку, второе обращение тоже вернет  ошибку, сохраненную ранее.

let

Data = GetDataFromWebService() // повышенная ошибка

in

{ List.Sum(Data[Amount]), List.Max(Data[TransactionDate]) }

Ошибки верхнего уровня

Если ошибку не удалось сдержать, она передается из выражения в верхний уровень, как результат всего запроса. Далее в среду хоста и выполнение запроса останавливается. В следующем выражении ничто не содержит ошибку, поэтому её нельзя сдержать, и запрос завершается ошибкой:

Листинг 6

let

GetValue= () => error «Something bad happened!»,

SomeFunction = (input) => input + 1

in

SomeFunction(GetValue())

Сдерживание против исключения

Поведение Power Query по сдерживанию ошибок отличает его от большинства языков программирования, основанных на исключениях. В мире исключений ошибка автоматически распространяется вплоть до среды хоста, что приводит к завершению работы программы (если только в коде не будет предусмотрена обработка ошибок). В M ошибка локализуется, пока есть что-то, что ее содержит. Это позволяет успешно завершить запрос, даже если не удалось вычислить отдельные элементы.

Сдерживание ошибок – отличное поведение, учитывая цель использования M: обработка данных. Предположим, что выражение, определяющее значение столбца таблицы, содержит ошибку для одной ячейки из всей таблицы. В мире, основанном на исключениях, эта ошибка может привести к завершению всей обработки. В мире M ошибка просто влияет на эту единственную ячейку и любой код, который обращается к этой ячейке. Обработка продолжается, и будет получен результат.

На самом деле, из-за лени M, если к ячейке с ошибкой не будет обращений, то ошибка и не возникнет.

Листинг 7

let

Data = #table({«Col1»}, {{«SomeValue»}, { error «bad» }})

in

Table.RowCount(Data) // возвращает 2

Хотя одна ячейка и содержит ошибку, запрошенные данные (количество строк), не требуют вычисления значения ошибочной ячейки, поэтому выражение вернет значение 2.

Хотя сдерживание ошибок – отличное поведение по умолчанию, что, если оно не соответствует вашим потребностям? В частности, что делать с таблицами, если важно различать строки с ошибками и строки без ошибок? Возможно, вы не обращаетесь к содержимому строки напрямую, поэтому не делаете ничего, что могло бы вызвать распространение ошибок, но все же хотите знать, в каких строках есть ошибка, а в каких нет. Функции Table.SelectRowsWithErrors и Table.RemoveRowsWithErrors, то, что вам нужно.

Листинг 8

let

Data = #table({«Col1»}, {{«SomeValue»}, { error «bad» }})

in

[

RowsWithErrors = Table.RowCount(Table.SelectRowsWithErrors(Data)),

RowsWithoutErrors = Table.RowCount(Table.RemoveRowsWithErrors(Data))

]

Рис. 4. Список, содержащий количество строк с ошибками и без

Обработка ошибок

Понимая, какие операции способны вызывать ошибку, вы можете использовать ключевое слово try, чтобы проверить, не возвращает ли выражение ошибку. try используется в двух вариантах…

try ExpressionToTry otherwise FallbackExpression

… первый, try with otherwise, пытается выполнить ExpressionToTry. Если это выражение возвращает значение, всё Ok, переходим к следующему шагу запроса. Когда выражение выдает ошибку, вычисляется выражение otherwise и возвращается его значение.

try Number.FromText(input) otherwise 0

Если Number.FromText возвращает значение, оно и будет результатом выражения. Когда Number.FromText выдает ошибку, try обращается к части otherwise, и возвращает 0. Другими словами, если входные данные могут быть преобразованы в число, возвращается это число; в противном случае возвращается значение по умолчанию – 0.

Имейте в виду, что ошибки будут обработаны только в выражении, расположенном непосредственно справа от try. Если ошибку возвращает выражение otherwise, эта ошибка не будет обработана предшествующим try. Но… поскольку otherwise само по себе является выражением, try можно поместить внутрь него, чтобы обработать ошибку, вызванную otherwise.

try GetFromPrimary()

otherwise try GetFromSecondary()

otherwise «Возникли проблемы с обоими серверами. Возьми отгул на остаток дня :)»

Проблема с конструкцией try with otherwise в том, что она неразборчива: любая ошибка возвращает альтернативное значение. Иногда последующие действия зависят от типа ошибки. Для этих ситуаций подойдет второй вариант – простое выражение try.

Эта форма всегда возвращает запись. Если выражение завершилось успешно, эта запись имеет вид:

[

HasError = false,

Value = (значение выражения ExpressionToTry)

]

Если выражение вызвало ошибку, возвращаемая запись выглядит следующим образом:

[

HasError = true,

Error = (запись, описывающая возникшую ошибку)

]

Например:

Листинг 9

let

DoSomething = () => 45,

Result = try DoSomething()

in

Result // [HasError = false, Value = 45]

Рис. 5. Запись, возвращаемая try, если нет ошибки

Листинг 10

let

DoSomething = () => error «bad»,

Result = try DoSomething()

in

Result // [HasError = true, Error = [Reason = «Expression.Error», Message = «bad», Details = null]

Рис. 6. Запись, возвращаемая try, если есть ошибка

Запись, помещенная в поле Error, содержит ровно три поля: Reason, Message и Details.[3] Это верно, даже если в записи, первоначально использовавшейся для определения ошибки, отсутствовало одно или несколько из этих полей (помните, они необязательны при определении ошибки), или если она включала дополнительные поля.

Запись, возвращаемая try, может быть использована для реализации логики условного исправления. Следующий код обращается к вторичному источнику данных, если первичный выдает ошибку из-за недоступности сервера.

let

Primary = try GetDataFromPrimary(),

Source =

if Primary[HasError] = false then Primary[Value]

    /* если Primary возвращает значение, используй его */

else if Primary[Error][Reason] = «External Source Error»

and Primary[Error][Message] = «Server is unreachable»

    then GetDataFromSecondary()

    /* если ошибка Primary вызвана тем, что его источник недоступен,

            запроси данные с сервера Secondary */

else error Primary[Error]

    /* если Primary вернул иную ошибку, верни её

            в качестве результата запроса */

in

Source

Используя try with otherwise, мы бы запросили Secondary, если Primary выдаст любую ошибку, а не только когда основной сервер недоступен:

try GetDataFromPrimary()

otherwise GetDataFromSecondary()

Масштаб (область действия)

Обработка ошибок должна происходить на уровне, на котором они возникают. Нельзя обработать ошибки, содержащиеся на другом уровне.

let

Data = #table({«Amount»}, {{10}, {error «help!»}, {error «save me!»}})

in

try Data otherwise 0

try – бесполезный оператор в этом запросе. Возможно, разработчик надеялся с помощью try заменить ошибки нулями. Но в этом случае Data возвращает допустимую таблицу. Правда, в ней самой есть ячейки с ошибками, но эти ошибки содержатся на уровне ячеек. Поскольку они не влияют на выражение данных на уровне таблицы, try не дает эффекта.

try будет полезен в следующем случае, но его эффект может быть не таким, как предполагал разработчик.

Листинг 11

let

Data = #table({«Amount»}, {{10}, {error «help!»}, {error «save me!»}})

in

try List.Sum(Data[Amount]) otherwise 0

List.Sum суммирует значения в столбце [Amount] таблицы Data. Если выражение, определяющее значение элемента, вызывает ошибку, она повышается. List.Sum прекращает суммирование и возвращает ошибку. try обрабатывает эту ошибку, возвращая 0 вместо суммы элементов списка. Скорее всего, цель у разработчика была иная. Он хотел заменить элементы с ошибками на 0, и суммировать числовые значения. Необходимо применить try так, чтобы обработка ошибок велась на уровне ячеек таблицы. Кажется, что можно сделать так:

Table.TransformColumns(Data, (input) => try input otherwise 0)

Однако, эта логика не улавливает ошибки, вызванные выражениями значений ячеек. Дело в том, что аргументы вычисляются до того, как их значения будут переданы в функцию. Если оценка приводит к ошибке, функция не вызывается. Вместо этого ошибка передается шагу, который вызвал функцию. В нашем случае, если выражение значения столбца выдает ошибку, функция преобразования (input) => … не вызывается, поэтому try не может обработать ошибку. Вместо этого ошибка передается обратно в Table.TransformColumns.

Проблема заключается в том, что выражение значения ячейки должно быть вычислено внутри try. Чтобы добиться этого, надо вернуться на уровень строки, и использовать функцию, которая получает строку. Затем внутри функции использовать ссылку на значение столбца строки и вот его подставить в try. Лишь тогда try сможет обработать ошибку. Чтобы реализовать это, нужно создать новый столбец, значения которого формировать путем проверки try. Затем можно удалить исходный столбец, а новому столбцу дать старое имя.

Листинг 12

let

Data = #table({«Amount»}, {{10}, {error «help!»}, {error «save me!»}}),

ErrorsReplacedWithZero = Table.AddColumn(

Data,

«NewAmount»,

(row) => try row[Amount] otherwise 0

),

RemoveOldAmount = Table.RemoveColumns(ErrorsReplacedWithZero, {«Amount»}),

RenameNewAmount = Table.RenameColumns(RemoveOldAmount, {«NewAmount», «Amount»})

in

List.Sum(RenameNewAmount[Amount]) // возвращает 10

Это довольно сложно. Но пример хорошо иллюстрирует общий подход к использованию try на уровне ячеек. Если же, как в нашем пример, вы просто хотите заменить любую ошибку значением по умолчанию, используйте Table.ReplaceErrorValues.

Листинг 13

let

Data = #table({«Amount»}, {{10}, {error «help!»}, {error «save me!»}}),

ErrorsReplacedWithZero = Table.ReplaceErrorValues(

Data,

{{«Amount», 0}}

) // заменяет ошибки в столбце Amount нулями

in

List.Sum(ErrorsReplacedWithZero[Amount]) // возвращает 10

Применить try к элементам списка сложнее. Для списков нет функции List.ReplaceErrorValues. Самым простым решением может быть преобразование списка в таблицу, обработка ошибки, а затем обратное преобразование таблицы в список.

Листинг 14

let

Data = {10, error «help!», error «save me!»},

#»Преобразовано в таблицу» = Table.FromValue(Data),

#»Замененные ошибки» = Table.ReplaceErrorValues(#»Преобразовано в таблицу», {{«Value», 0}}),

Value = #»Замененные ошибки»[Value],

#»Вычисленная сумма» = List.Sum(Value)

in

#»Вычисленная сумма»

Рис. 7. Сумма элементов списка, содержащего ошибки

Нарушения правил

Вы можете использовать ошибки, как сигнал о несоответствиях. Допустим, вы обрабатываете CSV-файл, где значения в столбце ItemCode должны начинаться с буквы A. В начале запроса вы проверяете это, заменяя несоответствующие значения ошибками. Последующие этапы обработки, которые обращаются к столбцу, будут предупреждены, если они попытаются работать со значениями, нарушающими правила.

let

Data = GetData(), // for testing use: #table({«ItemCode»}, {{«1»}, {«A2»}})

Validated = Table.TransformColumns(

Data,

{

«ItemCode»,

each if Text.StartsWith(_, «A») then _ else error Error.Record(

      «Invalid Data»,

«ItemCode does not start with expected letter»,

_

)

}

)

in

Validated

Такую проверку полезно применить в базовом запросе, на который будут ссылаться несколько других запросов. Это позволит вам выполнить проверку один раз (вспомните принцип Не повторяйся, Don’t repeat yourself), гарантируя, что пользователи, пытающиеся использовать ошибочные данные, будут предупреждены о наличии аномалий.

Другой вариант – добавить столбец со значениями true и false, в зависимости от того, соблюдается ли правило:

let

Data = GetData(), // for testing use: #table({«ItemCode»}, {{«1»}, {«A2»}})

Validated = Table.AddColumn(

Data,

«ValidItemCode»,

each Text.StartsWith(_[ItemCode], «A»),

type logical

)

in

Validated

В этом примере логика заботится о том, является ли ItemCode допустимым. Если разработчик забудет выполнить проверку, неверные данные могут рассматриваться как действительные. В отличие от этого, подход замены несоответствующих данных ошибками гарантирует, что попытка получить доступ к недопустимому значению, закончится ошибкой. Пользователь будет вынужден поправить данные в источнике. Какой вариант выбрать, зависит от вашего контекста.

В следующей заметке

Я планирую рассказать о том, что остается за кулисами: организации разделов кода и о том, как M предоставляет возможность аннотировать значения дополнительной информацией (метаданными). Однако перед этим обсудим, как работает система типов в Power Query.

[1] Заметка написана на основе статьи Ben Gribaudo. Power Query M Primer (Part 15): Error Handling. Если вы впервые сталкиваетесь с Power Query, рекомендую начать с Марк Мур. Power Query.

[2] Номер листинга соответствует номеру запроса в приложенном Excel файле.

[3] Судя по рис. 6 современная реализация M создает пять полей.

Содержание

  1. SPBDEV Blog
  2. Пример набора данных
  3. Происходит ошибка
  4. Почему Power Query Editor не поймал ошибку?
  5. Работа с ошибками: поиск строк ошибок
  6. Удаление ошибок из загрузки таблицы в Power BI
  7. Храните ошибки в таблице исключений
  8. Получение информации об ошибке
  9. Удалите столбец ошибок
  10. Отчет об исключении
  11. Подведем итоги
  12. Работа с ошибками в Power Query
  13. Ошибка на уровне шага
  14. Распространенные ошибки на уровне шага
  15. Не удается найти источник — DataSource.Error
  16. Столбец таблицы не найден
  17. Другие распространенные ошибки на уровне шага
  18. Ошибка уровня ячейки
  19. Обработка ошибок на уровне ячейки
  20. Удаление ошибок
  21. Замена ошибок
  22. Сохранение ошибок
  23. Распространенные ошибки на уровне ячеек
  24. Ошибки преобразования типов данных
  25. Ошибки операций

SPBDEV Blog

Чтобы создать надежную систему BI, вам необходимо тщательно учитывать и обрабатывать ошибки. Если вы создаете решение для отчетов, обновление которого не выполняется при каждом возникновении ошибки, это не надежная система. Ошибки могут произойти по многим причинам. В этом сообщении мы покажем вам способ поймать возможные ошибки в Power Query и как создать страницу отчета об исключении, чтобы визуализировать строки ошибок для дальнейшего изучения. Метод, о котором вы здесь узнаете, сохранит вашу модель от сбоя во время обновления. Эо означает, что вы обновили набор данных, и вы можете поймать любые строки, вызвавшие ошибку на странице отчета об исключении.

Пример набора данных

Мы будем использовать пример файла Excel в качестве источника данных, который содержит 18 484 строки клиентов. В образце Dataset у нас есть поле BirthDate рядом со всеми другими полями, которые должны иметь в нем значение даты. Вот как выглядят данные, когда мы вводим их в Power Query:

Происходит ошибка

Когда мы получаем этот набор данных в окне редактора Power Query Editor (как показано на приведенном выше снимке экрана), Power Query автоматически преобразует тип данных столбца BirthDate в Date. Вы можете увидеть это автоматическое преобразование типа данных в списке шагов;

Конечно, вы можете отключить автоматическое определение типа данных Power Query, но наша точка зрения отличается. Мы хотим, чтобы набор данных не показывал вам, как с этим бороться. Ошибки происходят в Power Query в реальном мире, и мы хотим показать вам, как их найти.

Как вы можете видеть в редакторе Power Query Editor, мы не видим ошибок для этого типа данных, и все выглядит великолепно;

Теперь мы загружаем этот набор данных в Power BI, используя Close и Apply в окне редактора запросов, и мы ждем, что все загрузится успешно, однако это выходит из-под контроля!

Звучит знакомо? Да, если вы некоторое время работали с Power BI, возможно, вы это испытали. В редакторе Power Query Editor нет ошибок, но когда мы загружаем данные в Power BI, они появляются ! Как это возможно? Давайте сначала узнаем, почему это происходит.

Почему Power Query Editor не поймал ошибку?

Редактор Power Query Editor всегда работает с предварительным просмотром набора данных, размер предварительного просмотра зависит от того, сколько столбцов у вас есть, иногда это 1000 строк, а иногда и 200 строк. Если вы нажмете на Query в окне редактора Power Query, вы можете увидеть это, как показано ниже в строке состояния;

Причина использования Power Query для использования набора данных предварительного просмотра заключается, главным образом, в ускорении процесса разработки трансформации. Представьте, что если у вас есть таблица с 10 миллионами строк, каждое преобразование, которое вы хотите применить к этому набору данных, займет много времени, и вам придется подождать, прежде чем вы начнете делать следующий шаг. Ожидание ответа каждый раз замедляет процесс разработки. Именно по этой причине предпочтительным вариантом является работа над предварительным просмотром в наборе данных. Вы можете применить все преобразования, которые вы хотите в предварительном просмотре, и когда вы им довольны, затем примените его ко всему набору данных. Как правило, первые 1000 строк или первые 200 строк являются хорошим образцом всего набора данных, и вы можете ожидать увидеть большинство проблем с данными. Не всегда, конечно.

Как тогда преобразование будет применено ко всему набору данных? Когда вы загружаете данные в Power BI, а именно — когда вы нажимаете «Close» и «APPLY» в окне Power Query Editor. Этот APPLY означает применить эти преобразования теперь во всем наборе данных. Именно по этой причине процесс загрузки может занять больше времени, особенно если набор данных большой.

Power Query Editor всегда работает с предварительным просмотром данных, чтобы ускорить процесс разработки. Когда вы загружаете данные в Power BI, преобразования будут применяться ко всему набору данных.

Теперь, когда вы знаете, как Power Query Editor имеет дело с предварительным просмотром данных, вы можете догадаться, почему произошла ошибка выше? Причина в том, что предварительный просмотр данных (около 1000 строк) не имел проблем с применяемыми преобразованиями (в этом случае автоматический тип данных изменяется на Date для столбца BirthDate). Однако весь набор данных (около 18 тыс. строк) имеет проблемы с этим преобразованием! Когда вы увидите вышеприведенную ошибку в Power BI Desktop, вы можете нажать View errors и перейти в Power Query editor, посмотреть их, разобраться с ними и исправить. Однако этого недостаточно.

Что делать, если ошибка не возникает в Power BI Desktop, но происходит в запланированном обновлении в службе Power BI?

Это хороший вопрос! Исправить ошибки в Power BI Desktop легко, но учтите, что ошибка также не произошла в Desktop, и вы опубликовали отчет Power BI на веб-сайт и запланировали его обновление. Затем на следующий день вы увидите, что отчет не обновился с ошибкой! Вы должны научиться правильно обращаться к строкам ошибок до того, как это приведет к сбою запланированного обновления. Давайте посмотрим, как с этим справиться.

Работа с ошибками: поиск строк ошибок

Чтобы справиться с ошибками, вы должны поймать ошибку до того, как она загрузится в Power BI. Один из способов сделать это — создать две ссылки одной и той же таблицы, одну в качестве окончательного запроса, а другую — как строки ошибок.

На скриншоте выше, мы переименовали таблицу DimCustomer в DimCustomer — Original, а затем создали ссылку из нее. Если вы хотите узнать, что такое Reference, прочитайте статью о Reference и Duplicate здесь . Новый запрошенный запрос можно назвать DimCustomer. Это будет чистый запрос без ошибок (мы удалим ошибки из него на следующем шаге);

Новая таблица — это таблица, которая будет чистой, без ошибок, и мы можем использовать ее в отчете. Давайте очистим это от любых ошибок

Удаление ошибок из загрузки таблицы в Power BI

Поскольку DimCustomer станет для нас окончательным запросом, я хочу удалить из него ошибки. Удаление ошибок — это простой вариант на вкладке «Главная» в разделе Reduce Rows -> Remove Rows -> Remove Errors.. Перед этим выберите столбец BirthDate.

Вы также можете сделать это для всех столбцов, если хотите; выбрав все столбцы, а затем выбрав «Remove Errors». Это сообщение — всего лишь образец одного столбца и может быть продлен до конца.

Remove Errors — это шаг на этапе преобразования данных, а это означает, что при нажатии APPLY он будет применяться ко всему набору данных, поэтому в результате, когда изменение типа данных приведет к ошибке, следующий шаг после этого — Remove Errors, уничтожит строки, вызвавшие ошибку. Но DimCustomer — Original все еще может вызвать ошибку, поэтому мы должны снять галочку Enable Load с этого запроса.

Теперь мы успешно удалили ошибки и загрузили данные в Power BI. Ошибок не будет.

Но подождите! Как насчет этих строк ошибок? Как мы можем их поймать? Нам нужно поймать эти строки и выяснить, что произошло, и подумать о плане действий, чтобы исправить их, не так ли? Таким образом, нам нужна другая ссылка запроса из исходного запроса, но для сохранения строк ошибок.

Храните ошибки в таблице исключений

Аналогично опции «Remove Errors» есть опция «Keep Errors». Если вы уже видели этот вариант, возможно, вам интересно, как его использовать? Вот точный сценарий использования. Keep Errors поможет уловить строки ошибок в таблице исключений.

Создайте еще одну ссылку из DimCustomer — Original.

Переименуйте этот новый запрос как строки ошибок DimCustomer. Для этого запроса нам нужно сохранить ошибки, которые можно найти рядом с ошибками удаления, но в разделе Keep Rows.

Теперь эта таблица будет содержать строки, которые вызывают ошибку. Вот пример набора;

Это еще не конец истории. Если вы загрузите эту новую таблицу DimCustomer — строки ошибок в Power BI, вы снова получите ту же ошибку. Зачем? ну, потому что этот запрос, безусловно, собирается возвращать строки ошибок! Вам необходимо удалить ошибку из этого набора данных.

Получение информации об ошибке

Если вы удалите столбец ошибок из таблицы исключений, которые мы создали, то у вас не будет никаких подробностей о произошедшей ошибке, и было бы трудно отследить ее и устранить неполадки. Лучше всего поймать детали ошибки. Сообщение об ошибке и значение, вызвавшее ошибку, являются важными деталями, которые вы не хотите пропустить. Выполните следующие шаги, чтобы получить эту информацию.

В таблице Error Rows добавьте Custom Column.

В редакторе Custom Column напишите «try», а затем пробел, имя поля, вызвавшего ошибку. В нашем примере: BirthDate;

try (все строчные буквы), это ключевое слово в M, которое будет ловить данные об ошибке. Вместо того, чтобы возвращать только ошибку, она вернет запись, содержащую данные об ошибках, такие как исходное значение и сообщение об ошибке. Ниже, снимок экрана показывает, как будет выводиться результат попытки;

Выход записи «try» будет иметь два поля; HasError (мы уже знаем, что это будет правда) и Error. Ошибка — это еще одна запись с более подробной информацией. Нажмите «Expand » в столбце «Custom column» и выберите «Error».

В столбце вывода с именем «Error» снова нажмите на «Expand» и на этот раз выберите все столбцы;

Хорошо иметь исходное имя столбца в качестве префикса, потому что тогда вы бы знали, что это столбцы с подробными сведениями об ошибках.

Теперь вы получите полную информацию об ошибке, как показано ниже;

Вышеупомянутая информация является вашим самым ценным активом для отчетности об исключениях.

Удалите столбец ошибок

Теперь последний шаг перед загрузкой данных в Power BI — удалить столбец, который вызывает ошибку. В нашем примере; Столбец BirthDate должен быть удален (в противном случае обновление снова завершится неудачей);

Отчет об исключении

Теперь вы можете загрузить данные в Power BI. У вас будет две таблицы; DimCustomer и DimCustomer – Error Rows. DimCustomer — это таблица, которую вы можете использовать для обычной отчетности. DimCustomer – Error Rows — это таблица, которую вы можете использовать для отчетов об исключениях. Отчет об исключении — это отчет, который можно использовать для устранения неполадок, и перечисляет все ошибки для дальнейшего расследования. Убедитесь, что между этими двумя таблицами нет никакой связи.

Вот созданный нами образец визуального отчета, который показывает ошибки:

Подведем итоги

Ошибки случаются, и вам приходится иметь дело с ними. Вместо того, чтобы ждать ошибки, а затем находить их лишь через месяц после появления, лучше выявлять их, как только они произойдут. В этой статье вы узнали способ обработки строк ошибок.

Источник

Работа с ошибками в Power Query

В Power Query можно столкнуться с двумя типами ошибок:

  • Ошибки на уровне шага
  • Ошибки на уровне ячеек

В этой статье приводятся рекомендации по устранению наиболее распространенных ошибок, которые можно найти на каждом уровне, а также описывает причину ошибки, сообщение об ошибке и подробные сведения об ошибке для каждого из них.

Ошибка на уровне шага

Пошаговая ошибка предотвращает загрузку запроса и отображает компоненты ошибок на желтой панели.

  • Причина ошибки: первый раздел перед двоеточием. В приведенном выше примере причина ошибки — Expression.Error.
  • Сообщение об ошибке: раздел непосредственно после причины. В приведенном выше примере сообщение об ошибке — столбец «Столбец» таблицы не найден.
  • Сведения об ошибке: раздел непосредственно после строки Details: В приведенном выше примере сведения об ошибке — «Столбец«.

Распространенные ошибки на уровне шага

Во всех случаях рекомендуется внимательно ознакомиться с причиной ошибки, сообщением об ошибке и подробными сведениями об ошибке, чтобы понять, что вызывает ошибку. Вы можете нажать кнопку «Перейти к ошибке» , если она доступна, чтобы просмотреть первый шаг, в котором произошла ошибка.

Не удается найти источник — DataSource.Error

Эта ошибка обычно возникает, когда источник данных недоступен пользователем, у пользователя нет правильных учетных данных для доступа к источнику данных или источник был перемещен в другое место.

Пример. У вас есть запрос из текстовой плитки, которая была расположена на диске D и создана пользователем A. Пользователь A предоставляет общий доступ к запросу пользователю B, у которого нет доступа к диску D. Когда этот пользователь пытается выполнить запрос, он получает dataSource.Error , так как в своей среде нет диска D.

Возможные решения. Вы можете изменить путь к файлу текстового файла на путь, к которому у обоих пользователей есть доступ. Как пользователь Б, вы можете изменить путь к файлу, чтобы он был локальной копией того же текстового файла. Если кнопка «Изменить параметры» доступна в области ошибок, ее можно выбрать и изменить путь к файлу.

Столбец таблицы не найден

Эта ошибка обычно активируется, когда шаг создает прямую ссылку на имя столбца, которое не существует в запросе.

Пример. У вас есть запрос из текстового файла, в котором одно из имен столбцов — Column. В запросе есть шаг, который переименовывает этот столбец в date. Но в исходном текстовом файле произошло изменение, и у него больше нет заголовка столбца с именем Column , так как он был изменен вручную на Date. Power Query не удается найти заголовок столбца с именем Column, поэтому он не может переименовать столбцы. Отображается ошибка, показанная на следующем рисунке.

Возможные решения: существует несколько решений для этого случая, но все они зависят от того, что вы хотите сделать. В этом примере, так как правильный заголовок столбца Date уже поступает из текстового файла, можно просто удалить шаг, который переименовывает столбец. Это позволит выполнять запрос без этой ошибки.

Другие распространенные ошибки на уровне шага

При объединении или объединении данных между несколькими источниками данных может возникнуть ошибка Formula.Firewall , например, показанная на следующем рисунке.

Эта ошибка может быть вызвана рядом причин, таких как уровни конфиденциальности данных между источниками данных или способом объединения или объединения этих источников данных. Дополнительные сведения о диагностике этой проблемы см. в брандмауэре конфиденциальности данных.

Ошибка уровня ячейки

Ошибка на уровне ячейки не препятствует загрузке запроса, но отображает значения ошибок в ячейке. При выборе пробела в ячейке отображается область ошибок под предварительным просмотром данных.

Средства профилирования данных помогают более легко выявлять ошибки на уровне ячеек с помощью функции качества столбца. Дополнительные сведения: средства профилирования данных

Обработка ошибок на уровне ячейки

При возникновении ошибок на уровне ячеек Power Query предоставляет набор функций для их обработки путем удаления, замены или сохранения ошибок.

В следующих разделах указанные примеры будут использовать тот же пример запроса, что и начальная точка. В этом запросе есть столбец Sales с одной ячейкой с ошибкой, вызванной ошибкой преобразования. Значение внутри этой ячейки было NA, но при преобразовании этого столбца в целое число Power Query не удалось преобразовать НС в число, поэтому отображается следующая ошибка.

Удаление ошибок

Чтобы удалить строки с ошибками в Power Query, сначала выберите столбец, содержащий ошибки. На вкладке «Главная» в группе «Уменьшить строки» выберите «Удалить строки«. В раскрывающемся меню выберите «Удалить ошибки«.

Результат этой операции даст вам таблицу, которую вы ищете.

Замена ошибок

Если вместо удаления строк с ошибками необходимо заменить ошибки фиксированным значением, это также можно сделать. Чтобы заменить строки с ошибками, сначала выберите столбец, содержащий ошибки. На вкладке «Преобразование» в группе «Любой столбец » выберите «Заменить значения«. В раскрывающемся меню выберите «Заменить ошибки«.

В диалоговом окне «Замена ошибок » введите значение 10 , так как вы хотите заменить все ошибки значением 10.

Результат этой операции даст вам таблицу, которую вы ищете.

Сохранение ошибок

Power Query может служить хорошим средством аудита для выявления строк с ошибками, даже если вы не исправите ошибки. Здесь могут быть полезны ошибки keep . Чтобы сохранить строки с ошибками, сначала выберите столбец, содержащий ошибки. На вкладке «Главная» в группе «Уменьшить строки» выберите «Сохранить строки«. В раскрывающемся меню выберите «Сохранить ошибки«.

Результат этой операции даст вам таблицу, которую вы ищете.

Распространенные ошибки на уровне ячеек

Как и в случае с любой ошибкой на уровне шага, мы рекомендуем внимательно изучить причины ошибок, сообщения об ошибках и сведения об ошибках, предоставленные на уровне ячейки, чтобы понять, что вызывает ошибки. В следующих разделах рассматриваются некоторые наиболее частые ошибки на уровне ячеек в Power Query.

Ошибки преобразования типов данных

Обычно активируется при изменении типа данных столбца в таблице. Некоторые значения, найденные в столбце, не удалось преобразовать в нужный тип данных.

Пример. У вас есть запрос, содержащий столбец с именем Sales. Одна ячейка в этом столбце содержит значение NA в качестве значения ячейки, а остальные имеют целые числа в качестве значений. Вы решили преобразовать тип данных столбца из текста в целое число, но ячейка со значением NA приводит к ошибке.

Возможные решения. После идентификации строки с ошибкой можно либо изменить источник данных, чтобы отразить правильное значение, а не NA, либо применить операцию «Заменить» , чтобы указать значение для любых значений NA , вызывающих ошибку.

Ошибки операций

При попытке применить операцию, которая не поддерживается, например умножение текстового значения на числовое значение, возникает ошибка.

Пример. Вы хотите создать настраиваемый столбец для запроса, создав текстовую строку, содержащую фразу «Total Sales: » сцеплено со значением из столбца Sales . Ошибка возникает из-за того, что операция объединения поддерживает только текстовые столбцы, а не числовые.

Возможные решения. Перед созданием этого настраиваемого столбца измените тип данных столбца Sales на текст.

Источник

As any other programming language, Power Query handles errors in its own unique way and the goal of this blog post is to give you a few hints on how to audit the errors or warnings that Power Query might throw your way.

Types of Errors

Power Query primarily handles 2 types or categories of errors:

  • Step level Errors – it’s main symptom is that you query simply will not load giving you a message similar to the one below

image

  • Value Level Errors – query will load, but will have a warning saying that it loaded with errors and give you a hyperlink to see what errors it had when loading. For example, you could click on the “1 error” hyperlink shown in the image below and Power Query will create a new query with only the rows that have errors so you can audit those rows specifically.

image

Ways to Audit Errors

The best way to audit the errors is to go into the Power Query editor window (fka Query Editor window) and go through the steps and values to read the error messages.

For both categories or types of errors, it is extremely important to understand the Error Message which provides a path (exactly where it happened, usually the first sentence in the error message) and checking the Error Reason (exactly why it happened, usually in the details section of the error message).

An example of a Step level error with its Error message is shown in the next image:

image

In some cases Power Query even gives us this “Go To Error” button so we can go to the first step where we hit the error so we can fix the issue. If Power Query doesn’t give you that button, or it doesn’t get you to the first step where you error was raised then it is helpful to navigate through the steps to find out where the error first appeared.

For Value Level errors the hyperlink to the errors is an invaluable help. Clicking that hyperlink will make Power Query automatically create another query, usually with the Format “Errors in [Name of Original Query]”, with only the rows that had errors in your original query and it’ll also add an Index Column (called Row Number) to tell you exactly in what row the error happened. You can click in the whitespace next to the value errors to see the Error Message in the Cell Preview pane as shown below.

SNAGHTMLa3e47b

One thing to mention is that you could’ve manually gone through your original query, select the fields that you want to audit and select the option called “Keep Errors” so you can only see the errors found in those specific fields/columns:

SNAGHTMLa93f74

The Most Common Errors in Power Query

From my experience over the years, there are only a handful of errors that you’ll encounter in Power Query. There are so few that I created the next list of the most common errors that might come across when working with Power Query.

Most Common Step Level Errors

  1. A Data Source function Error – usually caused by Power Query not having the right credentials or unable to connect to the data source (wrong file path or server name in most cases). Example: A query is being pointed to a filepath that no longer exists and, since Power Query can’t find it or connect to it, it displays a DataSource Error as shown below

SNAGHTML93f12b

  1. Missing Columns Errors – usually caused when a step is referencing a column that no longer exists. Example: The report was doing a fill down operation over a column that was named “Employee”, but suddenly the files had a change so that column would have the name “Full Name” instead. This discrepancy gives us the errors below

SNAGHTML959805

Most Common Value Level Errors

  1. Conversion Errors – converting a text that isn’t a date to a date data type can bring an error. When a value can not be converted to the desired data type, its output will be an error as shown below (Power Query can’t convert the text string ‘——‘ to a date)

image

  1. Operation Errors – when a operation or a function requires a specific data type for a value, but we pass a completely different data type, then its output will be an error value. Example:  in the next image you’ll see that I try multiplying a column that has a text value “1” against a column that has a numeric value 1. Since the Column1 is set to text, that is not the number 1, but just a text “1”, so that operation yields an error and the Details tells us that the operator (*) can’t be applied to it. Similar to this situation, you can find others with functions that only accept certain data types and we try to pass a completely different data type that causes errors.

image

To learn more cool techniques and more advanced scenarios with the M language, go ahead and enroll to the FREE trial of the Power Query Academy where I talk more in detail about these type of techniques.

Power Query MЯзык, использованиеerrorУказывает на ненормальную ошибку при обработке выражения вычисления.

MИсключения в языке обычно возникают из-за того, что операторы и функции сталкиваются с ошибками или используют неверные выражения.

1. Распространенные ошибки Power Query

(1) Функция ввела неверный параметр: Expression.Error: невозможно преобразовать значение XXX в тип XXX.

Функция Number.ToText реализует функцию преобразования числового типа в текстовый. Входной параметр должен быть числовым, но входным параметром в следующем примере является текст, что вызывает ошибку.

let
         result = Number.ToText ("Текст")
in
    result

(2) Ошибка типа выражения: Expression.Error: невозможно применить оператор XXX к типам XXX и XXX.

Выражение + используется для сложения чисел, но следующий пример используется для добавления текста, вызывающего ошибку.

let
    результат = 1+ "текст"
in
    result

(3) Имя не может быть распознано (регистр и орфографические ошибки): Expression.Error: Имя XXX не может быть распознано

По сравнению с именем функции в Common Errors (1) имя функции number.totext введено неправильно в зависимости от регистра, что приводит к ошибкам.

let
         result = number.totext ("текст")
in
    result

(4) Ошибка преобразования данных: DataFormat.Error: невозможно преобразовать в XXX

Столбец суммы продаж преобразован в числовой тип, но он содержит текстовые данные, что вызывает ошибку.

let
         Source = Excel.CurrentWorkbook () {[Name = "  2"]} [Содержание],
         Тип изменения = Table.TransformColumnTypes (источник, {{"сумма продаж", номер типа}})
in
         Тип изменения

2. Обработка исключений на языке M (Ошибка)

можно использоватьtryВыражения для тестирования, анализа и обработки исключений ошибок.При возникновении ошибкиtryВ выражении можно указать значение, которое может использоваться для указания причины ошибки.

1TryСтруктура выражения:

tryResult = try Заявления, которые могут быть ненормальными otherwise Значение результата, когда произошла ошибка

2tryРезультат, возвращаемый выражением

Когда ошибка не возникла

TryВернуть записьrecordС полямиHasErrorValue

из ихHasErrorЦенностьFALSEValueДа»Заявления, которые могут быть ненормальными«Результат расчета

Когда возникает ошибка

потому каксчитать1”Столбец не существует, ошибка вычисления выражения.

TryВернуть записьrecordС полямиHasErrorError

из ихHasErrorЦенностьTRUEErrorЭто рекордrecord

РазвернутьError, Вы увидите подробную запись сообщения об ошибке, включая поляReasonMessageDetail

из ихMessageВ поле указана неверная информация (она уже запрошена на китайском, как правило, более понятная)

3) СловосочетаниеotherwiseВремя,tryРезультат, возвращаемый выражением

Когда ошибка не возникла

Возвращается результат вычисления «утверждения, которое может быть ненормальным».

Без совпаденияotherwiseизtryПо сравнению с оператором, нет необходимости передавать возвращаемый результатValueПрочтите поле еще раз. Выражение предложения проще и компактнее.

Когда возникает ошибка

потому каксчитать1”Столбец не существует, ошибка вычисления выражения.

Результат расчета возвращенotherwiseПосле значения.

три,использоватьtryИсключение обработки выражения

(1) Повышение отказоустойчивости кода

После возникновения исключения выполнение программы будет прервано в месте исключения, и следующий код не будет выполнен. Следовательно, хороший код должен использовать механизмы обработки исключений, чтобы повысить надежность и справиться с непредсказуемыми условиями.

В Power Query с помощью приведенных выше выражений try исключения могут создаваться и обрабатываться.

(2) Пользовательское исключение выброса

В соответствии с фактическим использованием вы можете настроить генерируемую информацию об исключении, просто используйте ошибку и формат записи.

let
         результат = (если (попробуйте 1+ "текст") [HasError]
                                         затем ошибка [Reason = "Ошибка вычисления",
                                                                 Message = "Ошибка операции сложения",
                                                                 Detail = "Можно только складывать числа"]
                    else 1+1)
in
    result

Skip to content

One of the great features of Power Query is the way you can view any rows that contain error values when you load data. However, even if you can see the rows that have errors you can’t see the error messages easily – without writing a little bit of M code, which I’ll show you in this post.

Imagine you have the following table of data:

image

…and you load it into Power Query using the following query, which sets the data type for the Sales column to be Whole Number:

let
    Source = Excel.CurrentWorkbook(){[Name="Sales"]}[Content],
    #"Changed Type" = Table.TransformColumnTypes(
                                      Source,
                                     {{"Sales", Int64.Type}, 
                                      {"Product", type text}})
in
    #"Changed Type"

As you’d expect, the last two rows contain error values as a result of this type conversion:

image

You can also see the number of rows that contain errors when you load the query:

image

Clicking on the “2 errors” link in the screenshot above creates a new query that only contains the rows with errors:

image

You can click on the Error link in any cell that contains one to see the error message:

image

But what you really want is to see the error message for each row. To do this add a new custom column with the following definition:

try [Sales]

image

You will then see a new column called Custom containing a value of type Record. You can then click the Expand icon in the column header (highlighted) and then OK:

image

You’ll then see another column called Custom.Error with an Expand icon; click on it and then click OK again.

image

image

And at last you’ll have two columns that show the error messages for each row:

image

My name is Chris Webb, and I work on the Power BI CAT team at Microsoft. I blog about Power BI, Power Query, SQL Server Analysis Services, Azure Analysis Services and Excel.
View all posts by Chris Webb

In Excel we can use IFERROR to if our calculation results in an error, and we can then tell Excel to produce a different result, instead of the error.

Power Query doesn’t have IFERROR but it does have a way of checking for errors and replacing that error with a default answer, it’s called try otherwise

In this post I’ll show you how to use try otherwise to handle errors when loading data, how to handle errors in your transformations and how to handle errors when your query can’t locate a data source.

Watch the Video

Subscribe YouTube

Download Sample Excel Workbook

Enter your email address below to download the sample workbook.

By submitting your email address you agree that we can email you our Excel newsletter.

First up, let’s load data from this table.

sample data

I’ve already generated a couple of errors in this table, and of course I can obviously see them and I could fix them before loading into Power Query.

But when using Power Query this isn’t always the situation. Your query will be loading data without knowing what it is so how would it handle these errors?

Let’s load the data into Power Query and call it Errors from Sheet

errors in sheet

Straight away you can see the errors in the column.

Now of course you could use Remove Errors but that would remove the rows with the errors and that’s not what I want.

remove errors

Or I could use Replace Errors, but this doesn’t give me any idea what the cause of the error is.

replace errors

I want to see what caused the error and to do this I’ll add a Custom Column and use try [End]

try end

This creates a new column with a Record in each row

column of records

In this record are two fields. HasError states whether or not there’s an error in the [End] column

error record

If there is an Error then the 2nd field is another record containing information about that error

If there isn’t an error, then the 2nd field is the value from the [End] column

record with no error

If I expand the new column I get 3 new columns containing the HasError value which is boolean, and either an Error or a Value

expanding record column

Checking what’s in the Error Records, you can see the Reason for the error, DataFormat.Error, this is from Power Query

examining error record

There’s the Message, which is the error from the Excel sheet, and some errors give extra Detail, but not in this case.

If I expand this Error column I can see all of these fields.

expanded error column

I’ve ended up with a lot of extra columns here and it’s a bit messy so let’s tidy it up. In fact I’ll duplicate the query and show you another way to get the same information in a neater way

The new query is called Errors from Sheet (Compact) and I’ve deleted all steps except the first two.

compact query

What I want to do is , check for an error in the Try_End column, and if there is one I want to see the error message from Excel.

If there isn’t an error I want the value from the [End] column.

I can do all of this in a new column using an if then else

Add a new Custom Column called Error or Value and enter this code

try if then else

What this is saying is:

  • If the boolean value [HasError] in the [Try_End] column is true then
  • return the [Message] in the [Error] record of the [Try_End] column
  • else return the [Value] from the [Try_End] column

With that written I can remove both the End and Try_End columns so the final table looks like this

try if then else result

Checking for Errors and Replacing Them With Default Values

In this scenario I don’t care what the error is or what caused it, I just want to make sure my calculations don’t fail.

I duplicate the original query again, calling this one Error in Calculation, and remove every step except the Source step

I add a new Custom column called Result and what I’ll do here is divide [Start] by [End]

error dividing

this gives me an error as I know it will in rows 1 and 3

errors in calc column

so to avoid this, edit the step and use try .. otherwise

try otherwise to replace errors

now the errors are replaced with 0.

errors fixed

Errors Loading Data from A Data Source

I’ll create a new query and load from an Excel workbook

new query from workbook

Navigating to the file I want I load it

loading workbook

and loading this table

loading table from workboiok

table loaded to power query

I’m not going to do any transformations because I just want to show you how to deal with errors finding this source file.

I’ll open the Advanced Editor (Home -> Advanced Editor) and change the path, so that I know I’ll get an error. Here I change the drive letter to X.

I don’t have an X: drive so I know this will cause the workbook loading to fail.

change path to file

error loading file

So that’s what happens when the file can’t be found so let’s say I have a backup or alternate file that I want to load if my main file can’t be found.

Open the Advanced Editor again and then use try otherwise to specify the backup file’s location

try otherwise backup file

close the editor and now my backup file is loaded.

backup file loaded

0 0 голоса
Рейтинг статьи
Подписаться
Уведомить о
guest

0 комментариев
Старые
Новые Популярные
Межтекстовые Отзывы
Посмотреть все комментарии

А вот еще интересные материалы:

  • Яшка сломя голову остановился исправьте ошибки
  • Ясность цели позволяет целеустремленно добиваться намеченного исправьте ошибки
  • Ясность цели позволяет целеустремленно добиваться намеченного где ошибка
  • Power query ошибка переполнения
  • Power query ошибка загрузки