в АРМе Каталогизатор в БД Статьи непоказывает несколько записей.При поиске они находятся,но при переходе на этот искомый MFN выдает ошибку Grit out the range of index(вроде бы так).Дальше при диагностике файла в Администраторе выдавало ошибку уже не помню какую(было не соответсвие МФН) вообщем я по запарке нажал Восстановить файл документов и выбрал файл ХХХ.bkp в папке workdir.Кароче теперь осталось 20% от всего.Нельзя ли как то вернуть предыдущее состояние БД.В голову приходит только Восстановление системы Win

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

Вообщем назревает скандал,восстановление ОС не помогло:( :)o.Теперь обязательно буду архивировать.В нашем деле без ошибок никак,все добивается путем проб и ошибок так что остальным начинающим ирбисоводам советую первым делом организовать архивацию данных

так у вас никаких прошлых вариантов базы не осталось? ТОлько вот тот, с которого удалось восстановить "20% от всего"? Подумайте, может вы копировали ирбис себе для каких-то экспериментов и там база осталась

У нас случилась подобная ситуация, подскажите ,пожалуйста,как такое
можно избежать в будущем. У нас ИРБИС64 ,при сохранении баз Я никогда не интересовалась размером полученного файла.Тем более не представляю как можно заглянуть в iso файл.
А когда для удаления 'дырок' сделала опустошение-импорт, увидела что там всего 11000 и размер файла этого в 3 раза меньше .Поставив более старую копию я угробила отделу 3 дня работы. Может ли эта ситуация с некорректной работой антивируса или вирусной атакой . И как после сохранения можно убедиться что все данные скопированы...

Цитата:

Tamara
Tamara написал(а):
-------------------------------------------------------
> У нас случилась подобная ситуация

Уточните что именно у Вас произошло.

Цитата:

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

Если копирование закончилось не ошибкой, значит скопировал все. Делайте копирование каждый день и файлы бекапов не перезаписывайте.
Например я сделал пакетное задание, которое делает копии всех нужных мне БД в папку. Добавил АРМ Администратора в ini-файле которого прописано это задание и его запускаю обычным планировщиком заданий виндовс. Потом, через 10 мин. после выполнения пакетного задания планировщиком заданий запускается батник, он создает папку, у которой именем служит дата, и копирует в эту папку файлы с расширением .bkp и еще он в текстовый файл скидывает сообщение в случаи успеха или ошибки.
Я уже где-то здесь его выкладывал, но если что вот еще раз.

Там единственное что нужно в строке
md D:\BackupIrbis\%date:~6,4%.%date:~3,2%.%date:~0,2%\
Кусочек D:\BackupIrbis\ заменить на свой путь, это путь где будет создаваться папка с именем текущей даты и в нее же будет копироваться рез. копии БД.

Еще там есть
xcopy D:\AdminFiles\backupirbistemp\*.bkp D:\BackupIrbis\%date:~6,4%.%date:~3,2%.%date:~0,2%\ /y /e /z /c /h
Тут D:\AdminFiles\backupirbistemp\ заменить на путь, куда пакетное задание Ирбиса складывает файлы резервных копий
А D:\BackupIrbis\ заменить на путь, где располагается папка, в которой предыдущая комманда создала папку с именем даты, т.е. этот путь совпадает с тем что идет после md

Лог копирования будет создан в папке, где будет находится сам батник, при каждом новом копировании в конец дописываться дата и успех или ошибка копирования. Типа так:

Цитата:

Дата и время копирования:
12.03.2010
18:10
*******************************
...Creating folder for backup. Please wait...
...Copying files. Please wait...
Резервное копирование данных завершилось успешно. Можно сохранить на диск.
*******************************
Дата и время копирования:
15.03.2010
18:10
*******************************
...Creating folder for backup. Please wait...
...Copying files. Please wait...
Резервное копирование данных завершилось успешно. Можно сохранить на диск.

Здравствуйте
Я копирование баз делаю по одной схеме <export в файл> , в конце процесса получаю сообщение , что копирование завершено и число сохраненных записей. Сделав export базы 37000 записей , на сообщение что сохранены 11000 записей не обратила внимание ,т.к. процесс не прерывала и зависаний не наблюдала. Сейчас я готова проверять каждый iso файл и хотела спросить Вас можно ли в блокноте его расшифровать <допустим увидеть последнюю запись>.

Tamara написал(а):
-------------------------------------------------------
> Здравствуйте
> Я копирование баз делаю по одной схеме , в конце
> процесса получаю сообщение , что копирование
> завершено и число сохраненных записей.
Этот процесс называется ЭКСПОРТ, а не копирование (копирование - это режим КОПИРОВАТЬ ФАЙЛ ДОКУМЕНТОВ (если Вы будете путать эти режимы, то Вас трудно будет понять)
И кстатти, непонятно - почему для сохранения БД Вы используете именно ЭКСПОРТ, а не КОПИРОВАНИЕ...


Сделав
> export базы 37000 записей , на сообщение что
> сохранены 11000 записей не обратила внимание ,т.к.
> процесс не прерывала и зависаний не наблюдала.
Если при экспорте не применяется ТВП переформатирования и нет УДАЛЕННЫХ (физически и логически) записей, то экспортируется строго столько записей, сколько их в БД - за исключением ПУСТЫХ записей. Никаких иных вариантов.

Tamara
Можно и Iso, там в папке с Ирбисом есть программа IsoEditor, и его можно с администратора запустить.
Но в нем не удобно редактировать по сравнению с текстовым форматом. При экспорте там можно указать чтобы выгружались записи не в ISO а в текст.
Только после редактирования проверяйте на тестовом Ирбисе, нельзя на реальном.

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

Alio написал(а):
-------------------------------------------------------
> Этот процесс называется ЭКСПОРТ, а не копирование
> (копирование - это режим КОПИРОВАТЬ ФАЙЛ
> ДОКУМЕНТОВ (если Вы будете путать эти режимы, то
> Вас трудно будет понять)
> И кстатти, непонятно - почему для сохранения БД Вы
> используете именно ЭКСПОРТ, а не КОПИРОВАНИЕ...
>
Я думала ,что главной моей обязанностью админа есть функция ежедневного сохранения баз в файлах iso на флэшке или диске , что только в данном случае при сбое программы потери данных можно снизить до минимума.
КОПИРОВАНИЕ я понимаю как создание ещё одной БД -копии рабочей. Но ,поскольку они 'живут' на одном сервере, то и 'погибать'
будут вместе <проблемы на сервере у нас были когда 'слетал' windows ,
и в сезон вирусных атак>. Когда сервер- уязвимое место, ЭКСПОРТ
наверное будет актуальней...

Tamara написал(а):
-------------------------------------------------------
> Alio написал(а):
> --------------------------------------------------
> -----
> > Этот процесс называется ЭКСПОРТ, а не
> копирование
> > (копирование - это режим КОПИРОВАТЬ ФАЙЛ
> > ДОКУМЕНТОВ (если Вы будете путать эти режимы,
> то
> > Вас трудно будет понять)
> > И кстатти, непонятно - почему для сохранения БД
> Вы
> > используете именно ЭКСПОРТ, а не КОПИРОВАНИЕ...
> >
> Я думала ,что главной моей обязанностью админа
> есть функция ежедневного сохранения баз в файлах
> iso на флэшке или диске , что только в данном
> случае при сбое программы потери данных можно
> снизить до минимума.
> КОПИРОВАНИЕ я понимаю как создание ещё одной БД
> -копии рабочей.
Ничего подобного. КОПИРОВАТЬ ФАЙЛ ДОКУМЕНТОВ - это создание ОДНОГО файла, гарантирующего полное восстановление всей БД. И этот файл, как и экспортную выгрузку, Вы можете сохранить и спрятать куда угодно.

Tamara
На мой взгляд наоборот при экспорте больше вероятно потерять данные.
А сохранять какая разница куда, в пакетном задании можно выставить чтобы копировалось в сеть на другой комп или флешку или дополнительный жесткий диск. И батник я прикрепил, можно рез. коп. делать прямо на сервер а в батнике путь в сетевую папку прописать или на флешку или на доп. жесткий диск.



Редактировано 2 раз. Последний раз 16.03.2010 17:33 пользователем -AND-.

Ещё одно замечание: если производите экспорт записей для последующего их импорта в Ирбис, то экспорт лучше делать в текстовом формате, кодировка UTF-8. ISO-формат имеет ряд ограничений...

Да, точно. Помню как-то с маленькой БД(400 с хвостиком записей) был у меня случай, когда импорт заканчивался ошибкой. Импорт из ISO. Тогда просто попробовал экспорт/импорт в текстовом формате и все отлично импортировалось.

спасибо большое ,Вы меня сразили полностью..
Если можно место
пакетное задание, которое делает копии всех нужных мне БД в папку. Добавил АРМ Администратора в ini-файле которого прописано это задание и его запускаю обычным планировщиком заданий виндовс.
распишите подробнее....
Я в Администраторе сделала копирование файла и получила BD.bkp.
После запускается батник, он создает папку, у которой именем служит дата, и копирует в эту папку файлы с расширением .bkp и еще он в текстовый файл скидывает сообщение в случаи успеха или ошибки.
получила пустую папку BackupIrbis\2010.03.18\ и log_backup.txt с описанием ошибки..
Что я делаю не так???

Михайленко Илья написал(а):
-------------------------------------------------------
> Ещё одно замечание: если производите экспорт
> записей для последующего их импорта в Ирбис, то
> экспорт лучше делать в текстовом формате,
> кодировка UTF-8. ISO-формат имеет ряд
> ограничений...

Можно подробнее? А то раньше считал именно iso оптимален для сохранения записей при смене версий Ирбиса например...

Konstantinus написал(а):
-------------------------------------------------------
> Михайленко Илья написал(а):
> --------------------------------------------------
> -----
> > Ещё одно замечание: если производите экспорт
> > записей для последующего их импорта в Ирбис, то
> > экспорт лучше делать в текстовом формате,
> > кодировка UTF-8. ISO-формат имеет ряд
> > ограничений...
>
> Можно подробнее? А то раньше считал именно iso
> оптимален для сохранения записей при смене версий
> Ирбиса например...


Формат iso работает только с метками до 999. Все остальные он просто сохраняет в поле кажется 998. Соответственно, если у вас в Ирбисе были свои поля с метками больше 999, то вы их не сможете импортировать в другой Ирбис.
Вроде бы как есть ограничения по размеру записи и количеству повторений полей. На Ирбис 32 это распространяется строго - запись со служебной информацией, а в формате iso это может быть до трети длинны записи, не должны привышать 32 кб. В текстовом формате меньше служебной информации, по этому остается больше места для записи информации (помним об ограничении в 32 кб). Но это проблема как бы почти исключительно для Ирбис 32.

У iso 2709 следующие ограничения:

Метка - до 999
Размер записи до 99999 байт
размер поля - до 9999 байт

А текстовый всех этих ограничений не имеет?

Не имеет...

При копировании БД обнаружила , что после восстановления записей большая часть полей бесследно исчезает(это касается только записей OJ-регистрация журналов.C ASP и PAZK проблем нет). Такой результат был при всех способах (копирование, экспорт-импорт, сохранение-восстановление).Вид одной записи до и после копирования прилагаю в файле..Где здесь проблема??

О каком КОПИРОВАНИИ идет речь?

Если речь идет о режимах АРМа Администратор - КОПИРОВАТЬ ФАЙЛ ДОКУМЕНТОВ и ВОССТАНОВИТЬ ФАЙЛ ДОКУМЕНТОВ - то никаких ПОТЕРЬ данных не может быть.

Если речь идет об ЭКСПОРТЕ/ИМПОРТЕ, то "потери", о которых Вы говорите, могут быть связаны с использованием ТВП ПЕРЕФОРМАТИРОВАНИЯ или АВТОВВОДА, т.е. если ПРИ ЭКСПОРТЕ/ИМПОРТЕ Вы НЕ БУДЕТЕ использовать какие-либо ТВП ПЕРЕФОРМАТИРОВАНИЯ и будете отключать АВТОВВОД при импорте, то никаких" потерь" не будет.

У вас НИЧЕГО не пропадало. Проверьте, есть ли в ЭТОЙ БД сводные записи на эти журналы. Название журнала в записях NJ появляется только тогда, когда есть сводное описание. Либо у вас неактуализированный словарь. Это тоже может привести к такому результату.

На скриншотах приводятся разные записи. О чем свидетельствует не совпадение года издания и его номеров.

Такой результат был при всех способах (копирование, экспорт-импорт, сохранение-восстановление)
Под Копированием я имела в виду: сервис-копирование записей в другую базу,копировать в буферную запись-вставить из буферной записи в Каталогизаторе.
Если речь идет о режимах АРМа Администратор - КОПИРОВАТЬ ФАЙЛ ДОКУМЕНТОВ и ВОССТАНОВИТЬ ФАЙЛ ДОКУМЕНТОВ - то никаких ПОТЕРЬ данных не может быть.
На скриншотах привожу 2 записи.
Открытые записи -результат Администратор - КОПИРОВАТЬ ФАЙЛ ДОКУМЕНТОВ и ВОССТАНОВИТЬ ФАЙЛ ДОКУМЕНТОВ,виды записей описания журнала и сводного до и после процесса.Почему изменился шифр??
Либо у вас неактуализированный словарь. Это тоже может привести к такому результату.
После процесса КОПИРОВАТЬ - ВОССТАНОВИТЬ ФАЙЛ ДОКУМЕНТОВ всегда создаю словарь заново...Насколько я понимаю ,все проблемы из-за шифра, но как с бороться не знаю

Трудно понять, о чем здесь...
Но я надеюсь, Вы поняли:
Аналитические записи (1), записи на номер периодического издания (2) и сводная запись на периодическое издание (3) ЯВЛЯЮТСЯ СВЯЗАННЫМИ. Т.е. нельзя копировать ПЕРВЫЕ без вторых и третьих, а ВТОРЫЕ без третьих.

Но когда я копирую всю базу -там у каждого периодич. издания есть сводный.
фраза Аналитические записи (1), записи на номер периодического издания (2) и сводная запись на периодическое издание (3) ЯВЛЯЮТСЯ СВЯЗАННЫМИ. Т.е. нельзя копировать ПЕРВЫЕ без вторых и третьих, а ВТОРЫЕ без третьих не понятна

Тамара, для корректной работы записей у вас в одной БД должны дыть все три типа записей: сводная запись, запись на номер журнала, запись аналитическая. В принципе, последнии записи сами по себе самодостаточны. Но для отображения всех связок вам нужны именно все три записи. Если вы перенесли не все записи, то у вас режим перехода по связям и нормально отображение записей будет нарушенно.

Вы копировали все записи из одной базы в другую?

Как вы могли переносить данные из базы в базу методом копирования файла документов? Ирбис не дал бы вам восстановить файл документов для одной базы файлом от другой.

вы можете выгрузить полность БД и дать посмотреть на нее?

А еще лучше - упакуйте 2 файла: DATAI\RDR\RDR.MST и DATAI\RDR\RDR.XRF в архив и прикрепите их к сообщению - БД у Вас маленькая, так что много архив весить не будет