🚀 go-pugleaf

Dnia 23-06-2010 o 15:59:46 qaz <qazvox29a@wp.pl> napisał(a):

> No i znów siê powiesi³em. Siermiê¿nie strugam aplikacjê do obs³ugi  
> danych w
> MSSQL i tak:
> "bezpo³±czeniowy" model dostêpu do danych - DataSet, TableAdapter itd. i  
> tu
> pytanie:
> odpalenie aplikacji skutkuje otwarciem okienka logowania u¿ytkownika - w
> jaki sposób programowo modyfikowaæ connectionString na podstawie danych
> logowania ?
>
> po wstawieniu do projektu ¼ród³a danych widzê w app.config :
> ...
> <connectionStrings>
>   <add name="iCZ.Properties.Settings.icstr" connectionString="Data
> Source=QAZ\SQLEXPRESS;Initial Catalog=TEST;User  ID=qaz;Password=qaz"
> providerName="System.Data.SqlClient" />
> </connectionStrings>
> ...
>
> qaz
> baza sql'owa ma dopisanych "loginów" i zawiera tabelê z uprawnieniami
>
>

Czytasz connection string i go modyfikujesz. Albo sklejasz w aplikacji.

Tylko nie wiem po co chcesz to robić. Chyba nie sterujesz uprawnieniami w  
aplikacji uprawnieniami bazodanowymi?

Użytkownik "3P" <nospam@serwer.pl> napisał w wiadomości 
news:op.vetwzvfomsp0fz@mcs...
> Dnia 23-06-2010 o 15:59:46 qaz <qazvox29a@wp.pl> napisał(a):
>>...
>> jaki sposob programowo modyfikowac connectionString na podstawie danych
>> logowania ?
>>

> Czytasz connection string i go modyfikujesz. Albo sklejasz w aplikacji.
>
> Tylko nie wiem po co chcesz to robić. Chyba nie sterujesz uprawnieniami w 
> aplikacji uprawnieniami bazodanowymi?

Byc moze niezbyt jasno opisalem o co mi chodzi albo zbyt zielony jestem by 
zakumac.
Robiac projekt dzialam: [Data]->[Add New Data 
Source]->[Database]->[Dataset]->[New Connection]
no i tworze connectionstring (do bazy z mojego komputera ) dalej projektuje 
dataset'a itd.
Jak zrobic, by aplikacja po identyfikacji użytkownika "otwierała" baze z 
dami z logowania.
[btw: kiedy (w jakiej kolejnosci) realizowany jest kod tworzacy DataSet ?]
a moze totalnie bladze - dotad pisalem w VFoxPro
qaz 

Dnia 25-06-2010 o 10:12:44 qaz <qazvox29a@wp.pl> napisał(a):

>
> U¿ytkownik "3P" <nospam@serwer.pl> napisa³ w wiadomo¶ci
> news:op.vetwzvfomsp0fz@mcs...
>> Dnia 23-06-2010 o 15:59:46 qaz <qazvox29a@wp.pl> napisa³(a):
>>> ...
>>> jaki sposob programowo modyfikowac connectionString na podstawie danych
>>> logowania ?
>>>
>
>> Czytasz connection string i go modyfikujesz. Albo sklejasz w aplikacji.
>>
>> Tylko nie wiem po co chcesz to robiæ. Chyba nie sterujesz uprawnieniami  
>> w
>> aplikacji uprawnieniami bazodanowymi?
>
> Byc moze niezbyt jasno opisalem o co mi chodzi albo zbyt zielony jestem  
> by
> zakumac.
> Robiac projekt dzialam: [Data]->[Add New Data
> Source]->[Database]->[Dataset]->[New Connection]
> no i tworze connectionstring (do bazy z mojego komputera ) dalej  
> projektuje
> dataset'a itd.
> Jak zrobic, by aplikacja po identyfikacji u¿ytkownika "otwiera³a" baze z
> dami z logowania.
> [btw: kiedy (w jakiej kolejnosci) realizowany jest kod tworzacy DataSet  
> ?]
> a moze totalnie bladze - dotad pisalem w VFoxPro
> qaz
>
Po pierwsze nie używam tych kreatorów, więc nie do końca wiem jak to  
działa.

Ale aplikacja ma otwierać połączenie do bazy z danymi z connection stringa  
zapisanego w app.config.
Nie z loginem i haslem danego uzytkownika aplikacji. A rozumiem, że to  
chcesz osiągnąć.

On Jun 27, 10:18 am, 3P <nos...@serwer.pl> wrote:

> Ale aplikacja ma otwierać połączenie do bazy z danymi z connection stringa  
> zapisanego w app.config.
> Nie z loginem i haslem danego uzytkownika aplikacji. A rozumiem, że to  
> chcesz osiągnąć.

Spotkałem się już z kilkoma dużymi programami które tworzą nowego
dbusera dla każdego użytkownika i używają go do połączenie z bazą.
Właśnie po to, żeby wyeliminować przechowywanie danych połączenia w
programie.

Mógłbyś napisać dlaczego nie powinno się tak robić?

Pozdrawiam.

> Mógłbyś napisać dlaczego nie powinno się tak robić?

tak się zwykle robi w programie o 2 fizycznych warstwach (aplikacja - serwer 
bd).
w programie o 3 fizycznych warstwach (gui - warstwa aplikacyjna - serwer bd) 
jest zwykle jedno whardkodowane w warstwę aplikacyjną, a credentials 
użytkowników siedzi albo wprost w bazie aplikacji albo gdzieś obok (active 
directory, jakieś dodatkowe komponenty autentykacyjne).

jeśli chodzi o Twój problem, to nie przejmuj się tym, że masz zapamiętany 
connection string do bazy w środowisku developerskim. zrób klasę / managera 
połączeń, tam zapamiętaj właściwy connection string i podpinaj do obiektów 
dostępowych do bazy danych (niestety, w kodzie).

Wiktor Zychla 

On Jun 28, 11:18 am, "Wiktor Zychla" <wzyc...@nospam.com> wrote:
> > Mógłby napisać dlaczego nie powinno się tak robić ?
>
> tak się zwykle robi w programie o 2 fizycznych warstwach (aplikacja - serwer
> bd).
> w programie o 3 fizycznych warstwach (gui - warstwa aplikacyjna - serwer bd)
> jest zwykle jedno whardkodowane w warstwę aplikacyjną

Czyli jednak robi się i tak i tak :-)

> jeśli chodzi o Twój problem, to nie przejmuj się tym,
....

To nie mój wątek, byłem tylko ciekawy jakie sa przeciwwskazania dla
tworzenia db usera dla każdego application usera, no i chyba takich
nie ma, wszystko zależy od założeń.

Pozdrawiam.

Dnia 28-06-2010 o 13:54:00 Jakub Owczarski <jakub.owczarski@gmail.com>  
napisał(a):

> On Jun 28, 11:18 am, "Wiktor Zychla" <wzyc...@nospam.com> wrote:
>> > Mógłby napisać dlaczego nie powinno się tak robić ?
>>
>> tak się zwykle robi w programie o 2 fizycznych warstwach (aplikacja -  
>> serwer
>> bd).
>> w programie o 3 fizycznych warstwach (gui - warstwa aplikacyjna -  
>> serwer bd)
>> jest zwykle jedno whardkodowane w warstwę aplikacyjną
>
> Czyli jednak robi się i tak i tak :-)
>
>> jeśli chodzi o Twój problem, to nie przejmuj się tym,
> ....
>
> To nie mój wątek, byłem tylko ciekawy jakie sa przeciwwskazania dla
> tworzenia db usera dla każdego application usera, no i chyba takich
> nie ma, wszystko zależy od założeń.
>

Przeciwwskazaniem może być to, że rezygnujesz z connection poolingu.
Uzależnione od bazy. I tak uprawnienia aplikacyjne będziesz musiał zrobić  
sam.

Ja nie widzę sensu tworzenia "db usera" dla użytkownika aplikacji. Co to  
daje?

3P wrote:

> Ja nie widzę sensu tworzenia "db usera" dla użytkownika aplikacji. Co
> to daje?

Możliwość zrezygnowania z własnych procedur logowania do aplikacji. To duża 
oszczędność czasu i przede wszystkim o wiele bezpieczniejsze rozwiązanie niż 
tworzenie własnych procedur autoryzacji (o ile oczywiście całość jest w AD).
yamma 

Dnia 28-06-2010 o 18:04:03 yamma <yamma@wp.pl> napisał(a):

> 3P wrote:
>
>> Ja nie widzę sensu tworzenia "db usera" dla użytkownika aplikacji. Co
>> to daje?
>
> Możliwość zrezygnowania z własnych procedur logowania do aplikacji. To  
> duża oszczędność czasu i przede wszystkim o wiele bezpieczniejsze  
> rozwiązanie niż tworzenie własnych procedur autoryzacji (o ile  
> oczywiście całość jest w AD).
> yamma

Z wykorzystaniem AD może i ma sens. Jeżeli każdy z AD ma móc się logować.

A przy zakładaniu kont przez użytkowników samodzielnie to może być  
potencjalnie niebezpieczne.
Ponieważ aplikacja musi łączyć się do bazy na koncie ze sporymi  
uprawnieniami.

On Jun 28, 4:04 pm, "yamma" <ya...@wp.pl> wrote:
> 3P wrote:
> > Przeciwwskazaniem mo e by to, e rezygnujesz z connection poolingu.
> > Ja nie widz sensu tworzenia "db usera" dla u ytkownika aplikacji. Co
> > to daje?
>
> Mo liwo zrezygnowania z w asnych procedur logowania do aplikacji. To du a
> oszcz dno czasu i przede wszystkim o wiele bezpieczniejsze rozwi zanie ni

Tutaj widać jedną z wielkich zalet web aplikacji, można zjeść ciastko
i mieć ciastko :-)
Web aplikacje na prezydenta!

Pozdrawiam ;-)

> Przeciwwskazaniem może być to, że rezygnujesz z connection poolingu.

absolutnie nie.

przecież aplikacja i tak powinna działać w modelu "rozłączonym", tzn. 
otwierać/zamykać połączenie na czas kontaktu z bazą.
a takie zamknięte połączenie trafia właśnie do puli i stamtąd jest pobierane 
bez ponownej negocjacji z serwerem w kolejnych połączeniach.

pooling nie ma związku z architekturą aplikacji, to tylko techniczny 
mechanizm wspomagający wydajność połączeń do serwera.

> Ja nie widzę sensu tworzenia "db usera" dla użytkownika aplikacji. Co to 
> daje?

brak konieczności implementowania warstwy serwerowej.
taki program jest tańszy w projektowaniu/utrzymaniu/wdrażaniu, tyle ze 
oczywiście wdrożenie ma te specyficzne uwarunkowania (programy dla 
pojedynczego użytkownika lub sieci lokalnej).

Wiktor Zychla 

On 28 Cze, 23:01, "Wiktor Zychla" <wzyc...@nospam.com> wrote:
> > Przeciwwskazaniem mo e by to, e rezygnujesz z connection poolingu.
>
> absolutnie nie.
>
> przecie aplikacja i tak powinna dzia a w modelu "roz czonym", tzn.
> otwiera /zamyka po czenie na czas kontaktu z baz .
> a takie zamkni te po czenie trafia w a nie do puli i stamt d jest pobierane
> bez ponownej negocjacji z serwerem w kolejnych po czeniach.
>
> pooling nie ma zwi zku z architektur aplikacji, to tylko techniczny
> mechanizm wspomagaj cy wydajno po cze do serwera.
>
Tylko na co komu taki connection pooling? Jeżeli każdy użytkownik
łączy się do bazy swoim connection stringiem to masz tyle pul ilu
użytkowników pracujących. A nie o to chodzi w connection poolingu.

Widziałem aplikację ASP.NET, która właśnie tak działała :)

> > Ja nie widz sensu tworzenia "db usera" dla u ytkownika aplikacji. Co to
> > daje?
>
> brak konieczno ci implementowania warstwy serwerowej.
> taki program jest ta szy w projektowaniu/utrzymaniu/wdra aniu, tyle ze
> oczywi cie wdro enie ma te specyficzne uwarunkowania (programy dla
> pojedynczego u ytkownika lub sieci lokalnej).
>
Przecież dodawanie użytkownika aplikacji i tak trzeba zaimplementować.
Tylko zamiast INSERT USER INTO nasza tabela
jakieś CREATE USER, ADD server login itd. itp. A żeby to zrobić i tak
trzeba się jakoś podłączyć do bazy na "ogólnym" connection stringu.

> Tylko na co komu taki connection pooling? Jeżeli każdy użytkownik
> łączy się do bazy swoim connection stringiem to masz tyle pul ilu
> użytkowników pracujących. A nie o to chodzi w connection poolingu.

o to, o to.

przecież połączenie nie jest cały czas otwarte, tak się nie powinno 
komunikować z serwerem bo go to obciąża.

a skoro polączenia zamykam i otwieram, to pooling jak najbardziej przydaje 
się do nawiązywania kolejnych połączeń dla tego samego connection string - 
nie ma negocjacji autentykacji, bo połączenie może być pobrane z puli.

pozdrawiam
Wiktor Zychla 

Wiktor Zychla wrote:

> przecież połączenie nie jest cały czas otwarte, tak się nie powinno 
> komunikować z serwerem bo go to obciąża.
> 
> a skoro polączenia zamykam i otwieram, to pooling jak najbardziej 
> przydaje się do nawiązywania kolejnych połączeń dla tego samego 
> connection string - nie ma negocjacji autentykacji, bo połączenie może 
> być pobrane z puli.


A tak przy okazji to jak się powinno zamykać połączenia do bazy danych w 
Linq2SQL? Ja w swoim kodzie wywołuję dwie komendy jedna po drugiej (jak 
poniżej) ale gdzieś znalazłem informację że podobno wystarczy samo 
Dispose().

DBDataContext context = new DBDataContext(ConnectionString);
context.Connection.Open();

//tu jakiś kod

context.Connection.Close();
context.Dispose();

Czy powyższe jest OK czy coś tu jest nie tak.
(W powyższym kawałku nie uwzględniłem try-catch)

Pozdrawiam
Mariusz

On Tue, 29 Jun 2010 11:34:13 +0200, mk wrote:
> A tak przy okazji to jak się powinno zamykać połączenia do bazy danych w 
> Linq2SQL? Ja w swoim kodzie wywołuję dwie komendy jedna po drugiej (jak 
> poniżej) ale gdzieś znalazłem informację że podobno wystarczy samo 
> Dispose().

Tak, wystarczy.

> DBDataContext context = new DBDataContext(ConnectionString);
> context.Connection.Open();
> 
> //tu jakiś kod
> 
> context.Connection.Close();
> context.Dispose();
> 
> Czy powyższe jest OK czy coś tu jest nie tak.

Nie trzeba explicit zamykać i otwierać połączenia,
pozatym lepiej stanowczo zamiast ctx.Dispose()
skorzystać z bloku using():

using(DBDataContext ctx = new DBDataContext("zxc"))
{
    ...
}

I cała reszta się zrobi sama, i dodatkowo się upewni, 
że jeżeli w "..." coś pójdzie nie tak to nie zostawisz 
otwartych śmieci. DBDataContext jest disposable bo 
dziedziczy z DataContext, DataContext sprząta swoje 
rzeczy i deleguje Dispose() do Providera który z kolei
deleguje Dispose() do Connection'a(w przypadku SqlProvider'a 
do connection managera który zamyka połączenie).

> (W powyższym kawałku nie uwzględniłem try-catch)

Lepiej pozostawiać kompletne wycinki, minimalistycznie 
kompletne. ;-). bo nigdy nie wiadomo czy w try-catch 
coś nie jest ,,popsute" co byśmy znaleźli po drodze ;-).

-- 
Pozdrawiam,
Łukasz 'Maly' Ostrowski.      http://l3v.pl/

Dnia 29-06-2010 o 10:33:22 Wiktor Zychla <wzychla@nospam.com> napisał(a):

>> Tylko na co komu taki connection pooling? Jeżeli każdy użytkownik
>> łączy się do bazy swoim connection stringiem to masz tyle pul ilu
>> użytkowników pracujących. A nie o to chodzi w connection poolingu.
>
> o to, o to.
>
> przecież połączenie nie jest cały czas otwarte, tak się nie powinno  
> komunikować z serwerem bo go to obciąża.
>
> a skoro polączenia zamykam i otwieram, to pooling jak najbardziej  
> przydaje się do nawiązywania kolejnych połączeń dla tego samego  
> connection string - nie ma negocjacji autentykacji, bo połączenie może  
> być pobrane z puli.

Ale po stronie serwera połączenie też jest otwarte. I jeżeli masz 100  
użytkowników aplikacji
to po stronie serwera musi być tyle samo połączeń otworzonych. 100 pul po  
jedno połączenie.

Gdy łączą się na jednym wystarczy np 10.