Visual FoxPro - доступ к файлу запрещен

Question

Наша ERP-система является гибридной. Фактические данные - это SQL, но таблицы, которые содержат пользовательскую информацию, профили, права, безопасность и т. Д., Находятся в Visual FoxPro.

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

set excl on
open data l:\M2MDATA\Util\util.dbc excl

Я получаю ответ: Доступ к файлу запрещен. Я зашел в диспетчер серверов, и ни у кого нет файлов, открытых в нашем каталоге VFP.

Есть ли в VFP команда, которая позволит мне определить, у кого / у кого открыт файл и / или как можно завершить любые сессии в FoxPro, которые это делают?

Я пытался погуглить, но безуспешно.

Answer 1

Возможно, вы захотите проверить Process Explorer от Sysinternals (Microsoft).

http://technet.microsoft.com/en-us/sysinternals/default.aspx

Вы можете использовать Find | Файл дескриптор или параметр меню DLL и введите имя файла DBC. Process Explorer сообщит вам идентификатор процесса и процесс, в котором открыт файл.

Если вы делитесь файлом в сети (файловый сервер или одноранговый), перейдите на «сервер» и запустите программу «Управление компьютером». Разверните раздел «Общие папки»> «Открыть файлы», и вы должны увидеть список файлов, открытых на компьютере другими пользователями в сети.

Rick

Answer 2

Как упоминал Джефф, одна вещь может быть, когда происходит сбой на машине одного человека, и он отключается от сети. Сервер по-прежнему ДУМАЕТ, что файл открыт с каким-то низкоуровневым дескриптором. Затем, когда пользователь повторно подключается, кажется, что все предыдущие настройки автоматически сбрасываются, возвращаются в систему, затем все кажется в порядке. Кроме того, проверьте ОТ СЕРВЕРА в разделе «Управление компьютером, общие диски и у кого файлы могут быть действительно открыты, даже если в противном случае у них могло быть некорректное отключение».

В качестве альтернативы для предварительной проверки такой исключительности для таблицы, вы можете попробовать выполнить запрос к .DBC, поскольку он также является не чем иным, как самой таблицей ... Что-то вроде

nStatus = 0
try
   use L:\M2MData\Util\Util.dbc shared
   ** Ok so far, now try exclusive
   nStatus = 1
   use L:\M2MData\Util\Util.dbc EXCLUSIVE
   nStatus = 2

catch to loTrapMsg
   messagebox( "Can't get exclusive use of DBC" )

endtry 

if nStatus = 2
   ** you have exclusive use of it as a simple TABLE
   ** Now, what do you want to do
   use
   open database L:\M2MData\Util\Util.dbc EXCLUSIVE

endif 

Answer 3

Вы можете попробовать это:

1. Перезагрузите сервер (если это возможно). Сейчас никто не использует его.

2. Получите список таблиц, связанных с DBC, и напишите сценарий для открытия каждой таблицы по отдельности и без исключения. Сбой какого-либо из открытий?

3. Возможно, одна из таблиц обратно связана с таблицей на другом сервере.

Просто некоторые идеи.

Answer 4

Найдите на сайте поддержки Microsoft настройки сервера Opportunistic Locking и Cached Open. Возможно, вам потребуется установить EnableOplocks на 0 и CachedOpenLimit на 0, как описано в статьях. Также антивирусное сканирование при доступе печально известно для такого рода вещей.

В дополнение к упомянутому превосходному инструменту SysInternals Process Explorer я использую инструмент UnLocker, который позволяет щелкнуть правой кнопкой мыши любой файл на сервере и увидеть процессы блокировки.

Существует также другой инструмент SysInternals, называемый «handle», который запускается в приглашении и дает много информации о том, какие процессы имеют дескрипторы для данного файла или файлов.

Answer 5

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

В таких случаях я обычно либо перезагружаю сервер, на котором расположена база данных, либо демонтирую / перемонтирую диск, на котором находится база данных (если это SAN или сетевой диск).

Answer 6

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

Answer 7

У меня была та же проблема (без эксклюзивного доступа к DBC), но другая причина.

Мы осуществляем протоколирование доступа и определенных действий в текстовом файле, обрабатываемых с помощью команд низкого уровня (FOPEN, FSEEK, FPUTS, FCLOSE, FCREATE). Мы делаем это с 1 апреля 2000 года, без каких-либо проблем.

После «серьезного неблагоприятного сетевого события» наша система все еще работала, но со скоростью гипер-улитки. Каждое протокольное действие заняло около 5 минут. Очевидно, FoxPro повторил процедуры низкого уровня в течение 5 минут и, наконец, пропустил их (без предварительного уведомления, кстати).

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

Понятия не имею, как это связано, но потом все снова было хорошо и остается. Сервер - Novell Netware, с которым я не знаком.

Answer 8

Я получил это сообщение раньше, и проблема проста, запустите проводник Windows и попробуйте открыть папку, в которой находится файл. если вы не можете получить доступ к папке, то делает Visual FoxPro. Я предполагаю, что вы используете папку общего доступа, поскольку вы упоминаете, что используете диск L. cmiiw:)