Robert Winkler pisze:
>> Tylko wtedy istota okienka logowania
>> sprawdzala by tylko na chwile czy wykona metode Open
>> a potem zrobi Close i przekaze InitString do bazy ?!
>>
>> W sumie wiekszosc rynkowych aplikacji po zalogowaniu przez caly czas
>> pokazuje
>> jakies informacje lub kartoteki, które podczas pracy przez caly czas
>> sa aktywne....
>>
>> Ale ok, skoro nie da sie w prosty sposób miec dostepna z wszystkich
>> formularzy globalny aktywny obiekt polaczenia z baza bede musial
>> Zrobic tak jak piszesz.....
>> Tylko kazda otwierana kartoteka bedzie opózniana przez zestawienie
>> polaczenia z baza !!!
>> A to spowolni prace calej aplikacji...
>>
>> Dziekuje z góry za kazda opinie - jesli ktos inaczej to robi to prosze
>> o posta !!!
>
> To, ze twoja aplikacja nie ma jednego globalnego obiektu polaczenia
> reprezentowanego przez obiekt SqlConnection
> wcale nie oznacza iz takie polaczenia nie ma.
> .NETowa implementacja polaczenia do bazy
> posiada w swoim wnetrzu mechanizm puli polaczen.
> Dzieki temu tylko jesli pierwszy raz tworzysz obiekt SqlConnection i
> wywolujesz metode Open
> to tak naprawde zestawiasz nowe polaczenie.
> Pózniej gdy wywolujesz metode Close aby zamknac polaczenia
> albo korzystasz z tego ze jest implementuje ona interfejs IDisposable
> (i poprzez odpowiedni sposób tworzenia obiektu SqlConnection
> gwarantujesz wywolanie metody Dispose)
> polaczenie z baza nie jest zamykane, ale dalej otwarte trafia do
> wewnetzrnej puli polaczen
> z której to zostanie pobrane przy kolejnym utworzeniu obiektu
> SqlConnection.
> Nie istnieje wiec zaden narzut czasowy na tworzenie kolejnego polaczenia.
Nie tak szybko - taki narzut zawsze istnieje, tyle że w tym przypadku
można go absolutnie pominąć.

> Kolejna zaleta to mozliwosc pracy wielowatkowej,
> z jednej instancji obiektu SqlConnection
> moze w danej chwili korzystac tylko jedna operacja bazodanowa,
> musialbys wiec stworzyc dodatkowy mechanizm blokujacy innym watkom
> aplikacji dostep do bazy
> w momencie gdy którys z nich juz z tego polaczenia korzysta.
> Jesli dwa watki w tym samym czasie beda zadaly dostepu do bazy
> to zostanie poprostu utworzone drugie polaczenia
> i umieszczone w puli aktywnych polaczen.
> Jesli dwa watki z jakichs powodów beda naprzemiennie zadaly dostepu do bazy
> to aplikacja caly czas bedzie korzystala tylko z jednego otwartego
> polaczenia.
Świetne.
A jak to ma się do innych baz danych?
Albo zapytam inaczej (ale o to samo) - co w przypadku, kiedy nie
korzystamy z NativeClient, czyli z System.Data.SqlClient?
Co mi z poolingu jak to zadziała tylko na jedynie słusznej bazie danych
jaką jest SQL Server od MS'a?

> Widze ze fakt iz aplikacja caly czas prezentuje zawartosc bazy danych
> utozsamiasz z koniecznoscia ciaglego utrzymywania polaczenia.
> Musze cie rozczarowac, w przypadku ADO.NET nie jest to prawda.
> U podstaw ADO.NET lezy koncepcja praca bezpolaczeniowej.
> Aplikacja co prawda na starcie laczy sie z serwerem i pobiera dane
> ale pobiera je do lokalnych struktur znajdujacych sie
> w pamieci operacyjnej komputera uzytkownika.
> Gdy dane zostaly juz pobrane polaczenie do bazy mozna zamknac.
> Oznacza to jednak iz uzytkownik nie otrzyma zadnych informacji
> o jakichkolwiek zmianach w bazie danych
> oraz ze zmiany jakie dokona na swoim komputerze nie znajda sie w bazie.
> Za obsluge tego odpowiedzialny jest programista
> który powinien napisac aplikacje w taki sposób
> aby cyklicznie odpytywala baze danych o zmiany
> oraz zapisywala lokalne zmiany w bazie.
Właśnie opisałeś największą wadę ADO.NET :)

> Oczywiscie takie podejscie powoduje kolejne problemy
> jesli wielu uzytkowników modyfikuje te same dane
> program musi bys w stanie rozpoznac konflikty
> i odpowiednio na nie reagowac.
To jest tylko jedna z implikacji powyższego...
BTW - a co daje ADO.NET do pomocy? Chodzi mi o rozwiązywanie konfliktów...

> Moze sie to tez wiazac z odpowiednim projektem samej bazy danych,
> sposobem przechowywania danych,
> oraz koniecznoscia rozszerzenia tabel o dodatkowe informacje techniczne
> konieczne do rozpoznawania i obslugi konfliktów,
Masz na myśli row_timestamp?
Bleee...

> czy tez ulatwiajacych przyrostowa synchronizacje danych pomiedzy SQL'em
> z programem.
I to wszystko w epoce coraz szybszych i coraz stabilniejszych sieci..
Czy przypadkiem w wersji ADO.NET 2.0 nie istnieje możliwość pracy w
trybie state-full?

--
wloochacz