Newsgroup: it.comp.lang.visual-basic
Titolo: aperture in modo esclusivo mdb condiviso.

Ho un applicazione che gira in rete con un archivio mdb, "non creatra da 
me".
Ogni 2 x 3 si rompe mdb , con conseguente ricompattamento, il problema che 
mdb in rete è condiviso .
DOMANDA: con VB6 come faccio sconnettere tutte le utenza allacciate al in 
oggetto  mdb per far manutenzione ?
Grazie

 al in oggetto  mdb per far manutenzione ?
Non lo fai. Punto.
Al limite, puoi monitorare la directory dell'mdb, e verificare la presenza 
del file .ldb
Nel momento in cui non lo trovi, vuol dire che il db non è aperto da 
nessuno... a quel punto, puoi aprirlo in modalità esclusiva e fare 
manutenzione.
Purtroppo, in alcuni casi, l' ldb è presente anche se nessuno è connesso 
al db (capita quando qualcosa va storto...)
Ciao
-- 
Gianluca Cannalire
Microsoft MVP/MCP - Visual Basic
http://www.visual-basic.it
http://community.visual-basic.it/gianluca
 


In modo nativo non puoi, però ci sono stratagemmi per farlo.
Uno è quello di usare una Tabella nella quale scrivere un Flag(True/
False) e fare in modo che il Client ciclicamente legga il valore della
tabella, quando lo trova = True
si disconnette.
Ci sono ovviamente affinamenti a questa tecnica(registrare gli user
connessi con una Query INSERT all'avvio del Client ed una query DELETE
alla chiusura, poichè il file LDB non è completamente affidabile....
la cosa migliore sarebbe che lato Server girasse un servizio che
ciclicamente cancella gli User Loggati e che i Client ciclicamente lo
riscrivessero, poichè in caso di Crash del DB il file LDB rimarrebbe
aperto e le tabelle di Login piene), ma penso che se vuoi forzare il
LogOff non ci siano molte alternative.
Purtroppo Access non è un DB server, quindi tutte le soluzioni sono
semplicemente accrocchi....!
@Alex

 al db (capita quando qualcosa va storto...)
se i tempi di lavoro non sono molto ravvicinati, filedatetime() puo' essere 
un buon indicatore.
ciao, a. 

"Alessandro Baraldi"
Ci sono ovviamente affinamenti a questa tecnica(registrare gli user
connessi con una Query INSERT all'avvio del Client ed una query DELETE
alla chiusura, poichè il file LDB non è completamente affidabile....
la cosa migliore sarebbe che lato Server girasse un servizio che
ciclicamente cancella gli User Loggati e che i Client ciclicamente lo
riscrivessero, poichè in caso di Crash del DB il file LDB rimarrebbe
aperto e le tabelle di Login piene), ma penso che se vuoi forzare il
LogOff non ci siano molte alternative.
Purtroppo Access non è un DB server, quindi tutte le soluzioni sono
semplicemente accrocchi....!
--
nella pratica ho riscontrato che un accrocchio abbastanza efficace e' una 
cosa del tipo
sub timer1_timer
    on error goto errman
    if adesso=lo-decidi-tu and dir("admin.lock")<>"" then _
         msgbox "pussa via o l'admin ti scuoia vivo e poi ti azzera il 
pc..."
    exit sub
errman: msgbox "l'admin ti azzera vivo e poi scuoia il pc...."
end sub
non so com'e', si sloggano sempre all'istante :)
ciao, a.


Ciao Andrea.
Non ho ben capito quanto hai suggerito....(fà rima)
tnx
@Alex

Ciao Andrea.
Non ho ben capito quanto hai suggerito....(fà rima)
tnx
lavoriamo in 4-5 su un mdb sul server.
con una funzione ms che legge l'ldb (*), vedo se ci sono altri connessi.
un bkp automatico viene fatto ogni ora anche a mdb aperto con 
shfileoperation, se l'mdb cambia.
in ogni modo, quando mi collego anch'io scrive un admin.lock.
due volte al giorno, per mezz'ora (quando voglio sistemare bkp statistiche 
ecc), se esiste l'admin.lock agli altri ogni 60" appare un msgbox di 
scollegarsi.
e se poi non si scollegano entro 2-3' vuol dire che sono via e li scollego 
io con vnc. ma in genere non serve.
ciao, a.
(*) unica parte ado del tutto
cnn.OpenSchema(adSchemaProviderSpecific, , JET_SCHEMA_USERROSTER)
il resto e' dao.

 ha scritto nel messaggio 
news:53ecmqF...@mid.individual.net...





 ciao, a.
Si ho capito, ma tutto stà in piedi se nessun Client o tu stesso
generate Crash sul file MDB
in quel caso l'utente Admin.Lock rimane presente anche se in realtà tu
non sei più connesso, ed è
il motivo per il quale io non mi fido del file LDB e mi sono
realizzato una gestione parallela ed indipendente.
In ogni caso si potrebbe creare un servizio che su timer cerca di
Eliminare il file LDB, se lo elimina significa
che il file MDB era inchidato, di conseguenza il file LDB non
affidabile.
@Alex

"Alessandro Baraldi"
Si ho capito, ma tutto stà in piedi se nessun Client o tu stesso
generate Crash sul file MDB
in quel caso l'utente Admin.Lock rimane presente anche se in realtà tu
non sei più connesso
e/o si e' s/connesso un altro admin, col suo admin.lock, e i due si 
incrociano. ci si potrebbe ragionare, e vagliare la casistica, ma resta il 
fatto che, come dicevi, accrocchi sono...
e' un cocktail di statistica e budget. cosa serve, cosa serve di piu', 
quando capita, e quanto tempo costa.
ciao, a.

 ha scritto
Si ho capito, ma tutto stà in piedi se nessun Client o tu stesso
generate Crash sul file MDB
in quel caso l'utente Admin.Lock rimane presente
dimenticavo. forse qualcosina di meglio si puo' probabilmente ottenere 
appunto con userrooster
http://support.microsoft.com/default.aspx?kbid=285822
ho provato adesso a lanciare due istanze da due pc diversi: la showusers 
mostrava le due connessioni.
facendone andare una in crash, la showusers ne mostra una sola, quindi direi 
che aggiorna.
ciao, a.

> 
http://support.microsoft.com/default.aspx?kbid=285822
e
http://www.mvps.org/access/general/gen0034.htm
ciao, a.

 ciao, a.
Purtroppo credo che le tue ipotesi siano tutte corrette solo se la
connessione in rete funziona, e che quindi la caduta della connessione
al DB sia vista...!
Concordo con te sugli accrocchi, è la prima osservazione che ho fatto,
e concordo
sullo studio di casistiche, ma se hai problemi con la rete nessuno ti
aggiorna il file LDB, e l'unico modo per farle una cosa funzionale è
che lato Server ci sia qualche ammennicolo che fà qualcosa... (la
filosofia dei Server) perchè l'aggiornamento degli LDB viene fatto
dalle connessioni dei client(Rete intranet/scheda di rete/ecc.. di
rete permettendo).
Quando dicevo che il Crash crea problemi non intendevo il PC ma la
connessione dell'applicativo verso il DB che non aggiorna più il file,
e non è semplice simularla...
anche perchè spesso si corrompeva il DB...
Il link al sito nel post sotto lo conosco bene, io però, per
esperienza personale, maturata qualche anno fà(ora non uso più JET da
diverso tempo come DB in rete ma solo per impostazioni locali) ti
posso assicurare che il problema esiste, e con l'accrocchio che ho
ipotizzato ho solo provato a mettere una pezza lato server e non lato
client perchè personalmente la ritengo sempre la strategia migliore.
@Alex