Такова жизнь. Но нам не вчера

Коллеги, подскажите, пожалуйста. Есть задача объединить 5 списков, живущих в Sharepoint Online, в один, а потом его выгружать в Excel. Решил сделать через Power Query. Объединение простое, все 5 списков поочередно присоединяю друг к другу: сначала первые два, потом к ним третий и т.д. Столкнулся с проблемой, что это очень долго происходит. Каждое объединение занимает по паре часов, а то и больше. Самый большой список 3400 строк, и 17 столбцов, остальные меньше. В чем может быть проблема? Я никак не могу понять, то ли у меня компьютер слабоват, то ли дело в PowerBI? Спасибо!

имею в виду, что вдруг такая работа для PowerBI - норма, а я этого не знаю

Это что-то странное

Тем более в pq раз

более того, каждая операция в PQ тоже может висеть очень долго, делаю все в PowerBI Desktop, единственное, что вижу, что жесткий диск у ноута при работе PBI занят всегда на 100%

может это так влиять?

Зачем поочередно? У вас количество запросов к шарику  начинает расти необоснованно. Получите все 5 списков и потом одним запросом объединяйте.
Во-вторых, в десктопе включите "Игнорировать уровни конфиденциальности".
В-третьих, шариковые списки конечно не самый быстрый источник, но вы точно просто объединяете списки, ничего больше с ними при этом не делаете?

А одним запросом это как, не подскажете? Что-то никак не уловлю, как это сделать.
Второй пункт-ок, включу.
Третий пункт: еще удаляю ненужные столбцы и несколько переименований делаю.

С начала попробуйте загрузить несколько табличек без объединения, если загрузятся быстро то это значит что источник отдаёт хорошо, и канал связи Вас тоже не подводит! :)
После попробуйте поиграйтья с функцией table.buffer.
Попробую описать логику работы:
есть запрос А и на его основании сделан запрос B, так вот когда идёт обновление всех запросов сначала обновляется запрос А, после начинает обновляться запрос B и на этом этапе он автоматически заставляет повторно обновится запросу А, то есть запрос А обновляется два раза.
table.buffer - запрещает повторно обновляться запросу А и выгружает все данные во временный буфер который находится в оперативной памяти, естественно если у Вас мало будет оперативной памяти - то это будет затормаживать, если много то проблемы не будет.
В общем логику и вектор движения рассказал, я бы двигался в эту сторону!:)
Может быть где-то не точности, но тогда меня поправят участники группы.

Коллеги, всем добрый вечер!

Подскажите, пожалуйста, можно ли передать каким-то образом в визуализацию карты для поля широта/долгота меру. Не столбец, не вычисляемый столбец, а меру. И каким образом она должна быть оформлена для этого? Какие формулы можно использовать в такой мере?

широта и долгота - это десятичные градусы, сделайте две меры с десятичными градусами, например широта = 24,35 и долгота = 45,6 и попробуйте поместить на карту, если увидите точку - Значит можно меры долготы и широты передавать !!! :)

То есть, в моем случае весь "компот" из 5 поочередно соединенных списков обновляется очень много раз, получается?

теоретически да, но для того, чтобы назначить мерам категории "Долгота" и "Широта", меры должны быть текстовые. И обычная карта не позволяет ставить меры в эти поля

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

если списки однотипные, и загружены в 5 разных запросов, то тогда потом эти запросы в один сводим при помощи Append queries (Добавить запросы)

Спасибо! Проверю сначала, как загружаются списки по отдельности

Стоп, добавление запросов же добавляет строки? Мне нужно добавить столбцы, то есть, списки не однотипные все таки. У меня в первом списке заявки, а к ним нужно остальные данные добавлять из других списков

А кто знает, с помощью чего  можно посмотреть количество обращений к файлу и какой трафик идёт в PQ при выполнении запроса? :)

тогда, раз списки небольшие, в буфер их перед слиянием, как советовал Анатолий