FreeTDS hangs indefinitely when I try to connect to a server:
C:\FreeTDS\bin>tsql -H localhost -p 1433
locale is "English_United States.1252"
locale charset is "CP1252"
using default charset "CP1252"
(nothing else is displayed, can only exit with ^C)
Identical behaviour occurs when I run tsql -S <servername>.
I recently uninstalled Microsoft SQL Server Management Studio, and then installed the Express edition. Connection with tsql -H localhost -p 1433 worked before the uninstall/install.
Running tsql -C yields:
Compile-time settings (established with the "configure" script)
Version: freetds v0.91.98
freetds.conf directory: /mingw/etc
MS db-lib source compatibility: no
Sybase binary compatibility: no
Thread safety: yes
iconv library: yes
TDS version: 7.0
iODBC: no
unixodbc: yes
SSPI "trusted" logins: yes
Kerberos: yes (Heimdal 1.5.3)
SSL encryption: yes (OpenSSL 1.0.1e)
Some more information:
I have the folowing SQL-related services running:
SQL Full-Text Filter Daemon Launcher (SQLEXPRESS)
SQL Server (SQLEXPRESS)
SQL Server Browser
SQL Server Reporting Services (SQLEXPRESS)
SQL Server VSS Writer
I have tried reinstalling FreeTDS.
I have enabled TCP/IP for SQLEXPRESS in the Sql Server Configuration Manager.
The tsql command was hanging because the server was not running on the default port. I found this out by running C:\>netstat -na | find "1433", which showed nothing LISTENING on port 1433.
This is how I fixed the problem:
Open "Sql Server Configuration Manager"
Go to "SQL Server Network Configuration > Protocols for SERVER"
Right click "TCP/IP", select "Properties", go to the "IP Addresses" tab
Under "IPAll" set "TCP Port" to the desired port number
Click OK, and restart the SQL Server service.
Related
I installed an application on a Windows machine, and it silently installed Microsoft SQL Server Express (mssql) as dependency. By reading the documentation, I know that the mssql was installed with these command line options:
“C:\Users\<USERNAME>\AppData\Local\Temp\SQLEXPR_x64_ENU.exe” /q /ACTION=Install
/FEATURES=SQLEngine,FullText /INSTANCENAME=BarTender /SQLSYSADMINACCOUNTS="Builtin\Administrators"
"NT AUTHORITY\SYSTEM" /SQLSVCACCOUNT="NT AUTHORITY\SYSTEM" /ADDCURRENTUSERASSQLADMIN /TCPENABLED=1
/IACCEPTSQLSERVERLICENSETERMS /HIDECONSOLE /SkipInstallerRunCheck /UpdateEnabled=0
/SKIPRULES=RebootRequiredCheck SetupCompatibilityCheck NoRebootPackage
It used Windows Authentication instead of SQL Server Authentication.
I could not connect to it using sqlcmd from another Linux machine. I tried sqlcmd -S 192.168.1.x\\BarTender -U <mssql_server_hostname>\\Administrator and it failed (looks like -U options is for SQL Server Authentication only). Then I tried sqlcmd -S 192.168.1.x\\BarTender -E and of course it failed again for obvious reason -- neither the mssql server nor my Linux machine joined a domain:
Sqlcmd: Error: Microsoft ODBC Driver 17 for SQL Server : SSPI Provider: No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_1000).
Sqlcmd: Error: Microsoft ODBC Driver 17 for SQL Server : Cannot generate SSPI context.
How do I connect to the mssql instance from my Linux machine without both machines joining a domain?
I'm in a linux container using the gem file tiny_tds (verions 2.1.1) to try to connect to sql server on an Azure Managed instance.
The code I'm using to connect is this:
client=TinyTds::Client.new(:username=>'username#full.server.name', :password=> 'password', :host=>'full.server.name.database.windows.net', :port=>3342, :database=>'database', :azure=>true)
I've tried running this both from the ruby console, as well as from within the container.
Here is the info for the freetds that I'm using:
Version: freetds v1.00.91
freetds.conf directory: /usr/local/etc
MS db-lib source compatibility: no
Sybase binary compatibility: no
Thread safety: yes
iconv library: yes
TDS version: 7.3
iODBC: no
unixodbc: no
SSPI "trusted" logins: no
Kerberos: no
OpenSSL: yes
GnuTLS: no
MARS: no
I'm consistently getting the error message:
Login failed for user 'username#full.server.name
Curiously, I'm able to connect via freetds:
tsql -H full.server.name.database.windows.net -U username -D database -p 3342 -P password
I'm wondering if it has something to do with the server/host having multiple '.' characters in the host name.
Also, from what I've read about tiny_tds, when connecting to Azure, the username needs to have the #servername appended to it.
I have tried several version of tiny_tds (all to no effect).
I have also tried many various permutations of the connection string. Nada.
Please let me know if you have any suggestions!!
I have install the driver odbc 2.3.0 on linux by this reference: https://www.microsoft.com/en-ca/download/confirmation.aspx?id=28160
All these steps work correctly.
This is my configation:
SERVER:
Oracle server is on linux
SQL Server is on windows
SQL Server:
My login and password are the same. It's: demo
When I use cmd and I use the command: "ipconfig", I can get my IP
My IP is: 192.168.0.106
This is how I do my connection manually and it work:
After the installation, i have configure my files odbinst.ini and odbc.ini
This is my file odbcinst.ini:
This is my file odbc.ini:
This is where my driver is download:
My instance name is MSSQLSERVER and TCP-IP and listen all are enable:
Dynamic port is blank and static port is 1433:
As you see, I can be connect on localhost with the command line:
sqlcmd -S 192.168.0.106 -d demo -U demo -P demo
But, I can't connect with my Oracle server on putty with this command line:
isql MSSQLSERVER -v
Why it don't work?
The server is start
Allows remotely connexion is enable
I have add port 1433 in firewall setting
I tried to disable the firewall, nothing change
Something is wrong in my configuration?
Problem reseolve :
Change sqlServer Localhost to SqlServer.
You can't connect 2 server if they are on localhost. You need an oracle SQL Server and SQlServer working not on LocalHost
While trying to connect remote SQL Server:
$tsql -S localhost -U myuser
I got error like:
locale is "en_US.UTF-8"
locale charset is "UTF-8"
using default charset "UTF-8"
Error 20009 (severity 9):
Unable to connect: Adaptive Server is unavailable or does not exist
OS error 61, "Connection refused"
There was a problem connecting to the server
The output of $tsql -C is as below:
Compile-time settings (established with the "configure" script)
Version: freetds v0.91
freetds.conf directory: /usr/local/freetds/conf/freetds
MS db-lib source compatibility: no
Sybase binary compatibility: no
Thread safety: yes
iconv library: no
TDS version: 5.0
iODBC: no
unixodbc: no
SSPI "trusted" logins: no
Kerberos: no
I have created tunnel for remote server like:
$ssh -L 1433:db_server:1433 user#mid_server
This forward the local port 1433 to db_server. I tested. My ssh tunnel works because I can connect to database using Navicat (localhost on 1433). I can telnet localhost on port 1433.
I kinda get it worked by modifying freetds.conf
from
[global]
# TDS protocol version
; tds version = 4.2
to
[global]
# TDS protocol version
tds version = 7.0
This worked for me with ASE 16.0 installed and running on Ubuntu 14.04 LTS, both client and server.
SERVER: Make sure there is an entry in /etc/hosts of your server (sybaseServer). In a standard Ubuntu 14.04 installation you will not find this, but "127.0.1.1 sybaseServer". But sybase seems depends on it.
/etc/hosts
...
192.168.1.100 sybaseServer
...
CLIENT: The entry in freetds.conf is
[SYBASE]
host = 192.168.1.100
port = 5000
tds version = 5.0
Now you can connect to your server:
$tsql -S SYBASE -U sa
obviously you have to replace IP-address, servername etc. with your own data
I've decided to use FreeTDS driver and unixODBC to manage the PDO connection between my LAMP-based app with a remote MsSQL database.
unfortunately it appears that the driver doesn't read the freetds.conf file, nor the environmental variables set either directly via server's CLI or specified in php file by putenv() function.
now some data:
as I ping the server - no packets are lost.
as I telnet the server on 1433 port - the connection is established
as I use the command
TDSVER=7.0 tsql -H >IP< -p 1433 -U username
I am prompted to enter password and connection is established.
without the TDSVER preceding the command - the connection fails with such a message:
Error 20017 (severity 9):
Unexpected EOF from the server
OS error 115, "Operation now in progress"
Error 20002 (severity 9):
Adaptive Server connection failed
There was a problem connecting to the server
the tsql -C commands echos such an output:
Compile-time settings (established with the "configure" script)
Version: freetds v0.91
freetds.conf directory: /usr/local/etc
MS db-lib source compatibility: yes
Sybase binary compatibility: no
Thread safety: yes
iconv library: yes
TDS version: 5.0
iODBC: no
unixodbc: yes
SSPI "trusted" logins: no
Kerberos: no
freetds.conf in the location given above has this entry:
[MSSQL]
host = >IP<
port = 1433
tds version = 7.0
the ISQL also fails:
isql -v MSSQL
[S1000][unixODBC][FreeTDS][SQL Server]Unable to connect to data source
[01000][unixODBC][FreeTDS][SQL Server]Adaptive Server connection failed
[ISQL]ERROR: Could not SQLConnect
my odbc.ini :
[MSSQL]
Description = MS SQL Server
Driver = FreeTDS
TDS_Version = 7.0
Server = >IP<
UID = username
PWD = password
ReadOnly = No
Port = 1433
I suppose the solution is really simple, but i'm just too stupid to find it...
I spent a long time today debugging a similar problem. I had set "TDS version" in freetds.conf but it was not being used in my ODBC connection. After reading the freetds source code (connectparams.c:odbc_parse_connect_string) I discovered that:
If your connection string uses "SERVER=" then both freetds.conf and odbc.ini are ignored
If your connection string uses "SERVERNAME=" then the settings in the appropriate freetds.conf server are used
If your connection string uses "DSN=" then the settings in the appropriate odbc.ini DSN are used
odbcinst.ini is a red herring. FreeTDS never checks that for settings.
The settings you specify in the connection string are always respected. It also always respects the environment variables like TDSVER.
My gut instinct is you need to change your tds version = 7.0 to tds version = 8.0 in your freetds.conf and odbc.ini files AND you need something in your odbcinst.ini file. Here's what I've got working on an Ubuntu 12.04 server talking to a remote MSSQL server:
freetds.conf
# Define a connection to the MSSQL server.
[mssql]
host = myserver
port = 1433
tds version = 8.0
odbc.ini
# Define a connection to the MSSQL server.
# The Description can be whatever we want it to be.
# The Driver value must match what we have defined in /etc/odbcinst.ini
# The Database name must be the name of the database this connection will connect to.
# The ServerName is the name we defined in /etc/freetds/freetds.conf
# The TDS_Version should match what we defined in /etc/freetds/freetds.conf
[mssql]
Description = MSSQL Server
Driver = freetds
Database = MyDB
ServerName = myserver
TDS_Version = 8.0
odbcinst.ini
# Define where to find the driver for the Free TDS connections.
[freetds]
Description = MS SQL database access with Free TDS
Driver = /usr/lib/i386-linux-gnu/odbc/libtdsodbc.so
Setup = /usr/lib/i386-linux-gnu/odbc/libtdsS.so
UsageCount = 1
I experienced this exact same problem, but my config was already correctly set up. The problem was that the TDS versions that freetds.conf recognizes has changed in newer versions, but apparently the old versions still work in the TDSVER environment variable. Once I set the version in the config files to 7.1 rather than 8.0 everything started working.
The initial TDSVER=7.0 issue was resolved by adding the following at the end of my odbc.ini file:
[Default]
Driver=/usr/local/lib/libtdsodbc.so
Instead of connecting to an IP, try to connect to the name of the configuration section? For example:
isql -v MSSQL