VisualStudio C# - Okienko Logowania do bazy SQL...
Ted
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.
Robert Winkler
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
Ted
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.
Robert Winkler
> 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
> 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.....
> A to spowolni prace calej aplikacji...
>
> 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.
wloochacz
>> 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
>> 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.....
>> A to spowolni prace calej aplikacji...
>>
>
> 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.
> albo korzystasz z tego ze jest implementuje ona interfejs IDisposable
> polaczenie z baza nie jest zamykane, ale dalej otwarte trafia do
> wewnetzrnej puli polaczen
> Nie istnieje wiec zaden narzut czasowy na tworzenie kolejnego polaczenia.
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
Wiktor Zychla
> 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