Quando Microsoft Access diventa lento, la causa raramente è una sola. Un database può aprirsi rapidamente ma impiegare molto per eseguire una query; una maschera può essere lenta solo in rete; un report può bloccarsi per minuti; oppure l’intera applicazione può peggiorare gradualmente man mano che il file cresce. Per risolvere davvero bisogna misurare il problema e capire dove viene speso il tempo: nel front-end, nel motore ACE, sulla rete, nelle query, nel codice VBA, nei collegamenti ODBC o nel back-end SQL Server.
Questa guida analizza in modo sistematico le cause più comuni della lentezza in Access per Microsoft 365 e Access 2024, includendo database ACCDB, Runtime, 32/64 bit, front-end/back-end, reti Windows e SQL Server. Per approfondire puoi consultare la categoria Guide Access, la guida su come migliorare le prestazioni di Access in rete e quella su Compatta e ripristina.
Prima regola: misurare prima di ottimizzare
Dire “Access è lento” non basta. Annota quale operazione è lenta, quanto tempo impiega e in quali condizioni. Misura apertura del database, apertura della maschera principale, caricamento di un record, esecuzione delle query principali, generazione report e chiusura. Ripeti il test su un PC locale e, se il back-end è in rete, confrontalo con una copia di test locale.
Se una query impiega 30 secondi in rete e 1 secondo in locale, il problema è molto probabilmente legato a quantità di dati trasferiti, latenza, progettazione della query o struttura del back-end. Se è lenta anche in locale, concentra l’analisi su indici, join, funzioni, struttura delle tabelle e codice.
File Access cresciuto nel tempo
Microsoft spiega che i file database possono crescere durante l’uso non solo per nuovi dati, ma anche per oggetti temporanei e spazio lasciato libero dopo eliminazioni. Questo spazio non viene automaticamente restituito al file system. Con il tempo il file può diventare più grande del necessario e alcune operazioni possono rallentare.
Il comando Compact and Repair elimina spazio inutilizzato e può migliorare le prestazioni. Non “comprime” i dati come un archivio ZIP: ricostruisce il database eliminando spazio non più usato. Prima di eseguirlo crea un backup e ottieni accesso esclusivo, soprattutto in un database multiutente.
Query senza indici
Gli indici sono uno degli strumenti più importanti. Se filtri frequentemente per IDCliente, DataDocumento, CodiceArticolo o Stato e questi campi non sono indicizzati, Access potrebbe dover esaminare molti record. Crea indici sui campi usati regolarmente in join, criteri e ordinamenti, ma non indicizzare ogni colonna indiscriminatamente: gli indici occupano spazio e rallentano inserimenti e aggiornamenti.
Le chiavi primarie sono indicizzate. Per chiavi esterne usate nei join è spesso opportuno un indice. Nei campi con pochissimi valori distinti, come Sì/No, l’indice può avere utilità limitata. Misura sempre l’effetto.
Join inefficienti
Un join tra campi con tipi dati diversi può impedire al motore di sfruttare gli indici in modo efficiente. Verifica che chiave primaria e chiave esterna abbiano tipi compatibili. Un Autonumber Long Integer deve essere collegato a un Number Long Integer, non a testo o Double.
Evita join non necessari e query annidate eccessivamente. Una struttura chiara in più query salvate può essere più facile da ottimizzare rispetto a una singola query enorme con molte espressioni.
Funzioni nei criteri
Applicare una funzione al campo nel criterio può rendere più difficile usare un indice. Per esempio filtrare con Year([DataOrdine])=2026 può essere meno efficiente di un intervallo sulla data, come [DataOrdine]>=#2026-01-01# And [DataOrdine]<#2027-01-01#. L’intervallo permette al motore di usare più facilmente un indice sulla data.
Lo stesso principio vale per Left, UCase, conversioni e calcoli applicati a ogni riga. Quando possibile sposta la trasformazione sul valore di ricerca o usa criteri che preservino l’indicizzabilità.
Funzioni di dominio DLookup, DCount, DSum
Le funzioni di dominio sono comode, ma se usate in una maschera continua o in una query con migliaia di righe possono essere eseguite una volta per riga. Questo moltiplica le interrogazioni. Quando il valore può essere ottenuto con un join o una query aggregata, la soluzione set-based è spesso più efficiente.
Non è necessario eliminare ogni DLookup: per un singolo campo in una maschera di dettaglio può essere perfettamente adeguato. Il problema nasce quando viene ripetuto centinaia o migliaia di volte.
Maschere che caricano troppi record
Una maschera collegata direttamente a una tabella enorme può caricare o rendere disponibili più dati di quelli realmente necessari. Progetta una maschera di ricerca che consenta di selezionare il cliente o documento e poi apri la maschera di dettaglio filtrata sull’ID.
Con VBA puoi usare DoCmd.OpenForm con una WhereCondition. In questo modo l’utente lavora su uno o pochi record, riducendo traffico e memoria.
Combo box con origini enormi
Una casella combinata che carica 100.000 clienti ogni volta che si apre una maschera è inefficiente. Usa ricerca incrementale, filtri per stato, query limitate o una maschera di selezione. Se il valore è raramente scelto, carica la lista solo quando serve.
Controlla inoltre colonne nascoste: anche se non vengono mostrate, possono comunque essere recuperate dalla RowSource.
Subform e subreport
Ogni sottomaschera aggiunge una query. Una dashboard con dieci subform, grafici e contatori può eseguire decine di interrogazioni all’apertura. Misura ciascun componente e carica solo quelli necessari. Puoi utilizzare schede e caricare contenuti quando l’utente apre la scheda, invece di eseguire tutto subito.
Assicurati che Link Master Fields e Link Child Fields usino campi indicizzati. Un collegamento su campi non indicizzati può rallentare notevolmente.
Report pesanti
Un report con raggruppamenti, calcoli, immagini e subreport può essere lento se la RecordSource restituisce troppi record. Prepara una query specifica per il report e filtra prima di aprirlo. Evita di aprire un report annuale completo quando l’utente vuole un solo mese.
Calcoli aggregati dovrebbero essere eseguiti dove è più efficiente: query per riepiloghi complessi, controlli nel report per totali semplici. Con SQL Server valuta query o viste lato server.
Front-end aperto dalla rete
In un database multiutente ogni utente dovrebbe avere una copia locale del front-end. Aprire lo stesso front-end dalla condivisione significa trasferire continuamente oggetti, query e codice attraverso la rete e aumenta anche il rischio di corruzione. Mantieni in rete soltanto il back-end Access con le tabelle.
Distribuisci gli aggiornamenti del front-end con un launcher o script che copia la versione più recente in una cartella locale prima dell’avvio.
Wi-Fi e VPN
Un back-end ACCDB è file-based. I client leggono e scrivono dati attraverso la rete, quindi latenza e instabilità hanno un impatto notevole. Wi-Fi congestionato e VPN geografiche possono rendere Access molto lento e aumentare il rischio di interruzioni durante le scritture.
Per utenti remoti valuta Remote Desktop Services, dove Access e il back-end restano sulla stessa LAN, oppure SQL Server come back-end. Evita di usare OneDrive come sostituto della rete multiutente.
Antivirus e scansione dei file
La scansione in tempo reale può influire sulle operazioni di file, soprattutto se front-end e back-end sono continuamente letti e modificati. Non disattivare l’antivirus. Se sospetti un impatto, misura con il reparto IT e valuta esclusioni strettamente controllate per cartelle specifiche, mantenendo altre protezioni.
Record locking troppo restrittivo
Impostazioni RecordLocks come “All Records” possono ridurre la concorrenza e dare la sensazione di lentezza perché gli utenti attendono il rilascio dei blocchi. Controlla le proprietà delle maschere. Il locking ottimistico può essere più efficiente quando i conflitti sono rari.
VBA lento
Codice che scorre record uno alla volta può essere molto più lento di una query di azione. Se devi aggiornare 50.000 record, prova a esprimere l’operazione come UPDATE SQL invece di un ciclo DAO. Usa i recordset quando la logica non è facilmente rappresentabile con SQL.
Evita DoEvents in loop intensivi se non serve, riduci accessi ripetuti a controlli e tabelle e memorizza valori usati più volte in variabili locali.
DAO: aprire e chiudere correttamente
Apri recordset solo quando servono e chiudili appena finito. Scegli il tipo appropriato: snapshot per lettura, dynaset quando devi modificare. Recupera solo i campi necessari. Un SELECT * su una tabella molto larga trasferisce colonne che potresti non usare.
Query parametrizzate
Una query salvata con parametri può essere più ordinata e sicura di SQL concatenato in VBA. Definisci correttamente i tipi dei parametri, soprattutto date e numeri, per evitare conversioni implicite. Con DAO QueryDef imposta i parametri e apri il recordset o esegui la query.
Indici duplicati e inutili
Troppi indici rallentano gli aggiornamenti perché ogni INSERT, UPDATE o DELETE deve mantenere gli indici. Controlla se esistono indici duplicati creati nel tempo. Mantieni quelli utili per chiavi, join e ricerche frequenti.
Campi Allegato e OLE
Immagini e allegati memorizzati direttamente nel database possono far crescere rapidamente il file. Per grandi archivi documentali spesso è preferibile conservare i file in un repository gestito e memorizzare nel database metadati e riferimenti, tenendo conto dei requisiti di sicurezza e backup.
Se devi usare allegati Access, monitora la dimensione del file e archivia periodicamente i dati storici.
Dimensione massima del file
Un database Access ha limiti di dimensione che diventano rilevanti man mano che dati e oggetti crescono. Non aspettare di arrivare vicino al limite per intervenire. Monitora dimensione, tasso di crescita e quantità di allegati. Un back-end SQL Server rimuove molti limiti tipici del file ACCDB.
Tabelle temporanee
Creare e cancellare continuamente tabelle temporanee nel front-end può far crescere il file. Se hai bisogno di tabelle di lavoro, valuta un database temporaneo separato o svuota le tabelle con DELETE anziché ricrearle continuamente, a seconda dello scenario. Compact and Repair periodico può recuperare spazio inutilizzato.
Nome AutoCorrect e opzioni
Alcune opzioni di tracciamento nomi possono aggiungere overhead in database complessi. Prima di modificarle verifica la documentazione e fai test su copia, soprattutto se il database dipende da Name AutoCorrect. Non cambiare opzioni globali senza sapere quali oggetti possono essere influenzati.
Riferimenti VBA mancanti
Un riferimento “MISSING” nell’editor VBA può provocare errori e comportamenti anomali. Apri l’editor, controlla Tools > References e correggi eventuali riferimenti. Compila il progetto. In distribuzioni 32/64 bit verifica compatibilità delle librerie.
Driver ODBC
Con SQL Server, driver ODBC vecchi o configurazioni DNS inefficienti possono rallentare connessioni e query. Usa driver Microsoft supportati, configura correttamente cifratura e autenticazione e testa tempi di connessione. Mantieni DSN e stringhe di connessione coerenti tra i PC.
Query Access su SQL Server che scaricano troppi dati
Una query Access che combina tabelle ODBC e funzioni locali può costringere il client a scaricare molti record prima di filtrare. Spingi i criteri al server quando possibile. Usa viste, query pass-through o stored procedure per elaborazioni pesanti.
Ad esempio, invece di scaricare milioni di righe di vendite e aggregarle in Access, crea una query SQL Server che restituisca già il riepilogo mensile.
Pass-through query
Le query pass-through inviano SQL direttamente al server e restituiscono il risultato. Sono utili per query complesse e reporting. Devi usare sintassi T-SQL, non la sintassi Access, e gestire parametri attraverso VBA o costruzione controllata del comando.
SQL Server rowversion e aggiornamenti
Per tabelle aggiornabili da Access, una chiave primaria e un campo rowversion possono rendere più affidabile il rilevamento delle modifiche. Il rowversion non è una data: è un valore di versione delle righe.
Runtime e prestazioni
Access Runtime non è intrinsecamente più veloce dell’edizione completa. Usa lo stesso motore per l’applicazione. Se la versione Runtime è lenta, applica la stessa diagnosi: query, rete, front-end, codice e back-end.
32 bit contro 64 bit
La versione 64 bit può indirizzare più memoria, ma passare a x64 non risolve automaticamente query inefficienti o rete lenta. Prima misura il collo di bottiglia. Inoltre l’architettura deve essere compatibile con driver, API e controlli esterni.
Access 2024 contro Microsoft 365
Entrambe le versioni desktop moderne possono usare ACCDB e le tecniche fondamentali di ottimizzazione sono le stesse. Microsoft 365 riceve aggiornamenti continui secondo il canale configurato; Access 2024 segue il ciclo della versione perpetua. Mantieni Office aggiornato per correzioni di stabilità e compatibilità.
Compact on Close: usarlo con cautela
L’opzione “Compact on Close” può essere utile in piccoli database monoutente, ma Microsoft avverte che in un database multiutente potrebbe interrompere temporaneamente la disponibilità. Per back-end condivisi è spesso meglio compattare in una finestra di manutenzione controllata.
Backup prima dell’ottimizzazione
Prima di eliminare indici, modificare tabelle, compattare o riscrivere query importanti, crea un backup. L’ottimizzazione è una modifica tecnica e deve essere reversibile. Nei database split fai backup del back-end e conserva il sorgente del front-end.
Creare un benchmark semplice
Costruisci una tabella con operazione, tempo prima, tempo dopo e note. Misura tre volte ogni test e usa la mediana per ridurre l’effetto di cache e variazioni di rete. Ottimizza una cosa alla volta: se cambi dieci elementi insieme non saprai quale ha prodotto il miglioramento.
Quando SQL Server diventa necessario
Se il database serve molti utenti, gestisce grandi volumi, richiede accesso remoto o transazioni critiche, SQL Server offre un’architettura più adatta. Access può restare front-end. La migrazione consente di spostare filtri, aggregazioni e transazioni sul server riducendo il traffico sulla rete.
Checklist diagnostica
- Misura l’operazione lenta.
- Confronta locale e rete.
- Controlla dimensione del file.
- Verifica indici e tipi dei join.
- Elimina funzioni per riga non necessarie.
- Filtra maschere e report.
- Distribuisci front-end locali.
- Controlla VBA e recordset.
- Verifica driver ODBC.
- Con SQL Server spingi il lavoro sul server.
- Compact and Repair dopo backup quando appropriato.
- Rimisura dopo ogni modifica.
FAQ
Compact and Repair rende sempre Access più veloce?
Può recuperare spazio inutilizzato e migliorare alcune prestazioni, ma non corregge query o rete progettate male.
Un SSD risolve la lentezza?
Può migliorare I/O locale, ma non sostituisce indici, query efficienti e rete corretta.
Access 64 bit è sempre più veloce?
No. Offre più spazio di indirizzamento, ma la velocità dipende soprattutto dal carico.
Meglio usare SQL Server?
Dipende da utenti, volumi, sicurezza e accesso remoto. Per scenari crescenti può essere la scelta giusta mantenendo Access come front-end.
Perché è lento solo in rete?
Probabilmente stai trasferendo troppi dati oppure la rete è lenta/instabile. Filtra prima e usa front-end locale.
Conclusione
Access diventa lento quando uno o più componenti dell’architettura non scalano: file cresciuto, query non indicizzate, maschere che caricano troppo, VBA riga per riga, front-end condiviso, rete instabile o query ODBC che scaricano troppi dati. La soluzione migliore è una diagnosi misurabile e progressiva. Parti dai tempi reali, ottimizza query e indici, distribuisci front-end locali, esegui manutenzione controllata e sposta sul server le elaborazioni che richiedono una piattaforma più robusta. In questo modo Access può rimanere reattivo e affidabile anche in applicazioni aziendali ben più complesse di un semplice database personale.