Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!
all the database querying should be done in the .Net web application running on the web server, the results are then passed to the users browser.
The end users PC should never be making a direct connection to the database
Web app running on IIS opens a connection to the SQL Server using ado
Creates a ado recordset. puts the SQL you want in it. open it and then scroll through the results.
It all get complicated when those fancy controls which can bind to the data come into play.
I think there are plenty of examples on www.asp.net
One option is ADO.NET using the SqlConnection and SqlCommand classes that are wrappers around the Sql Server provider. Another option is LINQtoSQL which is my preference and others are OleDB and ODBC which are not worth considering since the first two will give better performance and integration.
There's nothing to stop you doing a mix of traditional ADO.NET and LINQ in your web app, but the nice thing about LINQ is that is effectively builds your data layer entities for you making the data returned from the db nice and easy to work with. LINQ also provides good support for SQL Server stored procs and functions
The setup is true client / server when you consider the web application to be the client and the Sql server to be the server, but there's no reason why the Sql Server and the web application must be on the same box and anyone worth their salt developing a public facing web site (whatever the technology choice) would never implement a setup like this because there's a potential security risk in putting your db on a public facing box.