Newsgroup: it.comp.appl.access
Titolo: ricercare stringa in tutti i campi

Ciao,
con una query in A2003 sarebbe possibile cercare una determinata stringa ma in tutti i campi di una tabella?
Per es. se cercassi la stringa "rom" in un'anagrafica, potrebbe trovare nel campo nome "romeo", nel campo cognome "trombetta", nel campo città "roma".
Grazie per l'aiuto.
 
Remigio


Ma è mai possibile che una stringa sia da ricercare in tutti i
campi....?
Come hai strutturato la tabella...?
 
Io se devo cercare unome nella Tabella Anagrafica lo cerco nel campo
"NOME" non la vado a cercare in "INDIRIZZO".... o in [TELEFONO]....
 
Chiaramente il mio è un'esempio per farti capire che forse qualche
cosa di strano c'è e vale la pena capire meglio...
 
@Alex

 Remigio
 
 
tecnicamente e' possibile, solo che difficilmente e' utile.
 
se prepari una maschera che esegue la query:
 
select * from * where * like '*rom*'
 
il risultato e' inutilizzabile il 99% delle volte.
 
 
 
-- 
Paolo opg
 
BE AWARE that this post uses a fake reply-to address
to contact me write to:
janickg ( at ) hotmail ( dot ) com
--

 wrote:

Ciao Remigio.
E' molto semplice; basta inserire nella query sotto il campo nome nel
rigo Criteri "rom", sotto il campo cognome nel rigo Oppure "rom" e
sotto il campo città nel rigo Oppure (più in basso dell'altro Oppure)
"rom".
Volendo, puoi inserire un parametro (l'importante che sia lo STESSO
PARAMETRO) di ricerca nei tre righi su esposti; ad esempio Like "*" &
[Inserire la stringa da ricercare] & "*"
Ciao Vladimiro.

Ho adottato la soluzione di Vladimiro, che in effetti era quello che stavo pensando di ottenere.
Vi ringrazio tutti per l'aiuto.
Saluti.
 
Remigio


In effetti è strano, ma + usato di quanti si pensi.......nel campo dei
libri (per esempio) la ricerca con parola chiave che cerchi un match
su autore, titolo ed editore contemporaneamente è molto usato. Lo
sviluppo nn è banale (la parola puo essere in tutti i campi, in uno
solo, due parole una sul titolo e una sull'autore....) a mio avviso ma
molto utile. Chiaro che si parla di ricerche molto avanzate, da usare
con query full-text (quindi non access) o con tabelle (o campi) di
appoggio che contengono già scremature delle ricerche da gestire ogni
modifica/inserimento dei record (altrimenti si diventa vecchi
nell'attendere i risultati su corpi di record molto grossi). Una roba
insomma abbastanza mastodontica, ma per l'utente finale nn è male per
nulla....

 nulla....
 
Pur comprendendo quello che dici, reputo sia una distorsione delle
basilari regole di Normalizzazione.
Questo non significa sia sbagliato, ma non funzionale.
Aggiungo, oltretutto che quanto stai dicendo tu(suggerito poi da
Vladimiro) è in tutti i caso MOLTO differente dalla richiesta dell'OP.
Avete fatto l'ipotesi che si limita a pochi campi... non TUTTI come ha
richiesto all'inizio e concetto sul quale ho espresso riserve.
Anche perchè ribadisco, nella norma le Tabelle viaggiano relazionate
con INDICI NUMERICI non sono grosse tabelle come i fogli ei EXCEL e
fare ricerche
FullText monotabellari è inutile.
 
In tutti i casi ognuno si fa male come meglio crede.
 
@Alex
 


Capito quello che intendi. Anche vero che ricercare su 3 campi è
diverso che ricercare su n campi variabili.....Cmq io nn ci vedo nulla
contro la normalizzazione, che di fatto è da attuare per costruire il
db e poi rappresentarlo. Ma se devo fare una ricerca complessa (parlo
chiaramente di esperienza utente) alla fine è come, in effetti, se io
presentassi un foglio excel all'utente finale....Cosa intendi per
ricerche full-text monotabellari inutili?