Maschera Access: per passare valori da una maschera a una query in Access puoi usare un riferimento del tipo [Forms]![frmRicerca]![txtCliente] nel criterio della query. La maschera deve essere aperta quando la query viene eseguita e il controllo deve contenere un valore compatibile con il campo filtrato.
Quando conviene far leggere un valore dalla maschera
Questa tecnica è utile quando vuoi creare un’interfaccia di ricerca o filtro più amichevole rispetto al prompt standard di una query parametro. L’utente seleziona un cliente da una casella combinata, inserisce una data o sceglie uno stato e poi preme un pulsante. La query legge i controlli della maschera e restituisce soltanto i record coerenti con le scelte.
Il vantaggio è che puoi controllare i valori prima dell’esecuzione, usare combo con descrizioni leggibili e mantenere il criterio centralizzato nella query. È una soluzione tipica per maschere di ricerca, report filtrati, dashboard e procedure di esportazione.
Il riferimento Forms! spiegato bene
In Access il riferimento completo a un controllo di una maschera aperta usa normalmente la sintassi [Forms]![NomeMaschera]![NomeControllo]. Per esempio, se la maschera si chiama frmRicercaOrdini e la casella combinata cboCliente, il criterio può essere [Forms]![frmRicercaOrdini]![cboCliente].
Il nome importante è il Nome tecnico del controllo, non la didascalia dell’etichetta. Se sullo schermo leggi Cliente ma la combo si chiama Combo12, la query deve usare Combo12 finché non rinomini il controllo. Per manutenzione è meglio usare nomi descrittivi come cboCliente, txtDataDa e txtDataA.
Procedura passo passo con una casella combinata
Crea una maschera non associata chiamata frmRicercaOrdini. Aggiungi una casella combinata cboCliente. La sua origine riga può essere una query che restituisce IDCliente e RagioneSociale, con la prima colonna nascosta e la seconda visibile. In questo modo l’utente vede il nome ma il valore memorizzato dalla combo è l’ID numerico.
Apri la query qryOrdiniRicerca in Visualizzazione Struttura. Nel campo IDCliente inserisci nella riga Criteri [Forms]![frmRicercaOrdini]![cboCliente]. Salva la query. Apri frmRicercaOrdini, scegli un cliente e poi apri la query: dovresti vedere soltanto gli ordini con quell’IDCliente.
Perché usare l’ID e non il testo visualizzato
Le caselle combinate possono mostrare una descrizione e restituire una chiave. È preferibile filtrare sulla chiave primaria o esterna perché è stabile e univoca. Due clienti possono avere lo stesso nome, mentre IDCliente dovrebbe identificare un solo record. Inoltre i confronti numerici evitano problemi con apostrofi e spazi.
Se la colonna associata della combo è la prima colonna nascosta, il valore di cboCliente è l’ID. Non confondere il valore della combo con il testo che l’utente vede. Se hai bisogno di una colonna diversa puoi usare la proprietà Column, ma per i criteri è spesso meglio progettare la combo in modo che il valore associato sia già quello giusto.
Dichiarare i parametri nella query
Quando una query usa parametri, soprattutto date e numeri, è buona pratica dichiararne il tipo. In Visualizzazione Struttura apri la finestra Parametri della query e inserisci esattamente il riferimento [Forms]![frmRicercaOrdini]![txtDataDa], associandolo al tipo Data/Ora se contiene una data. Ripeti per gli altri parametri.
La dichiarazione evita che Access interpreti erroneamente un parametro come testo e riduce errori di conversione. È particolarmente importante nelle query a campi incrociati e in scenari in cui il motore deve conoscere il tipo prima di pianificare l’esecuzione.
Passare un intervallo di date
Per filtrare un intervallo usa due controlli, per esempio txtDataDa e txtDataA. Nel campo DataOrdine della query puoi usare un criterio equivalente a Between [Forms]![frmRicercaOrdini]![txtDataDa] And [Forms]![frmRicercaOrdini]![txtDataA].
Se il campo contiene anche l’ora e vuoi includere completamente il giorno finale, un confronto diretto con una data a mezzanotte può escludere i record successivi alle 00:00. Una tecnica più robusta è usare >= DataDa And < DateAdd('d',1,DataA), così includi tutte le ore della data finale senza dover impostare 23:59:59.
Controllare i valori prima di lanciare la query
Una maschera permette di fare validazione prima dell’esecuzione. Il pulsante Cerca può verificare che DataDa non sia successiva a DataA, che il cliente sia stato selezionato quando obbligatorio e che i campi numerici contengano valori validi. Se un requisito manca, mostra un messaggio e sposta il focus sul controllo.
Per esempio in VBA puoi usare If IsNull(Me.txtDataDa) Then MsgBox "Inserisci la data iniziale": Me.txtDataDa.SetFocus: Exit Sub. È preferibile a lasciare che la query generi prompt tecnici incomprensibili.
Eseguire la query dal pulsante
Se la query è di selezione puoi aprirla con DoCmd.OpenQuery, ma spesso l’utente non deve vedere il foglio dati. È più elegante usare la query come origine record di una maschera risultati o di un report. Il pulsante può aprire frmRisultati o rptOrdini, e la query leggerà i controlli della maschera di ricerca ancora aperta.
Se chiudi frmRicerca prima che la query venga valutata, i riferimenti Forms! non esistono più e Access può chiedere un parametro. Mantieni quindi aperta la maschera oppure passa i valori in un altro modo, per esempio tramite TempVars o parametri DAO.
Usare la query come origine di una maschera risultati
Imposta l’Origine record di frmRisultatiOrdini su qryOrdiniRicerca. Nel pulsante Cerca della maschera filtri esegui DoCmd.OpenForm "frmRisultatiOrdini". La query viene valutata all’apertura e legge i valori presenti nei controlli.
Se frmRisultatiOrdini è già aperta, dopo la modifica dei criteri puoi usare Requery. Per esempio Forms!frmRisultatiOrdini.Requery. Requery riesegue l’origine record; Refresh invece aggiorna i dati già presenti senza necessariamente rieseguire tutti i criteri nello stesso modo.
Usare la query come origine di un report
Lo stesso schema funziona per i report. Un report vendite può essere basato su qryVenditePeriodo, che legge txtDataDa e txtDataA da frmFiltroVendite. Il pulsante Anteprima apre il report mentre la maschera rimane aperta.
Per report distribuiti a molti utenti considera se sia più chiaro usare WhereCondition di OpenReport invece di parametri Forms!. WhereCondition rende il filtro esplicito nell’azione di apertura. I riferimenti Forms! sono ottimi quando la stessa query deve leggere più controlli e la maschera di filtro è parte stabile del flusso.
Criteri facoltativi: il problema del Null
Spesso un filtro deve essere facoltativo: se cboCliente è vuota vuoi mostrare tutti i clienti. Una formula comune è combinare il confronto con Is Null sul controllo, per esempio logicamente IDCliente=[Forms]![frmRicerca]![cboCliente] OR [Forms]![frmRicerca]![cboCliente] Is Null.
Questa tecnica funziona, ma molte condizioni facoltative possono produrre query complesse e meno efficienti. Se hai dieci filtri opzionali, può essere più leggibile costruire dinamicamente WhereCondition in VBA e aprire la maschera o il report con i soli criteri selezionati.
Maschera aperta: requisito fondamentale
Un riferimento Forms! è risolto soltanto se la maschera esiste nella raccolta Forms, quindi deve essere aperta. Se esegui la query direttamente dal Riquadro di spostamento mentre frmRicerca è chiusa, Access interpreta il riferimento come parametro non risolto e mostra una finestra di richiesta valore.
Questo comportamento è normale, non un bug. Per testare la query apri prima la maschera e valorizza i controlli. Se vuoi che la query possa essere eseguita anche da sola, valuta parametri espliciti gestiti via DAO invece di dipendenze dalla UI.
Errore Immettere un valore di parametro
Se la maschera è aperta ma Access chiede ancora un parametro, controlla l’ortografia del nome della maschera e del controllo. Verifica la proprietà Nome nel Foglio proprietà. Un refuso di una sola lettera è sufficiente a generare il prompt.
Controlla inoltre che il controllo non si trovi in una sottomaschera. In quel caso il percorso è diverso: devi passare attraverso il controllo sottomaschera della maschera principale e poi accedere alla proprietà Form. I riferimenti alle sottomaschere sono una delle cause più comuni di espressioni errate.
Riferimenti a una sottomaschera
Supponiamo che frmOrdini contenga un controllo sottomaschera subDettagli che ospita frmDettagliOrdine. Per leggere un controllo interno potresti dover usare un riferimento del tipo [Forms]![frmOrdini]![subDettagli].[Form]![txtProdotto]. Il nome subDettagli è il nome del controllo sottomaschera, che può essere diverso dal nome dell’oggetto maschera contenuto.
Questa distinzione è importante. Quando inserisci una sottomaschera, Access crea un controllo contenitore. Le espressioni devono navigare attraverso quel controllo, non saltare direttamente al nome dell’oggetto se il contesto non lo consente.
TempVars come alternativa
Access offre TempVars per memorizzare valori temporanei utilizzabili da macro, query e codice. Possono essere utili quando vuoi evitare che la query dipenda da una maschera aperta. Il pulsante imposta una TempVar e poi apre query o report; al termine puoi rimuoverla.
Non lasciare TempVars indefinite senza una convenzione di pulizia, perché un valore vecchio può influenzare esecuzioni successive. Usa nomi chiari e inizializza sempre i valori nel punto in cui inizia il flusso.
DAO QueryDef per parametri più controllati
Per procedure VBA avanzate puoi usare DAO QueryDef e assegnare i parametri esplicitamente. Questo approccio è utile quando vuoi eseguire una query senza dipendere dall’interfaccia, elaborare recordset o creare esportazioni automatizzate. Dichiarare e assegnare parametri rende il codice più testabile.
Non è necessario introdurre DAO per una semplice maschera di ricerca. Usa lo strumento più semplice che soddisfa il requisito. Forms! è immediato, WhereCondition è ottimo per l’apertura filtrata, TempVars separa un po’ l’interfaccia dalla query, QueryDef offre controllo programmatico.
Tipi dati compatibili
Il controllo deve fornire un valore coerente con il campo. Se IDCliente è Numero/Intero lungo, la combo deve restituire un numero. Se DataOrdine è Data/Ora, il parametro deve essere dichiarato come data. Se il campo è Testo breve, il confronto deve trattare il valore come testo.
Molti errori apparentemente casuali derivano da tipi incompatibili. Non risolverli convertendo tutto in testo: mantieni tipi coerenti dalla tabella alla query e dalla query alla maschera. Questo migliora anche ordinamento, indicizzazione e prestazioni.
Prestazioni
Un filtro su un campo indicizzato, come una chiave esterna, è normalmente efficiente. Se la query usa funzioni sul campo in Criteri, Access potrebbe non sfruttare l’indice allo stesso modo. Per intervalli di date, preferisci confronti sul valore originale quando possibile invece di trasformare ogni riga con Format.
Con SQL Server o Azure SQL, valuta quante righe vengono trasferite e se i criteri possono essere eseguiti lato server. Una maschera Access può essere un ottimo front-end, ma una query progettata come se tutti i dati fossero locali può diventare lenta su rete.
Microsoft 365, Access 2024, Runtime e Windows
I riferimenti a Forms, le query parametriche, macro e VBA descritti qui appartengono ad Access desktop e sono applicabili alle versioni correnti per Windows, incluse Microsoft 365 e Access 2024. Access Runtime può eseguire maschere, query e codice già predisposti, ma non è l’ambiente di progettazione.
Non esiste una versione nativa desktop di Access per macOS equivalente a quella Windows e le vecchie Access Web Apps non devono essere presentate come alternativa corrente alle maschere desktop. Se serve un front-end Web, occorre progettare una soluzione diversa.
32 e 64 bit non cambiano la sintassi dei riferimenti Forms!. Le differenze emergono con API, controlli ActiveX o librerie esterne. Per query, controlli e VBA standard il comportamento è sostanzialmente coerente.
Convalida e sicurezza
Non affidarti alla sola maschera per regole che devono valere sempre. Se un campo è obbligatorio o deve rispettare un vincolo fondamentale, considera regole a livello di tabella e integrità referenziale. La maschera può offrire messaggi più amichevoli, ma non deve essere l’unica barriera contro dati incoerenti quando esistono più percorsi di modifica.
Macro e VBA possono essere disabilitati in file non attendibili. In ambiente aziendale usa posizioni attendibili gestite e non chiedere agli utenti di abilitare indiscriminatamente contenuti. Conserva una copia ACCDB sorgente anche se distribuisci ACCDE.
Test da eseguire
Prova la query con tutti i controlli valorizzati, con un filtro vuoto se deve essere facoltativo, con date uguali, con intervallo inverso e con un cliente che non possiede record. Verifica che il risultato sia vuoto quando corretto e che non appaiano prompt di parametro inattesi.
Se la query alimenta una maschera modificabile, verifica che i record restino aggiornabili. Se alimenta un report, controlla anteprima e stampa. Se viene usata in Runtime, esegui il test anche in Runtime per assicurarti che i messaggi all’utente siano sufficienti.
Esempio completo di maschera filtro
Una buona frmFiltroVendite può contenere cboCliente, txtDataDa, txtDataA, cboAgente e cmdVisualizza. Il pulsante controlla l’intervallo, poi apre frmVenditeRisultati o rptVendite. La query usa gli ID per cliente e agente, parametri data dichiarati e criteri facoltativi solo dove hanno senso.
Aggiungi un pulsante Pulisci che azzera i controlli e un’etichetta che spiega i filtri attivi. Se gli utenti eseguono spesso la stessa ricerca, valuta valori predefiniti come il primo giorno del mese corrente e Date() come data finale.
Manutenzione
Prima di rinominare una maschera o un controllo usato dalle query, cerca i riferimenti nel database. Il riquadro Dipendenze oggetti aiuta a individuare relazioni tra tabelle, query, maschere e report, ma i riferimenti nel codice meritano una ricerca specifica. Un cambio di nome non documentato è una causa classica dei prompt parametro.
Usa una convenzione di nomi e documenta le query che dipendono dall’interfaccia. Una breve nota come “qryVenditeFiltro richiede frmFiltroVendite aperta” evita ore di diagnosi future.
Link interni
Leggi anche come creare una query parametro, come far chiedere un valore all’utente, come creare una maschera di ricerca record e come aprire una maschera filtrata. Tutte le guide sono nella categoria Guide Access.
Fonti Microsoft
Per le query come origine dati e l’aggiornabilità consulta Microsoft Support. Per apertura e filtri consulta Microsoft Learn: DoCmd.OpenForm e Microsoft Support sui filtri.
FAQ
La maschera deve essere aperta? Sì, se la query usa un riferimento Forms! a quella maschera.
Posso passare due date? Sì, usa due controlli e dichiara i parametri come Data/Ora.
Perché compare Immettere un valore di parametro? Di solito la maschera è chiusa oppure il nome di maschera, controllo o campo è errato.
Posso usare una combo? Sì, ed è spesso la scelta migliore perché può mostrare una descrizione ma restituire un ID.
Funziona in Runtime? Sì, purché tutto sia già progettato e il flusso non richieda strumenti di progettazione.
Conclusione
Passare valori da una maschera a una query in Access permette di creare filtri guidati e interfacce molto più pratiche dei prompt standard. Usa riferimenti Forms! per scenari semplici e stabili, parametri tipizzati per date e numeri, WhereCondition quando il criterio serve soprattutto all’apertura di una maschera o report e QueryDef quando il processo deve essere controllato da VBA.
La qualità dipende soprattutto da nomi chiari, tipi dati coerenti, gestione dei Null e test del caso in cui la maschera non sia aperta. Con queste precauzioni la query diventa una parte affidabile dell’interfaccia invece di una fonte di prompt e conversioni inattese.