When I publish my project clients will need to be able to setup the initial configuration, and part of that is the Sql Database Connection. I have an instance of Sql Server 2008 running on my system (MSSQLSERVER2008) as well as SQLEXPRESS2005. I am trying to use the following connection string locally just to see if this works, and I can't get it to work:
ConnectionString = {Data Source=127.0.0.1;Initial Catalog=DCOMProductionsDesktop;Integrated Security=False;User ID=DCOMProductionsDesktopService;Password=;Network Library=dbmssocn}
The error I get is the usual "The target machine actively refused the connection".
*There isn't any firewalls running, and its inside the network anyway
*TCP/IP Protocols are enabled
*Remote Connections are enabled and permitted
So, I'm stumped.
Edit
I changed the connection string's data source to:
DataSource=192.168.0.2\MSSQLSERVER2008 on my WinXP VM (for testing remotely)
Now, this did work. But when I deploy this across the internet, will that same connection string work for clients outside my network using a domain name such as:
DataSource=desktop.dcomproductions.com\MSSQLSERVER2008
Or will I need to do something different?
It will work, as long as "desktop.dcomproductions.com" or whatever, resolves to the proper IP address. So that name should be set up either on the public or private DNS properly.
Also, make sure it resolves to a public/external IP address, unless your client's scripts are going to be within the same network as the SQL server.
Thought I post it as an answer, instead of comments :)
It's been a while sice I used anything but Named Pipes to connect to a sql server instance so this may not be relevent but try changong Data Source to Server.
They may be synonyms, as I said, it's been a while.
Also, even if you are using an IP address, you aren't specificying an instance of sql server to connect to, that may also be causing issues
Related
I am trying to connect to a MySQL database from Data Fusion, but I am getting the following error. Communications link failure The last packet sent successfully to the server was 0 milliseconds ago. The driver has not received any packets from the server. The database is accessed through public IP through port 3306, from my machine I can connect perfectly, but from Data Fusion I cannot.
As John Hanley pointed out in his comment, it's probably due to a connectivity issue with your SQL instance.
A possible reason would be that you have not enabled your instance to be connected via its public IP. If that's the case, go to your SQL instance and edit its configuration, adding a network (if you haven't done so previously) and providing an IP range to include your Data Fusion instance. Keep in mind that if you configure your instance to accept connections using its public IP address, also configure it to use SSL to keep your data secure. If that was the issue, now you should be able to connect properly.
Also, be sure to check that the Dataproc cluster that your data Fusion instance is using under the hood has the proper configuration (you shouldn't worry about this if you haven't changed anything about the Dataproc cluster).
This is the best advice I can give without further details. If this doesn't work for you, we're going to need more information.
My two cents:
I use one windows pc with several linux box at home.
My main station is the Windows one.
I'v been using Sqlyog just to prob tables on the remote db.
I use my class C addr. to address the server.
It works well. By design I want to access the db server
from anywhere in my home...
60% to 75%ishhh problems of that kind would be related
to the .cnt file configuration.
Regards
Steph
I am using mysql.connector package.
I want to make sure it is possible to remotely connect to a database from any IP (especially from computers that MySql is not installed in) via basic authentication (username and password), using the follwoing line:
con = mdb.connect(host=self.ip.text, user='username', passwd='pass', db='dbname')
Can somebody please confirm it can be done?
Are there any other parameters that can affect? (Like operation system etc.)
You can connect to a database from any IP (aside from cases related with network limitation e.x. security issues).
These parameters which You use are enough. Check IP adress variable is use correctly.
If no exception occurred You should connect successfully.
I'm running EC2 with MySQL RDS to serve dynamic websites' content.
The server was down due to 'too many connection' error on RDS database.
As it was urgent, I restart database server straight away and the problem gone.
However, I'm unable to see what queries produce those connection (as I didn't run SHOW PROCESS LISTS before reboot RDS).
CloudWatch show 250+ connections during period of issue which is obviously huge distinction from normal operating on other days.
I try to address the issue by see log in RDS, but there is quite a minimal message there.
The error message
2014-05-03 06:10:08 3628 [Warning] IP address '173.244.206.19' has been resolved to the host name '173.244.206.19.static.midphase.com', which resembles IPv4-address itself.
From above, 173.244.206.19 is not in our IP list both public and private. (but connection open to 0.0.0.0 secured with password which I'm going to limit IP remote in security group soon)
Questions
Is 173.244.206.19.static.midphase.com is something to do with RDS by default. I think this is obviously an attack sign but just would like to confirm.
What does 'resembles IPv4-address itself' mean? As this is RDS database server only, why server does need to resolve DNS?
Are there any way to digging into this for further detail (e.g. to see specific query).
I'm going to prevent this by only limit the IP access along with CloudWatch alarm setting for 10+ connections. Anything else I should do.
Thank you for reading through this guys. I'm the only developer in company start-up which take care for all front-end/backend/application/network. Therefore, apology if there are dummy questions out here.
However, your help would be really appreciated and will save a bit of my life writing the report.
You are maybe the target of a DDOS attack or a brute-force password discovery attempt.
I would report this to AWS support - as they can help to mitigate the effect of the attack.
As a best practice, we do not recommend to use 0.0.0.0/0 as source IP address for incoming connection rule in Security Group.
Try to restrict which IP addresses are authorised to connect to your database.
If you are accessing from on prem network, specify only your on-prem address range.
If you're accessing your database from an app server installed on EC2, use the ID of the App Server Security Group (sg-xxxx) as source authorised to connect to your database.
I have a dilemma which is completely and utterly baffling me...
We have a Classic ASP site which has been running for about a year, its powered via a local Win2008 SQL database (The SQL Express engine is on the same server as IIS). This is the connection string we currently use
Provider=SQLNCLI10;Server=SERVERNAME\SQLEXPRESS;Database=dbname;user id=username;password=password;
We now have a need to move the database to a dedicated DB server, and connect to it remotely - We restored the DB on the server, and checked everything looked ok (All data is present in all tables)
So we changed the server name to the IP address and was unable to get it to connect, in the end the only way we could get it to connect was using this connection string.
driver={SQL Server Native Client 10.0};server=IPADDRESS\SQLEXPRESS,1433;uid=user;pwd=password;database=dbname;
HOWEVER... Now it's randomly missing product names and SKU's and prices in the front and back end, even though the data is present in the DB AND it is REALLY slow to display the webpages? If I use the same DB locally with the previous connection string its fine and all data is appearing?
I know this DB server is fine as it powers other ASP.NET sites with via a remote connection and they are very fast to connect?
Any hints... or help on why this new connection string is causing problems with reading data from the DB???
To update the native client on the web server to the most recent public version, go here:
http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=2567714
Check the box for "2008R2_SP1_SNAC_CU2_2567714_10_50_2772_x86" if your web server is an X86 machine, and "2008R2_SP1_SNAC_CU2_2567714_10_50_2772_x64" if it is 64-bit. Enter your e-mail address, fill in the captcha, hit "Request hotfix" and the download link will be e-mailed to you. Download it to the web server, run the installer (using the password sent to you in the e-mail) and restart the web server. Now try your original connection string again.
EDIT
Adding some other sample connection strings that I have used in the past (I've been a classic ASP guy since the 90s, founding and writing 95% of the content on aspfaq.com, including this article on connection strings). As requested in a comment to the original question.
Note that "srv" could be IP address, or localhost, or servername, or . and it could be followed by \INSTANCE_NAME (e.g. \SQLEXPRESS). I would try them in this order, and pay attention to the parameter names as well as the values - you seem to mixing modern parameter names (e.g. Provider) with less modern ones (e.g. Database).
Provider=SQLNCLI10;Data Source=srv;Initial Catalog=db;User ID=user;Password=pwd;
Provider=SQLOLEDB.1;Data Source=srv;Initial Catalog=db;User ID=user;Password=pwd;
Provider=SQLOLEDB;Data Source=srv;Initial Catalog=db;User ID=user;Password=pwd;
Driver={SQL Server};Server=srv;Database=db;UID=user;PWD=pwd;
Sometimes if you are having issues with Named Pipes or Shared Memory it can help to enforce TCP/IP by adding the following parameter:
NETWORK=DBMSSOCN;
You can get a lot more information over at Carl Prothman's site or ConnectionStrings.com. They no longer cater to classic ASP specifically, for obvious reasons, but you can still glean a lot of information from the samples they provide for other languages.
I've got a trio of Windows servers (data1, data2 and datawitness) that aren't part of any domain and don't use AD. I'm trying to set up mirroring based on the instructions at http://alan328.com/SQL2005_Database_Mirroring_Tutorial.aspx. I've had success right up until the final set of instructions where I tell data1 to use datawitness as the witness server. That step fails with the following message:
alter database MyDatabase set witness = 'TCP://datawitness.somedomain.com:7024'
The ALTER DATABASE command could not be sent to the remote server instance 'TCP://datawitness.somedomain.com:7024'. The database mirroring configuration was not changed. Verify that the server is connected, and try again.
I've tested both port 7024 as well as 1433 using telnet and both servers can indeed connect with each other. I'm also able to add a connection to the witness server from SQL Server Manager on the primary server. I've used the Configuration Manager on both servers to enabled Named Pipes and verify that IP traffic is enabled and using port 1433 by default.
What else could it be? Do I need any additional ports open for this to work? (The firewall rules are very restrictive, but I know traffic on the previously mentioned ports is explicitly allowed)
Caveats that are worth mentioning here:
Each server is in a different network segment
The servers don't use AD and aren't part of a domain
There is no DNS server configured for these servers, so I'm using the HOSTS file to map domain names to IP addresses (verified using telnet, ping, etc).
The firewall rules are very restrictive and I don't have direct access to tweak them, though I can call in a change if needed
Data1 and Data2 are using SQL Server 2008, Datawitness is using SQL Express 2005. All of them use the default instance (i.e. none of them are named instances)
After combing through blogs and KB articles and forum posts and reinstalling and reconfiguring and rebooting and profiling, etc, etc, etc, I finally found the key to the puzzle - an entry in the event log on the witness server reported this error:
Database mirroring connection error 2 'DNS lookup failed with error: '11001(No such host is known.)'.' for 'TCP://ABC-WEB01:7024'.
I had used a hosts file to map mock domain names for all three servers in the form of datax.mydomain.com. However, it is now apparent that the witness was trying to comunicate back using the name of the primary server, which I did not have a hosts entry for. Simply adding another entry for ABC-WEB01 pointing to the primary web server did the trick. No errors and the mirroring is finally complete.
Hope this saves someone else a billion hours.
I'd like to add one more sub answer to this specific question, as my comment on Chris' answer shows, my mirror was showing up as disconnected (to the witness) Apperently you need to reboot (or in my case i just restarded the service) the witness server.
As soon as i did this the mirror showed the Witness connection as Connected!
See: http://www.bigresource.com/Tracker/Track-ms_sql-cBsxsUSH/