Newsgroup: it.comp.appl.access
Titolo: Corruzione mdb con biprocessore Xeon

Salve a tutti!
Sottopongo alla vostra illuminata attenzione il problema che mi sta
logorando :
win 2000 server
(dual Xeon 2.4 - raid sata - Access 97) dove gli utenti accedono via
terminal
service ad un mdb di circa 100 mega di sole tabelle (fe),  si ha un errore
durante la
compattazione:
Impossibile leggere record. Autorizzazione a lettura dati non disponibile
per D:\mydb.mdb
Dopo i vari controlli del caso, scopro che in alcune tabelle si sono messi a
null alcuni records, chiavi comprese, e da qui l'errore di compattazione.
Importo tutte le tabelle in un nuovo db, sistemando tutte le chiavi delle
tabelle corrotte, ricompatto e via senza errori.
Lo stesso problema si ripresenta andando a compattare dopo qualche tempo,
trovo errori di chiave in tabelle diverse ma tutte di grande dimensione con
campi contatore in chiave primaria, in modo random, 2 o 3 records corrotti
in 1 o 2 tabelle.
In alcuni casi l'esecuzione di "ripristina database" ha successo e
sucessivamente si riesce a compattare senza errori, altre volte fallisce
l'azione di ripristina database con errore di chiave null.
Si poteva attribuire qualche colpa al fe o alla rete o all'installazione di
access ma durante il lavoro degli utenti non si verifica MAI nessun errore
sui dati, accade raramente che qualche be si rovini e non sia piu'
riconosciuto come database di access.
Ma come se non bastasse adesso arriva il bello:
se copio l'mdb rovinato su di un altro pc e lo compatto, magia torna a
posto.
Sono arrivato alla conclusione che l'archivio non e'
corrotto in realtà, ma bensì ci sia qualche write lock su tabelle di grandi
dimensioni che impedisca il buon esito dell'operazione di compattazione.
Girovagando sul sito ms ho trovato un bollettino inquietante che potrebbe
fare al mio caso:
Dual Processor Computer Hangs When Running Query
http://support.microsoft.com/default.aspx?scid=kb;EN-US;178650
inutile dire che avevo già installato il jet3.5sp3 (che avrebbe dovuto
risolvere il problema..).
Disabilitando l'hyper-threading dello xeon va notevolmente meglio, cioè la
frequenza di errori durante la compattazione e' diminuita ma il problema
sussiste, e non è sicuramente una situazione affidabile.
Ergo jet3.5 non è compatibile con dual Xeon?
E' possibile provare ad usare il jet 4.0 con access 97? (e come? :))
Scusate per la lunghezza del post e grazie per qualsiasi suggerimento.
Ale.

 ha scritto nel messaggio
news:c0q6r0$7r1$1...@news.flashnet.it...

Il tuo messaggio ne ricorda uno postato oltre due anni fa; allora si arrivò
alla conclusione che i problemi di corruzione delle chiavi di un database
Access 97 era dovuto all'uso, in certi client in rete, di schede di rete
Realtek.
Allora ci fu una disputa se la cosa dipendesse dall'hardware delle schede o
dal loro driver: qualcuno sosteneva che per risolvere il problema era
sufficiente aggiornare i driver; altri invece tagliarono la testa al toro
eliminado dal network aziendale tali tipi di schede di rete, e di
conseguenza i loro driver.
Se ti interessano in dettaglio la analisi che allora vennero fatte, ti
conviene ricercare sul SitoComune o su Google i messaggi di allora di questo
NG in cui si parlava delle schede Realtek.
-- 
Roberto
---------------------------------------------
il Sito Comune di it.comp.appl.access:
http://www.sitocomune.com
---------------------------------------------


Grazie Roberto, gentile come sempre.
Eventualità già considerata, esistono si' tali schede nella mia rete,
peraltro con gli ultimi drivers aggiornati, ma ne escluderei la colpa per
questi motivi:
- Nessun client accede direttamente ai dati.mdb in quanto si connettono solo
in terminal service e l'esecuzione del fe / be rimane in locale sul server.
- I problemi sono iniziati quando e' stato sostituito il server (scheda di
rete intel), prima era un pentium 4 con mono processore e mai avuto nessun
problema di sorta con accces, il parco client e struttura della rete sono
rimasti identici.
- Ho provato a rete scollegata a reimportare tutte le tabelle in un nuovo db
e lanciare la compattazione piu' volte, ottenendo lo stesso errore.
Mi si rafforza in testa sempre piu' l'idea che il problema stia nel
biprocessore,  in un' anomala chiusura del task, se il server salta da una
cpu all'atra durante l'esecuzione di access se si lancia un'elaborazione
"pesante".
Addirittura con la modalità hyper-threading (che ho disabilitato da bios) le
cpu erano 4, e gli errori piu' frequenti.
Del resto non credo che supportino piu' a97, tantomeno sulle nuove
architetture hardware, una patch su questo eventuale bug me la posso
sognare.
Sto valutando l'upgrade ad Access Xp, non vorrei fosse inutile, anche perchè
a parte il costo c'e un sacco di lavoro per convertire il fe che spara
centinaia di errori in fase di conversione :)
Ale.

 ha scritto nel messaggio
news:c0qlmo$buc$1...@news.flashnet.it...

La tua ipotesi è verosimile. Nella mia azienda alcuni anni fà ho avuto
problemi con un applicativo Access 95 in ambiente Windows NT 4.0 quando
questo girava su un biprocessore della Dell ed eravamo costretti ad usare un
mono processare, con tutte le conseguenze del caso in termini di
performance.
In seguito l'applicativo fu upgradato con Access 2000 usando anche SQL
Server ed il problema è scomparso, ma non siamo mai riusciti a sapere con
certezza dalle persone della software house (neppure torturandoli) da cosa
dipendesse il problema; loro ipotizzarono sempre che dipendeva
dall'hardware, penso per paura che se fosse dipeso dal software avrebbero
potuto pagare delle penali, visto che il progetto era chiavi in mano.



Mi sono fermato prima di tutta la spiegazione tecnica poichè
sei andato in un campo che non conosco....., ma oltre a quello che ha
detto Roberto se non ricordo male A97 ha evidenziato problemi con
la compattazione di File superiori ad una certa dimensione, il problema
è già stato postato, ma giuro non ricordo gli estremi....!
PEr quanto riguarda la conversione invece non allarmarti è più semplice
di quello che credi.
Prima di tutto ci sono problemi sulla Libreria ADO(Default per le
versioni>97)
di conseguenza devi eliminarla dai riferimenti(A meno di non volere
realmente
riprogettare il FE) e vai a cercare DAO penso 3.6 se installi i SP
aggiornati.
NEssuna modifica ulteriore dovrebbe essere necessaria.
Ciao-
@Alex.

 ha scritto nel messaggio
news:c0r2h6$vrm$1...@lacerta.tiscalinet.it...

Grazie a tutti per i vostri pareri.
Ho trovato una soluzione empirica che rafforza la mia ipotesi. Non vi e' una
reale corruzione dei dati ma solo indicatori di una "sospetta" chiusura
anomala del paging
Eseguendo prima ripiristina database, anche se sconsigliano di usarlo senza
che venga richiesto da un messaggio di errore, sucessivamente la
compattazione, va tutto bene.
Il be e' di circa 130 mega, ho provato a copiare qualche tabella in un nuovo
db in modo da ridurne le dimensioni a 10 mega, nessun errore dopo 50
compattazioni consecutive.
Chiaramente è una situazione rischiosa, faccio 3 backup al giorno, e dormo
male la notte :)
Sto montando sul server un disco rimuovibile su cui faro' i test con  A xp,
speriamo bene, anche se ho letto che non è cerificato per l'hyper-threading,
forse conviene saltare direttamente al 2003.
Ciao!
Ale.