ASP.NET application load balancing - asp.net

I have an ASP application sitting on 2 servers, using a db in SQL Server 2012. The SQL Server uses AlwaysOn Availability groups but when these failover the client connecting to the ASP.NET application terminates. I have looked into the SQL driver which as it turns out the app is using SqlClasses so not using ODBC driver (from what I have deduced I presume that logic is sound but correct me if I'm wrong).
Another suggestion has been made that I load balance the 2 app servers and that will seamlessly allow failover underneath without the client loosing connection, is this a viable way to go? We don't have much control over the applications code to ask it to try the connection again after failing....
Many thanks in advance.

Try defining the failover partner in your connection string.
Data Source=myServerAddress;Failover Partner=myMirrorServerAddress;
Initial Catalog=myDataBase;Integrated Security=True;
And also check out MultiSubNetFailover property in .NET 4.5

Related

Connect to Oracle 10g through Internet using Pool

Our .Net webservice provides data for about 1000 users and 3000 request per seconds.
If it connects to a database reside on LAN, every thing is OK. But when it connects to a database through The Internet, and naturally, connection will some times not stable and it lead to dead connections. In client's connection pool, connections are still there and on the server also but they are dead already. No connection will be created after that because of full connection pool.
If that happend, we have to reset IIS :( and it happens a lot.
We are using free version of DotConnect 7.3.132.0, Oracle 10g and webservice written in .Net 2.0.
Please help :(
We move our webservice to the same LAN of DB. Every thing is fine.

OLE DB Provider for SQL Server works, but not SQL Native Client

I'm running out of ideas so checking if anybody can shed some light.
2 tier Client-server application
SQL Server 2005
Workstation: Windows XP
Client-Server Application 1 uses SQL OLE DB Provider. (Provider=SQLOLEDB.1)
Client-Server Application 2 uses SQL Native Client. (System.Data.SqlClient.SqlConnection)
Somehow, application 1 works well but application 2 needs to have Timeout in connection setting to be 30 seconds to make it work.
Using a tip I learned from JohnnyCoder's Database Connectivity Test with UDL File, I tracked down the problem is somewhere around driver. When I try Microsoft OLE DB Provider for SQL Server, it connects immediately. When I try SQL Native Client, it doesn't take long. It fails even it I set connection timeout to be 60.
Both of the applications work well on other installations but not on one specific site. So it has to be related to some environmental settings such as security, firewall, etc.
I tried installing new SQL Server 2005 Native Client on workstation. No luck.
So my question is:
Why does Application 2 ever make it work when the client actually cannot connect? Is there internal logic to use OLE DB when SQL Native Client timeout happens?
What else would you take a look?
Answer: their network firewall blocked TCP/IP packets.
As a result, SQL Native Client timed out with TCP/IP after 20 seconds and then tried Named Pipe which made it work.

Multiple connections on a single .mdf database (ASP.net) SQL Server

I'm trying to place a .mdf database on a Computer A and access it simultaneously on Computer B but I'm having an error that says I cannot access the mdf file because it's being used by another process.
The setup is, the database is hosted on a Public folder in Computer A. I have Visual Studio running on both computers, and Computer B accesses the database on Computer A.
Computer A Connection path string:
C:\Users\Public\database.mdf
Computer B Connection path string:
\192.168.254.8\Public\database.mdf
Is there some sort of setting that I do not know of to enable multiple access on a db? Or this is not possible?
EDIT:
Let me rephrase my question, sorry.
There are two computers connected via a network, and I want to access one Visual Studio solution/project website. I wanted to do this as a demonstration, is it possible?
You should have an instance of SQL Server (even express) running on the host machine.
All requests from the clients should use the standard mechanisms for connecting to that server instance. In other words, they won't run their own copy of SQL Server, instead they will connect to the instance running on the host machine.
Simultaneous or direct access to Database files under any DBMS control either a very bad practice or simply impossible.
Use proper DBMS tools to access the data.
And yes - its possible to access Web site project for demo.
Install SQL Server on the host machine (the one that you want to keep your database on).
Then in Visual Studio, use the "Server Explorer" to locate the remote instance of the database. From there, you can utilize the remote instance of SQL Server in your connection string, thus allowing you to connect multiple computers to a single database.
Using two instances of SQL Server to connect to the single .mdf file is a very bad practice.
Instead of specifying the MDF file in your connection string (which, I believe, uses a form of User Instancing), you should use SQL Server Management Studio (SSMS) to attach the MDF. Then connect to SQL Server, rather than to the MDF.
You may need to move the MDF and LDF files to a place where the SQL Server identity can access them, rather than keeping them in your VS project.
Most projects keep scripts to create the DB in their VS project, but not the binary MDF itself.
When you deploy, the process is similar: use SSMS to attach the MDF on your server.
Yes, If 2 or More Computers are connected by networks like LAN You can access the Database Database1.mdf (say) from another SQL Server by entering its user name / Password /by Visual studio connection.
Disadvantages:
If more than 7~8 systems are accessing same Database same time System response slows down and Hangs up or may result error like connection pool exceeded or Device not responding..
In Big Companies they use Huge Multi-core & Multi-Processer based sever which will respond faster.
Overcome: while writing Applications Use Connection Open and Close Particularly while executing the SQL queries in other time it should be closed.
Best Programer uses Transaction instead of using normal methods. Transaction Makes Every User Access Database With valid and successful Execution of queries. These Queries (Transaction Queries) mainly executes on client machine and later updates the same over Main server when it got Time slot for it(synchronize).

SQL connection is too slow

We have a business web application in ASP.NET + SQL Server 2008.
In the beginning, SQL Server and IIS were on the same machine. Now we bought another machine. Current configuration is IIS machine plus SQL Server machine, and they are connected by a 1gb LAN connection.
With this configuration our web application is slower than before. Max bandwidth is 1-2% of network, about 15mbps.
When we use another threads to the same SQL Server from the same IIS machine, network use is higher. So this is no problem with SQL Server.
Ho we can make higher bandwidth for this SQL connection?
Specs:
.Net 3.5
SQL Server 2008 Standard
file transfer can use 100% of LAN
SQL connection by TCP/IP protocol
SQL logins
Pool tested with enable and disable
Ado.Net by subsonic without LINQ
Use Sql Server Profiler to make sure you pool DB connections. You do cache DB query results, do you? Also make sure that the DB server has good enough hardware. There might also be some authentication or name resolution problems which are eventually resolved but will take time. These tends to cumulate, so many small delays will grow into big one.

Not able to connect to the SQL Server data from asp.net app

We are upgrading from an environment where the development web server, the SQL Server 2005, and SQL Server data are all on the same machine, a Windows XP Machine. We are upgrading to having the web server on one Windows 2008 server, the SQL Server on a 2nd Windows 2008 Server, and to Server to a Windows 2008 server, nd the data on a SAN.
Now we are getting the error message:
A connection was succesfully established with the server, but then
an error occured during the login
process. (provider: named pipes
provider, error 0, no process is on
the other end of the pipe.)
The network guy thinks it is a problem with the connection string:
<add name="CNString"
connectionString="Data Source=WEBSERVER;
Initial Catalog=PCIdb;
User ID=sa;Password=pass;"
providerName="System.Data.SqlClient"/>
Can anyone help out here?
Is your SQL Server really called WEBSERVER (DataSource="WEBSERVER") ??
Also, I would never EVER use the sa account in a connection string - NEVER, period. Use an application specific user or something, but do not use the sa account under any circumstances.
This can be caused by any number of reasons, but the first thing to look at is the configuration and setup of the SQL Server itself.
Are named pipes enabled on the server? You can check this through the server configuration manager (on the SQL Server machine itself).
Is the user on the connection string (or the connection pool user if you are using SSPI) setup on the server?
Note:
I do hope the connection string you put up is an edited version of your real one, as there are a couple of issues with it:
Using the sa login - you should never do that as now any SQL exploit can do any damage it wants
Calling a sql server "webserver" - a really confusion naming decision
When it comes to connection strings, look at connectionstrings.com - they hold a good list of valid connection strings to many databases using different providers.
I got that error before...Make sure SQL server services are started
If that's not it, change the authentication mode to both server and windows.
It could be a connectionstring problem. Try comparing your connectionstring to the connectionstrings at http://www.connectionstrings.com but it could also be that the remote connection or the remote server (the webserver in this case) isn't allowed to connect to SQL.
Check if remote connections are allowed and named pipes and/or TCP/IP protocols are enabled on the database server.
But, based on the scenario you've described, I'd say it's the database-end that's refusing the connection (since you've already had a working solution).

Resources