I am using ASP.NET web form application and use ado.net to establish connection between SQL Server and my application to perform CRUD operation. I'd like to know: is any socket used to establish the connection like connection between server and client socket?
Actually I want a know how Ado.net establishes a connection with SQL Server to fetch data. I'd like to know what happens internally. Does Ado.net have any client socket part which connects to a server socket at the SQL Server database?
There is any documentation or article on the web to explain how ADO.net handshakes with SQL Server?
Thanks
That ADO.NET library wraps the OLEDB library which is at a lower layer and in turn encapsulates a lower level native C library called the ODBC. The ODBC opens a socket to the pre-defined SQL Server IP and Port to relays command using SQL Server's native TDS message format.
Related
I have tried searching the msdn and google but unable to find any sources that specifically touches on this question. At the moment I can only assume A JSON is used.
If so then I guess the SQL server would process the query received, and send the results in a JSON format back to the web app. Which also leads me to ask, is the query also sent to the SQL Server in a JSON format?
Any thoughts?
The Microsoft SQL Server Wikipedia provides the information I will need to know for Microsoft SQL Server If I choose to dive deep into the mechanics of the components/services.
For the original question of this post, communication is done through TDS protocol as stated in the section below.
The protocol layer implements the external interface to SQL Server. All operations that can be invoked on SQL Server are communicated to it via a Microsoft-defined format, called Tabular Data Stream (TDS). TDS is an application layer protocol, used to transfer data between a database server and a client. Initially designed and developed by Sybase Inc. for their Sybase SQL Server relational database engine in 1984, and later by Microsoft in Microsoft SQL Server, TDS packets can be encased in other physical transport dependent protocols, including TCP/IP, named pipes, and shared memory. Consequently, access to SQL Server is available over these protocols. In addition, the SQL Server API is also exposed over web services.
https://en.wikipedia.org/wiki/Microsoft_SQL_Server#Architecture
Is it possible to compress the data transfer between the asp.net and sql server r2 . I know about packet size in sql server using SinglePage Allocator and MultiPage Allocator
Data Source=(local);Initial Catalog=AdventureWorks;"
+ "Integrated Security=SSPI;Packet Size=512"
The above is a SinglePage Allocator. I have to know whether it is possible to reduce the data transfer when i save a form details to the sql server using asp.net(c#) and sql serverr2
No, compression is not supported by SQL server natively. There are options, you can tunnel traffic through a VPN with compression enabled or setup a web service on SQL server that exposes the data you need access to. Most web services and clients support gzip compression and you will benefit from this. Alternatively, there are some commercial options that will support compression of SQL data.
See this post for more details:
Possible to compress SQL Server network traffic?
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.
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
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).