Visual FoxPro - File Access est refusé

Question

Notre système ERP est un hybride. Les données réelles sont SQL, mais les tables qui contiennent des informations utilisateur, les profils, les droits, la sécurité, etc est dans Visual FoxPro.

Je dois obtenir un accès exclusif à la base de données VFP. Je retire tout le monde du système à l'aide du programme lui-même, et il indique tout le monde est hors du système. Je reçois la réponse suivante au code suivant:

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

La réponse que je reçois est: File Access est refusé. Je suis allé dans le gestionnaire de serveur et personne n'a tous les fichiers ouverts dans notre répertoire VFP.

Y at-il une commande VFP qui me permettra de déterminer qui / ce qui a le fichier ouvert et / ou un moyen de tuer toutes les sessions dans FoxPro qui font?

J'ai essayé googler, mais pas eu de chance.

Answer 1

Vous pouvez consulter le Process Explorer de Sysinternals (Microsoft).

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

Vous pouvez utiliser la Recherche | Poignée de fichier ou de l'option de menu DLL et mis dans le nom du fichier DBC. Process Explorer vous indiquera l'ID du processus et le processus qui a ouvert le fichier.

Si vous partagez le fichier sur le réseau (serveur de fichiers ou peer-to-peer), la tête sur le « serveur » et exécutez Gestion de l'ordinateur. Percer vers le bas dans les dossiers partagés> les fichiers ouverts et vous devriez voir, espérons la liste des fichiers ouverts sur l'ordinateur par d'autres utilisateurs sur le réseau.

Rick

Answer 2

Comme l'a mentionné Jeff, une chose pourrait être quand un accident sur la machine d'une personne, et ils sont déconnectés du réseau. Le serveur PENSE encore le fichier est ouvert à une certaine poignée de bas niveau. Ensuite, lorsque l'utilisateur re-connects, tous les réglages antérieurs semblent obtenir leur libération automatique par magie, revenir dans le système, tout semble bien. En outre, vérifiez DU SERVEUR sous gestion informatique, les lecteurs partagés, et qui peut avoir les fichiers ouverts en fait même si elles ont eu une déconnexion disgracieuse autrement.

Comme alternative à pré-test tel exclusivisme sur la table, vous pouvez essayer et exécuter une requête contre le .DBC car il est aussi rien de plus qu'une table elle-même ... Quelque chose comme

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

Il est possible que certains programmes écrasé alors qu'il avait la base de données ouverte (en laissant un verrou de zombie) ou la base de données est connecté via un partage réseau qui ne libère pas la ressource.

Dans ce cas, je suis généralement réduit soit le redémarrage du serveur sur lequel la base de données se trouve ou désinstallez / le disque sur lequel remonter réside la base de données (si sur un SAN ou un disque réseau).

Answer 4

Regardez sur le site de support de Microsoft pour le serveur et les paramètres de verrouillage Opportuniste ouverts en cache. Vous devrez peut-être mettre EnableOplocks à 0 et CachedOpenLimit à 0 que les articles décrivent. Vous trouverez également sur l'accès antivirus est connu pour ce genre de chose.

En plus de l'excellent outil Sysinternals Process Explorer mentionné, j'utilise un outil appelé Unlocker qui vous permet d'un clic droit sur un fichier sur le serveur et voir les processus de verrouillage.

Il y a aussi un autre outil Sysinternals appelé « poignée » qui fonctionne à l'invite et donne beaucoup d'informations sur ce processus ont des poignées sur un fichier ou des fichiers.

Answer 5

Vous pouvez essayer ceci:

1. Redémarrez le serveur (si possible). Maintenant Noone est l'utiliser.

2. Obtenir une liste de tables liées à la DBC et écrire un script pour ouvrir chaque table individuellement et execlusively. Est-ce que des OUVRE échouent?

3. Peut-être, l'une des tables est de retour liée à une table sur un autre serveur.

Juste quelques idées.

Answer 6

Peut-être vaut la peine que vous pouvez l'ouvrir pour un accès partagé pour être sûr qu'il est pas un problème d'autorisations.

Answer 7

J'ai ce message avant et le problème est simple explorateur, exécutez Windows et essayez d'ouvrir le dossier où le fichier situé. si vous ne pouvez pas accéder au dossier, donc ne foxpro visuel. Je suppose que vous utilisez dossier de partage puisque vous mentionnez que vous utilisez lecteur L. cmiiw:)

Answer 8

J'ai eu le même problème (pas exclusif les accès à DBC), mais une autre raison.

Nous protocolage accès et certaines activités dans un fichier texte géré par des commandes de bas niveau (fopen, FSEEK, fputs, FCLOSE, FCREATE). Nous faisons depuis 1er avril 2000, sans aucun problème.

Après un « événement indésirable grave réseau » notre système a fonctionné encore, mais à une vitesse hyper-escargot. Chaque action a pris environ 5 protocole est dressé minutes. FoxPro rejugée évidemment les procédures de bas niveau pendant les 5 minutes et enfin les sautée (sans préavis, d'ailleurs).

Le fichier texte est loin d'une partie de la base de données elle-même. Nontheless, DBC était pas accessible avec un verrou de zombie de la machine (hors tension), qui était également le propriétaire d'un verrou de zombie dans le fichier texte. verrouillage DBC ne pouvait être libéré après le chapeau de verrouillage de fichier thext été supprimé.

Aucune idée, comment cela est connecté, mais après, tout allait bien à nouveau et est encore. Server est Novell Netware, que je ne suis pas faniliar avec.