Odpověď

Jméno:
E-mail:
Předmět:
Ikona zprávy:

Ověření:
Kolik je šest plus čtyři (slovem):

Zkratky: stiskněte shift+alt+s pro odeslání nebo shift+alt+p pro prohlédnutí


Shrnutí tématu

Poslal: maca2me
« kdy: 09-01-2018, 12:00:54 »

Nakonec to přes clientdatasety nešlo, tak jsem raději převedl bloby v DB.

Díky
Poslal: Stanislav Hruška
« kdy: 08-01-2018, 15:08:40 »

Nechcelo sa mi točiť kolieskom myši ;)
Poslal: Delfin
« kdy: 08-01-2018, 15:06:06 »


Citace
Jen pro Firebird se budes muset trochu potrapit s definici sloupce autoinkrementalniho klice.
Oni používajú FB2.5 :) Ale priamo v FDQuery sa to dá nastaviť. Priraďuje sa tam generátor.

Vse potrebne (automaticke rozpoznani i manualni definice) je popsane v tom manualu (pro verzi 3.0 a ostatni, tedy verze starsi) ;)
Poslal: Stanislav Hruška
« kdy: 08-01-2018, 15:01:01 »


Citace
Jen pro Firebird se budes muset trochu potrapit s definici sloupce autoinkrementalniho klice.
Oni používajú FB2.5 :) Ale priamo v FDQuery sa to dá nastaviť. Priraďuje sa tam generátor.
Poslal: Delfin
« kdy: 08-01-2018, 14:12:04 »

My používáme DBGrid a DBNavigátor pro přímou úpravu dat. To jde použít pouze FDQuery i pro zpětné promítnutí změn do DB? Jen kvůli tomu používáme clientDataSet + dataSource

Ano, to se da. Jen pro Firebird se budes muset trochu potrapit s definici sloupce autoinkrementalniho klice.
Poslal: maca2me
« kdy: 08-01-2018, 13:51:40 »

My používáme DBGrid a DBNavigátor pro přímou úpravu dat. To jde použít pouze FDQuery i pro zpětné promítnutí změn do DB? Jen kvůli tomu používáme clientDataSet + dataSource
Poslal: Delfin
« kdy: 08-01-2018, 13:46:35 »

Díky za rady, oba máte pravdu. Tato tabulka obsahuje typ BLOB a proto nám to pomohlo pro query (to už je rychlé). DB jsme převzali a je tam textový popis ve formátu BLOB :-( to jsme přehlédli. Zatím FDMemory dataset. Snad už to rozlouskneme.

Díky za pomoc.

Zvaz i nastaveni toho RowsetSize. By default je jen 50 zaznamu (presneji tedy hodnota C_FD_DefRowSetSize). Nevim kolik ma Firebird optimum (snad velikost v bytech TcpRemoteBufferSize?), ale s vychozim nastavenim by ses dockal prenosu po 50 zaznamech.

A konecne, nevidim duvod proc pouzivat dataset provider. Ten je urceny spis pro transformaci dat z klientskeho datasetu. Ten sbira zmeny a jejich aplikaci je provider prenese v patricnem formatu na server. TFDQuery umi cached updates, takze ten klientsky dataset nebo memory table spolu s providerem je navic (a to navic mozna za cenu duplikace zaznamu ve storage protoze bych tipoval ze si jak query objekt tak klientsky dataset nebo memory tabulka budou by default drzet zaznamy v cache separatne - ale to tipuju).
Poslal: maca2me
« kdy: 08-01-2018, 13:21:13 »

Díky za rady, oba máte pravdu. Tato tabulka obsahuje typ BLOB a proto nám to pomohlo pro query (to už je rychlé). DB jsme převzali a je tam textový popis ve formátu BLOB :-( to jsme přehlédli. Zatím FDMemory dataset. Snad už to rozlouskneme.

Díky za pomoc.
Poslal: Delfin
« kdy: 08-01-2018, 13:03:07 »

Zkus:

Kód: Delphi [Vybrat]
  1. FDQuery.FetchOptions.Mode := fmAll; // prenos vsech zaznamu resultsetu pri otevreni kurzoru (mozna optimalizace kurzoru)
  2. FDQuery.FetchOptions.CursorKind := ckDefault; // neni nutne nastavovat explicitne (pro Firebird by mel byt vychozim pri ckAutomatic)
  3. FDQuery.FetchOptions.RowsetSize := 1000; // pocet zaznamu prenesenych v packetu na jeden routrip (1k je pomerne vysoka hodnota)
  4. FDQuery.FetchOptions.Items := FDQuery.FetchOptions.Items - [fiBlobs]; // neprenaset automaticky BLOB streamy

Vice viz. General Usage Cases.
Poslal: Radek Červinka
« kdy: 08-01-2018, 12:57:14 »


Jak pises tak davas select * from tabulka, nejsou tam nejake bloby? Zkousel jsi vyjmenovat sloupce, zacit od jednoho a pridavat?
Poslal: maca2me
« kdy: 08-01-2018, 12:55:25 »

Ještě jsme vyzkoušeli nastavení v FDQuery - items to fetch a zakázali metadata a další položky. V query to teď běží rychle. Teď to vypadá ještě na ten clientDataSet. Zkusíme nastavení clientDataSet případně memory dataset jak píšeš.

Díky moc
Poslal: Radek Červinka
« kdy: 08-01-2018, 12:54:41 »

No a nejaky jednoduchy select (treba SELECT 1) ti projde ve stejnem datasetu rychle? Snazim se zjistit, zda nemas nejake problemy s nastavenim te query?
Poslal: maca2me
« kdy: 08-01-2018, 12:42:17 »

Díky za rady.

Zkusil jsem vytvořit jen FDQuery bez clientdataset a spustil dotaz - stále stejné. Všechny záznamy potřebujeme přenést rovnou, on demand nevyužijeme. U komponent necháváme kromě nastavení DB connection všechno v default nastavení. Do podrobnějšího nastavení se nepouštíme a u menších DB nám to problémy nedělá.

Pomalejší je to i na Windows 7 při lokálním použití. Když to omezíme třeba na 1000 záznamů, stejně to trvá několik sekund - to je divné.
Poslal: Radek Červinka
« kdy: 08-01-2018, 12:14:58 »

Sundal bych ten client dataset. Jinak tezko radit. Chces prenest vsechny zaznamy nebo mit prenos "on demand"? Jake maji komponenty nastaveni?

Přesně u jednoho co jsem mu upravoval program měl stejný problém. ClientDataset měl nastaven Sort, takže to stále snažil nějak přeřazovat. Mimochodem proč nepoužiješ memory dataset z firedacu?

Zkus jen pro test mít jen query, která není na nic napojená a zkus za jak dlouho se ti načtou data.
Poslal: Delfin
« kdy: 08-01-2018, 12:12:14 »

Ahoj,

prosím vás o radu. Řeším již nějakou dobu pomalé odezvy a načítání dat přes komponenty TIBconnection a TFDconnection. Všechna data v aplikaci spravuji pomocí DBGrid a DB navigator. Používám komponenty - connection - transaction - query - dataSetProvider - clientDataSet  a pokud mám DBgrid tak i clientDataSet. Když načítám větší počet řádků (nic extrémního - cca 17 000 záznamů), provádí se mi SQL minuty (select * from tabulka), nic složitého. I když v komponentě query zkouším select, je to stejné - čili bez nějakého méno kódu.

Hlavní vodítko, že je něco špatně v nastavení komponent je fakt, že v IBExpertu se těch 17 000 záznamů načte téměř okamžitě (fetch all). Databáze je na síti ale zkoušel jsem i lokální - tam je to rychlejší ale stále veliký rozdíl mezi IBexpertem a delphi. Firebird používáme i v ostatních aplikacích a tento problém nemáme - jsou to však DB, kde je v tabulce max několik stovek záznamů. Nenarazili jste někdo na podobný problém? Nemáte nějaký tip na co se zaměřit? 

DB je firebird 2.5, "server" je Windows 10.

Díky moc předem za rady.

Sundal bych ten client dataset. Jinak tezko radit. Chces prenest vsechny zaznamy nebo mit prenos "on demand"? Jake maji komponenty nastaveni?

Problemem to nebude, pises-li ze to resis "nejakou dobu", ale pro Windows 10 uz vysel patch pro procesory Intel (pro ostatni verze bude kumulativni zitra), takze je mozne na stroji s procesory Intel cekat mozne zpomale pri jeho aplikaci.