Gli errori di tipo durante le importazioni in Access sono tra i problemi più comuni quando si trasferiscono dati da Excel, CSV, file di testo o altre origini verso una tabella Access. Il sintomo può essere evidente, con un messaggio come “Errore di conversione del tipo”, oppure più subdolo: valori importati come Null, date trasformate in numeri, codici interpretati come valori numerici, campi troncati o righe inserite nella tabella degli errori di importazione.
Il problema nasce quasi sempre da una differenza tra il tipo di dati che Access si aspetta e il contenuto reale della sorgente. Durante l’importazione, Access deve decidere se una colonna contiene testo, numeri, date, valori Sì/No o altri tipi. Se i dati sono incoerenti, oppure la tabella di destinazione ha una struttura incompatibile, alcune righe possono fallire.
Questa guida spiega come diagnosticare e correggere gli errori di tipo in modo affidabile in Access per Microsoft 365 e Access 2024 su Windows, con esempi relativi a Excel, CSV, TXT, append a tabelle esistenti, specifiche di importazione e automazioni VBA. Access è un’applicazione desktop Windows: non esiste una versione nativa completa per macOS e le procedure illustrate riguardano il prodotto desktop e, dove pertinente, Access Runtime.
Per ulteriori approfondimenti puoi consultare anche come automatizzare importazioni con VBA in Access, come documentare i flussi di import/export, come gestire importazioni e integrazioni e la raccolta completa delle Guide Access.
Che cosa significa “errore di conversione del tipo”
Microsoft definisce l’errore di tipo non corrispondente come una situazione in cui Access non riesce ad abbinare un valore al tipo di dati previsto. Un esempio semplice è una stringa di testo inserita dove Access si aspetta un numero. La stessa logica si applica alle importazioni: se il campo di destinazione è Numerico e una riga contiene “N/D”, “-”, “ABC” o una data testuale non convertibile, Access non può inserirla correttamente.
La documentazione Microsoft dedicata all’importazione da Excel spiega inoltre che Access analizza le prime righe della colonna per proporre un tipo di dati. Microsoft raccomanda di non mescolare tipi differenti nelle prime righe e di formattare in modo coerente la sorgente prima dell’importazione. Per Excel, la guida ufficiale è Import or link to data in an Excel workbook.
Per i file di testo, Microsoft descrive errori come Field Truncation, Type Conversion Failure, Key Violation, Validation Rule Failure, Null in Required Field e Unparsable Record. La documentazione è disponibile in Import or link to data in a text file.
Prima domanda: stai importando in una nuova tabella o accodando a una tabella esistente?
Questa distinzione è fondamentale. Quando importi in una nuova tabella, Access deve creare la struttura e dedurre i tipi dei campi. Quando invece accodi i dati a una tabella già esistente, i tipi sono già definiti e ogni valore deve essere compatibile con la struttura di destinazione.
Nel primo caso gli errori nascono spesso dall’inferenza del tipo: una colonna contiene principalmente numeri ma più avanti compaiono codici alfanumerici. Nel secondo caso la causa è spesso una struttura troppo restrittiva: campo Numero che riceve testo, campo Data/Ora che riceve stringhe non riconoscibili, campo obbligatorio che riceve Null, campo Testo breve troppo corto oppure chiave duplicata.
Come leggere la tabella degli errori di importazione
Quando un’importazione termina con problemi, Access può creare una tabella di log degli errori. Non cancellarla subito. È uno degli strumenti migliori per capire esattamente quali righe e campi hanno fallito. Microsoft indica che la tabella degli errori include informazioni sul tipo di errore, sul campo e sulla riga interessata.
Apri la tabella in visualizzazione Foglio dati e analizza gli errori per categoria. Se quasi tutti riguardano lo stesso campo, hai probabilmente individuato il punto critico. Se gli errori sono distribuiti su molti campi, la sorgente potrebbe essere strutturalmente incoerente oppure la tabella di destinazione potrebbe non essere allineata al file.
Errore Type Conversion Failure
“Type Conversion Failure” significa che Access ha trovato un valore incompatibile con il tipo assegnato al campo. Immagina una colonna CodiceCliente con questi valori: 1001, 1002, 1003, A1004. Se Access interpreta la colonna come Numero, la riga A1004 non può essere convertita e viene scartata o registrata nella tabella degli errori.
La soluzione corretta è capire la semantica del dato. Un codice cliente non è necessariamente un numero solo perché contiene cifre. Se non viene usato per calcoli e può contenere zeri iniziali o lettere, spesso il tipo corretto è Testo breve.
Per esempio, i codici “000123” e “123” sono diversi come identificatori ma diventano lo stesso valore se convertiti in numero. Importare come testo preserva lo zero iniziale.
Excel: perché le prime righe sono così importanti
Microsoft documenta che, durante l’importazione da Excel, Access esamina le prime righe della colonna per determinare il tipo di dati. Se queste righe contengono valori misti, la deduzione può essere errata. Per questo è importante che i dati siano coerenti già nella sorgente.
Prima dell’importazione, apri Excel e controlla ogni colonna critica. Se contiene codici alfanumerici, formatta la colonna come Testo. Se contiene date, assicurati che le celle contengano vere date e non stringhe con formati diversi. Se contiene numeri decimali, verifica il separatore decimale e il formato locale.
Non basta cambiare solo l’aspetto visivo della cella. Una cella può apparire come data ma contenere testo. Puoi verificarlo con funzioni Excel appropriate o confrontando l’allineamento e il valore nella barra della formula. Una pulizia preventiva riduce enormemente gli errori in Access.
Colonne con numeri e testo mescolati
Le colonne miste sono una delle cause principali degli errori di importazione. Esempi tipici sono numeri di volo come 871, AA90, 171; codici prodotto con prefissi; CAP internazionali; numeri di telefono; matricole; codici fiscali; identificativi di magazzino.
La regola pratica è semplice: se il dato non viene usato matematicamente e può contenere lettere, simboli o zeri iniziali, trattalo come testo. Questo evita conversioni indesiderate e mantiene l’identificatore esattamente come fornito dalla sorgente.
Date importate come numeri
Excel memorizza le date come numeri seriali. Se Access interpreta la colonna con il tipo sbagliato, puoi vedere numeri a cinque cifre al posto delle date. Microsoft segnala questo comportamento nella documentazione sull’importazione da Excel.
Controlla che la colonna sorgente contenga date reali e che le prime righe non siano valori numerici generici. Durante la procedura guidata seleziona Data/Ora come tipo di destinazione quando appropriato. Se stai accodando a una tabella esistente, verifica che il campo Access sia Data/Ora e che nessuna riga contenga testo come “da definire”, “nessuna data” o “N/A”.
Se devi rappresentare l’assenza di data, usa Null nella destinazione e non stringhe descrittive in un campo Data/Ora. La descrizione può essere mantenuta in un campo separato.
Testo importato in un campo Data/Ora
Stringhe come “31/12/2026” possono essere riconosciute come date in base alle impostazioni locali, ma formati ambigui come “01/02/2026” possono essere interpretati diversamente in contesti internazionali. Per importazioni professionali è preferibile usare formati non ambigui, per esempio ISO 2026-12-31, oppure trasformare il dato in una fase di staging.
Quando la sorgente contiene più formati nello stesso campo, non importare direttamente nella tabella finale. Importa prima tutto come testo in una tabella temporanea, quindi esegui una query di trasformazione che converta soltanto i valori validi.
Strategia professionale: usare una tabella di staging
Per dati sporchi o provenienti da sistemi esterni, la soluzione più robusta è una tabella di staging. La staging table riceve i dati quasi senza trasformazioni, spesso usando campi Testo breve o Testo lungo per i valori problematici. In un secondo momento le query Access validano, convertono e trasferiscono i record nella tabella definitiva.
Per esempio, puoi importare un campo ImportoTesto come testo e poi creare una query che identifichi i valori convertibili. In Access puoi usare funzioni come IsNumeric per un primo controllo, ricordando però che la validazione dipende dalla semantica del dato e dalle impostazioni locali.
Una query di diagnosi potrebbe essere SELECT ImportoTesto FROM StagingOrdini WHERE Not IsNumeric([ImportoTesto]) AND [ImportoTesto] Is Not Null;. In questo modo individui subito le righe che richiedono pulizia.
Conversione controllata dei numeri
Dopo aver validato il dato, puoi usare funzioni VBA/Access come CLng, CDbl, CCur o CDec dove appropriato. Evita di convertire valori senza prima controllarli. Una funzione di conversione applicata a una stringa non valida genera un errore.
Per campi monetari è generalmente meglio usare Currency in Access quando la semantica è economica e la precisione richiesta rientra nel tipo. Per misure scientifiche può essere più adatto Double. La scelta del tipo deve seguire il contenuto, non solo l’esigenza di “far passare” l’importazione.
Errore Field Truncation
Field Truncation indica che un valore è troppo grande per la proprietà Field Size del campo di destinazione. Nei campi Testo breve il limite massimo è 255 caratteri, ma il campo può essere configurato con una dimensione inferiore. Se la destinazione è lunga 20 caratteri e la sorgente contiene una descrizione di 80 caratteri, l’importazione fallisce o tronca il valore a seconda del contesto.
Apri la tabella in visualizzazione Struttura e controlla Dimensione campo. Se il dato è realmente più lungo, aumenta la dimensione o usa Testo lungo quando la semantica lo richiede. Non aumentare automaticamente tutti i campi a 255: una progettazione precisa aiuta prestazioni, qualità e validazione.
Per campi numerici, Field Size può indicare Byte, Integer, Long Integer, Single, Double e altri tipi. Un valore fuori dall’intervallo ammesso genera problemi. Se devi importare identificatori molto grandi, verifica se devono essere numerici o se sarebbe più corretto conservarli come testo.
Errore Key Violation
Una violazione di chiave si verifica quando stai importando un valore di chiave primaria o indice univoco già presente nella tabella. Non è propriamente un errore di tipo, ma compare spesso nello stesso log di importazione.
Prima di accodare dati, verifica la logica della chiave. Se il file contiene record già importati, devi decidere se ignorarli, aggiornarli oppure considerarli errori. Non rimuovere l’indice univoco solo per permettere l’importazione: rischieresti di creare duplicati che rendono incoerente il database.
Errore Null in Required Field
Se il campo di destinazione ha la proprietà Required impostata su Yes, Access non accetta Null. Excel e CSV possono contenere celle vuote, quindi l’importazione fallisce per quelle righe.
Decidi se il campo deve davvero essere obbligatorio. Se sì, correggi la sorgente o assegna un valore significativo durante la trasformazione. Non usare valori fittizi come 0 o “N/D” solo per aggirare il vincolo, a meno che abbiano un significato documentato nel modello dati.
Null e stringa vuota non sono la stessa cosa
In Access Null rappresenta l’assenza di un valore, mentre una stringa vuota "" è una stringa di lunghezza zero. Alcuni campi testo possono consentire uno, l’altro o entrambi in base alle proprietà Required e Allow Zero Length.
Durante l’importazione questa differenza può produrre risultati inattesi. Se il sistema sorgente usa stringhe vuote ma la tabella Access richiede un valore, devi normalizzare i dati prima dell’append.
Errore Validation Rule Failure
Una regola di convalida può rifiutare valori che sarebbero tecnicamente compatibili con il tipo del campo. Per esempio, un campo Numero con regola >=0 rifiuta -10 pur essendo perfettamente numerico. Un campo Data/Ora può richiedere una data non futura.
Apri la tabella in visualizzazione Struttura e controlla Validation Rule e Validation Text. Se la regola è corretta, devi correggere la sorgente. Se invece la regola è obsoleta, aggiornala con cautela e verifica l’impatto sull’intero database.
Errore Unparsable Record nei file di testo
Nei CSV e TXT una riga può non essere interpretabile se delimitatori e qualificatori di testo non sono coerenti. Un valore contenente una virgola deve essere correttamente racchiuso tra virgolette se la virgola è il delimitatore. Se il testo contiene virgolette, devono essere gestite secondo la sintassi del formato.
Microsoft indica esplicitamente che un qualificatore di testo interno deve essere raddoppiato quando necessario. Se il file è generato da un software esterno, controlla che produca CSV valido invece di correggere manualmente ogni file.
Separatore decimale e impostazioni locali
In Italia il separatore decimale è normalmente la virgola, mentre molti sistemi esportano numeri con il punto. Un CSV che usa la virgola anche come delimitatore può diventare ambiguo se non utilizza correttamente i qualificatori.
Prima di importare, identifica il formato reale. In un file delimitato da punto e virgola, per esempio, valori come 123,45 sono più facili da interpretare in ambiente italiano. Se il sistema sorgente produce 123.45, potresti dover normalizzare il dato o usare una specifica di importazione coerente.
Importare CSV e TXT con una specifica salvata
Quando importi regolarmente lo stesso tipo di file, non affidarti ogni volta all’inferenza automatica. Usa la procedura guidata di importazione testo e salva una specifica con delimitatore, qualificatore, tipo dei campi, nomi e altre impostazioni.
Una specifica salvata rende il processo ripetibile e può essere richiamata anche da VBA tramite DoCmd.TransferText. È particolarmente utile per file con codici alfanumerici che altrimenti Access potrebbe interpretare come numeri.
Esempio VBA con TransferText
Una procedura semplificata può essere:
DoCmd.TransferText acImportDelim, "SpecOrdini", "StagingOrdini", "C:\Import\ordini.csv", True
La specifica “SpecOrdini” definisce come leggere il file. La tabella StagingOrdini raccoglie i dati grezzi. Dopo l’importazione esegui query di validazione e soltanto successivamente accoda alla tabella finale.
Quando automatizzi il processo, aggiungi gestione errori e log. Non nascondere semplicemente gli errori con On Error Resume Next, perché potresti completare apparentemente la procedura perdendo righe senza accorgertene.
Importare Excel in una tabella di staging
Per Excel puoi utilizzare DoCmd.TransferSpreadsheet. Anche in questo caso la staging table offre maggiore controllo rispetto all’append diretto. Un esempio generale è DoCmd.TransferSpreadsheet acImport, acSpreadsheetTypeExcel12Xml, "StagingClienti", PercorsoFile, True.
Dopo l’importazione verifica il numero di record ricevuti, eventuali Null inattesi e tipi dei valori. Solo dopo esegui l’append verso la tabella definitiva.
Controllare i dati prima dell’append
Supponiamo che StagingClienti contenga DataNascitaTesto, CAP e Importo. Puoi creare query dedicate per individuare anomalie. Una query può cercare date non valide, una seconda CAP troppo lunghi e una terza importi non numerici.
Separare i controlli rende il processo più comprensibile rispetto a una singola query enorme. Inoltre puoi creare una tabella LogImportazioni che memorizza nome file, data, numero righe lette, righe valide, righe scartate e messaggi di errore.
Usare CDate con cautela
CDate converte un’espressione in Date, ma può interpretare valori in base alle impostazioni locali. Se il file proviene da paesi diversi, non affidarti a formati ambigui. Una data ISO come 2026-09-02 è più semplice da normalizzare in modo deterministico.
Per conversioni robuste puoi scomporre anno, mese e giorno e usare DateSerial. In questo modo non dipendi dall’interpretazione di “02/09/2026” come 2 settembre o 9 febbraio.
Campi Sì/No
Un campo Sì/No Access può ricevere valori booleani, ma le sorgenti usano convenzioni diverse: TRUE/FALSE, 1/0, Y/N, S/N, Yes/No. Non presumere che Access interpreti ogni variante.
In staging conserva il valore originale come testo e trasformalo con una query controllata. Per esempio, puoi mappare “S”, “SI”, “TRUE” e “1” a True, e “N”, “NO”, “FALSE” e “0” a False. I valori sconosciuti devono finire nel log invece di essere trasformati arbitrariamente.
Campi AutoNumber
Quando accodi dati a una tabella con chiave AutoNumber, normalmente non devi importare un valore nel campo AutoNumber: lascia che Access generi il nuovo ID. Se invece stai migrando un database e devi preservare identificativi esistenti, la procedura richiede maggiore attenzione per evitare duplicati e incoerenze.
Microsoft include “Null value in AutoNumber field” tra gli errori possibili durante alcune importazioni. Verifica la mappatura dei campi e non tentare di inserire Null espliciti nel campo AutoNumber se la struttura non lo consente.
Importazioni verso tabelle collegate SQL Server
Se la destinazione è una tabella collegata a SQL Server, il tipo Access deve essere compatibile anche con il tipo SQL Server. Un campo Access Long Integer può mappare a int, ma bigint richiede gestione appropriata. DateTime2, decimal, bit, uniqueidentifier e nvarchar hanno caratteristiche proprie.
Per grandi volumi, importare prima in Access e poi fare append tramite ODBC può essere meno efficiente di un processo ETL lato server. Se la mole cresce, valuta SQL Server Integration Services, Power Query, Azure Data Factory o altri strumenti appropriati. Access può rimanere il front-end senza essere necessariamente il motore di importazione per milioni di righe.
BigInt e Access moderno
Access Microsoft 365 e versioni moderne possono supportare il tipo Numero grande (BigInt) in scenari appropriati, ma l’uso può influire sulla compatibilità con versioni precedenti. Se il database deve essere aperto da client più vecchi, pianifica la migrazione e verifica la documentazione Microsoft relativa al tipo BigInt.
Non convertire chiavi server bigint in Double: perderesti precisione per valori sufficientemente grandi. Una chiave deve mantenere corrispondenza esatta.
Controllare la tabella dopo un’importazione “riuscita”
Microsoft raccomanda di verificare contenuto e struttura della tabella anche quando l’importazione viene segnalata come completata. Apri la tabella in Foglio dati e controlla valori campione, quindi aprila in Struttura e verifica i tipi dei campi.
Confronta anche il conteggio righe con la sorgente. Se Excel contiene 50.000 righe e Access ne ha 49.873, non considerare l’importazione riuscita finché non sai che cosa è successo alle 127 righe mancanti.
Query di controllo del conteggio
Puoi usare SELECT Count(*) AS NumeroRecord FROM StagingOrdini;. Se hai un identificativo univoco, controlla anche i duplicati con una query Totali o con una query SQL che raggruppa per chiave e filtra i conteggi maggiori di uno.
Questi controlli possono essere automatizzati e salvati in un log per ogni importazione.
Quando conviene correggere Excel e quando Access
Se la sorgente è sotto il tuo controllo e viene generata manualmente, conviene correggere la qualità direttamente in Excel: colonne uniformi, tipi coerenti, niente valori descrittivi in campi numerici o data, intestazioni stabili.
Se invece ricevi file da clienti, fornitori o sistemi esterni, non puoi fidarti della struttura. In questo caso Access deve essere progettato per tollerare l’ingresso sporco tramite staging e validazione, senza contaminare le tabelle operative.
Errori ricorrenti: creare un processo di qualità
Se ogni mese importi lo stesso file e correggi sempre gli stessi problemi a mano, il processo non è realmente automatizzato. Crea regole esplicite: quali colonne sono obbligatorie, quali tipi sono ammessi, quali valori vengono trasformati, quali righe vengono scartate e chi riceve il report degli errori.
Documenta inoltre il formato del file. Indica separatore, codifica, intestazioni, tipi logici, lunghezza massima e formato delle date. Questo riduce gli errori quando il sistema sorgente cambia.
Access Runtime e importazioni
In Access Runtime gli utenti possono eseguire procedure di importazione create dallo sviluppatore, ma non dispongono dello stesso ambiente completo per correggere struttura e codice. Per questo un’app Runtime deve avere messaggi chiari, log e gestione errori.
Se un file non è valido, la procedura dovrebbe spiegare quale colonna ha causato il problema e non limitarsi a mostrare un generico errore VBA. Lo sviluppatore corregge il sorgente ACCDB e ridistribuisce l’applicazione.
32 bit e 64 bit
Gli errori di conversione dati non dipendono normalmente dalla bitness di Access. Tuttavia importazioni automatizzate possono usare driver ODBC, provider OLE DB o componenti esterni che devono avere la stessa architettura dell’applicazione Office.
Se un’importazione funziona su Access 32 bit ma non su 64 bit, controlla i driver e i provider prima di modificare i tipi dei dati. Un errore di connessione non va confuso con un errore di conversione del contenuto.
Checklist pratica prima di importare
Prima dell’importazione verifica intestazioni, numero di colonne, delimitatore, codifica, formati data, separatore decimale, valori Null, zeri iniziali, lunghezza massima dei testi, chiavi duplicate e tipi misti. Se l’importazione è ricorrente, salva una specifica e usa staging.
Dopo l’importazione controlla il log errori, il conteggio dei record, valori campione, tipi della tabella, Null inattesi e duplicati. Solo dopo rendi i dati disponibili agli utenti.
FAQ sugli errori di tipo nelle importazioni Access
Perché Access importa alcuni valori come Null?
Spesso perché il valore non è compatibile con il tipo dedotto o con il campo di destinazione. Controlla la colonna sorgente e la tabella degli errori.
Perché un codice come 00123 perde gli zeri iniziali?
Perché è stato interpretato come numero. Se è un identificatore, importalo come testo.
Perché le date diventano numeri?
Excel memorizza le date come seriali numerici. Se Access interpreta male il tipo, può mostrare il numero sottostante. Uniforma la colonna e imposta Data/Ora.
Come gestire valori N/D in una colonna numerica?
Importa prima in staging come testo, sostituisci N/D con Null o una regola documentata e poi converti solo i valori validi.
Posso ignorare la tabella degli errori?
No. È la fonte principale per capire quali righe non sono state importate correttamente. Una procedura professionale la analizza sempre.
Meglio importare direttamente nella tabella finale?
Solo se la sorgente è molto affidabile e stabile. Per file esterni o dati sporchi è più sicuro usare una staging table.
TransferSpreadsheet evita gli errori di tipo?
No. Automatizza l’importazione ma non elimina i problemi di qualità. Devi comunque controllare struttura e valori.
Access 2024 si comporta diversamente da Microsoft 365?
Le funzioni di importazione principali sono simili, ma Microsoft 365 può ricevere aggiornamenti e nuove funzionalità prima delle versioni perpetue. Verifica sempre la documentazione corrente se usi tipi recenti o origini esterne particolari.
Conclusione
Gli errori di tipo durante le importazioni in Access non si risolvono semplicemente cambiando il campo finché l’operazione “passa”. La soluzione corretta consiste nel comprendere la semantica dei dati, allineare la sorgente alla struttura di destinazione e creare controlli ripetibili.
Per Excel, presta particolare attenzione alle prime righe e alle colonne con tipi misti. Per CSV e TXT, usa specifiche di importazione e controlla delimitatori, qualificatori e codifica. Per processi professionali utilizza una staging table, valida i valori, registra gli errori e accoda alle tabelle definitive solo i record conformi.
Con questo approccio l’importazione diventa un processo controllato e auditabile, invece di una serie di correzioni manuali. Per altri tutorial consulta la sezione Guide Microsoft Access.