Newsgroup: it.comp.appl.access
Titolo: Evitare doppia apertura dello stesso mdb

Ciao. 
Esiste un modo semplice per verificare (e in caso positivo) chiudere un mdb se lo stesso è già aperto?
Questa la casistica:
L'utente "a" apre il db "db1"
Sempre l'utente "a" riapre lo stesso db perché non si è accorto che lo aveva già aperto. 
Avrei bisogno che "db1" si accorga che è già 
stato aperto dall'utente "a" e per tale ragione si chiuda. 
Non posso utilizzare "apertura con accesso esclusivo". 
 
Grazie!
Omar

Dimenticavo: siamo su Access2003

 Non posso utilizzare "apertura con accesso esclusivo". 
 
fa pensare ad un utilizzando in multiutenza di un mdb
NON suddiviso in BackEnd e FrontEnd ...
 
ma, per dare un suggerimento:
lo scopo di NON far aprire più copie dallo stesso utente
si ottiene anche inserendo l'opzione accesso esclusivo
come argomento in una linea di comando (in uno script) 
che lancia sia Access e sia il file mdb
 
così facendo si evita di agire con il flag "accesso esclusivo" sul file mdb

Il giorno venerdì 1 settembre 2017 08:54:12 UTC+2, iLanders ha scritto:

 aggiungo una considerazione meno agostana,
precisando che non sono in grado di dare riferimenti
su come rintracciare un processo attivo nella lista dei task attivi
 
si tratta di testare, con uno script, il comportamento del ldb sul posto di lavoro (se nel posto c'è un file mdb), 
test che comunque ha la sua magagna,
 
inoltre non so se è presentabile perchè si può pensare che la tua sia una situazione in cui ogni postazione lavori con un link ad una unica installazione del programma su server (o in remote desktop),
o con più utenti sulla stessa copia nello stesso pc
 
è da eseguire l'istruzione di CANCELLAZIONE del file ldb
e poi segue, o meno, l'apertura del file mdb
 
si hanno queste possibilità:
-- ACCESSO NEGATO (occorre gestire l'errore, avvisare e uscire)
-- FILE NON TROVATO (occorre gestire l'errore e lanciare Access + file mdb)
-- CANCELLAZIONE CHE VIENE EFFETTUATA (NON ci sono errori, è un falso positivo, si può lanciare Access + file mdb)
-- FALSO NEGATIVO: accesso negato SENZA che ci sia il file mdb aperto (è la magagna possibile)
Posso lasciare l'esempio dello script

Ciao Giorgio. 
Credo di capire che la tua soluzione vada bene ma per un'architettura diversa dalla mia. 
 
Il mio utente si collega in RDP su un server e apre la sua applicazione (che ricordo essere un FE+BE). 
Vorrei evitare che entri sul server una seconda volta (operazione questa volutamente permessa), ma che all'apertura dell'applicazione (già aperta prima) venga informato che l'ha già aperta e non glielo permetta. 
La lettura del file ldb mi sembra poco robusta, perché a volte si impalla (con tutti gli utenti scollegati non viene rimosso), a volte contiene due volte lo stesso utente, etc.
Anche se a dire il vero è l'unico modo "automatico" per sapere quali utenti sono collegati. 
L'alternativa sarebbe creare una tabella di supporto dove registrare chi si collega (è fin qui ok), da controllare ad ogni accesso. 
Il mio problema è che ogni utente ha un unico punto di ingresso all'applicazione (posso intercettarlo univocamente), ma ha la possibilità di uscire da varie vie (maschere diverse). Vorrei evitare di doverle controllare tutte. 
Ed in ogni caso, in caso di crash, il codice per cancellare l'utente dalla tabella di supporto non verrebbe eseguito (questo problema cel'avrebbe anche la soluzione con ldb, a dire il vero). 
Qualche idea (se c'è) più affidabile?
Grazie!

 Il mio problema è che ogni utente ha un unico punto di ingresso all'applicazione (posso intercettarlo univocamente), ma ha la possibilità di uscire da varie vie (maschere diverse). Vorrei evitare di doverle controllare tutte. 
 
non so come hai strutturato l'appicazione ma in ogni caso potresti far uscire da un unico modo (eventualmente nascondendo passaggi all'utente)

Riflettendoci, mi sa che è l'unica strada percorribile. 
Devo solo  "incanalare" meglio l'utente quando esce dall'app. in modo da intercettarlo e toglierlo dalla tabella di supporto. 
Faró anche in modo che un utente amministratore non venga registrato nella tabella di supporto, per poter gestire la casistica del crash (in caso di crash, se un utente non venisse cancellato dalla tbl di supporto non potrebbe più rientrare poiché verrebbe visto come secondo accesso. 
Serve pertanto un utente che non esista mai nella tabella di supporto, oppure la cui presenza venga ignorata. Mi aspetto che un utente amministratore "stia più attento" degli altri nell'evitare un doppio accesso. Questo utente poi toglierà a mano quelli che rimangono "appesi" in seguito al crash. 
Mi pare che così si chiuda il cerchio.
Grazie a tutti degli spunti!
 

Non sono certo di aver capito bene l'esigenza, ma per evitare MULTIISTANZE del Client potrebbe essere bene delegare al S.O. usando i MUTEX, come già suggerito in un recente 3D:
 
https://www.experts-exchange.com/articles/2104/Avoiding-running-multiple-instances-of-an-application.html
 
 
@Alex
 

Ciao Alex, suggerimento grandioso!
Questa si che è una soluzione robusta!
Approfondisco l'argomento al volo. 
Grazie!!!