Newsgroup: it.comp.lang.visual-basic
Titolo: Danneggiamento file Jet con Win2k

Ho scritto un software con VB6 e Jet 3.5 un paio di anni fa. Con un
sistema Win9x funzionava tutto perfettamente, ora il sistema č passato
integralmente a Win2k e succede che in continuazione il file del
database .mdb si danneggia dopo che gli utenti vi memorizzano dei
dati. Dopo un'ora-due di accessi in scrittura (in lettura nessun
problema) concorrenti da parte degli utenti senza alcun apparente
errore, il database si danneggia e non c'č verso di leggerlo nemmeno
con Access (oppure solo dopo una riparazione).
Qualcuno di voi č a conoscenza di eventuali problemi fra Win2k
professional o server e il Jet 3.5?
Sono disperato e non so che pesci pigliare!! Vi ringrazio tutti.

 professional o server e il Jet 3.5?
Non ho spiegazioni logighe, ma mi è successo qualcosa del genere. E' bastato
inserire fra i riferimenti DAO 3.6 al posto di DAO 3.51 e tutto, senza
convertire i database da 97 a 2000, si è magicamente risolto. Spero che
basti, fai solo attenzione alla CompactDatabase e alla CreateDatabase. Credo
che siano gli unici interventi da fare sul codice.

 Sono disperato e non so che pesci pigliare!! Vi ringrazio tutti.
E' cambiato anche il sistema o solo l'OS?
Potrebbe essere il driver del controller, oppure qualche
difetto/incompatibilità HW...

No, adesso PROBABILMENTE ho scoperto cos'è!!!
Mai sentito parlare del problema "OPLOCK"?
In due parole: Win2k (sia server che client) hanno un bug immenso che
porta a distruzione gli archivi Jet (qualunque versione, fino ad
arrivare ad Access 2002, cioè Jet 4.0) quando più postazioni vi
accedono in scrittura contemporaneamente.
E ciò è indipendente dal tipo di accesso impostato via codice (blocco
ottimistico, pessimistico e menate varie).
Increduli? Effettivamente non sono riuscito a trovare nulla in
italiano relativo a questo bug; sul sito microsoft (VERGOGNA PLURIMA)
c'è un misero accenno senza risoluzione.
C@@@@! Ma è un bug immenso!!!!!
La soluzione la si trova su Google: un tizio con suffisso di posta
"@
microsoft.com
" suggerisce un metodo che sto sperimentando adesso e
che pare funzionare, a patto di perdere parecchi punti dal versante
prestazionale.
Nessuno di voi ha esperienza di questo problema?
Ciao e grazie per le risposte!

 prestazionale.
Potresti citare qualche indirizzo? Grazie.


Mi accodo...! ;)

 Nessuno di voi ha esperienza di questo problema?
Ho letto di problemi simili se si utilizzava access e un archivio installati
sullo stesso share samba...
Non ho notato ancora problemi simli se non dipendenti dalla rete! Appena
possibile (settimane mesi direi dato che il software non è ancora pronto)
farò una serie di test di accesso dati concorrente in modo pesante...
pensavo di costruirmi un tool per il test! ;)
hth

...

Chiedo scusa per la pochezza di info del mio messaggio, ma questo bug
mi ha generato così tanti problemi che non ho avuto un attimo di
pausa.
Dunque, per ora disattivando la funzione OpLock sul server Win2k non
ho avuto altre corruzioni dei file (PER ORA); tutto questo da giovedì
pomeriggio, cioè solamente una giornata abbondante di lavoro: troppo
poco per gridare al successo.
Gli unici link sull'argomento sono, ahimè, quelli evidenziati da te
nell'altro messaggio. O meglio, ce ne sono tantissimi altri, ma che
conducono essenzialmente lì e basta.
Il massimo "esperto" della questione parrebbe essere un certo Tony
Toews, che ha inserito nel suo sito una pagina riepilogativa
interessante. La trovate qui:
http://www.granite.ab.ca/access/myinfopages.htm
E' da notare, comunque, che il problema NON riguarda i soli file di
Access (97, 2000, 2002) ma QUALUNQUE file di grosse dimensioni
condiviso con più accessi simultanei in scrittura in una rete Win2k
(server e/o client).
Da notare, ancora, che le patch risolutive NON SONO DISPONIBILI sul
sito Microsoft, ma vanno richieste appositamente al servizio supporto
tecnico; gratuitamente, dicono loro, ma chissà?
Per il momento ancora non le ho richieste. La mia soluzione (speriamo)
per ora è stata quella di disabilitare il blocco opportunistico
direttamente dal server. Parrebbe non essere necessario ripetere
l'operazione anche sui client, perché quando il server nega il blocco
il client non crea la cache locale e tutto fila liscio. Ripeto:
parrebbe, perché il tutto è in fase di valutazione presso il cliente
da soltanto una giornata: non è successo nulla, però, e prima
bastavano pochi minuti di lavoro per devastare il file .mdb!...
Anche i link di Google che suggerisci sono corretti; ne esistono molti
altri, ma ancora una volta i documenti di riferimento sono i due o tre
da te citati.
Aggiungo solo un altro link molto completo e aggiornato:
http://www.dataaccess.com/whitepapers/opportunlockingreadcaching.html
Infine c'è da qualche parte in Google un thread con il messaggio che
mi ha aperto gli occhi, firmato da [non ricordo]@
microsoft.com
, ma non
riesco a trovarlo nuovamente.
Ciao!