Ломается таблица Platved

[s2176]

Добрый день!
У нас возникла проблема. Ломается таблица Platved. Причем ломается только, когда выбираю одно конкретное подразделение.
Т.е., создаю в "Кассе" ведомость с нуля, в шапке ведомости выбираю это подразделение, пытаюсь начать выбирать людей, как сразу выдается ошибка: "Ошибка ввода-вывода. Возможно нарушена целостность файла BTRIEVE. Код ошибки 2. Таблица 9044" и дальше еще куча сообщений об ошибках (с кодом 326). Решила занести запись просто через Суппорт, и обнаружила, что, если я сначала заполню поле PRIZDEL (поставлю 1), то мне удается в поле CEX завести nrec проблемного подразделения, а если PRIZDEL=0, то при попытке заполнить CEX и выйти из записи сразу возникает все та же ошибка.
С другими подразделения все работает нормально.
Подскажите, в чем проблема?

[edward_K]

2 табла разрушена. и похоже только индексы. Лечите таблу доступными способами. за 2 гига не переваливала?

[s2176]

нет, до 2Г еще далеко. Но лечение помогает только до тех пор, пока я опять не попытаюсь создать ведомость для этого подразделения. Мы уже создали новое подразделение, перевели в него всех сотрудников из этого злополучного подразделения. Теперь таблица не ломается, но хочется понять, что такое могло произойти с этим подразделением, точнее его nrec'ом? Почему оно попало в "черный список"? Ведь Гал-ке не нравится именно сочетание этих 2-х полей: конкретного значения cex и prizdel=0

[m0p3e]

А журнал по таблице ведется?

[s2176]

Журнал ведется, но мы ничего криминального не увидели.
Эдвард прав, полечили - помогло. Мы и до этого пробовали лечение, но при этом терялось много ведомостей, поэтому пошли другим путем, как оказалось, не правильным. Мы подкладывали таблицу из архива, но, видимо, уже и она имела поврежденный индекс, хотя сервис btrieve не показывал в ней ошибки, писал, что все Ок, и мы ему верили.

[m0p3e]

Есть один нюанс на первасиве при ведении журнализации. Галактика начинает материться на некую таблицу. Лечение таблицы помогает на некоторое время, но потом ошибка возникает вновь. Виновата при этом сбойная запись в журнале.

[s2176]

А как увидель эту сбойную запись? Она связана с поломавшейся таблицей?

[Алексей]

а может журнал очистить, напрочь?

[s2176]

Если повторится ошибка, то придется, но не хочется(( вдруг придется что-нибудь искать.
Мы, собственно, и так его чистим раз в месяц, когда закрываем месяц в ЗП.

[m0p3e]

Честно говоря когда, с таким сталкивался (3 раза) времени на изучение журнала небыло. Поэтому просто журнал убивался, либо заменялся архивным.

[s2176]

А как же вы вычислили, что виноват в поломке именно журнал???

[m0p3e]

Не помню уже...
Но мучались очень долго. Подумать на журнал при данной ошибке очень сложно.

[edward_K]

при падении системы на первасиве (типа вырубание сервака) журнад падает в первую очередь - поскольку туда постоянно что то пишется. Если ошибка 2 вылазит при записи в любые таблы то это 100% он. Вряди сей случай завязан на добалении записи в конкретную таблу да еще и по условию.

[m0p3e]

На серваках NetWare проблемы с базой на физическом уровне не испытывили ни разу. Даже после отключения питания при дохлом упсе. На похожие по симптомам ошибки попадали на виндусовом серванте с бетривом. При этом никаких отключений питания и прочего небыло. Похоже было именно на постоянное умирание одной определенной таблицы. Проблема была в журнале. Повезло наверное...
В этом смысле MSSQL и Oracle базы намного стабильнее. Шуршат себе... Есть не просят... В оракловой при этом не плодятся почкованием хранимые процедуры...

Собственно речь шла о том, что не всегда сообщение о дохлой табле под первасивом означает проблемы в самой табле. Иногда это может быть и журнал.

[edward_K]