🚀 go-pugleaf

Sowiecki Agent napisał(a):
> Witam!
> Chcialbym sie przypomniec Włoochaczowi :)
> Mial napisac lopatologicznie krok po kroku jak sie to robi
> gdy tylko znajdzie chwilke czasu.
> 
> Zalozenie:
> tabeli
> ptak
> ID_ptak (uniqueidentifier NOT NULL default newid())
> nazwa_ptaka varchar(200) NOT NULL;
> 
> Jak mam ustawic komponent i jakie wpisac zapytania w odpowidnich polach 
> (pomijajac insert, update, delete, chodzi o te do blokowania i 
> zwalniania blokady)
> 
> Najlpiej by bylo uniwersalne i dziaalo na bazach
> MSsql, Oracle, DB2, Firebird(jak juz zostanie dolaczone do AnyDaca)
> 
> P.

Witam,

dzieki Wloochaczowi również przesiadłem się (jakiś czas temu) na AnyDaca.
Szukałem sposobu, który pozwoliłby mi maksymalnie skrócić czas 
"produkowania" prostszych programików bazodanowych. Aby zachować wygodę 
pracy z ADClientDataSet równocześnie nie tracąc funkcjonalności ADUpdateSQL.

Może będzie przydługie ale postaram się napisać "krok po kroku"  o co mi 
chodzi. (baza MSSQL)
Będzie trochę oczywistości ale może ktoś początkujący z tego skorzysta.

ADClientDataSet -> ADTableAdapter -> ADCommand (podpięty do 
SelectCommand w ADTableAdapret)

Zakładając, że mam dwie tabele:
1. "czytelnicy"
czytelnik_id
czytelnik_imie
czytelnik_nazwisko
czytelnik_grupa_id

2. "grupy"
grupa_id
grupa_nazwa

jeżeli w ADCommand wpiszę zapytanie:
SELECT * FROM [czytelnicy]

to naturalne jest, że mogę korzystać z ADClientDataSet.Edit, 
ADClientDataSet.Insert itd.
Problem pojawia się przy bardziej złożonym pytaniu:
SELECT
[czytelnik_id],
[czytelnik_imie],
[czytelnik_nazwisko],
[grupa_nazwa]
FROM [czytelnicy]
LEFT JOIN [grupy]
ON [czytelnik_grupa_id]=[grupa_id]

W tym momencie, próba modyfikacji rekordu ADClientDataSet.Edit (albo 
dodanie ADClientDataSet.Insert) skończy się komunikatem, że pole 
[grupa_nazwa] nie istnieje w tabli [czytelnicy]. I to również jest 
zrozumiałe. Po to wymyślono ADUpdateSQL.

Ale w ten sposób, dla każdej operacji muszę tworzyć osobne zapytania, 
także dla blokowania rekordu (oczywiście można pisać ręcznie albo 
skorzystać z edytora "prawyklik" na ADUpdateSQL, który odpowiednie 
zapytania wygeneruje automagicznie, łącznie z LOCK). Stwierdziłem 
jednak, że ADUpdateSQL jest mniej "wygodne" w użyciu (i wydłuża jednak 
czas pisania programu) więc postanowiłem zmusić ADClientDataSet do pracy 
z dowolnie złożonym zapytaniem SELECT (umieszczonym w ADCommand).

W tym celu dla pól wybieranych w zapytaniu, które nie uczestniczą w 
modyfikacji tabeli [czytelnicy] czyli w tym przypadku dla pola 
[grupa_nazwa] ustawiam w ADClientDataSet wszystkie właściwości dla tego 
pola ProwiderFlags na FALSE
plfnUpdate= false
plfnWhere= false
plfnKey= false
pfHidden= false
(ostatnie dwa domyślnie są false)
i dodatkowo dla tych pól:
ReadOnly= true

Od tego momentu, mogę korzystać ADClientDataSet.Edit (Insert itd.) 
niezależnie od złożoności zapytania SELECT. Piszę jedno zapytanie, 
zamiast dla każdej operacji osobne. Nie muszę pisać zapytania blokowania 
rekordu (LOCK w ADUpdateSQL) bo ADClientDataSet pilnuje tego sam:
ADClientDataSet.UpdateOptions
LockMode= lmPessimistic
LockPoint= lpImmediate
LockWait= false
(podczas próby równoczesnej edycji tego samego rekordu, dostaję śliczny 
komunikat, że rekord jest blokowany, tłumaczę go na język zrozumiały dla 
użytkownika i powiadamiam użytkownika)

Uprzedzając wątpliwości: jak pisałem wyżej, zdaję sobie sprawę, że to 
podejście nie rozwiązuje wszystkich problemów i raczej nadaje się do 
mniejszych programów, takich "do wyklikania". Ale właśnie cel 
osiągnąłem: mam mniej klikania, generowania dodatkowych zapytań (lub 
pisania ręcznie) i problem blokowania "z głowy". W gridzie wyświetlam to 
co chcę (dowolny SELECT), dodawanie,  modyfikację i podgląd rekordów 
robię na osobnej formatce pracując na tym samym Datasecie.

Pozdrawiam
Piotr