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

StackOverflow https://stackoverflow.com/questions/1336564

  •  20-09-2019
  •  | 
  •  

Вопрос

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

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

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

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

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

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

Это было полезно?

Решение

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

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

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

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

Рик

Другие советы

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

В качестве альтернативы предварительной проверке такой исключительности в таблице, вы можете попробовать выполнить запрос к .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

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

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

Поищите на сайте поддержки Microsoft информацию о случайной блокировке сервера и параметрах кэшированного открытия.Возможно, вам потребуется установить EnableOplocks равным 0 и CachedOpenLimit равным 0, как описано в статьях.Кроме того, проверка на вирусы при доступе печально известна подобными вещами.

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

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

Вы могли бы попробовать это:

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

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

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

Просто несколько идей.

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

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

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top