Не получается решить задачу следующего характера.
Есть запрос, который обращается к двум файлам: плану и факту.
"План" находится на моем компьютере, а факт - в общем доступе.
Если я отдаю файл сотрудникам, у которых есть доступ к файлу с фактом, но нет доступа к файлу с планом, то при обновлении запроса получаем ошибку и данные не обновляются.
Можно ли как-то обойти в запросе проверку на доступность файла с планом, если сам файл недоступен?

Здравствуйте!

Может быть кто-либо сталкивался с проблемой "...переполнения стека..." при отработке запросов PQ при следующих обстоятельствах.
1. Есть файлы, которые размещены на дропбоксе. В каждом из них прописана т.н. "динамическая ссылка", которая позволяет открывать и обновлять (при определенных условиях) файлы не только на компе создателя запросов, но и на компьютерах, которым предоставлен доступ к папкам и у которых также установлен локальный дропбокс, обновляемый через облачный сервис.
2. К обновляемым на дропе файлам подключены запросы, например, к файлу с фактической реализацией (находится там же, на дропбоксе) и к файлу с планами продаж, который находится на моем компьютере и я его в облако намеренно на выкладывал (постоянно обновлять их не нужно и обычно в случае, если доступ к файлу отсутствует, то выдается предупреждение при выполнении запроса о том, что запрос выполнен быть не может и предлагается продолжить обновление иных запросов, как-то так).
3. На моем компьютере (Вин10х64, офис 365х64) запросы выполняются, на компе коллеги (Вин10х64, офис 365х64), у которого есть доступ к локальной папке на дропбоксе, обновляемой через облако, запросы не выполняются. Постоянно вываливается такая ошибка "При вычислении возникло переполнение стека. Продолжение невозможно". При нажатии на кнопку "ОК" выполнение запросов прекращается и файлы не обновляются.

Причин для возникновения такой ошибки быть не может (я так думал ранее), ведь у меня аналогичный запрос обновляется нормально. Единственное отличие между моей позицией и позицией коллеги по отношению к файлам - отсутствии доступа к планам. Но непонятно, почему возникает ошибка "переполнения стека". В этой ситуации я предполагал, что будет предупреждение об отсутствии доступа к файлу и можно будет продолжить выполнение иных запросов. И это бы меня полностью устроило.

Вопрос: сталкивался ли кто-нибудь с аналогичной проблемой и как ее решил в итоге?

После обновления офиса до билда 16.0.12725.20000 (инсайдерский билд) при загрузке данных из интернета (https://bank.gov.ua/files/T-bills_debt.xls) получаю ошибку при обновлении запроса: DataFormat.Error: Сбой IErrorInfo.GetDescription с E_FAIL(0x80004005).
В более ранних билдах такой проблемы не было.
Другие запросы отрабатывает нормально. Проблема именно при обращении к экселевским файлам xls (по крайней мере, у меня нее работает только этот запрос пока).
Кто-нибудь сталкивался с такой ошибкой ранее и как обходил ее?

Столкнулся в Excel со следующей проблемой.
Есть файл плана и факта продаж за большой период. Данные обрабатывались в Power Query и выгружались в Power Pivot.
При первой выгрузке создал календарь в Power Pivot (конструктор - таблица дат - создать).
Календарь подтянул все даты из существующих отчетов и ограничил диапазон дат 31.12.2019.
Календарь связал с планом и фактом. Сводные строю с датами из календаря.
Сейчас (в январе) обновил факт продаж (до 11.01.2020) и попытался изменить диапазон дат в календаре и... ничего не получается почему-то.
Если создаю новый календарь, то конечная дата вроде и устраивает (31.12.2020), но увеличить ее опять не получается. Да и странно это: каждый год пересоздавать календарь.
Кто-нибудь сталкивался с такой проблемой в ПаверПивоте Excel и если сталкивался, то как обошел?

Офис365х64 билд 16.0.12325.20288

Не получается создать справочник курсов валют.
Создаю список дат.
Создаю функцию, которая обращается к сайту Нацбанка и тянет оттуда дату.
При проверке функции все Ок, т.е. функция возвращает курс на указанную в соответствующем поле дату.
Далее создаю календарь, в который подтягиваю список дат. Добавляю столбец, который обращается к дате в конкретной строке и на этом все заканчивается.
Почему - непонятно.
При этом меня терзают смутные сомненья относительно того, что такое количество запросов сайт перенесет с трудом. Ведь обращение происходит по каждой дате в списке.
Подскажите, пожалуйста, куда копать и как оптимизировать запрос.
Ссылка на файл - https://1drv.ms/x/s!Amn-IZ0k3g6o1DK2dtHfTwELqNf1?e=tighNu

Имеется файл Excel с большой таблицей. Одно из полей этой таблицы - код, числа представленные в текстовом формате по некоторым причинам (ссылка на поле с кодами).

Есть также внешний запрос к этому файлу. Но при формировании этого запроса коды выводятся некорректно.
Например, вместо 8.2 получаю 8.1999999999999993.
Кто-нибудь сталкивался с таким странным поведением PQ и если "да", то как, кроме банальной замены, поборол этот странный недуг?

Возможно ли в кэше сводной изменить формат поля (кодом, например)?
И именно в кэше, так как в таблице-источнике формат нормальный (общий), а в кэше - изломанный (дата).
Изменить формат полей сводной существующими инструментами не получается никак.
Сталкивался ли кто-нибудь с такой задачей?

После последнего обновления офиса в столбцах с датами больших таблиц перестал нормально работать автофильтр.
Например, данные собирались с 2010 года до текущей даты. При попытке использовать фильтр в столбце с датой в выпадающем списке вижу только несколько месяцев 2011 года. Таблица большая (более 280 000 строк) и преобразована в т.н. "умную" таблицу.
При этом на форуме Майкрософта нет ни одного сообщения на эту тему. Да и вообще сообщений подобного рода в последнее время не нахожу.
Пересмотрел все настройки... все Ок. Ну, мистика просто.
Примечательно, что предыдущие билды указанного выше глюка не имеют.
Кто-нибудь сталкивался с таким поведением автофильтров именно в колонках с датами и если "да", то как поборол?

Указанные проблемы наблюдаются в текущем билде 16.0.8229.2073, а также в более старших инсайдерских slow и fast билдах.

Коллеги! А сталкивался ли кто-нибудь из вас с сабджем.
При этом формат может изменяться и в области фильтров, и в области строк, и в области столбцов
В стилях ячеек все Ок (никаких сторонних пользовательских форматов нету).
В исходной таблице (преобразованной как "умная таблица")  эти поля - либо числовой формат, либо общий.

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

Если есть решение, поделитесь, плз.
Офис 2013*64

Прошу помощи.  
 
Есть таблица с наименованиями и количеством. Наименования расположены в порядке возрастания. Некоторые наименования дублируются с добавлением "звездочки" (*). Т.е., товар "RRR" и "RRR*". В исходной таблице товар с наименованием "RRR*" следует за товаром "RRR" (т.е. повторюсь, сортировка в исходной таблице "от меньшего - к большему").  
При использовании функции ВПР именно при такой сортировке на выходе получаются искаженные данные (функция воспринимает два разных наименования, как полностью идентичные и возвращает первое значение, т.е. RRR).  
Сталкивался ли кто-нибудь с таким поведением функции ВПР?  
И как победить эту странную хрень без сортировки исходной таблицы в порядке убывания?

Коллеги!  
Не нашел на форуме ответа на вопрос, который у меня возник. Поэтому запостил новую тему.  
Проблема такая. Имеется относительно большой массив данных (таблица). Часто есть необходимость проделать замену точек на точки в столбце с датой, т.к. простым "форматом ячейки" изменить текстовый формат на формат даты неполучается.  
При такой замене происходит следующее: Excel проходит по всем ячейкам и заменяет точкуна точку (у меня последний раз было около 33000 замен). После замены Excel типа "думает". Причем, чем больше замен, тем больше "думает". Не зависает. Это точно.  
 
У меня Офис 2010 (Вин7*32, 3 Гб оперативки). Пробовал ради интереса на 2003 офисе (ВинХР*32, 1 Гб оперативки). Та же проблема.  
 
Кто-нибудь сталкивался с подобным и как это можно обойти? Так как если количество замен исчисляется сотнями тысяч, ждать приходиться по 20...30 минут.