firedac problem s pamatou

[pf1957]

nad jednym stlpcom stupa pamat tiez, ale samozrejme pomalsie. mrknem na ten debugger

A v jakem stavu mas transakci? Nezustava ti otevrena a nesysluji se ti mak vsechna data?

My na vsech platformach a se vsemi typy RDMBS vzdycky cteme data pod explicitne nastartovanou a commitnutou read only transakci.

[wajco]

nad jednym stlpcom stupa pamat tiez, ale samozrejme pomalsie. mrknem na ten debugger

A v jakem stavu mas transakci? Nezustava ti otevrena a nesysluji se ti mak vsechna data?

My na vsech platformach a se vsemi typy RDMBS vzdycky cteme data pod explicitne nastartovanou a commitnutou read only transakci.

nerobim to v transakcii

[hlucheucho]

"Sypeš to tam" aniž bys řešil odezvu DB. DB může dotaz zpracovávat delší dobu než za jakou vytvoříš a pošleš nový dotaz. Převzal bych přijatá data a pak bych poslal další dotaz. Obsluhuj události FDQuery (myslím AfterOpen). Takto jsem pracoval s MySQL, běželo to celý den bez nárůstu paměti.

Pokud používáš parametrický dotaz, SQLText stačí vytvořit jen jednou před vstupem do cyklu.

Komunikaci s DB může být vhodnější umístit do samostatného vlákna.

hu

[wajco]

"Sypeš to tam" aniž bys řešil odezvu DB. DB může dotaz zpracovávat delší dobu než za jakou vytvoříš a pošleš nový dotaz. Převzal bych přijatá data a pak bych poslal další dotaz. Obsluhuj události FDQuery (myslím AfterOpen). Takto jsem pracoval s MySQL, běželo to celý den bez nárůstu paměti.

Pokud používáš parametrický dotaz, SQLText stačí vytvořit jen jednou před vstupem do cyklu.

Komunikaci s DB může být vhodnější umístit do samostatného vlákna.

hu

v BDE to ide  bez narastu pamati, to len firedac ma takyto problem

[hlucheucho]

Když posílám select, očekávám data. Kromě dotazů se tam mohou hromadit i přijatá data. Vždycky jsem zpracoval odezvu DB a neměl jsem problém s Memory Leak ani u FireDAC.

hu

[pf1957]

nerobim to v transakcii

No to neni zcela urcite pravda - komunikace s RDMBS urcite pod nejakou transakci bezi. Takze pouzivas nejakou default txn z FireDac, ktera je buhvi jak nastavena.

Osobne bych doporucoval transakce neignorovat a i kdyz je to nepohodlne, tak si je pekne explicitne ridit.

[wajco]

nerobim to v transakcii

No to neni zcela urcite pravda - komunikace s RDMBS urcite pod nejakou transakci bezi. Takze pouzivas nejakou default txn z FireDac, ktera je buhvi jak nastavena.

Osobne bych doporucoval transakce neignorovat a i kdyz je to nepohodlne, tak si je pekne explicitne ridit.

tak jedine nastavenie txOptions ktore som zmenil su DisconnectAction xdRollback a Isolation xiDirtyRead

[pf1957]

v BDE to ide  bez narastu pamati, to len firedac ma takyto problem

S BDE bych zrovna nic nesrovnaval, tak je spis divne, ze to vubec neco dela :-)

BTW, jaky je smysl dotazu, ktery nic s vytazenymi daty nedela? Normalne by za open nasledovalo neco jako

Kód: Delphi [Vybrat]

1. Query1.Open;
2. while not Query1.Eof do
3.   begin
4.      .... Query.Fields[x].AsXxxx;
5.      Query1.Next;
6.   end;
7.  

[Stanislav Hruška]

No, kompletný kód by mal byť takýto:

Kód: Delphi [Vybrat]

1. procedure TForm1.Button1Click(Sender: TObject);
2. var i: Integer;
3.   q: TFDQuery;
4. begin
5.   i:= 0;
6.   Randomize;
7.   q := TFDQuery.Create(self);
8.   q.Connection := SomeConnection;
9.   q.Trnasaction := SomeBasicTransaction;
10.   q.SQL.Text := 'select * from tab where i_tab = :p';
11.  
12.   while True do
13.     begin
14.       q.Close:  // Moja skúsenosť.
15.       q.ParamByName('p').AsInteger := Random(182064);
16.       inc(i);
17.       Label14.Caption := i.ToString();
18.       Application.ProcessMessages;
19.       q.Open();
20.     end;
21. end;
22.  

Predpokladám, že to je len tak narýchlo čosi čiastočne opísané. Ako by som to robil ja
Osobne ma zaujíma, že ak dáš

Kód: Delphi [Vybrat]

1. Label14.Caption := i.ToString() + ' - ' + SomeField.AsString;
2.  

či sa bude meniť hodnota poľa.

[wajco]

v BDE to ide  bez narastu pamati, to len firedac ma takyto problem

S BDE bych zrovna nic nesrovnaval, tak je spis divne, ze to vubec neco dela :-)

BTW, jaky je smysl dotazu, ktery nic s vytazenymi daty nedela? Normalne by za open nasledovalo neco jako

Kód: Delphi [Vybrat]

1. Query1.Open;
2. while not Query1.Eof do
3.   begin
4.      .... Query.Fields[x].AsXxxx;
5.      Query1.Next;
6.   end;
7.  

to je len ilustracny priklad

[pf1957]

to je len ilustracny priklad

To je sice vyborny, ale na zaklade ceho myslis, ze dostatnes relevantni odpoved, kdyz jsi apriory udelal rozhodnuti o tom, kde ten memory leak urcite neni 

[wajco]

to je len ilustracny priklad

To je sice vyborny, ale na zaklade ceho myslis, ze dostatnes relevantni odpoved, kdyz jsi apriory udelal rozhodnuti o tom, kde ten memory leak urcite neni 

ved som skusil spustit len tento zdrojak a som videl ako mi pamat stupa, tak naco tam budem dohadzovat ostatny kod...

[pf1957]

ved som skusil spustit len tento zdrojak a som videl ako mi pamat stupa, tak naco tam budem dohadzovat ostatny kod...

No protoze ten kod ma - eufemisticky receno - spekulativni charakter a jak jsem prubezne psal, vykazuje radu vlastnosti, ktere se mi nelibi a ktere bychom nikdy nenapsali. A protoze pouzivame databaze zpusobem, jaky se predpoklada, tak jsme nikdy nehonili takovouhle ducharinu. A pod FireDac jsem pred lety portoval docela rozsahlou rodinu aplikaci z FIB+, kterou jsem ani sam nepsal. A na zadne problemy si nepamatuju.

Proto by mne zajimalo, jak se to bude chovat, kdyz se s tim pracuje radnym zpusobem.

[hlucheucho]

V obsluze události kliknutí na tlačítko bych si odpustil nekonečnou smyčku a ProcessMessage. Opakování select jde udělat i bez nich.

hu

[wajco]

V obsluze události kliknutí na tlačítko bych si odpustil nekonečnou smyčku a ProcessMessage. Opakování select jde udělat i bez nich.

hu

nekonecna slucka je na znazornnie kvoli tej narastajucej pamati
process je kvoli refreshu labelu