Aggiornare collegamenti quando cambia Access significa ricollegare il front-end alle tabelle del back-end dopo uno spostamento di file, una nuova cartella condivisa, un cambio server o una modifica dell’origine dati. Nei database divisi il front-end conserva per ogni tabella collegata informazioni sulla sorgente; se il percorso non esiste più, maschere e query iniziano a restituire errori fino a quando i collegamenti non vengono aggiornati.
La procedura corretta non consiste nel cancellare e ricreare tutto. In Access per Microsoft 365 e Access 2024 puoi usare Gestione tabelle collegate per aggiornare o ricollegare una sorgente. In applicazioni distribuite puoi anche automatizzare il relink con DAO e TableDef.RefreshLink. La scelta dipende dal numero di utenti e dal modo in cui distribuisci il front-end.
Indice
- Perché i collegamenti si rompono
- Preparare lo spostamento
- Controllare il nuovo percorso
- Gestione tabelle collegate
- Ricollegare tutte le tabelle
- Percorsi UNC
- VBA e RefreshLink
- Più back-end
- Runtime
- SQL Server e ODBC
- Aggiornare molti PC
- Test
- Troubleshooting
- FAQ
Perché cambia il percorso del back-end
I motivi più comuni sono sostituzione del server, riorganizzazione delle cartelle, migrazione da un PC condiviso a un file server, cambio di nome della condivisione o separazione tra ambiente test e produzione. In tutti questi casi il file .accdb può essere perfettamente integro, ma il front-end continua a cercarlo nella vecchia posizione.
Un errore di percorso non è corruzione. Prima di tentare riparazioni, verifica la proprietà dei collegamenti e prova a raggiungere manualmente la nuova cartella.
Prerequisito: database diviso
Questa guida presuppone che il database sia già separato. Il back-end contiene le tabelle; il front-end contiene query, maschere, report, macro e VBA. Se ancora usi un singolo file, consulta come dividere un database Access.
Ogni utente dovrebbe avere una copia locale del front-end. Questo permette di aggiornare una copia master e ridistribuirla, invece di ricollegare manualmente decine di file diversi.
Prima dello spostamento: inventario
Elenca quali tabelle appartengono a quale back-end. Un’app complessa può avere tabelle in due file Access, SQL Server e SharePoint. Se cambi soltanto un file, non devi toccare gli altri collegamenti.
Documenta vecchio percorso, nuovo percorso, nome file, data, versione front-end e persone autorizzate. Questa semplice tabella evita errori durante la manutenzione.
Fai un backup
Prima di spostare il back-end crea una copia verificata. Assicurati che gli utenti abbiano chiuso Access e che non esistano sessioni attive. Copia il file con strumenti normali del file system o backup aziendale.
Non spostare un back-end mentre utenti stanno scrivendo. Se devi capire chi è connesso, consulta come capire chi sta usando il database Access.
Controllare il nuovo percorso
Dopo aver copiato il back-end, accedi alla cartella dal PC di test con un account utente normale. Verifica che il file sia visibile e che l’utente abbia i permessi necessari per il funzionamento multiutente.
Non testare soltanto come amministratore. Un percorso può funzionare per te e risultare negato per gli utenti.
Preferire un percorso di rete coerente
Le lettere mappate come Z: possono differire tra PC. Un percorso UNC uniforme è spesso più semplice da distribuire. Il requisito essenziale è che tutti i client risolvano il server e abbiano accesso stabile.
Se usi DFS, VPN o altre astrazioni, verifica con l’IT che il comportamento sia adatto a file Access condivisi.
Aggiornare con Gestione tabelle collegate
Apri il front-end master in Access completo. Vai a Dati esterni e apri Gestione tabelle collegate. Microsoft consiglia prima di aggiornare la sorgente, quindi, se il percorso è cambiato o lo stato fallisce, ricollegarla.
Seleziona la sorgente corrispondente al vecchio back-end. Scegli Ricollega e indica il nuovo file. Access aggiorna le tabelle selezionate e mostra lo stato.
La guida come usare Gestione tabelle collegate approfondisce tutte le funzioni.
Selezionare tutte le tabelle della stessa sorgente
Quando tutte le tabelle provengono dallo stesso file, seleziona l’intera origine. È più sicuro che ricollegare una per volta e rischiare di dimenticarne una.
Dopo il relink espandi la sorgente e verifica che lo stato sia positivo per tutte. Una singola tabella Failed può indicare che è stata rinominata o rimossa nel nuovo back-end.
Nomi locali e nomi remoti
Una tabella collegata può avere nel front-end un nome locale che non coincide perfettamente con quello remoto. Quando ricolleghi, evita di cambiare il nome locale se query e codice lo utilizzano. Cambiare il nome può rompere riferimenti.
Se la tabella è stata rinominata nel back-end, valuta se mantenere l’alias locale e puntarlo al nuovo oggetto, quando Access lo consente, oppure aggiorna sistematicamente tutte le dipendenze.
Testare la lettura
Apri alcune tabelle e query. Verifica record recenti e conteggi. Se il database contiene dati sensibili, usa un ambiente di test o query di sola lettura.
La sola apertura non basta: devi anche testare la scrittura se l’applicazione consente modifiche.
Testare inserimento e modifica
In un ambiente di test crea un record, modificalo e salvalo. Se il collegamento è leggibile ma non aggiornabile, controlla permessi, chiavi e integrità. Con SQL Server una tabella senza chiave univoca riconosciuta può risultare non aggiornabile.
Chiudere e riaprire il front-end
Dopo il relink salva e chiudi Access. Riapri il front-end come farebbe un utente e ripeti i test principali. Questo verifica che il collegamento non dipenda da uno stato temporaneo della sessione.
Automatizzare con DAO
Per molti client può essere utile una routine VBA. Ogni TableDef collegata ha una proprietà Connect; dopo averla modificata puoi eseguire RefreshLink. Il codice deve però distinguere tabelle Access, ODBC e altre origini.
La logica sicura è: identificare soltanto le tabelle che puntano al vecchio back-end, costruire la nuova stringa, chiamare RefreshLink, intercettare errori e registrare l’esito. Non modificare indiscriminatamente tutte le TableDefs.
Controllare che il file esista
Prima del relink verifica la presenza del nuovo back-end. In VBA puoi usare Dir per un file semplice o una funzione più robusta. Se non esiste, mostra un messaggio e non alterare i collegamenti esistenti.
Eseguire il relink all’avvio?
Non è necessario ricollegare a ogni avvio se il percorso è stabile. Puoi invece eseguire un rapido test di una tabella o confrontare la proprietà Connect con quella attesa. Se coincide e funziona, non fare nulla.
Ricollegare continuamente aumenta i tempi di startup e può generare prompt ODBC inutili.
Più back-end Access
Alcune applicazioni separano dati correnti, archivio e configurazione. In questo caso crea una mappa delle sorgenti. Ogni gruppo di tabelle deve essere ricollegato al file corretto.
Una tabella locale di configurazione può contenere i percorsi per ruolo: Produzione, Archivio, Documenti. Evita di codificare percorsi in decine di procedure VBA.
Ambiente test e produzione
È utile avere un modo controllato per passare da test a produzione. Non lasciare all’utente finale un menu che consenta di cambiare liberamente il back-end, soprattutto se i dati sono sensibili.
Lo sviluppatore può usare una build di test con percorsi distinti e una build produzione ACCDE. Colori o titoli diversi aiutano a non confondere gli ambienti.
Access Runtime
Gli utenti Runtime non dovrebbero aprire Gestione tabelle collegate. Il front-end deve arrivare già configurato oppure avere una routine di relink integrata.
Se il percorso cambia in un’installazione Runtime, distribuisci una nuova build o un file di configurazione aggiornato. Consulta come distribuire un’app Access con Runtime.
ACCDE
Un front-end ACCDE può continuare a ricollegare tabelle tramite codice già compilato. Non puoi però modificare quel codice nell’ACCDE. Per cambiare la logica di relink devi aggiornare l’ACCDB sorgente e generare una nuova build.
SQL Server e ODBC
Se il back-end cambia da un server SQL a un altro, non basta scegliere un file. Devi aggiornare stringa ODBC, DSN o configurazione DSN-less. Verifica driver, server, database, autenticazione e certificati.
Con Gestione tabelle collegate puoi modificare e ricollegare le origini ODBC. Dopo il cambio verifica tabelle aggiornabili e query.
Cambio da Access a SQL Server
Se stai migrando il back-end da .accdb a SQL Server, non trattarlo come un semplice cambio percorso. Cambiano tipi dati, driver, autenticazione e comportamento delle query. Serve un progetto di migrazione e test più ampio.
Distribuire il nuovo front-end
Dopo aver aggiornato la copia master, incrementa la versione, crea ACCDE se previsto e distribuiscilo localmente. Non chiedere a ogni utente di ripetere la procedura manualmente.
Un updater può copiare la nuova build alla successiva apertura. La guida come aggiornare il front-end Access su più PC spiega il modello.
Verifica della versione schema
Quando cambia il back-end, registra anche una versione schema. All’avvio il front-end può leggere una tabella di configurazione e rifiutare l’apertura se non è compatibile.
Questo previene il caso in cui un utente continui a usare un vecchio front-end con nuove tabelle.
Permessi della nuova cartella
Lo spostamento su un nuovo server spesso cambia ACL. Gli utenti devono poter leggere e scrivere secondo le esigenze di Access e gestire il file di lock. Se hanno sola lettura, le tabelle possono aprirsi ma le modifiche falliscono.
Testa con un account reale prima del rilascio.
Antivirus e rete
Un nuovo server può avere policy antivirus o backup diverse. Se le prestazioni peggiorano dopo lo spostamento, misura latenza e I/O. Non disattivare protezioni senza un’analisi IT.
Non spostare su OneDrive
Microsoft sconsiglia di aprire database Access direttamente da OneDrive o raccolte documenti SharePoint. Non usare una cartella sincronizzata come nuovo percorso del back-end multiutente.
Backup del vecchio back-end
Dopo la migrazione non cancellare subito il vecchio file. Rendilo di sola lettura o spostalo in archivio controllato per il periodo necessario. Evita però che alcuni utenti continuino a collegarsi per errore.
Puoi rinominare la vecchia condivisione o rimuovere i permessi dopo aver verificato la nuova produzione.
Problemi comuni
Alcune tabelle funzionano e altre no
Probabilmente appartengono a sorgenti diverse oppure una tabella è stata rinominata. Controlla Gestione tabelle collegate.
Il relink funziona sul PC dello sviluppatore
Se fallisce sugli altri, confronta permessi, percorso, DNS, unità mappate, driver e architettura Office.
Access chiede password
Il nuovo back-end può essere cifrato o l’origine ODBC richiede credenziali. Non incorporare password in chiaro senza una strategia di sicurezza.
Le query dicono parametro mancante
Il collegamento può essere riuscito ma lo schema è cambiato. Controlla nomi dei campi e tipi dati.
Il database è molto lento dopo lo spostamento
Misura latenza e rete. Il nuovo server può essere più distante o attraversare una VPN. Valuta percorsi e architettura.
Checklist passo passo
- Comunica manutenzione.
- Chiudi tutti gli utenti.
- Backup del back-end.
- Copia sul nuovo server.
- Configura permessi.
- Testa la cartella come utente standard.
- Apri il front-end master.
- Gestione tabelle collegate.
- Ricollega la sorgente.
- Controlla stato di tutte le tabelle.
- Testa lettura.
- Testa scrittura.
- Chiudi e riapri.
- Testa maschere/report.
- Incrementa versione.
- Crea ACCDE.
- Distribuisci front-end.
- Monitora le prime sessioni.
FAQ
Devo ricreare le tabelle collegate?
No nella maggior parte dei casi. Puoi ricollegare la sorgente esistente.
Posso usare VBA?
Sì. DAO TableDef.RefreshLink permette di aggiornare i collegamenti programmaticamente.
È meglio ricollegare a ogni avvio?
No se il percorso è stabile. Controlla e intervieni solo quando serve.
Con Runtime come faccio?
Prepara il front-end prima della distribuzione o integra una routine di relink. L’utente Runtime non dovrebbe fare amministrazione manuale.
Posso spostare il back-end su OneDrive?
Non come file multiutente aperto direttamente. Microsoft sconsiglia questo scenario.
Serve aggiornare tutti i PC?
Sì se ogni front-end conserva il vecchio percorso. La soluzione migliore è aggiornare la build master e ridistribuirla.
Conclusione
Aggiornare collegamenti quando cambia Access è un’operazione semplice se viene pianificata: utenti disconnessi, backup, nuovo percorso testato, relink del front-end master e distribuzione della nuova build. Gestione tabelle collegate è il metodo manuale principale; DAO consente di automatizzare.
Non confondere cambio percorso con migrazione a una tecnologia diversa. Per altri tutorial visita Guide Access.
Fonte ufficiale: Microsoft Support – Manage linked tables.