Relazioni e collegamenti rotti in Microsoft Access possono manifestarsi in modi diversi: query che non restituiscono più dati, maschere che mostrano record incompleti, errori all’apertura di una tabella collegata, messaggi che indicano un file non trovato, impossibilità di applicare l’integrità referenziale oppure richieste parametro causate da campi che non esistono più. Per risolvere il problema bisogna prima capire se è rotta una relazione logica tra tabelle oppure un collegamento a un’origine dati esterna.
Questa guida spiega come diagnosticare e riparare entrambi i casi in Access per Microsoft 365 e Access 2024 su Windows. Vedremo relazioni uno-a-molti, chiavi primarie ed esterne, integrità referenziale, record orfani, tabelle collegate a un altro ACCDB, SQL Server, file spostati, modifiche di schema, Gestione tabelle collegate, VBA e considerazioni per ambienti multiutente e Runtime.
Per approfondire puoi consultare anche come usare Gestione tabelle collegate, come ricollegare le tabelle in Access, come aggiornare i collegamenti quando cambia il percorso del back-end e la raccolta completa delle Guide Access.
Relazione e collegamento non sono la stessa cosa
Una relazione descrive come due tabelle sono logicamente connesse. Per esempio, Clienti.IDCliente può essere collegato a Ordini.IDCliente con una relazione uno-a-molti. Un collegamento, invece, permette a un database Access di usare una tabella che risiede in un altro file o sistema.
Una tabella può essere collegata senza avere una relazione locale visibile, e due tabelle locali possono avere una relazione senza alcun collegamento esterno. Prima di intervenire identifica quindi quale livello è coinvolto.
Come riconoscere una relazione rotta
Una relazione può essere considerata problematica quando non è più definita come previsto, quando i campi chiave non hanno tipi compatibili, quando l’integrità referenziale non può essere applicata oppure quando esistono record orfani.
Apri Strumenti database > Relazioni e scegli di visualizzare tutte le relazioni. Microsoft spiega che una relazione è formata da campi corrispondenti in due tabelle e che l’integrità referenziale aiuta a mantenere sincronizzati i dati correlati. La guida ufficiale è Creare, modificare o eliminare una relazione.
Controllare chiave primaria e chiave esterna
In una relazione uno-a-molti, il lato “uno” utilizza normalmente una chiave primaria o un indice univoco. Il lato “molti” contiene una chiave esterna compatibile. Se la chiave primaria è Numerazione automatica con Dimensione campo Intero lungo, la chiave esterna deve normalmente essere Numero/Intero lungo.
Microsoft specifica che i campi correlati devono avere tipi compatibili e, per campi numerici, anche la Dimensione campo deve essere coerente. Se uno dei campi viene cambiato da Long Integer a Double o Testo, la relazione può non essere più valida.
Errore durante l’applicazione dell’integrità referenziale
Se Access non permette di selezionare “Applica integrità referenziale”, controlla tre elementi: tipo dei campi, unicità del lato padre e presenza di record orfani. Un record orfano è una riga nella tabella figlia con una chiave esterna che non esiste nella tabella padre.
Supponiamo che Ordini contenga IDCliente=500 ma Clienti non abbia alcun IDCliente=500. In questa situazione Access non può imporre la relazione senza prima risolvere l’incoerenza.
Come trovare record orfani
Puoi creare una query con LEFT JOIN dalla tabella figlia alla tabella padre e filtrare i casi in cui la chiave padre è Null. Per esempio:
SELECT Ordini.* FROM Ordini LEFT JOIN Clienti ON Ordini.IDCliente = Clienti.IDCliente WHERE Clienti.IDCliente Is Null;
Questa query mostra gli ordini che fanno riferimento a un cliente inesistente. Prima di eliminarli, determina perché esistono: potrebbe trattarsi di dati storici validi, importazioni incomplete o cancellazioni effettuate senza integrità referenziale.
Come correggere record orfani
Hai tre strategie: ripristinare il record padre corretto, aggiornare la chiave esterna della riga figlia oppure eliminare il record orfano se è realmente invalido. La scelta dipende dal significato dei dati.
Non assegnare automaticamente un cliente generico o il valore zero solo per far passare la relazione. Una correzione tecnica che altera la semantica dei dati può essere peggiore del problema originale.
Aggiornamenti ed eliminazioni a catena
Access consente di attivare aggiornamento e eliminazione a catena nelle relazioni con integrità referenziale. Queste opzioni sono potenti: l’eliminazione a catena può cancellare automaticamente record figli quando viene eliminato il record padre.
Attivale solo se il modello dati lo richiede. In un sistema ordini, eliminare un cliente potrebbe non dover cancellare lo storico degli ordini. In molti casi è preferibile impedire l’eliminazione del cliente e usare uno stato “inattivo”.
Relazioni sparite dopo importazione o copia tabelle
Importare tabelle da un altro database non garantisce sempre che tutte le relazioni e regole vengano ricreate nel modo desiderato, soprattutto se importi solo alcuni oggetti o modifichi la struttura. Dopo una migrazione controlla sempre la finestra Relazioni.
Confronta lo schema sorgente e destinazione: chiavi primarie, indici univoci, tipi, valori Null consentiti e proprietà dei campi. Una relazione ricreata graficamente ma con proprietà diverse può modificare il comportamento dell’applicazione.
Come riconoscere un collegamento rotto
Una tabella collegata rotta può mostrare errori come “Impossibile trovare il file”, “Access non trova l’oggetto”, “ODBC–call failed”, richieste credenziali oppure stato Failed in Gestione tabelle collegate. Nel riquadro di spostamento la tabella mantiene l’icona di collegamento ma non si apre correttamente.
Microsoft consiglia di usare Gestione tabelle collegate per aggiornare e ricollegare le origini. La procedura raccomandata è: Refresh della sorgente, correzione del percorso o delle credenziali, Relink delle tabelle con stato Failed e ripetizione fino a quando lo stato è Success. La documentazione ufficiale è Gestire le tabelle collegate.
Back-end Access spostato in un’altra cartella
È uno scenario molto comune. Il front-end contiene collegamenti a un vecchio percorso di rete, ma il file viene spostato su un nuovo server. Le tabelle collegate continuano a puntare al vecchio percorso e falliscono.
Apri Dati esterni > Gestione tabelle collegate, seleziona la sorgente e scegli Relink. Indica il nuovo file back-end e verifica che tutte le tabelle risultino Success. Se alcune falliscono, controlla che esistano ancora con lo stesso nome.
Usare percorsi UNC invece delle unità mappate
In ambienti aziendali è spesso più robusto usare un percorso UNC del server invece di una lettera di unità mappata. Le lettere possono differire tra utenti o sessioni Remote Desktop.
Se distribuisci lo stesso front-end a più PC, un percorso UNC coerente riduce i problemi. Verifica naturalmente permessi e disponibilità del server.
Permessi di cartella e collegamenti Access
Un utente che apre un back-end Access condiviso necessita di permessi adeguati sulla cartella, non solo sul file. Access deve poter creare e gestire il file di lock nella stessa directory. Se l’utente può leggere il file ma non scrivere nella cartella, potresti avere errori o apertura in sola lettura.
Non risolvere concedendo Full Control a Everyone senza valutazione. Usa gruppi di sicurezza e privilegi appropriati secondo le policy aziendali.
Tabelle collegate rinominate nel back-end
Se nel back-end rinomini Clienti in AnagraficaClienti, il front-end può continuare a cercare la vecchia tabella. Gestione tabelle collegate consente di ricollegare la tabella scegliendo il nuovo nome.
Dopo il relink verifica le query. Il nome della tabella collegata locale può rimanere quello precedente oppure essere modificato. Se lo cambi, tutte le query che la usano devono essere aggiornate.
Campi rinominati nel back-end
Una modifica di schema è più delicata di un semplice cambio percorso. Se una colonna viene rinominata o eliminata, le query locali possono continuare a riferirsi al vecchio nome e generare richieste parametro.
Dopo modifiche SQL Server o al back-end, esegui Refresh dei collegamenti e poi prova le query principali. Non considerare il relink completato finché l’intera applicazione non è stata testata.
SQL Server: collegamenti ODBC rotti
Con SQL Server, il collegamento dipende da server, database, driver, autenticazione, schema e nome tabella. Un errore può derivare da password scaduta, cambio DNS, migrazione del server, driver ODBC mancante o modifica dello schema.
In Gestione tabelle collegate verifica la connection string. Se l’applicazione usa DSN, assicurati che il DSN esista sul PC con l’architettura corretta. Se usa connessioni DSN-less, controlla il driver indicato nella stringa.
ODBC 32 bit e 64 bit
Se Access è a 64 bit deve utilizzare driver compatibili a 64 bit. Un front-end che funzionava con Access 32 bit può fallire dopo una migrazione se il driver richiesto non è installato nella nuova architettura.
Questo non significa che devi tornare automaticamente a 32 bit. La soluzione corretta è standardizzare Access e installare i driver supportati nella stessa bitness dell’applicazione.
Chiave primaria mancante su SQL Server
Una tabella SQL Server può essere leggibile ma non aggiornabile correttamente se Access non riesce a identificare un record in modo univoco. Assicurati che sul server esista una chiave primaria o un indice univoco appropriato.
Se durante il collegamento Access chiede di scegliere un identificatore univoco, non selezionare campi che non sono realmente unici. Meglio correggere lo schema server.
Relazioni locali e SQL Server
Le relazioni definite nel front-end Access non sostituiscono i vincoli di integrità referenziale sul server. Se SQL Server è il back-end principale, foreign key e regole critiche dovrebbero essere implementate sul server quando possibile, così da proteggere i dati anche da applicazioni diverse da Access.
Access può comunque usare join e relazioni per progettazione dell’interfaccia, ma la garanzia dell’integrità deve risiedere nel sistema che possiede i dati.
Relazioni tra tabelle collegate Access
Se il back-end è un altro file Access, le relazioni reali vengono normalmente definite nel back-end dove risiedono le tabelle. Nel front-end puoi vedere o usare i dati collegati, ma la manutenzione dell’integrità va eseguita sul database che contiene fisicamente le tabelle.
Apri il back-end in modalità esclusiva per modifiche strutturali importanti e assicurati che nessun utente lo stia usando.
Quando una query smette di funzionare dopo il relink
Se il collegamento è Success ma la query fallisce, confronta schema vecchio e nuovo. Potrebbero essere cambiati tipo dati, lunghezza, nome dei campi o chiave. Il problema non è più il percorso ma la compatibilità logica.
Apri la tabella collegata e controlla in visualizzazione Struttura quali campi vede Access. Poi confronta la SQL della query.
Collegamenti Excel e file di testo
Access può collegare anche Excel e file di testo, ma questi formati non hanno la stessa struttura di un database relazionale. Se il file viene spostato o rinominato, il collegamento fallisce. Se cambiano intestazioni o tipi, query e maschere possono comportarsi diversamente.
Per processi critici è spesso più stabile importare i dati in una tabella staging piuttosto che mantenere un collegamento permanente a un file che utenti possono modificare.
SharePoint e origini cloud
Le liste SharePoint collegate dipendono da URL, autenticazione e schema della lista. Se una colonna viene rinominata o rimossa, aggiorna il collegamento e verifica le query.
Non confondere le liste SharePoint collegate con l’apertura multiutente di un file ACCDB da una cartella OneDrive sincronizzata. Sono architetture differenti.
VBA per controllare i collegamenti all’avvio
In applicazioni distribuite puoi creare una routine che controlla le proprietà Connect delle TableDef collegate e tenta un RefreshLink. Questo consente di rilevare subito un back-end non disponibile.
Una logica semplificata può iterare CurrentDb.TableDefs, identificare le tabelle collegate e chiamare tdf.RefreshLink. Gestisci gli errori e mostra un messaggio chiaro invece di lasciare l’utente davanti a errori tecnici.
Non modificare automaticamente la connection string senza una configurazione affidabile. In ambienti aziendali conserva il percorso in una tabella di configurazione o in un file controllato.
VBA e relink di un back-end Access
Per un file Access, la proprietà Connect di una TableDef contiene un riferimento al database esterno. Puoi aggiornare il percorso e chiamare RefreshLink. Questo è utile quando distribuisci lo stesso front-end in ambienti test e produzione.
Prima del relink automatico verifica che il file esista e che l’utente abbia permessi. Se il file non è raggiungibile, non cancellare i collegamenti correnti.
Come documentare i collegamenti
Per ogni front-end mantieni un inventario con nome tabella locale, origine, percorso/server, tabella remota e metodo di autenticazione. In SQL Server documenta anche driver e schema.
Questa documentazione rende molto più semplice migrare un server o ripristinare l’applicazione dopo un guasto.
Controllare dipendenze prima di rinominare campi
Prima di rinominare una tabella o un campo, cerca tutte le query, maschere, report, macro e moduli VBA che lo usano. Un cambiamento apparentemente semplice può rompere decine di oggetti.
Nei progetti maturi conviene applicare modifiche di schema con una checklist e un ambiente di test.
Compatta e ripristina: quando serve
Se una relazione locale scompare o il database mostra comportamenti anomali dopo crash, può esserci corruzione. Crea prima un backup e poi valuta Compatta e ripristina.
Questa operazione non ripara un percorso di collegamento sbagliato e non ricrea automaticamente relazioni eliminate intenzionalmente. Serve per problemi del file, non per errori di configurazione.
Come ricreare una relazione eliminata
Apri Strumenti database > Relazioni, aggiungi le due tabelle, trascina la chiave primaria sul campo esterno e configura integrità referenziale e opzioni a catena secondo il modello originale.
Prima di fare clic su Crea, verifica i record orfani. Se Access rifiuta l’integrità, non disattivarla solo per completare l’operazione: trova i dati incoerenti.
Backup prima delle modifiche strutturali
Modifiche a chiavi, relazioni e tipi possono avere impatto su molti oggetti. Crea una copia del front-end e del back-end prima di intervenire. In multiutente assicurati che il back-end non sia aperto.
Per SQL Server usa la strategia di backup gestita dal server e coordina le modifiche con l’amministratore.
Ambienti test e produzione
Gestione tabelle collegate è utile per passare da un’origine test a una produzione. Tuttavia non effettuare il cambio manualmente su ogni PC senza controllo. Automatizza la distribuzione del front-end e verifica che la configurazione punti all’ambiente giusto.
Un front-end di test collegato accidentalmente alla produzione può modificare dati reali durante le prove.
Access Runtime
In Runtime l’utente non dispone degli stessi strumenti di progettazione. Se un collegamento è rotto, l’app dovrebbe rilevarlo all’avvio e mostrare istruzioni comprensibili oppure eseguire un relink controllato.
Le relazioni strutturali devono essere corrette nel sorgente ACCDB o nel back-end, non nel file distribuito ACCDE.
Controllo dopo il ripristino da backup
Dopo aver ripristinato un front-end o un back-end da un backup, non dare per scontato che i collegamenti siano ancora corretti. Il backup potrebbe provenire da un server precedente, da un ambiente test oppure da una cartella con un percorso differente. Apri Gestione tabelle collegate e verifica tutte le origini prima di consegnare il database agli utenti.
Controlla inoltre che le relazioni del back-end siano quelle previste. Se il backup è molto più vecchio, potrebbe non contenere modifiche di schema introdotte successivamente. Confronta quindi versione dell’applicazione, schema e data del backup.
Relazioni e migrazioni di versione
Il passaggio da un vecchio MDB a un ACCDB moderno può essere l’occasione per verificare relazioni, indici e tipi. Non limitarti a convertire il file e considerare il lavoro concluso. Esegui query per trovare orfani, controlla le chiavi e verifica l’integrità referenziale.
Se alcune tabelle sono state spostate su SQL Server, documenta quali vincoli sono rimasti in Access e quali sono stati trasferiti al server. Una migrazione incompleta può lasciare regole duplicate o, al contrario, nessuna regola efficace.
Come testare davvero una relazione riparata
Non basta vedere la linea nella finestra Relazioni. Crea record di prova in un ambiente separato: inserisci un padre, aggiungi un figlio, prova a inserire una chiave esterna inesistente e verifica che Access la rifiuti se l’integrità referenziale è attiva. Se sono abilitate opzioni a catena, testa con dati non reali anche aggiornamento ed eliminazione.
Il test deve riflettere il comportamento voluto. Se l’eliminazione di un cliente non deve cancellare gli ordini, assicurati che l’opzione a catena non sia attiva. Una relazione tecnicamente valida può comunque essere progettata in modo sbagliato.
Come testare davvero un collegamento riparato
Dopo il relink apri ogni tabella critica, poi una query che la utilizza, una maschera di modifica e un report. Se l’origine è SQL Server, prova anche un aggiornamento su un record di test. Uno stato Success in Gestione tabelle collegate indica che il collegamento è stato aggiornato, ma il test funzionale serve a verificare tipi, chiavi e query dipendenti.
Se usi più origini dati, controllale separatamente. Un’applicazione può avere dieci tabelle nel back-end Access e cinque su SQL Server: il fatto che una sorgente funzioni non conferma le altre.
Prevenire il problema con una procedura di rilascio
Ogni nuova versione del front-end dovrebbe includere una verifica automatica o manuale dei collegamenti. Mantieni una lista delle origini attese e una versione dello schema. Prima della distribuzione compila VBA, aggiorna i collegamenti nell’ambiente corretto e prova le funzioni principali.
Per le modifiche al back-end pianifica una finestra di manutenzione. Chiedi agli utenti di uscire, esegui un backup, applica la modifica, aggiorna i front-end e verifica il risultato prima di riaprire l’accesso.
Checklist completa di troubleshooting
Per una relazione rotta controlla: chiavi, tipi dati, Dimensione campo, indici univoci, record orfani, integrità referenziale e opzioni a catena. Per un collegamento rotto controlla: percorso, file, server, credenziali, driver, bitness, nome tabella, schema e stato in Gestione tabelle collegate.
Dopo ogni correzione esegui le query principali, apri maschere e report e prova inserimento, modifica ed eliminazione su dati di test. Registra che cosa hai modificato e conserva una procedura di rollback.
FAQ su relazioni e collegamenti rotti in Access
Come faccio a sapere se è rotta una relazione o un collegamento?
Se la tabella non si apre o l’origine non viene trovata, è probabilmente il collegamento. Se i dati si aprono ma join e integrità non funzionano, controlla le relazioni.
Perché Access non mi fa applicare integrità referenziale?
Di solito perché i campi non sono compatibili, il lato padre non è univoco o esistono record orfani.
Come trovo record orfani?
Usa una LEFT JOIN dalla tabella figlia alla padre e filtra dove la chiave padre è Null.
Gestione tabelle collegate cambia anche le query?
No. Aggiorna il collegamento, ma se nomi o schema cambiano devi verificare e correggere le query dipendenti.
Meglio usare una lettera mappata o un percorso UNC?
Per distribuzioni multiutente il percorso UNC è generalmente più coerente perché non dipende dalla lettera mappata sul singolo PC.
Una relazione Access protegge SQL Server?
No. I vincoli critici devono essere definiti sul server se SQL Server è l’origine autorevole.
Il relink può essere automatizzato?
Sì, usando TableDef.RefreshLink e aggiornando la proprietà Connect, ma serve gestione errori e una configurazione affidabile.
Compatta e ripristina ricrea relazioni eliminate?
No. Può aiutare con corruzione del file, ma non ricostruisce automaticamente una relazione cancellata.
Controllare l’integrità dopo la riparazione
Dopo aver ripristinato una relazione o ricollegato una tabella non basta verificare che Access non mostri più un errore. Esegui controlli sui dati: cerca record orfani, verifica che le chiavi esterne puntino a record esistenti e prova le operazioni che gli utenti eseguono ogni giorno. Se hai riattivato l’integrità referenziale, controlla che gli aggiornamenti e le eliminazioni a catena siano davvero coerenti con le regole aziendali. Una relazione tecnicamente valida può comunque essere progettata male rispetto al flusso reale.
Nei database con SQL Server come back-end verifica anche che le tabelle collegate dispongano di una chiave primaria o di un identificatore univoco adeguato. Access deve poter identificare in modo affidabile le righe aggiornabili. Se il collegamento è stato ricreato dopo una modifica dello schema, testa inserimento, modifica e cancellazione su una copia o ambiente di prova prima di considerare risolta l’anomalia.
Documentare percorsi e dipendenze
Per ridurre il rischio di collegamenti rotti futuri, documenta il percorso dei back-end, i nomi delle tabelle collegate, i driver ODBC richiesti e le eventuali modalità di autenticazione. Nei progetti multiutente preferisci percorsi UNC stabili alle unità di rete mappate, perché una lettera come Z: può non esistere su tutti i PC. Mantieni inoltre una procedura di ricollegamento testata e una copia del front-end sorgente prima di ogni modifica strutturale.
Conclusione
Riparare relazioni o collegamenti rotti in Access richiede prima di distinguere il livello del problema. Le relazioni riguardano la coerenza logica dei dati; i collegamenti riguardano il percorso e la connessione all’origine esterna.
Per le relazioni verifica chiavi, tipi compatibili, record orfani e integrità referenziale. Per le tabelle collegate usa Gestione tabelle collegate seguendo la sequenza Refresh, correzione origine, Relink e verifica dello stato Success. Nei sistemi SQL Server controlla anche driver, chiavi e schema server.
Per altri tutorial consulta la sezione Guide Microsoft Access.