Kratak odgovor:
Ne.

Dug odgovor:
TQuery i TADOQuery povuku podatke sa DB servera ili nekog drugog data provider-a kada pozoves T(ADO)Query.Open. Prilikom poziva Open query komponenta prosledjuje sql text provajderu direktno bez ikakve promene, tj. Delphi nema blagu predstavu sta si ti u query napisao da hoces. Cim podaci stignu od provajdera kopiraju se u internu memorijsku strukturu query objekta u tabelarnoj formi, i od tog trenutka na dalje mozes da citas podatke sa FieldByName ili FindField metodama. Jednom otvoreni query ne moze da sluzi kao dataprovider za drugi query zbog toga sto se podaci transformisu-izravnaju u tabelarnu strukturu koja nema nikakve informacije o tome koje polje je odakle doslo. Ono sto mozes da uradis, sto se i inace radi u svim komplikovanijim aplikacijama, je da dinamicki kreiras/dopunjavas SQL tekst tokom izvrsavanja programa i da koristis parametre. Takodje mozes i jednom otvorni query da dodatno filtriras sa TQuery.Filter i TQuery.Filtered, mada je to ograniceno i u smislu mogucosti i performansi.

Hvala Borise na odgovoru. :)

Pogledacu onda malo po netu oko koriscenja parametara.

Ono sto mi je nejasno jeste kako bih "spojio" sledeca dva kverija.

Query1:


Query2

gde ... kod SELECT oznacavaju jos nekoliko izabranih tabela, a ...nesto... oznacava nekoliko ugnjezdjenih INNER JOIN-ova.

Ovo je SQL koji je Access izbacio, izostavio sam gore naglaseno zbog preglednosti, ako treba mogu ubaciti. Bilo bi dobro bar da dobijem neke smernice u kom pravcu da razmisljam, posto nisam radio mnogo sa SQL-om, bar ne ovakve malo komplikovanije upite.

Kao što ti Boris reče, to ne može tako u Delphi.

Jedna stvar koja mi prva pada na pamet, a da može da ti reši problem, jeste da koristiš VIEW. Ako su ti ti upiti "statički", odnosno ako se ne menja tekst upita, onda onaj prvi napraviš kao VIEW a onda ovaj drugi modifikuješ da koristi njega umesto ono "Query1".

Drugo, možeš da napraviš ugnježdeni Query (pod uslovom da DBMS koji koristiš to podržava). Ključna rečenica za to je SELECT FROM SELECT.

Ajde probaj tako nešto, pa ako zapneš pitaj.

Hvala Dejane. Pokusao sam da nadjem nesto o koriscenju VIEW-a, ali mrka kapa za sada. Nasao sam samo jedan primer uradjen, ali nigde nisam nasao neko objasnjenje kako funkcionise i kako ga pravim u Delphiju. Ako ti imas neki link o tome ili te ne mrzi da ukratko objasnis, bio bi ti (jos jednom :)) vrlo zahvalan, to mi deluje kao fino resenje. Inace, upiti jesu staticki. Ja cu probati sada sa ovim drugim predlogom, to mi se cini da bi trebalo da znam da odradim, pa cemo videti sta ce ispasti.

te staticke upite u accessu bi delphi trebao da vidi kao tabele, ne znam da li si probao... probaj da odradis taj upit nad upitom u accessu i da ga nadjes u delphiu kao klasicnu tabelu. za upite sa parametrima koristi adostoredproc

Probacu i tako, pa cemo videti. Uspeo sam u medjuvremenu da odradim posao sa jednim query-jem, kao neko privremeno resenje, dok ne sredim ovo. Hvala jos jednom svima na savetima.

Sto si tice VIEW-a, ako se budes bavio ovim u zivotu nagledaces ih se, stoga mozes vec i da naucis o njima. Ovako uprosceno, VIEW je jedan SELECT iskaz, koji je sacuvan negde u bazi.
Primer:

CREATE VIEW MojView AS
SELECT * FROM MojaTabela1 INNER JOIN MojaTabela2 ON Mojatabela1.K1 = MojaTabela2.K1.

Ovakav VIEW kad napravis, podatke iz njega uzimas na sledeci nacin:

SELECT * FROM MojView. Rezultat ce biti isti kao da si pozvao SELECT * FROM MojaTabela1 INNER JOIN MojaTabela2 ON Mojatabela1.K1 = MojaTabela2.K1.

Poenta VIEW-a jeste da ako ces gornji JOIN koristiti cesto, ne pises ga svaki put. SQL kod ti bude cistiji, razumljiviji. U VIEW mozes da stavljas i unije vise upita, itd. Da ne duzim, procitaj malo o VIEW-ovima, pa ces videti zasto su dobri, i probaj da se nateras da ih koristis. Naravno, nije to sveto pismo, i koristi ih onda kada ima potrebe i smisla, ne po svaku cenu.

Pozdrav, i javi ako zapne.

Hvala mnogo Marvine na pojasnjenju VIEW-a. :) Deluje dosta elegantije ovako preko njega. Svakako cu prouciti ovo, a verujem i koristiti. Pozdrav

View-ovi su mac sa dve ostrice. Sa jedne strane ti olaksaju zivot jer ti omogucavaju da reorganizujes podatke u upotrebljivu formu i onda lakse sa njima baratas. Problem sa druge strane je u tome sto su staticni. Na primer, ako imamo view:


Ako ti trebaju npr. samo kupci (ID_TipStranke = 2), ne mozes napisati

...jer se polje ID_TipStranke ne nalazi u view-u. Ali to se da resiti ako dodamo jos jedno polje u view:


Sada ce query [SELECT * FROM ListaStranaka WHERE ID_TipStranke = 2] da radi, ali kako? Prvo dovuce sve stranke (izvrsi ce select koji kreira view), pa tek onda se nad tim podacima izaberu (Selectuju) oni koji imaju ID_TipStranke = 2. To je jos i prihvatljivo za ovaj simple primer, ali sta ako imas milion stranaka ili ne daj boze aplikaciju za banku?

Da ne duzim, problemi pri svakom Selectu gde je dataprovider view a ne tabela su sledeci:
- Naknadno filtriranje je moguce samo po poljima koja su selectovana u view, cak iako znas strukturu tabela na kojima se view zasniva
- Najpre se izvrsi ceo view pa tek onda ostatak selecta
- Eliminises sve optimizacije DB Servera, jer forsiras execution planner da radi na tacno odredjen nacin

Upravo zbog ovih razloga view-ovi se u praksi koriste najcesce za male kolicine podataka ili za podatke koje ne treba naknadno filtrirati ili transformisati (npr. top 10 kupaca ili neki kumulativni izvestaj)

Btw., MSSQL 2005 omogucava tzv. indexed view-e koji su nesto brzi, ali su toliko ograniceni preduslovima da su neupotrebljivi.

Hvala Borise. Posto sam jos na pocetku da tako kazem rada sa bazama, necu odmah raditi sa velikim bazama pa cu pokusati da kroz male baze udjem u stos sa VIEW-om. A imacu na umu i nedostatke koje si naveo kada budem radio sa bazama sa mnogo podataka.