From peter.van.dijk at powerdns.com Fri Apr 5 12:30:05 2019 From: peter.van.dijk at powerdns.com (Peter van Dijk) Date: Fri, 05 Apr 2019 18:30:05 +0200 Subject: [freetds] Support for SQL Server 2019 In-Reply-To: <7b65aa9a-1bc1-3c31-327a-f3a707a70e3b@4js.com> References: <7b65aa9a-1bc1-3c31-327a-f3a707a70e3b@4js.com> Message-ID: <938C3FFD-397D-45BD-8E79-549050659A52@powerdns.com> Hello Sebastien, On 19 Feb 2019, at 18:51, Sebastien FLAESCH wrote: > Is anyone testing FreeTDS with SQL Server 2019 CTP ? I use official the 2019-CTP2.2-ubuntu Docker image for PowerDNS ODBC CI testing, see https://github.com/PowerDNS/pdns/blob/fbd89850013536ecad8da2368d136f092d355388/.circleci/config.yml#L28 - it?s working fine. My odbc.ini looks like this: https://github.com/PowerDNS/pdns/blob/fbd89850013536ecad8da2368d136f092d355388/build-scripts/circleci.sh#L54-L67 I?m using FreeTDS 0.91-6.1 as shipped by Debian 9. Example logs at https://circleci.com/gh/PowerDNS/pdns/139 Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ From no-reply at appveyor.com Wed Apr 17 09:52:34 2019 From: no-reply at appveyor.com (AppVeyor) Date: Wed, 17 Apr 2019 13:52:34 +0000 Subject: [freetds] Build failed: freetds 1409 Message-ID: <20190417135234.1.16D9870A5755C2F1@appveyor.com> From no-reply at appveyor.com Mon Apr 29 03:52:55 2019 From: no-reply at appveyor.com (AppVeyor) Date: Mon, 29 Apr 2019 07:52:55 +0000 Subject: [freetds] Build failed: freetds 1414 Message-ID: <20190429075255.1.8E391772057E180D@appveyor.com> From no-reply at appveyor.com Mon Apr 29 07:08:11 2019 From: no-reply at appveyor.com (AppVeyor) Date: Mon, 29 Apr 2019 11:08:11 +0000 Subject: [freetds] Build failed: freetds 1416 Message-ID: <20190429110811.1.357923F4A000E73D@appveyor.com> From no-reply at appveyor.com Wed May 8 12:11:30 2019 From: no-reply at appveyor.com (AppVeyor) Date: Wed, 08 May 2019 16:11:30 +0000 Subject: [freetds] Build failed: freetds 1427 Message-ID: <20190508161130.1.EDEEF35F29E67480@appveyor.com> From no-reply at appveyor.com Wed May 8 13:39:22 2019 From: no-reply at appveyor.com (AppVeyor) Date: Wed, 08 May 2019 17:39:22 +0000 Subject: [freetds] Build completed: freetds 1428 Message-ID: <20190508173922.1.6DAD010689524014@appveyor.com> From no-reply at appveyor.com Fri May 10 09:27:11 2019 From: no-reply at appveyor.com (AppVeyor) Date: Fri, 10 May 2019 13:27:11 +0000 Subject: [freetds] Build failed: freetds 1432 Message-ID: <20190510132711.1.C4138568EF119407@appveyor.com> From randy at thesyrings.us Wed Jun 5 15:50:56 2019 From: randy at thesyrings.us (Randy Syring) Date: Wed, 5 Jun 2019 15:50:56 -0400 Subject: [freetds] (no subject) Message-ID: *Randy Syring* Husband | Father | Redeemed Sinner /"For what does it profit a man to gain the whole world and forfeit his soul?" (Mark 8:36 ESV)/ From axel.vestin at learningwell.se Tue May 28 03:12:46 2019 From: axel.vestin at learningwell.se (Axel Vestin) Date: Tue, 28 May 2019 07:12:46 -0000 Subject: [freetds] Issues authenticating with freebcp Message-ID: Hello! Thanks for letting me join! :) I've tried to configure my e-mail client to use plaintext, hopefully there are no issues. I've run into some problems trying to use freebcp to dump a table from an SQL Server 2012, and after reading the documentation on freetds.org, I'm out of ideas. Using tsql(with the same username, password, etc) everything works fine from the same machine. This is an NT domain style login, i.e the user is "domain\username". From what I can gather, there's a maximum length of 30 characters for the authentication fields? I'm using Debian 8.11, and freetds from Debian's repository, version 0.91-6+b1. $ uname -a Linux rayleigh 3.18.16-rt13 #5 SMP PREEMPT RT Mon Feb 13 14:58:54 CET 2017 i686 GNU/Linux This is the output from freebcp: avext at rayleigh:~/programming/freetds_test$ freebcp pqinfo.blandzon_aspec out test.txt -c -S $(cat server.txt) -U $(cat user.txt) -P $(cat password.txt) Msg 20042, Level 2 Name too long for LOGINREC field Msg 18452, Level 14, State 1 Server 'SRV00852\SRV00852', Line 1 Login failed. The login is from an untrusted domain and cannot be used with Windows authentication. Msg 18452, Level 14 General SQL Server error: Check messages from the SQL Server Msg 20002, Level 9 Adaptive Server connection failed Can't connect to server "SRV00852". I'm thankful for any help! /Axel Vestin From freddy77 at gmail.com Tue Jun 18 04:39:45 2019 From: freddy77 at gmail.com (Frediano Ziglio) Date: Tue, 18 Jun 2019 09:39:45 +0100 Subject: [freetds] Issues authenticating with freebcp In-Reply-To: References: Message-ID: Il giorno mar 18 giu 2019 alle ore 09:27 Axel Vestin < axel.vestin at learningwell.se> ha scritto: > Hello! Thanks for letting me join! :) > > I've tried to configure my e-mail client to use plaintext, hopefully there > are no issues. > > I've run into some problems trying to use freebcp to dump a table from an > SQL Server 2012, and after reading the documentation on freetds.org, I'm > out of ideas. > > Using tsql(with the same username, password, etc) everything works fine > from the same machine. This is an NT domain style login, i.e the user is > "domain\username". From what I can gather, there's a maximum length of 30 > characters for the authentication fields? > > The limit apply only to old protocol which you should avoid. Also domain login are encoded in a different way. > I'm using Debian 8.11, and freetds from Debian's repository, version > 0.91-6+b1. > > Pretty old I would say. $ uname -a > Linux rayleigh 3.18.16-rt13 #5 SMP PREEMPT RT Mon Feb 13 14:58:54 CET 2017 > i686 GNU/Linux > > This is the output from freebcp: > > avext at rayleigh:~/programming/freetds_test$ freebcp pqinfo.blandzon_aspec > out test.txt -c -S $(cat server.txt) -U $(cat user.txt) -P $(cat > password.txt) > Msg 20042, Level 2 > Name too long for LOGINREC field > > Msg 18452, Level 14, State 1 > Server 'SRV00852\SRV00852', Line 1 > Login failed. The login is from an untrusted domain and cannot be > used with Windows authentication. > Msg 18452, Level 14 > General SQL Server error: Check messages from the SQL Server > > The username should contain a backslash ("\"), also pay attention and escape according to the shell to avoid to have it stripped. Try to use logging (TDSDUMP) to see if program is using right protocol and receiving the correct account. The "untrusted domain" message is not much helpful, the server tends to just give error with not exact explanation, potentially to avoid helping hackers. Msg 20002, Level 9 > Adaptive Server connection failed > > Can't connect to server "SRV00852". > > > I'm thankful for any help! > > /Axel Vestin > > Frediano