г-да, тов-щи, члены профсоюза и приравненные!
вспоможите убогому!

___
И хто сталкивался со следующей проблемой:

примерная конфинурация:
1. Интерфейс Акс 97.
2. БД .mdb (mde) (несколько файлов - источников). В т.ч. формат 2.0
2.а. (пути и в виде \\server\...\xxx.mdb, и в виде z:\...\xxx.mdb
3. Новелл

проблема: в некий момент от Акс 97 приходит сообщение об отсутствии пути (именно к директории запущенного интерфейса или данных). При этом, если не выходить из акса, то сетевые пути используемые аксом (и к базам.д. и к системнику) "не доступны" - нет доступа (в т.ч. из эксплорера). В т.ч. нельзя запустить еще один акс с тем же системником (сообщение то же, но по поводу пути к системнику). Как только закрыть сеанс, в котором "защелкнуло" ошибку подключения - путь находится. И снова можно запущать Акс. (такое было с принтерами во 2-м аксе - если терял, то уже больше не находил).
__
Вопрос: есть ли пимпочки (напр. типа SetOption, как Application-a, так и DbEnjine-ов (2.5/3.5), которые могут повлиять на восстановление подключения в том же сеансе Акс-а? Или это в новеле надо что-й то подкрутить? Что-то я не разберусь, что в сетевых настройках может на эту ситуацию повлиять? (обычно все касается повторов попыток доступа уже в таблицы, а не к файлу)

ошибка у меня вылетела на \\ххх\..., но не факт. (воспроизводимость невысока, зависит не пойми от чего). В этот момент я был совсем в другом окне. К тому же это акс сообщил о потере сети, а по этому пути у меня большая часть данных и сам интерфейс . Если бы пытался работать с интерфейсом, была бы вероятность ругани на путь к системнику - он по "прописанному буковкой сетевому диску" -на запрос прав на работу (тоже не факт, но вероятно). А вот когда запускаю еще один акс, не закрыв "заклинивший", тогда ругань идет на путь к системнику. Меня интересует не как заставить сеть не отваливаться, а можно ли заставить Акс не блокировать (или хотя бы существенно уменьшить вероятность "заклинивания") путь -т.е. находить по новой.


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

На сетке Win (да на раб станции NT4) с сетевыми путями аналогичная базка годами крутилось. (Сеть пропадала токо от механических воздействий). А ежли мапить - то надо насиловать админов, чтобы не только диски у всех юзеров назывались одинако, но и пути в них были одинакие. А то ж норовят кажному токо его дирехторию подцепить, т.ч. у кого поглавней - и корневища в этом диске, а у кого подробнее - одна голая конечная директория. Тут фих одинакий путь задаш. А каждого цеплять по своему (да раскладать по собственному мде) - цеплялка отвалиться. Опять же если б везде (во всех армах, то бишь) данные с интерфейсом разделены были... :0) Да и юзеров тучу враз не перестроишь.


Вот и спрашаю - нет ли у кого практики по выкручиванию рук аксу или новелу. (а не админам и юзерам).

Сенькаю. Проблема с ЭТИМ ключом была в транзакциях 2.0. но его (кажись) выкрутили (на новеле) под 50 000. Вроде транзакции проходят. (Умолчание 9500 никто не трогал). Да и Справка и говорит именно о транзакциях.

авторMaxLocksPerFile
Данный параметр запрещает превышение определенного числа в транзакциях, выполняемых ядром Microsoft Jet. Если число попыток блокировки в транзакции превышает это значение, транзакция разбивается на две части, занесение в которых производится независимо. Этот параметр был добавлен для предотвращения срывов на сервере Netware 3.1 при превышении предела блокировок Netware, а также для повышения быстродействия при работе как с Netware, так и с NT.


А вот что может влиять на попытки аксеса постучатся снова по пути, по которому не произошло подключение? Тоже какой нить параметр из этой серии? (DbEngine-овский параметр блокировки?)