Сначала была 1С 8.2, теперь 8.3 Серверный вариант,sql 2012. База довольно большая, порядка 500 Гб. При формировании отчетов происходят странные вещи: очень большой и сложный запрос, допустим по всей номенклатуре, остатки, состояние и т.п. Часть номенклатуры не выводится, как будто нет остатков или не удовлетворяет она какому-либо условию. Но при этом, если формировать с отбором по этой самой номенклатуре, все прекрасно выводится. При чем у одних пользователей одна часть номенклатуры выпадает из отчета, у других совершенно другая ((( Вроде и саму 1С-ку поменяли, а не помогло. Пользовательские настройки на компах сбрасывали, на случай вдруг где какой отбор остался... Неужели дело в sql? У кого-нибудь были подобные проблемы и как с этим бороться?

Значит не по всей номенклатуре.
Ищите, например, где запрос из левого превращается во внутренний. Например, левое соединение справочника номенклатуры с остатками но добавляется условие в ГДЕ на остатки.
Например, рлс

P.S. "не верю" (с) В 99% случаев проблема не в 1с, а в запросе (руках)

(0) Программиста позвать пробовали?

(0)[Вроде и саму 1С-ку поменяли, а не помогло.]+[Род занятий:     Домохозяйка]= ответ очевиден

(3) зачем в домохозяйстве база >500 ГБ?

Как плюс к вышесказанному, из разряда фаантастики: конструкция ПЕРВЫЕ Нн есть в запросе? :-)

(0) Суровые нынче пошли домохозяйки.

Если же по делу:
1) Зря перешли на 8.3. Кто вас вообще надоумил?
2) Сама 1С тут врят ли виновата, скорее всего дело в запросе. Так как тут экстрасексов нет, то вываливай запрос - поглядим.

100 лет не заходила на форум, надобности не было, что же так сразу править род занятий теперь? Да, когда регистрировалась, была домохозяйкой )))
Конструкций  ПЕРВЫЕ в запросе нет.
Как таковая Номенклатура не выбирается, идет перебор элементов подчиненного справочника, но они выбираются ВСЕ и уже соединяются с другими таблицами. Конфигурация очень далеко не стандартная и про Номенклатуру я утрировано сказала, боюсь, что текст самого запроса (огромный 5844 строки ), если я и выложу, но ясности это не добавит. Нет с запросом все нормально. У небольшого количества пользователей он формируется полностью.Т.е. вполне работоспособная версия ((((( Настройки у разных пользователей проверяла- одинаковые, но у всех по разному формируется.

База распределенная. 7 филиалов. В 5-ти филиалах все нормально, в двух такая беда (((( Базы индексировали и на логическую целостность проверяли.

(7)"Нет с запросом все нормально". ИМХО. Опрометчивое заявление. Если стесняешься показать запрос, то показывай характеристики железок. Есть еще отладчик, замер производительности, технический журнал.. Продолжать?

Кэш, рлс, кривой запрос, вспышки на солнце.

Проблема устойчивая или время от времени. Под одним пользователем на всех компах или под всеми пользователями на одном компе.

Что за гадание на кофейной гуще? Доктор, у меня где-то болит.

это что ж такое можно делать в пяти тысячах строк?

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

Ваша цель доказать, что я не такая умная, как большинство здесь присутствующих? Не старайтесь, я с этим и не спорю, а то бы не стала просить помощи у мэтров ))) Давайте не будем уточнять и вдаваться в подробности, запрос сложный и конечно не совершенный. Но давайте будем условно-досрочно считать, что он все-таки рабочий.
Кэш чистили, не помогло.
Проблемы начались некоторое время назад, месяца два. Причем запрос не менялся.
Вариант аутефикации пользователя по сетевому имени и паролю. Поэтому вариант под разными пользователями на одном компе не проверяла.
Что может дать замер производительности?
В Отладчике я только могу проверить, что параметры у всех одни и те же в запрос передаются. Ну и результат выполнения запроса, но я итак знаю, что у кого-то что то выпадет.
Никто никогда не сталкивался с подобной проблемой? Я просто хотела бы услышать что то типа:"У меня так было, но вот есть такая утилитка для sql, ее прогоняешь и все замечтательно" (((

А что такое тии?

Это наверное аббревиатура от Тестирование И Исправление? Прогоняли, не помогло.

(13) Доказывать ваши знание\не знание тут нет смысла.

Предлагаю следующий порядок действий (если принимать во внимание .что типа ЗАПРОС РАБОТАЕТ ПРАВИЛЬНО (хотя это очень под вопросом)):

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

(13)  +

"Я просто хотела бы услышать что то типа:"У меня так было, но вот есть такая утилитка для sql, ее прогоняешь и все замечтательно" ((("

Если изобретут большую зеленую кнопку, о которой вы говорите, ты мы с вами потеряем работу.

Да, Большая Зеленая Кнопка (БЗК) это конечно было бы здорово, но мы про нее никому не расскажем ))))

Еще можно проверить, нет ли РАЗРЕШЕННЫЕ в запросе.

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

надо рассчитать итоги

нет РАЗРЕШЕННЫХ нет в запросе.
Попробую рассчитать итоги и разберу запрос на временные таблицы.
Спасибо большое всем неравнодушным. Ведь даже осознание того, что ты не один во Вселенной вселяет Надежду ))))