🚀 go-pugleaf

On Tue, 21 Nov 2017 07:10:46 -0800 (PST), ExM wrote:

> Jak powinienem zrobić to prawidłowo aby nie dochodziło do konflitów między watkami?

Prawidłowo powinieneś w wątku utworzyć connection, wykonać query, a wyniki
lub fakt ich gotowości przekazać do formy za pomocą Synchronize() lub np.
PostMessage().
Absolutnie nie powinieneś mieć jednego query dostępnego i w wątku i w
formie.

-- 
pozdrawiam
Roman Tyczka

W dniu wtorek, 21 listopada 2017 16:22:47 UTC+1 użytkownik Roman Tyczka napisał:
> On Tue, 21 Nov 2017 07:10:46 -0800 (PST), ExM wrote:
> 
> > Jak powinienem zrobić to prawidłowo aby nie dochodziło do konflitów między watkami?
> 
> Prawidłowo powinieneś w wątku utworzyć connection, wykonać query, a wyniki
> lub fakt ich gotowości przekazać do formy za pomocą Synchronize() lub np.
> PostMessage().
> Absolutnie nie powinieneś mieć jednego query dostępnego i w wątku i w
> formie.

Problem w tym że na wynikach tego query opiera się wiele elementów wizualnych (listy rozwijane, filtry itp)
Jeśli więc utworzę obiekt w wątku jak miałby on dalej istnieć i odświeżać wyniki jeśli byłby połączony przez TDataSource z formą główną?

Sorry - może nie do końca zrozumiałem jak by to miało działać.

Inna sprawa że jeśli pilnuję aby wszystko co się dzieje z poziomu wątku pobocznego na formie głównej było synchronizowane to jakie jest zagrożenie takiego działania?

On Tue, 21 Nov 2017 08:59:52 -0800 (PST), ExM wrote:

>>> Jak powinienem zrobić to prawidłowo aby nie dochodziło do konflitów między watkami?
>> 
>> Prawidłowo powinieneś w wątku utworzyć connection, wykonać query, a wyniki
>> lub fakt ich gotowości przekazać do formy za pomocą Synchronize() lub np.
>> PostMessage().
>> Absolutnie nie powinieneś mieć jednego query dostępnego i w wątku i w
>> formie.
> 
> Problem w tym że na wynikach tego query opiera się wiele elementów wizualnych (listy rozwijane, filtry itp)
> Jeśli więc utworzę obiekt w wątku jak miałby on dalej istnieć i odświeżać wyniki jeśli byłby połączony przez TDataSource z formą główną?

Musisz zmienić myślenie jeśli nie chcesz za chwilę rozgryzać "dziwnych
problemów u klientów". Dane z tego query możesz wszak przepakować w obiekty
i te obiekty przekazać do main threada. Miliony możliwości żeby to zrobić.

> Sorry - może nie do końca zrozumiałem jak by to miało działać.

Sprawnie i bezbłędnie.
 
> Inna sprawa że jeśli pilnuję aby wszystko co się dzieje z poziomu wątku pobocznego na formie głównej było synchronizowane to jakie jest zagrożenie takiego działania?

Robisz sobie sam pod górę. Nie po to się wątków używa, żeby potem musieć
wszystko blokować synchronizacją. Przemyśl jakąś metodę przekazywania
danych z wątka roboczego do GUI i problem rozwiązany.

-- 
pozdrawiam
Roman Tyczka

> 
> Mam sobie bazę danych MSSQL (komponenty Devart - choć to raczej bez znaczenia)
> Dane odświeżam sobie w osobnym wątku
>    query.Active:=False; / query.Active:=True;  czy tam: query.Refresh;
>
 > (...)>
> Jak powinienem zrobić to prawidłowo aby nie dochodziło do konflitów między watkami?
> 
A może prymitywnie nie wykonywać Refresh w wątku tylko
timerem na głównej formie?

Pozdrowienia,
MKi

On Thu, 23 Nov 2017 08:45:40 +0100, MKi wrote:

>> Mam sobie bazę danych MSSQL (komponenty Devart - choć to raczej bez znaczenia)
>> Dane odświeżam sobie w osobnym wątku
>>    query.Active:=False; / query.Active:=True;  czy tam: query.Refresh;
>>
>  > (...)>
>> Jak powinienem zrobić to prawidłowo aby nie dochodziło do konflitów między watkami?

> A może prymitywnie nie wykonywać Refresh w wątku tylko
> timerem na głównej formie?
> 
> Pozdrowienia,
> MKi

A co jeśli zapytanie wykonuje się kilka sekund?

-- 
pozdrawiam
Roman Tyczka

> > 
> A może prymitywnie nie wykonywać Refresh w wątku tylko
> timerem na głównej formie?

Opanowałem problem w ten sposób że w formie głównej stworzyłem tablicę obiektów tego typu: 

Metody : Array of TDatasetNotifyEvent;

W wątku wyłączam metody tak jak opisałem na początku a dodatkowo dodaje do tablicy Metody - metodę która chciała się wykonać w wątku (po zakończeniu wykonywania zapytania) ale została wyłączona czyli AfterRefresh lub AfterOpen.

W formie głównej jest timer odpalany co 100ms który sprawdza czy są jakieś metody w tablicy i je wykonuje. 
Dzięki temu wątki zajmują się tylko wykonaniem zapytania a forma główna wykonuje resztę (metody AfterOpen/ AfterRefresh) które ingerują w treści na formie głównej a nie są dużym obciążeniem dla wątku głównego aplikacji.

Tak na szybko takie rozwiązanie mi wystarcza.

On Thu, 23 Nov 2017 13:13:44 -0800 (PST), ExM wrote:

>> A może prymitywnie nie wykonywać Refresh w wątku tylko
>> timerem na głównej formie?
> 
> Opanowałem problem w ten sposób że w formie głównej stworzyłem tablicę obiektów tego typu: 
> 
> Metody : Array of TDatasetNotifyEvent;
> 
> W wątku wyłączam metody tak jak opisałem na początku a dodatkowo dodaje do tablicy Metody - metodę która chciała się wykonać w wątku (po zakończeniu wykonywania zapytania) ale została wyłączona czyli AfterRefresh lub AfterOpen.
> 
> W formie głównej jest timer odpalany co 100ms który sprawdza czy są jakieś metody w tablicy i je wykonuje. 
> Dzięki temu wątki zajmują się tylko wykonaniem zapytania a forma główna wykonuje resztę (metody AfterOpen/ AfterRefresh) które ingerują w treści na formie głównej a nie są dużym obciążeniem dla wątku głównego aplikacji.

https://goo.gl/LbX4RY

-- 
pozdrawiam
Roman Tyczka

> Tak na szybko takie rozwiązanie mi wystarcza.
> 

Takie rozwiązania "na szybko" prędzej czy później mszczą się dodatkowymi 
godzinami na szukanie AV !

Spróbuj zrobić to tak jak zaproponował Pan Roman w pierwszej odpowiedzi.

M

> > A może prymitywnie nie wykonywać Refresh w wątku tylko
> > timerem na głównej formie?
>
> Opanowałem problem w ten sposób że w formie głównej stworzyłem tablicę obiektów tego typu:
>
> Metody : Array of TDatasetNotifyEvent;
>
> W wątku wyłączam metody tak jak opisałem na początku a dodatkowo dodaje do tablicy Metody - metodę
> która chciała się wykonać w wątku (po zakończeniu wykonywania zapytania) ale została wyłączona
> czyli AfterRefresh lub AfterOpen.

> W formie głównej jest timer odpalany co 100ms który sprawdza czy są jakieś metody w tablicy i je
> wykonuje.
> Dzięki temu wątki zajmują się tylko wykonaniem zapytania a forma główna wykonuje resztę (metody
> AfterOpen/ AfterRefresh) które ingerują w treści na formie głównej a nie są dużym obciążeniem dla
> wątku głównego aplikacji.
>
> Tak na szybko takie rozwiązanie mi wystarcza.

Jeśli ten DataSet odświeżany w wątku ma jakiekolwiek połączenie przez DataSource z kontrolkami 
wizualnymi
w głównym wątku, to wszystkie zdarzenia z DataSet docierają bez synchronizacji do kontrolek 
wizualnych
niezależnie od tego, jakie zdarzenia odłączysz w wątku. Reszty domyśl się sam :-)

-- 
pozdrowienia
Krzysztof Szyszka, X-Files Software
Developer of X-DBGrid Component
Embarcadero Technology Partner
http://www.x-files.pl/
Join to "Delphi X-DBGrid Component Community"
https://plus.google.com/#communities/100842098152269100547 

W dniu 24.11.2017 o 23:00, Krzysztof Szyszka pisze:
>> Tak na szybko takie rozwiązanie mi wystarcza.
> 
> Jeśli ten DataSet odświeżany w wątku ma jakiekolwiek połączenie przez 
> DataSource z kontrolkami wizualnymi
> w głównym wątku, to wszystkie zdarzenia z DataSet docierają bez 
> synchronizacji do kontrolek wizualnych
> niezależnie od tego, jakie zdarzenia odłączysz w wątku. Reszty domyśl 
> się sam :-)

I bigos mamy gotowy :)

Do autora wątku: zrób jak Pisał Roman Tyczka bo Twoje rozwiązanie jest 
do niczego to że działa a właściwie wydaje się Tobie że działa :) bo to 
zemści się na Tobie wcześniej czy później. Jeżeli dodajesz gdzieś lub 
zmieniasz rekordy w DB to może być to jeszcze bardziej bolesne dla 
Ciebie. Wątki są fajne ale jak się wie jak się ich używać. Ty swoją 
wiedze jeszcze musisz doszkolić w tej materii (I nie odbierz tego jako 
negatywną uwagę, raczej jako przestrogę)

Pozdrawiam
J-23

On Fri, 24 Nov 2017 23:00:48 +0100, Krzysztof Szyszka wrote:

> Reszty domyśl się sam :-)

Właśnie obawiam się, że domyślenie wymaga pewnej wiedzy o tym co to są
wątki i z czym się je gryzie, a tego ewidentnie OP brakuje, co gorsza nie
planuje jak widać tego braku wyrównać, lecz łatać na kolanie byle
jakośtamcośtam działało.

-- 
pozdrawiam
Roman Tyczka

Mam pytanie, czy smartFetch masz ustawione na true??

pozdrawiam Roland

W dniu piątek, 24 listopada 2017 13:00:25 UTC+1 użytkownik mmm napisał:
> Takie rozwiązania "na szybko" prędzej czy później mszczą się dodatkowymi 
> godzinami na szukanie AV !
> 
> Spróbuj zrobić to tak jak zaproponował Pan Roman w pierwszej odpowiedzi.

Tak oczywiście zdaję sobie sprawę że będę musiał to przerobić. 
Teraz musiałem rozwiązać problem a docelowo chcę przygotować rozwiązanie jak to robić zgodnie ze sztuką.

Przede wszystkim szukam informacji jak to powinno być zaprojektowane.
Jeśli macie jakieś materiały jak powinienem tworzyć tego typu obiekty w trybie wielowątkowym i łączyć je z kontrolkami wizualnymi podeślijcie proszę info. 

> Jeśli ten DataSet odświeżany w wątku ma jakiekolwiek połączenie przez DataSource z kontrolkami 
> wizualnymi
> w głównym wątku, to wszystkie zdarzenia z DataSet docierają bez synchronizacji do kontrolek 
> wizualnych
> niezależnie od tego, jakie zdarzenia odłączysz w wątku. Reszty domyśl się sam :-)

DataSet jest obiektem znajdującym się na formie głównej. Odświeżany jest przez wątek i na ten czas żadne zdarzenia się nie wykonują.
Po odświeżeniu DataSet'a zdarzenia zaczynają działać ale one już nie wymagają synchronizacji bo nie są wykonywane w osobnym wątku.

W dniu sobota, 25 listopada 2017 11:54:42 UTC+1 użytkownik roland....@gmail.com napisał:
> Mam pytanie, czy smartFetch masz ustawione na true??
> 
> pozdrawiam Roland

Nie, mam False

W dniu niedziela, 26 listopada 2017 13:17:57 UTC+1 użytkownik ExM napisał:
> W dniu sobota, 25 listopada 2017 11:54:42 UTC+1 użytkownik roland....@gmail.com napisał:
> > Mam pytanie, czy smartFetch masz ustawione na true??
> > 
> > pozdrawiam Roland
> 
> Nie, mam False

spróbuj przełączyć na true, miałem kiedyś problem z Unidaciem przy kilku wątkach, to pomogło.

On Sun, 26 Nov 2017 14:39:51 -0800 (PST), roland.rusiecki@gmail.com wrote:

> W dniu niedziela, 26 listopada 2017 13:17:57 UTC+1 użytkownik ExM napisał:
>> W dniu sobota, 25 listopada 2017 11:54:42 UTC+1 użytkownik roland....@gmail.com napisał:
>>> Mam pytanie, czy smartFetch masz ustawione na true??
>>> 
>>> pozdrawiam Roland
>> 
>> Nie, mam False
> 
> spróbuj przełączyć na true, miałem kiedyś problem z Unidaciem przy kilku wątkach, to pomogło.

Ten cały wątek jest megazabawny.
Wygląda to mniej więcej tak:

pytacz) mam problem z klejeniem kafelków na ścianie, nie chcą się trzymać,
odpadają, próbuję je kleić gumą do żucia i mam problemy

odpowiadacz A) nie rób tak, użyj kleju do glazury oraz porządnie oczyść,
odpyl i zagruntuj wcześniej ścianę

pytacz) nie mam czasu, muszę teraz tak zrobić, ale dałem lepszą gumę i
trochę plasteliny i już trzyma od wczoraj, tylko dwa kafelki odpadły,
dokleiłem je na dżem i jest oki

odpowiadacz B) próbowałeś odkręcić kran w czasie schnięcia spoiny? mi
pomogło


ps. devart team: "The SmartFetch mode allows to speed up navigation through
the DataSet with a big amount of data. To enable this mode, it is enough to
set the Enabled property to True. In this case, when opening the DataSet,
only key field values will be read out, our the values of the fields
specified in the PrefetchedFields property. Data of other fields will be
read out on demand when accessing a record."

-- 
pozdrawiam
Roman Tyczka

> Ten cały wątek jest megazabawny.
> Wygląda to mniej więcej tak:
> 
> pytacz) mam problem z klejeniem kafelków na ścianie, nie chcą się trzymać,
> odpadają, próbuję je kleić gumą do żucia i mam problemy

Ej no, przecież piszę że chce to zrobić lepiej tylko nikt nie pisze gdzie kupić klej do glazury...

Podpowiedzcie - czy mogę po wykonaniu query (tak jak napisał RT) podpiąć je pod grida na formie głównej czy powinienem to jakoś przepisać/przenieść? Bo jak kojarzę wątek po wykonaniu zadania zwalnia automatycznie pamięć więc również wszystko co w nim utworzę?

Możecie podrzucić jakiś prosty przykład jak to w praktyce wykonać?

W dniu 2017-11-26 o 13:08, ExM pisze:
> W dniu piątek, 24 listopada 2017 13:00:25 UTC+1 użytkownik mmm napisał:
>> Takie rozwiązania "na szybko" prędzej czy później mszczą się dodatkowymi
>> godzinami na szukanie AV !
>>
>> Spróbuj zrobić to tak jak zaproponował Pan Roman w pierwszej odpowiedzi.
> 
> Tak oczywiście zdaję sobie sprawę że będę musiał to przerobić.
> Teraz musiałem rozwiązać problem a docelowo chcę przygotować rozwiązanie jak to robić zgodnie ze sztuką.
> 
> Przede wszystkim szukam informacji jak to powinno być zaprojektowane.
To proste - dokładnie odwrotnie jak to zrobiłeś.

> Jeśli macie jakieś materiały jak powinienem tworzyć tego typu obiekty w trybie wielowątkowym i łączyć je z kontrolkami wizualnymi podeślijcie proszę info.
To też proste - nie da się bez synchronizacji wątku z wątkiem głównym. 
Wszystko.
A i jeszcze jedno - jeśli baza danych, to każdy wątek operujący na bazie 
danych musi (są wyjątki (a to zależy od bazy danych i jej biblioteki do 
połączenia, tzw. klienta) od reguły, ale najlepiej będzie jak uznamy, że 
MUSI) korzystać z osobnego połączenia (dla klikaczy; komponent 
Connection czy Database czy czego tam używasz).
Jeśli tego nie zrobisz, to prosisz się o kłopoty.

Jeśli chcesz to zrobić i nie wiesz ile może być tzw. _worker-threads_, 
to najlepiej jak skorzystasz z _connection pooling_

Jeśli wiesz co i jak, to zrób tak, aby każdy wątek roboczy korzystał z 
prywatnego połączenia z bazą.

Co do tego Twojego blokowania zdarzeń - to nie będzie dobrze działać.
Tak się nie da.

Jeśli chcesz otwierać w wątku dataseta, który jest własnością formy 
głównej, a ta z definicji jest obsługiwana przez wątek główny, to...

Musisz zapewnić, że nikt tego dataseta nie będzie używał z innego wątku 
(również z wątku głównego) bez synchronizacji w trakcie jego otwierania.
Jawnie, pośrednio czy niejawnie.

Aby to zrobić - to musisz odłączyć wszystkie DataSource od tego DataSet; 
np. DataSource.Dataset := nil;
Innymi słowy - taki wątek powinien przejąć totalną kontrolę nad tym 
DataSetem na czas otwierania i oddać go po otwarciu, synchronizując z 
wątkiem głównym i przywracając stan przypisania DataSource, zdarzeń, etc.

Tylko jak zachowa się Twój kod i kontrolki, kiedy im nagle z DataSource 
DataSet zniknie? ;-)
Ten temat nie jest w Delphi do zrobienia prosto, jak się ma wyklikane 
wszystko w IDE.

Jak widać, mam nadzieję, problem jest szerszy i wymaga podejścia, że tak 
powiem architektonicznego.

Jeśli szukasz magicznej metody czy komponentu na realizację w/w 
zagadnienia, to odpuść sobie ten temat, ponieważ prędzej czy później 
skończy się to dziwnymi problemami.

I na koniec - dlaczego chcesz otwierać dane w wątki pobocznym?
osobiście przydałoby mi się to z raz czy dwa, ale generalnie nie.

Zamiast odświeżania całości w wątku pobocznym, odświeżam wątku głównym 
tylko te rekordy, które zostały zmienione/dodane czy usunięte, pod 
warunkiem, że wcześniej zostały załadowane do DataSeta (bo i nie ładuję 
z serwera wszystkiego jak leci).
Nie dość że działa to bardzo wydajnie (odświeżanie danych, niezależnie 
od ich ilości, to zazwyczaj ułamek sekundy), to nie wymaga fiku-miku z 
wątkami.

-- 
wloochacz

W dniu 2017-11-27 o 20:55, ExM pisze:
> Możecie podrzucić jakiś prosty przykład jak to w praktyce wykonać?
Problem polega na tym, że w praktyce nie ma prostego sposobu :)

-- 
wloochacz

On Mon, 27 Nov 2017 11:55:40 -0800 (PST), ExM wrote:

>> Ten cały wątek jest megazabawny.
>> Wygląda to mniej więcej tak:
>> 
>> pytacz) mam problem z klejeniem kafelków na ścianie, nie chcą się trzymać,
>> odpadają, próbuję je kleić gumą do żucia i mam problemy
> 
> Ej no, przecież piszę że chce to zrobić lepiej tylko nikt nie pisze
> gdzie kupić klej do glazury... 
> 
> Podpowiedzcie - czy mogę po wykonaniu query (tak jak napisał RT) podpiąć
> je pod grida na formie głównej czy powinienem to jakoś
> przepisać/przenieść? Bo jak kojarzę wątek po wykonaniu zadania zwalnia
> automatycznie pamięć więc również wszystko co w nim utworzę? 

Wątek nie zwalnie niczego co utworzyłeś, wątek zwalnia jedynie swój stos.
To co zaalokujesz przez getmem czy konstruktory klas jest nadal
zaalokowane.
 
> Możecie podrzucić jakiś prosty przykład jak to w praktyce wykonać?

Temat jest tak rozległy, że nawet trudno wybrać od czego zacząć. Może po
prostu zacznij od poczytania o TThread i okolicach w helpie, a potem
eksperymentuj, googluj i pytaj jak będziesz miał z czymś problem.
Na początek napisz jakie dane z tego zapytania chcesz na formie pokazywać,
jak ich jest dużo i jakiego są rodzaju.

-- 
pozdrawiam
Roman Tyczka

Do poduszki

https://edn.embarcadero.com/article/22411
https://www.slideshare.net/NiallMunro1/delphi-howto-threads

ps. kiedyś były dostępne materiały ze zlotów programistów delphi, tam też
były wykłady na te tematy, ale nic teraz nie mogę znaleźć

ps. pewnie na stronie embarcadero są też materiały z CodeRages oraz filmy w
YT

-- 
pozdrawiam
Roman Tyczka

W dniu poniedziałek, 27 listopada 2017 20:58:08 UTC+1 użytkownik wloochacz napisał:
> W dniu 2017-11-26 o 13:08, ExM pisze:
> > W dniu piątek, 24 listopada 2017 13:00:25 UTC+1 użytkownik mmm napisał:

> I na koniec - dlaczego chcesz otwierać dane w wątki pobocznym?
> osobiście przydałoby mi się to z raz czy dwa, ale generalnie nie.

Ponieważ większość danych jakie odświeżam to duże listy wyników lub raporty oparte o procedury składowane które się długo przetwarzają (od kilku sekund do półtorej minuty)

> Zamiast odświeżania całości w wątku pobocznym, odświeżam wątku głównym 
> tylko te rekordy, które zostały zmienione/dodane czy usunięte, pod 
> warunkiem, że wcześniej zostały załadowane do DataSeta (bo i nie ładuję 
> z serwera wszystkiego jak leci).
> Nie dość że działa to bardzo wydajnie (odświeżanie danych, niezależnie 
> od ich ilości, to zazwyczaj ułamek sekundy), to nie wymaga fiku-miku z 
> wątkami.

A jak modę to zrealizować? Jak wczytać tylko te "nowe" lub "zmienione" dane i odświeżyć dataset'a tak żeby zaktualizować wyniki już załadowane na grida?
Obecnie używałem tylko DataSet.Refresh

W dniu poniedziałek, 27 listopada 2017 22:22:56 UTC+1 użytkownik Roman Tyczka napisał:
> On Mon, 27 Nov 2017 11:55:40 -0800 (PST), ExM wrote:
> Temat jest tak rozległy, że nawet trudno wybrać od czego zacząć. Może po
> prostu zacznij od poczytania o TThread i okolicach w helpie, a potem
> eksperymentuj, googluj i pytaj jak będziesz miał z czymś problem.
> Na początek napisz jakie dane z tego zapytania chcesz na formie pokazywać,
> jak ich jest dużo i jakiego są rodzaju.

Generalnie wszystko co wyświetlam w programie jest tylko do odczytu. (Modyfikacje robię wywołując procedury składowane SQL - insert/update/delete)

Dane są generowane większości przez funkcje i procedury składowane a czas ich generowania wynosi od kilku sekund do półtorej minuty.

Danych jest od kilu do kilkunastu tysięcy wierszy. Zwykle kilka-kilkanaście kolumn. Teksty, daty, wartości liczbowe.

W dniu 2017-11-28 o 16:44, ExM pisze:
> W dniu poniedziałek, 27 listopada 2017 20:58:08 UTC+1 użytkownik wloochacz napisał:
>> W dniu 2017-11-26 o 13:08, ExM pisze:
>>> W dniu piątek, 24 listopada 2017 13:00:25 UTC+1 użytkownik mmm napisał:
> 
>> I na koniec - dlaczego chcesz otwierać dane w wątki pobocznym?
>> osobiście przydałoby mi się to z raz czy dwa, ale generalnie nie.
> 
> Ponieważ większość danych jakie odświeżam to duże listy wyników lub raporty oparte o procedury składowane które się długo przetwarzają (od kilku sekund do półtorej minuty)
Dla analiz wszelkiej maści, prezentowanych w formie grida, pivota czy 
wydruku ma to sens i stosunkowo łatwo to zrobić.
A więc zdecydowanie warto.

>> Zamiast odświeżania całości w wątku pobocznym, odświeżam wątku głównym
>> tylko te rekordy, które zostały zmienione/dodane czy usunięte, pod
>> warunkiem, że wcześniej zostały załadowane do DataSeta (bo i nie ładuję
>> z serwera wszystkiego jak leci).
>> Nie dość że działa to bardzo wydajnie (odświeżanie danych, niezależnie
>> od ich ilości, to zazwyczaj ułamek sekundy), to nie wymaga fiku-miku z
>> wątkami.
> 
> A jak modę to zrealizować? Jak wczytać tylko te "nowe" lub "zmienione" dane i odświeżyć dataset'a tak żeby zaktualizować wyniki już załadowane na grida?
> Obecnie używałem tylko DataSet.Refresh

Na twoim miejscu zacząłbym od czytania dokumentacji. Ja używam FireDACa, 
więc nie pomogę. A za Ciebie dokumentacji do UniDACa czytał nie będę ;-)

-- 
wloochacz

On Tue, 28 Nov 2017 07:49:39 -0800 (PST), ExM wrote:

>> Temat jest tak rozległy, że nawet trudno wybrać od czego zacząć. Może po
>> prostu zacznij od poczytania o TThread i okolicach w helpie, a potem
>> eksperymentuj, googluj i pytaj jak będziesz miał z czymś problem.
>> Na początek napisz jakie dane z tego zapytania chcesz na formie pokazywać,
>> jak ich jest dużo i jakiego są rodzaju.
> 
> Generalnie wszystko co wyświetlam w programie jest tylko do odczytu. (Modyfikacje robię wywołując procedury składowane SQL - insert/update/delete)
> 
> Dane są generowane większości przez funkcje i procedury składowane a czas ich generowania wynosi od kilku sekund do półtorej minuty.
> 
> Danych jest od kilu do kilkunastu tysięcy wierszy. Zwykle kilka-kilkanaście kolumn. Teksty, daty, wartości liczbowe.

Albo czegoś nie rozumiem albo robisz to dziwnie.
Te dane co je generujesz to nie jest prosty zrzut tabel tylko jakieś
wyliczone rzeczy? I wyliczasz je bez przerwy w kołko, żeby mieć jak
najbardziej aktualne dane?
Czyli posługując się jakimś analogicznym przykładem masz bazę, która np.
gromadzi kupony lotto, które spływają on-line i chcesz pokazywać na bieżąco
ile kuponów wpłynęło na każdą kolekturę, ile było pojedynczych a ile
podwójnych zakładów, itd.?

-- 
pozdrawiam
Roman Tyczka

W dniu wtorek, 28 listopada 2017 17:01:14 UTC+1 użytkownik wloochacz napisał:
> > A jak modę to zrealizować? Jak wczytać tylko te "nowe" lub "zmienione" dane i odświeżyć dataset'a tak żeby zaktualizować wyniki już załadowane na grida?
> > Obecnie używałem tylko DataSet.Refresh
> 
> Na twoim miejscu zacząłbym od czytania dokumentacji. Ja używam FireDACa, 
> więc nie pomogę. A za Ciebie dokumentacji do UniDACa czytał nie będę ;-)

Używam głównie Devartowego SDACa (do MSSQLa) i ODACa (do Oracle'a)
One generalnie są wszystkie podobne - głównie obsługą baz się różnią

W dniu wtorek, 28 listopada 2017 19:16:36 UTC+1 użytkownik Roman Tyczka napisał:
> Albo czegoś nie rozumiem albo robisz to dziwnie.
> Te dane co je generujesz to nie jest prosty zrzut tabel tylko jakieś
> wyliczone rzeczy? I wyliczasz je bez przerwy w kołko, żeby mieć jak
> najbardziej aktualne dane?
> Czyli posługując się jakimś analogicznym przykładem masz bazę, która np.
> gromadzi kupony lotto, które spływają on-line i chcesz pokazywać na bieżąco
> ile kuponów wpłynęło na każdą kolekturę, ile było pojedynczych a ile
> podwójnych zakładów, itd.?

Coś w tym stylu. 
Procedury wyliczają różne wyniki, składają dane z innych funkcji itp. a użytkownik ma możliwość ich odświeżenia na żądanie.
W tym samym czasie ma podgląd na inne wyniki które aktualizują się samoczynnie co podany czas.

Dla tego muszę to robić wielowątkowo aby nie ścinać interfejsu użytkownikowi kiedy coś sobie w nim dłubie (np. ustala parametry wywołania procedury) a równocześnie w tle aktualizują się inne procedury.

> Coś w tym stylu.
> Procedury wyliczają różne wyniki, składają dane z innych funkcji itp. a użytkownik ma możliwość
> ich odświeżenia na żądanie.
> W tym samym czasie ma podgląd na inne wyniki które aktualizują się samoczynnie co podany czas.
>
> Dla tego muszę to robić wielowątkowo aby nie ścinać interfejsu użytkownikowi kiedy coś sobie w nim
> dłubie (np. ustala parametry wywołania procedury) a równocześnie w tle aktualizują się inne
> procedury.

Jeśli te dane służą tylko do oglądania w DBGridzie (bez edycji w DBGridzie) i mają się odświeżać bez
angażowania głównego wątku, to najprościej będzie zrobić podwójne buforowanie DataSetów.

Jeden DataSet cały czas jest podłączony do DBGrida i pozwala przeglądać dane, a żądanie odświeżenia
powoduje pobranie tych samych danych w wątku pobocznym do drugiego DataSet. Jak wątek skończy
działanie (pobierze wszystkie dane) to informuje wątek główny, że można podmienić DataSety i 
podłaczyć
do DBGrida ten odświeżony, a ten pierwszy DataSet można zamknąć.

To jest taka kosztowniejsza pamięciowo (ale prosta do realizacji) wersja rozwiązanie, które na 
początku
podał Wloochacz z doczytywaniem jedynie danych, które się zmieniły, ale tu nie musisz wiedzieć, co 
się
zmieniło w danych.

-- 
pozdrowienia
Krzysztof Szyszka, X-Files Software
Developer of X-DBGrid Component
Embarcadero Technology Partner
http://www.x-files.pl/
Join to "Delphi X-DBGrid Component Community"
https://plus.google.com/#communities/100842098152269100547 

W dniu 2017-11-29 o 16:41, ExM pisze:
> W dniu wtorek, 28 listopada 2017 17:01:14 UTC+1 użytkownik wloochacz napisał:
>>> A jak modę to zrealizować? Jak wczytać tylko te "nowe" lub "zmienione" dane i odświeżyć dataset'a tak żeby zaktualizować wyniki już załadowane na grida?
>>> Obecnie używałem tylko DataSet.Refresh
>>
>> Na twoim miejscu zacząłbym od czytania dokumentacji. Ja używam FireDACa,
>> więc nie pomogę. A za Ciebie dokumentacji do UniDACa czytał nie będę ;-)
> 
> Używam głównie Devartowego SDACa (do MSSQLa) i ODACa (do Oracle'a)
> One generalnie są wszystkie podobne - głównie obsługą baz się różnią
> 
ODAC ma coś takiego jak NonBlocking mode. Czyli odczyt danych bez 
blokowania wątku, który to wywołał. Zapytanie jest wykonywane w 
dedykowanym wątku, ale obsłużonym przez bibliotekę ODAC. Czy jest coś 
takiego w SDACu nie wiem - nigdy go nie używałem. Nonblocking mode nie 
obsłuży poprawnie zdarzeń dataseta aktualizujących warstwę wizualną, ale 
odchodzi Ci przynajmniej ręczna dłubanina w wątkach. Dodatkowo możesz 
wysłać do serwera informację o przerwaniu wykonania zapytania czego w 
układzie query w wątku standardowo nie zrobisz.

Połącz tryb NonBlocking z tym co napisał Krzysztof Szyszka i może na 
Twoje potrzeby to wystarczy.

-- 
z pozdrowieniami
Adam Siwoń

> Jeden DataSet cały czas jest podłączony do DBGrida i pozwala przeglądać dane, a żądanie odświeżenia
> powoduje pobranie tych samych danych w wątku pobocznym do drugiego DataSet. Jak wątek skończy
> działanie (pobierze wszystkie dane) to informuje wątek główny, że można podmienić DataSety i 
> podłaczyć
> do DBGrida ten odświeżony, a ten pierwszy DataSet można zamknąć.
> 
> To jest taka kosztowniejsza pamięciowo (ale prosta do realizacji) wersja rozwiązanie, które na 
> początku
> podał Wloochacz z doczytywaniem jedynie danych, które się zmieniły, ale tu nie musisz wiedzieć, co 
> się
> zmieniło w danych.

o... to jest super pomysł! Na pewno przetestuje :) 
Jeszcze tylko jakieś info symbolizujące ładowanie danych dodam i będzie super.
Wtedy po staremu zostanie chyba tylko pierwsze otwarcie DataSet'a...

W dniu środa, 29 listopada 2017 23:26:04 UTC+1 użytkownik Adam Siwoń napisał:
> ODAC ma coś takiego jak NonBlocking mode. Czyli odczyt danych bez 
> blokowania wątku, który to wywołał. Zapytanie jest wykonywane w 
> dedykowanym wątku, ale obsłużonym przez bibliotekę ODAC. Czy jest coś 
> takiego w SDACu nie wiem - nigdy go nie używałem. Nonblocking mode nie 
> obsłuży poprawnie zdarzeń dataseta aktualizujących warstwę wizualną, ale 
> odchodzi Ci przynajmniej ręczna dłubanina w wątkach. Dodatkowo możesz 
> wysłać do serwera informację o przerwaniu wykonania zapytania czego w 
> układzie query w wątku standardowo nie zrobisz.
> 
> Połącz tryb NonBlocking z tym co napisał Krzysztof Szyszka i może na 
> Twoje potrzeby to wystarczy.

Faktycznie jest taki parametr również w SDACu
Sprawdzę - faktycznie razem z trikiem Krzysztofa powinno to rozwiązać moje problemy :)
Dam znać

W dniu 2017-11-29 o 17:29, Krzysztof Szyszka pisze:
> To jest taka kosztowniejsza pamięciowo (ale prosta do realizacji) wersja 
> rozwiązanie, które na początku
Tylko wiesz, on ma super-duper-ogrom danych, co o mu się wczytują 
półtorej minuty...

> podał Wloochacz z doczytywaniem jedynie danych, które się zmieniły, ale 
> tu nie musisz wiedzieć, co się
> zmieniło w danych.
A to (czyli co zostało zmienione, kiedy i przez kogo) uważam zawsze 
warto wiedzieć.
Do tego kolejka komunikatów i mamy aktywne powiadamianie o zmianach :)
Tylko jak zrobić taką kolejkę?

A najprościej jak się da, np. przy pomocy tego:
Wersja dla Overbyte ICS:
https://github.com/pjde/delphi-mqtt/tree/master/src

Wersja dla Synapse:
https://github.com/jamiei/Delphi-TMQTT2

Albo postawić mORMota z dwukierunkowym WebSockets, albo innego RabbitMQ, 
ZeroMQ czy inne MQ :-)


-- 
wloochacz

> > To jest taka kosztowniejsza pamięciowo (ale prosta do realizacji) wersja rozwiązanie, które na
> > początku
> Tylko wiesz, on ma super-duper-ogrom danych, co o mu się wczytują półtorej minuty...
>
> > podał Wloochacz z doczytywaniem jedynie danych, które się zmieniły, ale tu nie musisz wiedzieć,
> > co się zmieniło w danych.
> A to (czyli co zostało zmienione, kiedy i przez kogo) uważam zawsze warto wiedzieć.
> Do tego kolejka komunikatów i mamy aktywne powiadamianie o zmianach :)
> Tylko jak zrobić taką kolejkę?
>
> A najprościej jak się da, np. przy pomocy tego:
> Wersja dla Overbyte ICS:
> https://github.com/pjde/delphi-mqtt/tree/master/src
>
> Wersja dla Synapse:
> https://github.com/jamiei/Delphi-TMQTT2
>
> Albo postawić mORMota z dwukierunkowym WebSockets, albo innego RabbitMQ, ZeroMQ czy inne MQ :-)

Obaj wiemy od dawna, że Ty lubisz super-hiper wydajne rozwiązania, a ja wolę
stosować "regułę KISS" https://pl.wikipedia.org/wiki/KISS_(regu%C5%82a) dokąd
się sprawdza, ale w tym przypadku zbyt wielu założeń tego projektu to nie znamy,
więc niech wątkotwórca sam sobie dobierze lepsze rozwiązanie do własnych potrzeb.

-- 
pozdrowienia
Krzysztof Szyszka, X-Files Software
Developer of X-DBGrid Component
Embarcadero Technology Partner
http://www.x-files.pl/
Join to "Delphi X-DBGrid Component Community"
https://plus.google.com/#communities/100842098152269100547 

W dniu czwartek, 30 listopada 2017 19:47:59 UTC+1 użytkownik wloochacz napisał:
> Tylko wiesz, on ma super-duper-ogrom danych, co o mu się wczytują 
> półtorej minuty...
To niekoniecznie wynika z ilości danych a raczej z takiej ilości danych która przy serwerze o danej mocy powoduje tak długi czas odpowiedzi oraz na wielu złączeniach które wydłużają czas przetwarzania przez SQL

> > podał Wloochacz z doczytywaniem jedynie danych, które się zmieniły, ale 
> > tu nie musisz wiedzieć, co się
> > zmieniło w danych.
To by było świetne rozwiązanie - przy czym jeśli obecnie nie wspierają tego komponenty jakich używam wymaga to sporych modyfikacji aplikacji, ale pewnie powoli o do tego dojdę...
Dzięki za materiały poglądowe :)