I get this error on Linux (Ubuntu and CentOS) when executing a stored proc from Perl/DBI/ODBC/FreeTDS to SQL Azure: [unixODBC][FreeTDS][SQL Server]Read from the server failed (SQL-08S01) I don't get this error running the same Perl script on Windows (ODBC/Native) connecting to the same SQL Azure database, and although the proc takes a couple minutes to run, it does complete. Obviously a completely different client/driver environment, but they are both going to the same SQL Azure database and there is no difference in the Perl script itself. Both Perl environments should be similar but obviously the client/drivers will be different. The line which fails is simple - a proc with no parameters which takes data from a staging table and processes it - at the time of failure from Linux call, the environment on SQL Azure is not significantly different than when I test called from Windows (it is completely reproducible when the staging table is loaded with certain data and invoked from Linux): $dbh->do("EXEC procname;") or die $DBI::errstr ; Indications from my searches are that this is some kind of connection issue or timeout. I'm working to improve the proc performance, but the timeout is not set on the Linux machines (so should default to 0). Is there something I can do to stop this error? Here is the log from FreeTDS of a bad run: util.c:156:Changed query state from IDLE to QUERYING write.c:140:tds_put_string converting 27 bytes of "EXEC DWTOOLS.LoadFromStage;" write.c:168:tds_put_string wrote 54 bytes util.c:156:Changed query state from QUERYING to PENDING net.c:741:Sending packet 0000 01 01 00 3e 00 00 01 00-45 00 58 00 45 00 43 00 |...>.... E.X.E.C.| 0010 20 00 44 00 57 00 54 00-4f 00 4f 00 4c 00 53 00 | .D.W.T. O.O.L.S.| 0020 2e 00 4c 00 6f 00 61 00-64 00 46 00 72 00 6f 00 |..L.o.a. d.F.r.o.| 0030 6d 00 53 00 74 00 61 00-67 00 65 00 3b 00 |m.S.t.a. g.e.;.| net.c:1257:GNUTLS: level 4: REC[0x9a833c8]: Sending Packet Application Data(23) with length: 62 net.c:1257:GNUTLS: level 7: WRITE: enqueued 101 bytes for 0x9a574b8. Total 101 bytes. net.c:1257:GNUTLS: level 7: WRITE FLUSH: 101 bytes in buffer. net.c:1240:in tds_push_func net.c:1257:GNUTLS: level 7: WRITE: wrote 101 bytes, 0 bytes left. net.c:1257:GNUTLS: level 4: REC[0x9a833c8]: Sent Packet Application Data(23) with length: 101 token.c:540:tds_process_tokens(0x9a574b8, 0xbfcb9ca8, 0xbfcb9cac, 0x6914) util.c:156:Changed query state from PENDING to READING net.c:1199:in tds_pull_func util.c:331:tdserror(0x9a54e80, 0x9a574b8, 20004, 104) odbc.c:2270:msgno 20004 20003 util.c:361:tdserror: client library returned TDS_INT_CANCEL(2) util.c:384:tdserror: returning TDS_INT_CANCEL(2) util.c:156:Changed query state from READING to DEAD net.c:1257:GNUTLS: level 7: READ: -1 returned from 0x9a574b8, errno=104 gerrno=0 net.c:1257:GNUTLS: level 2: ASSERT: gnutls_buffers.c:344 net.c:1257:GNUTLS: level 2: ASSERT: gnutls_buffers.c:625 net.c:1257:GNUTLS: level 2: ASSERT: gnutls_record.c:969 token.c:555:processing result tokens. marker is 0() token.c:122:tds_process_default_tokens() marker is 0() token.c:125:leaving tds_process_default_tokens() connection dead util.c:104:logic error: cannot change query state from DEAD to PENDING odbc.c:3534:odbc_process_tokens: tds_process_tokens returned 0 odbc.c:3535: result_type=4055, TDS_DONE_COUNT=0, TDS_DONE_ERROR=0 odbc.c:3374:_SQLExecute: odbc_process_tokens returned result_type 4048 odbc.c:3450:SQLExecute: bad results error.c:517:SQLGetDiagRec(3, 0x9a89fe8, 1, 0xbfcb9ce6, 0xbfcb98b8, 0xbfcb9ae6, 512, 0xbfcb98bc) error.c:566:SQLGetDiagRec: "[FreeTDS][SQL Server]Read from the server failed" error.c:517:SQLGetDiagRec(3, 0x9a89fe8, 2, 0xbfcb9ce6, 0xbfcb98b8, 0xbfcb9ae6, 512, 0xbfcb98bc) odbc.c:3980:SQLFreeHandle(3, 0x9a89fe8) odbc.c:4075:_SQLFreeStmt(0x9a89fe8, 1, 0) odbc.c:4718:_SQLGetConnectAttr(0x9a55d78, 102, 0xbfcb9e90, -5, (nil)) odbc.c:2240:SQLDisconnect(0x9a55d78) mem.c:615:tds_free_all_results() net.c:1257:GNUTLS: level 6: BUF[HSK]: Cleared Data from buffer net.c:1257:GNUTLS: level 4: REC[0x9a833c8]: Epoch #1 freed odbc.c:3980:SQLFreeHandle(2, 0x9a55d78) odbc.c:4006:_SQLFreeConnect(0x9a55d78) odbc.c:3980:SQLFreeHandle(1, 0x9a552f0) odbc.c:4050:_SQLFreeEnv(0x9a552f0) Here is the log from a good run - the same proc, just slightly different data - there seems to be no error running the proc from Windows: util.c:156:Changed query state from IDLE to QUERYING write.c:140:tds_put_string converting 27 bytes of "EXEC DWTOOLS.LoadFromStage;" write.c:168:tds_put_string wrote 54 bytes util.c:156:Changed query state from QUERYING to PENDING net.c:741:Sending packet 0000 01 01 00 3e 00 00 01 00-45 00 58 00 45 00 43 00 |...>.... E.X.E.C.| 0010 20 00 44 00 57 00 54 00-4f 00 4f 00 4c 00 53 00 | .D.W.T. O.O.L.S.| 0020 2e 00 4c 00 6f 00 61 00-64 00 46 00 72 00 6f 00 |..L.o.a. d.F.r.o.| 0030 6d 00 53 00 74 00 61 00-67 00 65 00 3b 00 |m.S.t.a. g.e.;.| net.c:1257:GNUTLS: level 4: REC[0x96ed3c8]: Sending Packet Application Data(23) with length: 62 net.c:1257:GNUTLS: level 7: WRITE: enqueued 101 bytes for 0x96c14b8. Total 101 bytes. net.c:1257:GNUTLS: level 7: WRITE FLUSH: 101 bytes in buffer. net.c:1240:in tds_push_func net.c:1257:GNUTLS: level 7: WRITE: wrote 101 bytes, 0 bytes left. net.c:1257:GNUTLS: level 4: REC[0x96ed3c8]: Sent Packet Application Data(23) with length: 101 token.c:540:tds_process_tokens(0x96c14b8, 0xbfd5aeb8, 0xbfd5aebc, 0x6914) util.c:156:Changed query state from PENDING to READING net.c:1199:in tds_pull_func net.c:1257:GNUTLS: level 7: READ: Got 5 bytes from 0x96c14b8 net.c:1257:GNUTLS: level 7: READ: read 5 bytes from 0x96c14b8 net.c:1257:GNUTLS: level 7: RB: Have 0 bytes into buffer. Adding 5 bytes. net.c:1257:GNUTLS: level 7: RB: Requested 5 bytes net.c:1257:GNUTLS: level 4: REC[0x96ed3c8]: Expected Packet Application Data(23) with length: 8 net.c:1257:GNUTLS: level 4: REC[0x96ed3c8]: Received Packet Application Data(23) with length: 48 net.c:1199:in tds_pull_func net.c:1257:GNUTLS: level 7: READ: Got 48 bytes from 0x96c14b8 net.c:1257:GNUTLS: level 7: READ: read 48 bytes from 0x96c14b8 net.c:1257:GNUTLS: level 7: RB: Have 5 bytes into buffer. Adding 48 bytes. net.c:1257:GNUTLS: level 7: RB: Requested 53 bytes net.c:1257:GNUTLS: level 4: REC[0x96ed3c8]: Decrypted Packet Application Data(23) with length: 22 net.c:1257:GNUTLS: level 6: BUF[REC]: Inserted 22 bytes of Data(23) net.c:1257:GNUTLS: level 6: BUFFER[REC][AD]: Read 8 bytes of Data(23) net.c:555:Received header 0000 04 01 00 16 03 2f 01 00- |...../..| net.c:1257:GNUTLS: level 6: BUFFER[REC][AD]: Read 14 bytes of Data(23) net.c:609:Received packet 0000 04 01 00 16 03 2f 01 00-79 00 00 00 00 fe 00 00 |...../.. y.......| 0010 e0 00 00 00 00 00 - |......| token.c:555:processing result tokens. marker is 79(RETURNSTATUS) token.c:690:tds_process_tokens: return status is 0 util.c:156:Changed query state from READING to PENDING odbc.c:3534:odbc_process_tokens: tds_process_tokens returned 1 odbc.c:3535: result_type=4043, TDS_DONE_COUNT=0, TDS_DONE_ERROR=0 token.c:540:tds_process_tokens(0x96c14b8, 0xbfd5aeb8, 0xbfd5aebc, 0x6914) util.c:156:Changed query state from PENDING to READING token.c:555:processing result tokens. marker is fe(DONEPROC) token.c:2339:tds_process_end: more_results = 0 was_cancelled = 0 error = 0 done_count_valid = 0 token.c:2355:tds_process_end() state set to TDS_IDLE util.c:156:Changed query state from READING to IDLE token.c:2370: rows_affected = 0 util.c:104:logic error: cannot change query state from IDLE to PENDING odbc.c:3534:odbc_process_tokens: tds_process_tokens returned 1 odbc.c:3535: result_type=4053, TDS_DONE_COUNT=0, TDS_DONE_ERROR=0 odbc.c:3578:odbc_process_tokens: processed TDS_DONEPROC_RESULT token.c:540:tds_process_tokens(0x96c14b8, 0xbfd5aeb8, 0xbfd5aebc, 0x26914) token.c:543:tds_process_tokens() state is COMPLETED odbc.c:3534:odbc_process_tokens: tds_process_tokens returned 2 odbc.c:3535: result_type=4052, TDS_DONE_COUNT=0, TDS_DONE_ERROR=0 odbc.c:3374:_SQLExecute: odbc_process_tokens returned result_type 4046 odbc.c:4506:_SQLRowCount(0x96f3fe8, 0xbfd5b0b8) odbc.c:4525:SQLRowCount returns 0, row count -1 odbc.c:3980:SQLFreeHandle(3, 0x96f3fe8) odbc.c:4075:_SQLFreeStmt(0x96f3fe8, 1, 0) odbc.c:4718:_SQLGetConnectAttr(0x96bfd78, 102, 0xbfd5b240, -5, (nil)) odbc.c:2240:SQLDisconnect(0x96bfd78) mem.c:615:tds_free_all_results() net.c:1257:GNUTLS: level 6: BUF[HSK]: Cleared Data from buffer net.c:1257:GNUTLS: level 4: REC[0x96ed3c8]: Epoch #1 freed util.c:156:Changed query state from IDLE to DEAD odbc.c:3980:SQLFreeHandle(2, 0x96bfd78) odbc.c:4006:_SQLFreeConnect(0x96bfd78) odbc.c:3980:SQLFreeHandle(1, 0x96bf2f0) odbc.c:4050:_SQLFreeEnv(0x96bf2f0)

I am attempting to let a login kick off an SSIS package via the built-in SSISDB stored procedures instead of doing so through SQL Agent. The login will be connecting through an Airflow DAG on a Ubuntu box, so we're utilizing FreeTDS / pyodbc to allow it to authenticate as a Windows Login, which is working fine. However the following happens when launching the package: 1. Package is launched using [SSISDB].[catalog].[start_execution] @execution_id. Tried running both synchronously and asynchronously. 2. An execution ID is generated, along with an entry in [SSISDB].[catalog].[executions] with a [status of 5 ("Pending")](https://learn.microsoft.com/en-us/sql/integration-services/system-views/catalog-executions-ssisdb-database?view=sql-server-ver15) 3. ~1 minute later the the execution "completes" and the execution ID is wiped from all SSISDB tables and does not show up in any of the built-in reports. Even when adding exec parameters to [create dump files](https://learn.microsoft.com/en-us/sql/integration-services/troubleshooting/generating-dump-files-for-package-execution?view=sql-server-ver15) , none are created during the package execution. **Bonus problem:** During the ~1 minute timeframe, other packages being launched from SQL Agent that generally work fine often fail with this error message: > The operation failed because the execution timed out. Notes: * The SQL Server installation is on Windows and is SQL Server 2016 Ent. * This process works fine when using my Windows Authentication login from a Windows box. * The Windows account being used by the DAG is the agent service account, so has all necessary permissions. * The two SID fields in [[SSISDB].[catalog].[executions]](https://learn.microsoft.com/en-us/sql/integration-services/system-views/catalog-executions-ssisdb-database?view=sql-server-ver15) for the pending execution match the SIDs of other working executions being handled by SQL Agent for the same service account. * We are using TDS version 7.2 and the latest FreeTDS version. * No difference when using autocommit True/False * No blocking seen during execution I am guessing the login is being re-authenticated when it is used to launch the external SSIS process, but am hoping there may be some way to make this work still. Calling via CLR is an undesirable option due to the added complexity and security implications. I am also currently testing launching them via dtexec via xp_cmdshell (looking promising) but it is unclear to me how/why that would work and using the stored procedures does not.

Microsoft has official ODBC drivers for MS SQL Server, for Linux. Great! [Nice installation instructions for all the major distros, too.](https://blogs.msdn.microsoft.com/sqlnativeclient/2016/10/20/odbc-driver-13-0-for-linux-released/) Unfortunately, their ODBC drivers, going back to the [oldest version I can find](https://www.microsoft.com/en-us/download/details.aspx?id=28160) only support SQL Server 2005 and newer: > Native Data Access APIs – ODBC and OLE DB – for SQL Server 2005 and later. I need to connect to a very old SQL Server (2000): SELECT @@VERSION → Microsoft SQL Server 2000 - 8.00.2039 (Intel X86) May 3 2005 23:18:38 Copyright (c) 1988-2003 Microsoft Corporation Enterprise Edition on Windows NT 5.2 (Build 3790: Service Pack 2) I've confirmed that the v13 driver **does not work**: $ sqlcmd -U XXXX -S 10.1.2.3 Password: Sqlcmd: Error: Microsoft ODBC Driver 13 for SQL Server : ODBC Driver 13 for SQL Server does not support connections to SQL Server 2000 or earlier versions.. Sqlcmd: Error: Microsoft ODBC Driver 13 for SQL Server : Client unable to establish connection. — Is there an official MS SQL ODBC driver that will run on a modern 64-bit Linux and connect to SQL Server 2000? Or do I need to go to third party drivers like the open-source [FreeTDS](http://www.freetds.org/userguide/prepodbc.htm) ?

This is running on an AWS AMI EC2 Linux instance in a PHP script using dblib and PDO to connect to remote Sybase databases (Sybase version 11.0.1.2596). The server has freetds with these settings: Compile-time settings (established with the "configure" script) Version: freetds v0.91 freetds.conf directory: /etc MS db-lib source compatibility: yes Sybase binary compatibility: yes Thread safety: yes iconv library: yes TDS version: 4.2 iODBC: no unixodbc: yes SSPI "trusted" logins: no Kerberos: yes Sometimes when we run queries on the sybase computers we get an error like this (the token can vary): TDS: unexpected token 95 (severity 0) [(null)] The query sometimes runs even after this error and sometimes fails. I have searched online but I can't find what this error means or how to fix it. Here is an example of one of the queries: -- 999 | Hammil | 2017-04-05 08:23:29 SELECT 999 as 'site_id', (select rest_name from micros.rest_def) as 'location', now() as 'dt_run', emp_seq, employee_number as 'obj_num', last_name, first_name, check_number, xfer_from_check, xfer_from_type, xfer_to_check, xfer_to_type, check_id, table_number, table_name, group_number, cover_count, order_type, order_type_name, business_date, check_open_date_time, check_closed_date_time, table_open_date_time, printed_count, sub_ttl, tax_ttl, auto_svc_ttl, other_svc_ttl, paymnt_ttl, amount_due_ttl, sp_error FROM micros.micros.v_R_guest_checks x where x.check_closed_date_time is null; Sometimes we get this error: SQLSTATE[HY000]: General error: 20047 DBPROCESS is dead or not enabled (severity 1) [(null)] When this happens, I can run nc -v -w 4 xxx.xxx.xxx.xxx 2638 and it returns Connection to xxx.xxx.xxx.xxx 2638 port [tcp/sybaseanywhere] succeeded! but I will continue to get the error for a few minutes and then it goes away.

I have a C++ application that connects to SQL Server 2008 through FreeTDS unixODBC on an RHEL box. However, i am unable to insert supplementary characters to the database through FreeTDS unixODBC. [FreeTDS][SQL Server]Error converting characters into server's character set. Some character(s) could not be converted This is the query that my application is hitting INSERT INTO mytable (SAMPLE) VALUES(N'乕乭𠁄𠁉乺丕') == version details == unixODBC version - 2.3.0 freeTDS version - 0.95 I can successfully insert the characters in BMP. This characters are inserted perfectly fine. INSERT INTO mytable (SAMPLE) VALUES(N'乕乭乺丕') While using Microsoft SQL Server Native Client for Linux, the supplementary characters are inserted properly. == freetds conf == [mysever.mydomain.com] host = mysever.mydomain.com port = 1433 tds version = 7.3 debug flags = 0xffff dump file = /tmp/dump.log dump file append = no client charset = UTF-16 use utf-16 = yes unixODBC v2.3.0 has been built with ./configure --prefix=/usr/local/ --enable-iconv --with-iconv-char-enc=UTF8 --with-iconv-ucode-enc=UTF16LE FreeTDS v0.95 has been built with ./configure --prefix=/usr/local --sysconfdir=/usr/local/etc --with-tdsver=7.3

I have installed Oracle 12c on Centos 7 and I wanted to connect SQL Server 2014 using freeTDS. So, I installed the following: 1. FreeTds. 2. unixODBC.
Next, I configured ODBC on the Linux server so that, when I run isql dsn username password, I can connect to the MSSQL successfully and tnsping also succeed but when I run: select * from ItemTbl@MSSQL; I get this error: ERROR at line 1: ORA-28545: error diagnosed by Net8 when connecting to an agent Unable to retrieve text of NETWORK/NCR message 65535 ORA-02063: preceding 2 lines from MSSQL freetds.conf: [SQLSERVERADDRESS] host = 192.168.1.102 # MsSQL Server IP Address port = 1433 # MsSQL Server Port tds version = 8.0 # Tds version for SQL Server 2008 odbc.ini: [SQLDSN] Description = SQLDSN CONNECTION Driver = /usr/local/freetds/lib/libtdsodbc.so Servername = SQLSERVERADDRESS Database = Cafe11 [ODBC Data Sources] SQLDSN=FreeTDS initSQLDSN.ora: HS_FDS_CONNECT_INFO = SQLDSN HS_FDS_TRACE_LEVEL = 0 HS_FDS_SHAREABLE_NAME = /usr/lib64/libodbc.so HS_LANGUAGE = AMERICAN_AMERICA.WE8ISO8859P9 set ODBCINI=/etc/odbc.ini listener.ora: LISTENER = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = oracle.gorannet.net)(PORT = 1521)) ) ) SID_LIST_LISTENER = (SID_DESC = (SID_NAME=SQLDSN) (ORACLE_HOME=$ORACLE_HOME) (PROGRAM=/u01/app/oracle/product/12.1.0/db_1/bin/dg4odbc) tnsnames.ora: GORANNET = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.10.140)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = gorannet) ) ) SQLDSN = (DESCRIPTION = (ADDRESS = (PROTOCOL=TCP) (HOST=192.168.10.140) (PORT = 1521) ) (CONNECT_DATA = (SID = SQLDSN) ) (HS = OK) ) (ENVS= LD_LIBRARY_PATH=/usr/lib64:/usr/local/freetds/lib:$ORACLE_HOME/lib) ) ) tnsping result: [oracle@oracle ~]$ tnsping SQLDSN TNS Ping Utility for Linux: Version 12.1.0.1.0 - Production on 20-JUN-2015 23:52:01 Copyright (c) 1997, 2013, Oracle. All rights reserved. Used parameter files: /u01/app/oracle/product/12.1.0/db_1/network/admin/sqlnet.ora Used TNSNAMES adapter to resolve the alias Attempting to contact (DESCRIPTION = (ADDRESS = (PROTOCOL=TCP) (HOST=192.168.10.140) (PORT = 1521)) (CONNECT_DATA = (SID = SQLDSN)) (HS = OK)) OK (0 msec) isql result: [root@oracle ~]# isql SQLDSN cf11 cf11 +---------------------------------------+ | Connected! | | | | sql-statement | | help [tablename] | | quit | | | +---------------------------------------+ SQL> select count(*) from ItemTbl; +------------+ | | +------------+ | 136 | +------------+ SQLRowCount returns 1 1 rows fetched database link: CREATE PUBLIC DATABASE LINK "MSSQL" CONNECT TO "cf11" IDENTIFIED BY VALUES ':1' USING 'SQLDSN';

I am unable to connect to a MSSQL 2012 Server using FreeTDS on OSX in the terminal when I pass the -P . Example: V-MBP:etc vashavoc$ tsql -S SERVER_IP -p PORT -U USER -P PASSWORD locale is "en_US.UTF-8" locale charset is "UTF-8" using default charset "UTF-8" Msg 18456 (severity 14, state 1) from SERVER_IP Line 1: "Login failed for user 'USER'." Error 20002 (severity 9): Adaptive Server connection failed There was a problem connecting to the server If I leave out the -P and force it to prompt for input, I can type/paste it in and I can connect. (No there is no typo when I try using -P.) V-MBP:etc vashavoc$ tsql -S SERVER_IP -p PORT -U USER Password: locale is "en_US.UTF-8" locale charset is "UTF-8" using default charset "UTF-8" 1> Seems very odd it works when I omit the password from the connect string. FreeTDS seems installed OK. V-MBP:sh vashavoc$ tsql -C Compile-time settings (established with the "configure" script) Version: freetds v0.95.80 freetds.conf directory: /usr/local/Cellar/freetds/0.95.80/etc MS db-lib source compatibility: no Sybase binary compatibility: no Thread safety: yes iconv library: yes TDS version: 7.1 iODBC: no unixodbc: no SSPI "trusted" logins: no Kerberos: no OpenSSL: yes GnuTLS: no Tried TDSVER=X.X variants before the tsql string without any change. tsql -LH SERVER_IP Also tried to see if it would list back its instances using the -LH, doesn't respond and times out I presume. Am I missing anything that could get this to work? It is a server setting that is preventing it?

I have SQL Server 2008 R2 SP1. I am using connection string to connect to SQL Server. In connection string I am passing the driver path, server name, TCP port number, user name with which I want to connect, password, DSN name, TDS driver version number, db name. - I am using Free TDS driver for connecting from Mac OS machine. - On SQL server side I am having Windows authentication mode. - When I tried to connect by entering the user name and password of the user who has installed the SQL server or admin of the SQL server, it works fine. But if I try with normal domain user, I am getting the SQL Server connection failed error. After searching about it I found that some authentication is failing. Can anyone help me in resolving this issue? I believe that some settings need to be changed or there should be some modification on connection string.

At work, one of our primary databases is running on MS SQL Server. I think it's 2008. I'm currently hitting it via UnixODBC and FreeTDS from a Linux host. Unfortunately, the UnixODBC/FreeTDS are not supported by our admins, so it falls on me. For a long-term strategy I want to move off ODBC and switch to HTTP, using either SOAP or REST calls. The installation is a lot easier with HTTP and most languages understand it, at least Perl, Python and Ruby, which I develop in. We've got a decent amount of SOAP calls set up on the database for some Java processes, so we can probably switch to that pretty easily. We were discussing REST also, which I like because it's lighter-weight. Our DBAs don't have any REST interfaces set up, so I was wondering if there is a plugin or tool for SQL Server that can do simple REST mappings of the tables to get us jump-started. I've considered writing something in Ruby's Sinatra but that'd be one more thing on my plate. I searched for "SQL Server + rest" but it's pretty obvious that the Googles will do the wrong thing with the word "REST" and, as a consequence, didn't find anything worth while. So, if you have experience with something providing REST and felt it was a good tool then chime in.

I've been struggling to get the MySQL Workbench to behave properly to complete the following: With Mavericks (OS X 10.9), connect to a SQL Server and create a migration job to a MySQL server. The main issue seems to be with ODBC drivers. iODBC was deprecated with 10.8, and the header files removed complete in 10.9 (Some discussion on this here . More in-depth discussion here ). Despite my best efforts, this is the farthest I have gotten in Workbench, when trying to Test the connection to a SQL Server on a local subnet: > The ODBC driver that was selected for the source connection was not found by the ODBC manager. > Ensure that you have the proper ODBC driver installed and retry. > > Error Text: Error("('00000', ' [iODBC][Driver Manager]dlopen({FreeTDS}, 6): image not found (0) (SQLDriverConnect)')"): error calling Python module function DbMssqlRE.connect Here is what I have done up to this point: * installed FreeTDS .92.XX from their site (homebrew install of FreeTDS wasn't acceptable, as it uses .91. Apparently .92 or greater is required, according to the Docs I have been following on MySQL, located here * Installed the latest iODBC files I could find on iodbc.org (seemingly forgotten since 10.6) * Using homebrew, installed unixODBC, just in case that provided some alternative, which did not seem to be of any use either, * installed ODBC Administrator App, v 1.1.0 from Apple Has anyone successfully connected to a SQL Server database as a source, using the Workbench on Mac OS 10.9? About to give up and opt for the Windows app, because this iODBC stuff is becoming pretty frustrating 5+ hours in :( **Edits** It seems that PuTTY is showing simple telnet and ssh commands over ports 3606 and 22 are not accepted either. The firewall is completely open on Windows, from what I can tell. Private, Public, and Corporate settings allow for all inbound and outbound traffic. root and users with a wildcard host are not working either :-/

After installing FreeTDS I was able to connect to our SQL Server using tsql but not yet through bsqldb. With bsqldb it's trying to connect to the master even though the db was specified to testDB. serverName is setup in /etc/freetds.conf [serverName] host = database.windows.net port = 1433 tds version = 8.0 Using tsql: [gpadmin@mdw ~]$ /usr/bin/tsql -S serverName -U user -D testDB -P password works fine With bsqldb it's trying to connect to the master even though the db was specified to testDB. [gpadmin@mdw ~]$ /usr/bin/bsqldb -U user -P password -S serverName \ -D testDB -i tag.sql -o tag.csv Msg 4060, Level 11, State 1 Server 'fj5j2jtt5k', Line 1 Cannot open database "master" requested by the login. The login failed. bsqldb: error: severity 11 > 10, exiting

I am using freetds to connect to SQL Server from ubuntu. First, the SQL Server is running at port 1433 currently. I can telnet it. The following command also works. I can query table data using it, sqsh -H 192.168.10.249 -p 1433 -H xx -P xxxxxx however, this command does not work, and consequently making my ror app crash. sqsh -S developer -U xxx -P xxxxxxxxx this is error inside freetds.log 1:24:59.068648 5010 (log.c:190):Starting log file for FreeTDS 0.82 on 2012-06-04 11:24:59 with debug flags 0xffff. 11:24:59.069259 5010 (iconv.c:197):names for ISO-8859-1: ISO-8859-1 11:24:59.069298 5010 (iconv.c:197):names for UTF-8: UTF-8 11:24:59.069317 5010 (iconv.c:197):names for UCS-2LE: UCS-2LE 11:24:59.069335 5010 (iconv.c:197):names for UCS-2BE: UCS-2BE 11:24:59.069352 5010 (iconv.c:363):iconv to convert client-side data to the "UTF-8" character set 11:24:59.069394 5010 (iconv.c:516):tds_iconv_info_init: converting "UTF-8"->"UCS-2LE" 11:24:59.069461 5010 (iconv.c:516):tds_iconv_info_init: converting "ISO-8859-1"->"UCS-2LE" 11:24:59.069492 5010 (net.c:836):tds7_get_instance_port(192.168.10.249, MSSQLSERVER) 11:25:00.070784 5010 (net.c:905):tds7_get_instance_port: timed out on try 0 of 16 11:25:01.072121 5010 (net.c:905):tds7_get_instance_port: timed out on try 1 of 16 11:25:02.073441 5010 (net.c:905):tds7_get_instance_port: timed out on try 2 of 16 11:25:03.074756 5010 (net.c:905):tds7_get_instance_port: timed out on try 3 of 16 ... 11:25:15.095377 5010 (net.c:905):tds7_get_instance_port: timed out on try 15 of 16 11:25:15.095480 5010 (net.c:974):instance port is 0 11:25:15.095506 5010 (login.c:418):invalid port number 11:25:15.095532 5010 (mem.c:563):tds_free_all_results() 11:25:15.095580 5010 (ct.c:630):leaving ct_connect() returning 0 11:25:15.095605 5010 (ct.c:334):ct_con_props() action = CS_GET property = 9143 11:25:15.095630 5010 (ct.c:1865):ct_con_drop() 11:25:15.095652 5010 (ct.c:242):ct_exit() this is my freetds.conf file [global] ; tds version = 4.2 # Whether to write a TDSDUMP file for diagnostic purposes # (setting this to /tmp is insecure on a multi-user system) ; dump file = /tmp/freetds.log ; debug flags = 0xffff # Command and connection timeouts ; timeout = 10 ; connect timeout = 10 text size = 64512 [egServer50] host = symachine.domain.com port = 5000 tds version = 5.0 [developer] host = 192.168.10.249 port = 1433 #instance = MSSQLSERVER tds version = 8.0 client charset = UTF-8 dump file = /home/daisy/freetds.log dump file append = yes debug flags = 0xffff From the log output, I can see the program does not read the SQL Server port correctly in this case, it reads 0 which is wrong. It also outputs some information relating to encoding. so I guess it may relate to the translation issue.

Here is the query I ran select CAST(PageGuid as varchar(max)) + ',' + CAST(TenantGuid as varchar(max)) + '/' + CAST(OriginalFileGuid as varchar(max)) from Pages This worked with tsql but when run with bsqldb I get empty lines instead of results. I confirmed that bsqldb works by running other simple queries. So why is this one not working? Here is the verbose output bsqldb:163: Verbose operation enabled bsqldb:212: Query: select CAST(PageGuid as varchar(max)) + ',' + CAST(TenantGuid as varchar(max)) + '/' + CAST(OriginalFileGuid as varchar(max)) from Pages bsqldb:186: dbsqlsend(): OK bsqldb:194: dbsqlok(): OK bsqldb:289: calling dbresults: OK Result set 1 Freeing prior allocations Allocating buffers Allocating compute buffers Metadata col name source type size varies ------ ------------------------------ ------------------------------ --------------- ------ ------ 1 text 64512 1 Data Retrieving return status... none 11084 rows affected Retrieving output parameters... none bsqldb:615: dbresults() returned NO_MORE_RESULTS (2): bsqldb:212: Query: I'm using FreeTDS 0.64RC1, FreeBSD 8, and SQL Server 2008

I have a third-party Sybase database, which my users would like to connect to and query from a Linux box, using [iSQL](http://isql.sourceforge.net/) . I have installed [UnixODBC](http://www.unixodbc.org/) and [FreeTDS](http://www.freetds.org/) . As it is third-party database however, I am not able to perform any GRANTs. The query fails with iSQL on Linux: [unixODBC][FreeTDS][SQL Server]ASA Error -121: Permission denied: you do not have permission to use the "CREATE PROCEDURE" statement It appears that the actual SQL that is getting sent by iSQL is CREATE PROCEDURE AS . I have read the iSQL and FreeTDS manpages but there is no hint in there about how to disable this behavior. This works OK in Python: >>> import Sybase >>> db = Sybase.connect('host:port', 'user', 'password', 'db') >>> c = db.cursor() >>> c.execute('select table_name from systable') >>> len(c.fetchall()) 570 So I believe I have installed the Sybase client libraries correctly. Before I recommend this solution instead, can I as a DBA do anything about fixing iSQL?