TFDTable + OnFilterRecord

[ShaneZB]

Ahoj všem.
Stále pracuji na migraci z BDE na FireDAC. Upravovaná aplikace používá jako startovací zobrazení aktualizací přehled jejich záznamů pomocí TTable (nově TFDTable). Pro rozumnou rychlost načtení obsahu jsem nastavil FetchOptions.Mode na fmOnDemand a FetchOptions.RowsetSize na 100. To je OK. Ale jakmile použiju filtrování přes OnFilterRecord, tak se to načítá hrozně dlouho. Můj odhad je, že to ignoruje nastavení FetchOptions.Mode a dělá FetchAll.
Pokud nastavím FetchOptions.RecsMax, tak to je sice rychlé, ale výsledek je nekompletní a nepřišel jsem na to, jak zajistit, aby se načetlo vše.
OnFilterRecord není možné přestat používat - to by znamenalo příliš velké úpravy na mnoha místech.

Moc prosím o nakopnutí a předem děkuji.

[Jan Fiala]

Proti jaké databázi pracuješ s daty?
Jestli s nějakým SQL serverem, pak tam TTable nemá (až na velmi opodstatněné vyjímky co dělat). A ano, je to hromada práce a musíš to celé přepsat.

[mbx]

Ano, kvuli filtrovani se stahnou vsechny zaznamy, a to obvykle nechces. Na podobny problem take zrejme narazis, pokud se pokusis pouzivat v datasetech vestavenou master-detail funkcionalitu. Na oboji je proto lepsi pouzivat podminku (where) v SQL dotazu.

[Jirka]

Na podobny problem take zrejme narazis, pokud se pokusis pouzivat v datasetech vestavenou master-detail funkcionalitu. Na oboji je proto lepsi pouzivat podminku (where) v SQL dotazu.

To mě zaujalo. Máš to nějak exaktně ověřené ?

[pf1957]

OnFilterRecord, tak se to načítá hrozně dlouho. Můj odhad je, že to ignoruje nastavení FetchOptions.Mode a dělá FetchAll.

Odhad je spravny: OnFilterRecord je funkcionalita clienta, takze aby to spravne fungovalo, musi na clienta dostat vsechny zaznamy.
Jedine, co se s tim da udelat, je podminku z filtru presunout na server (do SQL dotazu) a jak pise JF, bez prace to nebude.

[ShaneZB]

Proti jaké databázi pracuješ s daty?
Jestli s nějakým SQL serverem, pak tam TTable nemá (až na velmi opodstatněné vyjímky co dělat). A ano, je to hromada práce a musíš to celé přepsat.

Je to proti FireBird databázi. Přes BDE to fungovalo dobře/použitelně - taky se stahovalo vše, ale asi nějak optimálněji. To fakt nejde nějak obejít? = zařídit, aby se to načítalo dávkově, tak aby měl uživatel pocit, že nemusí čekat?

[vandrovnik]

Je to proti FireBird databázi. Přes BDE to fungovalo dobře/použitelně - taky se stahovalo vše, ale asi nějak optimálněji. To fakt nejde nějak obejít? = zařídit, aby se to načítalo dávkově, tak aby měl uživatel pocit, že nemusí čekat?

Když už se to stejně přepisuje, udělal bych to radši rovnou pořádně, tj. filtrovat na serveru.

[ShaneZB]

OK, přesunout na server. ALE je TFDTable.Filter plně kompatibilní s SQL WHERE? Pod BDE to tak není (má omezené možnosti - asi kvůli Paradoxu) a proto je to realizováno přes OnFilterRecord.
Nebo má TFDTable ještě jinou možnost filtrace, která mi uniká?

[pf1957]

OK, přesunout na server. ALE je TFDTable.Filter plně kompatibilní s SQL WHERE? Pod BDE to tak není (má omezené možnosti - asi kvůli Paradoxu) a proto je to realizováno přes OnFilterRecord.

Plne kompatibilni nebude uz s podstaty, ze kazdy RDMBS ma trochu jine moznosti. Co umi filtr je v dox: http://docwiki.embarcadero.com/RADStudio/Sydney/en/Setting_the_Filter_Property a jedine, co tam pisi, ze filtr umi pouzit Field ve vyrazech jako operand, zatimco u lokalnich DB jako Paradox ne, a proto se pouziva OnFilterRecord. Takze zalezi, co v tom filtru delas.

Ale jinak nevim, ja nikdy BDE, TTable ani filtraci na strane klienta nikdy nepouzil, vzdycky jsme pri zmene filtru sestavovali SQL prikaz a ptali se serveru a vzdycky to pak byl fetch on demand.

[ShaneZB]

Našel jsem virtuální proceduru GetCustomWhere. Má s tím někdo zkušenosti?

[mbx]

Na podobny problem take zrejme narazis, pokud se pokusis pouzivat v datasetech vestavenou master-detail funkcionalitu. Na oboji je proto lepsi pouzivat podminku (where) v SQL dotazu.

To mě zaujalo. Máš to nějak exaktně ověřené ?

Uz kdysi davno, kdyz jsem prechazel z Paradoxu na Delphi+FB, jsem vazbu M-D, tak jak je vestavena do beznych datasetu (pouzivam IBX) vyhodnotil jako nepouzitelnou pro vetsi data. Nacte se cely detail (to muzou byt statisice radku i vic), a pak se filtruje. Bylo to pomale. Napsal jsem si pak vlastniho potomka datasetu, ktery mimo jine i toto vyresi efektivne pomoci SQL proti serveru.

[Jan Fiala]

Uz kdysi davno, kdyz jsem prechazel z Paradoxu na Delphi+FB, jsem vazbu M-D, tak jak je vestavena do beznych datasetu (pouzivam IBX) vyhodnotil jako nepouzitelnou pro vetsi data. Nacte se cely detail (to muzou byt statisice radku i vic), a pak se filtruje. Bylo to pomale. Napsal jsem si pak vlastniho potomka datasetu, ktery mimo jine i toto vyresi efektivne pomoci SQL proti serveru.

Na to stačí událost - při změně záznamu v master spustíš dotaz pro detail. je to sice pomalejší, než když máš komplet detail data načtená na klientovi, ale při konkurenčním přístupu více klientů k DB máš zajištěno, že zobrazuješ aktuální data. Nehledě na přistup po pomalejší síti (VPN přes internet apod.)

[mbx]

Na to stačí událost - při změně záznamu v master spustíš dotaz pro detail. je to sice pomalejší, než když máš komplet detail data načtená na klientovi, ale při konkurenčním přístupu více klientů k DB máš zajištěno, že zobrazuješ aktuální data. Nehledě na přistup po pomalejší síti (VPN přes internet apod.)

Jasny, presne tak to mam udelano - jen jsem si mj. toto vestavel do vlastniho potomka, abych nemusel na kazdem formu porad dokola psat to same. Uvnitr je timer, ktery otvira detail s nejakym malym zpozdenim, takze pri prochazeni gridem s master zaznamy se detail otevre az kdyz uzivatel zastavi. Ale jde to samozrejme stejne snadno udelat i "rucne", s pouzitim beznych komponent.