Sql Server isn't closing a connection to linked Server after execution - c#

I am using a linked server to update records in AS/400. It isn't closing the connections properly. On the AS/400 side there are still a number of connections idle. In the sql log it is showing:
EXCEPTION_ACCESS_VIOLATION writing address 0000000000000024 at 0x0000000077BDE4B4
It doesn't appear that it is every time we open a connection and update the file on the AS/400 side. We updated 222 records and there were still 210 connections open. I would expect there to be 222.
We are calling a stored procedure from a .NET app. In the stored procedure we are executing:
EXECUTE (#as400Query) at S100405D
Where the as400Query is a string with the update statement and S100405D is the linked server. The records are getting updated in the AS/400, so that isn't an issue. Just seems that when trying to close the connections, there is an error. Also I checked the settings on the linked server and the connection timeout = 0 (off). Not sure if setting a timeout will close them, or it won't matter because it is throwing an error anyways.
Any help would be greatly appreciated!
Brian

are you submiting any sort of code to close the connection on the AS side? SQL server will only close its connecion, any other connection opened on any other RDBMS won't be managed by SQL

As an IBM i programmer, I would not expect to see any errors during a stored procedure call. Rarely, the OS will throw an exception if there is a parameter mis-match. The most common is the caller (C#) using VARCHAR and the IBM side declaring it as CHAR.
Aside from that, have the IBM people make sure they are current on PTFs.
As a style matter, I would not expect to see:
open connection
CALL proc
close connection
for each row to be updated. Rather, I would expect
open connection
loop
CALL proc
end loop
close connection

Related

Dealing with SQL Server query exceeded (number of columns/Allowable size) issue

I'm constructing a query that joined a lot of tables. When I execute the query by select all columns, SQL Server throws an error
A transport-level error has occurred when receiving results from the server. (provider: TCP Provider, error: 0 - The specified network name is no longer available
When I replace the * with a few columns, it works fine. So I assume the problem is due to the result has exceeded the allowable size per row.
Now I'm wondering will it be ok to construct such a stored procedure and implement it in my WPF application?
Seems like you are having a timeout problem.
Have you seen this post?
In the link i added someone is claiming that the solution was to increase the "connect timeout" (Probably the select statement is taking too long).
If this does not solve your problem then you can try diagnosing it by:
1) Assume you were making remote connection, ping ,
telnet , or net view \ or see
firewall setting on the remote server to check whether the network is
still good to make sure remote server is still reachable, and contact
your network administrator to fix those problems.
2) You can give a retry by running your client app see whether the
problem went away.
3) If 1) and 2) passed, you might open sql profile to nail down which
client operation to cause sql server terminate connection, and check
server errorlog or application event log find out any clue.
If you were making local connection, it is probably reason 3).
Note: this is copied from the attached link.
Regarding whether you shold use a Stored Procedure check this post.

Watching state of OracleConnection

I'm using ODP on my Oracle DB application.I registered to OracleConnection.StateChange event for watching the state of the connection. When i disconnect the db connection the event fires but for example if the internet connection is lost there is no action.
How can i handle these kind of(internet conenction lost etc.) situations via the StateChange event?
Or do i have to create a thread for checking the connnection state regularly?
If yes how can i check the connection because i checked the state and it seems to be open even i unplug the internet cable.
Regards.
The common way is to issue an unexpensive sql statement just before the connection is used for something. On oracle it is something like 'select 1 from dual', on ms-sql 'select 1'. This sql forces a roundtrip to the server and lost connection to the server is reported.
JBoss is using something called check-valid-connection-sql. Others have other names.

Getting Connection lost contact even though a new connection is created

I'm writing an ASP.NET web application. The database is Oracle. I've recently noticed that if I leave the application open for a while without doing anything and then try to access the database I get "ORA-03135: connection lost contact" error. One reason I can think of first is the connection timeout but I create a fresh new connection, open it, do what I need to do and "finally" close it every time I access the database. What's more interesting is after I get this error, I don't have any problems any more with connecting to the database. Do you have any ideas as to what the problem might be?
Are you using a connection pool?
In this case you can get this behaviour because the Oracle Connection Pool returns a "disconnected" connection. Try adding Validate Connection=True; to your connection string.

ASP.NET SqlConnection Timeout issue

I have run into a frustrating issue which I originally thought was a connection leak but that does not seem to be the case. The secnario is this: the data access for this application is using the Enterprise Libraries (v4) from Microsoft. All data access calls are wrapped in using statements such as
using (DbCommand dbCommand = db.GetStoredProcCommand("sproc"))
{
db.AddInParameter(dbCommand, "MaxReturn", DbType.Int32, MaxReturn);
...more code
}
Now the index of this application makes 8 calls to the database to load everything and I can bring the application to its knees by refreshing the index about 15 times. It seems that when the the database reaches 113 connections is when I recieve this error. Here is what makes this weird:
I have run similar code with the entlib on high traffic sites and have NEVER had this problem ever.
If I kill all the connections to the database and get the production application back up and running everytime I refresh the application I can run this SQL
SELECT DB_NAME(dbid) as 'Database Name',
COUNT(dbid) as 'Total Connections'
FROM sys.sysprocesses WITH (nolock)
WHERE dbid > 0
GROUP BY dbid
I can see the number of connections actively increasing with each page refresh. Running the same code on my local box with the same connection string does not cause this problem. Further if the production website is down I can fire up the site via Visual Studio and run it fine and the only difference between the two is that the production site has Windows authentication turned on and my local copy doesn't. Turning windows authentication off seems to have no effect on the server.
I have absolutely no clue what is causing this or why the connections are not being disposed of in SQL Server. The EntLib objects do no explose .Close() methods for anything so I can't explictily close the object.
Any thoughts?
Thanks!
Edit
Wow I just noticed that I never actually posted the error message. Oy. The actual connection error is: Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool. This may have occurred because all pooled connections were in use and max pool size was reached.
Check that the stored procedure you are executing is not running into a row or table lock. Also if you can possibly try to deploy in another server and check if the application would crawl again.
Also try to increase the maximum allowed connections for your SQL server.
think the “Timeout Expired” error is a general issue and may have seveal causes. Increasing the TimeOut can solve some of them but not all.
You may also refer to the following links to troubleshoot and fix the error
http://techielion.blogspot.com/2007/01/error-timeout-expired-timeout-period.html
Could it be a configuration issue on the server?
How do you make a connection to the database on the production server?
That might be an area worth looking into.
While I don't know the answer I can suggest that for some reason connections are not being closed by you application when run in production. (Stating the obvious)
You might want examine your network configuration between the web server and sql server. High latency networks can cause connections not being closed in time.
Also it might help looking at the performance counters listed in the end of the following msdn article:
http://msdn.microsoft.com/en-us/library/8xx3tyca%28VS.71%29.aspx
Finally, if nothing else helps, I'd get debugger and Enterprise Library source code on production and debug your code inside the enterprise library to find out why connections are not being closed.
Silly question are you properly closing your DataReader? If not this could be the problem and the difference in behaviour between dev and prod can be caused by different garbage collection patterns.
I would disable connection pooling and try to suppress it (heh). Just add ";Pooling=false" to your connection string.
Or, perhaps you could add something like the following 'cleanup' code to your page (which closes any connection left open when the page unloads) - right in the 'using' clause:
System.Web.UI.Page page = HttpContext.Current.Handler as System.Web.UI.Page;
if (page != null) {
page.Unload += (EventHandler)delegate(object s, EventArgs e) {
try {
dbCommand.Connection.Close();
} catch (Exception) {
} finally {
result = null;
}
};
}
Also, make sure you've enabled the 'shared memory' protocoll if your SQL server and IIS are on the same machine (a real performance booster)!

SQL Server 2000 Server Errors

The same database and application acts weirdly on our test machine, but it works nice on other computers.
On the test machine:
We get SSL error exception. We fixed that based on an MS KB article, but after that it said
"Server error" or "General network error" and slowed down to 1-2 stored procedures/second.
The profiler said that we have 2000-2500 connections when the application runs. The same application has only 5-10 connection on other machines. I think the random error messages are caused by this huge connection count.
We reinstalled SQL Server, turned off the connection pool, and closed all datareaders.
What else can I do? Is there a "deeper" configuration tool for MSSQL2k? Any hidden component/ini/config/registry key? Or another profiler other than SQL Profiler that I can use?
Yet another possibility(!):
Multiple Fixes for SQL Server .NET Data Provider
When the SQLCommand.CommandTimeout is
set to zero, you expect an infinite
timeout. However, versions 1.1 and 1.0
of the SqlClient provider incorrectly
timeout when a response from SQL
Server is broken into two packets.
Immediately upon receipt of the second
packet, versions 1.1 and 1.0 of the
provider incorrectly timeout. The fix
that is included in this article fixes
this issue so that the command will
have an infinite timeout.
What happens if you turn off OLE DB Resource Pooling?:
'For SQLOLEDB provider
'strConnect = "Provider=SQLOLEDB;server=MyServerName;OLE DB Services = -2;uid=AppUser;pwd=AppUser;initial catalog=northwind"
' For MSDASQL provider
'strConnect = "DSN=SQLNWind;UID=Test;PWD=Test; OLE DB Services= -2"
Another thing to look at is whether you are always specifying the type and direction of stored procedure parameters from ADO.NET.
What happens internally is sqlClient converts the parameters which you have set in ADO.NET to the relevant datatypes in the stored procedure parameters. But this can fail when you are sending nText parameters where it might result in a wrong conversion.
Also, I would check to see if you are sometimes passing very long statements in stored procedure parameters.
Thanx again Mitch, sadly none of those ideas was real solution. No suprise - it seems that those error messages from MSSQL are random.
Random, I mean:
After X[1] concurrent connection MSSQL stops to close connections automatically, and the connection pool grooves huge. Before X, I saw only 5-10 connections[2] / but after that there was 2500 and MSSQL chrased.
In this case, MSSQL throws non deterministic error messages like 'General failure', 'User (null)' etc.
We had unclosed connection in our DAL (hidden since 2 years...brrr), and when we used that to much, it caused this wreid error.
[1] I have no idea about concrete value of X
[2] I've used this query:
SELECT
DB_NAME(dbid) as DBName,
COUNT(dbid) as NumberOfConnections,
loginame as LoginName
FROM
sysprocesses
WHERE
dbid > 0
GROUP BY
dbid, loginame

Categories

Resources