Created a new Server 8 machine. Testing out a .net + SQL Server 2012 site. I am trying to remotely connect to the machine but in order to do so I need to enable TCP/IP protocol. If I try and do it visually through the Computer Management Console I get some strange behavior in that if I try to select any Yes/No dropdown list it simply gives me a blank list and I cannot change the value. I can enable the TCP/IP as a whole by selecting it from the context menu in the config, but when I go into the properties I get enabled = No for all IP1, IP2, etc... areas.
I then tried to change it using SQLPS... but does not seem to take... the strange thing is that I notice that under properties there is nothing... take a look and let me know..
PS SQLSERVER> $MachineObject.getsmoobject($tcp.urn.Value + "/IPAddress[#Name='IP2']")
Parent : Microsoft.SqlServer.Management.Smo.Wmi.ServerProtocol
IPAddressProperties : {Active, Enabled, IpAddress, TcpDynamicPorts...}
IPAddress : 192.168.0.24
Urn : ManagedComputer[#Name='WIN-LLJKBQ6OVVR']/ServerInstance[#Name='MSSQLSERVER']/ServerProtocol[#Name
='Tcp']/IPAddress[#Name='IP2']
Name : IP2
Properties : {}
UserData :
State : Existing
When you enable TCP/IP protocol on SQL Server, not only do you enable port 1433 (or whatever) but you also need to make sure you bound the listener to the right interface. In the past, SQL server would bind to 0.0.0.0 but in recent versions you can bind to one of the many options : 127.1, 192.168.1.xx, 0:0:0:0:0:0:0:1, ::1 , etc.
Please run "SQL Server COnfiguration Manager" , look in the network configuration, and make sure you configured the listener bindings correctly. You can verify it using "netstat -an" in a shell.
Also, double check that your user account is actually enabled and that SQL Server "mixed auth" is probably enabled.
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 created a db instance (sql server ex) in my AWS account and now trying to access it via MS SQL Server Management Studio or via Visual Studio Server Explorer, but i can't, i get the errors like below:
I have added my ip address in inbound under security group as well:
I Tried all the above steps but didn't work. Even though, i have selected 'Publicly Accessible' while using visual studio, it didnt reflect in the aws console. So, the below steps worked for me. Please try this.
Note:- this is only for my testing/learning purposes. So, i made it publicly accessible. You might not enable publicly accessible if there is a security issue. If you are testing/using for learning purposes, you can follow the below approach.
Make sure your port is publicly accessible .Else you will not be able to connect.
To enable the public accesss, please follow the below steps.
Select the db instance --> click Modify
Scroll to connectivity Section, expand 'Additional configuration' section --> select 'Publicly Accessible'--> Scroll to bottom --> select update. (as shown below).
Your db instance will be in modifying state and after 2-3 minutes it will be available. Now, give it a try to connect again and you will be able to connect now.
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.
Is this even a valid question? I have a .NET Windows app that is using MSTDC and it is throwing an exception:
System.Transactions.TransactionManagerCommunicationException: Network access for Distributed Transaction Manager (MSDTC) has been disabled. Please enable DTC for
network access in the security configuration for MSDTC using the Component Services Administrative tool ---> System.Runtime.InteropServices.COMException (0x8004D024): The transaction manager has disabled its support for remote/network
transactions. (Exception from HRESULT: 0x8004D024) at System.Transactions.Oletx.IDtcProxyShimFactory.ReceiveTransaction(UInt32
propgationTokenSize, Byte[] propgationToken, IntPtr managedIdentifier,
Guid& transactionIdentifier, OletxTransactionIsolationLevel&
isolationLevel, ITransactionShim& transactionShim)....
I followed the Kbalertz guide to enable MSDTC on the PC on which the app is installed, but the error still occurs.
I was wondering if this was a database issue? If so, how can I resolve it?
Use this for windows Server 2008 r2 and Windows Server 2012 R2
Click Start, click Run, type dcomcnfg and then click OK to open Component Services.
In the console tree, click to expand Component Services, click to expand Computers, click to expand My Computer, click to expand Distributed Transaction Coordinator and then click Local DTC.
Right click Local DTC and click Properties to display the Local DTC Properties dialog box.
Click the Security tab.
Check mark "Network DTC Access" checkbox.
Finally check mark "Allow Inbound" and "Allow Outbound" checkboxes.
Click Apply, OK.
A message will pop up about restarting the service.
Click OK and That's all.
Reference : https://msdn.microsoft.com/en-us/library/dd327979.aspx
Note: Sometimes the network firewall on the Local Computer or the Server could interrupt your connection so make sure you create rules to "Allow Inbound" and "Allow Outbound" connection for C:\Windows\System32\msdtc.exe
Do you even need MSDTC? The escalation you're experiencing is often caused by creating multiple connections within a single TransactionScope.
If you do need it then you need to enable it as outlined in the error message. On XP:
Go to Administrative Tools -> Component Services
Expand Component Services -> Computers ->
Right-click -> Properties -> MSDTC tab
Hit the Security Configuration button
I've found that the best way to debug is to use the microsoft tool called DTCPing
Copy the file to both the server (DB) and the client (Application server/client pc)
Start it at the server and the client
At the server: fill in the client netbios computer name and try to setup a DTC connection
Restart both applications.
At the client: fill in the server netbios computer name and try to setup a DTC connection
I've had my fare deal of problems in our old company network, and I've got a few tips:
if you get the error message "Gethostbyname failed" it means the computer can not find the other computer by its netbios name. The server could for instance resolve and ping the client, but that works on a DNS level. Not on a netbios lookup level. Using WINS servers or changing the LMHOST (dirty) will solve this problem.
if you get an error "Acces Denied", the security settings don't match. You should compare the security tab for the msdtc and get the server and client to match. One other thing to look at is the RestrictRemoteClients value. Depending on your OS version and more importantly the Service Pack, this value can be different.
Other connection problems:
The firewall between the server and the client must allow communication over port 135. And more importantly the connection can be initiated from both sites (I had a lot of problems with the firewall people in my company because they assumed only the server would open an connection on to that port)
The protocol returns a random port to connect to for the real transaction communication. Firewall people don't like that, they like to restrict the ports to a certain range. You can restrict the RPC dynamic port generation to a certain range using the keys as described in How to configure RPC dynamic port allocation to work with firewalls.
In my experience, if the DTCPing is able to setup a DTC connection initiated from the client and initiated from the server, your transactions are not the problem any more.
Can also see here on how to turn on MSDTC from the Control Panel's services.msc.
On the server where the trigger resides, you need to turn the MSDTC
service on. You can this by clicking START > SETTINGS > CONTROL PANEL > ADMINISTRATIVE TOOLS > SERVICES. Find the service called 'Distributed Transaction Coordinator' and RIGHT CLICK (on it and
select) > Start.
MSDTC must be enabled on both systems, both server and client.
Also, make sure that there isn't a firewall between the systems that blocks RPC.
DTCTest is a nice litt app that helps you to troubleshoot any other problems.
#Dan,
Do I not need msdtc enabled for
transactions to work?
Only distributed transactions - Those that involve more than a single connection. Make doubly sure you are only opening a single connection within the transaction and it won't escalate - Performance will be much better too.
MSDTC can be configured with MsDtc PowerShell module, e.g.:
# Import the module
Import-Module -Name MsDtc
# Set the DTC config
$dtcNetworkSetting = #{
DtcName = 'Local'
AuthenticationLevel = 'NoAuth'
InboundTransactionsEnabled = $true
OutboundTransactionsEnabled = $true
RemoteClientAccessEnabled = $true
RemoteAdministrationAccessEnabled = $true
XATransactionsEnabled = $false
LUTransactionsEnabled = $true
}
Set-DtcNetworkSetting #dtcNetworkSetting
# Restart the MsDtc service
Get-Service -Name MsDtc | Restart-Service
Run on each of the machines that will be supporting the distributed transactions (i.e. where the MSDTC service is running).
I need to convert a named instance of SQL server 2005, to a default instance.
Is there a way to do this without a reinstall?
The problem is, 2 out of 6 of the developers, installed with a named instance. So its becoming a pain changing connection strings for the other 4 of us. I am looking for the path of least resistance to getting these 2 back on to our teams standard setup.
Each has expressed that this is going to be, too much trouble and that it will take away from their development time. I assumed that it would take some time to resolve, in the best interest of all involved, I tried combing through configuration apps installed and didn't see anything, so I figured someone with more knowledge of the inner workings would be here.
I also wanted to convert a named instance to default - my reason was to access it with just the machine name from various applications.
If you want to access a named instance from any connection string without using the instance name, and using only the server name and/or IP address, then you can do the following:
Open SQL Server Configuration Manager
Click SQL Server Network Configuration
Click Protocols for INSTANCENAME you want to make available (i.e. SQLExpress)
Right-click TCP/IP and click Enabled
Right-click TCP/IP and go to Properties
Go to the IP Addresses tab
Scroll down to the IPAll section
Clear the field TCP Dynamic Ports (i.e. empty/blank)
Set TCP Port to 1433
Click Ok
Go to SQL Server Services
Right-click your SQL Server (INSTANCENAME) and click Restart
This will make the named instance listen on the default port. Note : You can have only one instance configured like this - no two instances can have same port on the IP All section unless the instance is a failover cluster.
As far as I know, no. One reason is the folder structure on the hard drive; they will have a name like MSSQL10.[instancename]
This is why a lot of companies store their applications' connection strings at the machine level instead of the application level.
Just take the connection string out of the source code entirely. Then have everyone put their connection string in their machine.config.
This has the added benefit of avoiding unnecessary app-specific environment logic, i.e. when you copy your application to the staging server, the staging server already "knows" what database to use.
The only way to change the instance name is to re-install - uninstall and install as default instance.
A lot of times I'll use client alias to point an application at a different sql server than the ones it's connection string is for, esp. handy when working on DTS or an application with a hard coded connection string. Have everybody use a commonly named alias, use the alias in the connection string and point the alias’s on each dev box to the to the different instances. That way you won't have to worry about if the server is the default instance or not.
You shouldn't ever really need to do this. Most software that claims to require the default instance (like Great Plains or Dynamics) doesn't actually.
If you repost with your situation (installed X, then Y, but need to accomplish Z) I bet you'll get some good workarounds.
I think you can migrate your data from Sql Server without having default instance installed. You can just specify the port number of your Sql Server instance in Oracle Sql Developer and you can connect just using the server name, not using the server name and the instance.
Like this:
connect to "MYSERVER, 1433"