Newsgroup: it.comp.appl.access
Titolo: Corruzione DB...

Salve a tutti e buon inizio settimana.
Quello che mi sta portando via da questo NG è tra l'altro questo problema
che mi tiene "LEGATO" in maniera perpetua a questo importantissimo DB...
il fatto è questo...
Il DB in oggetto (vers.97) contiene oltre alle tabelle di base collegate
di diversi BE, collegamenti tab ODBC di programmi esterni (Zucchetti)...
queste ultime tab vengono spesso interrogate con query per controllo di
dati esistenti nelle tabelle di base dei BE... in caso negativo partono
sql/query di inserimento (ovvero i dati non trovati con gli incroci di
dati in archivio ODBC vengono inseriti nell'archivio stesso).
Tutto funziona normalmente fino a quando, non per evento particolare,
all'improvviso il DB si corrompre... a volte del tutto, a volte
parzialmente, nel senso che alcune tabelle funzionano e in altre il
sistema da un errore d'accesso del tipo "Indici non in tabella..." (e non
parlo solo di quelle ODBC, ma anche quelle collegate dai BE)
Premetto che il DB è usato da 6 Utenti che lavorano incessantemente in
certi periodi con lo stesso DB.
Al momento l'unico metodo per "tappare" è quello di fare copie ogni 10
minuti e ripristinarle nel caso in cui si corrompa... un vero caos.
Qualche suggerimento?
Grazie
(Ovviamente tutte le trade base le ho già provate e riprovate... quindi
altro db, compattazione, revisione del codice, etc...)
-- 
Pablitomf (Maurizio Facciuti)
“Quando non ti eserciti ricorda che qualcuno in qualche posto si sta
allenando e, quando lo incontrerai, ti batterà”.
Ed Macauley 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 ha scritto nel messaggio
news:cmn9qk$1r7$1...@news.newsland.it...

probabilmente ci sono problemi di rete
david

 david
Tra le strade base percorse... verifica rete e pacchetti clinet server
inviati e ricevuti... niente da fare... tutto in regola.


 altro db, compattazione, revisione del codice, etc...)
Forse qualche driver ODBC da aggiornare?
Ciao.
-- 
Sergio MAZZA 

 Ciao.
Ciao Sergio...
purtroppo anche quello è OK... la versione ODBC la da direttamente
zucchetti per i suoi archivi, quindi va bene (ho chiesto anche a loro ed è
l'ultima vers. in uso quella che ho io)... solo che continua a corrompersi
in modo anomalo... 
Stò un pò sclerando... forse è la vers.97 ?


 inviati e ricevuti... niente da fare... tutto in regola.
--
rgrds
SC
-- 


 Stò un pò sclerando... forse è la vers.97 ?
E' da sempre che succede questo? Se è così non credo sia un problema di 
access ma del modo diverso di accedere ai db da parte del programma 
originario (Zuccehtti) e quello di "supporto" (Access).
- Si rovina dopo che hai eseguito l'operazione da access (via ODBC)?
- Si rovina dopo che hai eseguito l'operazione da access (via ODBC) e un 
utente ha cercato di modificare un record via applicazione Zucchetti?
Ciao.
-- 
Sergio MAZZA 

 ha scritto nel messaggio
news:cmnh2t$qvl$1...@news.newsland.it...

infatti, se la rete "cade" mentre stai usando le tabelle collegate il db di
access97 va a farsi f.....re. david

David ha scritto:
Tutto... hardware (realtek compreso... skede eliminate anni orsono) e
software.
-- 
Pablitomf (Maurizio Facciuti)
“Quando non ti eserciti ricorda che qualcuno in qualche posto si sta
allenando e, quando lo incontrerai, ti batterà”.
Ed Macauley 
questo articolo e` stato inviato via web dal servizio gratuito 


 dati in archivio ODBC vengono inseriti nell'archivio stesso).
Si corrompe anche facendo tests in monoutenza?

 software.
Ma le macchine dei client sono tutte le stesse:
Hardware,SO,aggiornamenti..etc??
Hai eseguito delle prove escludendo ad uno ad uno gli utenti?
Il file .ldb ti rimane bloccato? Riesci a controllare se in quel momento i
client erano tutti connessi o in parte??
--
rgrds
SC 
-- 


 quindi altro db, compattazione, revisione del codice, etc...)
Se ti capisco bene esiste un solo FE sul server che viene
usato da 6 utenti. Questa disposizione è sempre in pericolo
delle corruzioni perché basta p.e. una piccola interruzione
nella connessione di un solo client per rompere il FE per tutti.
Inoltre è difficile di trovare un problema col NIC ecc.
Allora sarebbe molto meglio di istallare un FE a ogni client.
Per controllare update e distribuzione dei FE puoi usare
un tool come 
http://www.granite.ab.ca/access/autofe.htm
 .
-- 
HTH
Karl
*********
Access FAQ: 
www.donkarl.com/it
 

 un tool come 
http://www.granite.ab.ca/access/autofe.htm
 .
questo però me lo vado a vedere... ciao Karl


 "Pablitomf" <


Si, e non si rompe, ma come non si rompe quando si usa in multiutenza...
il fatto è che non c'è casistica che tenga perchè non ha "momenti o
operazioni critiche", ma "istanti di follia" che non sono riuscito a
rintracciare ne in monoutenza che in multiutenza... il problema è che non
è neanche su una sola Frm o codice o istruzione sql che si verifica il
problema, ma nell'utilizzo generico del db che accade...
Credo che l'unica cosa da fare sia cambiare la vers.97... magari XP è più
performante... qnche perchè è l'unica cosa che ancora non ho fatto.


 Pablitomf (Maurizio Facciuti)
-- 
Roberto
---------------------------------------------
il Sito Comune di it.comp.appl.access:
http://www.sitocomune.com
---------------------------------------------

 uno su ogni client)
Quindi non ti ho capito del tutto.
Quale DB si corrompe? Il FE o un BE sul server?
"Copie ogni 10 minuti" in una disposizione classica (cioè tutti
i dati che si cambiano spesso sul server) fanno solo senso per i BE.
Se si tratta di BE quali hanno i problemi? Tutti?
Certo ci sono diverse cause possibile. Qualche sono descritto
sul 
http://support.microsoft.com/?kbid=303519
p.e. Opportunistic Locking.
Se si tratta del FE e tutti hanno la stessa configurazione (Win, SP
di Office e JET ecc.) e succede su tutti client è difficile a dire con
quale metodo o l'ODBC ecc. hai il problema senza conoscere bene
l'applicazione.
-- 
cu


 l'applicazione.
Si, tutti le stesse versioni, e tutti gli stessi pacchetti di
aggiornamento... pensando fosse questo ho aggiornato tutti i client a
XP...ma il problema si ripropone. Ora leggo l'articolo che mi hai
segnalato.


 performante... qnche perchč č l'unica cosa che ancora non ho fatto.
Non ci giurerei: la versione 3.5 di JET funziona mica male, forse meglio
della 4.0.
Al posto tuo, per il futuro, prenderei in considerazione altre strade.
..........................
Personalmente da anni utilizzo solo MSDE per i lavori nuovi; sul lato FE
ricorro ad ODBC e le tecniche di sviluppo cambiano poco.
Chiaramente ho vecchie applicazioni che non voglio rivedere gratuitamente
(in mancanza di budget da parte della clientela: le mie tariffe sono alte).
Col tempo ho portato i piů importanti tra questi clienti su Terminal Server,
bypassando di fatto le cause che possono portare a corruzioni di .mdb.
............................
Questo non significa che DB jet condivisi in File-Sharing siano destinati a
dare problemi: non č assolutamente vero, e sono io il primo a dirlo.
Ci sono ditte che lavorano con sei o sette PC in maniera intensissima su DB
da 150-200 MB e non hanno mai perso un bit ... altre che per molto meno di
tanto in tanto rognano.
Ci sono passato anch'io: in certi casi pare che responsabile di questo stato
di cose siano spiritelli malvagi  :-)
Avendo parecchi clienti non posso impazzire per uno solo, perdendo giornate
per vedere cosa facciano e capire cosa possa scatenare problemi (hardware di
rete, lock opportunistico, Client che si spengono, etc.).
Per questo ti consiglio di mettere in discussione questo tipo di
configurazione: ci sono valide alternative.
Saluti.

 Saluti.
Saluti anche a te.
