Mam takie teoretyczne pytanie. Dlaczego warto używać do odczytu informacji z baz danych dbgrid a nie np. stringgrid lub jakiegoś innego komponentu wyświetlającego dane. Do tej pory zawsze robiłem tak że pobierałem dane przez query, wpisywałem je do stringgrid i zaraz zamykałem query. Podczas aktualizacji danych w bazie musiałem znowu załadować wszystkie wiersze do stringgrid. Teraz najważniejsza część pytania. Czy jeśli użyłbym dbgrida i nie zamykał query po wykonaniu zapytania to podczas dodawania/zmiany rekordu dane w dbgrid będą aktualizowały się automatycznie, czy będę musiał jeszcze raz odpalić procedurę odbierającą wszystkie rekordy (razem z tymi zaktualizowanymi)? Drugie pytanie jest następujące. Załóżmy że mamy użytkownika A i B na dwóch różnych stanowiskach w sieci. Obydwoje mają uruchomione aplikacje i wyświetlają im się dane w tabeli (rozwiązanie z wykorzystaniem dbgrida). Załóżmy że teraz użytkownik A zmodyfikuje tablę. Czy jeśli użytkownik B cały czas ma otworzone query z podłączonym dbgridem to dane w tabeli użytkownika B same się zaktualizują, czy trzeba odświeżyć tabelę (czyli pobrać z bazy jeszcze raz wszystkie rekordy)? Jak to jest?
axelll napisał(a)
Mam takie teoretyczne pytanie. Dlaczego warto używać do odczytu informacji z baz danych dbgrid a nie np. stringgrid lub jakiegoś innego komponentu wyświetlającego dane.
No chociazby sposob edycji danych. Jesli edytujesz dane w DBGrid, to zakonczenie edycji jednego wiersza moze automatycznie rownac sie wpisowi do tabeli w bazie danych. Natomiast jesli Ty chcialbys to zrealizowac na TStringGrid to komplikujesz sobie zycie, no bo musisz np sledzic w ktorym wierszu tabeli obecnie sie znajdujesz. A jesli dodatkowo zamykasz query no to juz w ogole, musisz albo ponownie otworzyc to query i znalezc wiersz ktory nalezy zmodyfikowac albo napisac dodatkowe query do INSERT/ UPDATE...
axelll napisał(a)
Załóżmy że teraz użytkownik A zmodyfikuje tablę. Czy jeśli użytkownik B cały czas ma otworzone query z podłączonym dbgridem to dane w tabeli użytkownika B same się zaktualizują, czy trzeba odświeżyć tabelę (czyli pobrać z bazy jeszcze raz wszystkie rekordy)? Jak to jest?
Trza aktualizowac dane.
Największe moim zdaniem różnice to:
- jak zachowa się twój mechanizm przy 1000000 rekordów - zaciągniesz je wszystkie do stringgrid'a ? = spory kawał czasu, w dbgridzie, lub ogólniej zależnie od technologi DB masz buforowanie, tzn, pobierasz tyle ile na starcie chcesz wyświetlić (ew. wszystkie FetchAll)
- prostota używania, dbgrid jest zaprojektowany do używania z komponentami bazodanowymi, nowe kolumny (ich wygląd, formatowanie, justowanie) tworzysz sobie z użyciem IDE, a nie jak podejrzewam jest u Ciebie w kodzie aplikacji
- stosunkowo prosto jest zaimplementować sortowanie
- bardzo prosto jest zaimplementować filtrowanie (mówię tutaj o połączeniu komponentów bazodanowych i grida)
Jest jeszcze wiele innych różnic, myślę że najprościej będzie jak go <ort>sprubujesz </ort>użyć - przekonasz się sam.
Co do pytania dotyczącego aktualizacji danych. DBGrid daje możliwość aktualizacji wprost w gridzie. Zresztą jest to nawet defaultowo włączone. Jeśli coś zmienisz i wywołasz Post, to nie musisz odświeżać danych (otwierać zapytania) - będziesz to widział od razu. Jeśli zmienisz coś w bazie "gdzie indziej" - przez inne komponenty to zmiany same się nie pojawią. Trzeba dodatkowych kombinacji. Jest to też odpwiedź na ostatnie pytanie. Twoich zmian nie będzie widział też drugi gość (abstrahuje tu od poziomu izolowania transakcji, i od transakcyjności <ort>w ogóle</ort>). W każdym razie dane trzeba odświeżyć. Nie napisałeś nic o silniku DB, więc podam przykład dotyczący Firebird'a/Interbase. Można zrobić w prosty sposób coś takiego, że dopisanie/modyfikacja/usunięcie rekordu z danej tabeli powoduje wywołanie event'a. Do tego trzeba dołozyć obsługę eventów w aplikacji, reagując na nie np poprzez odświeżenie dbgrid'a (wykonanie zapytania) - temat wymaga więcej szczegółów żeby nie zrobić z tego potwora - ja tylko nakreślam że jest to w prosty sposób możliwe.
Warto też nadmienić dynamiczne kursory po stronie serwer'a w przypadku ADO, aczkolwiek nie będzie to działać tak że gość na bieżąco bęzdie widział zmiany - odsyłam do google.
Macie rację jeśli chodzi o powolność działania. Ja używam stringgrid w bazach w których wyświetlam max 1000 rekordów. Na datamodule mam tylko jedno query i za jego pomocą wykonuję wszystkie zapytania selecty inserty i update. Dlatego za każdym razem otwieram i zamykam połączenie. Wg mnie jest to bardziej przejrzyste rozwiązanie bo nie mam za dużo komponentów i za dużo otwartych query. Jak Wy to robicie? Do każdej tabeli jest osobne query? Nie jest z tym za dużo zamieszania?
Wracając do odświeżania danych. Korzystam z Firebirda i pomysł z eventami wydaje mi się całkiem ciekawy.
Mam pomysł żeby zrobić tak: Zostawiam sobie na datamodule jedno query z trasnakcją do insert, update i delete oraz dla każdej tabeli oddzielne query z inną transakcją do odczytu. Dobrze myślę? Tylko jak skonfigurować te transakcje żeby do dobrze działało?
Co do tego jak to skonfigurować żeby dobrze działało, to nie jest to dobre miejsce żeby o tym pisać. Musisz poszukać na necie o co chodzi w transakcyjności. Jakby było jedno jedyne rozwiązanie to nic nie trzeba było by konfigurować, bo było by ono zapewne domyślnie poustawiana w komponentach. Wszystko zależy o konkretnego zastosowania. To czy masz mieć query do każdej tabeli czy inaczej to wszystko zależy od architektury. Możesz mieć formatkę bazową, żeby było mniej roboty, a reszta formatek po niej dziedziczy. Napisałeś o Firebirdzie, ale nie napisałeś jak z niego korzystasz (ADO, DBE, ODBC, IBX, DBX, IBO, FIB ...), a to ważne. W każdym razie na forum nie pytał bym jak poustawiać transakcje, jest o tym pełno na necie wystarczy poszukać
Aha i jeszcze dwie uwagi. Co do 1000 rekordów, jeśli jesteś absolutnie pewien że więcej nie będzie to wporzo. Ale jeśli wiesz tylko że więcej nie powinno być, to od razu odpuść temat, bo przyjdzie moment że będzie trzeba przerabiać na szybko.
Druga uwaga co do zamieszania z ilością komponentów - pojechałeś po bandzie. Jedno Query na Datamodule ... W poprzedniej robocie robilem pamiętam taką jedną formatkę, bez jakichś tam specjalnych bajerów, ale sama deklaracja komponentów w unicie tej formatki, sięgała około 1000-cznej linii... Jeśli będziesz sobie te komponenciki układał ładnie, nazywał tak jak Pan Bóg przykazał, to unikniesz zamieszania. Oczywiście nie twierdzę, że jeśli robisz dwie rzeczy 1 querasem, to trzeba to rozbić na dwa komponenty - tego nie da sie powiedzieć jednoznacznie bez konkretnego przykładu. Trzeba wziąć pod uwagę, częstość wykonywania danych operacji, itd, itp. Poczytaj o przygotowywaniu zapytać dzięki temu można trochę przyśpieszyć działanie aplikacji DB (Prepare, Unprepare).
Na pewno będę miał w bazie max 1000 rekordów. Pomimo tego że tak na prawdę może być ich więcej napisałem program tak, żeby po odfiltrowaniu nie było ich za dużo, tylko tyle żeby stringgrid mógł sobie poradzić. Tak więc jeśli chodzi o szybkość to nie ma problemu.
Korzystam z IBX do łączenia się z firebirdem. Zacząłem robić tak, że mam jedno query do wysyłania zapytań insert, update i delete, a do odczytu do każdej tabelki mam osobne query. Będę musiał się do tego przyzwyczaić, ale jeśli nie jest to złe rozwiązanie to OK. Aha mam jeszcze tylko jedno pytanie. Teraz przy odczytywaniu danych z tabeli otwieram query i tak je zostawiam. Muszę je kiedyś zamknąć? Czy wystarczy że wyłączę program i to załatwi sprawę?
axell napisał(a)
...Teraz przy odczytywaniu danych z tabeli otwieram query i tak je zostawiam. Muszę je kiedyś zamknąć? Czy wystarczy że wyłączę program i to załatwi sprawę?
Wyłączenie programu na pewno załatwi sprawę, zresztą jak masz wersję Delphiaka co najmniej Proff, to włącz sobie w opcjach projektu Use Debug DCU, i sobie podebuguj, to sam dostaniesz odpowiedzi na takie pytania. Nie wiem czy jak jest tak, że query masz na datamodule, a formatka z dbgrid'em jest osobno, to czy po zamknięciu tej formatki zamknie się query - na 90% się nie zamknie. Ja jednak jestem zwolennikiem praktyki, że jeśli na jakieś formatce mam dbgrid'a, to mam tam też i dataset'a (np query) oraz datasource. Na datamodulach mam rzeczy związane z połączeniem, transakcyjnością (database, session, transaction) i np stored procki wykorzystywane w całym systemie.
Nie powinieneś mieć otwartych zapytań, jak Ci to nie jest potrzebne. Zreszta w rozwiązaniu ze stringgrid'em, to możesz zamknąć zapytanie po wyciągnięciu wszystkich danych.
Przy zrzucaniu niektórych rzeczy na karb zamykania programu, trzeba być świadomym pewnych ustawień, jak np domyślne akcje w transakcjach (taCommit, taRollback)