Ovo je vise Delphi pitanje.
Koristi TDataSet.Locate sa loPartialKey opcijom.



Ne, povuku se samo oni koje treba prikazati.

Hm, mislim ipak da se povuku svi zapisi, jer upit nije ogranicen nekim uslovom, ali se prikazu samo oni, koje si definisao uslovom u toj aplikaciji.

Doduse nisam nikad radio sa Delphijem, pa ne znam kako to sve zajedno funkcionise.

Koliko ce se slogova povuci zavisi od konkretne implementacije naslednika TCustomDataSet. Neki imaju i mogucnost da podesis kako ce da se ponasa, to jest da li ce da povuce sve slogove ili samo deo a u toms lucjau i koliko slogova da povlaci.

to koliko redova da se povuce iz tabele/baze u user-interface je skakljivo pitanje i u stvari je kompromis izmedju toga kolika kolicina podataka treba da se dovuce (gde "sirina" tabele takodje ima znacajan uticaj) i toga koliko mazimo user-a, tj. da li nas je briga koliko ce isti da ceka na odziv punjenja pogleda u tabelu ili nas nije briga...

ukupno postoje 3 nacina gore/dole kretanja po tabeli: gore/dole strelicama, PageUp/PageDown i Ctrl+PageUp/PageDown, gde je lako shvatljivo sta koji treba da uzrokuje (kod zadnjeg se samo radi o vrhu i dnu tabele)

e sad', negde kazu da korisnik gubi interes za desavanje na ekranu posle 3 sec, da "sadasnjost" traje upravo toliko, pa bi to mozda bio limit koji ne bi trebao da se prekoraci; cak postoje resenja kod kojih se novo-pridosli red odmah baca na ekran, tako da ipak ima neke dinamike, sto je bolje nego da se gleda u ekran na kome se nista ne desava

moze se ciniti da bi neko dobavljanje redova unapred, a da se to desava u pozadini interfejsa, bilo elegantno resenje, ali se onda postavlja pitanje moguce bespotrebnog protoka gomile podataka koji tesko da ce biti iskorisceni; zamislite da se podaci vuku kroz net ili neku lokalnu mrezu - kakav bi u njima bio saobracaj :(

dakle pitanje nije nimalo naivno iako se takvim cini...

Imas dve opcije,

Prva ti je da za svaku ukucanu rec uradis query sa LIKE.

Druga ti je da pokupis sve podatke na klijentske strane sa SELECT * FROM X, i onda to filtriras uz pomoc borlandovim TDataSet klasom. Otvoris query, u start uradis:

IBDataset1->FetchAll();

i onda menjas filter dataseta po zelji. Pogledaj TDataset::Filter

Sve ti je ustvari trade off kolicine podataka i brzine search-a. Kad je kolicina podataka velika onda nema logike da neko zeli da pretrazuje bazu sa opstim kriteriuma i da dobije rezultat od milion rekorda.

Sto znaci, ako je rekordset mali, isplati se da ga povuces na klientskoj strani i da ga dalje filtriras sortiras i sta li jos ne, ukoliko je dataset ogroman, onda moras odrediti vise striktnih kriteriuma za pretragu. Kao na primer wild char pretraga da ne sme pretrazivati za manje od 3 slova i sl. I onda opet dobijes mali dataset koji povuces na klientskoj strani i onda sortiras i filtriras.

Radi se o tome da korisnik zeli da ima pregled neke tabele i da po njoj seta gore dole (i po potrebi trazi neki podatak). Kod rada sa lokalnim bazama nema problema, linkujem Table na DataSource i DbGrid i gotovo ali kako da uradim sa C/S bazom na LAN-u? Kako drugi to rade?

A meni uopste nije jasno dali ti imas pretstave koja je razlika TTable i TQuery ?

U principu iz programerskog aspekta nema razlike, obe na kraj zavrse sa datasetom odredjenih podataka koje zatim mozes da pretrazujes sortiras i sta god jos zelis. Jedino kod query ija mozes da spojis vise tabela odjednom ili da selektiras odredjeni opseg podataka, drugo sve je isto.

Procitaj jos jednom moj zadnji post. Sve ti je trade-off performanse i kolicine podataka. Da se ne ponavljam, procitaj, razmisli, testiraj real-world scenario onda pisi sta si sve novo otkrio :)

Mislim da se nismo razumjeli. Ja i ne poredim TTable i TQuery (inace razlika mi je jasna). Ja sam pitao kako da kod pristupa Firebird bazi uradim ono sto sa lokalnim bazama (dbaze, paradox...) radi FindNearest. Locate radi nesto slicno ali FindNearest trazi najblizi slog nekom tekstu a Locate trazi slog koji sadrzava odredjeni tekst.




Znam da mogu smanjiti kolicinu podataka sa nekim uslovom ali ja bih da korisnik moze otvoriti tabelu sa svim podacima i skrolati po njoj gore dole. Ovo je kod lokalnih baza u redu jer su podaci odmah dostupni. Pretpostavljao sam da i kod C/S baza ima neka mogucnost da se ne dohvacaju svi podaci nego samo oni koji se prikazuju a kako korisnik skrola dole tada se i dohvacaju potrebni slogovi.

Vidio sam u marketima na POS kasi da se mogu pregledati svi artikli i kretati se gore dole. Mislim da bi to bilo vrlo neefikasno ako bi se svi prebacivali sa servera.

Je li neko konkretno radio neku aplikaciju gdje je ponudio korisniku mogucnost pregleda npr. svih faktura tako da on skrola po tabeli?

Almedine, pa vjerovatno se i pri radu sa lokalnom bazom prebacuju svi unosi zatrazeni upitom, samo zbog brzine prenosa ti to ne primijetis, nego mislis da si dobio npr. samo 20 odabranih unosa...

Ti saljes bazi upit koliko unosa zelis - sve ili odredjeni broj ogranicen nekim uslovom. Uslov mozes zadati putem te aplikacije (npr. "Izlistaj 20 najnovijih unosa"), a prikaz takodje vrsis putem aplikacije. Ti dobijes npr. sve unose, ali u aplikaciji odredis da ti se prikaze samo 20 najnovijih.

Koji ces upit slati bazi, zavisi od tvojih potreba i same specifikacije zadatka, koji treba da se obavi.

Evo upravo sam testirao rad sa lokalnom bazom (dbase) tako sto sam kreirao jednu tabelu, popunio je podacima tako da bude velika oko 1,4 MB i kopirao je na disketu (kopiranje traje relativno dugo).

Na formu sam stavio TTable, TDataSource i TDBGrid i mjerio sam vrijeme koje je potrebno da se tabela otvori i prikaze u Grid-u. Ako koristim fajl na disku podaci se prikazu skoro trenutno a ako koristim fajl na disketi podaci se prikazu za jednu sekundu. U ovu sekundu ulazi i ono "skljocanje" kada se pristupa disketi. Kada se krecem po grid-u prema dole, nakon par slogova opet se pristupa disketi.

Iz ovoga se vidi da komponenta TTable ne prebacuje sve slogove nego samo onoliko koliko treba da se prikaze a zatim po potrebi dohvaca ostale slogove.

E sada mene interesuje ako je neko u praksi ovo radio sa nekim komponentama koje pristupaju Firebird serveru kako to izgleda. U opisu IBObjects stoji da se TTable moze zamijeniti sa TIBOTable i da ce aplikacija funkcionisati isto. Ako ce funkcionisati isto onda bi TIBOTable komponenta trebala dohvatiti samo mali broj slogova a kasnije ostale po potrebi inace ce korisnik osjetiti znatno usporenje.

Mozda ima jos jedno resenje, ako je bas tol'ka potreba (i ako se ja ne varam :)...

Napravi u FB stor.proc. kojoj preneses sta bi da gledas sa sve uslovom za selekciju unutar nje, a ona da vrati ustvari/kao kolone dataseta, s'tim sto unutar nje imas nekakvu FOR petlju koja u svom, da kazem "sredistu" ima jedan SUSPEND;

Pre tog SUSPEND-a napunis izlazne varijable stor.proc. cim ti volja i dobices lep dataset, koji, ako se ne varam, nece da isporucuje sve odjednom redove dataseta vec po potrebi. Najlepse od svega je, ako se opet ne varam, sto takvu stor.proc. stavis kao tabelu u SELECT pa u njenom WHERE uslovljavas njene ulaze...

Ustvari, u EMS Manager-u recimo, povuce vise redova nego se vidi na ekranu (u pitanju je neka okrugla cifra od recimo 1000), a ostatak tek kada zatreba sa strane korisnika, kad bi isti da vidi i ono sto nije preneto sa recimo strelicom-na-dole. E, sad' da bas kazes koliko bi tacno da povuces ili samo onoliko koliko staje na ekran, to valda zavisi od onoga ko podbada onaj SUSPEND...

S'druge strane, IB Console-a sem prvog nece da povuce ni jedan vise red, iz cega se daa zakljuciti da broj redova dataseta koji se dovlace bilo odakle zavisi od zahteva klijent strane, pa eto nacina da se diktira kolicina...

Evo probao sam i ustanovio da IBX komponente uzimaju onoliko slogova koliko im je potrebno. Ako su vezane za neku vizualnu kontrolu uzimaju koliko treba da se prikaze a ako nisu uzimaju samo 1 red. Prilikom skrolanaj uzimaju ostale redove.

Hvala svima koji su pokusali pomoci.