Visual FoxPro - L'accès au fichier est refusé

Question

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

J'ai besoin d'un accès exclusif à la base de données VFP. Je retire tout le monde du système en utilisant le programme lui-même, et cela indique que 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 j'obtiens est: Accès au fichier est refusé. Je suis allé dans le gestionnaire de serveur et personne n'a de fichiers ouverts dans notre répertoire VFP.

Existe-t-il une commande dans VFP qui me permettra de déterminer qui/quoi le fichier est ouvert et/ou un moyen de tuer les sessions dans FoxPro qui le font?

J'ai essayé de le googler mais je n'ai pas eu de chance.

Answer 1

Vous pouvez consulter l'Explorateur de processus de Sysinternals (Microsoft).

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

Vous pouvez utiliser la zone Rechercher | File Handle ou option de menu DLL et mettre dans le nom du fichier DBC. Process Explorer vous indiquera l'ID du processus et le processus dans lequel le fichier est ouvert.

Si vous partagez le fichier sur le réseau (serveur de fichiers ou poste-à-poste), rendez-vous sur le «serveur» et exécutez Gestion de l'ordinateur. Parcourez les dossiers partagés> Ouvrir les fichiers et vous devriez voir la liste des fichiers ouverts sur l'ordinateur par d'autres utilisateurs sur le réseau.

Rick

Answer 2

Il est possible que certains programmes se soient plantés alors que la base de données était ouverte (laissant un verrou zombie) ou que la base de données soit connectée via un partage réseau qui ne libère pas la ressource. Dans ce cas, je suis généralement réduit au redémarrage du serveur sur lequel se trouve la base de données ou au démontage/remontage du disque sur lequel réside la base de données (sur un réseau SAN ou sur un disque réseau).

Answer 3

Comme mentionné par Jeff, une chose pourrait être quand un accident sur la machine d'une personne, et ils se déconnectent du réseau. Le serveur pense toujours que le fichier est ouvert à une poignée de bas niveau. Ensuite, lorsque l'utilisateur se reconnecte, tous les paramètres précédents semblent être automatiquement libérés, revenir dans le système, puis tout semble bien se passer. En outre, vérifiez FROM THE SERVER sous la gestion de l'ordinateur, les lecteurs partagés, et qui peut avoir les fichiers effectivement ouverts, même si elles peuvent avoir eu une déconnexion disgracieuse sinon.

Comme alternative à pré-test tel exclusivisme sur la table, vous pouvez essayer de lancer une requête sur la .DBC car elle aussi est 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 4

Regardez sur le site de support de Microsoft pour le serveur Opportuniste paramètres de verrouillage et ouverts en cache. Vous devrez peut-être définir EnableOplocks sur 0 et CachedOpenLimit sur 0 comme les articles décrivent. La recherche de virus sur accès est également connue pour ce genre de choses.

En plus de l'excellent outil SysInternals Process Explorer mentionné, j'utilise un outil appelé UnLocker qui vous permet de faire un clic droit sur n'importe quel fichier sur le serveur et de voir les processus de verrouillage.

Il existe également un autre outil SysInternals appelé «handle» qui s'exécute à l'invite et donne beaucoup d'informations sur les processus qui gèrent un ou plusieurs fichiers.

Answer 5

Vous pouvez essayer ceci:

1. Redémarrez le serveur (si possible). Maintenant, personne ne l'utilise.

2. Obtenez une liste des tables liées au DBC et écrivez un script pour ouvrir chaque table individuellement et de manière exécutive. Est-ce que l'une des ouvertures échoue?

3. Eventuellement, l'une des tables est de nouveau liée à une table sur un autre serveur.

Juste quelques idées.

Answer 6

J'ai déjà reçu ce message et le problème est simple, lancez l'explorateur Windows et essayez d'ouvrir le dossier où se trouve le fichier. Si vous ne pouvez pas accéder au dossier, c'est aussi le cas de Visual FoxPro. Je suppose que vous utilisez le dossier de partage puisque vous mentionnez que vous utilisez le lecteur L. cmiiw :)

Answer 7

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

Nous surveillons l'accès et certaines activités dans un fichier texte géré via des commandes de bas niveau (FOPEN, FSEEK, FPUTS, FCLOSE, FCREATE). Nous le faisons depuis le 1er avril 2000, sans aucun problème.

Après un «événement de réseau négatif sévère», notre système fonctionnait toujours, mais à une vitesse d'hyper-escargot. Chaque action protocolée a pris environ 5 minutes. FoxPro a évidemment réessayé les procédures de bas niveau pendant les 5 minutes et les a finalement sautés (sans aucun préavis, btw).

Le fichier texte ne fait en aucun cas partie de la base de données elle-même. Néanmoins, DBC n'était pas accessible avec un verrou zombie de la machine (éteint) qui était également le propriétaire d'un verrou de zombie au fichier texte. Le verrou DBC ne peut être libéré qu'après la suppression du verrou du fichier thext.

Aucune idée, comment cela est connecté, mais après, tout allait bien encore et l'est toujours. Le serveur est Novell Netware, avec lequel je ne suis pas fan.

Answer 8

Il est peut-être utile de vous assurer que vous pouvez l'ouvrir pour un accès partagé afin de vous assurer qu'il ne s'agit pas d'un problème d'autorisations.