Переработанная торговля 7.7 SQL. 1С++, FormEx, Yoksel
Изредка возникает ошибка
Документ.ЗаявкаПокупателя.Форма.Модуль(2134)}: Значение не представляет агрегатный объект (ВалютаВзаиморасчетов)
в строке
ВалютаДоговораСтарая    = Договор.ВалютаВзаиморасчетов;

Договор - реквизит шапки документа типа Справочник.Договоры. В справочнике реквизит ВалютаВзаиморасчетов, конечно, есть.
По идее, такой ошибки быть не может, реквизит документа Договор может иметь значение или конкретного договора, или пустого значения типа "Справочник.Договоры". В любом случае "Договор.ВалютаВзаиморасчетов" не должно вызывать ошибку.
Переменных с именем "Договор" не объявлено.
Кто нибудь с таким сталкивался?

в 7.7 тоже есть отладчик

(0) давно в семерке не работал , а ВалютаВзаиморасчетов не переодический реквизит?

(2) не заметил , что изредка

договор не выбран, вот и.

Разве 7.7 нормально отрабатывает обращение к реквизитам пустой ссылки?

(1) Ошибка возникает на полторы сотни пользователей разок в неделю. Отладчиком хрен выловишь.

(4)(5)
ПолучитьПустоеЗначение("Справочник.Договоры").ВалютаВзаиморасчетов
отрабатывает нормально. И при невыбранном договоре все должно быть окей. Мне кажется, это какой-то странный глюк, связанный или с потерей, или с порчей контекста.

(7) ТиИ?

(7) Битая ссылка. Возможно.
Оформи в попытку и на исключение вешай запись в лог ключа для поиска записи и описание всех контекстов.

(8) А ТиИ сложно. Основная база уже на 100 гигов перевалила. Пытаюсь тестировать различными SQL-запросами, но, наверняка, много аспектов упускаю.
(9) На это похоже. Искать надо.

ВалютаДоговораСтарая - Это что такое, Реквизит или переменная?

Если переменная, то научись объявлять переменные через "Перем ВалютаДоговораСтарая;" :)

+(0) Смотри, какого типа "Договор", если просто справочник и он пустой, т.е. не указан, то ошибка имеет иметь место :)

(0) А при перепроведении проблемного документа ошибка воспроизводится?
Такое может быть если реквизит только для элемента, а выбрана группа.

(13) Разве? Это же документ. Кто мешает писать в реквизит Хоть элемент, хоть группу?

(11) 1С не требует объявления переменных и даже не способна это контролировать. Так что объявлять переменные хорошо, но толку обычно минимум.
(12) в (0) сказано "Договор - реквизит шапки документа типа Справочник.Договоры"
(13) Если бы отловить что-где-когда. :( Более полутора сотен пользователей в дюжине городов и проблема вылазит редко-редко. Сейчас вставил попытку-исключение с автоотправкой себе скриншота и прочей информацией. Может удастся выловить конкретную ситуацию.

Связанный вопрос: предположительно проблема из-за нарушения внутренних связей между 1sjourn, dt*, dh*. Нет ли у кого опыта и примера SQL-запроса для тестирования этих связей?

(14) Я как раз про это: в "Договор" выбрали группу, а у нее реквизита ВалютаВзаиморасчетов нет.

(13)(16) Это не вызывает ошибки. Похоже, 1С проверяет признак Для элемента/Для группы/Для обоих исключительно на этапе дизайна формы.

(15) "Связанный вопрос: предположительно проблема из-за нарушения внутренних связей между 1sjourn, dt*, dh*. Нет ли у кого опыта и примера SQL-запроса для тестирования этих связей?"
select *
from _1sjourn j (nolock)
full join dhXXX dh(nolock) on dh.iddoc = j.iddoc
where dh.iddoc is null or j.iddoc is null

Поиск битой ссылки
select
j.docno, j.date_time_iddoc
from $Документ.ЗаявкаПокупателя Док (nolock)
left join _1sjourn j (nolock) on j.iddoc = Док.iddoc
left join $Справочник.Договоры Договоры (nolock) on Договоры.id = $Док.Договор
where $Док.Договор != $ПустойИД
and Договоры.id is null

(18) Недостаточная проверка. С одним и тем же iddoc могут быть документы разных видов. Как я понимаю, нужно еще учитывать IDDOCDEF. Ну и ХХХ как-нибудь бы автоматически развернуть.

Попробовал вот так, но ничего не выдало. Или таки нет плохой ссылки, или я ошибся в запросе:
DECLARE @TableName char(32)
DECLARE @IDDOCDEF char(32)
DECLARE @query nchar(1000)
DECLARE TablesList CURSOR FOR SELECT name FROM sysobjects WHERE type='U' and name like 'DH%'
OPEN TablesList
FETCH NEXT FROM TablesList INTO @TableName WHILE @@FETCH_STATUS=0 BEGIN
  set @IDDOCDEF = SUBSTRING(@TableName,3,30)
  print 'Check documents ID '+@IDDOCDEF
  set @query = 'select * from _1sjourn j (nolock) full join dh'+@IDDOCDEF+' dh(nolock) on dh.iddoc = j.iddoc where (dh.iddoc is null or j.iddoc is null) and IDDOCDEF='+@IDDOCDEF
  exec sp_executesql @query OUTPUT
  FETCH NEXT FROM TablesList INTO @TableName
END
CLOSE TablesList
DEALLOCATE TablesList

(20) " С одним и тем же iddoc могут быть документы разных видов"
Нет, не могут. iddoc уникален во все ИБ

(21) запрос вполне годный. значить нет нарушений

Наверное в (18) нужно так:
select *
from _1sjourn j (nolock)
full join dhХХХ dh(nolock) on dh.iddoc = j.iddoc
where (dh.iddoc is null or j.iddoc is null) and j.iddocdef = ХХХ
иначе выкатывает, как я понимаю, кучу документов из других dh
(23) Если запрос годный и нет нарушений, тогда возвращается вопрос, с которого началось - причина проблемы.

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

(23) Может подскажешь, как в моём запросе в (21) выводить только результаты с отклонениями. А то вываливает в management studio кучу "пустых" результатов запросов.
(25) Индексы перестраиваются регулярно.

(26) в запросе в (21) у тебя итак выводятся только записи, iddoc которых нет либо в dh либо в journ. Все Ок. Если куча пустых результатов, значит и нет проблемных записей.

(24) "иначе выкатывает, как я понимаю, кучу документов из других dh "
да, совершенно верно, нужно условие j.iddocdef = ХХХ

(27) Вот хочется, что бы пустые результаты не выводились. А только те, в которых строки есть.
Может кому понадобится запрос, проверяющий правильность ссылок между журналом и шапкой/таблицей документов:

DECLARE @TableName char(32)
DECLARE @IDDOCDEF char(32)
DECLARE @query nchar(1000)
DECLARE TablesList CURSOR FOR SELECT name FROM sysobjects WHERE type='U' and (name like 'DH%' or name like 'DT%')
OPEN TablesList
FETCH NEXT FROM TablesList INTO @TableName WHILE @@FETCH_STATUS=0 BEGIN
  set @IDDOCDEF = SUBSTRING(@TableName,3,30)
  if LEFT(@TableName,2) = 'DH'
    set @query = 'select ''DH'+@IDDOCDEF+''' as DocTable, j.iddoc, j.docno, CAST(LEFT(j.DATE_TIME_IDDOC, 8) as DateTime) as docdate from _1sjourn j (nolock) full join dh'+@IDDOCDEF+' dh(nolock) on dh.iddoc = j.iddoc where (dh.iddoc is null or j.iddoc is null) and j.iddocdef='+@IDDOCDEF
  else
    set @query = 'select ''DT'+@IDDOCDEF+''' as DocTable, j.iddoc, j.docno, CAST(LEFT(j.DATE_TIME_IDDOC, 8) as DateTime) as docdate from _1sjourn j (nolock) full join dt'+@IDDOCDEF+' dt(nolock) on dt.iddoc = j.iddoc where (j.iddoc is null) and j.iddocdef='+@IDDOCDEF
  exec sp_executesql @query OUTPUT
  FETCH NEXT FROM TablesList INTO @TableName
END
CLOSE TablesList
DEALLOCATE TablesList

(26) Ну тогда лови попыткой-исклением, почему и когда у тебя Договор пустой...

Может пустой, может не пустой... Пустое значение правильного типа такую проблему вызывать не может.
Однажды у меня был похожий глюк, оказалось, причина в том, что идентификатор документа, приписанный в 1sjourn к одному виду документов, на самом деле в DH/DT принадлежал к другому виду. В отчетах представление документа было "счет-фактура", а из журнала открывалась заявка с проблемами, похожими на (0).
Но сейчас подобных проблем не обнаруживается. Другая, видно, причина.