Newsgroup: it.comp.appl.access
Titolo: evitare corruzione db FE BE o entrambi

quali accorgimenti sono da adottare per evitare che ogni tanto si danneggi 
il BE o FE o entrambi?
grazie a tutti. 
 

 grazie a tutti.
 
 
Secondo me il fattore di corruzione più importante per una base dati Access 
è l'uso di campi MEMO.
Ho installato applicazioni su centinaia di PC, nel corso di diciassette 
anni, attraverso varie versioni di Access.
All'inizio l'hardware (di rete e non) influiva molto sulle corruzioni, ma da 
un decennio a questa parte sempre meno; avendo l'accortezza di NON usare 
campi Memo nelle tabelle 'veramente' multiutenti (quelle relative ai 
movimenti, essenzialmente), il rischio di corruzione si abbatte quasi a 
zero.
Questo sulla base della mia esperienza.
 
Per quanto concerne il FE, devi anzitutto distribuire la versione .Mde/Accde 
dei programmi: in tal modo le maschere e i reports della procedura saranno a 
sola esecuzione.
Diversamente, se distribuisci i FE in modalità .Mdb, Access ha il brutto 
vizio di memorizzare nel design di Forms/Reports un mucchio d'impostazioni 
(Filtri applicati dagli utenti, dimensioni griglie DataSheets, Margini 
reports. etc). Queste scritture oltre a essere pericolose se gli utenti sono 
smanettoni, possono corrompere i programmi.
Altra accortezza sarebbe di limitare al minimo l'utilizzo di Tabelle 
temporanee locali, o di non usarne affatto (tuttavia per esigenze di 
programmazione spesso sono necessarie).
Eviterei anche di settare l'autocompattazione alla chiusura.
 
Saluti da Simone
 
 
 
 
 

Saluti da Simone
 
 
 
 
 
 
 
 
 

 
 
 
per evitare corruzioni del BE puoi passare a msde.
 
usare un BE mdb oppure msde non cambia molto dal punto di vista della 
costruzione dell'applicazione in access; nel FE hai sempre a che fare con 
le tue tabelle collegate e creare le tabelle con sqlmanager non e' molto 
diverso dal crearle in access.
 
un po' di anni fa esistevano gli 'upsizing tools' che prendevano un mdb e 
ricreavano le tabelle su sql in 2 click: 10 minuti e avevi gia' la 
struttura fatta copiando un mdb esistente, riallegavi le nuove tabelle 
nel fe e potevi gia' partire.
 
 
avere un rdbms al posto di un file mdb condiviso e' piu' robusto e ti 
apre la strada a possibilita' che con un be mdb non hai.
 
una su tutte: puoi fare il backup del database in qualunque momento, 
anche mentre ci sono utenti collegati che stanno lavorando (3 turni 
anyone?).
 
quando poi impari a usare indici, view e stored procedures non torni 
piu' indietro neanche per progetti piccoli.
 
 
 
-- 
Paolo opg
 
BE AWARE that this post uses a fake reply-to address
to contact me write to:
janickg ( at ) hotmail ( dot ) com
--

 diventando cosi pesante?
 
 
Mi riferivo a quella automatica di Access, che funziona così, così.
Puoi scrivere un programma che, ogni qualche giorno, tenta la compattazione 
del BE: se ci sono utenti collegati non la fa, altrimenti procede senza 
problemi.
Analogamente potresti compattare periodicamente il FE con qualche 
stratagemma, oppure sostituirlo con la copia di backup di cui parlavo più 
sopra.
 
Vale naturalmente il consiglio di Paolo Opg su SQL Server Express per quanto 
concerne il DB.
Personalmente, data la fastidiosa pesantezza di SQL Server, ho sempre 
preferito usare .mdb in piccole realtà ... però quando le multiutenze o il 
volume di dati preoccupano, la soluzione Server è necessaria.
Dai un'occhiata a questo tutorial: 
http://www.accessgroup.it/howto/documentazione-consigli-esempi-per-connettere-access-a-un-server-odbc.html
 
 
Saluti da Simone
 
 
 
 

volume di dati preoccupano, la soluzione Server è necessaria.
 
Il volume dei record è 2000 utenti che acquistano 2000 abbonamenti e ogni 
abbonamento può avere 4 corsi (questi sono i record i un anno)
utenti collegati in rete massimo 3
direi che access và piu che bene voi che dite?
 
 
 
 
 

piu' indietro neanche per progetti piccoli.
 
 
Visto che mi sembri esperto, puoi contattarmi a 
tmtu...@gmail.com
 vorrei 
chiederti una collaborazione per convertire il db se non subito in futuro.
 
Grazie.
 
 


 
 
+1
 
BFS
 

 direi che access và piu che bene voi che dite?
 
 
 
Più che per numero di Records, vale la dimensione del DB: in monoutenza o 
Terminal Server vanno bene anche archivi di 2 GB.
In rete LAN meglio non superare i 300 MB, ma è una valutazione soggettiva.
 
 
 
 

 direi che access và piu che bene voi che dite?
 
Da queste ciffre sì. Ho tante applicazione (mdb) con
molto più record e utenti senza problemi. Con i server
(SQL Server, mySQL, Oracle) lavoro solo se è
veramente necessario/desiderato/possibile al cliente.
 
È difficile dirti cosa sono i problemi della tua applicazione
senza vederla. In genere direi che la strategia per rendere
un'applicazione di Access robusta è lo sviluppo difensivo.
Questo comprende molte principi e tecniche da usare e da
evitare.
 
Alcuni hanno già descritto gli altri qui.
Non compattare automaticamente, non creare nuovi
oggetti, sostituire il FE ogni volta perché il FE è sempre
a buon prezzo, minimizzare lo stress al BE ecc. ecc.
Vedi anche 
http://www.donkarl.com/it/?catalogo
.
 
Inoltre le corruzioni spesso dipendono della qualità
del rete al cliente. Qui Access è più incline dei sistemi
server. Per questo spesso aiuta il cambio ad un server ma
spesso anche non è necessario. Dipende dal caso concreto.
 
-- 
Ciao
Karl
*********
Access FAQ:  
http://www.donkarl.com/it
 
 

Access FAQ:  
http://www.donkarl.com/it
 
 
Grazie per tutti i chiarimenti