Поиск  Пользователи  Правила  Войти
Форумы "Планета Excel" » Вопросы по Microsoft Excel
Страницы: 1
RSS
PQ: Странное поведение Refresh all DataFormat.Error: File contains corrupted data
 
#1
30.06.2018 19:25:36
Привет
Подскажите пожалуйста, странное поведение при нажатии на Refresh data вылетает вот такая ошибка

И один из connection ов становиться с ошибкой

При этом если сразу же после ошибки нажать Refresh около этого connection а то все проходит идеально

Я не смогу выложить пример, так как он тянет из десятков мест данные:(
Подскажите, что может быть - в какую сторону покопать? Благодарю!  
 
 
 
#2
02.07.2018 13:41:47
Цитата
Vsevolod написал:
тянет из десятков мест данные:(
судя по всему, один из запросов, которые дергают данные из внешнего/или большого локального источника, не успевает обновиться.
Попробуйте обновлять запросы макросомв нужном порядке. Но по сути нужно смотреть внимательно всю цепочку запросов и оптимизировать загрузку
F1 творит чудеса
 
 
 
#3
03.07.2018 06:54:38
Максим Зеленский, благодарю за ответ. Знаете что странное происходит, именно в этой модели один из файлов откуда идет считка почему-то самопроизвольно иногда открывается.
Но я выстроил такую логику загрузки: raw data -> reference подготовка всех данных - а от этого reference уже на несколько разных refference которые подготавливают финальные данные и выводят в таблицу(как раз которые ругаются)
Вот тут вопрос - разве PQ не должен сообразить, что он должен по порядку сделать raw data-> первый reference, а потом уже по финальным reference раздавать данные?
Благодарю.
 
 
 
#4
03.07.2018 09:01:21
Цитата
Vsevolod написал:
Вот тут вопрос - разве PQ не должен сообразить,
Нет, не должен. более менее правильный порядок загрузки формируется если вы используете в качестве источника именно сам запрос, а не таблицу, которую он формирует, а вот если таблицу, то взаимосвязи и очередности не выстраивается.
Вот горшок пустой, он предмет простой...
 
 
 
#5
03.07.2018 10:19:46
Цитата
PooHkrd написал:
если вы используете в качестве источника именно сам запрос, а не таблицу, которую он формирует
вот, совершенно точно подмечено
F1 творит чудеса
 
 
 
#6
03.07.2018 15:55:15
PooHkrd,  я все это делаю в PQ через референсы. Вопрос, когда Вы говорите про "сам запрос" - reference это сам запрос ?
То есть у меня идет так Источник -> Reference -> Reference - который выводит в таблицу результат и этот результат заново не используется.
Вопрос именно в цепочки референсов - PQ должен грамотную последовательность Выстраивать?
Благодарю!  
 
 
 
#7
03.07.2018 15:59:14
Дайте пример. У меня русскоязычный PQ - с  терминологией у нас в вами может быть непонимание.
Достаточно первой строки с источником, к которому подключается запрос, выдающий ошибку при обновлении.
Изменено: PooHkrd - 03.07.2018 16:00:35
Вот горшок пустой, он предмет простой...
 
 
 
#8
03.07.2018 16:09:06
Чтобы я никого не запутывал в терминологии, подскажите плиз правильно ли я именную элементы
Вот это именуется на русском как? Я это называю Connection


Когда я говорю про Reference - это значит, что в Connection в первой строчки прописано
Код
let
    Source = Connection

Как это по русски называется? В английской версии Reference.

Так вот пример той модели сокращенный такой dataRaw например

Код
let
    Source = Считываю из XLSX

Вторым шагом делаю Reference на считанные из XLSX сырые данные и провожу над ними манипуляции например report

Код
let    Source = dataRaw
делаю преобразования
Третим шагом, делаю подготовку для вывода как-раз в Excel
Код
let
source = report
Провожу структурирования столбцов для экспорта(названия, расположения)

Вот вопрос по такой цепочке обработке данных - нормально должен ли PQ очередность выполнения запросов выстроить, или нужно стремиться запихнуть все в один Connection? Я специально разделяю на разные шаги(через reference) чтобы легче было логику поддерживать в будущем. Надеюсь понятно описал, простите если путанно:(

 
 
 
#9
03.07.2018 16:44:41
При таком вызове по идее должен нормально выстраивать.
Разделение на отдельные запросы оно только для удобства пользователя, по факту весь код будет выстроен в единую цепочку преобразований, проанализирован, оптимизирован и только потом выполнен.
При этом если один источник вызван несколько раз в разных местах, то экселевский PQ крайне коряво это дело кэширует и обрабатывает. Лично я когда вытягиваю данные из первоисточника в конце запроса закидываю их в буфер при помощи функции Table.Buffer()
Попробуйте - возможно поможет. Вот здесь обсуждалось нафига я такое делаю.
Вот горшок пустой, он предмет простой...
 
 
 
#10
03.07.2018 20:17:23
Цитата
Vsevolod написал: PQ очередность выполнения запросов выстроить
я делаю так - сразу всё:
let
Query1=let .... in result1,
Query2=let .... in result2,
nn = какой нужно Calculation или Transform используя результаты Query1 и Query2   //именно Query1 и Query2 в качестве параметров
in
nn
---> вроде пока проблем не замечала  - последовательность соблюдается
Изменено: JeyCi - 03.07.2018 20:18:20
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
 
 
#11
04.07.2018 15:40:22
JeyCi, хорошая идея на последнем этапе разработки. Ну или для продвинутых :)
F1 творит чудеса
 
 
 
#12
04.07.2018 18:48:32
Цитата
Максим Зеленский написал:
хорошая идея на последнем этапе разработки
именно!.. так как в процессе разработки все Queries тестирую отдельно... потом свожу воедино по такой схеме (как описала выше) - для вывода только нужного итога (без промежуточных таблиц)
Изменено: JeyCi - 04.07.2018 18:54:29
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
 
 
#13
05.07.2018 09:01:46
Но, если я все правильно помню, то данная схема записи в Excel-евском PQ все равно не поможет, и если вы будете несколько раз обращаться к Query1 (который в результате выдает таблицу) даже внутри одного запроса, он все равно не будет его нормально кэшировать, что опять же вызовет неоднократное считывание источника с жесткого диска. Так что Table.Buffer для меня - это спасение.
А еще такая запись это ад для поиска косяка в источниках, если они выгружены криворучками.
Вот горшок пустой, он предмет простой...
 
 
 
#14
06.07.2018 11:28:45
Цитата
PooHkrd написал: Table.Buffer
при случае попробую внедрить
step = Table.Buffer(Query1)
и такой же для Query2 - далее в nn параметрами эти step'ы
НО
ввиду ссылки поста Максима #10 - не думаю, что получу ошеломляющий прирост в скорости (+ в проекте ~ 400 запросов в i'net за data)...
если не права в своём предположении - отпишусь...  :) или когда-нибудь перейду на PowerBI...
p.s.
хотя его замечание по скалярным величинам для меня почему-то ставит под сомнение эффективность Table.Buffer для работы с Таблицами... (хотя название метода даёт надежды) - если они не останутся лишь надеждами - черкану итоги по скорости (если окажусь под впечатлением)... жаль что что-нибудь типа "Debug.Print t-Timer" в PQ - не возможен...
P.S.
в любом случае - цель моего предыдущего поста - избавление от промежуточных таблиц...
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
 
 
#15
06.07.2018 11:56:37
Цитата
JeyCi написал:
черкану итоги по скорости (если окажусь под впечатлением)
Было бы очень интересно увидеть результаты такого теста.
От себя еще раз повторю, что максимальный прирост от этой функции получается либо если буферизованная таблица неоднократно вызывается в других местах запроса, либо если вы в одну таблицу наджойнили всякого, а потом из полученных данных вычисляете новые сущности (столбцы, списки и т.д.). Вот перед вычислением табличку со всяким приджойненным лучше загнать в оперативку.
Вот горшок пустой, он предмет простой...
 
 
 
#16
03.08.2018 10:05:00
добралась...
справочник календаря из 53 строк - используется в 44 440 строках финальной таблицы:
st=Table.Buffer(st1) дал прирост 25 сек (после части parse label)
2 мин 25 сек без него и 2 мин с Table.Buffer
p.s.  
всё равно 2 мин долговато... думаю на Power BI (по ссылке из #14) - результаты могут быть получше...
но я пока на office2010 win7
Изменено: JeyCi - 03.08.2018 10:43:19
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
 
 
#17
03.08.2018 10:44:45
JeyCi, справочник 53 строки в буфере - это, конечно, очень мало. Полминуты сэкономленные на буфере при таком объеме - вполне неплохо. Скорее всего, 2 минуты набегают в другом месте.
F1 творит чудеса
 
 
 
#18
03.08.2018 11:03:46
 да Максим, я думаю: 2 минуты набегают в обращении к папке за 311 текстовиками (в которых json структуры)... их разбор... потом обращение ко 2-й папке за 165 текстовиками... потом JOIN календаря с data из 1-й папки и data из 2-й папки... ну JOIN'ы в принципе быстро... вся загрузка - считать из текстовиков... и ещё 4 папки - но там поменьше файлов json
p.s.
раньше делала напрямую из i'net... замечала что побыстрее... но сейчас при обращении столько раз (за каждым json) из PQ в i'net - что-то постоянно вываливается совет подключаться как Anonymous - и так все 500 раз  8-0  - поэтому через vba загружаю на комп и считываю папку...
- думаю, может дело в правах доступа - устанавливаю на книгу Organization, на внешний источник Public... но пока подключение напрямую к сайту вызывает диалог xl со мной ~500 раз... поэтому беру с папок...
p.p.s
в принципе это сделать за 1 день данных 1 раз - потом скидываю в Access для работы с этими данными... PQ - только взять (2 минуты на день - ~44,5 тыс строк) - хотя масштабировать ещё в 2р на др активы - уже думаю будет не очень удобно... но пару  минут в день - это ещё терпимо, полагаю... (более 5 дней data не хранятся на сайте - поэтому брать глубоко историю с сайта нет необходимости и возможности)
Изменено: JeyCi - 03.08.2018 11:15:05
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
 
 
#19
10.08.2018 09:28:28
Цитата
PooHkrd написал:
табличку со всяким приджойненным лучше загнать в оперативку.
МОЙ ВЫВОД:
не улучшилась скорость... полагаю, в моём случае потому что после JOIN - получается большой массив, который загнав в память, - получаем уменьшение свободной памяти для дальнейших операций...
НО мне удалось ещё улучшить время до 1 мин - за счёт забуферивания сложного TransformColumns... 1 мин радует больше, чем 2 мин   :)  :idea:
ТАКИМ ОБРАЗОМ улучшение времени работы кода достигнуто за счёт использования Table.Buffer:
1) после парсинга строковых значений
2) после сложной трансформации - как в этой моей ветке (когда только знакомилась с PQ)... - там только справочник, полный код сложнее с использованием того справочника....
Изменено: JeyCi - 10.08.2018 09:35:04
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
 
 
Страницы: 1
Наверх