Ирбис 64, Каталогизатор, БД RDR.
При создании (сохранении) новой записи как автоматически заполнять поле 31 с подполями даты и ФИО регистратора?

И как сделать поиск записей редактированных (не созданных, а именно редактированных) за какой-то промежуток времени. Просто мы начали работу по БД RDR и хотелось бы в конце рабочего дня посмотреть(проверить) что было сделано за день...

iLq написал(а):
-------------------------------------------------------
> Ирбис 64, Каталогизатор, БД RDR.
> При создании (сохранении) новой записи как
> автоматически заполнять поле 31 с подполями даты и
> ФИО регистратора?

В обновлении D5 в файле Autoin.gbl БД RDR внесено исправление, обеспечивающее безусловное формирования полей 31 и 907 из данных, введенных в настройке (ФИО) и даты

> И как сделать поиск записей редактированных (не
> созданных, а именно редактированных) за какой-то
> промежуток времени.

В БД RDR нужно реализовать то, что сделано в этой части в БД IBIS, а именно:
1. В РЛ добавить поле 907 (907.wss копировать из IBIS)
2. Создать в справочник ETR.MNU (этап работы)
3. В Autoin.gbl для поля 907 добавить формирование 907^C (см. Autoin.gbl IBIS)
Этого достаточно для получения статистики по полю 907.

Можно создать также поиск по данным поля 907
4. Создать словарь "Этап работы-ФИО-дата" (в Ibis.fst - словарь Технология с префиксом TH= )
5. Добавить этот словарь в сценарий поиска

> Просто мы начали работу по БД
> RDR и хотелось бы в конце рабочего дня
> посмотреть(проверить) что было сделано за день...

Подскажите, пожалуйста, как узнать какое у нас обновление? Поискал на форуме про скачивание обновлений - почему-то толком ничего не нашел - только упоминания, что "скачайте с фтп". Можете ли написать фтп-адрес и где узнавать про обновления оперативно?

Так. Получается такая ситуация:
Есть параметр [Private]->FIO в ини файле на сервере (далее FIO-сервер).
Есть параметр [Private]->FIO в ини файле у клиента (далее FIO-клиент).

В "Сервис->Настройка параметров" отображается данные из FIO-клиент.
Записывается в 31 и 907 поля данные из FIO-сервер.
Если присутствует FIO-сервер, но отсутствует FIO-клиент, то в "Сервис->Настройка параметров" ничего отображаться не будет, но будет производиться сохранение отредактированного документа.
Если присутствует FIO-клиент, но отсутствует FIO-сервер, то не будет производиться сохранение отредактированного документа, так как "отсутствует ФИО регистратора), но в "Сервис->Настройка параметров" будут отображаться данные из FIO-клиент.
Синхронизация будет происходить только при нажатии кнопки "ПРименить" в "Сервис->Настройка параметров".

К чему это приводит:
- обязательное создание для каждого каталогизатора своего ини-файла на сервере.
- при необходимости поменять какой-то общий для всех параметр (а все параметры кроме фамилии, практически всегда общие) потребуется менять во всех ини-файлах каталогизаторов.
- непонятно зачем FIO-клиент вообще нужен.

Я давно предлагал вынести в INI-клиент ТОЛЬКО параметры интерфейса (расположение компонентов) и какие-то параметры, не зависящие от сервера. Попытка экономить трафик таким разделением настроек просто смехотворна. Только в этом я вижу вижу смясл клиентского ини-файла.

По-моему рациональным решением будет прописка фамилии в параметрах логина пользователя - там где прописываются используемые им ини-файлы. Тогда для группы пользователей с одинаковыми правами останется возможность использования одного ини-файла. В Сервис->настройка параметров будет загружаться эта фамилия. В клиентсокм ини-файле убрать этот параметр.
Другого рационального решения проблемы не вижу.

Александр Иосифович, что решим?

Присоединяясь...
На прошедшем ЛИБКОМе эта тема обсуждалась и Александр Иосифович насколько мне помниться не выказывал резкого противления идее замены параметра FIO в PRIVATE данными из логина регистрационной формы.
Относительно же клиентских ИНИ: полтора года назад я уже высказывал свое мнение относительно данных, которые в нем храняться (особенно дублирующихся с серверной частью), и полностью согласен с Паневым - чем меньше - тем лучше.

Иркутская ОГУНБ
ИРБИС64.21Турбо
WebИРБИС-PHP

Я имел ввиду немного другое - добавить в настройках логина - фамилию <имя отчество>, для возможности использовать логины как они есть (iLq, Куделя), чтобы исключить консенсусы типа однофамильцев.... Хотя эти случаи можно и обойти способом Лазарев1, Лазарев2 :)

вот кстати Илья, раз уж вы такой активно заинтересованный гляньте здесь, если не скучно..

Иркутская ОГУНБ
ИРБИС64.21Турбо
WebИРБИС-PHP



Редактировано 1 раз. Последний раз 18.01.2007 07:15 пользователем Куделя.

разрешили задачу как автоматически заполнять (отслеживать) кто создал запись, кто редактировал запись.
Как узнать кто удалил запись??? (нужно для статистики)

Вы можете решить эту проблему примерно таким образом:
1) определить произвольное поле NNN, которое будет рассматриваться как разрешение на удаление записи
2) в файле delflc.pft (отвечающем за ФЛК при удалении записи) в базе данных прописать условие что удаление записи запрещено при отсутствии в ней поля NNN и выдачу соответствующего сообщения оператору
3) В Autoin.gbl прописать команду DELREC с условием проверки наличия в записи поля NNN

В результате кнопка удалить для базы станет "декоративной", а чтобы удалить запись оператор должен будет сначала ее соответствующим образом изменить (ну и соответственно там пропишется 907 поле, если в autoin есть отвечающие за это операторы). Правда определить кто удалил запись вы сможете только напрямую выйдя на нее, поскольку в словарях она отражена не будет и при последовательном поиске логически удаленные записи также пропускаются.

Кстати вот мысль - может быть в форме последовательного поиска добавить чек "Искать и в удаленных". Не скажу что часто, но все-таки бывают ситуации когда это нужно сделать...

Иркутская ОГУНБ
ИРБИС64.21Турбо
WebИРБИС-PHP

Тогда можно зПлюсом к вышеописанным ФЛК добавить поле наподобии 907 - например, 990 (Удалил запись) и туда autoin'ом записывать так же дату и фамилию. Ведь можно так?

Итак вот что сделал для снятия статистики по кол-ву удаления записей:
1. Создал БД DELRD
2. Добавил поле 666 "Удалить запись" с переключателем Да-Нет.
3. В auotin.gbl прописал проверку поля, и при положительной проверке происходит копирование данной записи в БД DELRD, и удаление в БД RDR.

Но я наткнулся на такой глюк-проблему с фокусировкой:
Если фокус падает на поле с переключателем в удаленной записи, то вылезает окно-сообщение: "Cannot focus a disabled or invisible window." и происходит автоматическая "редакция" этой записи. То есть при переходе на другую запись задается вопрос - Хотите ли сохранить данную запись? (при положительном ответе она опять проходит автоин, и если там был переключатель "Удалить" произойдет повторное копирование данной записи в БД DELRD).

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

Александр Иосифович, вы не согласны со мной? Я что-то делал не так и такая ошибка имеет право быть??

Да, была ошибка - исправлена. Спасибо. Исправления попадут в ближайший апгрейд