Zaraz mnie trafi !
Napewno to temat z podstawóki....

Uruchamiajac projekt startuje mi forma frmStart - a w nim definicja obiektu
klasy cnn,
która bede przekazywal (po uzyskaniu polaczenia z baza danych) do kolejnych
form jako
podstawe pracy tych form z MSSQL
***
----------------------------------------------------
---------------------------------
public partial class frmStart : Form
{
protected SqlConnection cnn = new SqlConnection();

public frmStart()
{
InitializeComponent();

//Tutaj wywoluje okienko logowania, które ma mi ustawic cnn
frmServerConnect frmServerConnect_ = new frmServerConnect(ref
cnn);
frmServerConnect_.ShowDialog();
----------------------------------------------------
---------------------------------
Powyzszy poczatek kodu glównej formy przekazuje nowy obiekt cnn jako
referencje
do formularza okienka logowania (frmServerConnect)

Niestety w okienku logowania adres obiektu nie jest przekazany do
tamtejszego tez lokalnego obiektu cnn
A musi tak byc aby móc operowac na cnn poza konstruktorem klasy.
----------------------------------------------------
---------------------------------
public partial class frmServerConnect : Form
{
protected SqlConnection cnn;

public frmServerConnect(ref SqlConnection cnn)
{
InitializeComponent();

this.cnn = cnn;
this.Text = "Logowanie";
}
----------------------------------------------------
---------------------------------
Co ciekawe robilem próby zmieniajac obiekt SqlConnection na StringBuilder i
robilem
próby "tekstowe" jest to samo.
Zmiany sa wykonywane jesli operuje na cnn bezposrednio w metodzie
konstruktora okienka logowania.
Mam wrazenie, ze polecenie w okienku logowania nie dziala (nie przekazuje
adresu do lokalnego obiektutylko robi kopie)
this.cnn = cnn;

Prosze o jakiekolwiek opinie.
Dziekuje z góry.
Ted.


__________ Informacja programu ESET Smart Security, wersja bazy sygnatur wirusow 4665
(20091206) __________

Wiadomosc zostala sprawdzona przez program ESET Smart Security.

http://www.eset.pl lub http://www.eset.com

do góry

Witaj
Ni potrzebnie przekazujesz obiekt SqlConnection poprzez ref,
uzywa sie tego TYLKO w dwóch przypadkach
- dla typów wartosciowych, jesli nie chcesz tworzyc kopi danego obiektu
przy kazdym wywolaniu
struct MyStruct { int field; }
static void Main(){
MyStruct s;
Method(ref s);
}
static void Method(ref MyStruct s){
s.field = 2;
}

- dla typów referencyjnych, jesli dana metoda moze utworzyc nowa instancje
obiektu
nadpisujac ta z która zostala wywolana

static void Main(){
SqlConnection con = new SqlConnection();
Method(true, ref con);
}
static void Method(boolean recreateConnection, ref SqlConnection con){
if(recreateConnection)
{
con = new SqlConnection();
}
else
{
con.Close();
con.Open();
}
}

Nie podales pelnego zródla klasy frmServerConnect
nie wiemy wiec czy przypadkiem nie tworzysz w tej klasie
nowej instancji obiektu polaczenia,
jesli tak, to nie ma prawa to dzialac.
Ref i out dzialaja tylko na poziomie pojedynczych metod, a nie klas.

ps.
Bledem w przypadku .NET'a i MSSQLa jest tworzenie jednego obiektu polaczenia
i utrzymywanie go przez caly czas zycia aplikacji.
Bezpieczniej jest tworzyc i niszczyc polaczenia za kazdym razem gdy jest ono
potrzebne,
pooling polaczen w przypadku MS SQL'a dziala wysmienicie
i nie ma sensy utrzymywac polaczenia dluzej niz to jest konieczne.

--
____________
Pozdrawiam
Robert Winkler

do góry

No tak....
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 !!!

Pozdrawiam Ted.

do góry

> 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.

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.

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.
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.
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,
czy tez ulatwiajacych przyrostowa synchronizacje danych pomiedzy SQL'em z
programem.
--
____________
Pozdrawiam
Robert Winkler

do góry

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

do góry

> Co mi z poolingu jak to zadziała tylko na jedynie słusznej bazie danych
> jaką jest SQL Server od MS'a?

nie sprawdziłeś w dokumentacji innych dostawców czy obsługują pooling i z
góry zakładasz, że nie.
polecam więc lekturę dokumentacji czegokolwiek, OracleConnection,
NpgSqlConnection czy MySqlConnection.

>> 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 :)

co ma kod sprawdzający dostępność zmian w bazie do ADO.NET jako takiego?

przeciwnie - ADO.NET wspiera mechanizm "dependency", dzięki któremu możliwe
jest otrzymywanie powiadomień automatycznie.
polecam lekturę dokumentacji np. SqlDependency oraz poczytanie o tym jak to
jest zaimplementowane.

> BTW - a co daje ADO.NET do pomocy? Chodzi mi o rozwiązywanie konfliktów...

dokumentacja o tym mówi - ADO.NET wspiera model optymistyczny -
powiadomienia o modyfikacji przez kogoś innego pomiędzy Twoimi.

> Masz na myśli row_timestamp?
> Bleee...

dlaczego akurat zaraz row_timestamp czy cokolwiek innego? to można zrobić na
różne sposoby.
polecam sprawdzić jak to robi ADO.NET vs jak to robi XPO.

> Czy przypadkiem w wersji ADO.NET 2.0 nie istnieje możliwość pracy w trybie
> state-full?

w jakim sensie statefull?

pozdrawiam uprzejmie,
Wiktor Zychla

do góry