Login, Connections and Forms

[Guest]

Hi,


I've cross-posted this from the Windows Forms list ... I suppose the
question is actually a ADO.NET questions ... but it is about using this in a
Windows Forms context.

I'm developing an Windows forms based app that will draw data from a SQL
Server 2000 system, that is set to use SQL Authentication (i.e. connection
string must pass unameword).

Given that various forms will need to use a SQL connection to generate data
for data grid's etc ... how can I pass this authentication information around
the various forms?

A solution is to start the application from a VB.NET class, that has a
shared member with the connection string (set once the user completes the
login)

Or create a shared connection object? Should I create a new connection
object for each form?

I currently test whether the login credentials are correct by enclosing
within a try..catch clause an attempt to open and close a connection, failure
will indicate invalid details (or perhaps a dead SQL Server!) ... any
improvements on this?

I assume that when using the form designer in VS.NET that if I manually
program the connection (i.e. outside the section of code written by VS.NET )
that I can point the adapters/datasets etc. to the required connection.

There are a few questions here ... but I've not so far found any answers
here, on Google or elsewhere !

Thanks in advance for help

 

[William \(Bill\) Vaughn]

You're reading the wrong books--I discuss this approach in my book.
Sure, create a global connection string in a module so all forms can see it.
Each form can create its own Connection object (as they can't be used by two
operations at the same time), and open/close each connection as needed. When
connections are made, they'll be pooled so only the first time a connection
is opened will you have a bit of a delay.
As far as authentication, it's okay to use SQL Server authentication, but it
requires more DBA administrative work on your part--unless the application
is using a Login/Pwd of its own. Most folks use SSPI nowadays.

hth

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________

"Craig - A Healtchare IT developer"

 

[Sahil Malik]

Craig,

I don't know your reasons for SQL Server authentication, but that is usually
not my first choice for various reasons - the biggest being security since
now you have a password you need to keep safe. However, on an internet based
environment, you can't go for windows auth - but if your sql server is
exposed to the internet, you have bigger problems anyway.

A good approach to this would be to create a database access layer, which is
simply a class or a group of classes abstracting database access. You can
either use the Microsoft Data Access application block, or you can copy the
code verbatim quo from my book.

Once you have done that, there is the question of "Where to store the
database connection string". Depending upon the complexity and nature of
your application, you could choose a simple config file approach viz,
app.config, and put an appsetting in it, though the user could then easily
open the file in notepad and look at the password, or you could create a
directory called "Config" which is encrypted and kept safe using the
Microsoft Security Application block via two methods -

a) Using a key that is stored at a location accessible only to the operating
system.
b) Encrypting the password directly in a similar manner.

Ok good, once you have that much, your database access class would read the
connection string, and abstract all database access. So in essentiality, you
would very simply ensure that if any of your forms/modules request a dataset
to be filled (or whatever), they donot leave a connection open - a
connection which can then be pooled automatically by ADO.NET.

If this were a server application, I would go one step further and ensure
that your database access class is then wrapped within enterprise services,
so in a deployed administrative mode, an adminstrator could then monitor it,
and control instance creation of it, depending upon the load, and even shut
it down in case of a security problem.

Hope that helped !!

- Sahil Malik
You can reach me thru my blog -
http://www.dotnetjunkies.com/weblog/sahilmalik



"Craig - A Healtchare IT developer"

 

[Cor Ligthert]

You're reading the wrong books--I discuss this approach in my book.

LOL

Real direct text Bill.

Cor

 

[William \(Bill\) Vaughn]

Something has to pay the bills (so to speak).

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________