В БД ЭК накопилось много записей, удаленных логически. Попробовала реорганизовать файл документов (АРМ Администратор). В результате получила 80 документов, удаленных физически (исходный файл содержал 47 логически удаленных и 19 физически удаленных)!?
Выписала все удаленные (номера MFN), восстановила файл документов из архива. Необходимо было разобраться, почему на 14 записей больше оказались удаленными. Ситуация очень опасная, это книги, инвентарный учет, исчезнут, а обнаружить пропажу могут через полгода или...
Чтобы определить, почему записи были удалены, каждую запись из 14 отдельно обрабатывала глобальной корректировкой (самой простой, меняла дату) с ФЛК (флажок включен). Запись была удалена логически. Если ее восстановить, а потом попытаться сохранить, то появляется сообщение:"Дублетный шифр документа...".
Исправить просто: удалить содержимое поля и сохранить запись, шифр документа формируется заново, запись восстановлена.
Все проделано в АРМ Каталогизатор.
ВОПРОСЫ:
1) Почему оказалась возможной такая опасная ситуация?
2) Как производится проверка на дублетный шифр документа?
3) Почему только при помощи глобальной корректировки была обнаружена дублетность? Кстати, над БД ЭК было выполнено несколько глобальных корректировок ранее, а записи эти не были удалены логически.

Записи могут быть потеряны и при копировании и восстановлении файла документов (с этим случаем имела дело на прошлой неделе), перед глобальной корректировкой БД ЭК (все документов) скопировала файл документов, а после сбоя восстановила и была просто удивлена результатом, вместо 17 физически удаленных увидела 170!
К счастью, для перестраховки другими способами было создано еще 2 архива и данные были восстановлены. Сейчас это можно объяснить.

Вы можете прислать исходное состояние БД (MST и XRF - в том положении, когда 47 логически удаленных и 19 физически)?
Кстати не понял, что это значит...
"Чтобы определить, почему записи были удалены, каждую запись из 14 отдельно обрабатывала глобальной корректировкой (самой простой, меняла дату) с ФЛК (флажок включен)."

Старалась подробно изложить ситуацию, поясняю еще

> Кстати не понял, что это значит...
> "Чтобы определить, почему записи были удалены, каждую запись
> из 14 отдельно обрабатывала глобальной корректировкой (самой
> простой, меняла дату) с ФЛК (флажок включен)."

разбиралась с каждой отдельной записью.

После глобальной корректировки с ФЛК, запись логически удалялась, а когда ее восстанавливала и пыталась сохранить, то получала сообщение - "Дублетный шифр документа...", т.е. причину ее исчезновения при реактуализации. Это дублетные шифры документов.
Сейчас, когда дублетные шифры отсутствуют, реактуализация прошла нормально, сумма удаленных записей правильная до и после реактуализации.
В БД 10500 записей всего. Смысла присылать записи не вижу, я очень подробно и объективно описала ситуацию. Остались они только в архиве ежедневном. Я сохраняла 5 файлов БД (к счастью, догадалась их сохранить перед реактуализацией). Их уже нет, на их месте актуальная БД.

Во-первых, что такое "реактуализация"? Если речь идет о реорганизации файла документов - то этот процесс не имеет НИКАКОГО отношения к содержанию БД (т.е. к таким вещам как дублетность и прочее) Таким образом Ваша ситуация осталась АБСОЛЮТНО не понятной...

Александр Иосифович, конечно, реорганизация файла документов (опечатка).

Меня результат реорганизации файла документов просто изумил, когда я увидела 80 удаленных физически, вместо 66.

Эту ситуацию Вы можете смоделировать и посмотреть, все описано подробно.

Если выполнять реорганизацию файла документов, то обязательно контроль до и после.

> Сейчас, когда дублетные шифры отсутствуют, реактуализация прошла нормально, сумма удаленных записей правильная до и после реактуализации.

Александр Иосифович, а гланое, мои вопросы?

>ВОПРОСЫ:
>1) Почему оказалась возможной такая опасная ситуация?
>2) Как производится проверка на дублетный шифр документа?
>3) Почему только при помощи глобальной корректировки была обнаружена дублетность? Кстати, над БД ЭК было выполнено несколько глобальных корректировок ранее, а записи эти не были удалены логически.

Вашу ситуацию я не могу смоделировать, потому что я ее НЕ ПОНИМАЮ. Еще раз повторяю - между реорганизацией файла документов и дублетностью документов НЕТ НИКАКОЙ СВЯЗИ.
Что касается дублетности - она проверяется всякий раз, когда выполняется ФЛК записи в целом (dbnflc.pft), а он выполняется обязательно при СОХРАНЕНИИ записи в АРМе Каталогизатор, при ИМПОРТЕ и при ГЛОБАЛЬНОЙ (если ее явно не отменять)

Тогда конкретно вопрос:

Как производится проверка на дублетный шифр документа в БД ЭК?
В том, что произошло, была угроза потери данных!

Может быть имеет смысл сделать кнопку или команду для проверки на дублетный шифр документа в БД перед реорганизацией файла документов (сжатия БД) и соответственно перед копированием файла документов с целью потом восстановить (в случае разрушения БД), чтобы избежать подобной ситуации?

Извините, я не могу продолжать этот диалог - поскольку Вы меня абсолютно не понимаете...
Я говорю о том, что НЕТ НИКАКОЙ СВЯЗИ МЕЖДУ РЕОРГАНИЗАЦИЕЙ ФАЙЛА ДОКУМЕНТОВ и ДУБЛЕНОСТЬЮ ШИФРА ДОКУМЕНТОВ, а Вы предлагаете "Может быть имеет смысл сделать кнопку или команду для проверки на дублетный шифр документа в БД перед реорганизацией файла документов" - ну что это такое???

Alio писал(а):

> Я говорю о том, что НЕТ НИКАКОЙ СВЯЗИ МЕЖДУ РЕОРГАНИЗАЦИЕЙ
> ФАЙЛА ДОКУМЕНТОВ и ДУБЛЕНОСТЬЮ ШИФРА ДОКУМЕНТОВ, а Вы
> предлагаете "Может быть имеет смысл сделать кнопку или команду
> для проверки на дублетный шифр документа в БД перед
> реорганизацией файла документов" - ну что это такое???

Извините, Александр Иосифович, я Вас понимаю.
Но были удалены физически записи, у которых был ДУБЛЕТНЫЙ ШИФР ДОКУМЕНТА в БД. Их не оказалось в БД после реорганизации файла документов.
Значит есть какая-то связь. Как реорганизуется файл документа? Может быть проверяется шифр документа в БД? Если он дублет, то что?

Реорганизация ФД - это последовательное выполение двух режимов: копировать файл документов и восстановить файл документов.
Там нет никакой проверки.
Вы просто вышлите АИ базу ДО потери и проблема разрешиться...

Уважаемая Галина Николаевна!

Мы не можем повторить Вашу ситуацию на тестовой БД.
Если Вам не трудно, вышлите нам Вашу базу данных.
Обязуемся удалить ее сразу после проверки!

Файлы БД в rar-архиве занимают 15 мб.
Ваше предложение - как выслать?
Есть ftp-сервер у Вас, куда можно положить?

Вы можете положить на свой ftp?

У меня нет ftp и никогда не было.

Загляните, пожалуйста, на форуме: АРМ Администратор - "Рекомендуемые настройки ФС" - Станислав Когут, 30.03.2005 13:59
Стоит посмотреть, хоть это не клиент-сервер, а вдруг...

Я не системный администратор и не специалист по сетям, но стоит ли присылать файлы документов. Может быть надо смотреть все, в совокупности, как есть?

Здравствуйте.
Чтобы не создавать новую ветку, напишу здесь.
В БД Музей изредка появляются дублетные шифры. Заметили тогда, когда снова нужно было поработать с одной из дублетных записей.

Елена, КрЦНТИБ Красноярской ж.д.

LiLi написал(а):
-------------------------------------------------------
> Здравствуйте.
> Чтобы не создавать новую ветку, напишу здесь.
> В БД Музей изредка появляются дублетные шифры.
> Заметили тогда, когда снова нужно было поработать
> с одной из дублетных записей.


Autoin.gbl этой БД стандартный для БД ЭК? Шифр формируется как случайное 9-значное число с дефисом впереди?



Редактировано 1 раз. Последний раз 24.07.2017 14:44 пользователем Сорокина Лариса.

Практически стандартный, незначительные изменения были внесены. В частности шифр формируется иначе.
Ранее он формировался только как случайное число, позже добавила символы в зависимости от держателя. Т.к. дублетность встречалась чаще, причем только с конкретных рабочих станций, где нестабильная сеть.
ADD
903
XXXXXXXXXXXXXXXXXXX
if a(v903) then if v920='J' then v200^a.1,&unifor('R') else if v902^b:'Красноярск' then if v902^a:'спорт' then 'S' else 'K'fi, fi,if v902^b:'Абакан' then 'A' fi,if v902^b:'Боготол' then 'B' fi'-'&unifor('R') fi fi/
XXXXXXXXXXXXXXXXXXX

Елена, КрЦНТИБ Красноярской ж.д.

LiLi написал(а):
-------------------------------------------------------
> Практически стандартный, незначительные изменения
> были внесены. В частности шифр формируется иначе.
> Ранее он формировался только как случайное число,
> позже добавила символы в зависимости от держателя.
> Т.к. дублетность встречалась чаще, причем только с
> конкретных рабочих станций, где нестабильная
> сеть.
> ADD
> 903
> XXXXXXXXXXXXXXXXXXX
> if a(v903) then if v920='J' then
> v200^a.1,&unifor('R') else if v902^b:'Красноярск'
> then if v902^a:'спорт' then 'S' else 'K'fi, fi,if
> v902^b:'Абакан' then 'A' fi,if v902^b:'Боготол'
> then 'B' fi'-'&unifor('R') fi fi/
> XXXXXXXXXXXXXXXXXXX


Попробуйте заменить &unifor('R') на &unifor('R9').

Спасибо. Попробую.

Елена, КрЦНТИБ Красноярской ж.д.