v7: Невосстановимая ошибка Базы Данных Код -4 Таблица: 1SENTRY #753234

Первый раз словил такую ошибку летом. Именно один день, именно документы реализации. Появляется при перезаписи/перепроведении документа РеализацияПродукции. При нажатии на Ок - программа вылетает. Помогало только монопольная переиндексация. Теперь ошибка зачастила. Конфигурация ПУБ 7.70.297 - перепиленная. Диск SSD. Диску на серваке 1,5 года. Что это? Умирает база или диск? Кто-нибудь сталкивался??

ЗиК на флэшке (каприз заказчика) так же точно умирала. Итог: восстановление данных капризным заказчиком из базы месячной давности. Причина - хранение данных на обычной флэшке, которая имеет ограниченное количество циклов записи/перезаписи.

1SENTRY - вроде проводки. Для начала: 1. Сделать копию. 2. Удалить индексные файлы. Похоже база мрет.

А как то можно где-то ну может в логах или еще где, узнать сколько циклов уже записано?

Щас сначала попробую в копии.

смарт для флешки?? найдешь делись.

На диске еще несколько баз 1с 8.2 крутятся. С ними проблем нет. Да и тут в 7.7 почему то только реализации мозги делают.

А какая операционка?

windows 2008 server Enterprise

Тогда количество открытых файлов не причем. Размеры самых больших файлов в базе?

RG15141.DBF - 165 mb Дальше на понижение 80 и ниже.

chkdsk ошибок не находит. Или для ССД этот инструмент не катит?

однако перебор. Максимальный размер dbf до 2 гигов, но это в сферическом вакууме. В реале на таких размерах начинаются глюки. Решение: Вариант 1 - переход на SQL. Будет медленнее, но стабильно. Вариант 2 - обрезка базы.

что тут гадать, переноси базу на жесткий диск и смотри - пробуй. Если траблы исчезнут  - стало-быть диск мрет, если нет - база зы по любому делай архивы

Максимальный размер ОДНОЙ! dbf до 2 гигов

я это и имел в виду.

Индексы падают. Доиграются потеряют данные.

на как-бы в ничего такого не наблюдается

Индексы падают. Доиграются - потеряют данные.

Ничего не понимаю. Вдруг ни с того ни с сего началось. Может быть сделать chkdsk /f Так?

Ок. Почему могут падать индексы?

Попробую сегодня из дома chkdsk /f. Ну и может вечерком сервер перезагружу. Больше года барабанит без перезагрузки)

диск проверить лишним никогда не будет. :)

А в с индексами что-то попробовать?

На серваке еще есть не ССД диск. На него конечно можно перекинуть, но мне кажется скорость рас в 100 упадет((

Если после удаления индексов и входа монопольно, ошибка сохраняется, то сыпется база. Здесь же похоже проблема именно в индексных файлах, а конкретно в размере файла 1SENTRY. ИМХО.

так после переиндексации,  ошибка пропадаеит и документ уже проводится.

удалить все cdx, зайти монопрольно, + проверить наличие пустой даты в проводках и операциях и в 1sjourn. + проверить, нет ли проводок с другой позицией, нежели в 1sjourn (это когда в 23.59.59 пихают сотни доков)

Погуглил. Скорее всего, ситуация типичная. Например, на соседнем форуме пишут, что наиболее вероятная проблема -  "Слишком много открытых файлов". База на компе с WinXP - у неё ограничение на количество одновременно открытых файлов. Нужно базу выносить на другую ОС. Также пишут, что нужно проверить физический носитель. И вообще, лучше для важных баз делать как минимум зеркало с пересылкой журнала транзакций.

1sjourn блокнотом открывать? И "+ проверить наличие пустой даты в проводках и операциях и в 1sjourn. + проверить, нет ли проводок с другой позицией, нежели в 1sjourn" Можно поподробнее как и чем сделать?

-> windows 2008 server Enterprise

любым DBF-viewer-ом, отсортировав по полю Даты.

Спс скачал. А пустую дату смотреть в графе date или sp26762?

date, просто нажми на заголовок (должно отсортировать)

В файлах 1sjourn и 1SENTRY - даты везде проставлены. А как сделать это? - "проверить, нет ли проводок с другой позицией, нежели в 1sjourn"

а в 1soper ?

Тоже везде есть.

проверить, чтобы time для связки docid - iddoc из 1sjourn совпадало

+ посмотреть, какие виды субконто у вас, нет ли там случаем... с типом строка, длиной 200 ?

Невкурю что с чем сравнивать Все субконто либо справочники, либо перечисления.

сравнить date+time+iddoc в 1sjourn с date+time+docid в 1sentry

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

Ну как, решилась проблема? Или нет?