Visual FoxPro - File Accesso negato

Question

Il nostro sistema ERP è un ibrido. Il dato reale è SQL, ma le tabelle che contengono informazioni sugli utenti, i profili, i diritti, la sicurezza, ecc è in Visual FoxPro.

Ho bisogno di ottenere l'accesso esclusivo al database VFP. Tolgo tutti, dal sistema utilizzando il programma stesso, e indica tutti sono fuori dal sistema. Ottengo la seguente risposta al seguente codice:

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

La risposta che ottengo è: Il file Accesso negato. Sono andato in Server Manager e nessuno ha i file aperti nella directory VFP.

C'è un comando in VFP che mi permetterà di determinare chi / che cosa ha il file aperto e / o di un modo per uccidere tutte le sessioni all'interno di FoxPro che fare?

Ho provato googling, ma non ha avuto fortuna.

Answer 1

Si potrebbe voler controllare il Process Explorer da Sysinternals (Microsoft).

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

È possibile utilizzare la funzione Trova | Handle di file o l'opzione di menu DLL e messi nel nome del file DBC. Process Explorer vi dirà l'ID di processo e il processo che ha aperto il file.

Se si condivide il file sulla rete (file server o peer-to-peer), oltre al capo del "server" ed eseguire Gestione computer. Drill-down nei Cartelle condivise> Apri file e si dovrebbe auspicabilmente, vedere la lista dei file aperti sul computer da parte di altri utenti della rete.

Rick

Answer 2

Come accennato da Jeff, una cosa potrebbe essere quando un incidente sulla macchina di una persona, e ottengono disconnesso dalla rete. Il server pensa ancora il file è aperto ad un certo manico di basso livello. Poi, quando l'utente ri-collega, tutte le impostazioni precedenti sembrano auto-magicamente ottenere rilasciato, tornare nel sistema, allora tutto sembra andare bene. Inoltre, controllare dal server In Gestione computer, dischi condivisi, e che possono avere i file effettivamente aperto anche se possono aver avuto una disconnessione sgraziata altrimenti.

Come alternativa al pre-test, quali l'esclusività sul tavolo, si consiglia di provare a eseguire una query sul DBC in quanto troppo non è niente di più di una tabella stessa ... Qualcosa di simile

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

E 'possibile il qualche programma andato in crash mentre aveva il database aperto (lasciando un blocco di zombie) o il database è collegato tramite una condivisione di rete che non rilascia la risorsa.

In questi casi, sono generalmente ridotte a uno riavviare il server in cui si trova il database o smontaggio / rimontaggio della piastra in cui risiede il database (se su una SAN o un disco di rete).

Answer 4

Guarda sul sito di supporto di Microsoft per server di blocco opportunistico e le impostazioni di cache di Open. Potrebbe essere necessario impostare EnableOplocks a 0 e CachedOpenLimit a 0 per gli articoli descrivono. Anche la scansione in accesso dei virus è noto per questo genere di cose.

Oltre allo strumento Process Explorer eccellenti SysInternals detto, io uso uno strumento chiamato sblocco che consente di fare clic destro su qualsiasi file sul server e vedere i processi di blocco.

C'è anche un altro strumento di SysInternals chiamata 'manico' che corre al prompt e dà un sacco di informazioni su quali processi hanno maniglie su un dato file o file.

Answer 5

Si potrebbe provare questo:

1. Riavviare il server (se possibile). Ora nessuno lo utilizza.

2. Ottenere un elenco di tabelle collegate al DBC e scrivere uno script per aprire ogni tavolo individualmente e execlusively. Eseguite una delle apre falliscono?

3. Forse, uno dei tavoli è di nuovo collegato a una tabella su un altro server.

Solo alcune idee.

Answer 6

Potrebbe valere la pena fare in modo è possibile aprirlo per l'accesso condiviso per essere sicuri che non è un problema di autorizzazioni.

Answer 7

ho avuto quel messaggio prima e il problema è semplice, eseguire Windows Explorer e tenta di aprire la cartella in cui trova il file. se non è possibile accedere alla cartella, così fa di Visual FoxPro. Presumo che si sta utilizzando la cartella di condivisione in quanto si parla che si sta utilizzando un'unità L. cmiiw:)

Answer 8

Ho avuto lo stesso problema (non esclusivo accessi DBC), ma un altro motivo.

Siamo protocollazione di accesso e alcune attività in un file di testo gestito tramite comandi di basso livello (FOPEN, fseek, fputs, FCLOSE, FCREATE). Stiamo facendo in modo dal 1 aprile 2000, senza alcun problema.

Dopo un "evento di rete avversa grave" il nostro sistema continua a correre, ma a velocità iper-lumaca. Ogni azione protocollate sono voluti circa 5 minuti. FoxPro ovviamente ritentato le procedure di basso livello durante i 5 minuti e infine li saltato (senza alcun preavviso, btw).

Il file di testo non è affatto parte del database stesso. Ma la vera, DBC non era accessibile con un blocco di zombie dalla macchina (spento), che è stato anche il proprietario di un blocco di zombie al file di testo. Blocco DBC potrebbe essere rilasciato solo dopo che stato rimosso il cappello di blocco del file thext.

Non ne ho idea, come questo è collegato, ma poi, tutto è andato bene di nuovo e lo è ancora. Server è Novell Netware, che non mi faniliar con.