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/
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.
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.
I have made a program using visual basic 2010, which contains a database. When I copy my program across to another computer and attempt to debug it, I get the following error message:
An unhandled exception of type 'System.Data.SqlClient.SqlException' occurred in System.Data.dll
Additional information: Login failed for user 'Aaron\Aaron'.
And the following line of code is highlighted within the form load sub:
Me.Table1TableAdapter.Fill(Me.Database1DataSet1.Table1)
When I publish the program it also fails to run on any computer other than the one I created it on.
Any help would be much appreciated as I'm still very new to programming, thank you.
If you're trying to access the database over the network, use:
server="HostMachineIP\Aaron" (e.g. "10.1.1.1\Aaron") and make sure firewall port 1433 is open.
If you're transferring the database to another system, set your connection string to: ".\Aaron" - the .\ references the local system.
There are lots of things that could be the issue, but for starters, you probably don't have the same user set up on your other computer that you had on your first one. That is probably why you are getting the error about Login failed for Aaron/Aaron.
Additionally, you may well have a database on the first computer that is not on the second. Transferring the program does not copy the database with it. So you should go into SQL Server on your first computer and compare it to SQL Server on your second one. Likely there are differences in users and databases that will cause problems.
From your description, it sounds like maybe you aren't using a "server" yet.
You won't have much luck if you are moving/copying the .mdf file. Your dev environment will allow this, but not other machines. It will work better if you install SQL Express on one of your machines and use it to host your .mdf (database file). That machine will be your "server".
Download SQL Server Express and install it
Download SQL Server Management Studio. Use it to attach your .mdf. Set permissions. Allow remote connections.
Check your windows firewall (on the server) to make sure port 1433 is open (SQL server communicates across a network on port 1433.
Each machine (except for the server) will need to authenticate to the server. I find this is easier when I map a drive to the server. On the server, make a folder on the hard drive called "temp", share it to the network. On each machine, explore the network, find your server, find the share (temp), map a drive to it.
Once you have done these things, then these other recommendations will work.
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)