Привет всем! В таблицу импортренжем тянется диапазон данных. Таблица эти данные

показывает. А скрипт при заборе значения из ячейки в этом диапазоне выдаёт пустоту.

В аналогичной ситуации на другом листе тот же скрипт показывает всё правильно.

У кого-то было такое? В чём может быть причина?

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

SpreadsheeyApp.fetch()

Краткий перевод сообщения от Володи: Скрипт может не увидеть результат расчёта формулы, а формула может не успеть рассчитать. Для того, чтобы избежать этой проблемы используйте метод SpeadsheetApp.flush()

Это есть, оно не помогало.

getDisplayValues?

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

Благодарю! Попробую, если снова заглючит.

Это полный перевод того что можно найти в доках загуглив по flush

я его себе представляю как await

Оно очень важно когда применить а не просто есть

Да это понятно. Там фишка в другом была. Все "флюши" отработали, все посчитано и в ячейки поставлено. Потом едет скрипт, и он не видит в ячейке того, что вижу я...

А я представляю нафига брать после импортранж если можно напрямую взять с источника

Нужен режим авто-обновления онлайн. Потому и импортренж.

flush не гарантирует что у вас есть сеть. Так что это норм. Ну и проверьте, что там за типы данных, а то мож просто формат чудной

Доброго времени суток, Павел. Помогло? Просто интересно

Это прям ваще тонкий лёд. Я протиф

угу, я тоже против. Поэтому и спросил

getDisplayValues() я не пробовал здесь. Оно больше не глючило. В чём была проблема, так и не понял. Я тогда просто убил формулу в ячейке, а потом её заново прописал (такую же). И всё заработало. Магия какая-то... )

Интересно. Но не поянтно, как повторить фокус, чтобы понять, что это было.

Соглашусь. С датами вообще не работает.

Да, пользователь как вставит дату — хоть стой хоть падай. 2023-02-02 или 02/02/2023

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

если только не "закопиПастит"

Ну да. Но это вообще зло! )

дык они так и делают. На зло делают..

Есть такое. Типа "а нам так удобнее... а какая разница?..."

У меня даже зреет мысль на onOpen() повесить самовосстановление таблицы по форматированию.

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

Я от практики многопользовательских таблиц отказался. У меня каждый со своей работает. Так надёжнее.

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

Вроде на права к таблице ругаться станет. С пользовательской формулой ругалось на применение форматирования.

А Вы прикрепляйте таблицу к рабочему месту, а не к человеку. Потом (если они со своими личными аккаунтами) просто меняете доступ на нового юзера. А если адреса "корпоративные", то и вообще ничего менять не надо.

Если на onOpen() триггер от владельца скрипта, то не станет ругаться.

да не (но спасибо).. такой вариант не помогает в моем случае, т.к. к каждой сущности иные в множестве привязаны. Разложил всех с минимум данных в каждой таблице, но уже в pg. Сейчас вот все соединения спроектировал, но это уже другая история

Тогда сделайте скрипт создания и настройки новой таблицы для нового сотрудника.

да было б так все просто))

Понял. Отстал. ))

да вроде бы тут никто не пристает, обсудили просто))

Да я шучу )

Кстати, тут ест такое решение. Пишем инструкцию сотрудникам, ознакамливаем. И устанавливаем правило: кто будет ломать ячейки в таблице, тот скидывается на кофе админу. Тариф: одна поломанная ячейка = стоимость одной чашки кофе. Сам кофе покупать не надо, а просто задонатить, - админ сам решит, как этими донатами распорядиться. 😎