Forum Delphi.cz

Delphi => FireDAC => Téma založeno: ShaneZB 24-09-2020, 09:09:06

Název: TFDTable + OnFilterRecord
Přispěvatel: ShaneZB 24-09-2020, 09:09:06
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.
Název: Re:TFDTable + OnFilterRecord
Přispěvatel: Jan Fiala 24-09-2020, 09:35:13
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.
Název: Re:TFDTable + OnFilterRecord
Přispěvatel: mbx 24-09-2020, 10:31:06
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.
Název: Re:TFDTable + OnFilterRecord
Přispěvatel: Jirka 24-09-2020, 10:34:26
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é ?
Název: Re:TFDTable + OnFilterRecord
Přispěvatel: pf1957 24-09-2020, 10:37:33
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.
Název: Re:TFDTable + OnFilterRecord
Přispěvatel: ShaneZB 24-09-2020, 10:48:19
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?
Název: Re:TFDTable + OnFilterRecord
Přispěvatel: vandrovnik 24-09-2020, 11:01:34
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.
Název: Re:TFDTable + OnFilterRecord
Přispěvatel: ShaneZB 24-09-2020, 11:18:45
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á?
Název: Re:TFDTable + OnFilterRecord
Přispěvatel: pf1957 24-09-2020, 12:14:57
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 (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.
Název: Re:TFDTable + OnFilterRecord
Přispěvatel: ShaneZB 24-09-2020, 13:03:53
Našel jsem virtuální proceduru GetCustomWhere. Má s tím někdo zkušenosti?
Název: Re:TFDTable + OnFilterRecord
Přispěvatel: mbx 24-09-2020, 14:05:01
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.
Název: Re:TFDTable + OnFilterRecord
Přispěvatel: Jan Fiala 25-09-2020, 08:30:16
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.)
Název: Re:TFDTable + OnFilterRecord
Přispěvatel: mbx 25-09-2020, 09:45:16
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.