proNovell

Существует некая программа (Perco - контроль турникетов с ведением базы данных прохода через них сотрудников). База (судя по всему, борландовская) программы лежит на сервере NW 5.0. У всех клиентов, подключаемых к этой базе стоят новеловские клиенты и диски с этой базой отмэпированы новеловскими средствами.
Всё работало нормально примерно 2 недели. С сегодняшнего дня, программа пишет, что не может подкючиться к базе, по-скольку один из файлов занят (monitor показывает, что он свободен). Если переписать эту базу на локальный диск, то программа нормально её подключает. Получается, что дело в Novell-е?
На сетевом диске, где лежит база, места достаточно.
Что это может быть?
ПОМОГИТЕ добрым советом! А то начальство голову оторвет за отсутсвия сведений о том куда кто ходил.

А если это механизмы самого софта не пускают?
Borland? М.б. это парадоксовые базы? Тогда должен быть файл pdoxusrs.net (где-то рядом с базой, опять же, надо знать каким образом с БД работают: BDE и т.д. и т.п.) в котором прописывается захват файла/записей и т.д. (т.е. не используются функции ОС как таковые). В этом случае Novell совершенно не виноват. Меняем/исправляем этот файл (как самое простое решение) и все снова работает.

действительно лежит файл PDOXUSRS.NET
а что надо менять исправлять?
я с этим не знаком. до изготовителей софта достучаться трудно.

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

Непонятно про клиентов - какие ОС, версии клиентов? В DOS, напр, пока share не загрузишь такая картина и будет.

В составе eDirectory идет NMAS - Novell Modular Authentication Services. Попробовать использовать их вместо этого вашего софта. Это так - спрашивали же про все советы

Две машины с WinXP Pro На одной клиент 4.83En на другой 4.83Rus. Одна машина с WIN98SE с клиентом 3.32RUS.
На всех машинах каталог с базами отмэпирован как сетевой диск.
На сервере NW 5.0
Чем вообще в этом случае может быть принципиальное отличие в работе с базой на локальном диске и на отмэпированном диске для ПО?
Может какие-то атрибуты для файлов можно поставить?

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

Попробуйте атрибуты
Sh - Sareable и T - Transactional, также правильность выставленных (если есть) атрибутов Ro- Read Only .
Как минимум - хуже стать не должно.

И про патчи вы ничего не пишите. Не ставили? И на саму систему и на клиентов. Для НТ-клиента была куча постфиксов именно по файловой системе.

А ещё был способ борьбы с подобными взбрыками: снести базу с тома и сразу восстановить с локального диска. Если позволяет ситуация - между сносом и восстановлением - перезагрузка.

На самом деле все гораздо проще.
Надо -
1. снести все файлы которые находятся в сети Pdoxusrs.net (просто удалить)
2. тоже сделать с файлами *.lck. (их должно быть 1 или 2 взависимости
от обстановки)
Для удаления файлов НИ ОДИН пользователь не должен работать с БД.
данные файлы должны лежать ТОЛЬКО на сетевом диске с правами пользователя удалять-стирать-создавать-модифицировать. Если они есть на локальном возникают проблемы.

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

именно так проблема и решилась!

По всем признакам используется Borland Paradox или работа происходит через интерфейс типа BDE. Есть файл PDOXUSRS.NET который содержит информацию о состоянии БД и режимах работы пользователей. Таким образом, методы работы с БД не привязаны с инструментарию сетевой ОС ("тупая кросс-платформенность"). Поскольку все равно не известно как велось программирование самой задачи, говорить как исправлять слож. ситуацию трудно. Могу предложить несколько вариантов:
1) Если есть какая-нибудь резервная копия системы, то можно взять PDOXUSERS.NET из копии. При замене ничего страшного не произойдет;
2) Если есть дистрибутив системы, попробовать поставить систему заново (естественно, предварительно сохранив боевую версию) и оттуда взять PDOXUSERS.NET. Потом поставить боевую систему на место и переписать новый PDOXUSERS.NET вместо испорченного;
3) При определенных условиях программирования, система может сама восстанавливать свои первоначальные настройки (это если у разработчиков руки дошли до написания соответствующего кода). Поэтому иногда можно просто удалить этот файл или же создать вместо него файл нулевой длины. Но это отчаянный вариант, т.к. слишком много "если". Копию сделать сначала надо обязательно.
4) Несомненно, есть продукт который позволяет исправлять "этот" файл - Borlad Paradox. Но! Здесь я ничем не помогу, к сожалению. Не владею я информацией по данной СУБД. Ругать ее не будем. Время с поры его молодости прошло уже достаточно. Вообще, настоятельно советую поспрашивать на формах по борландовским продуктам. Это их хлеб. Новелл здесь точно совершенно не причем. Сам бываю регулярно в такой ситуации, но у меня была "соломка в нужном месте", обохожусь вариантом 1 (см. выше). И копию этого ненормального файла берегу.

P.S.: Старый вывод: Не экономьте на резервном копировании - себе же дороже.

резервные копии каталога с базой создаются еженочно.
был откат на три недели в 20 архивов. попытка восстановить базы из резервных копий (нескольких на угад) приводила к тем же результатам. сейчас попробывал: если из восстановленного архива стереть файл PDOXUSRS.NET и PDOXUSRS.LCK, система начинает работать. возникает следующий вопрос. можно ли таким способом пользоваться всегда при таком "падении" базы?

Можно. Эти файлы создаются заново ядром BDE (Borland DataBase Engine) при их отсутсвии. Насколько мне известно ВСЕ программы от более-менее известных производителей при компиляции кода включают необходимые функции ядра. (Тем более это есть в самом Парадоксе). Поэтому ничего страшного в этом нет.

P.S. я так думаю, что данная тема несколько вышла за пределы Novell, если будут еще вопросы около данной темы пиши slavsev@hybce.com. Мгновенный ответ не обещаю, но отвечу всегда.