Уважаемые разработчики, добрый день!
У меня вопрос по поводу пакетных файлов, а именно функция импорта!
Возникла необходимость в организации чистки баз в пакетном режиме(64_v.2009), написал порядок выполнения команд(вернее взял файл созданный и исполняемый ранее версией 2007):
……..
OpenDB 1
ActualIf
ExportDB 0,,1,1,d:\BackupIrbis\1.txt
ClearDB
ImportDB 1,,0,1,d:\BackupIrbis\1.txt
LoadIfComplete
Exit d:\BackupIrbis\protokol_ClearDB.txt

суммарный объем баз порядка 270000 записей, выполнение чистки баз занял порядка 20 часов, на версии 2007 около 6 часов.
Подскажите, может, что-то поменялось в алгоритме обработки…. или необходимо дописать в задание какие-то дополнительные параметры?
IRBISA.exe – 1,75 мб 06.08.2010г.
И еще один момент, визуально бросается – в протокол вписывается
MFN=1
MFN=2
MFN=3
MFN=4
MFN=5
ранее(v.2007) просто строка ……….номерами(MFN) 1 – ….., можно ли как-то задать параметром ранний вариант протокола?
Заранее спасибо

Замедление связано с тем, что при ИМПОРТе не отключен АВТОВВОД. В версии 2010.1 для команды IMPORTDB введен шестой параметр для отключения автоввода.
Также замедление связано с формированием протокола. ОТключить его, к сожалению, можно только при ручном выполнении.

Цитата:

В версии 2010.1

хмм.... а какже нам быть? получается, поменялась версия и ущемила нас в определенных видах выполнениях задач....
Александр Иосифович, версия 2009 еще актуальна для многих библиотек, мы можем рассчитывать на доработку АРМа в ближайшем обновлении (или уже не будет поддержки этой версии)?

Выслал Вам АРМ Администратор 2010.1

Спасибо за внимание, попробую в действии, новые параметры импорта!

Кстати, процесс, который Вы называете "чистка" и на который ВЫ тратите столько времени, абсолютно бессмысленный...

Александр Иосифович, в смысле «абсолютно бессмысленный...»?
Возможно для кого-то и так, но к примеру в частной ситуации, когда каталогизаторов очень трудно заставить вводить записи на местах ранее удаленных, и когда руководство просит порядка в базах (ну мешает визуально удаленные…), то я не вижу другого варианта, возможно подскажите какой-то иной вариант!?
И еще раз поблагодарю, за высланный АРМ, теперь уже шустрее выполняется процесс, спасибо!

Alio написал(а):
-------------------------------------------------------
> Кстати, процесс, который Вы называете "чистка" и на который ВЫ тратите столько времени, абсолютно бессмысленный...

Можно поподробней?
У меня отложилось в памяти, что регулярная выгрузка-загрузка базы - это хорошо. Недавно на этом же форуме приводился пример, выполняющий такие действия еженедельно
 
Или вы имели в виду лишюю команду ActualIf перед экспортом?

ADS написал(а):
-------------------------------------------------------
> Alio написал(а):
> --------------------------------------------------
> -----
> > Кстати, процесс, который Вы называете "чистка" и
> на который ВЫ тратите столько времени, абсолютно
> бессмысленный...
>
> Можно поподробней?
> У меня отложилось в памяти, что регулярная
> выгрузка-загрузка базы - это хорошо. Недавно на
> этом же форуме приводился пример, выполняющий
> такие действия еженедельно
Чепуха. Нет таких рекомендаций.

Пожалуй регулярно стоит проводить Реорганизацию и создание копии баз. А опустошать базу и загружать заново не нужно. Я такое когда-то настраивал в одной библиотеке по очень убедительному требованию сотрудников. Но это не является обязательным, да и сверх нужным. Я бы рекомендовал создавать копии баз ежедневно, а реорганизацию проводить раз в месяц(при очень большой интенсивности работы с БД - раз в неделю). Экспорт/Опустошение/Импорт нужен только для того, что бы окончательно удалить из БД все пустые записи, логически и физически удаленные.

Вот не знаю, реально или нет реализовать, к примеру физически удаленные чтоб не светились в списке записей (ставить в инишке какой либо параметр 0/1) АРМов кроме АРМа Администратор??

Нельзя

А можно как то поиском найти все логически удаленные?

Нет. Но можно попробовать что-то сделать с записями в глобальной корректировке (куда-то их скопировать). Детали нужно смотреть. Я сейчас не готов. Но стандартного способа выгрузить все логически удаленные из базы нет.

Здравствуйте. Можно к вам?

У меня такой вопрос. Если бы удаленные записи просто лежали и никому не мешали, но нет же. Я нашла в резервных копиях правильную ЗАПИСЬ и попыталась заменить ею испорченную. Эта запись - сводное БО газеты, изменила шифр и после этого смогла опустошить - удалить - реорганизовать.

Т.о. испорченная запись к моменту импорта была ФИЗИЧЕСКИ удалена, однако она все-равно мешает сохранить правильный вариант - дублетность.И по поиску ищется. Делать в этом случае экспорт-импорт-опустошить, а потом импортировать отдельную запись это повешаться - сутки все будут без работы. Как мне Not valid... сделать Красноярским рабочим?
Может я в алгоритме ошибаюсь?

И почему нет возможности копировать запись поверх существующей с соответствующим сообщением как в windows? "Дублетная запись. Заменить имеющуюся?"



Редактировано 2 раз. Последний раз 28.04.2011 10:29 пользователем Novinka.

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

Если испорчена нужно словарь заново создать?



Редактировано 1 раз. Последний раз 28.04.2011 10:55 пользователем Novinka.

Novinka написал(а):
-------------------------------------------------------
> Если испорчена нужно словарь заново создать?
Сначала проведите диагностику файла документов.

Диагностика не выдала ошибок.

Если вы видите в словаре "Not valid" записи, то єто значит, что вы их удалили, а затем востановили и они остались в системе, просто их имя изменилось с "Название" на "Not valid Название". По большому счету, просто удалите эти записи.

Gena написал(а):
-------------------------------------------------------
> Если вы видите в словаре "Not valid" записи, то
> єто значит, что вы их удалили, а затем востановили
> и они остались в системе, просто их имя изменилось
> с "Название" на "Not valid Название". По большому
> счету, просто удалите эти записи.

Геннадий Сергеевич, запись, про которую Вы говорите, это в таком виде импортировалась газета в ЭК (как Вы и говорите , из-за дублетности она после импорта автоматом поставлена на логическое удаление с коверканьем названия, и я ее восстановила), она мне как раз нужна, в ней правильно все кроме названия.
А переименовать ее мне мешает ФИЗИЧЕСКИ УЖЕ удаленная испорченная запись. Выдает дублет. Александр Иосифович считает, что после физического удаления в нормальной БД запись не может находиться по поиску и участвовать в контроле на дублетность. Значит проблема в том, как вылечить мою базу.

Там в скрине видно, что по результатам поиска пытается открыться <MFN 2533> и не может, но по поиску то она зачем-то нашлась.
А <MFN 27666> открыта на закладке База данных/MFN, просто картинка не перерисовалась.

Сейчас создаю словарь заново, но это так медленно делается(( ой мне тут напоминают, что рабочий день закончился, до свидания



Редактировано 4 раз. Последний раз 28.04.2011 12:21 пользователем Novinka.

Не надо путать физически удаленную и логически удаленную. Возможно при проблемах с БД в словаре могут быть ссылки на уже удаленную запись. Но это только в проблемной базе.

Могу посоветовать сделать как топикстартер, экспорт/импорт/актуализация.

Здравствуйте, большое спасибо за помощь. После создания словаря удаленная запись уже по поиску не находится и я смогла переименовать not valid...
Но основной вопрос остался какой правильный алгоритм замены конкретной испорченной записи на правильную из резервной копии базы?
Неужели нужно каждый раз проводить из-за одной записи такие многочасовые процедуры как экспорт/импорт/актуализация или создание словаря заново?

Novinka написал(а):
-------------------------------------------------------
> Но основной вопрос остался какой правильный
> алгоритм замены конкретной испорченной записи на
> правильную из резервной копии базы?
Что такое "испорченная" запись?
Что такое "правильная" запись и каким образом она оказывается в резервной копии?

Поддержу Novinka «проводить из-за …… записи такие многочасовые процедуры как экспорт/импорт/актуализация или создание словаря заново», просто со стороны пользователя, это очень длительный процесс, который (на не маленьком объеме базы) может занять длительное время для достижения необходимого результата (последствия: выговор от руководства, почему сотрудники, каталогизаторы, из-за каких-то работ, не могут выполнять свои прямые обязанности, кто будет оплачивать их, как-бы рабочий-выходной). Но и разработчиков понять можно, это программа, есть определенная задача и чтоб получить результат нужно выполнить порядок действий…..
Хотя может возможно как-нибудь оптимизировать процесс удаления - логически удаленных, да и не только удаления…. импорта…. Былоб очень приятно :-)

Вы о чем? Что Вы хотите "поддержать"?

Ладно, проехали, основной вопрос изначально решили (замолкаю), остальные мои сообщения (в этой ветке) так пожелания…..

Alio написал(а):
-------------------------------------------------------
> Novinka написал(а):
> --------------------------------------------------
> -----
> > Но основной вопрос остался какой правильный
> > алгоритм замены конкретной испорченной записи
> на
> > правильную из резервной копии базы?
> Что такое "испорченная" запись?
> Что такое "правильная" запись и каким образом она
> оказывается в резервной копии?

Простите, долго не заглядывала. Я в другой ветке жаловалась на невозможность актуализировать запись в каталогизаторе. Перегрузили сервер и проблема ушла, но при этом газета, которую как раз не смогли актуализировать "испортилась", я тоже спрашивала как ее отредактировать. Там исчезли все подполя 910 поля и не получалось регистрировать новые номера.
Ну а резервное копирование автомат ежедневно делает, взяла базу за предыдущий день и в ней нашла запись с 910 полем. Дальше Вы все знаете.

1.В испорченной записи изменила шифр, т.к.есть номера и статьи.
2.опустошила и удалиа "испорченную", сначала логически
3.реорганизовала файл документов, запись удалилась физически
4.импорт записи по mfn (ISO) из более ранней бд
5.она скопировалась, но из-за дублетности автоматически логически удалилась.
6.проблема (была) в том, что мне не могло прийти в голову, что запись физически удаленная, у которой даже в ALL-формате нет ни одного символа сможет находиться по словарю. Иначе конечно бы актуализировала словарь.

Вопрос в том, какой алгоритм с Вашей точки зрения для этой цели был бы оптимальным?



Редактировано 1 раз. Последний раз 03.05.2011 13:04 пользователем Novinka.

Sega, спасибо.



Редактировано 1 раз. Последний раз 03.05.2011 12:57 пользователем Novinka.