Newsgroup: it.comp.appl.access
Titolo: Non funziona il filtro

Ho un problema su un filtro in base a maschera che non mi
trova nessun record.
Nella maschera c'e' una combo Combo1, che tanto per
intenderci si appoggia su una tabella di regioni, e un'altra
combo Combo2 che si appoggia su una tabella di province, o
meglio una query, infatti se clicco Combo2 voglio che mi
compaiano solo le province della regione visualizzata in
Combo1, e cosi' Combo2 l'ho basata su una query col
criterio:
IdCombo1=forms!maschera!Idcombo1
cioe' l'id di regione IdCombo1 nella tabella province deve
essere quello della regione che appare nella combo Combo1.
Cio' funziona bene finche' si tratta di modificare o
aggiungere record, invece non funziona quando assegno i
valori dei controlli per il filtro, nel senso che se assegno
Combo1 e Combo2 non mi trova nessun record.
Invece se come origine riga di Combo2 provo a mettere
direttamente la tabella province, senza la restrizione su
IdCombo1, il filtro mi funziona. Naturalmente questa non
puo' essere la soluzione, perche' io voglio che quando la
regione e' la Lombardia mi compaiano in Combo2 solo le
province della Lombardia.
qu mi puo' aiutare?
il barbi

 ha scritto nel messaggio
news:I551b.117943$cl3.3...@news2.tin.it...

Come assegni il filtro?
Antonio

 ha scritto nel messaggio
news:i_61b.255680$Ny5.7...@twister2.libero.it...

be' nel solito modo, sto parlando di manualita' a livello
utente, clicco su "Filtro in base a maschera", assegno la
regione in Combo1, clicco su Combo2 per assegnare la
provincia, mi compaiono solo le province della regione
scelta e ne scelgo una, poi clicco sull'imbuto...
il barbi

 ha scritto nel messaggio
news:Or81b.119012$cl3.3...@news2.tin.it...

Con queste informazioni non so che dire.
Aggiungo solo che io preferisco utilizzare controlli non associati per
filtrare le maschere, quindi con recordsource della maschera avente criteri
tipo like nz([forms]![miaform]![miocontrollo];"*")
Antonio


ma tu come faresti nel mio caso? Non mi sembra un esempio di
database tanto strano...
il barbi

 ha scritto nel messaggio
news:uep1b.27627$zN5.8...@news1.tin.it...

dunque, dopo molti tentativi ho questa situazione:
sull'evento Enter di Combo2 faccio una requery su Combo2 per
aggiornare la lista dei valori possibili delle province in
base al valore di Combo1 (regione), e cosi' e' sistemata la
gestione della modifica e aggiunta di record
solo che quando entro in "Filtro in base a maschera"
l'evento Enter di Combo2 non scatta... e cosi' pure ogni
altro evento di Combo2... e quindi la lista dei valori per
Combo2 e' quella del record corrente, e quindi incoerente
col valore scelto per Combo1 nel filtro
ho controllato nel menu' "Filtro avanzato" e mi visualizza
un grafico di query con la tabella principale e connesse due
tabelle "Lookup_Combo1" e "Lookup_Combo2"
quindi mi sa che collo strumento "Filtro in base a maschera"
non ce la posso fare
il barbi

 non ce la posso fare
Senti, io ti ho già detto di usare controlli non associati per filtrare.
Io, il filtro in base a maschera non lo uso.
Poi fai tu...
Antonio


ma certo mi vanno benissimo i tuoi suggerimenti, solo dal pv
utente era comodissimo poter usare l' icona standard "Filtro
in base a maschera" dalla maschera principale, mentre invece
come dici tu mi pare che per entrare in ricerca, assegnando
i campi voluti mediante la stessa identica maschera, la
gestione sarebbe un po' piu' complicata, anzi non ho proprio
capito come fare
il barbi

 capito come fare
Ecco...
Controlli non associati, messi dove ti pare sulla maschera, magari combo che
ti danno solo i valori validi e legate tra loro con le requery.
La form avrà come origine record una query che ha come criteri sotto i campi
filtro cose tipo
like nz([forms]![tuaform]![tuocontrollo];"*")
Ad ogni aggiornamento di un controllo filtro, fai la requery della form.
Punto, fine, ecco fatto!!!
Antonio


ok ho fatto il test e funziona...
tra l'altro curiosamente la soluzione e' proprio quella che
avevo trovato io anni fa (questo db ha una lunga
storia...:-))). Ma io mi ero impiantato sulla storia
dell'espressione:
like nz([forms]![tuaform]![tuocontrollo];"*")
che e' necessaria per far interpretare il valore Null come
"non filtrare"... Mi ricordo che avevo chiesto a destra e
sinistra nel NG ma nessuno me l'aveva saputo risolvere,
tutti mi dicevano di usare il filtro, dove pero' c'e' questo
problema della dipendenza di Combo2 da Combo1 (anzi, c'e'
anche Combo3 che dipende da Combo2...:-)))
Quindi ti ringrazio molto, ma non prendertela se ti dico che
operativamente questa soluzione non e' soddisfacente. Ossia
non e' soddisfacente avere nella stessa maschera le Combo1,
Combo2 e Combo3 associate e a fianco quelle non associate
per fare la ricerca, anche perche' i controlli suscettibili
di ricerca sono anche quasi tutti gli altri... Anche perche'
gli utenti sono abituati a usare sistematicamente l'icona
del Filtro in base a maschera...
Piuttosto, l'idea dei controlli non associati per fare la
ricerca va bene lo stesso nel senso che ho pensato di fare
una maschera esattamente uguale a quella principale dove
pero' tutti i controlli sono non associati (in pratica e' la
stessa maschera che mi esce cliccando su Filtro in base a
maschera). Dalla maschera principale con un pulsante apro
questa maschera di ricerca e posso assegnare Combo1, Combo2,
Combo3 ecc. con tutte le restrizioni del caso, e alla fine
uso un altro pulsante per applicare i valori di filtro nella
maschera principale, simulando l'evento applyfilter
il barbi

 del Filtro in base a maschera...
Su questo fatto degli utenti secondo me non è bello lasciare disponibile la
barra degli strumenti con cui possono fare danno.
Puoi per esempio mettere le combo filtro nell'intestazione maschera e nel
corpo quelle associate.
C'è anche da dire che secondo me bisognerebbe separare la parte inserimento
da quella consultazione e quindi in consultazione (e quindi filtri) non ci
dovrebbero essere le combo associate ma caselle di testo normali.
Antonio


no, piu' che altro non sapevo se avevo capito bene...:-)

be' questo discorso dell'utente che fa danno e' vero, ma non
per questo io moltiplicherei le maschere, ad es. si puo'
pensare di usare i parametri della maschera "Consenti
modifiche/ eliminazioni/ aggiunte" a fronte di una qualche
password di supervisore (quello che puo' inserire i dati nel
DB)
comunque ho testato anche la soluzione che avevo prospettato
e funziona, in pratica ho simulato un "Filtro in base a
maschera" con una maschera apposita per il filtraggio in cui
ho messo il comando "Applica filtro"; cosi' ho il vantaggio
che posso applicare i criteri tutti insieme e, quando
rientro nella maschera principale, mi ritrovo i record
filtrati e l'icona "Applica filtro" incassata
il barbi

 DB)
Il discorso di fondo č che quello che fanno le barre degli strumenti lo puoi
sempre simulare tu tramite controlli e codice sulla maschera.
In questo modo perň quello che fa l'utente č tutto controllato e limitato a
ciň che gli dai, con le barre non sempre č cosě...
Antonio