Quando una tabella collegata non è più disponibile in Microsoft Access, l’applicazione può mostrare errori all’apertura, query che falliscono, maschere senza dati o messaggi relativi a file, server, credenziali e origini non raggiungibili. Il collegamento può essersi rotto perché il back-end Access è stato spostato, il nome della tabella è cambiato, il server SQL è stato migrato, una password è scaduta, il driver ODBC non è più presente oppure lo schema dell’origine è stato modificato.
In questa guida vediamo come aggiornare tabelle collegate non disponibili in Access con una procedura ordinata e sicura. Le istruzioni valgono per Access per Microsoft 365 e Access 2024 su Windows e includono database Access divisi in front-end/back-end, tabelle SQL Server e Azure SQL collegate via ODBC, Excel, file di testo e altre origini supportate. Access è un’applicazione desktop Windows: non esiste una versione nativa completa per macOS.
Per gli argomenti collegati puoi leggere anche come usare Gestione tabelle collegate, come ricollegare le tabelle in Access, come aggiornare i collegamenti quando cambia il percorso del back-end, come riparare relazioni e collegamenti rotti e la raccolta completa delle Guide Microsoft Access.
Che cosa significa tabella collegata non disponibile
Una tabella collegata è un oggetto che appare nel database Access ma i cui dati risiedono in un’altra origine. Access conserva le informazioni necessarie per raggiungere quella sorgente e presenta la tabella agli utenti quasi come se fosse locale. Quando il percorso o la connessione non sono più validi, il collegamento resta visibile ma i dati non sono accessibili.
Microsoft descrive Gestione tabelle collegate come il punto centrale per visualizzare e gestire le origini e le tabelle collegate. La documentazione corrente per Access Microsoft 365 e Access 2024 indica che può essere necessario aggiornare, ricollegare, trovare, modificare o eliminare collegamenti quando cambiano posizione, nome o schema della sorgente. La guida ufficiale è Gestire le tabelle collegate.
La sequenza Microsoft consigliata
Microsoft raccomanda una sequenza precisa: prima aggiornare l’origine dati per identificare i problemi; se esiste un problema correggere percorso o informazioni della sorgente; poi ricollegare le singole tabelle che risultano in stato Non riuscito; infine ripetere i passaggi finché tutte risultano riuscite.
Seguire questo ordine è importante perché evita di cancellare e ricreare collegamenti a caso. Se il problema è soltanto un file spostato, non serve modificare query o tabelle. Se invece il percorso è corretto ma il nome remoto è cambiato, il relink deve essere fatto a livello di tabella.
Prima di iniziare: crea un backup del front-end
Prima di modificare molti collegamenti, crea una copia del file front-end. Il relink normalmente non modifica i dati della sorgente, ma una configurazione errata può collegare l’applicazione al database sbagliato, per esempio alla produzione invece che al test.
Se il back-end è Access e devi anche spostarlo o modificarne lo schema, crea un backup del back-end quando nessun utente lo sta usando. Se è SQL Server, affidati alla strategia di backup e change management del server.
Passaggio 1: identifica quali tabelle non sono disponibili
Apri il database e prova una o due tabelle critiche dal riquadro di spostamento. Non aprire decine di oggetti se il server è irraggiungibile: rischieresti solo di accumulare messaggi. Annota quali tabelle falliscono e quale messaggio viene mostrato.
Poi apri Dati esterni > Gestione tabelle collegate. Espandi le origini dati e osserva lo stato dei collegamenti. La finestra consente di lavorare a livello di sorgente oppure su singole tabelle.
Passaggio 2: aggiorna l’origine dati
Seleziona la sorgente e scegli Aggiorna. Access tenta di verificare i collegamenti esistenti e aggiorna lo stato. Questo passaggio serve a separare i collegamenti sani da quelli realmente problematici.
Se il problema era temporaneo, per esempio un server momentaneamente non raggiungibile che ora è tornato online, un aggiornamento può essere sufficiente. Se continua a risultare Non riuscito, passa alla verifica della sorgente.
Passaggio 3: controlla percorso, server e credenziali
Per un back-end Access verifica che il file esista davvero nel percorso atteso. Per SQL Server controlla nome server, database, autenticazione e driver. Per Excel o file di testo verifica che file e cartella non siano stati rinominati.
Microsoft indica che tra le cause comuni dello stato Failed ci sono nuove credenziali o cambi del nome tabella. Non presupporre quindi che “il server è acceso” significhi che il collegamento è corretto.
Passaggio 4: modifica l’origine dati
In Gestione tabelle collegate puoi selezionare l’origine e usare Modifica quando il tipo di sorgente lo permette. Puoi aggiornare informazioni come percorso, nome file, password o stringa di connessione a seconda della sorgente.
Microsoft suggerisce inoltre che, se le stringhe di connessione vengono gestite nel codice VBA, può essere più semplice mantenere le informazioni tramite Gestione tabelle collegate invece di costruire codice complesso che riscrive continuamente le connection string.
Passaggio 5: ricollega le tabelle in stato Non riuscito
Seleziona una o più tabelle con stato Non riuscito e scegli Ricollega. Access chiede la nuova origine o la tabella corretta. Dopo il relink, controlla la colonna Stato.
Lo stato Success indica che il collegamento è stato ricollegato con successo; Failed indica che esiste ancora un problema. Continua finché tutte le tabelle necessarie risultano corrette.
Non fermarti allo stato Success
Success conferma che Access riesce a stabilire il collegamento, ma non garantisce che l’intera applicazione funzioni. Dopo il relink devi verificare query, maschere, report e operazioni di aggiornamento. Se lo schema remoto è cambiato, il link può essere tecnicamente valido ma una query può continuare a usare campi rimossi.
Scenario 1: back-end Access spostato
È il caso tipico di un database diviso. Il front-end contiene tabelle collegate a un file back-end e quel file viene spostato su un nuovo server o in una nuova condivisione. Il vecchio front-end continua a puntare al percorso precedente.
Apri Gestione tabelle collegate, seleziona l’origine Access e scegli Ricollega. Seleziona il nuovo file ACCDB. Se i nomi delle tabelle sono invariati, Access può aggiornare i collegamenti in modo relativamente rapido.
Percorsi UNC e unità mappate
In un ambiente con molti utenti è generalmente preferibile usare un percorso di rete coerente indipendente dalle lettere di unità mappate sul singolo PC. Le lettere possono variare tra utenti, sessioni Remote Desktop e policy aziendali.
Qualunque metodo scegli, tutti gli utenti devono poter raggiungere il percorso e avere i permessi necessari sulla cartella del back-end.
Permessi della cartella del back-end
Per un back-end Access condiviso non basta che l’utente possa leggere il file. Access crea e gestisce un file di lock nella stessa cartella durante l’uso multiutente. Servono quindi autorizzazioni appropriate a livello di directory.
Se il file si apre solo in lettura o alcuni utenti ricevono errori mentre altri no, confronta le autorizzazioni dei gruppi. Non concedere permessi eccessivi senza una politica di sicurezza: usa gruppi e privilegi necessari al funzionamento.
Scenario 2: il nome della tabella è cambiato
Se la sorgente contiene una tabella rinominata, l’aggiornamento della sorgente può mostrare il collegamento come fallito. Ricollega la tabella e seleziona il nuovo nome remoto.
Dopo questa operazione verifica il nome locale del collegamento. Se decidi di rinominare anche l’oggetto nel front-end, devi controllare tutte le query, maschere, report e macro che fanno riferimento al nome precedente.
Scenario 3: è cambiato lo schema
Un amministratore SQL Server può aggiungere, eliminare o rinominare colonne. Un back-end Access può subire modifiche analoghe. Gestione tabelle collegate può aggiornare la struttura visibile, ma gli oggetti del front-end che usano campi rimossi restano da correggere.
Dopo un refresh dello schema, apri la tabella collegata e confronta i campi. Se una query mostra una richiesta “Inserire valore parametro” con il vecchio nome del campo, probabilmente sta ancora usando una colonna non disponibile.
Scenario 4: SQL Server non è raggiungibile
Con tabelle ODBC il problema può essere rete, DNS, firewall, server, database, autenticazione o driver. Prima di modificare il front-end verifica che il server sia raggiungibile dal PC interessato.
Se il problema riguarda tutti gli utenti contemporaneamente, è più probabile un guasto lato server o rete. Se riguarda un solo PC, confronta configurazione ODBC, driver e credenziali di quel client.
Autenticazione SQL Server
Un collegamento può usare autenticazione Windows, SQL Server o altri metodi supportati dal driver e dall’ambiente. Se la password viene cambiata o l’account perde accesso, il collegamento fallisce anche se server e database sono online.
Non memorizzare password in chiaro nel codice senza una valutazione di sicurezza. Quando possibile usa metodi di autenticazione e gestione credenziali coerenti con le policy dell’organizzazione.
Driver ODBC e compatibilità 32/64 bit
Access a 32 bit e Access a 64 bit devono usare componenti e driver compatibili con la propria architettura. Se un front-end funziona su un PC ma non su un altro dopo la migrazione a Office 64 bit, controlla che il driver ODBC corretto sia installato.
La bitness non cambia la logica delle tabelle collegate, ma determina quali driver possono essere caricati dal processo di Access. Standardizzare l’architettura semplifica molto il supporto.
DSN e connessioni DSN-less
Un collegamento ODBC può dipendere da un DSN configurato nel sistema oppure contenere le informazioni necessarie nella stringa di connessione. Se usi un DSN, assicurati che esista sul computer dell’utente nel contesto e nell’architettura corretti.
Le connessioni DSN-less riducono la dipendenza dalla configurazione locale, ma spostano la responsabilità sulla stringa e sul codice o sulla configurazione dell’applicazione. Documenta sempre quale modello usa il front-end.
Scenario 5: Azure SQL o server migrato
Quando un database viene migrato da SQL Server locale ad Azure SQL o a un nuovo server, il nome dell’host e altri parametri cambiano. Non basta aggiornare un singolo collegamento se molte tabelle condividono la stessa origine.
Gestione tabelle collegate consente di lavorare sulla sorgente e sulle tabelle associate. Dopo la modifica, testa autenticazione, lettura e scrittura, perché la connettività può richiedere configurazioni di rete differenti.
Scenario 6: Excel o file di testo spostati
Access può mantenere collegamenti anche a file Excel e testo. Se il file viene rinominato, spostato o sostituito con una struttura diversa, il collegamento può fallire oppure aprirsi ma restituire colonne inattese.
Verifica percorso, nome foglio o intervallo in Excel e intestazioni dei file di testo. Per processi critici valuta se sia più robusto importare i dati in una tabella staging anziché dipendere da un file modificabile esternamente.
Scenario 7: lista SharePoint modificata
Le liste SharePoint collegate dipendono dall’URL, dall’autenticazione e dallo schema della lista. Se una colonna viene eliminata o rinominata, aggiorna il collegamento e controlla le query del front-end.
Una lista SharePoint collegata non è la stessa cosa di un file ACCDB archiviato in una cartella sincronizzata. Evita di usare la sincronizzazione del file come sostituto della condivisione multiutente supportata.
Come verificare il collegamento dopo il relink
Apri la tabella collegata e controlla alcuni record. Poi esegui una query semplice che la utilizza. Se la tabella deve essere aggiornabile, modifica un record di test e annulla o ripristina la modifica secondo le procedure dell’ambiente.
Se il collegamento è SQL Server, verifica anche che la chiave primaria venga riconosciuta. Una tabella senza identificatore univoco adeguato può risultare leggibile ma non aggiornabile correttamente.
Testare maschere e report
Le maschere possono basarsi su query che combinano più tabelle, quindi una sola tabella ricollegata non garantisce il funzionamento dell’interfaccia. Apri le maschere principali, prova filtri e salvataggio dei record.
Genera anche i report critici. Un report può usare query diverse da quelle delle maschere e rivelare un campo rinominato non ancora corretto.
Come capire se il problema è nel front-end o nel back-end
Se una nuova copia del front-end collegata alla stessa origine funziona, il problema può essere nella copia locale dell’applicazione. Se tutti i front-end falliscono sulla stessa tabella, concentrati sul back-end, sulla rete o sul server.
In ambienti multiutente ogni utente dovrebbe normalmente avere una propria copia locale del front-end, mentre il back-end è condiviso. Questo rende più semplice sostituire un front-end difettoso senza toccare i dati.
VBA: RefreshLink per aggiornare collegamenti
DAO espone l’oggetto TableDef e il metodo RefreshLink. In un’applicazione amministrata puoi iterare le tabelle collegate e tentare un refresh all’avvio o durante una procedura di manutenzione.
Un esempio concettuale è: Set tdf = CurrentDb.TableDefs("Clienti"): tdf.RefreshLink. In un progetto reale devi aggiungere gestione errori, verificare la sorgente e non bloccare l’avvio con tentativi infiniti.
Ricollegamento automatico a un nuovo back-end
Per un database Access puoi aggiornare la proprietà Connect delle TableDef e poi chiamare RefreshLink. Questa tecnica è utile quando il percorso viene salvato in una tabella di configurazione.
Prima di cambiare tutti i link verifica che il file di destinazione esista e contenga le tabelle attese. Se la validazione fallisce, conserva i collegamenti correnti e mostra un messaggio all’amministratore.
Non hardcodare percorsi in decine di moduli
Se il percorso del back-end è scritto in molte procedure VBA, ogni migrazione diventa fragile. Centralizza la configurazione. Per esempio, mantieni un’unica funzione che restituisce il percorso o usa una tabella locale di configurazione.
Gestione tabelle collegate resta comunque utile per verificare lo stato reale dopo la modifica.
Come gestire più origini dati
Un front-end può collegarsi contemporaneamente a un back-end Access, SQL Server, Excel e SharePoint. Non trattare tutti i link come se avessero lo stesso ciclo di vita. Raggruppa le origini e assegna nomi chiari in Gestione tabelle collegate.
Quando una sorgente non è disponibile, evita di ricollegare inutilmente le altre. Lavora sul gruppo fallito e verifica successivamente le dipendenze.
Ambiente di test e produzione
Microsoft cita esplicitamente il passaggio da test a produzione come caso tipico di modifica della posizione dell’origine. Questa operazione deve essere controllata per evitare che un front-end di test scriva dati di produzione.
Prima del rilascio annota quale origine deve essere usata, esegui il relink nella copia di distribuzione e prova una query che identifichi chiaramente l’ambiente.
Documentare il relink
Registra data, versione del front-end, origine precedente, nuova origine, tabelle coinvolte e risultato dei test. Se il server viene migrato di nuovo, questa documentazione riduce drasticamente i tempi di intervento.
Per SQL Server documenta anche nome del driver e metodo di autenticazione. Per un back-end Access registra il percorso di rete previsto.
Errori dopo un aggiornamento di Windows o Office
Se le tabelle smettono di funzionare dopo un aggiornamento, non dare per scontato che l’aggiornamento sia la causa. Controlla prima rete, file, credenziali e driver. Se solo alcuni PC sono interessati, confronta versioni e architettura.
In Access Microsoft 365 gli aggiornamenti sono più frequenti rispetto ad Access 2024 perpetuo. Mantieni comunque configurazioni supportate e driver aggiornati.
Access Runtime
Gli utenti Runtime possono utilizzare tabelle collegate tramite l’applicazione, ma non hanno lo stesso ambiente di amministrazione di Access completo. Una soluzione distribuita dovrebbe quindi verificare i collegamenti all’avvio e mostrare un messaggio comprensibile se il back-end non è disponibile.
Il relink strutturale va progettato e testato nel sorgente ACCDB con Access completo, poi distribuito nella versione finale.
Quando ricreare completamente il collegamento
Se refresh e relink non risolvono, puoi eliminare il collegamento locale e ricrearlo, ma fallo soltanto dopo averne documentato nome e configurazione. Eliminare una tabella collegata da Access rimuove il collegamento, non la tabella nell’origine dati, come chiarisce Microsoft.
Fai attenzione ai nomi locali: se il nuovo collegamento riceve un nome diverso, le query esistenti potrebbero smettere di funzionare.
Quando non è un problema di collegamento
Una tabella può aprirsi correttamente ma una query può fallire per un riferimento a un campo rinominato. In questo caso il collegamento è sano e devi correggere la query. Allo stesso modo, un errore di conflitto di scrittura o #Eliminato su SQL Server può dipendere dalla concorrenza o dai tipi dati e non dal link.
La diagnosi corretta evita di ricreare collegamenti che erano già funzionanti.
Checklist passo passo
Quando una tabella collegata non è disponibile: crea una copia del front-end; apri Gestione tabelle collegate; aggiorna l’origine; identifica gli stati Non riuscito; controlla percorso, server, credenziali e driver; modifica la sorgente se necessario; ricollega le tabelle fallite; verifica che lo stato diventi Success; apri le tabelle; prova query, maschere e report; documenta la modifica.
Se dopo questi passaggi il problema resta, verifica schema, chiavi e dipendenze dell’applicazione prima di concludere che il database sia danneggiato.
FAQ sulle tabelle collegate non disponibili
Perché una tabella collegata improvvisamente non si apre?
Le cause più comuni sono percorso cambiato, file spostato, nome tabella modificato, credenziali cambiate, server non raggiungibile o driver mancante.
Devo cancellare e ricreare tutte le tabelle collegate?
No. Microsoft consiglia prima Refresh e correzione dell’origine, poi Relink delle sole tabelle in stato Failed.
Che cosa significa Success in Gestione tabelle collegate?
Significa che il collegamento è stato aggiornato con successo. Devi comunque testare gli oggetti dell’applicazione.
Posso aggiornare un collegamento con VBA?
Sì. Con DAO puoi usare TableDef.RefreshLink e, quando necessario, aggiornare la proprietà Connect. Serve però gestione errori e validazione della destinazione.
Access 2024 ha Gestione tabelle collegate?
Sì. La documentazione Microsoft corrente indica che la funzione si applica a Access Microsoft 365, Access 2024 e Access 2021, con alcune differenze dell’interfaccia tra versioni.
Un driver ODBC a 32 bit funziona con Access a 64 bit?
In generale il driver caricato dal processo deve essere compatibile con l’architettura dell’applicazione. Installa il driver appropriato e standardizza la configurazione dei client.
Perché il link è Success ma la query chiede un parametro?
Probabilmente lo schema è cambiato e la query usa un campo che non esiste più. Aggiorna la query dopo aver verificato la struttura della tabella.
Posso ricollegare direttamente dalla copia Runtime?
La gestione e lo sviluppo devono essere predisposti nella versione completa di Access. Runtime è pensato per eseguire l’applicazione distribuita.
Ricollegare in modo controllato più origini dati
Un front-end Access può contenere contemporaneamente tabelle collegate a un back-end ACCDB, SQL Server, file Excel e altre sorgenti. Quando più collegamenti risultano non disponibili, evita di correggerli alla cieca uno per volta. Raggruppa le tabelle per origine nel Gestore tabelle collegate e verifica prima la disponibilità della sorgente: percorso di rete, server, database, driver e autenticazione. Solo dopo aggiorna o ricollega le tabelle interessate. Questo rende più semplice capire se il problema è generale oppure riguarda una singola tabella.
Microsoft indica il Gestore tabelle collegate come punto centrale per aggiornare, ricollegare, aggiungere, modificare e cercare origini dati nelle versioni correnti di Access. Dopo il relink controlla lo stato di ogni tabella e ripeti l’operazione su quelle che non risultano aggiornate correttamente. Non considerare sufficiente il fatto che una sola maschera si apra: query e report meno usati possono dipendere da collegamenti differenti.
Test dopo un cambio di server o cartella
Quando il back-end viene spostato, prova il front-end da un PC utente reale e non soltanto dalla postazione amministrativa. Verifica permessi sulla condivisione, nome server, driver ODBC della corretta architettura e autenticazione. Se usi Access Runtime, effettua almeno un test anche in Runtime. Un collegamento funzionante sul PC dello sviluppatore può fallire altrove per una differenza di driver, credenziali o percorso mappato.
Conclusione
Aggiornare tabelle collegate non disponibili in Access richiede una procedura ordinata. Inizia sempre dal controllo dell’origine e dallo stato dei collegamenti, poi correggi percorso, credenziali o configurazione e ricollega soltanto ciò che fallisce.
La sequenza indicata dalla documentazione Microsoft — Refresh, correzione della sorgente, Relink dei collegamenti Failed e verifica fino allo stato Success — riduce gli interventi inutili e aiuta a capire dove si trova il problema. Dopo il relink prova comunque query, maschere, report e operazioni di scrittura, perché uno schema modificato può richiedere correzioni aggiuntive.
Per continuare consulta le altre Guide Microsoft Access su collegamenti, front-end/back-end, SQL Server, Runtime, manutenzione e troubleshooting.