Related
I have made a program using visual basic 2010, which contains a database. When I copy my program across to another computer and attempt to debug it, I get the following error message:
An unhandled exception of type 'System.Data.SqlClient.SqlException' occurred in System.Data.dll
Additional information: Login failed for user 'Aaron\Aaron'.
And the following line of code is highlighted within the form load sub:
Me.Table1TableAdapter.Fill(Me.Database1DataSet1.Table1)
When I publish the program it also fails to run on any computer other than the one I created it on.
Any help would be much appreciated as I'm still very new to programming, thank you.
If you're trying to access the database over the network, use:
server="HostMachineIP\Aaron" (e.g. "10.1.1.1\Aaron") and make sure firewall port 1433 is open.
If you're transferring the database to another system, set your connection string to: ".\Aaron" - the .\ references the local system.
There are lots of things that could be the issue, but for starters, you probably don't have the same user set up on your other computer that you had on your first one. That is probably why you are getting the error about Login failed for Aaron/Aaron.
Additionally, you may well have a database on the first computer that is not on the second. Transferring the program does not copy the database with it. So you should go into SQL Server on your first computer and compare it to SQL Server on your second one. Likely there are differences in users and databases that will cause problems.
From your description, it sounds like maybe you aren't using a "server" yet.
You won't have much luck if you are moving/copying the .mdf file. Your dev environment will allow this, but not other machines. It will work better if you install SQL Express on one of your machines and use it to host your .mdf (database file). That machine will be your "server".
Download SQL Server Express and install it
Download SQL Server Management Studio. Use it to attach your .mdf. Set permissions. Allow remote connections.
Check your windows firewall (on the server) to make sure port 1433 is open (SQL server communicates across a network on port 1433.
Each machine (except for the server) will need to authenticate to the server. I find this is easier when I map a drive to the server. On the server, make a folder on the hard drive called "temp", share it to the network. On each machine, explore the network, find your server, find the share (temp), map a drive to it.
Once you have done these things, then these other recommendations will work.
So, I'm trying to use pymssql to connect to a SQL Server database from my Linux box. The database can only be reached from inside my company's private network. It is set up to accept SQL Server authentication and, from my windows machine, I am able to connect and query it when I am logged on to the VPN (Cisco Anyconnect is the client installed on the Windows box).
The python script works correctly when run on a linux machine that is plugged into the internet at work. I haven't tried it on my windows machine (because, right now, I have no python on that machine, for one).
On my linux machine at home, I have downloaded OpenConnect, which seems to be working fine for establishing a VPN connection. When I run my script from this machine, while on the VPN, I successfully connect to the database. If the test query I use in the script is to creat a table, or manipulate data in the database, it works. However, I am not able to RETRIEVE any data, i.e., if I run a select query, I get [].
(Also, it is perhaps worth mentioning, that the first thing I tried to do, before figuring out how to get a VPN client on my linux machine (at first I was messing around with Cisco stuff which was a nightmare), was to ssh from my windows machine inside the private network to my home linux machine while forwarding a port from my home linux machine to 1433 on the SQL Server machine. Then instead of using pymsswl.connect() to connect to the SQL SERVER machine, I connected to my local port. I observed the same behavior, actually, in this case as over the VPN. I wasn't particularly surprised that I couldn't get data back in that case, since it's overwrought, and I could see SQL Server not knowing where to send the data....although I am really just speculating there anyway...)
I should also mention that when I click around in the Cisco folder on my Windows machine, there is a "security catalog" with all kinds of wonkiness in it that I don't know much about. Maybe these certificates/thumbprints are at play.
So, I admit total noobness here, and would appreciate any help. If I said something senseless, or if there is other information that might apply, I'll do my best to clarify.
Are you logging in with SQL Server authentication? And how are you running your queries? Sproc have implied rights, meaning if your using a table that you don't have access to it will still work but doing a simple select will deny access, Long shot but who knows.
Here is a link where Pinal Dave talks about a similar error and goes through in detail how to check to make sure the instance is up and a number of other troubleshooting steps you should try. http://blog.sqlauthority.com/2009/05/21/sql-server-fix-error-provider-named-pipes-provider-error-40-could-not-open-a-connection-to-sql-server-microsoft-sql-server-error/
Yes folks, it's this one again.
"A connection was successfully established with the server, but then
an error occurred during the login process (provider: TCP Provider,
error: 0 - An existing connection was forcibly closed by the remote
host.)"
I'm sorry... I have Google'd this, I have read the other StackOverflow articles on this problem, and I have tried all kinds of suggestions, but nothing works.
Here's a few notes about what we're seeing.
This issue occurs occassionally in SQL Server Management Studio itself (doing any kind of database activity... getting a list of tables in a database, having a look at a Stored Procedure, etc)
It also happens in Visual Studio 2010 itself, when it is trying to get data from the servers (e.g. when creating a .dbml file, etc)
It also sometimes happens in our .Net (ASP, WPF, Silverlight) applications.
Our SQL Server 2005 & 2008 servers are all based on virtual machines in data centres around the world, and we see sometimes this error on each of them. But most of the time, they all work absolutely fine.
When the error does occur, we can just "retry" what caused the error, and then it'll work fine.
We think.. if we have an IIS Web Server in a data centre in a particular city, and it accesses a SQL Server in the same data centre, then we don't see the issue.
We think.. if we connect to the servers, and specify the UserID and Password to use, it causes this error much more frequently than if we just use Active Directory authentication.
Put all that together, and it sounds to me like some kind of network issue.
But can anyone suggest what to look for ?
This isn't a bug in our .Net applications, as even SQL Server Management Studio "trips up" with this error.
It's baffling us.
Just in case anyone else hits this issue, we finally found the solution.
Our company uses Riverbed software to compress data, when it's being passed between locations, and this was somehow causing some connections to get dropped.
Our IT gurus found a configuration setting which finally fixed this issue.
I believe there's a setting in there to turn off compressing results from SQL Server (or something like that). That fixed it for us.
It could be any number of network issues. ANYTHING that prevents the code from reaching the server even for the few miliseconds it takes to make one query.
it could also be the result of a failover. When we went from a single SQL Server to a clustered environment, we'd see this happen during a failover. In this case, it turned out to be our Connection Pooling. In essence, the SQL cluster has a controller and two servers behind it. A and B.
Say our web app is using server A just fine, Connection pooling creates a connection on both sides. The server is aware of it, and the web app is aware of it. Once the cluster fails over to the second server, the web app is aware of the connection but server B is not, so we get an error.
The point is, any possible cause of network issues imaginable may be the cause. DOS attacks on the server, man-in-the middle attacks intercepting and changing traffic. Someone trips on an ethernet cable and it's loose in the jack. You name it, if it can cause a connection issue, it could be the cause.
Your issue also sounds like one we had recently - we also have a virtual environment, wih software that moves VMs from one host to another as needed for load balancing. Every so often, we'd get bombarded with the same error. It turned out to be an issue with the NIC drivers on one of the hosts, so whenever a VM moved to that particular host, errors would occur.
It's really not a programming issue. It's an environment issue, and you need trained professionals with direct access to your environment to research and resolve this.
My problem was that I was inadvertently using a wireless network to connect to our network because the Ethernet cable was faulty. This after repairing SQL Server, running a Winsock reset as recommended elsewhere ...
I am experiencing the same issue and our app interfaces with a several Azure SQL DBs. I believe (same as you) I do not have a bug in the C# code to cause this issue. We've solved it by a simple for loop containing an extra attempts to try to connect to the Azure SQL again if the previous attempt fails and then run the query.
Most of the time everything runs fine but sometimes we can see the loop kicked-in and on the 2nd or 3rd time it executed properly without the below mentioned error. After that we see in the log file the error below for all the unsuccessful attempts:
A connection was successfully established with the server,
but then an error occurred during the login process. (provider: TCP
Provider, error: 0 - An existing connection was forcibly closed by the
remote host.)
Even though this is a less-then-pretty solution, it allowed us to run our app without interruptions. I know you've mentioned that trying to connect again (to introduce some connection-failure tolerance) solves the problem and unfortunately this is the only correct solution I found so far as well.
I should mention that we have tried many debugging strategies to figure this out. Right now it all points to the availability of the database we are trying to connect to i.e.: It happens if the number of allowed DB connections is exceeded. (or so it seems at this time)
Turn off your VPN
My Problem fixed by turn off VPN
It was happening in our code when we were opening the dbconnection for oracle and were passing DBtype as SQL in our database object.
in my case - the error was Microsoft first suggestion:
Client is connecting with an unsupported version of the SQL Server Native Client.
In our case, We got this error when we updated sql server to sp3. We were not able to connect to the database from SSIS package.
We updated the native client and configurations. We were able to connect.
link to download the native client - https://www.microsoft.com/en-us/download/confirmation.aspx?id=50402
Link for configurations settings and further troubleshooting - https://learn.microsoft.com/en-us/previous-versions/sql/sql-server-2008-r2/ms187005(v=sql.105)
Hope it helps.
Cheers!
Had the same type of issue. In my case it was a bit more complicated... I could connect to “ServerA” from “ServerB” via SSMS, but it would fail with sqlcmd. The error was the same:
Sqlcmd: Error: Microsoft SQL Server Native Client 11.0 : TCP Provider: An existing connection was forcibly closed by the remote host.
I could also connect from “ServerC” with both SSMS and sqlcmd. The following are the versions on the VMs:
ServerA: Microsoft Windows Server 2012 R2 Datacenter / Microsoft SQL Server 2012 (SP3-CU10) (KB4025925) - 11.0.6607.3 (X64)
ServerB: Microsoft Windows Server 2012 R2 Datacenter / Microsoft SQL Server 2012 - 11.0.5058.0 (X64)
ServerC: Microsoft Windows Server 2012 R2 Datacenter / Microsoft SQL Server 2012 (SP3-CU10) (KB4025925) - 11.0.6607.3 (X64)
Bottom line was the “unsupported version”. I noticed a mismatch of “sqlncli11.dll” between ServerC and ServerB, so I copied it to the System32 folder. After this, sqlcmd worked like a charm. Below were the versions in my case:
Failed:
FileVersion: 2011.0110.5058.00
ProductVersion: 11.0.5058.0
Worked:
FileVersion: 2011.0110.6607.03
ProductVersion: 11.0.6607.3
I was working on 2 projects at the same time (on 2 different machines) and both used SQL Server.
When i disconnected SQL with 1 machine the errorMessage went away. Probably you can mess around with IP-adresses too to fix the problem.
In my case I was seeing this error intermittently from a .Net application connecting to a SQL server located in the same server room. It turned out that some of the databases had auto close turned on which caused the server to close the connections in the pool. When the application tried to use one of the pool connections that had been closed, it would throw this error and I saw a log message on the SQL server that the database it was trying to connect to was being started. Auto-close has now been turned off on those databases and the error hasn't been seen since.
Also, having auto-close on is the default behavior for SQL Express databases and these were originally created on an Express instance during testing before being migrated to the production server where we were seeing the errors.
this answer is for those how have this problem with Azure Sql server database.
It happens when you reach mat pool
first remove Persist Security Info=False from connection string
second check your database plan in azure portal and increase the PTUs of your database plan.
In SSMS "Connect to Server" screen click Options, then on "Connection Properties" TAB change "Network protocol" to "Named Pipes"
Try this -
Click Start, point to All Programs, and click SQL Server Configuration Manager.
Click to expand SQL Server Network Configuration and then click Client Protocols.
Right-click the TCP/IP protocol and then click Enable.
Right-click the Named Pipes protocol and then click Enable.
Restart the SQL server service if prompted to do so.
I have had this issue a couple of time already, and I've fixed by reducing the MTU size. Often 1350, 1250, etc on my network interface.
Relevant background-
I'm a noob working my brains out for over a year into trying to make a database in MS SQL Server 2008 Express with the end idea for the front end being Access. After tons of reading and slaving over my schemas and three major revisions I'm finally ready to connect it to Access and I'm just striking out all around. The Microsoft Access IN and OUT book says it has instructions for this but they're on the included cd in the bonus material which seems to be the only part of the cd that will not work. Everything I've found on the internet hasn't gotten me there. The best I think I've found was an answer on this site but even the list of things to do given as the answer have me hitting some walls that I just haven't the foggiest of how to get through.
I'm going to lay these out and mention what I have and haven't done with each.
Just for background I'm running Access 2007 on a Vista machine that I'm pretty sure is up to date on the service packs (I should have 7 in a few days, it's in the mail finally) and I'm running SQL Server 2008 Express with the management studio.
Here's the answer that I was referencing--
The answer was given by the user "Renaud Bompuis" at the following link
Connect Access 2007 to SQL Server 2008 Database
There should be no issue with connecting Access 2007 to a SQL Server 2008 database.
You need to make sure that:
1.
Your SQL Server 2008 database is accessible, ie that it isn't locked down and that it is accessible to the machine(s) where you will have your Access 2007 application.
A few things to check:
* In SQL Server 2008, go to Properties > Connections > Check "Allow remote connections to this server".
I checked and the check box is checked to allow remote connections. Since this is on the same machine I don't know if this is vital, but whether or not it is it's taken care of to the best of my understanding.
* Enable TCP/IP in the Configuration Manager.
didn't think this was necessary since it's on the same machine but I did it all the same.
* Make sure the firewall allows incoming connections on TCP port 1433.
This is one thing I didn't do since I really couldn't see how a firewall would get in the way if both instances (the SQL Server Express and Access 2007) are on the same machine under the same admin login. But if I'm wrong on this please tell me how to go about altering things.
* You can also start the SQL Server Browser Service so your SQL Server instance can be found.
Did this, even restarted the machine, still can't get Access, nor the ODBC, to pull up the SQL Server 2008 instance on the machine. Nothing.
2.
You have created an ODBC DSN (a System DSN) using Windows ODBC administration tool. If you're running on a 64 bit system, make sure that you're using the 32 bit version of ODBC to create your DSN, otherwise it will never be visible to Access which is a 32 bits application.
Went in there to make the system DSN and when I choose the SQL Server Native Client 10 thing and go to hit the drop down menu to choose the data source it pauses and then nothing comes up, nothing to choose from at all.
3.
Once you have created the ODBC link (and tested it works) on the machine where Access is installed, you can just link the tables: In Access 2007, in the External Data ribbon tab > import > More > ODBC Database.
Then select the DSN you create for your SQL Server 2008 database and chose which tables you want to link.
So clearly this last part I can't even try since I can't even get an ODBC link.
I have a feeling, being a self taught noob and all, that I'm probably missing something obvious to a professional or seasoned amateur but regardless of what my problem is it's driving me nuts. Having a good portion of the last year of my life put into this I'd really like to be able to make progress finally on the front end so that I can finally get some utility out of all my effort beyond just writing queries in SSMS.
Thanks in advance for any and all help anyone can give.
OK, so you're obviously having trouble creating the DSN. Have you tried using "SQL Server" or "SQL Native Client" instead of "SQL Server Native Client 10.0" as the driver? I've found a webpage with a few screenshots on creating an SQL Server DSN (scroll down to the section "Creating a ODBC DSN"), maybe they can give you some guidance.
If it all fails, could you provide a screenshot of the part of the DSN creation process where you get stuck?
I appreciate all yer'allz help. Even though I didn't really see much new and nothing directly helped me I did end up looking in the SQL Server Configuration Manager and the 'VIA' (whatever that means) was the only thing I hadn't enabled (since I hadn't read anything about it in all my investigations--I usually shy away from making modifications to settings that I don't have someone specifically telling me to modify) I hadn't previously touched it nor thought much of anything about the fact that it was the only thing I'd yet to enable.
Well I enabled it, restared services and YAAAAAAAAAAAAAAAAAAAAAAHHHHHHHHHHHOOOOOOOOOOOOOOOOOOOO!!!!!!!!!!!!
I'm now able to (and have successfully) created a ODBC DSN AND I've got Access connected to my database!!!!
I like this site!
Thank you all for caring and for presenting me stuff that led, however fumblingly, to a solution!
Be glad we are only connected through the internet otherwise I'd kiss ya!
I just setup a new Windows Server 2008 machine with an instance of SQL Server 2008 Express. The SQL Browser service does not appear to be working correctly. In Management Studio, browsing for servers shows the hostname of the new server, but not the instance name. When you choose the hostname form the list it doesn't connect. But I can connect manually by typing the hostname\instancename combination.
update 1:
The browser service is running, and I have tried it with several different accounts, including domain administrator which is a bad practice, but I tried anyway for troubleshooting purposes.
I have tried punching the appropriate holes in the firewall, and also completely turning the firewall off.
This is running on a Hyper-V, Windows Server 2008 32 bit guest, which is on a Windows Server 2008 64-bit host. I have done this before (without issues) on this same host, but with SQL 2008 Standard instead of Express.
When I browse for the server in SSMS(Express) on the SQL Server machine, it works fine and shows the whole instance name. When I browse for it on a remote machine (on the same intranet) with SSMS (standard) it just shows the host name.
update 2:
Followed the packets as suggested and found the following
The client sent the broadcast as expected and received correct responses from other SQL Servers on the same network.
The server received the broadcast but did not send a response.
Considering these results, I wonder why the host name ever appears in the client list in the first place. It shouldn't show up at all, right?
update 3:
Spent an hour and a half on the phone with Microsoft support. I learned a few things, but the problem is not yet solved. It was suggested that I try installing an instance of SQL Standard on the same machine. I did that and the new instance exhibits all the same symptoms. The hostname shows up in the browse list only once, not once for each instance.
update 4:
Stackoverflow chose an answer for me thanks to the bounty system, but this question is not answered. Today I tried moving the whole VM to a different host server - everything is exactly the same. The hostname still appears in the browse list, without the instance name.
update 5:
Confirmed that Hyper-V Integration Services are installed on the guest (SQL) server.
check that the browser service is running, it's not turned on by default.
UPDATE1: See if you can install Network Monitor/Wireshark to do a network trace on the SQL Server to see if it's receiving the broadcasts and sending responses. I think this is your best option in troubleshooting this issue. According to MSDN the service uses UDP port 1434, so this is the traffic to watch.
UPDATE2: Does the server have multiple IP's? according to this MSDN article the Windows Server 2008 firewall has issues responding to SQL Browser service broadcasts, even with rules allowing packets through.
I tend not to rely on browsing. You'll get inconsistent results because browsing sends out a broadcast udp/1434 packet and waits for responses back. However, since you are able to connect remotely via SERVERNAME\INSTANCENAME, that aspect of the SQL Browser service is working. If it wasn't, you wouldn't have been able to connect. With that said, to troubleshoot the browsing portion:
Have you tried stopping and restarting the SQL Browser Service?
Have you tried stopping and restarting the instance if that didn't work?
To completely troubleshoot this, unfortunately, you'd have to do packet traces.
Sounds like the browsing service is messed up somehow...
I don't know if you can temporarily take this SQL Server down temporarily. But if so, you may want to try this:
Uninstall all SQL\instances completely.
Run the install of SQL Express 2008
Create a default instance during install (Not a named instance)
Run the installer again and create the default named instance (SQLExpress)
Try connecting to the named instance again. If it works, you can remove the default instance.
I had the same issue in a VM. After shutting down the Firewall it worked.
I just had this same issue. I was not able to see Instance Names in the SSMS Network Servers tab. It turned out that I had set up Hyper-V and created an Internal Network on my local machine. That network was identified as a Public/Guest Network and the Windows Firewall was ENABLED for it, even though my Domain setting has the Firewall DISABLED. Once I disabled that guest network on my computer I could see all the instances.
Machines:
Physical SQL Server 2014 Ent
Windows 8.1 laptop running Hyper-V