I have used SMO API.in that i have used SmoApplication.EnumAvailableServers(FALSE) and from that i have filtered local instances i have used this approch insted of true to make this as convinent for remote sqldiscovery also.using that api created a dll and use that dll in c++.
Now this is working in all combinations but some times it is failed to retrieve the instannces in win2008 sql2008 cluster combination. if i run the exe for 5 times it got succeed for 3 times and failed for two times...
What is wromg with win-sql2008 cluster .is there any additional changes needed to make it work properrly.My firewall is off and also added exception for tcp port 1433.
Anyy help is greately Appreciated...
Thanks in Advance.
SMO finds the instances through the SQL Browser Service if I recall correctly. The SQL Browser is listening on UDP 1434 which should be opened in the firewall, but for a cluster the service would be set to manual start up, again if I recall correctly, I don't have a SQL 2008/Windows 2008 cluster to check immediately. Check that the SQL Browser Service is started on the nodes owning instances and then that each node has UDP 1434 open in the firewall.
Related
I am attempting to set up a communication between Labview and Microsoft SQL Server, on two separate devices, in order to send and receive information about the database from both labview to SQL Server and SQL Server to labview. However, when I reach the "Data Link Properties" menu, I get the same "unable to log in" error upon attempting to log into the server. The server name comes up, however, an error occurs once I move on to select the database on that server. Is there any solution or tutorial to this problem that can allow me to successfully communicate back and forth from labview and smss on separate devices?
I've opened up various ports to allow a connection, even disabled the firewalls on both devices. The devices are connected via an Ethernet cable and I AM able to ping the devices to each other. However, in regards to being unable to log into the server in ssms, I have created new users, adjusted the login properties, tried changing permissions, but anything I try doesn't seem to solve my issue.
Can't really help much without seeing the error or some of the code of what you are trying to do.
That being said, if you go to the menu and select Help>Find Examples... and search for database, you should see a bunch of different things related to database connections. You may find the Database Connection.vi one helpful.
More info on the Database Connectivity Toolkit in LabVIEW can be found here
I see there can be one of the 2 issues
1) Inbound/Outbound port rules not set, Remote connection to server is not allowed.
2) If the server has multiple instances then you need to provide full host name of the instance you are trying to connect.
*Please refer to the below link to configure firewall rules.
https://learn.microsoft.com/en-us/sql/sql-server/install/configure-the-windows-firewall-to-allow-sql-server-access?view=sql-server-2017
I have hosted my WebApp on server 1 and my database on server 2
But I'm getting following error
Communication with the underlying transaction manager has failed.
I googled and found a post which mentioned that it is the issue of DTC(Distributed Transaction)
I enabled DTC on server2(DB server) and made an exception of it in Firewall.
But still same error.
Here is the full stack trace
Message: System.Transactions.TransactionManagerCommunicationException: Communication with the underlying transaction manager has failed. ---> System.Runtime.InteropServices.COMException: The MSDTC transaction manager was unable to pull the transaction from the source transaction manager due to communication problems. Possible causes are: a firewall is present and it doesn't have an exception for the MSDTC process, the two machines cannot find each other by their NetBIOS names, or the support for network transactions is not enabled for one of the two transaction managers. (Exception from HRESULT: 0x8004D02B)
at System.Transactions.Oletx.IDtcProxyShimFactory.ReceiveTransaction(UInt32 propgationTokenSize, Byte[] propgationToken, IntPtr managedIdentifier, Guid& transactionIdentifier, OletxTransactionIsolationLevel& isolationLevel, ITransactionShim& transactionShim)
at System.Transactions.TransactionInterop.GetOletxTransactionFromTransmitterPropigationToken(Byte[] propagationToken)
Kindly advice
We had the exact same situation, and more than once. Each time, it was one of the following:
The IP address in the DNS for the server is outdated (as said in error message: "two machines cannot find each other by their NetBIOS names"). You can check if this is the case by trying ping servername from one server to another in the command prompt. If the ping by name fails and ping by IP succeeds (or ping by name returns the wrong IP), than you should talk to the System Admins to take a look at DNS/DHCP.
The servers are created as an image of preconfigured server (for example, if you are working with virtual machines, and instead of doing a fresh install for each of the servers, you simply clone the image). This is a problem because DTC has an internal "Identifier" - and in case of image cloning both your installations now have same DTC ID, and won't be able to communicate with each other. The solution is to simply uninstall and install the DTC again.
Hope it helps.
Things to check:
Have you done this configuration on both servers?
Are both servers members of the same domain?
Have you checked the event log?
I had the same problem while connecting to a remote SQl Server.
The solution in my case was to add "enlist=false" to the connection string.
I was missing quite a lot of things:
No authentication (as DB server and APP server and not within same AD domain)
Rule to Windows Firewall enabling msdtc.exe
Rule to firewall between DMZ and internal zone TCP 135,1024-65535 in both directions. The link tell you how to restrict the firewall policy to few ports only.
short / long server names to hosts or a shared DNS server. Eg. 192.168.1.1 app1 as well as 192.168.1.1 app1.domain.local
On the other hand based on this link my setup doesn't require:
Allow Remote Clients
Allow Remote Administration
Enable XA Transactions (required prior Windows Server 2003 SP1)
Solved after adding remote IP\machine name to files on server:
hosts, lmhosts
in folder
C:\Windows\System32\drivers\etc
One of our servers displayed this error after the Virtual Machine (VM) controlling our Domain Controller froze. Several related communication problems also started to pop up (like failed password resets). Resetting the frozen VM fixed the issue.
Lots of helpful answers already given.
One problem for me was the presence of invalid (cyrillic) characters in the computer name.
And there is also a way to validate the connection between two servers (or between a server and a computer) using a small tool from Microsoft called DTCPing.
When we change the port number of SQL server, is any changes we have to done in the web application, to connect the database.
Probably not. There is a service that gets installed along with the database engine called SQL Browser that serves as a means to translate the instance name to a port. So, assuming that you didn't hard code the port number into the connection string, you should be good to go. Of course, you should test it first to make sure.
I'm trying to set up mirroring between two sql 2008 databases on different servers in my internal network, as a test run before doing the same thing with two live servers in different locations.
When I actually try and switch the mirroring on the target DB (with
ALTER DATABASE testdb SET PARTNER = N'TCP://myNetworkAddress:5022') I'm getting an error telling me that the server network address can not be reached or does not exist. A little research suggests this is a fairly unhelpful message that pops up due to a number of possible causes, some of which are not directly related to the server existing or otherwise.
So far I've checked and tried the following to solve this problem:
On the target server, I've verified that in SQL Configuration Manager that "Protocols for SQLEXPRESS" (my local installation is labelled SQLEXPRESS for some reason, even though querying SERVERPROPERTY('Edition') reveals that it's 64-bit Enterprise), and Client Protocols for SQL Native Client 10 all have TCP/IP enabled
I'm using a utility program called CurrPorts to verify that there is a TCP/IP port with the same number specified by the mirroring setup (5022) is open and listening on my machine. Netstat verifies that both machines are listening on this port.
I've run SELECT type_desc, port FROM sys.tcp_endpoints; and
SELECT state_desc, role FROM sys.database_mirroring_endpoints to ensure that everything is set up as it should be. The only thing that confused me was the "role" returns 1 .. not entirely sure what that means.
I've tried to prepare the DB correctly. I've taken backups of the database and the log file from the master DB and restored them on the target database with NORESTORE. I've tried turning mirroring on both while leaving them in the NORESTORE state and running an empty RESTORE ... neither seems to make much difference. Just as a test I also tried to mirror an inactive, nearly empty database that I created but that didn't work either.
I've verified that neither server is behind a firewall (they're both on the same network, although on different machines)
I've no idea where to turn next. I've seen these two troubleshooting help pages:
http://msdn.microsoft.com/en-us/library/ms189127.aspx
http://msdn.microsoft.com/en-us/library/aa337361.aspx
And as far as I can tell I've run through all the points to no avail.
One other thing I'm unsure of is the service accounts box in the wizard. For both databases I've been putting in our high-level access account name which should have full admin permissions on the database - I assumed this was the right thing to do.
I'm not sure where to turn next to try and troubleshoot this problem. Suggestions gratefully received.
Cheers,
Matt
I think that SQL Express can only act as a witness server with this SQL feature, you might get better mileage on ServerFault though.
Mike.
Your network settings might be OK. We got quite non-informative error messages in MS SQL - the problem might be an authorization issue and the server still will be saying "network address can not be reached".
By the way, how the authentication is performed? A MSSQL service (on server1) itself must be runned as a valid db user (on server2, and vice versa) in order to make the mirroring work.
I am trying to connect to a biztalk instance over the network, and not being all that successful. The SQL server with the biztalk databases on it has named pipes disabled. When I try to connect to the server that has biztalk installed, it gives a named pipes error. When I try to connect to the database server, it just times out and gives an error that covers virtually every scenario under the sun (basically it can't connect and it doesn't know why)
If I try to connect with SQL Server Management Studio it works. If I try to make a dsn, it works. If I try to go through biztalk, it dies. If I try to go through biztalk with the tcp: prefix, it dies. If I force named pipes on the other two, it dies.
Is there any way from the Connect to existing group dialog to force using TCP/IP as the transport?
To force tcp , try "tcp:servername" (or "tcp:servername\instancename,port")
This can be done without setting an alias or default protocol with SQL tools
There are alternatives to why you may get the error though:
The named pipes error can be misleading, It usually just means "can't find server"
firewalls etc are blocking access to either the SQL instance
... or SQL listener port 1434 thats enumerates instance/ports
do you get any error messages in system or application log?
you may need to check some of the shapes - ports etc as there may be
http://www.biztalkserverguide.com/2008/02/04/biztalk-server-throwing-named-pipes-error-40-could-not-open-a-connection-to-sql-server/
declared a variable called btsConnString (string), this varable was not set to the connection string, it was blank ( by mistake), things were working as expected without issue. On the Stage As the btsConnString wasn’t assigned a connection string, it was throwing the error
Also look at MSDTC issues for connection DTC Test is here http://support.microsoft.com/kb/293799 and if you can install on both servers use DTCPing
also look at theseThe majority of Microsoft SQL Server issues that affect Microsoft BizTalk Server 2006 fall into one of the following categories:
I believe I had something similar fairly recently - BizTalk would try to connect to the SQL box using named pipes for some obscure reason, which would time out.
We've using the registry (HKLM\SOFTWARE\Microsoft\MSSQLServer\Client\SuperSocketNetLib) to force it to try TCP first (and last, and we haven't specified any other protocol) and it seemed to do the trick.
See details here
I know this is an extremely old thread but for reference with the exact same problem. I ended up creating an alias to the instance in SQL Server Configuration Manager. Your alias would look like this: Alias = Aliasname Value = Server\Instance. Then put Aliasname as your datasource in your connection string. Seems to me BizTalk doesn't understand the backslash (\) in the connection string. It must have the a single word.