Per spostare il back-end Access su un server di rete devi prima creare un backup, far uscire tutti gli utenti, copiare il file ACCDB nella nuova share, assegnare permessi corretti alla cartella e ricollegare le tabelle del front-end al nuovo percorso. Dopo lo spostamento verifica lettura, scrittura, lock, query principali e accesso da più PC prima di riaprire il sistema a tutti.
Il back-end contiene le tabelle condivise, mentre ogni utente dovrebbe eseguire una copia locale del front-end. Per approfondire consulta la categoria Guide Access, come dividere Access, come distribuire il front-end e come condividere Access in rete.
Quando conviene spostare il back-end
Può essere necessario spostare il back-end quando il server viene sostituito, quando una cartella di rete cambia, quando il database deve essere centralizzato su un file server più affidabile o quando una share locale non offre backup e sicurezza adeguati. Lo spostamento è anche una buona occasione per rivedere permessi, naming e procedure di manutenzione.
Non eseguire il trasferimento semplicemente trascinando il file mentre gli utenti stanno lavorando. Devi pianificare una breve finestra di fermo per garantire che nessuno scriva durante la copia.
Verificare che il database sia realmente split
Prima di spostare il back-end assicurati che i front-end usati dagli utenti contengano tabelle collegate e non copie locali dei dati. Nel riquadro di spostamento le tabelle collegate hanno un’icona specifica. Puoi anche usare Gestione tabelle collegate per vedere l’origine.
Se il database non è ancora diviso, valuta di usare Database Splitter prima della migrazione. Spostare un file monolitico su un server e farlo aprire da tutti non offre gli stessi vantaggi.
Creare un backup verificato
Crea una copia del back-end prima di qualunque operazione. Chiudi tutte le sessioni e controlla che il file di lock non segnali utenti attivi. Salva il backup su un percorso diverso dal server che stai modificando.
Apri la copia per assicurarti che sia valida. Un backup non testato potrebbe non essere sufficiente se devi fare rollback.
Pianificare una finestra di manutenzione
Comunica agli utenti data e ora. Chiedi di chiudere Access e verifica dal server che non ci siano handle aperti sul file. Non affidarti soltanto alla dichiarazione degli utenti: controlla effettivamente le sessioni aperte.
Se l’app è critica, predisponi un messaggio nel front-end che impedisca l’accesso durante la manutenzione oppure rinomina temporaneamente il master di distribuzione.
Preparare il server di rete
La nuova posizione deve essere su una rete stabile e con storage affidabile. Crea una cartella dedicata e assegna permessi tramite gruppi. Non usare una cartella generica in cui tutti possono modificare qualunque file.
Gli utenti che devono scrivere nel database hanno bisogno di permessi sufficienti sulla cartella perché Access possa creare e gestire il file di lock. Permessi solo in lettura causano errori o accesso limitato.
Percorso UNC
Per i collegamenti è spesso preferibile usare un percorso UNC stabile, amministrato a livello aziendale. Le lettere di unità mappate possono variare tra PC o non essere disponibili in alcune sessioni.
Documenta il percorso ufficiale e usalo nella build del front-end. Evita di lasciare collegamenti a nomi temporanei del server.
Copiare il back-end
Con tutti gli utenti fuori, copia il file ACCDB nella nuova cartella. Non spostare subito l’originale: mantienilo intatto finché i test non sono conclusi. Questo semplifica il rollback.
Controlla dimensione e data del file copiato. Per database importanti puoi calcolare un hash prima e dopo la copia per verificare l’integrità.
Ricollegare con Gestione tabelle collegate
Apri una copia di test del front-end e usa Dati esterni > Gestione tabelle collegate. Seleziona l’origine attuale, scegli Relink e indica il nuovo back-end. Access aggiorna i collegamenti e mostra lo stato.
Microsoft raccomanda di controllare che ogni tabella riporti Success. Se alcune falliscono, correggi percorso, nome tabella o credenziali e ripeti.
Testare le tabelle
Apri ogni tabella critica, verifica i dati e prova operazioni di lettura e scrittura su record di test. Controlla chiavi primarie, campi aggiornabili e tabelle che usano nomi diversi nel front-end.
Se una tabella ODBC o esterna non appartiene al back-end Access, non modificarne il collegamento per errore. Gestione tabelle collegate può mostrare più origini.
Testare query e maschere
Esegui le query principali, soprattutto quelle con join tra tabelle collegate. Apri maschere operative, inserisci e modifica dati di test e verifica che i report funzionino.
Controlla anche query di azione e procedure VBA che potrebbero usare un percorso del back-end hard-coded anziché le tabelle collegate.
Cercare percorsi hard-coded nel VBA
Alcune applicazioni usano DBEngine.OpenDatabase, TransferDatabase o routine di backup con un percorso scritto direttamente nel codice. Cerca il vecchio nome server nell’intero progetto VBA e nelle macro.
Centralizza il percorso in una tabella o funzione di configurazione. Questo rende i futuri spostamenti più semplici.
Verificare importazioni ed esportazioni
Se procedure automatiche leggono o scrivono file vicino al back-end, verifica che la nuova posizione non abbia cambiato anche cartelle di import/export. Mantieni separati il percorso dati e le cartelle di scambio.
Controlla permessi di servizio e utenti sulle directory usate dalle automazioni.
Test multiutente
Prima di aprire a tutti, fai collegare due o tre utenti pilota. Esegui modifiche contemporanee su record diversi e, in un ambiente di test, prova anche un conflitto sullo stesso record per verificare RecordLocks e messaggi.
Misura i tempi di apertura delle maschere e delle query. Un nuovo server dovrebbe offrire prestazioni almeno equivalenti alla vecchia posizione.
File di lock
Quando gli utenti aprono il back-end, Access crea un file di lock nella stessa cartella. Se il lock non viene creato, verifica i permessi. Non cancellarlo mentre sessioni sono attive.
Dopo l’ultimo utente, il file dovrebbe normalmente scomparire. Se rimane dopo un crash, assicurati prima che nessuno stia usando il database.
Permessi NTFS e share
Controlla entrambi i livelli. Un permesso permissivo sulla share ma restrittivo su NTFS può bloccare l’accesso e viceversa. Usa gruppi e documenta chi deve modificare dati.
Non concedere Full Control indiscriminatamente. Fornisci i diritti necessari al funzionamento e proteggi la cartella da cancellazioni accidentali quando possibile.
Antivirus e software di sicurezza
Alcuni antivirus possono analizzare intensivamente file Access e rallentare l’accesso. Non creare esclusioni globali senza valutazione di sicurezza, ma se le prestazioni peggiorano verifica con il team IT se lo scanning della share influisce sul file.
La soluzione deve bilanciare sicurezza e prestazioni, non disabilitare protezioni alla cieca.
Rete cablata
Per postazioni che modificano frequentemente il back-end, una LAN cablata stabile è preferibile a Wi-Fi instabile. Le disconnessioni durante scritture aumentano il rischio di problemi.
Se gli utenti sono remoti, considera RDS o SQL Server invece di un back-end ACCDB attraverso WAN/VPN.
OneDrive e SharePoint
Non spostare il back-end su una cartella sincronizzata OneDrive pensando che equivalga a un file server. Microsoft sconsiglia l’apertura contemporanea di file Access da OneDrive o raccolte documenti SharePoint per il rischio di copie e comportamenti inattesi.
SharePoint può essere integrato con liste, ma è un modello diverso.
Backup sul nuovo server
Dopo la migrazione verifica che il nuovo percorso sia incluso nel sistema di backup. Non dare per scontato che tutte le share siano protette allo stesso modo.
Definisci retention, frequenza e test di ripristino. Se il database è critico, documenta RPO e RTO.
Compattazione e manutenzione
Pianifica Compatta e ripristina in finestre in cui nessuno è connesso. La compattazione richiede accesso esclusivo. Crea un backup prima.
Non affidare manutenzione del back-end a script non testati che possono partire mentre utenti stanno lavorando.
Aggiornare i front-end
Se ogni utente ha un front-end locale, devi aggiornare i link in tutte le copie. Il modo migliore è distribuire una nuova build già configurata oppure usare un updater che ricolleghi automaticamente.
Evita di chiedere a decine di utenti di usare Gestione tabelle collegate manualmente.
Routine VBA di relink
Una routine può enumerare TableDefs, identificare collegamenti Access e aggiornare la proprietà Connect al nuovo percorso, quindi chiamare RefreshLink. Gestisci errori e limita l’operazione alle tabelle previste.
Conserva il percorso in configurazione e non nel codice duplicato. Testa la routine su una copia.
Access Runtime
Gli utenti Runtime non dovrebbero dover ricollegare manualmente. Il front-end distribuito deve essere già configurato o includere una procedura automatica di relink.
Mostra un messaggio chiaro se il back-end non è disponibile invece di lasciare che l’utente incontri una serie di errori.
32 e 64 bit
Lo spostamento del back-end non dipende dalla bitness, ma la nuova build del front-end potrebbe evidenziare componenti esterni non compatibili. Se cambi anche PC o versione Office, testa 32/64 bit separatamente.
Il file dati ACCDB resta lo stesso, salvo dipendenze particolari.
Rollback
Se i test falliscono, fai chiudere tutti, ripristina il vecchio percorso nei front-end e riattiva il back-end originale. Poiché non lo hai cancellato, il ritorno è rapido.
Non permettere modifiche contemporanee su vecchio e nuovo back-end: rischieresti due copie divergenti dei dati. Durante la migrazione deve esistere una sola sorgente attiva.
Dopo la migrazione
Quando sei certo che tutti usano il nuovo server e i backup funzionano, archivia l’originale in sola lettura per il periodo previsto dalla politica aziendale. Non lasciarlo accessibile come database operativo alternativo.
Aggiorna documentazione, diagrammi, procedure di backup e istruzioni di supporto.
Quando valutare SQL Server
Se stai spostando il back-end perché la share è diventata un collo di bottiglia, valuta se conviene migrare direttamente a SQL Server. Access può continuare a essere il front-end.
SQL Server è particolarmente utile per utenti remoti, sicurezza granulare, backup avanzati e maggiore concorrenza.
Errori comuni
- Copiare il file mentre utenti sono connessi.
- Non conservare il vecchio back-end per rollback.
- Dimenticare i permessi della cartella.
- Usare percorsi diversi sui PC.
- Non aggiornare tutti i front-end.
- Ignorare percorsi hard-coded nel VBA.
- Mettere il file su OneDrive.
- Non testare backup sul nuovo server.
Checklist passo passo
- Pianifica fermo.
- Crea backup.
- Fai uscire gli utenti.
- Prepara share e permessi.
- Copia il back-end.
- Ricollega un front-end di test.
- Verifica tabelle.
- Verifica query e maschere.
- Testa multiutente.
- Distribuisci front-end aggiornati.
- Attiva backup.
- Monitora prestazioni.
- Archivia il vecchio file solo dopo conferma.
FAQ
Posso spostare il back-end con Access aperto?
No. Fai chiudere gli utenti e copia il file in una finestra controllata.
Come aggiorno i collegamenti?
Usa Gestione tabelle collegate oppure una routine VBA di relink testata.
Meglio percorso UNC o unità mappata?
Un UNC stabile è spesso più coerente tra PC, soprattutto in ambienti gestiti.
Posso usare un NAS?
Sì se offre una share di rete stabile, permessi corretti e backup affidabile. Testa prestazioni e compatibilità.
Posso usare OneDrive?
Non come back-end Access aperto contemporaneamente da più utenti. Microsoft sconsiglia questo uso.
Serve aggiornare il front-end?
Sì, se i collegamenti contengono il vecchio percorso. Distribuisci una nuova build o ricollega automaticamente.
Conclusione
Spostare il back-end Access su un server di rete è un’operazione semplice solo se viene pianificata: backup, utenti disconnessi, share stabile, permessi, copia, relink e test. La fase più importante è evitare che vecchio e nuovo back-end vengano usati contemporaneamente.
Microsoft spiega come cambiare il back-end nella guida Split an Access database e come ricollegare le origini in Manage linked tables. Usa queste procedure come riferimento e documenta il nuovo percorso per tutti i futuri rilasci.