Visual FoxPro - Acceso al archivo denegado

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

  •  20-09-2019
  •  | 
  •  

Pregunta

Nuestro sistema ERP es un híbrido. Los datos reales es SQL, pero las tablas que contienen información de los usuarios, perfiles, los derechos, la seguridad, etc es en Visual FoxPro.

Necesito obtener acceso exclusivo a la base de datos VFP. Elimino a todos, desde el sistema utilizando el programa en sí, e indica que todos estén fuera del sistema. Me da la siguiente respuesta al código siguiente: 

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

La respuesta que recibo es: Acceso al archivo denegado. Entré en el Administrador de servidores y nadie tiene todos los archivos abiertos en nuestro directorio VFP.

¿Hay un comando en VFP que me permitirá determinar quién / qué tiene el archivo abierto y / o una manera de matar las sesiones dentro de FoxPro que hacen?

He intentado googling pero no tuvo suerte.

¿Fue útil?

Solución

Es posible que desee comprobar hacia fuera el explorador de procesos de Sysinternals (Microsoft).

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

Puede usar la Búsqueda | Identificador de archivo DLL u opción de menú y poner en el nombre del archivo de DBC. Process Explorer le indicará el ID del proceso y el proceso que tiene el archivo abierto.

Si va a compartir el archivo en la red (servidor de archivos o peer-to-peer), la cabeza hacia el "servidor" y ejecuta Administración de equipos. Profundizar en las carpetas compartidas> archivos abiertos y que todo funciona correctamente, consulte la lista de archivos abiertos en el ordenador por otros usuarios en la red.

Rick

Otros consejos

Como se mencionó por Jeff, una cosa podría ser cuando un accidente en la máquina de una persona, y que se desconecta de la red. El servidor sigue pensando que el archivo está abierto en algún mango de bajo nivel. Entonces, cuando el usuario se vuelve a conectar, todos los ajustes anteriores parecen auto-mágicamente ser liberado, vuelve en el sistema, entonces todo parece estar bien. Además, compruebe desde el servidor bajo la administración de equipos, unidades compartidas, y que pueden tener los archivos se abren en realidad a pesar de que pueden haber tenido una desconexión sin gracia lo contrario.

Como una alternativa a la pre-prueba de este tipo exclusividad sobre la mesa, es posible que desee para tratar de ejecutar una consulta en la .DBC ya que también es nada más que una tabla en sí ... Algo así como 

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

Es posible que el programa bloqueado algún tiempo que tenía la base de datos abierta (dejando un bloqueo zombi) o la base de datos está conectada a través de un recurso compartido de red que no es la liberación de los recursos.

En estos casos, generalmente estoy reducido a cualquiera de reiniciar el servidor donde se encuentra la base de datos o desmontaje / remontaje del disco donde reside la base de datos (si es en una SAN o disco de red).

Look en el sitio de soporte de Microsoft para el servidor y la configuración de bloqueo oportunista en caché abiertas. Es posible que necesite configurar EnableOplocks a 0 y CachedOpenLimit a 0 ya que los artículos describen. También el análisis en tiempo real de virus es conocido por este tipo de cosas.

Además de la excelente SysInternals herramienta Process Explorer mencionado, yo uso una herramienta llamada Unlocker que le permite hacer clic derecho sobre cualquier archivo en el servidor y ver los procesos de cierre.

También hay otra herramienta SysInternals llamada 'mango', que se ejecuta en el indicador y da mucha información sobre qué procesos tienen asas en un archivo o archivos determinado.

Usted podría intentar esto:

  1. Reiniciar el servidor (si es posible). Ahora nadie lo está utilizando.

  2. Obtener una lista de tablas vinculadas con el DBC y escribir un guión para abrir cada mesa individual y execlusively. ¿Alguno de los Abiertos fallan?

  3. Posiblemente, una de las mesas está de vuelta vinculada a una mesa en otro servidor.

A sólo algunas ideas.

Podría valer la pena asegurarse de que se puede abrir para el acceso compartido para asegurarse de que no es un problema de permisos.

He conseguido que el mensaje antes y el problema es simple, ejecute el Explorador de Windows e intenta abrir la carpeta donde encuentra el archivo. si no se puede acceder a la carpeta, también lo hace FoxPro visual. Asumo que está utilizando la carpeta para compartir desde lo mencionas que está utilizando la unidad L. cmiiw:)

Yo tenía el mismo problema (accesos no exclusivo de DBC), pero otra razón.

Estamos sobre protocolo de acceso y ciertas actividades en un archivo de texto se maneja a través de comandos de bajo nivel (FOPEN, FSEEK, fputs, FCLOSE, FCREATE). Lo hacemos desde abril 1 ª de 2000, sin ningún problema.

Después de un "evento de red adversa severa" nuestro sistema sigue corriendo, pero a una velocidad hiper-caracol. Cada acción protocolizado llevó unos 5 minutos. FoxPro, obviamente, vuelve a intentar los procedimientos de bajo nivel durante los 5 minutos y finalmente los saltado (sin previo aviso, por cierto).

El archivo de texto de ninguna manera es parte de la base de datos en sí. Nontheless, DBC no era accesible con una cerradura zombi de la máquina (apagado), que también era el dueño de una cerradura zombi al archivo de texto. cerradura DBC sólo podía ser puesto en libertad después de sombrero el bloqueo del archivo thext sido eliminado.

Ni idea, cómo esto está conectado, pero después, todo estaba bien otra vez y todavía lo es. Servidor es Novell Netware, que no estoy con faniliar.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top