Newsgroup: it.comp.appl.access
Titolo: Contare gli accessi al BE

Salve a tutti.
Ho un programma strutturato in FE e BE; quest'ultimo risiede su un server. Gli utenti sono in totale 6. Uno di questi è abilitato ad effettuare le copie di salvataggio del DB, ma prima di effettuarlo deve chiedere a tutti gli altri di disconnettersi. Esiste un modo automatico di controllare quanti utenti stanno utilizzando il DB? Ho ipotizzato di contare gli accessi, e se sono maggiori di 1 (l'utente che salva) avvisare che altri lo stanno utilizzando, ma non so come fare.
L'applicativo è sviluppato con Access 2013 x86, gli utenti lo usano con Access Runtime.
Saluti
Franco

 Ho un programma strutturato in FE e BE; quest'ultimo risiede su un server. Gli utenti sono in totale 6. Uno di questi è abilitato ad effettuare le copie di salvataggio del DB, ma prima di effettuarlo deve chiedere a tutti gli altri di disconnettersi. Esiste un modo automatico di controllare quanti utenti stanno utilizzando il DB?...
 
Quasi automatico, cioè con un po' di codice VBA: Puoi vedere gli utenti 
attuali del BE con il User Roster di ADO. Vedi l'esempio qui: 
http://www.fmsinc.com/MicrosoftAccess/monitor/user-roster.htm
 
 
-- 
Ciao
Karl
*********
http://www.AccessDevCon.com
 
Access FAQ: 
http://www.donkarl.com/it
 

> Ho un programma strutturato in FE e BE; quest'ultimo risiede su un server. Gli utenti sono in totale 6. Uno di questi è abilitato ad effettuare le copie di salvataggio del DB, ma prima di effettuarlo deve chiedere a tutti gli altri di disconnettersi. Esiste un modo automatico di controllare quanti utenti stanno utilizzando il DB? 
 
aggiungo un rilievo personale
e, come sempre, seguo volentieri altre precisazioni
essendo questo uno degli argomenti di mio (maggior) interesse
 
In situazioni simili:
FE mde A2000-2003 lanciato con uno script vbs (quindi "sempre nuovo"), 
postazioni anche superiori a 10, con un utente che può definirsi "regista"
ho questi due approcci (che NON si escludono)
 
- "sbrigativo"
dalla postazione regista viene effettuata una SEMPLICE copia del BE
"disinteressandosi" del fatto che ci siano utenti connessi
con uno script vbs che ha l'istruzione di copia file
E ANCHE le istruzioni che rinominano un numero di copie (almeno 5) precedenti
 
Al riscontro effettivo, pur effettuando dal SO una copia del BE "alla cieca" 
(senza accorgimenti particolari), 
non è mai (ancora ?) accaduto che le copie avessero degli errori 
 
- "più accurato"
FORZATURA del logout di TUTTI gli utenti con apposita routine
(se cerchi ci sono esempi anche in questo gruppo,
comunque ho utilizzato, come base, questo download free:
http://www.peterssoftware.com/fsd.htm
 
che penso sia valido anche per A2013)
 
quindi:
inserimento del "segnale" di logout
(un file txt nella cartella server,
la cui presenza viene testata dalla routine di logout nel FE)
copia del BE su cartella di scopo, 
compattazione del BE copiato, 
reinserimento del BE nella cartella "server"
 


Innanzi tutto grazie ad entrambi.
Ho avuto tempo di testare solo la soluzione di Karl, che però mi restituisce un messaggio di errore: "Jet non è in grado di aprire il file perché è aperto in accesso esclusivo da altro utente o perché occorre disporre dell'autorizzazione per visualizzare i dati"
di seguito posto il codice di richiamo della funzione UtentiCollegati (l'ho rinominata per mia comodità).
il nome del DB lo costruisco con due mie funzioni, che richiamano il percorso e il nome; la MSGBOX intermedia mi restituisce l'esatto nome del DB.
 
Private Sub Comando0_Click()
    Dim Conn As ADODB.Connection
    Dim NomeCompletoDB As String
    NomeCompletoDB = PercorsoDB("BE") & NomeDB("BE")
    MsgBox NomeCompletoDB
    Set Conn = New ADODB.Connection
    With Conn
        .CursorLocation = adUseServer
        .Open "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & NomeCompletoDB & ""
    End With
    Debug.Print UtentiCollegati(Conn)
End Sub
 
Che cosa sbaglio?
 
Per la soluzione suggerita da Giorgio, posso solo dire che anch'io finora ho sempre effettuato il salvataggio non curandomi di chiudere il BE, ed è sempre andato a buon fine (apparentemente). Se mi confermate che non ci sono problemi posso anche evitare di controllare l'utilizzo o meno del BE.
Saluti
Franco


Ho visto la demo suggerita da Giorgio, ma credo che sia più adatta ad effettuare la manutenzione del DB piuttosto che il salvataggio. Occorre tenere presente che l'eventuale backup viene effettuato da uno degli utenti (il "regista"), quindi se si lanciasse l'avviso contenuto nell'esempio, verrebbero disconnessi tutti gli utenti, regista compreso.
Saluti
Franco

 Ho visto la demo suggerita da Giorgio, ma credo che sia più adatta ad effettuare la manutenzione del DB piuttosto che il salvataggio. Occorre tenere presente che l'eventuale backup viene effettuato da uno degli utenti (il "regista"), quindi se si lanciasse l'avviso contenuto nell'esempio, verrebbero disconnessi tutti gli utenti, regista compreso.
 
con utenti TUTTI scollegati e che NON possono ricollegarsi
(cosa che si ottiene abbinando la routine di forzatura logoff
CON il lancio del FE tramite script che controlla la presenza del segnale di blocco ESTERNO al BE !!!)
la copia del BE, con le semplici istruzioni del SO, diventa "più sicura"
(lo posso dire anch'io ...) 
 
Da parte mia posso solo rimarcare che, se non le hai già presenti,
conviene davvero prendere familiarità con le istruzioni vbscript
che, di fatto, permettono queste operazioni (e sono poche per questi scopi).
Considera anche che queste istruzioni possono essere riunite
in files ad esecuzione diretta (estensione .vbs)
oppure inserite in routines all'interno di Access.
 
Confermo che le copie "sbrigative" del BE
NON hanno mai comportato corruzioni del BE stesso
(però il distacco di TUTTI i client appare "più consigliabile")


Grazie Giorgio per le delucidazioni; appena possibile proverò il tuo suggerimento. Per quanto riguarda le istruzioni vbscript non le conosco: mi riprometto di studiarle.
 
Per quanto riguarda invece il messaggio di errore relativo alla demo di Karl, preciso che gli utenti lavorano spesso tutti in contemporanea senza problemi; l'accesso lo controllo con una tabella degli utenti abilitati e solo quelli presenti in tabella possono accedere. Credo quindi che il problema non sia relativo all'accesso esclusivo da parte di qualcuno.
Saluti
Franco

 ...
Prova se funziona con una database locale sul tuo disc, prima senza 
utente, poi con solo te come utente.



Ciao Karl,
ho fatto la prova che mi hai suggerito, ora il messaggio è diverso: "Formato file non riconosciuto".
E' possibile che il problema sia la stringa che passo come costante ({947bb102-5d43-11d1-bdbf-00c04fb92675})?
Ricordo che il formato è .accdb (Access 2013).
Grazie 
Franco

 ...
 
Prova di aggiornare il Provider, cioè sostituire
 
.Open "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & NomeCompletoDB & ""
 
con
 
.Open "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=" & NomeCompletoDB



Grazie Karl,
ho trovato anch'io sul web la possibilità di modificare la stringa come suggerito; in effetti la finestra immediata, interrogata in merito, mi restituisce ACE.OLEDB.12.0.
Con questa correzione, se interrogo un BE sul mio PC mi restituisce il dato (ovviamente ci sono collegato solo io), ma se faccio la stessa prova sul BE vero, messo sul server, mi restituisce sempre lo stesso errore: "Il DB è aperto in modo esclusivo da altro utente".
Posto la posizione del BE:
"\\fileservernord\torino\dtp02\UO SICUREZZA\02 SICUREZZA LAVORO\Cartella di Reparto\VISITE MEDICHE\DATABASE\ScadenzaVisiteTabelle.accdb".
Ho controllato le impostazioni avanzate del DB, che sono:
Modalità di apertura predefinita: condiviso.
Blocco record predefinito: nessun blocco.
Apri database con blocco a livello si record (Sì).
Ho provato anche a disabilitare quest'ultima impostazione, ma non è cambiato nulla.
Saluti e grazie comunque per la pazienza
Franco

 ...
 
Spesso il problema non è questa parte del messaggio ma l'altra, cioè un 
problema con i diritti sul network share = percorso UNC o cartella.
 
Qualche volta il colpevole è anche un processo non terminato bene. 
Almeno questa variante puoi testare con un file accdb diverso/nuovo 
nello stesso percorso. Se ti dà lo stesso errore, è molto probabile che 
si tratta di un problema con i diritti.



OK proverò, grazie. E grazie anche a Giorgio.
Franco