Не совсем уверен, что сюда можно с этим вопросом - но я уже отчаялся почти :(

Имеем конфигурацию Континент:Страхование на базе стандартного предприятия под 1c v7.7 25 релиз. Версия в варианте для SQL. Объем данных сейчас за 7 лет - около 20GB (именно данных, не sql файлов). До недавнего времени все было нормально, но при очередной попытке пересчитать полностью бухитоги натолкнулись на ошибку:
Cannot insert duplicate key row in object '_1SBKTTL' with unique index 'PK_1SBKTTL'
Причем это на самом первом годе, где есть проводки.
Запуск MS SQL Profiler для отлова некорректной инструкции не помогает - ибо он просто не может, как оказалось, переверить такой объем - при открытии трэйса споткнулся минуте на 20-й (из 8 часов) трэйса с руганью на невозможность отобразить столько данных.
Повторный пересчет не помогает.
Найденный Скрипт поиска битых ссылок не помогает - он не находит никаких несоответствий.
Пробовал сделать непроведенными документы за год, на котором спотыкается - начал спотыкаться на следующем годе.
Пробовал удалять содержимое _1SBKTTL и _1SBKTTLC и пересчитать по новой - получил ошибку
SQL State: 42S02 Native: 208
Message: [Microsoft][ODBC SQL Server Driver][SQL Server] Invalid object name '#TMPPROVTBL'.
То есть не может создать временную таблицу, хотя места там для этого - вагон - несколько десятков гигабайт. Файлы баз данных на рост никак не ограничены.
При повторном рассчете опять ругается на индексы.
Пробовал проверять корректность индексов - проверка проходит нормально. Пробовал прибить индексы и создать заново - не помогло.
dbcc checkdb тоже отрабатывает нормально.
Попытка пересчитать итоги на 27 релизе 1с к успеху не привели.
Путем долгих мытарств нашел способ:
Откатил точку рассчет бухитогов на 1997 год. Сделал полный пересчет - все прошло нормально. Потом последовательно сделал установку точки рассчета бухитогов вплоть до 2007 года - все нормально.
Ради интереса попробовал опять сделать полный пересчет - опять обвалилась с руганью на индексы.
Вопрос - что это и как с этим теперь бороться?
Совершенно не прельщает использовать и в дальнейшем найденный мной способ, так как он требует значительного ручного вмешательства :(

2RedBird: бэкап естественно делается, да и вообще все эксперименты идут на копии базы. По поводу тестирования и исправления - битый номер, пробовал - тестирование шло НЕДЕЛЮ, потом надоело ждать - нереально.

Пробовал выгрузить в dbf - тоже не помогло, ибо 1с просто валится с ошибкой невозможности открыть zip файл. То есть она скидывает туда конфу, юзеров, потом очень долго шуршит, а вот данные положить не может - вероятно какие-то ограничения по объему у zip формата :(

2mlegkiy: Пробовал - яисто... Да и не отновсится это к делу... если бы были потерянные проводки, то оно бы валилось и при последовательном рассчете бухитогов - а так ведь не валится :(

2MLight: Работает потихоньку, не слишком быстро, конечно, но в целом терпимо. База оперативная. Правда 20gb это вместе с индексами.

2 MLight: а толку то? все равно эта операция в 3-4 раза более длительная, чем найденный мной способ рассчет БИ. разве что только попытаться все-таки ошибку в данных найти.

2 RedBird: про Линию Консультаций - у меня большие сомнения по этому поводу - ведь для воспроизведения ситуации им наверняка нужна будет моя база. А на это сами понимаете идти никак нельзя :(

2 MLight: тестирование идет очень долго - говорю же - неделю шло, потом терпение кончилось...
По поводу сюрдюка, etc мысль конечно, но пока хочется малой кровью отделаться ;)
По поводу УРБД надо обмозговать...

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

2 RedBird: Да, лицензионная. А что вы понимаете под "официальным" письмом?

Угу. Письмо ушло на приват ящик...

2 идиоты: пробовал уже... все чисто

2 AHDP: Вы правы во всех своих предположениях и PS :( Если что-то удастся накопать в вашей dbf выгрузке - буду очень рад услышать.

Нет, все чисто - дублей нет :(

ps: запрос можно проще написать
SELECT COUNT(NUMBER), DATE_TIME_DOCID
FROM _1SENTRY
GROUP BY NUMBER, DATE_TIME_DOCID
having count(number)>1

Да и как они там могли в sql базе появится?
Там же кластерный индекс по [DATE_TIME_DOCID],[NUMBER],[CORNO].