Newsgroup: it.comp.appl.access
Titolo: passare valori all'operatore 'in' in una query

In una normale query con parametri, se voglio selezionare solo certi
valori di un campo, mi basta usare l'operatore IN e aggiungere la
condizione
In("Torino";"Milano";"Genova")   , per esempio
Se però voglio che sia l'utente a scegliere quanti e quali valori
selezionare, dovrò usare una maschera per passare i valori alla query.
Per iniziare con un esperimento semplice, ho fatto una maschera di
prova con una textbox. 
Nei parametri della query ho provato fiduciosamente a scrivere
In([forms]![frmProva]![ctlTextbox])
Quindi ho provato a eseguire la query, dopo aver scritto un elenco
nella textbox, in vari modi:
Torino;Milano;Genova
"Torino";"Milano";"Genova"
"'Torino';'Milano';'Genova'"
ma figuriamoci, non funziona mai.
Eppure a me l'idea sembra ragionevole; scusate il momento di malumore,
ma che noia!!
Sono sicuro che c'è qualche diabolico dettaglio che mi sfugge, e
quando qualche anima caritatevole me lo avrà detto, mi dovrò dare
dello scemo... ma perché Access deve sempre complicare
all'inverosimile anche le questioni più banali?
poli

 malumore, ma che noia!!
  Non capisco bene quello che dici... se la quety è una query con 
parametri, allora ad ogni parametro DEVI passare UN valore; non puoi 
passare ad un parametro un'istruzione SQL o VBA.
  Supponendo pero' che tu, invece che parametri, intendessi dire 
CRITERI, allora ti dico che la cosa che proponi NON può funzionare per 
un motivo molto semplice. L'operatore Campo IN (v1, v2, v3, ...) 
verifica che il contenuto del campo Campo sia uguale ad uno dei valori 
contenuti nelle variabili v1...vn enumerati tra le parentesi ( e ).
  Ebbene, scrivendo Campo IN ([forms]![frmProva]![ctlTextbox]) tu 
chiedi all'operatore IN di verificare se il contenuto di campo è 
uguale all'UNICO valore (stringa) contenuto tra parantesi.
  In altre parole, se «Torino;Milano;Genova» è il contenuto della 
casella di testo ctlTextBox, allora l'espressione prima scritta 
equivarrebbe a scrivere
     Campo IN ("Torino;Milano;Genova")
  Nota che la stringa «"Torino";"Milano";"Genova"» verrebbe 
interpretata come
     Campo IN ("""Torino"";""Milano"";""Genova""")
cioè sempre e solo come un unico valore stringa.
  Questo è il motivo percui la query non ti ritorna nulla.  
  Cosa fare allora? Beh, le strade da seguire sono diverse. Se 
utilizzi il risultato della query come origine dati di una maschera 
allora puoi utilizzare la proprietà Filter della maschera stessa.
  Per esempio, supponiamo che la tua query si chiami Query1 e 
supponiamo che la query Query1 funga da origine dati per la maschera 
Maschera1.
  Se nella Intestazione della  Maschera1 posizioni una casella di 
testo (TextBox1) ed un pulsante (Comando1) allora potresti scrivere 
questo codice nel suo evento Click:
Private Sub Comando1_Click()
 
    If Len(TextBox1) > 0 Then
        Me.Filter = "Campo1 In (" & TextBox1 & ")"
        Me.FilterOn = True
    Else
        Me.Filter = ""
        Me.FilterOn = False
    End If
 
End Sub
  Altre soluzioni più complesse prevedono, ad esempio, la modifica del 
codice SQL associato alla query da codice VBA, oppure l'utilizzo di 
tabelle (temporanee o meno) di appoggio.
  Qual'è la tua esigenza?
  Ciao.
-- 
Raccolta di programmi freeware
http://digilander.libero.it/winses/
----
Togli '_' e '.invalid' per rispondere...

 poli
-- 
Roberto
-----------------------------------------------------
il Sito Comune di it.comp.appl.access
http://www.sitocomune.com
----------------------------------------------------

 O sbaglio?
Mah, più che altro speravo confusamente che ci fosse un modo perché
jet *valuti* una stringa, anziché prenderla in blocco... ma
chiaramente non c'è. E siccome non mi risulta neppure che ci sia un
tipo di controllo che restituisce una *tupla* di valori anziché un
solo valore, mi sa che devo lasciar perdere (un pizzico di rabbia mi
viene lo stesso però: per es., ma che diavolo di valore assume una
casella di riepilogo impostata in modo da accettare selezioni
multiple? Null?! Ma che senso ha...)
Il problema è che qualche anno fa avevo fatto un'applicazione
piuttosto complessa in Access, che adesso avrebbe bisogno di
un'aggiornamento. Ma francamente è da un bel po' che ho abbandonato
Access, ormai, e non ricordo più quasi nulla... Probabilmente è solo
questione di rifarci un po' la mano.
Ma ieri, dopo mezza giornata passata a risolvere faticosamente una
decina di problemini stupidi del genere, ho avuto la forte tentazione
di buttare via tutto e riscrivere daccapo l'intera applicazione usando
gli strumenti con cui mi trovo meglio... Di qui il momento di noia e
di sconforto. 
Ad ogni buon conto, grazie a entrambi per le vostre risposte, sono
state utili.
Per quanto riguarda il problema specifico, alla fine ho scelto di
rinunciare ai criteri where, di recuperare tutti i dati e poi
filtrare: pensandoci oggi a mente fresca, ho capito che è la soluzione
più corretta per il tipo di uso che l'utente farà di quei dati...
poli

"poli" <ric...@YYYtiscali.it> ha scritto nel messaggio
news:42fcff58...@news.tiscali.it...

Io sono più di quarant'anni che programmo e mi è sembre capitato di
uniformare il mio modo di ragionare alle regole imposte dall'ultimo
linguaggio di programmazione e/o applicativo che stavo usando, al punto da
ritenerle naturali, così che poi, al momento che cambiavo linguaggio ho
fatto sempre molta fatica ad accettare che certi problemi venissero risolti
in maniera diversa e mi sembrava illogico non avere più a disposizione
strumenti che ormai consideravo il sesto dito della mia mano destra.
Poi con il tempo assimilavo il nuovo linguaggio e quindi mi rispuntava il
sesto dito della mano destra.
