🚀 go-pugleaf

> 1.
> Przyzwyczaiłem się do pakietu UIB, jeszcze w czasach, gdy nie dało się 
> podpinać tych komponentów wprost pod kontrolki dbaware - więc wszelkie 
> wyniki zapytania wstawiałem do np. TListView, czy indywidualnych 
> komponentów typu TEdit. Miało to dla mnie taki plus, że po 
> aktualizowaniu/dodaniu danego rekordu nie musiałem ponownie odczytywać 
> danych z bazy, a jedynie aktualizowałem ów komponent. I do tych małych 
> rzeczy pracujących na 2-3 stanowiskach jednocześnie sprawdzało się to do 
> dziś. Drugi plus tego rozwiązania był taki, że TDBGrid czy jemu podobne 
> do najpiękniejszych (wizualnie) nie należą, a o mniej archaiczny wygląd 
> upraszali się użytkownicy. 
Mnóstwo komercyjnych komponentów i trochę za friko - np.
http://www.scalabium.com/smdbgrid.htm

> Teraz mam robótkę, w której jednocześnie z 
> bazy będzie korzystać kilkudziesięciu użytkowników. Zastanawiam się, na 
> ile łatwiej będzie mi pracować w całości na kontrolkach dbaware. Jakie 
> są plusy tego rozwiązania?
Plusy są takie, że kontrolki są dbAware ;-)
To jest czasem też minus ;-)

> 2.
[ciach]
> I chcę zrealizować to tak, że jeżeli typ przyjmie 
> wartość np. 1, to pole opis będzie dostępne, a podkategoria - nie; i 
> vice versa - gdzie typ to np. 2, opis ma być niedostępny, natomiast 
> podkategoria owszem. Nie wiem, czy rodzaj bazy ma teraz znaczenie, ale o 
> ile większość rzeczy mam w Firebird i to wystarcza, o tyle w tym 
> przypadku ze względu na pozostałe wymagania będzie to pewnie MS SQL, a 
> co za tym idzie - pewnie skorzystam z AnyDAC. Jakiś hint? A może mam 
> chwilowe zaćmienie i to jest jakiś banał...? :)
No, ale w czym problem?
Baza danych nie ma żadnego znaczenia, wystarczy obsłużyć zdarzenie 
OnSetText danego pola (typ) i udostępniać tam odpowiednie kontrolki lub 
cokolwiek innego...

-- 
wloochacz