Usare Gestione tabelle collegate Access significa avere un punto centrale da cui controllare se le tabelle esterne sono raggiungibili, aggiornare i collegamenti dopo uno spostamento del back-end e diagnosticare rapidamente credenziali, percorsi o nomi di origine cambiati. In Microsoft 365 e Access 2024 questo strumento è particolarmente utile nei database divisi in front-end e back-end, nelle soluzioni che usano SQL Server tramite ODBC e nei progetti che collegano file Excel, altri database Access o liste SharePoint.
La regola più importante è semplice: Gestione tabelle collegate non sposta i dati e non crea copie dei record. Lavora sui collegamenti memorizzati nel front-end. Per questo va usata con metodo, soprattutto in ambienti multiutente: prima si verifica l’origine dati, poi si aggiorna, quindi si ricollegano solo le tabelle che risultano in errore. Microsoft suggerisce proprio questa sequenza operativa. In questa guida vediamo come applicarla in modo pratico e sicuro.
Indice
- Che cos’è Gestione tabelle collegate
- Quando usarla
- Come aprirla in Access
- Aggiornare i collegamenti
- Ricollegare un back-end Access
- Gestire origini ODBC e SQL Server
- Controllare lo stato delle tabelle
- Gestire percorsi di rete
- Automatizzare il relink con VBA
- Problemi comuni e troubleshooting
- Microsoft 365, Access 2024 e Runtime
- FAQ e buone pratiche
Che cos’è Gestione tabelle collegate in Access
Gestione tabelle collegate è l’interfaccia di Access dedicata alle tabelle che non risiedono fisicamente nel file front-end. Una tabella collegata appare nel riquadro di spostamento quasi come una tabella locale, ma i dati vengono letti da un’altra origine: un file .accdb o .mdb, una sorgente ODBC, SQL Server, una lista SharePoint oppure, in alcuni casi, un file esterno supportato da Access.
Quando il percorso o la configurazione dell’origine cambia, Access conserva il vecchio riferimento e la tabella può smettere di aprirsi. In un database diviso è il caso classico: il front-end contiene query, maschere, report, macro e VBA, mentre il back-end contiene le tabelle. Se il back-end passa da una cartella locale a una condivisione di rete, le tabelle del front-end continuano a cercare la vecchia posizione finché non vengono ricollegate.
La funzione è quindi strettamente collegata alle guide su come dividere un database Access in front-end e back-end, come spostare il back-end Access su un server di rete e come ricollegare le tabelle collegate.
Quando conviene usare Gestione tabelle collegate
Lo strumento serve ogni volta che il front-end deve verificare o modificare la relazione con una sorgente esterna. I casi più frequenti sono lo spostamento del back-end, la rinomina di un file, la migrazione da una cartella locale a una condivisione di rete, il cambio di server SQL, la modifica di DSN o credenziali ODBC e la necessità di aggiornare lo schema percepito da Access.
È utile anche senza errori apparenti. Dopo una modifica strutturale del back-end, per esempio l’aggiunta di un campo o la modifica di una tabella, un aggiornamento del collegamento consente ad Access di rileggere le informazioni della sorgente. Non sostituisce però una progettazione corretta: se cambiano chiavi, tipi dati o relazioni in modo incompatibile, bisogna verificare query, maschere e codice dipendente.
Un esempio concreto
Immagina un database per la gestione ordini usato da dieci persone. Ogni PC contiene una copia locale del front-end; sul server è presente il file back-end. Il server viene sostituito e cambia la cartella condivisa. Tutte le copie del front-end devono essere aggiornate. Gestione tabelle collegate permette di selezionare la sorgente precedente e ricollegarla al nuovo file. Se le tabelle mantengono gli stessi nomi, l’operazione è rapida e non richiede di ricreare manualmente ogni collegamento.
Come aprire Gestione tabelle collegate
In Access per Microsoft 365 e Access 2024 apri il database front-end, vai nella scheda Dati esterni e scegli Gestione tabelle collegate. La finestra elenca le origini dati e le tabelle collegate associate. Nelle versioni moderne l’interfaccia consente di espandere una sorgente, selezionare singole tabelle, cercare collegamenti e visualizzare lo stato.
Prima di fare modifiche, crea una copia del front-end. In genere il relink non altera i dati nel back-end, ma un backup del file applicativo rende semplice tornare indietro se cambi per errore una sorgente o una tabella. In un ambiente aziendale esegui la modifica su una copia di test, verifica maschere, query e report, quindi distribuisci il nuovo front-end agli utenti.
La sequenza corretta: aggiorna, controlla, ricollega
Microsoft raccomanda una sequenza precisa. Primo: aggiorna l’origine per verificare che sia raggiungibile. Secondo: se compare un problema, correggi la posizione o le credenziali. Terzo: ricollega le tabelle con stato non riuscito. Quarto: ripeti finché tutte risultano correttamente collegate. Questa sequenza evita di cambiare collegamenti che in realtà funzionano e aiuta a isolare l’errore.
1. Aggiornare una sorgente
Apri Gestione tabelle collegate, espandi la sorgente interessata e seleziona l’origine oppure le singole tabelle. Premi Aggiorna. Access tenta di contattare la sorgente usando le informazioni già memorizzate. Se il file è ancora nello stesso percorso e le autorizzazioni sono valide, lo stato dovrebbe risultare positivo.
Un aggiornamento è la prima scelta quando sai che il back-end non è stato spostato ma hai modificato lo schema o sospetti un problema temporaneo di rete. Se fallisce, non insistere in modo casuale: controlla percorso, nome del file, connettività e autorizzazioni.
2. Ricollegare una sorgente
Se il percorso è cambiato, seleziona la sorgente e scegli Ricollega. Access chiede di indicare la nuova posizione. Per un back-end Access selezioni il nuovo .accdb; per una sorgente ODBC potresti dover confermare DSN, server, database e autenticazione. Alla fine verifica la colonna Stato.
Se solo una tabella è stata rinominata nel back-end, puoi ricollegare quella specifica tabella e scegliere il nuovo nome. Tuttavia, se il cambio rompe query o codice che fanno riferimento al nome locale, è spesso più prudente mantenere nel front-end il nome atteso dall’applicazione e cambiare solo il collegamento alla tabella remota.
Come ricollegare un back-end Access spostato
Il caso più comune è un file back-end .accdb spostato da una cartella a un’altra. Prima verifica che il nuovo percorso sia raggiungibile da tutti i PC. Se il database è multiutente, preferisci un percorso di rete uniforme e documentato invece di una lettera mappata che potrebbe cambiare da utente a utente.
Apri il front-end mentre nessuno lo sta modificando. In Gestione tabelle collegate seleziona tutte le tabelle che puntano al vecchio back-end, scegli Ricollega e indica il nuovo file. Se Access chiede di selezionare le tabelle, associa quelle corrette. Al termine apri alcune tabelle, prova una query di selezione, inserisci un record di test in un ambiente non produttivo e verifica una maschera di modifica.
Perché testare anche scrittura e modifica
Una tabella può aprirsi in lettura ma non essere aggiornabile a causa di permessi, chiavi o configurazioni. Perciò il test non deve fermarsi a vedere i record. Verifica inserimento, modifica e cancellazione secondo le regole reali dell’applicazione. In SQL Server, per esempio, una tabella collegata senza una chiave univoca riconosciuta può risultare non aggiornabile anche se la connessione è corretta.
Gestione tabelle collegate con SQL Server e ODBC
Con SQL Server la logica è simile ma ci sono più livelli: driver ODBC, DSN o connessione DSN-less, nome server, database, autenticazione, certificati e autorizzazioni. Gestione tabelle collegate può aggiornare o modificare la sorgente e ricollegare le tabelle, ma non risolve problemi del server. Se la connessione fallisce, verifica prima che il server risponda e che il driver corretto sia installato.
In ambienti moderni conviene usare driver ODBC Microsoft supportati e mantenere coerente l’architettura 32/64 bit con Access e con eventuali DSN. Un DSN ODBC creato con l’amministratore a 64 bit non è automaticamente visibile a un’applicazione Access a 32 bit. Questa distinzione è una causa frequente di origine dati non trovata.
Se stai lavorando con un’architettura ibrida Access + SQL Server, consulta anche come usare Access come front-end di SQL Server.
Come leggere lo stato dei collegamenti
Nelle versioni moderne di Gestione tabelle collegate la colonna Stato è molto utile. Uno stato positivo indica che Access ha potuto verificare il collegamento. Uno stato di errore segnala invece che almeno una parte della configurazione non è valida: percorso assente, tabella rinominata, password cambiata, DSN non disponibile, credenziali scadute o autorizzazioni insufficienti.
Non limitarti al messaggio generico. Se una sorgente contiene trenta tabelle e solo una fallisce, espandi la sorgente e individua la tabella specifica. Potrebbe essere stata rinominata o eliminata. Se tutte falliscono insieme, il problema è più probabilmente a livello di file, server, DSN o credenziali.
Percorsi di rete, permessi e stabilità
Un database Access condiviso funziona meglio quando il back-end si trova su una LAN affidabile, non su una cartella sincronizzata via cloud. Gli utenti devono avere permessi di lettura, scrittura, creazione e cancellazione nella cartella che contiene il back-end, perché Access crea file di blocco nella stessa posizione. Un permesso di sola lettura sulla cartella può produrre errori di apertura o comportamento inatteso.
Evita di aprire direttamente un .accdb condiviso da OneDrive o da una raccolta documenti SharePoint. Microsoft avverte che il file può essere scaricato localmente e poi risincronizzato, generando copie multiple o comportamenti imprevisti quando più persone lo aprono. Per SharePoint è preferibile collegare liste SharePoint come origine dati oppure usare un’architettura diversa.
Automatizzare il relink con VBA
Gestione tabelle collegate è ideale per interventi manuali. Se distribuisci un front-end su molti PC, può essere utile automatizzare il controllo dei collegamenti all’avvio. Con DAO puoi scorrere la raccolta TableDefs, leggere la proprietà Connect, modificare il percorso e chiamare RefreshLink. La logica essenziale è: aprire CurrentDb, ciclare le TableDef, riconoscere quelle che appartengono al back-end da aggiornare, assegnare la nuova stringa di connessione e invocare RefreshLink. In produzione aggiungi gestione errori, log e verifica preventiva del file.
Questo approccio va usato con cautela. Una soluzione Access può contenere contemporaneamente tabelle collegate a un .accdb, SQL Server e SharePoint. Riscrivere indiscriminatamente la proprietà Connect di tutte le tabelle romperebbe le sorgenti che non usano lo stesso formato. Il codice deve quindi riconoscere il tipo di collegamento prima di intervenire.
Diagnosi metodica: dal sintomo alla causa
Quando un collegamento non funziona, procedi per livelli. Il primo livello è il file o server: esiste, è raggiungibile, risponde? Il secondo livello è l’identità dell’utente: possiede i permessi necessari? Il terzo è il driver o provider: la macchina dispone della versione corretta e dell’architettura giusta? Il quarto è il collegamento Access: la stringa Connect punta alla sorgente corretta? Il quinto è lo schema: tabella, campi e chiavi coincidono con ciò che il front-end si aspetta?
Questo ordine riduce molto i tempi di troubleshooting. Se non riesci nemmeno ad aprire la cartella di rete da Windows, non ha senso modificare una query Access. Se la cartella è raggiungibile ma tutte le tabelle risultano Failed, il problema è probabilmente nel collegamento o nei permessi. Se una sola tabella fallisce, concentra l’analisi su nome e schema di quella tabella.
Controllare la stringa di connessione
Per le tabelle collegate è utile conoscere la proprietà Connect. In VBA puoi ispezionare una TableDef oppure creare una piccola routine amministrativa. Evita però di mostrare password o segreti agli utenti. Le stringhe di connessione possono contenere informazioni sensibili, soprattutto con alcune configurazioni ODBC.
Registrare gli errori di relink
In un’applicazione professionale crea una tabella locale di log con data, computer, utente Windows, nome tabella, vecchia sorgente, nuova sorgente, esito e numero errore. Un log consente di capire se il problema riguarda un singolo PC o l’intera distribuzione. È molto più utile di una schermata con il solo messaggio collegamento non riuscito.
Strategia per più ambienti: sviluppo, test e produzione
Le applicazioni Access aziendali mature spesso hanno almeno due ambienti: test e produzione. Il front-end dovrebbe poter essere collegato al back-end corretto senza modifiche manuali sparse nel codice. Puoi conservare la configurazione in una tabella locale, in un file di impostazioni protetto o in una costante centralizzata, quindi eseguire un controllo dei collegamenti all’avvio.
Durante lo sviluppo collega il front-end a dati di prova. Prima del rilascio crea una copia, ricollega alla produzione, verifica le tabelle, compila il VBA e testa le funzioni critiche. Se distribuisci un ACCDE, esegui il relink e i test prima di creare la versione finale oppure progetta un meccanismo di relink compatibile con l’ACCDE.
Gestire cambi di schema senza interrompere gli utenti
Il relink non è una migrazione dello schema. Se nel back-end aggiungi un campo opzionale, molte query continueranno a funzionare; se rinomini o elimini un campo usato da query e maschere, il front-end può rompersi anche dopo un collegamento riuscito. Per questo le modifiche strutturali dovrebbero essere versionate e testate insieme al front-end.
Una buona pratica è assegnare una versione al back-end e una al front-end. All’avvio il front-end può leggere una tabella di configurazione nel back-end e verificare che la versione minima sia compatibile. Se non lo è, mostra un messaggio chiaro e impedisce operazioni potenzialmente pericolose. Questo evita che un vecchio front-end lavori su uno schema nuovo.
Problemi comuni e soluzioni
Il pulsante Aggiorna restituisce Failed
Controlla prima la raggiungibilità dell’origine. Per un file di rete prova ad aprire la cartella da Esplora file usando lo stesso account Windows. Verifica nome del server, condivisione, file e autorizzazioni. Se il file esiste ma Access non lo apre, controlla permessi e blocchi.
Access chiede continuamente credenziali ODBC
Le credenziali possono non essere salvate nel modo previsto oppure l’organizzazione può imporre autenticazione interattiva. Valuta Windows Authentication quando appropriata e concordata con l’amministratore SQL. Evita password in chiaro nel codice VBA o in file distribuiti.
Una tabella è collegata ma non aggiornabile
Verifica chiave primaria o indice univoco, autorizzazioni di scrittura, query sottostante e tipo di sorgente. Su SQL Server Access ha bisogno di identificare univocamente i record per aggiornare una tabella collegata. Una vista complessa può essere leggibile ma non aggiornabile.
Dopo il relink alcune query danno errore
Controlla che i nomi dei campi e i tipi dati siano rimasti compatibili. Il collegamento può essere tecnicamente valido ma lo schema può essere cambiato. Una query che usa un campo rinominato non si corregge da sola.
Il collegamento funziona sul PC dell’amministratore ma non sugli altri
Quasi sempre il problema è un percorso locale, una lettera mappata diversa, un DSN presente solo su un computer, un driver mancante o permessi diversi. Distribuisci configurazioni coerenti e documenta prerequisiti, versione di Access, architettura 32/64 bit e driver ODBC.
Microsoft 365, Access 2024 e versioni precedenti
Microsoft documenta Gestione tabelle collegate per Access per Microsoft 365 e Access 2024, oltre a versioni precedenti ancora presenti in molte aziende. L’interfaccia non è identica in tutte le release. Nelle versioni moderne sono disponibili funzioni più ricche per ricerca, aggiunta, modifica e gestione delle sorgenti. Per questo una procedura scritta per una versione più vecchia potrebbe non corrispondere esattamente alla finestra vista in Microsoft 365.
Il principio però rimane invariato: le tabelle collegate conservano informazioni sull’origine, e quando l’origine cambia occorre aggiornare o ricollegare. Se gestisci un parco PC eterogeneo, documenta la versione minima supportata e testa il front-end sulla versione più vecchia realmente in uso.
Access Runtime: cosa cambia
Access Runtime è pensato per eseguire applicazioni Access senza fornire l’intero ambiente di progettazione. Non è lo strumento giusto per attività amministrative come la gestione manuale delle tabelle collegate da parte dell’utente finale. In un’app distribuita con Runtime conviene quindi fare il relink prima della consegna oppure integrare nel front-end una procedura controllata che verifichi e aggiorni i collegamenti.
Il Runtime non va confuso con una misura di sicurezza completa. Microsoft chiarisce che limita molte funzioni di progettazione e navigazione, ma non sostituisce una strategia di protezione. Per una distribuzione professionale si possono combinare front-end ACCDE, cartelle attendibili, permessi Windows sul back-end e, quando necessario, SQL Server come livello dati.
Buone pratiche per database multiutente
Ogni utente dovrebbe avere una copia locale del front-end. Il back-end può essere condiviso in una cartella di rete affidabile. Non mettere un unico front-end condiviso sul server e farlo aprire contemporaneamente da tutti: aumenta il traffico, complica gli aggiornamenti e rende più fragile l’applicazione. La guida come distribuire il front-end Access agli utenti approfondisce questo modello.
Quando devi cambiare percorso del back-end, crea prima una versione aggiornata del front-end in un ambiente di test. Esegui Gestione tabelle collegate, verifica tutte le origini, salva, chiudi e riapri il database, quindi testa le funzioni principali. Solo dopo sostituisci le copie locali. In questo modo la modifica dei collegamenti diventa parte di una procedura di rilascio controllata, non un intervento improvvisato su ogni PC.
Checklist operativa
- Fai un backup del front-end.
- Verifica che il nuovo back-end o server sia raggiungibile.
- Controlla permessi di cartella o credenziali database.
- Apri Dati esterni e Gestione tabelle collegate.
- Aggiorna prima la sorgente esistente.
- Ricollega solo se percorso o origine sono cambiati.
- Controlla lo stato di ogni tabella.
- Apri tabelle e query principali.
- Testa inserimento, modifica e cancellazione.
- Testa maschere, report e procedure VBA.
- Distribuisci il front-end aggiornato.
- Documenta il nuovo percorso e la data della modifica.
FAQ
Gestione tabelle collegate copia i dati?
No. Gestisce i riferimenti alle origini esterne. I dati restano nella sorgente, per esempio nel back-end .accdb o in SQL Server.
Posso ricollegare tutte le tabelle in una volta?
Sì, se appartengono alla stessa sorgente puoi selezionare l’origine o più tabelle. Controlla comunque lo stato finale di ciascuna e fai test funzionali.
È meglio usare un percorso uniforme di rete?
Sì. In un ambiente con più PC un percorso di rete coerente è più facile da distribuire e diagnosticare rispetto a configurazioni locali differenti.
Gestione tabelle collegate funziona con SQL Server?
Sì, Access può gestire tabelle collegate ODBC. Devi però avere driver, configurazione, credenziali e permessi corretti.
Posso usare OneDrive come back-end condiviso?
Non è consigliabile aprire direttamente un file Access condiviso da OneDrive o da una raccolta documenti SharePoint. Microsoft segnala il rischio di copie multiple e comportamenti inattesi. Per SharePoint usa piuttosto liste collegate quando adatte al progetto.
Devo usare Gestione tabelle collegate su ogni PC?
Se ogni PC possiede una copia identica del front-end, puoi aggiornare una copia master, testarla e ridistribuirla. È più controllabile rispetto a modificare manualmente ogni installazione.
Posso automatizzare il relink?
Sì. DAO espone TableDef, proprietà Connect e metodo RefreshLink. Il codice deve però distinguere correttamente i diversi tipi di sorgente.
Conclusione
Usare Gestione tabelle collegate Access in modo corretto permette di mantenere stabile un database diviso, aggiornare il percorso del back-end e diagnosticare rapidamente collegamenti interrotti. La strategia migliore è partire sempre dal controllo della sorgente, aggiornare, ricollegare solo ciò che serve e verificare lo stato finale con test reali di lettura e scrittura.
Nei database multiutente questa funzione deve inserirsi in una gestione più ampia: front-end locale per ogni utente, back-end su rete affidabile, percorsi coerenti, backup e rilascio controllato. Per continuare consulta tutte le Guide Access.
Fonti ufficiali: Microsoft Support – Manage linked tables; Microsoft Support – Split an Access database; Microsoft Support – Ways to share an Access desktop database.