Доброго всем дня, вечера или ночи и т.д.
1С 7.7 своя 27 релиз SQL. База крутится на SQL сервер 2005, размер базы 30 гигов. УРБД
Есть документ выписка в таб. части этого документа есть субконто 2 для определенных счетов это договор основания. Стояла задача быстро выбрать по договору основания все выписки. Для этого был сделан отбор по этому полю с типом Справочник.Договора. И все было хорошо, пока по бизнес процессу при сведении реализации бухи перепроводили все выписки за месяц, но начался процесс оптимизации который привел к сокращению «не нужной» операции. В результате часть выписок начала выпадать из отбора, проблему решает перепроведение «не послушной» выписки.
Была сделана попытка перевести алгоритм на прямой запрос. В этом случае в отбор попадали все выписки, но время которое на это тратилось превышало в разы типовой алгоритм, что привело к неприемлемости данного варианта. В результате была написана обработка, которая выбирала выписки прямым запросом и типовым алгоритм находил не попадающие выписки и пересохранял их. Причем пересохранение по Записать() не давало нужных результатов. Была обнаружена закономерность, что при изменении таб. части и сохранении, выписка возвращалась в отбор (перепроводить выписки нельзя). Пути решения понятны: нужно попробовать выполнить типовой отбор профайлером и посмотреть как выполняется запрос, после этого с оптимизировать свой или оставить обработку проверки на ночь, она будет автоматом все выравнивать. Но это борьба с последствиями, а мне нужно понять причину и попытаться исправить её.
Мои предположения: Видимо при первичной записи выписки не записывается какое-то поле, либо оно слетает в момент обмена данными по УРБД или по каким-то другим причинам.
Суть вопроса: Что это за поле? И если кто-то сталкивался, то как можно решить проблему?

Для справки: Типовой отбор по выписки строился по следующей конструкции:

SELECT ВыпискаСтроки.IDDOC [ТекущийДокумент $Документ.Выписка]
_1SJOURN AS Журнал
INNER JOIN
$Справочник.Договора as Договора ON Договора.ID = IDДоговора
INNER JOIN
_1SCRDOC AS Отбор ON Отбор.CHILDID = Журнал.IDDOC AND
Отбор. MDID = $ГрафаОтбора.ВыпискаДФА

В зависимости от того какой тип выписки, это субконто либо есть либо нет. Алгоритм аналогичен типовой бух справки. Изначально поле не типизировано, в зависимости от выбранного счета поле типизируется, то же самое и здесь. Для моих нужд все поля заполнены.
Конкретно перестали перепроводить документы выписок в конце месяца. Изначально выписки формируются автоматически при загрузке даннх из банк-клиента.
Я разобрал профайлором запрос примерно он выглядит вот так:
SELECT
Журнал.IDDOC [ТекущийДокумент $Документ.Выписка],
Журнал.DATE_TIME_IDDOC,Отбор.CHILD_DATE_TIME_IDDOC
FROM
_1SJOURN Журнал(NOLOCK INDEX=ACDATETIME)
INNER JOIN
_1SCRDOC Отбор (NOLOCK INDEX=Parent)
ON
Отбор.CHILD_DATE_TIME_IDDOC = Журнал.DATE_TIME_IDDOC AND
Отбор. MDID = 45455 AND
Отбор.ParentVal = 'B1 13Z DHZRN2 '
AND Отбор.CHILD_DATE_TIME_IDDOC>='20100801' and Отбор.CHILD_DATE_TIME_IDDOC<='20100831 863990001 0 '

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

Как я говорил значения самих отборов тут не причем, проблема в отличии времени в таблице [_1SJOURN] и [_1SCRDOC]

Вот пример документа не попадает в отбор. выделено время:

[_1SJOURN]
1719059 186 12SUYRN2 6415 53 20101013 75IMA8 12SUYRN2


а это мой отбор он содержит первичное время создания, хотя документ уже был проведен и имеет другое время. Думаю что проблема в функции Провести() и Записать() интерактивное проведение и запись отличаются от ссылочного.
[_1SCRDOC]
11163525 45455 B1 13Z BWKOMS 20101013 CB604W 12SUYRN2 12SUYRN2 1

Буду думать как побороть.

Спасибо, за ответы.
Нашли причину, мои хлопцы разработали систему присвоения уникальности времени выпискам, выписки разного вида присваивается время всегда увеличенное на 1 сек, в рамках всех ИБ. Для ускорения процесса, был использован свой алгоритм изменения времени, но они забыли обновлять время отборов, что и привело к таким последтсвиям.
|BEGIN TRANSACTION TIME
|
|UPDATE _1SJOURN
| SET DATE_TIME_IDDOC = '"+ИДДокВремя+"'
|WHERE (IDDOC = :ТекДок)
|
|UPDATE _1SOPER
| SET DATE_TIME_DOCID = '"+ИДДокВремя+"'
|WHERE (DOCID = :ТекДок)
|
//это сделать забыли
|UPDATE _1SCRDOC
| SET CHILD_DATE_TIME_IDDOC = '"+ИДДокВремя+"'
|WHERE (CHILDID = :ТекДок)
|
|COMMIT TRANSACTION TIME

В бухгалтерской базе работает около 40 человек. Вообще у нас 4 бухгалтерских базы, одна из них посажена на отдельный инстанс SQL с ограниченным объемом памяти и лежит она на других винтах, в ней сводится реализация. Одна основная рабочая и 2 еще на всякий случай, если вдруг что-то умрет или потребуется срочно для каких либо больших операций+15 региональных баз по всей стране. Но проблема в том что количество ресурсоёмких запросов увеличивается с каждым годом. Мы лизинговая компания и учет приходится вести за всю жизнь договора лизинга максимальное время 7 лет. А так как изначально весь учет был построен на счетах и часть архитектуры было заложено коряво мы занимаемся оптимизацией путем перестроения запросов на прямые, выноса часто используемых данных в другую информационную систему и т.д. У нас есть так называемый "портал" написан на асп, база SQL к нему есть веб интерфейс со всех регионов часть функционала вынесено туда и и каждая региональная база 1С не может работать без доступа к порталу, это даёт нам неограниченные возможности разработки. Перенося часть функционала в базу портала мы используем 1С как клиента, причем никто фактически и не видит что происходит подмена места хранения данных, но существенно снижает время обменов при этом изменения сделанный к примеру в Питере, мгновенно видно в базе Владивостока. В дальнейшем планируется перевести весь управленческий учет на портал, а в 1С оставить только одну бухгалтерскую часть, при этом сократить количеств пользователей 1С до бухгалтеров. Но пока это только далёкие планы и до этого нам еще всем пахать и пахать.