Neznam tačno gde ti je zapelo ali si počeo korektno. Kreiraj upit dovlačeći neophodne tabele u dizajn prozor upita. U polju Criteria navedi uslove za svako polje sa forme, tako što ćeš upisti referencu na formu. Recimo:
[Forms]![naziv forme respektivno]![naziv polja respektivno]. Na kraju dodaj dugme na formi i u događaju On Click napiši DoCmd.OpenQuery.

Meni to više liči na organizacioni problem nego na problem u dizajnu, jer bi u cilju zaštite podatak korisnicima trebalo da bude omogućeno da vide ono što treba da vide a ne ono što hoće, a još je gore ako imaju pristup bazama i 'kasape' ih kako ko stigne.
Možda bi to mogao da rešiš tako što ćeš napraviti više upita sa različitim kombinacijama a na nekoj formi omogućiš korisniku da izabere jednu od ponuđenih kombinacija ...

@ Getsbi
Koliko ja razumem njemu je problem što mu trebaju upiti sa 'dinamičkim brojem polja' tj da konkretni korisnik izabere koja polja hoće da vidi, a uz to se verovatno radi o korisnicima koji ne poznaju access ...

Mozes to da uradis na vise nacina. Npr preko iif f-je ispitas da li je check box potvrđen pa ako jeste onda prikazes podatke. Naravno, kao sto rece kolega, biras podatke za prikazivanje sa [Forms]![naziv forme respektivno]![naziv polja respektivno]. Ako sam dobro razumeo problem :)

Brz_na_tastaturi mi se cini u pravu. Sta korisnici zele da vide nije bas toliko 'slobodna tema'. Zavisno od bisnzisa koji rade, moze se pretpostaviti sta bi im trebalo, otprilike. Iz prakse znam da je veci problem definisanje WHERE uslova nego potrebnih kolona. Kod mene sa mnogo uspeha ide sledeca taktika:

- ja pisem kverije koji rade sta korisnicaima treba. U pocetku svako malo pa nekome nesto treba sto nemamo, posle se smanji

- ti kveriji nisu upotrenbljeni nigde u aplikaciji, sluze samo da ih korisnici izaberu donekud i pogledaju rezultate

- kveriji imaju uglavnom vise kolona nego sto korisnicima treba

- imam tabelu koju zovem zSysQueries i tu cuvam (qryName, Opis) qryName je ono sto vidimo u Query prozoru. opis je ono sto napisemo da bi korisnici razumeli o cemu se radi.

- Kad god napisem novi kveri (na zahtev korisnika), dodam jedan red u tabelu zSysQueries

- U aplikaciji imam formu na kojoj je veliki lis box, baziran na zSysQueries. Prva kolona, qryName je nevidljiva, vidi se samo Opis

- Korisnik bira opis sa liste i na DblClick ili nekim dugmetom se odradi
DoCmd,OpenQuery QueryName:= me!lstBox

Kad otvore kveri, mogu da sakriju nepotrebne kolone i upotrebom filtera da postignu efekat WHERE.
Ovo pokriva 90% korisnickih potreba. Ktroz vreme, broj zahteva za novim kverijima opada, pa umesto svaki dan, imam potrebu da dopisemo neki kveri jednom u mesec dva.

U cemu je problem sa ovim pristupom? Kad god napisem novi kveri to je promena aplikacije i aplikacija se mora osveziti na svim radnim stanicama. Jedan moj kolega je smislio fenomenalan fazon da se to odradi:

1. na nekom network folderu koji mogu citati svi korisnici aplikacije, drzimo .MDE versiju tekuce aplikacije
2. napravili smo .BAT fajl, u tom istom network folderu koji izgleda ovako:


3. Svim korisnicaim smo dali shortcut na .BAT fajl umesto kopije aplikacije
4. Kad god startuju .BAT fajl, korsnici i ne znajuci obrisu fajl an C drajvu (MD C:\Aplikacija) i donesu sebi novi verziju sa networka.

Ovo mi se mnogo dopalo, jer se aplikacije 'za u kuci' menjaju mnogo cesce nego aplikacije koje pisete za externog korisnika. Stalno se menjaju potrebe, menja se proces rada i dobar sistem (baza + razne aplikacije) sve to mora da prati. Jedini nacin pracenja je da se povremeno dopisuju novi objekti, menjaju ili uklanjaju postojeci. Znaci, jedna vrsta stalne dogradnje aplikacije. Vrlo neprijatna stvar ako je 'deployment' tezak. Sa nasim .BAT fajlom deployment je nepostojeci problem. Cesto dobijemo poziv od korisnika koji je ortkrio neki bug ili treba neku sitnu izmenu. U roku od nekoliko minuta stvar se popravi (najcesce, ne uvek i samo zovnes korisnika i kazes "Ziko, OK, izadji iz programa i startuj ga ponovo"

Njacesci zahtev za dodavnaje funkcija je dopisivanje kverija, pa odrzavanje aplikacije i dodavanje poslovnih funkcija nije tako veliki problem. Posto je lako menjati aplikaciju i svima dostaviti promenu, onda ni nekompletna specifikacija i nedoreceni projektni zadatka nisu problem. Uvek mozemo lako da dodamo sta nam treba.

Kako pogoditi koji kveriji bi bili interesantni korisnicima, za pocetak? Pogledajte realtionships diagram. To je graf, gde su tabele cvorovi. Teorijski, bilo koji put zmdeju dva cvora jeste kandidat za JOIN. Recim, uvek imate nesto kao

Kupci--< Narudzbe ---< StavkeNarudzbi >------ Artikli

Po meni, jejk kanmdidat za kveri je JOIN izmedju ove cetiri tabele, sa svim mogucim kolonama, bez ponavljanja. Odmah sledi GROUP BY po (Kupac,Narudzba) kao i GROUP BY po Artiklu.

Pagledajte dakle relationship diagram i to ce vam kazati koji otprilike kveriji trebaju, za pocetak. Ne treba bas svi moguci putevi da se pretvore u kveri, ali cete vec dobiti ideju. Naravno, pitajte i korisnike. Kad pocnu da rade sa sistemom, vrlo brzo ce vas izbombardovati zahtevima i kroz nedelju dan imacete cistu sliku i nmnogo funkcionalniju aplikaciju.

Ovakav sistem dodavanja kverija i izbor iz list boxa moze se primeniti i na reporte. Uvek treba neki novi report. Za report se prica malo komplikuje, jer za reporte treba postaviti kriterijum (od datuma do datume, za kupca tog i tog i slicno) pa se u igru uvode i forme za definisanej kriterijuma. O tom drugi put ako ima interesovanja.

Da se i ja nadovezem mozda pomognem sta.
U principu slazem se sa idarevom pricom da u vecini slucajeva korisnici traze i ono sto im u stvari i nece trebati pa ako slusate njih onda cete napraviti najmanje 100 razklicitih izvjestaja koji uglavnom nemaju smisla.
Najbolji nacin je prije izrade programa dogovoriti sta program treba da sadrzi pa ako se nesto ispusti onda to treba i platiti dodatno.
Ovim nacinom se ogradjujete upravo od takvih slucajeva jer onda nece traziti ono sto im mozda nece ni trebati.

Druga stvar je ako to stvarno treba tako onda je naravno moguce i to izvesti jer SQL naredbe nije tesko prevesti na naski ze da korisnik ukucava nase rijeci odnosno da bira sa ekrana sta hoce a to poslije kodom pretvoriti u naredbe SQL-a.

Imao sam jedanput takav slucaj gdje sam to morao primijeniti.
Baza je bila vema velika preko 1000 polja smjestenih u blizu u preko 50 tabela.
Obiljezenih polja za moguca filtriranja odnosno pretragu je bilo preko 100, medjutim u jednom momentu pretrage nije se koristilo vise od a5-20 polja.
Da bi bilo jasnije mozda da opisem neke tabele koje su rel. vezane:
Tabele:
Osobe.
OpstiPodaci
PrednetiIStavri
Boje
Dezeni

Da napomenem u ovakvim slucajevima pri kreiranju tabela treba obavezno prenositi primarni kljuc iz osnovne tabele inace pretraga ce biti veoma mukotrpna i spora.
Medjutim ako su tabele kreirane po propisu onda to i nije nesto tesko.

U gore navedenom primjeru postavlja se pitanje kako naci naprimjer osobu koja koja ima zlatni lanac i Djemper plave boje.

Naravno vi nemozete napraviti pretragu samo po poljima ImeStavri,boja i materijal jer ovo vazi samo za ovaj slucaj, kod neke druge osobe ce biti neke druge stvari koje se mogu prepoznati na osnovu nekih drugih polja a boja i materijal ne dolaze u obzir.

U ovakvim slucajevima se moze razmisljati o pravljenju pretrage na osnovu odabranih polja.

Veoma je bitno da se i zna koliki je maksimalan broj polja za pretragu a ako i to neznate onda ste prinudjeni i formu za pretragu kreirati kodom i sva polja u njoj.

Ako dodje do takve situacije onda je najbolje kreirati kodom novu mdb i sve to smjestiti u nju i linkovati tabele potrebne za pretragu.
Razlog vise je i to sto se u mde ne moze kreirati kodom forma kao ni kontrole.