Quando Microsoft Access mostra la finestra Inserire valore parametro senza che tu abbia creato intenzionalmente una query parametrica, nella maggior parte dei casi sta segnalando che non riesce a riconoscere un nome usato in una query, una maschera, un report, un controllo calcolato o un’espressione. Access interpreta quel nome sconosciuto come un parametro e chiede all’utente di fornirne il valore.
In questa guida vediamo come correggere parametri non riconosciuti in Access con un metodo sistematico, valido per Access per Microsoft 365 e Access 2024 su Windows. Analizzeremo refusi nei campi, riferimenti a maschere e report, alias, query dipendenti, crosstab, DAO QueryDef, VBA e tabelle collegate.
Per approfondire consulta anche come risolvere errori VBA in Access, come risolvere errori di compilazione VBA, come riparare relazioni e collegamenti e le Guide Microsoft Access.
Che cos’è un parametro in Access
Un parametro è un valore che una query riceve al momento dell’esecuzione. Una query può chiedere intenzionalmente una data iniziale, una data finale o un codice cliente. Il problema nasce quando Access interpreta come parametro qualcosa che avrebbe dovuto essere un campo, un controllo o una funzione. Per esempio, se il campo corretto è Citta ma nella query scrivi Cittta, il motore non trova il nome e può chiedere di inserirne il valore.
Leggere il testo della finestra
Quando compare Inserire valore parametro, non digitare subito un valore. Annota esattamente il nome mostrato. Se appare Cittta, Forms!frmOrdini!txtCliente oppure TotaleNetto, quel testo è l’indizio principale. Inserire un valore casuale può far continuare la query, ma può produrre risultati vuoti o errati. È preferibile annullare e individuare dove viene usato l’identificatore non risolto.
Controllare i nomi dei campi
Il refuso è la causa più frequente. Apri la query in visualizzazione Struttura e verifica i campi presenti nelle tabelle sorgenti. In visualizzazione SQL controlla SELECT, WHERE, JOIN, ORDER BY, GROUP BY e HAVING. Se una query ordina per RagioneSociele ma il campo si chiama RagioneSociale, Access può interpretare il nome errato come parametro. Correggere il riferimento risolve il problema alla radice.
Campi rinominati
Se un campo è stato rinominato dopo la creazione delle query, gli oggetti dipendenti possono continuare a usare il vecchio nome. Controlla query, Origine record delle maschere, Origine controllo delle caselle di testo, Origine riga delle combo, filtri, ordinamenti, report e codice VBA. Nei database grandi conviene modificare lo schema prima in una copia di sviluppo e testare tutte le dipendenze prima del rilascio.
Riferimenti alle maschere
Una query può leggere un valore da una maschera con un riferimento come [Forms]![frmOrdini]![txtCliente]. Se il controllo viene rinominato oppure la maschera è chiusa, Access non riesce a recuperare il valore. Controlla la proprietà Nome del controllo, non l’etichetta visualizzata. Una casella combinata può mostrare Cliente ma chiamarsi cboIDCliente: è il nome tecnico che deve coincidere con il riferimento.
Maschera chiusa
Anche un riferimento perfettamente scritto funziona soltanto se la maschera è aperta nel momento in cui la query viene eseguita. Una query progettata per essere lanciata da frmOrdini può quindi chiedere un parametro se viene aperta direttamente dal riquadro di spostamento. Se deve funzionare anche indipendentemente dalla maschera, valuta parametri dichiarati, TempVars oppure una QueryDef gestita da VBA.
Sottomaschere
Le sottomaschere aggiungono un livello perché il controllo sottomaschera può avere un nome diverso dall’oggetto maschera caricato al suo interno. Un riferimento tipico usa la proprietà Form del controllo. Apri la maschera principale in visualizzazione Struttura e controlla il nome effettivo del controllo sottomaschera. Non assumere che coincida con il nome della maschera secondaria.
Riferimenti ai report
Lo stesso principio vale per i report. Se una query usa un controllo di rptVendite, il report deve essere aperto nel momento corretto. Se il report stesso mostra una richiesta parametro, controlla Origine record, Origine controllo delle caselle di testo, Filtra, Ordina per e le impostazioni di raggruppamento. Un campo eliminato dal record source può restare referenziato in un controllo invisibile o in un ordinamento.
Alias calcolati
Una query può creare un alias come Totale: [Quantita]*[Prezzo]. In alcuni contesti non è possibile riutilizzare immediatamente Totale nello stesso livello della query come se fosse un campo fisico. Se Access non risolve l’alias, crea una query intermedia: la prima calcola Totale, la seconda usa quel campo per filtri, raggruppamenti o ulteriori calcoli. La struttura risulta anche più leggibile.
Campi calcolati
Un’espressione come ImportoNetto: Nz([Importo],0)-Nz([Sconto],0) funziona soltanto se Importo e Sconto sono disponibili nel recordset. Se uno dei due campi è stato rinominato o rimosso, Access può chiedere un parametro. Controlla quindi non solo la sintassi della formula, ma anche le sorgenti dati effettive dell’oggetto in cui viene eseguita.
Dichiarare i parametri intenzionali
Quando un parametro è voluto, dichiararne nome e tipo rende la query più robusta. In SQL Access puoi usare PARAMETERS [pDataInizio] DateTime, [pDataFine] DateTime; prima della SELECT. Il motore sa così che quei nomi non sono campi mancanti e conosce il tipo atteso. È particolarmente utile per date, numeri, query a campi incrociati e procedure eseguite da codice.
Perché il tipo è importante
Una data trattata come testo può essere interpretata in modo ambiguo; lo stesso vale per confronti tra numeri e stringhe. Dichiarare un parametro DateTime, Long o Text riduce conversioni implicite e comportamenti dipendenti dalle impostazioni locali. Nelle applicazioni distribuite su più PC questo aiuta a ottenere risultati coerenti e rende più semplice diagnosticare input non validi.
Query a campi incrociati
Le crosstab richiedono particolare attenzione perché Access deve determinare intestazioni e tipi prima di completare l’esecuzione. Se una query a campi incrociati legge l’anno da una maschera, dichiara esplicitamente quel riferimento nella finestra Parametri della query con il tipo corretto. In caso contrario una query apparentemente valida può mostrare richieste inattese o non essere accettata come origine di un report.
DAO QueryDef
Quando una query viene eseguita da VBA, evita di dipendere da finestre interattive. Crea una QueryDef, assegna i valori alla collezione Parameters e poi apri il recordset o esegui la query. In questo modo il codice controlla l’intero flusso. Se manca un parametro, puoi intercettare l’errore e mostrare un messaggio comprensibile invece di lasciare all’utente una finestra generica.
Errore Too few parameters
In DAO un nome non riconosciuto può produrre l’errore “Too few parameters. Expected 1” anziché la finestra Inserire valore parametro. Il principio è lo stesso: il motore ha interpretato un identificatore come parametro non valorizzato. Se la query non dovrebbe avere parametri, cerca un refuso. Se invece i parametri sono intenzionali, assegnali esplicitamente prima dell’esecuzione.
Ispezionare la collezione Parameters
Una QueryDef espone la collezione Parameters. Se una query che ritieni priva di parametri presenta uno o più elementi, questo è un indizio molto utile: uno dei nomi non è stato risolto come campo o funzione. Nei database complessi questa tecnica consente di trasformare un errore generico in un elenco concreto di identificatori da verificare.
Campi con spazi
Access consente nomi come Data ordine, ma nelle espressioni devono essere delimitati correttamente, per esempio [Data ordine]. Nei nuovi progetti sono preferibili nomi semplici come DataOrdine, perché riducono ambiguità e rendono SQL e VBA più leggibili. Nei database esistenti evita però rinominazioni massive senza prima analizzare tutte le dipendenze.
Parole riservate
Nomi come Date, Name, Value o Year possono coincidere con funzioni, proprietà o parole riservate. Le parentesi quadre possono risolvere alcune ambiguità, ma una convenzione più specifica è più robusta: DataOrdine, NomeCliente, ValoreTotale. Se il database usa già nomi problematici, documentali e qualifica i riferimenti in modo coerente invece di modificarli direttamente in produzione.
Funzioni VBA non risolte
Una query può richiamare una funzione pubblica personalizzata. Se il progetto VBA non compila o contiene un riferimento MISSING, Access può non riuscire a risolvere la funzione. Apri l’editor VBA, usa Debug > Compila e controlla Strumenti > Riferimenti. Risolvi prima gli errori di compilazione e le librerie mancanti, poi torna alla query. Un problema VBA può manifestarsi come errore apparentemente legato ai parametri.
Ambito delle funzioni
Una funzione richiamata globalmente da una query deve essere accessibile nel contesto corretto. Se viene resa Private o spostata nel modulo di una maschera, la query può non trovarla. Per funzioni generali usate dalle query è normalmente preferibile un modulo standard con una dichiarazione Public, mantenendo nomi univoci e compilando il progetto dopo ogni modifica.
Tabelle collegate
Se una tabella collegata a SQL Server, Excel o un altro back-end ha cambiato struttura, le query Access possono continuare a usare vecchi nomi di colonna. Apri Gestione tabelle collegate, aggiorna l’origine e verifica lo schema che Access vede. Un collegamento può risultare raggiungibile ma non essere compatibile con le query esistenti se una colonna è stata rinominata o eliminata.
Modifiche lato SQL Server
Rinominare una colonna sul server non aggiorna automaticamente ogni query, maschera e report del front-end Access. Le modifiche di schema devono essere coordinate con il rilascio di una nuova versione del front-end. Mantieni un changelog e testa le query collegate in un ambiente di prova. Per sistemi stabili può essere utile esporre viste con nomi di colonna coerenti anche quando lo schema interno evolve.
TempVars
Le TempVars possono sostituire alcuni riferimenti diretti a Forms!, rendendo una query meno dipendente dal fatto che una determinata maschera sia aperta. Devono però essere inizializzate e aggiornate correttamente. Una TempVar mancante genera problemi, mentre una TempVar con un vecchio valore può essere ancora più insidiosa perché la query funziona ma restituisce dati non pertinenti.
Controlli con lo stesso nome del campo
Nelle maschere associate è comune che una casella di testo abbia lo stesso nome del campo. In espressioni e VBA complessi può essere utile distinguere chiaramente controlli e campi, per esempio usando txtFiltroCliente per un controllo non associato e qualificando con Me! i riferimenti nel modulo della maschera. Una convenzione coerente riduce gli errori di risoluzione dei nomi.
Query di aggiornamento ed eliminazione
Una richiesta parametro inattesa in una query UPDATE, DELETE o APPEND è particolarmente pericolosa. Non inserire valori casuali e non confermare l’operazione. Trasforma temporaneamente la logica in una SELECT equivalente e verifica quali record sarebbero interessati. Crea un backup prima delle query di comando e dichiara esplicitamente i parametri intenzionali con il tipo corretto.
Access Runtime
In Access Runtime l’utente dispone di meno strumenti di sviluppo e diagnosi. Una richiesta parametro inattesa può quindi interrompere completamente il flusso. Prima della distribuzione prova maschere, report, importazioni e procedure automatiche in modalità Runtime. Le routine VBA dovrebbero valorizzare i parametri e intercettare gli errori, evitando di affidare all’utente finale la diagnosi di un nome non risolto.
32 bit e 64 bit
Il problema dei parametri non riconosciuti non dipende normalmente dalla bitness. Tuttavia una funzione VBA può diventare indisponibile dopo il passaggio da Office 32 a 64 bit se usa dichiarazioni API, ActiveX o librerie incompatibili. Se il problema compare dopo una migrazione di Office, compila il progetto e controlla riferimenti, driver e componenti prima di modificare query che prima funzionavano.
Metodo di diagnosi passo passo
Annota il parametro richiesto. Esegui la query da sola. Controlla i nomi dei campi. Esegui una alla volta le query sorgenti. Verifica riferimenti Forms! e Reports!. Controlla che gli oggetti siano aperti. Esamina alias e campi calcolati. Controlla Origine riga e Origine controllo. Compila VBA. Infine aggiorna le tabelle collegate. Dopo ogni correzione ripeti il test, così sai quale modifica ha risolto il problema.
Diagnosticare una catena di query
Se QueryC usa QueryB e QueryB usa QueryA, esegui prima QueryA. Se funziona, passa a QueryB e poi a QueryC. Il primo livello che mostra la richiesta parametro contiene normalmente il riferimento problematico. Questo metodo è molto più efficace che modificare direttamente la query finale, soprattutto quando una query di report dipende da numerosi livelli intermedi.
Cercare il nome in un database grande
Quando la finestra mostra un identificatore preciso, cerca quel testo nelle query SQL, nelle proprietà di maschere e report e nei moduli. Parti dagli oggetti aperti immediatamente prima dell’errore. Documentare dipendenze e convenzioni di denominazione riduce drasticamente i tempi di diagnosi. Nei progetti importanti mantieni anche una copia versionata del front-end prima di modifiche strutturali.
Parametri di data e impostazioni locali
Le date meritano attenzione particolare. Un valore digitato come testo può essere interpretato diversamente in base alle impostazioni locali di Windows. Dichiarare il parametro come DateTime e assegnargli un vero valore Date da VBA è più robusto che costruire stringhe SQL concatenando testo. Lo stesso principio vale per separatori decimali e valori numerici provenienti da controlli formattati.
Valori Null
Un controllo vuoto può restituire Null. Questo non equivale necessariamente a un parametro non riconosciuto, ma può complicare la diagnosi perché una query corretta restituisce zero righe. Prima di eseguire la query valida gli input richiesti e decidi esplicitamente come trattare Null. Per filtri opzionali puoi progettare condizioni specifiche invece di lasciare che il comportamento emerga accidentalmente.
Query salvate contro SQL costruito in VBA
Le query salvate con parametri dichiarati sono spesso più facili da testare e mantenere rispetto a lunghe stringhe SQL concatenate in VBA. Il codice assegna valori tipizzati senza dover gestire manualmente virgolette, formati data e separatori. SQL dinamico resta utile quando la struttura della query cambia realmente, ma non dovrebbe essere usato solo per evitare una corretta gestione dei parametri.
Controllare Origine riga delle combo
Una maschera può aprirsi mostrando una richiesta parametro anche se la propria Origine record è corretta. La causa può essere una casella combinata la cui Origine riga usa un campo rimosso. Controlla combo e list box una per una, comprese quelle nascoste. Se l’errore appare durante il caricamento della maschera, anche un controllo non visibile può essere responsabile.
Controllare ordinamenti e raggruppamenti nei report
Nei report un campo eliminato può rimanere configurato nella sezione Raggruppa e ordina. Il report chiede allora un parametro anche se nessuna casella di testo mostra quel nome. Apri il report in Struttura e verifica ogni livello di raggruppamento, ordinamento, filtro ed espressione. Controlla anche gli eventi VBA che impostano filtri dinamici durante Open o Load.
Prevenzione con convenzioni di denominazione
Usa nomi coerenti per tabelle, query, maschere, report e controlli. Puoi adottare prefissi come qry, frm, rpt, txt e cbo oppure una convenzione diversa: l’importante è applicarla con costanza. Evita nomi troppo generici e parole riservate. Una buona denominazione permette di capire immediatamente se un riferimento indica un campo, un controllo o un oggetto.
Prevenzione nelle modifiche di schema
Prima di rinominare o eliminare un campo crea un inventario delle dipendenze. Applica la modifica in sviluppo, aggiorna query, maschere, report e codice, compila VBA e prova i flussi principali. Solo dopo distribuisci il nuovo front-end e aggiorna il back-end. Una modifica apparentemente minima può interessare decine di oggetti e produrre richieste parametro settimane dopo.
Test di regressione
Dopo una correzione non limitarti ad aprire la query interessata. Prova le maschere che la usano, i report, le esportazioni, le procedure VBA e gli scenari Runtime. Se il parametro dipende da una maschera, prova sia con la maschera aperta sia nel flusso normale dell’applicazione. Registra i casi testati per poterli ripetere dopo futuri aggiornamenti.
FAQ sui parametri non riconosciuti
Perché Access chiede un parametro che non ho creato?
Perché non riesce a risolvere un nome e lo interpreta come parametro. Spesso si tratta di un campo scritto male, rinominato o non disponibile nel contesto.
Perché la query funziona solo con una maschera aperta?
Probabilmente usa un riferimento Forms! a un controllo della maschera. Con la maschera chiusa quel valore non esiste.
Too few parameters è collegato allo stesso problema?
Sì, frequentemente. In DAO indica che uno o più identificatori sono stati trattati come parametri non valorizzati.
Conviene dichiarare i parametri?
Sì, soprattutto per date, numeri, crosstab e query eseguite da VBA. Nome e tipo espliciti rendono il comportamento più prevedibile.
Una tabella collegata può causare il problema?
Sì. Se lo schema esterno cambia, il front-end può continuare a usare nomi di colonna non più presenti.
Posso inserire un valore nella finestra e continuare?
Solo se il parametro è intenzionale. Se la richiesta è inattesa, annulla e correggi la causa per evitare risultati errati.
Runtime cambia il comportamento?
Il motore resta lo stesso, ma Runtime offre meno strumenti di diagnosi. Per questo è importante eliminare le richieste inattese prima della distribuzione.
Approfondimento: usare una maschera per raccogliere parametri
Microsoft documenta anche un approccio più professionale rispetto alla semplice finestra Inserire valore parametro: creare una maschera dedicata alla raccolta dei criteri e fare in modo che query e report leggano i valori dai controlli della maschera. È particolarmente utile quando l’utente deve scegliere più condizioni, per esempio intervallo di date, cliente, stato dell’ordine e reparto. Una maschera permette inoltre di usare combo box, calendari, valori predefiniti e controlli di validazione prima di eseguire la query.
Per rendere il flusso robusto, verifica che i controlli necessari non siano Null, mostra messaggi chiari se manca un criterio obbligatorio e apri report o maschere soltanto dopo la validazione. Se il criterio è opzionale, progetta esplicitamente la query per ignorarlo quando è vuoto invece di affidarti a conversioni implicite. In questo modo eviti richieste parametro inattese e rendi l’interfaccia molto più comprensibile per chi utilizza il database senza conoscerne la struttura.
Parametri e manutenzione delle query nel tempo
Nei database che evolvono è utile trattare i parametri come parte dell’interfaccia applicativa. Documenta nome, tipo, origine del valore e oggetti che li utilizzano. Se una query usa pDataInizio e pDataFine, mantieni gli stessi nomi nelle procedure VBA e nei controlli di supporto oppure crea una convenzione chiara. Cambiare un nome senza aggiornare tutte le dipendenze può trasformare un parametro valido in un parametro non riconosciuto.
Prima di distribuire una nuova versione del front-end esegui un test di regressione delle query parametrizzate più importanti. Prova valori validi, Null, date limite, numeri fuori intervallo e maschere chiuse. Per i report verifica anche l’apertura diretta e l’apertura dal flusso normale. Questo controllo è particolarmente importante con Access Runtime, dove l’utente finale dispone di meno strumenti per capire perché una query sta chiedendo un valore imprevisto.
Controllo finale del parametro
Prima di chiudere la diagnosi esegui la query nel contesto reale in cui verrà usata, non soltanto dalla visualizzazione Struttura. Un riferimento a una maschera può risultare corretto durante un test manuale e fallire se il flusso normale apre gli oggetti in un ordine diverso. Verifica quindi apertura della maschera, valorizzazione dei controlli, esecuzione della query e chiusura dell’oggetto. Se il database è distribuito tramite Runtime, ripeti almeno questo test anche nell’ambiente Runtime.
Conclusione
Correggere parametri non riconosciuti in Access significa capire quale identificatore il motore non riesce a risolvere. Il testo mostrato nella finestra è il punto di partenza: verifica refusi, campi rinominati, riferimenti a maschere e report, alias, query dipendenti, funzioni VBA e tabelle collegate.
Quando il parametro è intenzionale, dichiarane il tipo e valorizzalo esplicitamente nelle procedure automatiche. Quando invece è inatteso, non mascherare il problema inserendo valori manuali. Una diagnosi ordinata, accompagnata da convenzioni di denominazione, test di regressione e modifiche di schema controllate, rende il database più affidabile e riduce drasticamente il rischio che lo stesso errore ricompaia.
Per altri tutorial consulta le Guide Microsoft Access di Guide-Pratiche.it.