Произеден поиск, произведен уточняющий поиск.
Отредактирована запись.
Сохранена запись.
Сообщение(Результат поиска изменился)
А дальше происходит переключение на закладку (Новый/MFN) со словами (Для продолжения работы с данной записью).
Как убрать этот автоматический переход с результатов поиска?

PS. Почему-то это происходит не всегда ...

iLq написал(а):
-------------------------------------------------------
> Произеден поиск, произведен уточняющий поиск.
> Отредактирована запись.
> Сохранена запись.
> Сообщение(Результат поиска изменился)
> А дальше происходит переключение на закладку
> (Новый/MFN) со словами (Для продолжения работы с
> данной записью).
> Как убрать этот автоматический переход с
> результатов поиска?
НИКАК. ВЫ просто не понимаете этой ситуации. Разберитесь...

>
> PS. Почему-то это происходит не всегда ...

Как мне понимать эту ситуацию?
Ситуация есть какой я её вижу - сейчас более подробно опишу.

- Каталогизатор. БД RDR.
- Последовательный поиск (не ругайтесь на последовательны поиск - тут, по-моему как раз он оправдан, так как производим потом уточняющий запрос)
- Ищем на наличие поля "пол" и находим 600 документов
- Ищем уточняющим запрсом на отсутствие "дата рождения" и находим 10 документов
- Редактирую одну запись - проставляю дату рождения
- Сохраняю
- Выходит сообщение: "Внимание. Peзультaт пoиcкa измeнилcя". Жму "Ок".
- Происходит переключение на закладку "Новый/MFN".
- Выходит сообщение "Внимание: B peзультaтe кoppeктиpoвки измeнилcя peзультaт пoиcкa - для пpoдoлжeния paбoты c тeкущим дoк-oм пpoизвeдeнo пepeключeниe кoнтeкcтa paбoты нa HOBЫЙ/MFN"
- И открыт тот документ, в котором я правил Дату рождения.

Что тут понимать?
Разобраться не могу - может намёкнете где разбираться ....

Все, что ВЫ описали, - это абсолютно нормальная ситуация. Так и должно происходить...
Что Вас не устраивает?

я произвел поиск, произвел уточняющий поиск - я хочу работать с этими документами (допустим их 60) надо исправить дату рождения. Я у одного исправил. Сохранил! (это практически признак того, что я с ним закончил работать). Мне надо работать дальше со списком документов (59 записей). Зачем он меня перекидывает на закладку Новый/MFN - нет чтобы переключиться на след. документ в том отобранном списке... я не прав? Ну по крайней мере логично?

Перейдите на закладку "Результаты поиска" и продолжайте работать с оставшимися документами (с теми, у которых ЕЩЕ отсутствует дата рождения)

Это понятно. НО 60 раз переходить на закладку - немного неудобно - согласитесь.
При чем по идее логичнее оставаться в той же закладке "результат поиска". Ведь сохранение - практически знак завершения работы с записью. То есть надо продолжать работать с другими записями в закладке "результат поиска". Смоделируйте мне ситуацию, когда требуется продолжить работать с записью после её сохранения.

Разговор по-моему ни о чем.

Каждому как говорится свое. Александр Иосифович мне кажется прав. Хотя свои неудобства я тоже в этом вижу. Но я нашел выход - просто не нажимайте СОХРАНИТЬ, а в результатх поиска перейдите на другую запись.

Попробуйте.

Ярославская ОУНБ им. Н.А.Некрасова

Можно вопрос не в тему, а по логике?

А зачем редактировать 600 дат рождения? В среднем по столько не живут, а если это почти одногодки, то может проще сделать все это несколькими глобальными корректировками?
Или выгрузить базу данных в несколько непересекающихся запросов в текстовом формате и руками в текстовом формате проставить все это?

Мне кажется, что проблема возникла из-за попытки решения задачи "в лоб". Может что-то придумать обходное? Ведь задача-то очень-очень частная. И решать ее, соответсвенно, потребуется частным нетривиальным решением.

Нет. Проблема не в этом - и вопрос соответственно не в этом.

Просто хочется чтобы не переходил и все! А что и как - это уже второстепенно, как я понял.

Ярославская ОУНБ им. Н.А. Некрасова

да даже не 60, а 10 например дат поменять.
Опишу ситуацию.
Каталогизатор, БД RDR, переходим на Ирбис. Сконвертили читателей со старой БД. Раньше Дату рождения например не вводили и пол тоже не вводили.
Вот начали перерегистрировать, ввели пол, дату рождения забыли. а вечером проверили - нашли тех, у кого пол есь (то есть перерегистрирован), а даты нет (ну например) (пока потому что не настроил поиск по дате редакции записи) и стали проставлять дату рождения ... И переключение это не нужно (и все равно думаю, что даже не логично этопереключение).
Хитрость коверги нам поможет :)

Я так думаю если вы еще будете продолжать акцентировать внимание на "хитрости" Александра (Коверги), то другой Александр (Иосифович) вам эту возможность в 6.2 обрежет, поскольку она не укладывается в концепцию и явно проскочила по недосмотру :))

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

почему не укладывается - происходит переход на другую запись самим пользователем - Ирбис делает что ему говорят переходит и запрашивает сохранение предыдущего документа. Так что тут все чики-пуки - никто никого резать не будет.

В версии 2006.2 (ИРБИС64) сделал изменения. В случае изменения (в результате корректировки) результата поиска СНАЧАЛА задается вопрос; переключать контекст работы (для продолжения работы с той же записью) или нет.

Это очень хорошо.. Это право выбора, свобода воли :) Спасибо.

Вот в свое время мы с вами Александр Иосифович помнится долго обсуждали вопрос о необходимости безусловного обновления результатов поиска при внесении измений в запись. Так может на этой доброй волне Вы кроме (а лучше вместо) выбора "переключться\не переключаться на новый MFN", дадите возможность указывать "обновлять/не обновлять результат поиска"?

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

Куделя написал(а):
-------------------------------------------------------
> Это очень хорошо.. Это право выбора, свобода воли
> :) Спасибо.
>
> Вот в свое время мы с вами Александр Иосифович
> помнится долго обсуждали вопрос о необходимости
> безусловного обновления результатов поиска при
> внесении измений в запись. Так может на этой
> доброй волне Вы кроме (а лучше вместо) выбора
> "переключться\не переключаться на новый MFN",
> дадите возможность указывать "обновлять/не
> обновлять результат поиска"?
А вот это ПРИНЦИПИАЛЬНО невозможно в ИРБИС64...
(результат поиска сохраняется не в виде перечня найденных MFN - как в ИРБИС32 - а в виде формулировки запроса)

> А вот это ПРИНЦИПИАЛЬНО невозможно в ИРБИС64...

Да, так Вы и ответили и позиция Ваша ясна.
Но тогда просто из академического интереса:
1) то что я (и любой пользователь) видит в левом нижнем углу программы - есть список строк получаемый в результате отработки на полученных в результате поискового запроса записях формата brief
2) когда я активирую строку в этом массиве, происходит расформатирование по другому формату (оптимизированному), загрузка записи в Рабочий лист и т.д. Все эти действия берут кокретную указанную мной запись. И берут они ее по mfn. В brief-строке этого номера нет. Значит он есть где-то. Может в самой форме списка записей (скорее всего). Так что либо я совсем ничего не понимаю, либо Вы несколько лукавите :) утверждая что
> (результат поиска сохраняется не в виде перечня
> найденных MFN - как в ИРБИС32 - а в виде
> формулировки запроса)

Хотя возможно это вопрос определения. Поскольку Вы говорите о СОХРАНЕНИИ результата поиска, а я имею в виду всего лишь отказ от принудительного сброса данных в списке записей в течение сеанса их редактирования и принудительного же обновления поискового запроса после каждого изменения любых данных в записи из списка.

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

Куделя написал(а):
-------------------------------------------------------
> > А вот это ПРИНЦИПИАЛЬНО невозможно в ИРБИС64...
>
> Да, так Вы и ответили и позиция Ваша ясна.
> Но тогда просто из академического интереса:
> 1) то что я (и любой пользователь) видит в левом
> нижнем углу программы - есть список строк
> получаемый в результате отработки на полученных в
> результате поискового запроса записях формата
> brief
> 2) когда я активирую строку в этом массиве,
> происходит расформатирование по другому формату
> (оптимизированному), загрузка записи в Рабочий
> лист и т.д. Все эти действия берут кокретную
> указанную мной запись. И берут они ее по mfn. В
> brief-строке этого номера нет. Значит он есть
> где-то. Может в самой форме списка записей (скорее
> всего). Так что либо я совсем ничего не понимаю,
Именно так...


> либо Вы несколько лукавите :) утверждая что
> > (результат поиска сохраняется не в виде перечня
> > найденных MFN - как в ИРБИС32 - а в виде
> > формулировки запроса)
>
> Хотя возможно это вопрос определения. Поскольку Вы
> говорите о СОХРАНЕНИИ результата поиска, а я имею
> в виду всего лишь отказ от принудительного сброса
> данных в списке записей в течение сеанса их
> редактирования и принудительного же обновления
> поискового запроса после каждого изменения любых
> данных в записи из списка.

> > указанную мной запись. И берут они ее по mfn. В
> > brief-строке этого номера нет. Значит он есть
> > где-то. Может в самой форме списка записей
> (скорее
> > всего). Так что либо я совсем ничего не
> понимаю,
> Именно так...

ну так и что же тогда мешает не выполнять поиск когда пользователь этого НЕ просит и НЕ хочет? Список mfn есть. Он фиксирован в самой форме.

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

Вы не поняли, к чему относится мое "именно так..." :)

понял :)
Ну тогда объясните как оно работает? Я же про академический интерес оговоился в начале :)

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

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

А я вот не вижу сложности запомнить текущий MFN. Если в результате корректировки корректируемая запись не попадает в результат поиска, то выделять следующий за редактируемым MFN. В этом алгоритме нет ничего космического, а логически все верно.

Да, действительно, посмотрел в отладке и увидел... По запросу отсылается пачка записей ПОЛНОСТЬЮ (хорошо еще что в пределах установленного лимита). Стало понятно отчего нам приходится экономить трафик на клиентских ИНИ :))) Это если на БД статей, где объем записей заведомо невелик сбрасывается около 200 Кб, то я представляю как выглядит "посылка" с многоэкземплярной учебной литературой, да с идивидуальными штрих-кодами:)). Спрашивается, зачем клиенту полный набор данных если ему нужен лишь минимум (brief&mfn) для идентификации конкретной записи, тогда как посмотреть ее целиком он может только открыв запись на редактирование. И уже предполагаю ответ - "расформатирование происходит на стороне клиента". Клиент толстый и кушает он соответственно много :) Но почему бы не "кормить" его только при редактировании одной записи,а то получается что довольно много "корма" совершенно "не в коня"

Относительно ситуации "разглядывания", могу сказать, что с точки зрения оператора - которым я был довольно долгое время :) - и, особенно, такой его разновидности как корректор она выглядит так:
1) я отобрал записи по критерию. Четкий диапазон. И намерен его отработать.
2) я прекрасно отдаю себе отчет в том, что какие-то из них могут измениться или появятся другие - не вошедшие в этот диапазон на момент выполнения запроса
3) это меня мало заботит, поскольку для тех которых не было, я выполню запрос позже, а те которые выпадут из диапазона по причинам изменения в них данных я все равно детально рассмотрю только вызвав на редакцию (не говорю уже о тех которые перестанут соответствовать критерию отбора в результате моих собственных действий)
4) а заботит меня то, что диапазон этот после каждой операции сохранения постоянно меняется; без моего желания и просьбы выполняются какие-то запросы; сами собой переключаются плоскости и все "бежит, летит и скачет". От этого я чувствую себя некомфортно, а мне то хочется стабильности и определенности, на что я и расчитывал зафиксировав запросвизуально. Все равно бы как в Яндексе страница с результатами поиска постоянно обновлялась сама собой. А если я работаю с базой больше сотни тысяч, да не дай Бог выполнил последовательный поиск, да еще и сижу в "удаленном офисе", тогда все это превращается в сущую муку = хоть распечатывай номера mfn да работай уже по ним на плоскости всей базы.

Совершенно нехорошо то, что клиенту сообщается о том, что запись изменилась только в момент сохранения, а не в момент открытия. Понятно что это вырастает из сомнительного (с моей точки зрения, конечно, о чем я не раз говорил) решения отказаться от практики блокировки записей. И в таком ключе оно оправдано... на плоскости (буду уж по старинке) "новый/MFN". Но на результатах поиска? Почему сразу не предупредить оператора? И опять же - потому что записи берутся пачкой.

Кстати, если в результатах поиска я отредактировал запись и при сохранении мне сообщается что возникла коллизия и надо проанализировать архивную запись, то в случае если эта "чужая" редакция изменила данные являвшиеся основанием для отбора записи, то при закрытии окна архива:
1 набор записей обновляется,
2 моя инвалидная запись из списка исчезает,
3 я автоматом оказываюсь на записи которая заняла ее порядковый номер в результатах запроса.
Вот это - как раз тот случай, кода оператор 100% пойдет исправлять результаты коллизии на плоскость НОВЫЙ. Но ему даже не предлагают :) так что открывай опять архив, смотри mfn и далее.

В общем влез я уже куда-то совсем в системообразующие дебри и посему умолкаю. правда с чувством выполненного долга, поскольку устно так все не обскажешь, а о том что "есть и такое мнение" комьюнити знать будет надеюсь полезно :))

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



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