Newsgroup: it.comp.appl.access
Titolo: Continua corruzione DB in rete

Buongiorno a tutti,
 
Ho installato un DB BE-FE su tre Pc di cui uno è il server.
Circa un mese fa, mi si è corrotto il Database. Con il programma AccessFix ho recuperato tutte le tabelle "importanti" del Database.
A distanza di una settimana dal primo ripristino il DB mi si è corrotto di nuovo.
In questa seconda occasione mi è bastato aprire il BE e il ripristino è stato effettuato. Dopo qualche giorno, mi si è ripresentato il problema risolto con il ripristino aprendo il BE. A questo punto ho provato a far lavorare il DB con un solo client e con il Server. Dopo alcuni giorni ancora stessa problematica. Ho provato con l'altro client stessa cosa. a questo punto ho deciso di far utilizzare (temporaneamente) il DB solo con il Server (sempre BE-FE). A distanza di 2 settimane di lavoro non si è più corrotta nessuna tabella.
Tenete conto che tale DB lavorava in rete con 2 Pc + server da diversi anni. Secondo voi da cosa può dipendere??? E soprattutto come si può ripristinare il tutto alla situazione iniziale?
 
Grazie in anticipo per la risposta.

 ...

Sembra che si tratta del problema che è stato (ri-) introdotto da un 
update di Win10 in maggio e che ha colpito tanta gente in tutto il mondo.
 
Fino a quando la MS pubblica un vero fix esiste il workaround di 
aggiungere una chiave al registro del server e tutti clienti nel rete. 
Vedi la descrizione ufficiale qui:
 
https://support.office.com/en-us/article/access-reports-that-databases-are-in-an-inconsistent-state-%ef%bb%bf-7ec975da-f7a9-4414-a306-d3a7c422dc1d
 
 
 
Per più informazione puoi anche leggere il blog di Daniel:
https://www.devhut.net/2018/06/13/access-bug-database-is-in-an-unrecognized-format/
 
 
-- 
Ciao
Karl
*********
http://www.AccessDevCon.com
 
Access FAQ: 
http://www.donkarl.com/it
 


Se stai parlando di file mdb condiviso da piu' postazioni, allora il 
problema e' quello
Se ha funzionato per anni, vuol dire che finora sei stato fortunato


Grazie a tutti per la risposta.
Rispondo prima a Karl:
In effetti (mi sono dimenticato di sottolinearvelo) su 2 Pc è installato Win 10(server compreso) e su di un client Win 8. Può dipendere da quello??
 
Rispondo a Roberto:
Perché Roberto sostieni che sono stato fortunato, forse perché non l'ho trasformato in .mde??? Diciamo che in passato questo database girava con Win7, e guarda caso non ho mai avuto problemi. Probabilmente è come dice Karl.
A dir la verità ho tantissimi DB .mdb condivisi che non hanno mai avuto problemi.
Tu sostieni che non è corretto mantenere questo formato?
Grazie ancora

 Grazie in anticipo per la risposta.
 
aggiungo qualche osservazione,
NON è proprio una "risposta",
ma questo, per me, è un argomento di grande interesse
dato che realizzo piccole procedure utilizzando SOLO Access
 
per prima cosa: alcuni link a RECENTISSIMI tread
di un newsgroup americano "sopravvissuto"
 
https://groups.google.com/forum/#!topic/comp.databases.ms-access/VSOOYEEaj0E
 
https://groups.google.com/forum/#!topic/comp.databases.ms-access/RcbQCO5hdkM
 
https://groups.google.com/forum/#!topic/comp.databases.ms-access/4imh3vnFcdQ
 
 
e, per il mio interesse, se vengono aggiunte altre segnalazioni
ne prendo volentieri visione
 
per seconda cosa: qualche rilievo personale
(preciso che NON ho una preparazione tale da poter esaminare 
la bontà dei collegamenti di rete)
 
le procedure più consistenti sono ancora mantenute nel formato
Access 2000 (!) e 2003, utilizzate con Runtime 2007,
suddivise in FE e BE, 
nel tempo i sistemi operativi dei FE sono variati da XP, a Seven, a 8.1, a 10
(MAI Vista)
e il BE è stato collocato in varie modalità:
macchina "server": LINUX (samba)
macchina "server": Windows server 2012
macchina "server": una WORKSTATION che funziona ANCHE da client
reti anche con PC collegati via WiFi
 
dimensioni del BE: da 8000 a 50000 KB
FE "sempre nuovo" (viene caricato da uno script ad ogni primo lancio)
utenti (per situazioni con numerosità significative): da 10-12 a circa 20
 
per farla corta:
SOLO IN UN CASO, (BE su Workstation anche client) con evidentissimi problemi di collegamenti di rete (attualmente risolti) ho avuto un periodo di corruzioni continue (negli altri casi NESSUNA corruzione, salvo il salto di corrente)
 
 
quindi:
dai link trascritti si pone enfasi sugli aggiornamenti di Windows
(anche se non vedo ben definiti versione di Access, deploy delle procedure e sistemi operativi)
 
e a me rimane il sospetto che FORSE sono le versioni più recenti di Access
a subire questo tipo di maltrattamento
 
chiedo infine se puoi specificare versione di Access e deploy della tua procedura
 
 


AGGIUNTA:
i FE sono tutti mde,
lo scorso settembre, l'export (solo export nel mio caso) su file xls fatto utilizzando docmd.transferSpreadsheet era messo fuori uso da un aggiornamnto Windows nel file mdb (di sviluppo) ma NON nel file mde, però continuava a funzionare docmd.OutputTo

Il giorno martedì 3 luglio 2018 18:26:53 UTC+2, GiorgioDaPrato ha scritto:

Ciao Giorgio,
Grazie e complimenti per "l'esaustività" della tua risposta.
In realtà per cercare di essere coinciso e non ridondante ho tralasciato dei particolari fondamentali per l'analisi :
Oltre ai sistemi operativi delle macchine (che ho citato nella prec. risposta)Non ho parlato nemmeno della versione di Access che si utilizzano i 3 Pc che è la 2013.
Grazie ancora
 


No, forse hai capito male, sto parlando del file dati, quello non puoi 
trasformarlo in mde, quello che sta sul server
Sostengo che sei stato forntunato perche' il problema della corruzione 
file dati in Access/Vb e' un GRAVE problema che ha afflitto, tuttora 
affligge ed affliggera' in futuro, intere generazioni di sistemi i cui 
dati sono tenuti sui famigerati mdb o accdb
Il problema non e' tanto la corruzione, che nella maggior parte dei casi 
si recupera fixando il file corrotto o riprendendo backup precedenti
E' la figura di merda che si fa' col cliente
E' come se su un'auto si rompesse il telaio
Il teaio di un'auto non deve rompersi, mai
E se si rompe, e' chiaramente un vizio strutturale, di progettazione, 
che evidenzia l'incompetenza dei progettisti e la possibilita' di 
rivalerti a suon di cause civili
E quando il progettista sei tu, c'e' poco da tirar fuori "..eh si ma e' 
colpa dei driver scheda rete o del fix di Windows..."
Oltre allo sputtanamento, i dindini, li chiedono a te, che hai usato un 
sistema inaffidabile, mica a Microsoft
 
 
 


Ok, adesso sei stato decisamente più chiaro,
Per quanto riguarda lo "sputtanamento", Beh, dipende da quanto è fidelizzato il cliente.
Ad ogni modo Roby, scusa forse non ho letto tra "le righe" il tuo consiglio.
Ti sostieni di........
grazie ancora

 ...
 
Sì, come già detto, negli ultimi 1,5 mesi è un problema specifico per 
molta gente in tutti fori di Access sul mondo. Si tratta di un problema 
con una tecnica del caching di Windows (OpLocks), già fissata una volta 
3 anni fa, ma introdotto di nuovo presumibile con un recente update di 
Win10 in maggio.
 
In dozzine di discussioni (ed emails) abbiamo visto che il workaround 
segnalato di spegnere questa tecnica aiuta. Per questo ora anche il team 
di Access lo raccomando, anche se sono ancora sulla ricerca della causa 
esatta.


 
 
"..in tutti i fori di Access.."
Questa non si puo' proprio leggere
:-)
 
 


Veramente nin era tra le righe
Il mio consiglio e' di spostare i dati su un db server che faccia quello 
di mestiere, tenere i dati al sicuro
Puo' essere il Microsoft ma anche tutti gli altri vanno piu' che bene
Personamente ho una predilezione per Firebird e Postgresql, ma 
sostanzialmente uno vale l'altro (ragionamento valido per db contenuti 
entro qualche decina di Gbyte)
Dopotutto il trattare con tabelle linkate ad un mdb/accdb oppure ad un 
Sql Server non e' che cambia granche'
Gia' solo la caratteristica di poter fare i backup 'a caldo' senza che 
gli utenti se ne accorgano, ti rendera' una tranquillita' di fornire un 
sistema davvero robusto
In definitiva, il database di un'azienda, costituisce un valore 
assolutamente primario, che vale assicurare con ogni mezzo disponibile
Fornire il sistema gestionale+db di una resilienza prima sconosciuta, 
sara' sicuramente apprezzato dalla direzione/proprieta' aziendale
E ciao