Evidentemente il predicato SQL che hai usato non prevede che in caso di assenza di un Parametro il Filtro non consideri il parametro stesso... purtroppo non vedendo il predicato non posso darti altre indicazioni.
Allego questo tutorial
Capita di dover scrivere Queries che comprendano PARAMETRI riferiti a Controlli presenti in Maschere, la situazione più evidente è l'uso di COMBOBOX per la selezione di Criteri.
codice:
SELECT * FROM T1
WHERE [CampoX]=Forms!NomeForm!NomeCombo
Nel caso in cui la Combo abbia valori NULLI la query restituirebbe tutti i record corrispondenti, probabilmente ZERO, ma spesso si vorrebbe venissero mostrati tutti come se il Criterio non fosse inserito.
Per ovviare a questo comportamento, che non è un'errore, si può scrivere diversamente il predicato SQL
codice:
SELECT *
FROM T1
WHERE [CampoX]=Forms!NomeForm!NomeCombo OR Forms!NomeForm!NomeCombo IS NUll;
Questo predicato è valido per tutti i Tipi di Campo(Date,Numeri,Testo...) ed evita il Casting dei dati che avverrebbe con l'uso del LIKE ...."*"
Chiaramente applicabile anche con HAVING.
La spiegazione tecnica del predicato si ottiene sostituendo ai 2 Criteri messi in OR LOGICO il valore logico risultante:
codice:
SELECT *
FROM T1
WHERE FALSE OR TRUE;
La logica Booleana dice che [FALSE OR TRUE] = TRUE quindi è come definire la selezione di TUTTI i records senza un criterio.
Tuttavia vorrei far notare che l'ottimizzazione delle Queries è una cosa seria che purtroppo nessuno degli utenti di Access fa, e che richiede la valutazione dei piani di esecuzione delle Queries per capire quale predicato venga eseguito con minor impatto ad ogni passata.
Ci sono predicati SQL che obbligano JET ad effettuare N Volte esecuzioni parziali del predicato ed a valutarne il risultato in un ulteriore passaggio, e questo accade per ogni RECORD.
Il risultato è avere Queries LENTE e non si capisce il perchè, e spesso si incolpa, per incompetenza, Access(JET) come motore di DB non performante...!
@Alex