Добрый день.
Ситуация следующая:
База самописная на основе ПУБ 77. Файловый режим (вся база весит около 6 ГБ, знаю, что нужен SQL).
Кодовая страница (+ текущая системная установка).
Периодичность хранения остатков - месяц.

ОСВ по 51 счету (и карточка счета) показывает неверные сальдо и обороты за день.
Пример:
За период с 01.09 по 12.09 сальдо и обороты отображаются верно.
Строю отчет с 12.09 по 12.09 - неверно.
С 1 по 13 - верно.
С 13 по 13 - неверно.
и т.д.
(со 2 по любое число тоже неверно, и т.д.)

При неверном отображении сальдо по счету отображается отрицательные миллионы. А верные остатки порядка десятков тысяч.

Пробовал:
-ТиИ со всеми включенными галочками (кроме сжатия таблиц).
-Полный пересчет бух итогов
-Удаление файлов dbf и cdx(accsel,1SBKTTL,1SBKTTLC,1ssbsel) с последующим полным пересчетом бух итогов.
-Распровел все документы с 31.08. Провел одно поступление ДС от 12.09 для контроля. С 1 по 12 отчет верный. С 12 по 12 - неверный (т.е. ничего не изменилось)
-Искал в файле 1SENTRY через viewer зависшие проводки по 51 счету (т.е. без существующих документов). Нашел только бух.операцию, введеную вручную от 31.08.12. Удалил ее из файла 1SENTRY, удалил операцию из 1С, пересчитал бух итоги в режиме предприятия - не помогло.

Сейчас:
Анализирую архивы с 01.09 на каждый день. Хочу локализовать день, с которого все сбилось.

Прошу советов и рекомендаций.

1. анализируй архивы
2. переходи на 8ку

Определил по архивам, что началось все с 24.09.12.
Т.е. архив за 23.09 нормально формирует ОСВ.

Удалил файл 1SENTRY:
ОСВ формируется 01.09 по любое число месяца верно.
Начиная со 2-го - нет проводок (вроде все логично).
Сформировал заново проводки за сентябрь регламентным документом "Формирование проводок" - ничего не изменилось.

Ищу дальше.

1) Удалил все файлы cdx, восстановил монопольно - не помогло
2) Удалил файл 1sjourn - не помогло
3) Загрузка - выгрузка не помогла, хотя база стала на 2 гига меньше весить

Ищу дальше

сверни базу

(3) зачем ты файлы удаляеншь? просто сделай пересчет итогов.

1SBKTTLC.dbf скока весит?

+(6) 1SBKTTLC = 1SBKTTL

Если 1SBKTTLC, 1SBKTTL больше 1Гб, то все шаманства с удалением/пересчетом/передвижкой взад-вперед итогов помогут ... или ненадолго, или совсем не помогут)).. можешь не рыть архивы, и не догонять день "когда все сбилось". "С 01 по 01 - верно, с 01 по 02 - красно" - до боли знакомая тема)))

два варианта:
1. SQL
2. резать базу

ну еще альтернативный вариант: http://infostart.ru/public/15211/

Но, имхо, если базе светит жить долго, то чем быстрее переберешься на СКЛЬ + прямые запросы, тем меньше геморроя наживешь))

(8) Это самые популярные грабли.

Всем спасибо, проблема решилась.
Проблемную базу загрузили в SQL - все итоги сошлись, все работает.

(10) Что сказали юзеры по поводу скорости работы на СКЛь?)))