I'm trying to detect Microsoft SQL Servers in a network. First of all, one would read Microsoft docs on how to do it, right? So I read about ODBC's SQLBrowseConnect and went with it. I found all SQL Server Express Editions I had installed and was happy, until I gave finished product to client for testing. They say it didn't find any servers.
Turns out that depending on operating system, ODBC SQL Server client used and other, unknown to me factors, I can detect some or none of running servers. When compared to output of sqlcmd -L my detection with SQLBrowseConnect looks bleak. We were moving my app between computers and depending on SQL Server ODBC driver version, SQL Server Native Client version (I've used both) and Windows version, results were different, but some servers were not detected at all, while sqlcmd detects them.
I then tried this method of broadcasting UDP packet of 0x02 to port 1434 where Browser listens, but I got no more than SQLBrowseConnect.
By the way: I tried today Management Studio on two of my computers - same version, different Windows. On Win7 detected 3 servers, on Win2003 detected 6 at the same time.
There's obviously more methods to detect SQL Servers, because on computers where I can't get any results, my colleague gets all servers, but he's using Embarcadero Delphi as a component, which, I believe, uses .NET provider.
I just read there's WMI method too, but I believe you have to supply user and password of target computer, which obviously is useless, as I would need users to supply multiple passwords for multiple servers, which they don't even know. Unless I misunderstand something.
Anyway, please share any method that can be implemented in c or c++, anything. Please note: I can't ask for passwords to computers to connect with WMI.
Related
I have two computers connected to the same switch on the same network with the same subnet, and when I go to either 32 or 64-bit ODBC to create a System DSN and attempt to add a new DSN using the SQL Server Native Client 11.0, the Server list is empty on one but fully populated on the other. I have a local SQL Server on both computers.
The last two entries above are from the computer that is not working. So the SQL Server on the non-working machine has an available instance.
For the computer that is NOT showing any SQL Servers I have tried the following with no success:
Upgraded the OS from Windows 10 to Windows 11
Followed the directions from Microsoft to open ports TCP 1433 and UDP 1434
Made sure the option to hide my SQL server instance is not enabled
Reinstalled ODBC drivers
Checked permissions
Nothing is working. Even my other computer can see my SQL Server instance, but I can't. I can type the server instance manually and that works. But I am dying to figure this out! This makes no sense to me. Also, the computer that works takes almost no time to build the list. On the computer that it's not working, it sits there for a long time before coming back empty.
I thought this could be a permission issue with my account, but it works fine on my other computer using the same account. The only other thing I can think of is it might be a policy issue, but I'm not sure where to go or look for a policy that might affect it. These are both work computers on a domain and even support here can't figure it out.
Any help/direction is appreciated. Thanks!
I'm in the midst of moving my company's timekeeping system from an old, slow Access backend to a snappy and quick SQL Server backend. What I'm finding though, is that while the frontend has no problem connecting to the backend on my machine or a handful of others, on most of the machines here, it just doesn't seem to work at all.
I'm linking tables using the CreateTableDef method, found here. An AutoExec macro establishes the tables at start-up. On my machine, running Windows 7 Professional 64-bit with Access 2016 (Version 1801, Build 9001.2171), it opens up with no issues. Another, rather disparate machine out in the shop, running Windows XP 32-bit with the Access 2010 Database runtime engine (this machine does not have a full version of Office, only the runtime) also works without a problem.
Other computers here in the office, however, running the same version of Office, with Windows 7 or 10, always 64-bit & Professional, when opening the .mdb file, fail to connect to SQL Server.
In one case, Access will hang for up to 30 minutes, before spitting out
ODBC--connection to '(server name here)' failed.
I've tried running a server profiler while Access is attempting to establish a connection, and what I'm seeing is that the server apparently isn't seeing the connection attempt, at all. This particular machine also runs a separate utility written in VC# to connect to and manipulate the database, which runs without a hitch. Only in the Access frontend, do I encounter problems.
So, in summary:
Microsoft SQL Server backend
Access frontend
Access frontend has no problems connecting on some machines, fails to connect on other machines.
Separate utility written in VC# works fine everywhere it's tried, including machines where the Access frontend doesn't work.
Profiler trace on server doesn't show any connection attempt being made by machines where the Access frontend doesn't seem to work.
I've tried installing the Access Database Engine, I've tried installing SSMS on one machine (no dice), I've installed as many different ODBC drivers from Microsoft as I can find, but nothing seems to make a difference. I'm inclined to think that the problem is not the driver, but some kind of network-related issue, and somehow specific to Access.
Any ideas? Is there some arcane software requirement that I'm just not aware of?
So, I found this thread, where someone has having trouble connecting on a first attempt. Turns out that this is a firewall issue. By nailing down the port the SQL Server instance is using, and explicitly opening it in the firewall, all connection issues apparently go away. Why it worked without issue on some computers, I still have no idea, but after making this change, everything does what it's supposed to.
So, I'm trying to use pymssql to connect to a SQL Server database from my Linux box. The database can only be reached from inside my company's private network. It is set up to accept SQL Server authentication and, from my windows machine, I am able to connect and query it when I am logged on to the VPN (Cisco Anyconnect is the client installed on the Windows box).
The python script works correctly when run on a linux machine that is plugged into the internet at work. I haven't tried it on my windows machine (because, right now, I have no python on that machine, for one).
On my linux machine at home, I have downloaded OpenConnect, which seems to be working fine for establishing a VPN connection. When I run my script from this machine, while on the VPN, I successfully connect to the database. If the test query I use in the script is to creat a table, or manipulate data in the database, it works. However, I am not able to RETRIEVE any data, i.e., if I run a select query, I get [].
(Also, it is perhaps worth mentioning, that the first thing I tried to do, before figuring out how to get a VPN client on my linux machine (at first I was messing around with Cisco stuff which was a nightmare), was to ssh from my windows machine inside the private network to my home linux machine while forwarding a port from my home linux machine to 1433 on the SQL Server machine. Then instead of using pymsswl.connect() to connect to the SQL SERVER machine, I connected to my local port. I observed the same behavior, actually, in this case as over the VPN. I wasn't particularly surprised that I couldn't get data back in that case, since it's overwrought, and I could see SQL Server not knowing where to send the data....although I am really just speculating there anyway...)
I should also mention that when I click around in the Cisco folder on my Windows machine, there is a "security catalog" with all kinds of wonkiness in it that I don't know much about. Maybe these certificates/thumbprints are at play.
So, I admit total noobness here, and would appreciate any help. If I said something senseless, or if there is other information that might apply, I'll do my best to clarify.
Are you logging in with SQL Server authentication? And how are you running your queries? Sproc have implied rights, meaning if your using a table that you don't have access to it will still work but doing a simple select will deny access, Long shot but who knows.
Here is a link where Pinal Dave talks about a similar error and goes through in detail how to check to make sure the instance is up and a number of other troubleshooting steps you should try. http://blog.sqlauthority.com/2009/05/21/sql-server-fix-error-provider-named-pipes-provider-error-40-could-not-open-a-connection-to-sql-server-microsoft-sql-server-error/
We've been experiencing a strange issue with SQL 2008 R2 (10.50.1600) installed as a named instance. In order for any external clients to connect, we have a certain procedure we have to follow, but should not have to. Now I did in fact open the TCP/IP and Named Pipes protocols on the SQL server and restarted it, this isn't the problem. We're on an Active Directory Domain (running from Server 2003). The problem exists no matter what OS the server or client is (XP, 2003, 2008, Vista, 7, 64bit, 32bit, etc.). The problem also persists from anything which can connect, for example, SQL Management Studio, ADO (from our applications), etc.
The problem is that before any client can connect to this server, each client machine must first connect to this server through ODBC (and we don't use ODBC). Any attempt to connect to a 10.5 SQL server before doing this results in "Server does not exist or access denied". But once we can connect in the ODBC (through Named Pipes), then everything else starts to work. The same issue occurs both when using the Computer Name and IP Address. In fact, if we want to connect with computer name \ instance name, then we have to do so first in the ODBC, and then if we want to connect via the IP address \ instance name, then we have to do the same also for that.
We've been having to do this on every single client computer. Again, once the ODBC is able to connect to this SQL server through Named Pipes, then all future attempts from that client work.
What could be causing this to occur? How to avoid it? I should not have to do this "ODBC Trick" as we've been calling it. I've never had this issue on any other version of SQL.
The issue might be related to the SQL Browser service. Each sql instance will have a different port number - try connecting from the client as IP Address,Port (e.g. 123.123.123.1,1433) - this will exclude DNS and Browser from the equation
Edit: now knowing that it is browser related, try see why clients can't access SQL Browser (usually Port 1434). Service not started? Possibly firewall blocking?
Microsoft have tied down everything security wise now by default, so any new configuration now generally requires quite a bit of detailed security planning, policy configuration, permissions etc. Welcome to the age of non-trust ;)
You could easily test your connection by creating a simple file. Follow the steps here at "How to test an SQL Server connection": http://teusje.wordpress.com/2012/02/21/how-to-test-an-sql-server-connection/
I'm running VS2008 on my client machine and I'm running SQL 2000 on the remote db server which is on a different domain. I am able to remote desktop to the remote computer and use query analyser to debug, however it doesn't work when I try it remotely. I don't get any errors and when I try and step into the sp it doesn't halt.
From the research I have done it looks like the client PC is trying to attach to a process on the remote machine. However since this is on an another domain the user that VS 2008 uses won't be able to authenticate with the remote machine.
I believe this possible but my question is what do I need to configure to make this work, or is there any additional software that I require for this. I've tried using the VS Remote debugging monitor on the db server, but not sure whether I'm barking up the wrong tree with this.
Thanks
The knowledgebase article INF: Transact-SQL Debugger Limitations and Troubleshooting Tips for SQL Server 2000 may still be relevant/helpful (although obviously, they've fixed the first mentioned limitation concerning terminal services/remote desktop)