Больше недели бьюсь с этой проблемой. У клиента стоит SQL Server 2008 RTM 10.00.1600.22. Есть одно начисление, называемое "Доплата до МРОТ" (не думаю, что это важно, но пусть будет для примера), которое используется редко. Так вот, при начислении зарплаты в базе клиента идут бешеные цифры - более 60 т.р. Выгружаем локально, рассчитываем документ - все как надо. Развернул у себя сервер на компе (правда, немного другой, 2008 R2), гружу эту же самую базу, открываю этот же самый документ, жму кнопку Рассчитать - опять все нормально. Поковырялся в коде, уперся в один маленький запрос, который выдает разный результат при одинаковых исходных данных (разберусь, как оформить код - кину его). Никто с подобными вещами не сталкивался? Куда вообще копать?
PS: Конфу обновляли, платформу тоже.

(0) У клиента ДТшник выгрузи/загрузи например. ТиИ опять же.
Найди записи которые не попадают или неправильно попадают в результат запроса.

1 + кэш

(2) как исправишь проблему требуй у клиента кэш. )

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

    
    ОБЪЕДИНИТЬ ВСЕ
    
    ВЫБРАТЬ
        База2.РезультатБаза,
        База2.Регистратор,
        База2.НомерСтроки
    ИЗ
        РегистрРасчета.ОсновныеНачисленияРаботниковОрганизаций.БазаДополнительныеНачисленияРаботниковОрганизаций(&парамИзмеренияОсновного, &парамИзмеренияБазового, &парамРазрезы, ВидРасчета.КатегорияРасчета = &парамКатегорияНачисления И Регистратор = &парамРегистратор И Авторасчет) КАК База2
    ГДЕ
        База2.Сторно И База2.ПериодРегистрацииРазрез < База2.ПериодРегистрации
            ИЛИ НЕ База2.Сторно И НАЧАЛОПЕРИОДА(База2.ПериодРегистрацииРазрез, Месяц) <= База2.ПериодРегистрации) КАК База
СГРУППИРОВАТЬ ПО
    База.Регистратор,
    База.НомерСтроки

ТиИ делали. И не в кеше проблема: на том же самом сервере клиента создавали новыую базу, грузили ДТ-шник, и на этой базе опять неверный расчет. Так что не все так просто...

(4) Один и тот же код на одной базе не может работать по-разному. Кэш или там, или там глюка ловит.

(5) ищи записи которые лишние или которых не хватает.

(7) Как это на одной же базе не может быть каких-то записей? Регистер один.

Запусти консоль запроса и там и там и посмотри, что оно тебе покажет.

(0) [ Никто с подобными вещами не сталкивался?]все
[Куда вообще копать? ]поставить на сиквел SP,
если алгоритм самописный, проверить в запросе сортировку

(6) Как я говорил, база на сервере создавалась заново, с кешем там все в порядке было. Подозреваю, что SQL хулиганит. Отцы 1С говорят, что про такое читали, но никто не сталкивался, найти какую-либо информацию не получается.
(7) Если ничего не останется, то этим и придется заняться. Но в запросе, я так понимаю, ищутся базовые начисления для указанного в документе. А система этих начислений весьма и весьма сложная, поэтому вручную проверять довольно проблематично.
(9) Так и проверял. Один и тот же сохраненный запрос открываю, выполняю - цифры в результате разные.
(10) Поясните пожалуйста, что значит "поставить на сиквел SP". Алгоритм типовой, в результате запроса одна запись, сортировка не поможет.

сервис-паки на скуль все накатите

(11) А где этот текст запроса сидит?
Может быть поможет или нет, не знаю, но когда говорили, чтоб почистил кэш - имеют мнение, что на клиенте, с которого идет расчет, из кэша модулей (не базы) вытаскивается "кривой" текст модуля.

(11) Если ничего не останется, то этим и придется заняться. Но в запросе, я так понимаю, ищутся базовые начисления для указанного в документе. А система этих начислений весьма и весьма сложная, поэтому вручную проверять довольно проблематично.

1 .Делаешь выгрузку запросом по таблице  РегистрРасчета.ОсновныеНачисленияРаботниковОрганизаций.БазаДополнительныеНачисленияРаботниковОрганизаций в одной базе и другой .
2.Копируешь в Excel
3.Сравниваешь построчно
4.....
5.Profit

(11) расчет с комментарием даст больше информации

(11) <<Отцы 1С говорят, что про такое читали, но никто не сталкивался, найти какую-либо информацию не получается>>
v8: Странно расчитывает районный коэффициент в ЗУПе.
v8: SQL 2008 + ВНУТРЕННЕЕ СОЕДИНЕНИЕ

И я бы посмотрел еще, что там в регистраторах возвращается (в запросе регистраторы есть) и перепровел бы их. Если висят какие-то оторвавшиеся от регистраторов записи с суммами... При загрузке из дт их не будет.

Перезалить базу на тоже самое место, если не слишком большое желание с ТИИ экспериментировать.

(11) Release     Product version
SQL Server 2008 Service Pack 3     10.00.5500.00
SQL Server 2008 Service Pack 2     10.00.4000.00
SQL Server 2008 Service Pack 1     10.00.2531.00
SQL Server 2008 RTM     10.00.1600.22

у Вас голый сервер, который не обязан вообще как-то работать

(11)[Отцы 1С говорят, что про такое читали]
это пиз.дёж к чему ?

было такое, но с Postre - итоги были криво подсчитаны

да много у кого такое было. лечится перепроведением косячных доков обычно или ТиИ.

запрос в запросе, как отмечают спецы по sql, не есть хорошо... рекомендуют переписывать такие запросы на временные таблицы... может быть тогда и проблема уйдет... вроде как, sql не оптимально и криво может построить план исполнения запроса... ну и у меня была проблема с корректным отображением результат запроса... помогла дефрагментация индексов, которая составляла по 90%... может проверить?...

(13) Текст запроса сидит как в документе, так и в консоли. Вряд ли он берется из одного и того же места в обоих случаях. (15) Да, самое интересное в расчете с комментариями - это база. Как раз она и превышает 60 т.р. в неправильном случае (должна быть в районе 5900). Тот запросик как раз и рассчитывает базу.
(18) Это не гола база, это просто первый релиз версии: [url]http://en.wikipedia.org/wiki/Software_release_life_cycle#RTM_or_RTW[\url]
(22) Подскажите, как я могу сделать дефрагментацию индексов? В консоли вытащил подзапрос, проблема не в нем.

параметры в запрос передаваемые проверьте

(16) Самое интересное оставил напоследок, спасибо большое. Админу дали задание на апгрейд, сегодня-завтра сделает. О результатах сообщу.
(24) Они идентичны: скопировал файл запросов консоли, и передал на сервер.

(0) Нечто подобное было. Помогла переиндексация. Но не в ТиИ, а на SQL сервере. Но у меня PostgreSQL.

(25) я не о тексте,а о параметрах.обновите скуль или попробуйте на нормальном свою базу

Сталкивался как-то с багом в ЗУПе, связанный с рабочим временем. Там запрос был без указания явного упорядочения, а перебор результатов предполагал наличие порядка. На файловой базе всё работало "правильно", а на sql-версии алгоритм выдавал ахинею.

(6) может, например сортировка в файловой и серверной может у запроса немного по разному отрабатывать.

(4) сравни результат запроса и там  и тут... допили запрос что-бы он выдавал то что нужно в обоих случаях.

Как-то был такой случай - обернул результат  во временную таблицу и отобрал из неё - вроде так решил

(23) дефрагментация индексов средствами sql... в management studio, либо sql-запросами... я "вычислял" имя интересующей таблицы sql в 1С (есть готовые решения-обработки по анализу структуры таблиц sql, сейчас не помню, где брал, поищу), затем смотрел в management studio индексы интересующей таблицы, находил сильно фрагментированные и, опять же, с помощью средств management studio эти индексы либо реорганизовывал, либо перестраивал (дефрагментировал)...

+ (31) вру... обработку по анализу писал сам... натолкнуло на идею здесь http://v8.1c.ru/metod/faq2/answer.jsp?id=493...

Товарищи, на моей улице праздник! Все прошло с накатом сервиспаков, спасибо большое за помощь!

(33) выпей вотки