May 18, 2016 at 11:36 am
Brandie Tarvin (5/18/2016)
Is SQL Server set up to allow remote connections?Is the client computer (the desktop / PC) on the same network and subnet as the Server or a different one?
What about the domain? Is it the same or different between the two?
If different domains, do they trust each other?
1- i don't know , how can i check it?
2- not same network but i connect to network via VPN .
3- same domain .
May 18, 2016 at 11:40 am
can anybody see my PC via teamviewre ? to check all of it .
May 18, 2016 at 12:00 pm
Were you able to identify the permissions for the account you using to connect to when creating the DSN?
I would recommend that you start there.
Regards.
For better, quicker answers on T-SQL questions, click on the following...
http://www.sqlservercentral.com/articles/Best+Practices/61537/
For better answers on performance questions, click on the following...
http://www.sqlservercentral.com/articles/SQLServerCentral/66909/
May 18, 2016 at 12:09 pm
dukanif (5/18/2016)
can anybody see my PC via teamviewre ? to check all of it .
If your company can't hire someone local, I'm sure one of us would be willing to contract with them to help you out. But our pay rates are pretty high and we'd have to sandwich you in between our other day-to-day work.
FYI: never ever ever accept anyone's offer to help you out via PC Anywhere or Teamviewer or even JoinMe without an ironclad contract and NDA, ones that include privacy level of data and covering damages. You're just asking a hacker or a data thief to take advantage of you and your company. Such behavior could get you fired and sued in court, even if it was the "helper" who did the damage / theft.
WelshCorgi has a good point. Check the permissions of the account you're using for the ODBC. Remember, just because you can connect to the server doesn't mean the account you're using for the ODBC can.
For checking the remote connections, follow these instructions from Microsoft. If you can connect remotely, it's already set up. You're certainly not getting the usual connection message that pops when it's disabled.
May 18, 2016 at 12:17 pm
Removed.
For better, quicker answers on T-SQL questions, click on the following...
http://www.sqlservercentral.com/articles/Best+Practices/61537/
For better answers on performance questions, click on the following...
http://www.sqlservercentral.com/articles/SQLServerCentral/66909/
May 18, 2016 at 2:55 pm
When you remote in launch SSMS and navigate to the Database that you are trying to connect to.
Perform a Select Statement.
Are you able to check Security at the Server Level and at the database Level?
Please try it and provide your results.
For better, quicker answers on T-SQL questions, click on the following...
http://www.sqlservercentral.com/articles/Best+Practices/61537/
For better answers on performance questions, click on the following...
http://www.sqlservercentral.com/articles/SQLServerCentral/66909/
May 18, 2016 at 5:49 pm
Apologies if someone mentioned this, but your VPN needs to forward traffic well. I assume this is the case, since you say you can connect to the host server, but what does "connect" mean? With Windows Explorer? Some other app? Computer Manager?
If you can connect when you are on the LAN with the server, from a machine not the server, then the server should be accepting remote connections. You should check that.
If you connect from SSMS (or the ODBC dialog), and you put in the IP, does it come back quickly (couple seconds) with the error, or take awhile? If it's slow, then likely you aren't getting a network connection on 1433 to this server. I'd be sure that the VPN allows 1433. I wouldn't think this is locked down by the VPN and/or firewall by default if you can connect on the LAN, but it's possible.
If you can connect with Windows Explorer to the machine that has SQL Server running, and you're sure the service is running, you've got some network issue. Possibly the port is being blocked, or 1433 (default SQL TCP port) isn't running on the VPN. There could be some restriction in the VPN that limits IPSEC access on non-default ports that are used for SMB.
May 18, 2016 at 6:05 pm
If you are remoting onto the same box that SQL Server is on, then open SQL Server Management Services. You'll get a logon dialog. Either select the SA account assuming you know the password IF you are using both Standard and Windows authentication. For the server instance, you can also enter "localhost" (no quotes).
May 19, 2016 at 3:12 am
Have you tried enabling the UDP ports 1433 (default instance) and 1434 (names instances) in the firewall on the server (incoming & outgoing)? I have found this helps in the past.
Regards
Steve
May 19, 2016 at 4:27 am
smw147 (5/19/2016)
Have you tried enabling the UDP ports 1433 (default instance) and 1434 (names instances) in the firewall on the server (incoming & outgoing)? I have found this helps in the past.
A good suggestion, but if dynamic ports are enabled on the server, then those are the ports that need to be enabled (I believe) instead of the defaults.
Viewing 10 posts - 31 through 39 (of 39 total)
You must be logged in to reply to this topic. Login to reply