I have a little problem with the database connection. There are 2 database server:
DBSA, DBSB
DBSA (primary server)
DBSB (mirrored server)
I connect with the following Connection String :
Data Source=DBSA;Failover Partner=DBSB;Persist Security Info=True;Initial Catalog=database;User ID=user;Password=password
When I run my program on my PC it works, but when I try the program on the web server in the DMZ the failover doesn't work.
Does somebody knows the reason for this?
=> I forgot to tell in the question. There is also a witness server.
The app must be getting the failover server name from the SQL server (probably not even the FQDN name) instead of the connection string in the web.config.
Try running ipconfig /flushdns then failover the SQL database and after you get the first SQL exception error run ipconfig /displaydns to see which name it cannot resolve. My bet is it doesn't look anything like the DB alias you have set up in the connection string for failover partner...
I had to deal with the same thing - Microsoft's implementation is a little convoluted since they're trying to cover every possible scenario.
Run this on your principal db
SELECT DB_NAME(database_id) AS 'DatabaseName'
, mirroring_role_desc
, mirroring_safety_level_desc
, mirroring_state_desc
, mirroring_partner_instance
FROM
sys.database_mirroring WHERE mirroring_guid IS NOT NULL;
The value returned in mirroring_partner_instance is the server name that will be used by your connection for failover, not what you specify in the config.
I imagine your PC can see this server using this name, where as when running in the DMZ it cannot.
Related
I have a flyway script that I run to migrate my db to Azure SQL db. Looks something like this:
flyway.url=jdbc:sqlserver://myazuresqlserver.database.windows.net/myazuresqldatabase;ssl=request;integratedSecurity=false;
flyway.user=myazuresqluser
flyway.password=myazuresqlpassword
...
And when I run it I get the following error:
Unable to obtain connection from database (jdbc:sqlserver://myazuresqlserver.database.windows.net/myazuresqldatabase;ssl=request;integratedSecurity=false;) for user 'myazuresqluser': The TCP/IP connection to the host dbserver-appinfra-test-000.database.windows.net/sqldb-appinfra-smartsuitemainoperational, port 1433 has failed. Error: "myazuresqlserver.database.windows.net/myazuresqldatabase. Verify the connection properties. Make sure that an instance of SQL Server is running on the host and accepting TCP/IP connections at the port. Make sure that TCP connections to the port are not blocked by a firewall.".
So the thing is I already have one db that I migrated to another Azure SQL db. The script file for that one was almost idetical to the one I am using to migrate this database. I saw posts similar to mine, and, as you can see, I tried adding stuff like "ssl=request" to the connection string, which didn't work, and also setting setting the minimum required TLS version of the azure sql db to the lowest one.
So, because I followed the exact same steps for the other database and it the migration to Azure worked there, I looked closely into the connection strings of my azure databases. Both of the databases are on the same azure SQL server that I created, and both of them are in the same elastic pool that I created.
From my understanding the problem is that, looking at the connection strings, both of the database have this in their connection strings:
myazuresqlserver:1433
Also, important to mention - I did try to connect to this database from Azure Data Studio and SSMS. And it connects just fine
So I think they are both on the same port of the same server, that is the problem.
Could someone let me know how I could change the port of my Azure SQL database to something else in Azure? Or if it is unrelated please let me know what I can do. Help much appreciated!
The problem was in the line flyway.url=jdbc:sqlserver://myazuresqlserver.database.windows.net/myazuresqldatabase
This is what I had in my other flyway migration file (which worked perfectly) so I thought there shouldn't be any problem with this line. But I had to change it to
flyway.url=jdbc:sqlserver://myazuresqlserver.database.windows.net;database=myazuresqldatabase;
Hope this will help someone!
I have received SQL Server infos that looks like this:
DB Server: abc\xyz
Login: sa
Password: 12345
Database: MyDB
Now, I do not have server abc's access directly but I can ping it like this:
abc.def.company.com
How can I connect to the server using SQL Server Management Studio from my local machine?
Try to connect to abc.def.company.com\xyz
In SQL Server you need to provide servername\instancename in order to connect to a specific database. Usually the instancename is omitted when the instance that is running on servername is the default one.
| How can I connect to the server using MS SQL Management Studio from my local machine?
The exact same way like to one on your network.
THAT IS - after making sure you can reach your network. Now, if the admins on the other side do not have some really unusual setup or are total idiots (and yes, that is how it is) then the server will not be reachable via an internet address (the unusual setup would be one that has to be reachable, but this is unusual).
This means that normally you will have to set up a VPN of some sort, which they should have told you how to do. At least NONE of the machines I know of and worked with would be reachable by some dude on the internet - they are all on internal networks.
I have migrated a classic ASP site to a new server and am getting the following error, message.
I have tried different connection strings but none of them work.
I am not even sure if the connection string is the problem
The new server is a Windows 2012 Server, SQL Server 2008 R2 Express machine.
Microsoft OLE DB Provider for SQL Server error '80004005'
[DBNETLIB][ConnectionOpen (Connect()).]SQL Server does not exist or access denied.
/scripts/dbcode.asp, line 31
Application("C2M_ConnectionString") = "Provider=SQLNCLI10;Server=(local);Database=mysite_live;Uid=mysitec_Live;Pwd=mypass;"
If it is an Express instance, it is most likely not a default instance, but rather a named instance. So you probably meant:
... "Provider=SQLNCLI10;Server=.\SQLEXPRESS; ...
--- instead of just (local) ---^^^^^^^^^^^^
Otherwise you'll need to show us the server properties in SQL Server Configuration Manager on that machine in order for us to be able to tell you how to correct your connection string.
As Aaron Bertrand mentioned it would be interesting to have a look at your connection properties (In Sql Server configuration check if the following are enabled Name Pipes and TCP/Ip).
Since you're able to connect from SSMS i would ask to check if the Remote connection is allowed on that server Also can you tell is the Sql browser service is running?
here is a link that i keep close to me as a reminder or check list on probable connection issues on SQL Server.
Sql Connection Issues
And lastly can you try as provider "SQLNCLI" instead of "SQLNCLI10"
Step-1: Enabling TCP/IP Protocol
Start >> All Programs >> Microsoft SQL Server >> Configuration Tools >> SQL Server Configuration Manager >> SQL Server Network Configuration >> Protocols for MSSQLSERVER >> right click “TCP/IP” and select “Enable”.
Step-2: change specific machine name in Data Source attributes'value to (local) will resovle the problem ni SQL SERVER 2012.
Try pinging the server in your connection string. The server your application resides on should be able to communicate on the port you specify by credentials. If you are developing locally try specifying "localhost". If the server is clustered or you installed as an instance then you need to specify that instance. Also make sure the server is configured for mixed-mode authentication if using sql credentials.
OR Try
Data Source=localhost;Initial Catalog=DBNAME;Persist Security Info=True;User ID=MyUserName; Password=MyPassword;
It can be a permission issue , Please check is that server is connecting with same configuration detail from SQL management.
other is username / password is wrong.
Here is what I would do:
EDIT: Note that this SO post, a few down, has an interesting method for creating the correct connection string to use.
Open SSMS (Sql Server Management Studio) and copy/paste the
username/password. Don't type them, copy/paste. Verify there isn't
an issue.
Fire up the code (this is next for me b/c this would be the next
easiest thing to do in my case) and step to line 31 to verify that
everything is setup properly. Here is some info on how to do
this. I understand that this may be impossible for you with this
being on production so you might skip this step. If at all possible
though, I'd set this up on my local machine and verify that there is
no issue connecting locally. If I get this error locally, then I
have a better chance at fixing it.
Verify that Provider=SQLNCLI10 is installed on the production
server. I would follow this SO post, probably the answer posted
by gbn.
You have other working websites? Are any of them classic asp? Even
if not, I'd compare the connection string in another site to the one
that you are using here. Make sure there are no obvious differences.
Fire up SQL Server Profiler and start tracing. Connect to the site
and cause the error then go to profiler and see if it gives you an
additional error information.
If all of that fails, I would start going through this.
Sorry I can't just point to something and say, there's the problem!
Good luck!
Have you ever tried SQL Server OLE DB driver connection string:
"Provider=sqloledb;Data Source=(local);Initial Catalog=mysite_live;User Id=mysitec_Live;Password=mypass;"
or ODBC driver:
"Driver={SQL Server};Server=SERVERNAME;Trusted_Connection=no;Database=mysite_live;Uid=mysitec_Live;Pwd=mypass;"
At least this is what I would do if nothing helps. Maybe you will be able to get more useful error information.
Could this be a x86/x64 thing?
The following thread seems to indicate that the (local) alias is a 32-bit alias which fails on 64-bit server:
http://social.msdn.microsoft.com/Forums/en-US/sqldataaccess/thread/c701d510-90e5-4dd0-b14f-ca1d694d6615
(note that the error is exacly what you had)
When you were testing the .udl on the server did you test both x86 and x64?
Following the advice from this blogpost (http://blogs.msdn.com/b/farukcelik/archive/2007/12/31/udl-test-on-a-64-bit-machine.aspx) you could test your
local udl :
in 64-bit by just double clicking it (acts the same as running "C:\Program Files\Common Files\System\Ole DB\oledb32.dll",OpenDSLFile C:\\test.udl
in 32-bit by double running C:\Windows\syswow64\rundll32.exe "C:\Program Files (x86)\Common Files\System\Ole DB\oledb32.dll",OpenDSLFile C:\\test.udl
If you can confirm it's a problem with the alias I'd suggest you create a new one by following the guidelines found here:
http://msdn.microsoft.com/en-us/library/ms190445(v=sql.105).aspx
Have you tried to use the server IP address instead of the "(local)"?
Something like "Server=192.168.1.1;" (clearly you need to use the real IP address of your server)
In case you try to use the server IP address, check in the "SQL-Server configurator" that SQL Server is listening on the IP address you use in your connection. (SQL Server Configurator screenshot)
Other useful thing to check / try:
And check also if the DB is in the default SQL Server instance, or if it is in a named instance.
Do you have checked if the firewall have the TCP/IP rule for opening the port of you SQL Server?
Have you tried to connect to SQL Server using other software that use the TCP/IP connection?
The SQL Server Browser service is disabled by default on installation. I'd recommend that you enable and start it. For more information, see this link and the section titled "Using SQL Server Browser" for an explanation of why this might be your problem.
If you don't wish to enable the service, you can enable TCP/IP protocol (it's disabled by default), specify a static port number, and use 127.0.01,<port number> to identify the server.
In line 31:
cmd.ActiveConnection = Application("C2M_ConnectionString")
How are you instantiating cmd?
Rather than the ConnectionString being wrong, maybe cmd is acting differently in the new environment.
Edited to add:
I see that you've gone from IIS 7 to IIS 8. To run Classic ASP sites on IIS 7 required manual changes to server defaults, such as "allow parent paths." Is it possible that some of the needed tweaks didn't get migrated over?
If you're not running with Option Strict On, you should try that - it often reveals the source of subtle problems like this. (Of course, first you'll be forced to declare all your variables, which is very tedious with finished code.)
I know that this sentence tells me that 'MyDatabase' database is online:
select databasepropertyex('MyDatabase', 'Status')
What if I need to check a database from another server? Suppose that I already have a link server, the call should be like this:
select databasepropertyex('[192.168.111.33].MyOtherDatabase', 'Status')
but it doesn't work, anyone knows how to check this?
Thank you.
Might have to run as a pass through query, e.g.
OPENQUERY ( [192.168.111.33] ,'select databasepropertyex(MuOtherDatabase, ''Status'')' )
(assuming your already set up linked server is called [192.168.111.33], as implied above - seems like a dubious naming convention to use IPs?)
Normally, you would just try to connect to the database, and trap the error if the connection fails. But depending on your network setup and security, it might not be possible to connect directly to the database server. Exactly how you do that depends on what language and provider you use.
Some online examples of connection strings>
To see whether a SQL Server 2008 database can accept connections, look at the Collation property instead. I know how strange that sounds, but that's the documented way.
The ONLINE status may be returned while the database is being opened
and is not yet recovered. To identify when a database can accept
connections, query the Collation property of DATABASEPROPERTYEX.
For example, many database servers are set up to deny connections from all IP addresses except one. This is especially common in web-based setups; it's a fundamental security measure. In that case connecting like this (immediately below) would work. Code on the application server or web server tries to connect to the database server, and returns an error if it fails.
Your server --> Application server --> Database server
or workstation or web server
But connecting like this won't, because the database server is configured to accept connections only from the application server or web server.
Your server ----------------------------> Database server
or workstation
Application server
or web server
How to connect to a remote SQL Server using servername, username & password in SQL Server 2005 ?
I'm going to assume that you're talking exactly about what your question asks, how to connect to a remote MSSQL instance inside SQL Server, rather than through SQL Server Management Studio because 1) you don't mention SSMS and 2) it's pretty obvious how to connect with SSMS (I mean, the connect box is right there when you start it).
To connect to one MSSQL instance from another you can use linked servers. You can query data from linked servers, and if they are configured for RPC Out you can also execute SQL against them.
If the server is configured for integrated security, there is no way of doing it without changing the security option.
Check out the ConnectionStrings website - it shows you how to build a connection string that will allow you to connect from your machine to a remote SQL Server instance.
That connection string will typically look something like:
server=YourServerHere;database=YourDatabase;User ID=YourUser;Password=Top$ecret
But there are lots of options and additional things you can specify - the ConnectionStrings.com web site shows and explains them all!