I've scoured the internet and apparently in the Linux version of SQL Server 2019 linked servers are only allowed between 1 SQL Server to another SQL Server. I need to create a linked server from linux SQL Server 2019 to postgresql 4.17 so I can query tables that are in PostgreSQL from SQL Server.
I have ODBC drivers installed on my Windows machine that can connect and I have the odbc drivers installed on my ubuntu server that hosts SQL Server 2019. I can also connect and pull data and run queries from SSIS. OPENQUERY, OPENDATASOURCE and OPENROWSET do not work either.
I can't believe this is not possible. Any suggestions or ideas on how to do this or the closest best possible solution would be greatly appreciated.
Edit
Linux version of SQL Server 2019 only supports linked server connections to other SQL Servers.
https://learn.microsoft.com/en-us/sql/linux/sql-server-linux-editions-and-components-2019?view=sql-server-linux-2017
I suggest looking at other ways for importing data, like BCP and SSIS, unfortunately.
End of edit
Your statement: "apparently in the Linux version of SQL Server 2019 linked servers are only allowed between 1 SQL Server to another SQL Server." Could you perhaps link to where that is stated in the Microsoft documents?
In the release notes for SQL Server 2019 on Linux I see mention of linked servers (with no statement that you can only connect to other SQL Servers).
Is there an error message you are receiving, or could you give us some more information on what steps you have taken and troubleshooting you've done? There are some configurations needed to insure communication on linux, according to the docs:
Features that involve outbound TCP connections from the sqlservr
process, such as linked servers or Availability Groups, might not work
if both the following conditions are met:
The target server is specified as a hostname and not an IP address.
The source instance has IPv6 disabled in the kernel. To verify if your
system has IPv6 enabled in the kernel, all the following tests must
pass:
cat /proc/cmdline will print the boot cmdline of the current kernel.
The output must not contain ipv6.disable=1.
The /proc/sys/net/ipv6/ directory must exist.
A C program that calls socket(AF_INET6,
SOCK_STREAM, IPPROTO_IP) should succeed - the syscall must return an
fd != -1 and not fail with EAFNOSUPPORT. The exact error depends on
the feature. For linked servers, this manifests as a login timeout
error. For Availability Groups, the ALTER AVAILABILITY GROUP JOIN DDL
on the secondary will fail after 5 minutes with a download
configuration timeout error.
To work around this issue, do one of the following:
Use IPs instead of hostnames to specify the target of the TCP
connection.
Enable IPv6 in the kernel by removing ipv6.disable=1 from the boot
cmdline. The way to do this depends on the Linux distribution and the
bootloader, such as grub. If you do want IPv6 to be disabled, you can
still disable it by setting net.ipv6.conf.all.disable_ipv6 = 1 in the
sysctl configuration (for example, /etc/sysctl.conf). This will still
prevent the system's network adapter from getting an IPv6 address, but
allow the sqlservr features to work.
Related
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 am aware of "SQL Server Profiler", But is there any tools or methods available to monitor the issued sql queries from the client machine?
Some of the things currently in my mind are:
1) The SysInternals ProcMon can log and tell when the executable process on client machine connects to sql server. Any similar but more advanced tools available to tell more data?
2) Any debug version or instrumented version of client libraries and APIs available for client machine to allow such operation?
You can enable ODBC Tracing from the ODBC Data Source Administrator (odbcad32.exe). The log file it generates is rather cryptic but it will provide you with the SQL statements run by the logged in user on that machine. There is also a checkbox labeled "Machine-Wide tracing for all user identities" for logging all SQL statements run by any user - including services - on that machine.
Logging may not start until you disconnect and reconnect to the SQL server. So, it is a good idea to restart whatever programs/services connect to your SQL Server. This is especially important if you have connection pooling enabled, which will keep connections open even if the program, in question, has disconnected.
Also, there are two versions of the ODBC Data Source Administrator on Windows 64bit, one for 32bit and the other for 64bit. So, you will need to enable logging for the appropriate bitness of the program you are tracing.
How To Generate an ODBC Trace with ODBC Data Source Administrator
Setting Tracing Options
Why my 32 bit applications cannot see the ODBC DSNs that I created on my 64 bit machine ?
ODBC Administrator tool displays both the 32-bit and the 64-bit user DSNs in a 64-bit version of Windows
Update: Another option for you would be to use a tool like Wireshark. Since it has the ability to sit at the network driver level, it can intercept all your network traffic - including but not limited to SQL. These are known as TDS packets - a standard that is used by Sybase SQL Server (ASE), Microsoft SQL Server and FreeTDS ( w/ UnixODBC).
RPR NA03: Analysing SQL Server performance using Wireshark and Excel
How do I filter SQL Server traffic between app and DB servers using Wireshark?
How can I decode SQL Server traffic with wireshark?
What does my SQL Server data look like over the wire?
Google Search for "Wireshark+SQL"
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 trying to link SQL Server 2005 to an Oracle 10g database. I've installed the Oracle client on the SQL server and validated that I can connect to the Oracle database using both tnsping and sqlplus. When I try to run a query in SQL Server I get the following:
OLE DB provider "OraOLEDB.Oracle" for linked server "ORA_CSSA2APD" returned message "ORA-12154: TNS:could not resolve the connect identifier specified".
Msg 7303, Level 16, State 1, Line 1
Cannot initialize the data source object of OLE DB provider "OraOLEDB.Oracle" for linked server "ORA_CSSA2APD".
Any ideas? I've tried both of the following queries with no luck:
select * from openquery(ORA_CSSA2APD, 'select count(rowid) from eservice_op.agent')
select count(rowid) from ORA_CSSA2APD..eservice_op.agent
I suspect an environment setting. That is, your session is picking up the TNSNAMES.ORA file but the session underlying SQL Server is not. I'd check were ORACLE_HOME and, possibly, TNS_ADMIN are being set and pointing to.
Are you able to use the easy connect syntax for the database with the SQL Server connection .
IE replace ORA_CSSA2APD with hostname:1521/service_name
ORA:12154 generally means that the alias of the db you're trying to connect to wasn't found in the tnsnames.ora file. (See http://ora-12154.ora-code.com/ a more detailed explanation.)
You need to make sure that the Data Source is an alias that the tnsnames file knows about (on the server where SQL Server resides, regardless of where you're running the queries from); SQL Server is going to be just like any other Oracle client and needs to know where to connect to and without the tnsnames.ora file, it's not going to know the details of where the Oracle db is.
If you don't have access to the SQL Server server (there's one from the department of redundancy department), you'll need to get the server admin to set that up for you.
(The Data Source property of the linked server should be the alias in tnsnames.ora alias for the db you're trying to link to.)
HTH...
TNS error messages generally means the connection is flawed (eg host is unobtainable/timesout on the specified port, or that is simply doesn't know what ORA_CSSA2APD is supposed to point to).
One thing to consider is, are you using a 64-bit Windows and are you using a 32-bit or 64-bit Oracle client (or possibly both). If you've got a 32-bit app running on a 64-bit OS trying to call Oracle, it needs a 32-bit Oracle client. Using a 32-bit client on a 64-bit OS can be tricky and it is safer to NOT install it in the "Program Files (x86)" folder.
Also bear in mind the following
In a 64-bit version of Windows Server
2003 or of Windows XP, the
%WinDir%\System32 folder is reserved
for 64-bit applications. When a 32-bit
application tries to access the
System32 folder, access is redirected
to the following folder:
%WinDir%\SysWOW64
So for 64-bit windows, the 32 bit stuff is in the SysWOW64 folder and the 64 bit stuff is in the system32 folder.
This issue happened to me, as well, but only with certain Windows user accounts. A combination of enabling the "Allow inprocess" provider option for the OraOLEDB.Oracle provide (SSMS > Server Objects > Linked Servers > Provides > OraOLEDB.Oracle), restarting the SQL Server Windows service and lastly adjusting the permissions on the TNSNAMES.ora file directly.
We found that SQL Server, for some unknown reason, started looking for the TNSNAMES.ORA file in default Oracle locations.
We were able to place the TNSNAMES.ORA files in the following locations, with successful results:
For SQL Server 32-bit on 32-bit OS or 64-bit on 64-bit OS
%ProgramFiles%\Oracle
%ProgramFiles%\Oracle\network\admin
For SQL Server 32-bit on 64-bit OS
%ProgramFiles% (x86)\Oracle
%ProgramFiles% (x86)\Oracle\network\admin
We too were able to connect using SQL*Plus, but SQL Server could not. It is important to note that SQL*Plus did not use the same TNSNAMES.ORA file. This is why one worked.
I am unable to connect to my local instance of SQL Server 2008 Express using SQL Server Management Studio.
I believe the problem is related to a change I made to the connection protocols. Before the error occurred, I had Shared Memory enabled and Named Pipes and TCP/IP disabled. I then enabled both Named Pipes and TCP/IP, and this is when I started experiencing the problem.
When I try to connect to the server with SSMS (with either my SQL server sysadmin login or with windows authentication), I get the following error message:
A connection was successfully established with the server, but then an error occurred during the login process. (provider: Named Pipes Provider, error: 0 - No process is on the other end of the pipe.) (Microsoft SQL Server, Error: 233)
Why is it returning a Named Pipes error? Why would it not just use Shared Memory, as this has a higher priority order in the list of connection protocols? It seems like it is not listening on Shared Memory for some reason?
When I set Named Pipes to enabled and try to connect, I get the same error message.
My windows account is does not have administrator priviliges on my computer - perhaps this is making a difference in some way (as some of the discussions in this post about an "SuperSocketNetLib\Lpc" registry key seems to suggest).
Had the same problem. Here is what solved it for me:
Open SQL Management Studio
Connected through the admin account I used to setup the instance
Selected the server from Object Explorer
Right mouse click properties
Server properties opens
Go to Security
Changed it from Windows Authentication mode to SQL Server and Windows Authentication Mode
I didi everything google teaches and can't connect with TCP/IP successfully. Then I do these steps to make it work in my home computer:
step 1. Enable TCP/IP in SQL Server Network Configuration for your DB instance.
step 2. Choose properties of TCP/IP and click IP Addresses tab.
step 3. Inactive all IP address except 127.0.0.1.
step 4. Set TCP Port to 1433 in 127.0.0.1 and IPALL.
step 5. Restart sql server service.
step 6. Connect it with TCP/IP using '127.0.0.1\SQLEXPRESS,1433' in Toad for SQL Server freeware, it works!
step 7. Connect it with same server string in php, it works!
step 8. If you need read Chinese string into php program as I am, download MS SQL Server driver for PHP(Believe me, don't even try php_mssql stuff, it'll drive you crazy with Chinese data). For PHP 5.2x, use ts_VC6 version. For 5.3X, use ts_VC9 version (especially when in Win7).
step 9. Edit php.ini (For Appserv, it's under C:\Windows7; for WAMPserver 2.2, it's under c:\wamp\bin\php\php5.3.8), find extension=... line groups. Add 'extension = specific sql erver driver dll filename you are to use.
step 10. Unzip the file downloaded in step 8 and copy the specific dll (or copy all) to php extension directory (you can find it in php.ini's extension_dir=... line). For Appserv, you better copy it to c:\windows\system32, too(Don't ask me why?).
step 11. restart apache service of Appserv or restart Wampserver.
Now you can use TCP/IP to connect with SQL Server 2008 and you can read utf-8 string (in my case) into php program correctly.
Hope this helps those who are deperately looking for this solution, as i am.
Since now you cannot connect to SQL Server to disable named pipes, you have to force a TCPIP connection.
Here's how:
click on START / RUN then run the cliconfg.exe utility. In this, create an alias for your server (you can use the same name) and put the default for TCPIP
That should force TCPIP over Named Pipes and maybe get you connected.
Try connecting to the alias name that you used in CliConfg and it will now connect using TCPIP.
I had this exact same problem. I'd try connecting as ASHWHVM004\SQLEXPRESS and I'd get a connection failed message. If I explicitly requested Shared Memory, it'd work fine. Shared Memory, Named Pipes, and TCP/IP were all enabled.
I seemingly "fixed" it by doing the following:
I opened up Sql Server Configuration Manager and drilled down to SQL Server Network Configuration > Protocols for SQLEXPRESS.
I disabled everything except Shared Memory.
I restarted the SQLEXPRESS service instance and tried connecting as before. It worked fine.
I enabled TCP/IP and Named Pipes and restarted the SQLEXPRESS service instance and tried connecting as before. It worked fine.
Either I did something else during this process to fix it that I don't recall, or the act of disabling and re-enabling caused some twiddly bit to get flipped back the right way.
Good luck!