Нахожусь в одном офисе. Подключаюсь по удалёнке в другой офис. Открываю базу. Запускаю запрос. Отрабатывает неверно. Выгружаю в dt, забираю к себе. Загружаю. Запускаю запрос. Отрабатывает верно. Платформа 1С и там, и здесь 8.2.17.143. Выгоняем с их админом всех пользователей. Чистим кэш на сервере 1С. Захожу. Не помогло.

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

В запросе используется таблица фактического периода действия. Если нужно, могу написать весь запрос (в упрощённом виде).

Что можно ещё попробовать? Может, кто-нибудь с таким сталкивался?

Файловая/клиент-серверная?

Итоги?

"Нахожу способ, как переписать запрос, чтобы он отрабатывал верно" - вот это единственно правильный выход!

(1) Серверная.

"лишний раз типовой модуль трогать не полезно,"
а не всегда типовое решение отрабатывает корректно. Нюансы могут быть в каждой ИБ.

(3) Чтобы выбрать единственно правильный выход, нужно для начала разобраться в причинах.
(4) И там и там? И в самом деле, попробуй итоги пересчитать, если в запросе регистры накопления используются.

(4) серверная у них и файловая у тебя? такое может быть, может...

(6) Да. И там, и там серверная.
Регистр расчёта. Там итогов нет. Я ведь написала, что используется таблица фактического периода действия. А она имеется только в регистрах расчёта.

покажи запрос

(0) покажите запрос

(8) если и там и там серверная, то я бы не стал использовать выгрузку через DT, она точно серверная? СУБД какая?

Точно серверная. В файловую она не загружается. Конфа дописанная и там где-то индекс длинный. При загрузке в файловую версию, появляется ругня о том, что загрузить её невозможно, а в серверную загружается нормально.

Запрос сейчас напишу. Типовой запрос слишком длинный. Я только с проблемой кусочек сделаю.

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

ВЫБРАТЬ
    ДАТАВРЕМЯ(2014, 1, 22, 23, 59, 59) КАК ТестоваяДата
ПОМЕСТИТЬ ВТ_Тест
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
    ТестоваяТаблица.ТестоваяДата КАК ТестоваяДата,
    ФактическийПериодДействия.ПериодДействияНачало КАК ПериодДействияНачало,
    ФактическийПериодДействия.ВидРасчета КАК ВидРасчета,
    ОсновныеНачисления.ЯвляетсяДоходомВНатуральнойФорме КАК ЯвляетсяДоходомВНатуральнойФорме
ИЗ
    ВТ_Тест КАК ТестоваяТаблица
        ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрРасчета.ОсновныеНачисленияРаботниковОрганизаций.ФактическийПериодДействия(
                Сотрудник = &Сотрудник
                    И ПериодРегистрации = ДАТАВРЕМЯ(2014, 1, 1)) КАК ФактическийПериодДействия
        ПО ТестоваяТаблица.ТестоваяДата = ФактическийПериодДействия.ПериодДействияНачало
        ВНУТРЕННЕЕ СОЕДИНЕНИЕ ПланВидовРасчета.ОсновныеНачисленияОрганизаций КАК ОсновныеНачисления
        ПО (ФактическийПериодДействия.ВидРасчета = ОсновныеНачисления.Ссылка)

(0) надо установить на сиквел сервиспак

данная проблема типовая и многократно обсужденная

(0)выгрузить в dt и загрузить обратно в боевой базе (а не у себя) пробовали?

(12) По-моему,  Ненавижу 1С имеет ввиду, что при выгрузке/загрузке данные могут измениться и для чистого эксперимента стоит копировать базу средствами СУБД.

(14) Спасибо большое! Попробуем.
(15) Пробовали. Не помогло.

проверьте еще смещение дат, там и там

(16) Копировать базу средствами СУБД тоже пробовали. Не помогло.

Попробую то, что посоветовали в (14), потом отпишусь.
Если проблему многократно обсуждали, значит, способ лечения может помочь. :)

Убежала на обед. Всем спасибо!

(20) начни с обратного

добейся от сисопа ответа на вопрос, установлен ли SP

(21) Добилась. Нету. Осталось добиться, чтобы они его установили. :)

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

А как может быть вылечена неверная сортировка загрузкой базы в другом месте? Тем более, что выгрузкой-загрузкой там у них проблема не лечится. И регистр типовой, изменений в него не вносила.

Кстати, раз проблема уже ни раз обсуждалась, то хотелось бы знать. Это происходит только с регистрами расчёта или с другими метаданными тоже?

(25) только с расчетам
(24) проблема проявляется при нерусских локализациях сиквелов

в типовых запросах, которые уверены что А раньше Я

таких мало, но они есть

хм... понятно, зато теперь буду знать, как это лечится :)

Я потом напишу сюда, помогла ли установка SP, когда добьюсь, чтобы она была сделана.

А всё начиналось так мирно. В Т-60 неверные данные. А вот доковырялась до того, что SP устанавливать надо.

shuhard ! Огромное спасибо! Установка SP помогла. Запрос теперь отрабатывает верно. :)