Databáze > Firebird a Interbase

IBQuery

<< < (5/5)

Mi.Chal.:

--- Citace: pepak  06-10-2012, 11:02:52 ---No tak například právě v případě, že si Dataset vytáhne z databáze celý resultset najednou, už se RecordCount použít dá.

--- Konce citace ---

Což něco stojí - pokud to taháš postupně, tak můžeš zpracovávat data dřív, než všechno dorazí. Pokud taháš všechno, tak třeba půl minuty zbytečně čekáš a pak to zpracování bude trvat o půl minuty déle.


--- Citace: pepak  06-10-2012, 11:02:52 ---
--- Citace ---Projde se max. stejné množství dat, ale netahá se na klienta.
--- Konce citace ---
V ideálním případě ano. Podle selského rozumu ano. V praxi někdy ne. Typicky, pokud původní dotaz obsahuje agregace.

--- Konce citace ---

Ono se to taky dost často chová tak, že první provedení dotazu trvá třeba i několikrát déle, než opakované, kdy se už řada dat nacachovala. Takže v některých případech může být ten count() pomalejší, než to vytažení dat. Pokud bys ho ale neudělal, tak to ty data bude tahat o to déle. Pomalý není ani tak ten count, jako to, že k datům přistupuješ poprvé.

Radek Červinka:

--- Citace: pepak  06-10-2012, 10:16:12 ---
--- Citace ---Písal som, že počet záznamov potrebujem na nastavenie dĺžky poľa.
--- Konce citace ---
V tom bude patrně algoritmická chyba - předem neznámý počet záznamů se obvykle v poli neuchovává. Máš nějaký zásadní důvod, proč je neukládáš třeba do TListu, když už chceš zachovat přístup jako k poli?

--- Konce citace ---

Já to dělám třeba docela často - myslím tím dynamická pole.  Zvláště v případě kdy položka pole je record - věta načtená z DB. Nemusím myslet na uvolnovani paměti a přes record helpery s tim pěkně pracuji. Navíc je jaksi samozřejmě bez námahy typově korektní, což do příchodu generik byl docela opruz vždy definovat následníka TList. Samozřejmě to používám primárně v případech kdy nemažu záznamy, v opačném případě je výhoda TList a spol nesporná.

Stanislav Hruška:
Tak tie úvahy o RecordCount mi dávajú zabrať. Budem čumieť do kódu aby som to nepotreboval. Okrem iného aj zobrazujem počet záznamov. To ovšem nemusí byť.
Včera sa mi stala takáto vec (zabil som s tým pár hodín):
Spustím Query a následne ďalší kde

- v selecte je len count(*)
- ostáva pôvodná časť FROM a WHERE
- prípadný ORDER BY je vyhodený

a vrátim si počet záznamov. V jednom prípade prípade mi hlásilo chybu (asi -303) konverzie stringu na "False"?

Ak som SQL spustil v TIBQuery, v ktorom sa predtým vykonal kompletný dotaz, tak to bolo OK. Vo všetkých ostatných prípadoch to padlo na chybu. Iný, aj doposiaľ nepoužitý, TQuery. Chyba zmizla ak som

Query.SQL.Text := ''; // pridal tento riadok
Query.SQL.Text := SQLText;

Vie to niekto (stretol sa s tým) vysvetliť?

Ak prejdem DataSet

WHILE not query.EOF do
begin
....
query.Next;

Tak by som, podľa mňa, nemal mať žiaden problém s Query.RecordCount - prosím o vyjadrenie.

Poznámka:
Ja tie DataSet-y komplet prechádzam a načítavam z nich všetky údaje napr. do
- LookUpComboBox
- VirtualTreeView
- do poľa pre ďalšie použitie, aby som nepracoval s DataSet-om. Možno to je nesprávny prístup (?). Napr. tie parametre programu, podľa ktorých sa určuje jeho správanie.

DBGrid nepoužívam.

pf1957:

--- Citace: Stanislav Hruška  06-10-2012, 09:43:42 ---Takže jednoznačne odporúčate použiť FetchAll a/alebo count(*)

--- Konce citace ---
Mam pocit, ze to stale nechapes: kdyz pouzijes count(*), tak uz nemusis delat zadne FetchAll ani Last a nepouzivas vubec RecordCount, ale pocet si prectes z result setu po tom selectu s count(*). To FetchAll je alternativa k tomu Last.



--- Citace: Stanislav Hruška  06-10-2012, 09:43:42 ---...
Musíte použiť metódu Last." Takto to funguje. Platí to pre tabuľky aj dotazy.a nespoliehať sa na
RecordCount + Last.

--- Konce citace ---
FetchAll a Last jsou alternativy, jak nastavit do RecordCount platny pocet zaznamu, ostatne treba konkretne u IBQuery je to implementovano tak, ze si zapamatuje v bookmarku soucasnou pozici, udela Last a pak pozici obnovi.

Ale uz jsem potkal query, ktere nedovoli se vracet, takze jak jednou udelas Last, tak sice ziskas RecordCount, ale uz se k jinym datum v result setu nedostanes, protoze jsou jednosmerne. Ale nepamatuji, ktere to konkretne byly.

Osobne se ridim tim, ze jakmile pouzivam Query, tak vzdycky ctu pocet pres count(*) a vzdycky prochazim result set od zacatku do konce pomoci while not Q.Eof do ...

Navigace

[0] Seznam témat

[*] Předchozí strana