I apologize in advance for how vague this question is. I had a connection string to SQL Server 2012 on a remote server from my work laptop using Visual Studio 2015 and it worked well for connecting to my database to populate asp:dropdownlists etc. on my web app as well as generating reports using SSRS.
That was last week, today I'm getting the error indicated in the title of this post. Below is my connection string minus the specific server name and ip address. Something changed between last Friday and today that this error is popping up.
Provider=SQLOLEDB.1;Data Source=[Server Name];Initial Catalog=[Database Name];Network Address=[Server IP Address]
I admittedly am at a loss as to how to troubleshoot this. I would endlessly appreciate a few leads as to what I can check out, whether there is some sort of log that tracks failed log ins, or some other means of finding out the source of the problem, or what changed.
Thank you so much in advance for helping a brand new programmer.
The problem could be any of the above problems, or a SQL Server configuration issue, or a network problem, or a permissions issue. The first thing I usually try is connecting with SQL Server Management Studio with the same settings. This will give a much more detailed message with specifics of what is failing. In short, all of the numbers in the error message are important and help pinpoint the real problem. You can also use https://msdn.microsoft.com/en-us/library/mt750266.aspx for some other techniques to diagnose/repair the issue.
Related
I use CheckPoint VPN to log in to my place of work's servers to work remotely. The VPN has been working (mostly) fine all year, and I haven't changed any of the settings, but this morning, when I tried to log in, it's giving me the "Arg_NullReferenceException." I can't seem to find anything on this particular error on google.
I have tried restarting my computer, because it's not the first issue I've had with CheckPoint VPN (though it is the first time I've seen that error message), and a restart usually resolves whatever issue I'm having. I've also tried creating a new connection with the same settings, but I'm getting the same error with that one, too.
I'm not entirely sure what other information I would need to provide. I'm also not sure if it's a problem on my end, or on the company servers. I have already emailed tech support, but I thought I should be thorough.
This is a known issue. I have been jumping through hoops trying to get the capsule client to work. Raise a ticket with TAC if you have support. If not then you can download the E86 Endpoint connect client and run it. That has been my work around for this issue.
They just issued an update to the Capsule via the Microsoft Store. It seems one of the recent Windows Security Update broke the L2TP protocol within windows.
BizTalk Server complains from time to time:
Reading error. Failed to recover from previous error. SQLServer: XXX, Database: BizTalkMsgBoxDb.
Should I care this, or simply ignore it?
Looks like a temporary loss of connectivity to the MessageBox. Not good, but also not critical as long as connectivity is restored quickly enough. The specific error message relates to BAM, which you can switch off if not being used. However, the problem will affect BizTalk as a whole.
You would have to find out what's causing the loss of connectivity and address that. Might not be easy, mind you, I have seen this happening on DEV boxes with both BizTalk and SQL Server on the same box...
BizTalk Server 2006: BAM FAQ
As per Fabio, the message you received is likely to be specific to BAM.
The types of error that you get in your eventlog if BizTalk hosts and ENTSSO does lose connectivity with SQL are listed here
These errors are more serious and can result in the loss of messages (Hosts and Receive Locations are usually stopped).
These errors can occur intermittently and then a minute or two later you see
Communication with MessageBox BizTalkMsgBoxDb on SQL Instance XXX has
been re-established
Common causes of BizTalk : SQL Connectivity issues are listed here
We've found the usual culprit of connectivity issues to be the TCP/IP SynAttackProtect security feature on the SQL Server host - BizTalk can hog a lot of SQL Connections, especially during a 'ramp up' of connections required when a batch of messages comes in after a protacted idle period.
my application is developed on classic asp, but also uses asp.net as I am migrating the application on .Net. Its using SQL server as database and hosted on Windows server 2003.
Now the problem is that the application continue to work perfectly fine for a long time but then after some time SQL server gives timeout error and it could fulfill any of the requests made. It doesn't get fixed even when I restart my SQL server or even IIS, ultimately I have to restart my server every time which only fixes the problem.
Any idea what might be causing the problem? Just to give a rought idea, the site is used by around 300 people at peak times.
Any idea what might be causing the problem? Just to give a rought idea, the site is used by around 300 people at peak times. I am certainely closing connection everywhere, my end code on each page closes the connection. If an error occurs before the end page, the expection handler closes the connection. So I am sure that closing the connection isn't an issue. And that there are no open connection if I see the sql logs. Our server, only one box, has SQL Server, IIS, iMail (our mail server). After I had restarted SQL Server, it did not solve the problem. Only restarting Windows Server, it worked. From perfom, IO usage is quite high. Is there any suggestions?
Thanks,
At the very least, are you closing the connection to the database, once you are done using it in the code? Also, how does your connection string look like? does it use connection pool?
EDIT: I saw your comments. Are there pending transactions to be committed?
It sounds a lot like there's an unmanaged resource of some kind that you aren't cleaning up properly. We don't have enough information to know exactly what that resource might be, so all we can do is guess.
My first instinct is database connections, except that restarting that restarting sql server should fix it if that were the case. Next on the list is file handles and threads, so if you do any multithreading work or extra file io that would be something to look at. Remember, in ASP.Net, the using statement (not directive) is your friend.
First, you need to talk to your DBA... they can check the number of open connections, table locks, slow-running queries, etc.
My gut reaction is that you aren't closing your connections somewhere, or your connection pool is too low.
Are you doing regular database maintenance? Rebuilding / defragmenting indexes, recalculating statistics (unless it's set to do this automatically). Check the size of your transaction log, etc.
I've got a number of ASP.Net websites (.Net v3.5) running on a server with a SQL 2000 database backend. For several months, I've been receiving seemingly random InvalidOperationExceptions with the message "Internal connection fatal error". Sometimes there's a few days in between, while other times there are multiple errors per day.
The exception is not limited to one site in particular, though they share business and data access assemblies. The error seems to always be thrown from SqlClient.TdsParser.Run(). It sometimes is thrown from old-school direct SqlCommand.Execute() calls, while other times it is thrown from Linq2Sql code.
I've been assured by the network guys that there are no errors or packets lost on their end. Has anyone else experienced this? Could it be a driver problem? We have been unable as of yet to pinpoint a specific trigger for this exception.
We're running II6 on Windows Server 2003.
After a few months of ignoring this issue, it started to reach a critical mass as traffic gradually increased. Under heavy load, including some crawlers, things got crazy and these errors poured in nonstop.
Through trial and error, we eventually tracked down a handful of SqlCommand or LINQ queries whose SqlConnection wasn't closed immediately after use. Instead, through some sloppy programming originating from a misunderstanding of LINQ connections, the DataContext objects were disposed (and connections closed) only at the end of a request rather than immediately.
Once we refactored these methods to immediately close the connection with a C# "using" block (freeing up that pool for the next request), we received no more errors. While we still don't know the underlying reason that a connection pool would get so mixed up, we were able to cease all errors of this type. This problem was resolved in conjunction with another similar error I posted, found here: Why is my SqlCommand returning a string when it should be an int?
Sounds like the database connection is getting dropped or timing out.
We recently had similar issues moving to IIS 6 from IIS 5 connecting to SQL 2000. Our issue was solved by increasing number of ephemeral ports available.
Look at the usage of the ephemeral ports by the IIS server. The default max no. of ports available is normally 4000. You might want to consider increasing this if the sites on your server are particularly busy or your application is making a lot of database calls.
You can monitor these first to see if going over max limit.
Search Microsoft Knowledge base for "MaxUserPort" and "TcpTimedWaitDelay" and make necessary registry changes. Make sure you back up registry or snapshot server before making the changes. Will need to reboot for changes to take effect.
You should double check your database and recordset connection are being closed after use. Not closing will use up this port range unnecessarily.
Check the efficiency of your stored procedures anyway as they might be taking longer than they need too.
"If you rapidly open and close 4000 sockets in less than four minutes, you will reach the default maximum setting for client anonymous ports, and new socket connection attempts fail until the existing set of TIME_WAIT sockets times out." - from http://support.microsoft.com/kb/328476
Check your server's LOG folder (\program files\Microsoft SQL Server\MSSQL.1\MSSQL\LOG or similar) for files named SqlDump*.mdmp and SqlDump*.txt. If you do find any you'll have to take it to Product Support.
I was creating a new EF Core project and was trying to create the database to an external Linux server instead of a Windows Server or local one. After hours of searching I found out that I am using MySQL instead of the Microsoft SQL server.
I found it weird that everyone was using 1433 instead of the usual 3306. So to fix my 'Internal connection fatal error' I had to set up a docker instance of SQL Server bound to its default port of 1433.
It literally was that simple. In the docker repo look for "microsoft-mssql-server" and run the image as described neatly in the description below. Everything works now and I am able to push my database from my EF Core project to an external server.
I have a website running a basic ASP.NET application that is mostly used from a single location, which is my client's office. The server is at a high-class datacenter.
Whenever I've been testing or using my application from outside their office I have consistently good connections but from their office the connection seems inconsistent. Sometimes requests just don't seem to make it to the server from the browser. I'm not familiar with the network hardware in the office, but they do have a T1 connection which should always be on.
I've tried ping and tracert and everything looks normal. When running Firebug during a failed request the request shows up in the log, then just sits there without showing it is sending any data, eventually it times out.
My question is, what tools can I use to diagnose this connection problem and start to narrow it down to a specific cause so I can fix it? Its an intermittent problem so a long running tool would probably make more sense, if there is any available.
Thanks for any help.
All of your standard ping and traceroute tools are probably your best bet. I'm not understanding though, where is the site located?
If you open command prompt, run ping -t aspwebsiteurl.domain <- will show if there is packet loss.
From command prompt again, tracert aspwebsiteurl.domain <- will show you what route the packet is taking to get the site. May also show you if there is one particular hop that is giving you the hickup.
Is there a proxy between the office and the datacenter that could be causing issues?
Also you could try Wireshark to try to debug the problem in more detail.
Speed Test - Internet Network Connection Speed may be of some help with some links to test out the connection at the client's office to see how well it works.
Another question is how far away is the client and the datacenter? If one is in New York and the other in Los Angeles then the distance apart may be a factor. Also, have you examined any possible DNS issues?