IBQuery

[Stanislav Hruška]

Používam

Kód: [Vybrat]

  SetLength(aParam, 1);
  aParam[0] := PrKey;

  IBQ('SELECT IDUSERS, FKLANDLORDS, USERS.SURNAME, USERS.FIRSTNAME, USERS.TITLE,'
    +' USERS.DATEFROM, USERS.DATETO, LANDLORD'
    +' FROM LANDLORDS INNER JOIN USERS ON LANDLORDS.IDLANDLORDS=USERS.FKLANDLORDS'
    +' WHERE USERS.FKLANDLORDS=:P0');

function IBQ(sSQL: string): Boolean; overload;
var
  I: Integer;
begin
  Result := False;

with MyQuery do
begin
Active := False;
Filter := '';
SQL.Text := sSQL;

    for I := Low(aParam) to High(aParam) do
      Params[I].Value := aParam[I];

    try
      Active := True;
      Result := True;
    except
      on E: Exception do
      begin
        Fault('Chyba v príkaze Select' +#10 + #13 + E.Message);
        Active := False;
      end;
    end;

First;
end;
end;


Vždy mi vráti prvý záznam z Users. V IBE a pod ADOQuery to funguje normálne. Už netuším, čo mám kontrolovať. V Users mám ForeignKey na tabuľku Landlords.

[Stanislav Hruška]

Už som to asi našiel. Vyzerá to, že som nechtiac zmenil kód.
Unáhlil som sa, problém pretrváva.
No, pracuje sa s tým trocha ináč

dmMain.ibqry1.Params.ParamValues['p'] := PrKey;

Trepem a trepem nezmysly. Prosím Vás, nevšímajte si ma.

Už som to objavil, ale vysvetlenie nemám. Problém je v názve parametra

    +' WHERE Users.FKLandlords=:p0');

Ak dám hocičo iné napr. :p1 tak to funguje. Vie niekto prečo?

[Mi.Chal.]

dmMain.ibqry1.Params.ParamValues['p'] := PrKey;

Už som to objavil, ale vysvetlenie nemám. Problém je v názve parametra

    +' WHERE Users.FKLandlords=:p0');

proc mas v paramValues p a v selectu p0? Ty nazvu parametru se snad davaji do sql dotazu i do parametru, ne? Mely by byt stejne.

[Stanislav Hruška]

V skutočnosti mám

    for I := Low(aParam) to High(aParam) do
      Params.Value := aParam;

To som skúšal čo sa dalo a pritom blbol.

[pf1957]

V skutočnosti mám

    for I := Low(aParam) to High(aParam) do
      Params.Value := aParam;

To som skúšal čo sa dalo a pritom blbol.

S TIBQuery jsem delal naposledy neco v D5/6, takze HOSIP, ale prijde mi to cele nejake pomatene...

Rekl bych, ze Params jsou typu DB.TParams a tam mas jen 3 moznosti, jak pridat parametr:

• Jmenem pres IBQ.ParamByName('xxx').Value := yyy
• Jmenem pres IBQ.Params.ParamValues['xxx'] := yyy
• Instanci tj. musis si vytvorit instanci TParam a tu pak pridat do kolekce parametru IBQ.Params.AddParam(param)

a pokud si instanci IBQ nevytvaris pro kazdy SQL znovu, tak je treba ty seznamy parametru nulovat.

Pokud ale parametru nedas jmeno, tak bys mel v SQL tzv. pozicni parametry tj. misto :xxx napsat ? nebo ?1 atd.  Ale uz nevim, jestli to Ptak ohnivak a komponenty IBX podporuji.

[Stanislav Hruška]

Takže ešte raz, a snáď už správne skopírované

Kód: [Vybrat]

   
for I := Low(aParam) to High(aParam) do
      Params[I].Value := aParam[I];

Aha ho. Nevložil som to ako kód tak mi hranaté zátvorky vyhodilo.
 Je pravda, že zoznam parametrov nenulujem. Doteraz som s tým poblém nemal. Momentáne čumím, že ibTable.RecordCount mi vracia 1 a je ich tam viac. Vôbec sa nenudím   

[pf1957]

Aha ho. Nevložil som to ako kód tak mi hranaté zátvorky vyhodilo.
Je pravda, že zoznam parametrov nenulujem.

Aha. Oni ty IBQuery pri zmene SQL vygeneruji automaticky seznam parametru. Pak to dava smysl a ani nulovat to nemusis.

Momentáne čumím, že ibTable.RecordCount mi vracia 1 a je ich tam viac. Vôbec sa nenudím   

RecordCount bys nemel vubec pouzivat a pokud ano, tak jedine po predchozim FetchAll, pokud je tech dat malo a chces je opravdu nacist. Jinak je treba zeptatse se DB pomoci select count(*)...

[Stanislav Hruška]

Je mi jedno čo použijem. Záznamov je málo a potrebujem ich dať do poľa. Takéto problémy som doteraz nepoznal. Skúsim ten Count. Ale prečo mi nefunguje RecordCount? Je to local DB a okrem čítania s ňou nič nerobím.

A už sa teším ako budem riešiť diakritiku. Mám ju rozhádzanú, ale to má čas. Najprv si chcem o tom niečo prečítať.

[pf1957]

Je mi jedno čo použijem. Záznamov je málo a potrebujem ich dať do poľa. Takéto problémy som doteraz nepoznal. Skúsim ten Count. Ale prečo mi nefunguje RecordCount? Je to local DB a okrem čítania s ňou nič nerobím.

Nefunguje ti ani po tom FetchAll? RecordCount je u SQL databaze obecne nedefinovane a spatne zjistitelne, protoze data se z SQL serveru tahaji po castech a nic jako lokalni DB neexistuje - maximalne SQL server bezici na stejnem stroji, na kterem s Delphi pracujes.

Takze bud musis nejdriv precist vsechno a nebo  vubec RecordCount (krome TClientDataset) nepouzivat.

[Mi.Chal.]

Ale prečo mi nefunguje RecordCount? Je to local DB a okrem čítania s ňou nič nerobím.

K čemu RecordCount chceš? Kdysi se to řešilo na builderu, ono to má snad význam toho, kolik záznamů se dotáhlo. Ty se ale tahají po částech (když voláš Next, tak se můžou dotáhnout další), takže to nemusí mít stejnou hodnotu jako počet záznamů vrácených SQL dotazem. Prakticky to ale asi na nic nepotřebuješ, stačí volat Next dokud není nastaveno Query.Eof. Pokud chceš skutečný počet záznamů, tak přes sql dotaz s Select count.

[pepak]

K čemu RecordCount chceš? Kdysi se to řešilo na builderu, ono to má snad význam toho, kolik záznamů se dotáhlo.

1) Jasný praktický význam má počet záznamů pro uživatele, konkrétně pro zobrazení progressbaru. Přinejmenším pro moje uživatele je, soudě podle toho, s čím se na mě obrací, důležitější vidět, že operace probíhá a jak je daleko, než jak rychle se dohrabe k výsledku. (Jinými slovy, nevadí čekat, ale musí jít odhadnout, jak dlouho ještě budou čekat.)

2) Zjištění počtu záznamů předem je u některých typů dotazů hodně nákladné. Typicky u operací, kde složitý dotaz vytáhne z velké tabulky relativně málo záznamů a ty potom dalšími operacemi upravuji.

Takže v tomto případě Stanislava chápu.

A přidám i řešení, plus mínus - Zeos určitě, a IB myslím taky, mají někde v query property, jestli se má resultset načítat postupně "jak bůh SQL zamýšlel", nebo najednou. Při načtení najednou RecordCount funguje. Jméno property si nepamatuju, resp. používám natolik specifickou sadu komponent (dost stará verze Zeosu, s mnoha in-house úpravami), že nedokážu rozlišit, co ještě je součást dnešního Zeosu a co je relikt minulosti a/nebo náš přílepek.

[pf1957]

2) Zjištění počtu záznamů předem je u některých typů dotazů hodně nákladné. Typicky u operací, kde složitý dotaz vytáhne z velké tabulky relativně málo záznamů a ty potom dalšími operacemi upravuji.
 mnoha in-house úpravami), že nedokážu rozlišit, co ještě je součást dnešního Zeosu a co je relikt minulosti a/nebo náš přílepek.

Ano, dulezite je vedet, ze se neco deje a jak je to daleko. ale pokud je reseni natolik nakladne, tak bys mel informovat o prubehu uz pri vykonavani SQL a k tomu ti RecordCount nepomuze. Takze bud nejakou jalovou animaci, nebo u Ptaka Ohnivaka vypocet do SP  a posilat si z nej notifikace o prubehu pomoci POST_EVENT...
A je-li result set po slozitem vypoctu maly, lze pouzit to FetchAll.

[Stanislav Hruška]

// FetchAll
To nepoznám. Pozriem sa na to.

Spomenul som si, že kedysi kdesi prečítal približne "DB nevie počet riadkov. Musíte použiť metódu Last." Takto to funguje. Platí to pre tabuľky aj dotazy.

Všetky moje úvahy/skúsenosti vychádzajú s Access-u a zásadne lokálnej DB. V Access-e sú mnohé veci automatizované a vo FB si ich musím urobiť ručne. Vidˇ nové vlákno.

Takže jednoznačne odporúčate použiť
FetchAll a/alebo count(*)

a nespoliehať sa na
RecordCount + Last.

Teraz myslím aj na to, že táto aplikácia by teoreticky mohla byť sieťová. A tak sa musím aj správať. Nateraz ťahám tak málo záznamov, že sa vždy načítajú všetky.

Písal som, že počet záznamov potrebujem na nastavenie dĺžky poľa. V tomto prípade načítavam nastavenia programu a pod. a najlepšia práca sa mi vidí práve pomocou poľa. Tak si mnohé veci môžem jednoducho automatizovať pomocou for I := Low(pole) to High(pole) do...
Nastaviť si pole na dĺžku 100 a v prípade potreby ho zväčšovať po skokoch mi v tomto prípade nevyhovuje. Pri práci s ním by som musel kontrolovať, či hodnota v ňom nie je null a použiť Break.
V pri mojom riešení som v prípade chyby upozornený na prekročenie dĺtžky poľa. Čo ma zachráni od prúseru.

Teraz mám dĺžku až 17.

[pepak]

Všetky moje úvahy/skúsenosti vychádzajú s Access-u a zásadne lokálnej DB. V Access-e sú mnohé veci automatizované a vo FB si ich musím urobiť ručne. Vidˇ nové vlákno.

Spíš je to dané tím, že implementace příslušných datasetů některé věci dělá automaticky. Otázka je, nakolik je to dobře - je to jistě pohodlnější, ale současně to znamená, že se vždy provádí časově náročné operace, které mohou být někdy potřeba.

Písal som, že počet záznamov potrebujem na nastavenie dĺžky poľa.

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?

Tak si mnohé veci môžem jednoducho automatizovať pomocou for I := Low(pole) to High(pole) do...

Je to tak zásadně odlišné od for i := 0 to Pred(List.Count) do ... ?

Nastaviť si pole na dĺžku 100 a v prípade potreby ho zväčšovať po skokoch mi v tomto prípade nevyhovuje. Pri práci s ním by som musel kontrolovať, či hodnota v ňom nie je null a použiť Break.

Ano, tak třeba přesně tohle TList dělá docela dobře.

[Stanislav Hruška]

Hm, s TList-om akosi nepracujem. Čo nie je môže byť.
Len jedna otázočka, to pole je viac rozmerné s rôznymi typmi údajov. Zvláda to TList?. Alebo tam budem musieť použiť TObject?

[Mi.Chal.]

1) Jasný praktický význam má počet záznamů pro uživatele, konkrétně pro zobrazení progressbaru. Přinejmenším pro moje uživatele je, soudě podle toho, s čím se na mě obrací, důležitější vidět, že operace probíhá a jak je daleko, než jak rychle se dohrabe k výsledku. (Jinými slovy, nevadí čekat, ale musí jít odhadnout, jak dlouho ještě budou čekat.)

2) Zjištění počtu záznamů předem je u některých typů dotazů hodně nákladné. Typicky u operací, kde složitý dotaz vytáhne z velké tabulky relativně málo záznamů a ty potom dalšími operacemi upravuji.

Jak teda zobrazuješ progressbar, když nevíš, kolik toho bude (RecordCount vždy nevrací hodnotu odpovídající skutečnému počtu) a "Zjištění počtu záznamů předem je u některých typů dotazů hodně nákladné"?

Jinak to zjištění počtu nebude nikdy náročnější, než ty data opravdu tahat. Projde se max. stejné množství dat, ale netahá se na klienta. On to ani nemusí být stejný dotaz - třeba můžeš přes select count zjistit počet záznamů v tabulce odpovídající podmínce, to prezentovat jako počet a dalším dotazem s joiny tahat ty skutečná data.

[Mi.Chal.]

// FetchAll
To nepoznám. Pozriem sa na to.

Spomenul som si, že kedysi kdesi prečítal približne "DB nevie počet riadkov. Musíte použiť metódu Last." Takto to funguje. Platí to pre tabuľky aj dotazy.

Ona je to taky otázka efektivity - pokud taháš data částečně, tak ti DB může vrátit část dat a než je zpracuješ, tak bude k dispozici další část. V opačném případě budeš čekat, než se všechno vrátí, nic nedělat a pak to zpracovávat najednou. Je to asi jako kdyby ti maily nechodily každých pár desítek vteřin, ale přišlo ti to všechno najednou večer.

[Mi.Chal.]

Hm, s TList-om akosi nepracujem. Čo nie je môže byť.
Len jedna otázočka, to pole je viac rozmerné s rôznymi typmi údajov. Zvláda to TList?. Alebo tam budem musieť použiť TObject?

TList interně používá pole, které zvětšuje podle potřeby,ale z pohledu uživatele té třídy tě to nemusí zajímat. Dávaly se tam snad objecty, takže si to můžeš přetypovat na co chceš, můžeš tam dávat třeba další TListy. Většina jazyků dneska podporuje generické typy (Delphi to má snad od nějaké verze umět taky), pak můžeš přímo říct, že to je třeba list stringů a bude ti vracet stringy bez nutnosti něco přetypovávat.

[Stanislav Hruška]

// Jinak to zjištění počtu nebude nikdy náročnější, než ty data opravdu tahat. Projde se max. stejné množství dat, ale netahá se na klienta. On to ani nemusí být stejný dotaz - třeba můžeš přes select count zjistit počet záznamů v tabulce odpovídající podmínce, to prezentovat jako počet a dalším dotazem s joiny tahat ty skutečná data.

Tak tomu rozumiem. A je rozhodnuté. Aj keď tie údaje potrebujem natiahnuť, ale počet si zistím samostatným dotazom, aby som si mekomplikoval ten svoj. (Viď napr. GROUP  BY)

Ten TList si naštudujem.

[pepak]

Jak teda zobrazuješ progressbar, když nevíš, kolik toho bude (RecordCount vždy nevrací hodnotu odpovídající skutečnému počtu) a "Zjištění počtu záznamů předem je u některých typů dotazů hodně nákladné"?

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á.

Jinak to zjištění počtu nebude nikdy náročnější, než ty data opravdu tahat.

To jistě ne, ale pokud je N dostatečně velké, tak 2*N je o hodně větší než N+1...

Projde se max. stejné množství dat, ale netahá se na klienta.

V ideálním případě ano. Podle selského rozumu ano. V praxi někdy ne. Typicky, pokud původní dotaz obsahuje agregace.

On to ani nemusí být stejný dotaz - třeba můžeš přes select count zjistit počet záznamů v tabulce odpovídající podmínce, to prezentovat jako počet a dalším dotazem s joiny tahat ty skutečná data.

Jistě. V extrémních případech mi přijde lepší použít jednoduchý dotaz, který počet záznamů nadhodnotí, a pak holt ProgressBar skončí na na 100 procentech, ale na 80ti.

[Mi.Chal.]

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á.

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.

Projde se max. stejné množství dat, ale netahá se na klienta.

V ideálním případě ano. Podle selského rozumu ano. V praxi někdy ne. Typicky, pokud původní dotaz obsahuje agregace.

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]

Písal som, že počet záznamov potrebujem na nastavenie dĺžky poľa.

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?

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]

Takže jednoznačne odporúčate použiť FetchAll a/alebo count(*)

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.

...
Musíte použiť metódu Last." Takto to funguje. Platí to pre tabuľky aj dotazy.a nespoliehať sa na
RecordCount + Last.

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 ...