From Deepa.Umesh at aptean.com Wed Jan 2 01:14:31 2019 From: Deepa.Umesh at aptean.com (Deepa Umesh) Date: Wed, 2 Jan 2019 06:14:31 +0000 Subject: [freetds] UTF-8 issue Message-ID: Hi Guys, While using FreeTDS I found there is an inconsistency in UTF-8 issue. Request anyone in the mailchain to provide information on how UTF-8 encoding is supported. The following is the configuration we made in odbc.ini [sqlprog1] Driver=/usr/local/freetds-1.00.97/lib/libtdsodbc.so Server=172.16.127.134 Database=sqlprog1_catdev19 Port=1433 TDS_Version=7.3 Client Charset = UTF-8. My question is can we set Client Charset = UCS-2 ? This message contains information that is confidential and/or may be privileged. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution or copy of this message and/or its attachments is strictly prohibited. If you have received this message in error, please advise the sender immediately by replying to this email and delete this message. We are committed to your privacy. For more information, please see our Privacy Policy at http://www.aptean.com/privacy-statement From freddy77 at gmail.com Fri Jan 4 04:16:01 2019 From: freddy77 at gmail.com (Frediano Ziglio) Date: Fri, 4 Jan 2019 09:16:01 +0000 Subject: [freetds] UTF-8 issue In-Reply-To: References: Message-ID: Il giorno mer 2 gen 2019 alle ore 06:14 Deepa Umesh ha scritto: > > Hi Guys, > > While using FreeTDS I found there is an inconsistency in UTF-8 issue. > > Request anyone in the mailchain to provide information on how UTF-8 encoding is supported. > > The following is the configuration we made in odbc.ini > > [sqlprog1] > Driver=/usr/local/freetds-1.00.97/lib/libtdsodbc.so > Server=172.16.127.134 > Database=sqlprog1_catdev19 > Port=1433 > TDS_Version=7.3 > Client Charset = UTF-8. > > My question is can we set Client Charset = UCS-2 ? No, that encoding is for multibyte, to use wide character use wide version of the functions. Frediano From Deepa.Umesh at aptean.com Tue Jan 8 01:41:11 2019 From: Deepa.Umesh at aptean.com (Deepa Umesh) Date: Tue, 8 Jan 2019 06:41:11 +0000 Subject: [freetds] UTF-8 issue In-Reply-To: References: Message-ID: Hi , I am trying to rephrase my question with more clarity, We are using UTF-8 as encoding in our product, which uses single byte of character data, But when we attempt to use non US ASCII UTF-8 charecters , we are having encoding problems similar to the following, Insert query : insert into altitem values ('????????????????'); When I retrieved the data using , SQlExecDirect('Select * from altitem) , I got an error similar to , SQLCODE: 0. SQL state: 42000. Native error: 2403. [FreeTDS][SQL Server]Some character(s) could not be converted into client's character set. Unconverted bytes were changed to question marks ('?') How to deal with UTF-8 non US ASCII values in ODBC APIs , and how FreeTDS supports the encoding ?' Thanks in advance, Deepa -----Original Message----- From: FreeTDS On Behalf Of Frediano Ziglio Sent: Friday, January 4, 2019 2:46 PM To: FreeTDS Development Group Subject: Re: [freetds] UTF-8 issue Il giorno mer 2 gen 2019 alle ore 06:14 Deepa Umesh ha scritto: > > Hi Guys, > > While using FreeTDS I found there is an inconsistency in UTF-8 issue. > > Request anyone in the mailchain to provide information on how UTF-8 encoding is supported. > > The following is the configuration we made in odbc.ini > > [sqlprog1] > Driver=/usr/local/freetds-1.00.97/lib/libtdsodbc.so > Server=172.16.127.134 > Database=sqlprog1_catdev19 > Port=1433 > TDS_Version=7.3 > Client Charset = UTF-8. > > My question is can we set Client Charset = UCS-2 ? No, that encoding is for multibyte, to use wide character use wide version of the functions. Frediano _______________________________________________ FreeTDS mailing list FreeTDS at lists.ibiblio.org https://lists.ibiblio.org/mailman/listinfo/freetds This message contains information that is confidential and/or may be privileged. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution or copy of this message and/or its attachments is strictly prohibited. If you have received this message in error, please advise the sender immediately by replying to this email and delete this message. We are committed to your privacy. For more information, please see our Privacy Policy at http://www.aptean.com/privacy-statement From peterd at iea-software.com Tue Jan 8 03:19:50 2019 From: peterd at iea-software.com (Peter Deacon) Date: Tue, 8 Jan 2019 00:19:50 -0800 (Pacific Standard Time) Subject: [freetds] UTF-8 issue In-Reply-To: References: Message-ID: On Tue, 8 Jan 2019, Deepa Umesh wrote: > Hi , > I am trying to rephrase my question with more clarity, > We are using UTF-8 as encoding in our product, which uses single byte of > character data, But when we attempt to use non US ASCII UTF-8 charecters > , we are having encoding problems similar to the following, > Insert query : insert into altitem values ('????????????????'); > [FreeTDS][SQL Server]Some character(s) could not be converted into > client's character set. Unconverted bytes were changed to question > marks ('?') >> [sqlprog1] >> Driver=/usr/local/freetds-1.00.97/lib/libtdsodbc.so >> Server=172.16.127.134 >> Database=sqlprog1_catdev19 >> Port=1433 >> TDS_Version=7.3 >> Client Charset = UTF-8. Hi Deepa, Set ClientCharset=CP1252 regards, Peter From Deepa.Umesh at aptean.com Tue Jan 8 05:40:20 2019 From: Deepa.Umesh at aptean.com (Deepa Umesh) Date: Tue, 8 Jan 2019 10:40:20 +0000 Subject: [freetds] UTF-8 issue In-Reply-To: References: Message-ID: Hi Peter, I set ClientCharset=CP1252 in odbc.ini (unixODBC) But the result is as previous : [FreeTDS][SQL Server]Some character(s) could not be converted into client's character set. Unconverted bytes were changed to question marks ('?') So do I need to reinstall freetds with this configuration in freetds.conf ? Request you to provide additional info on installation stuff. Also is there any config flags to be set? Thanks, Deepa -----Original Message----- From: FreeTDS On Behalf Of Peter Deacon Sent: Tuesday, January 8, 2019 1:50 PM To: FreeTDS Development Group Subject: Re: [freetds] UTF-8 issue On Tue, 8 Jan 2019, Deepa Umesh wrote: > Hi , > I am trying to rephrase my question with more clarity, > We are using UTF-8 as encoding in our product, which uses single byte > of character data, But when we attempt to use non US ASCII UTF-8 > charecters , we are having encoding problems similar to the following, > Insert query : insert into altitem values ('????????????????'); > [FreeTDS][SQL Server]Some character(s) could not be converted into > client's character set. Unconverted bytes were changed to question > marks ('?') >> [sqlprog1] >> Driver=/usr/local/freetds-1.00.97/lib/libtdsodbc.so >> Server=172.16.127.134 >> Database=sqlprog1_catdev19 >> Port=1433 >> TDS_Version=7.3 >> Client Charset = UTF-8. Hi Deepa, Set ClientCharset=CP1252 regards, Peter _______________________________________________ FreeTDS mailing list FreeTDS at lists.ibiblio.org https://lists.ibiblio.org/mailman/listinfo/freetds This message contains information that is confidential and/or may be privileged. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution or copy of this message and/or its attachments is strictly prohibited. If you have received this message in error, please advise the sender immediately by replying to this email and delete this message. We are committed to your privacy. For more information, please see our Privacy Policy at http://www.aptean.com/privacy-statement From ikorot01 at gmail.com Mon Jan 7 20:53:34 2019 From: ikorot01 at gmail.com (Igor Korot) Date: Mon, 7 Jan 2019 19:53:34 -0600 Subject: [freetds] UTF-8 issue In-Reply-To: References: Message-ID: Hi, On Tue, Jan 8, 2019 at 1:06 AM Deepa Umesh wrote: > > Hi , > > I am trying to rephrase my question with more clarity, > > We are using UTF-8 as encoding in our product, which uses single byte of character data, > But when we attempt to use non US ASCII UTF-8 charecters , we are having encoding problems similar to the following, > > Insert query : insert into altitem values ('????????????????'); > > When I retrieved the data using , > SQlExecDirect('Select * from altitem) > , I got an error similar to , As Frediano suggested, try SQLExecDirectW(). Thank you. > > SQLCODE: 0. SQL state: 42000. Native error: 2403. > [FreeTDS][SQL Server]Some character(s) could not be converted into client's character set. Unconverted bytes were changed to question marks ('?') > > How to deal with UTF-8 non US ASCII values in ODBC APIs , and how FreeTDS supports the encoding ?' > > Thanks in advance, > Deepa > > -----Original Message----- > From: FreeTDS On Behalf Of Frediano Ziglio > Sent: Friday, January 4, 2019 2:46 PM > To: FreeTDS Development Group > Subject: Re: [freetds] UTF-8 issue > > Il giorno mer 2 gen 2019 alle ore 06:14 Deepa Umesh ha scritto: > > > > Hi Guys, > > > > While using FreeTDS I found there is an inconsistency in UTF-8 issue. > > > > Request anyone in the mailchain to provide information on how UTF-8 encoding is supported. > > > > The following is the configuration we made in odbc.ini > > > > [sqlprog1] > > Driver=/usr/local/freetds-1.00.97/lib/libtdsodbc.so > > Server=172.16.127.134 > > Database=sqlprog1_catdev19 > > Port=1433 > > TDS_Version=7.3 > > Client Charset = UTF-8. > > > > My question is can we set Client Charset = UCS-2 ? > > No, that encoding is for multibyte, to use wide character use wide version of the functions. > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds > This message contains information that is confidential and/or may be privileged. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution or copy of this message and/or its attachments is strictly prohibited. If you have received this message in error, please advise the sender immediately by replying to this email and delete this message. We are committed to your privacy. For more information, please see our Privacy Policy at http://www.aptean.com/privacy-statement > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds From peterd at iea-software.com Tue Jan 8 12:27:53 2019 From: peterd at iea-software.com (Peter Deacon) Date: Tue, 8 Jan 2019 09:27:53 -0800 (Pacific Standard Time) Subject: [freetds] UTF-8 issue In-Reply-To: References: Message-ID: On Tue, 8 Jan 2019, Deepa Umesh wrote: > Hi Peter, > I set ClientCharset=CP1252 in odbc.ini (unixODBC) > But the result is as previous : > [FreeTDS][SQL Server]Some character(s) could not be converted into > client's character set. Unconverted bytes were changed to question > marks ('?') Hi Deepa, Normally this encoding causes everything to be mapped across so above would not occur. Recommend checking FreeTDS logs to confirm this is actually encoding used by FreeTDS. Also make sure FreeTDS uses libiconv when compiling. regards, Peter > So do I need to reinstall freetds with this configuration in freetds.conf ? > Request you to provide additional info on installation stuff. > Also is there any config flags to be set? > > Thanks, > Deepa > > -----Original Message----- > From: FreeTDS On Behalf Of Peter Deacon > Sent: Tuesday, January 8, 2019 1:50 PM > To: FreeTDS Development Group > Subject: Re: [freetds] UTF-8 issue > > On Tue, 8 Jan 2019, Deepa Umesh wrote: > >> Hi , >> I am trying to rephrase my question with more clarity, > >> We are using UTF-8 as encoding in our product, which uses single byte >> of character data, But when we attempt to use non US ASCII UTF-8 >> charecters , we are having encoding problems similar to the following, > >> Insert query : insert into altitem values ('????????????????'); > >> [FreeTDS][SQL Server]Some character(s) could not be converted into >> client's character set. Unconverted bytes were changed to question >> marks ('?') > >>> [sqlprog1] >>> Driver=/usr/local/freetds-1.00.97/lib/libtdsodbc.so >>> Server=172.16.127.134 >>> Database=sqlprog1_catdev19 >>> Port=1433 >>> TDS_Version=7.3 >>> Client Charset = UTF-8. > > Hi Deepa, > > Set ClientCharset=CP1252 > > regards, > Peter > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds > This message contains information that is confidential and/or may be privileged. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution or copy of this message and/or its attachments is strictly prohibited. If you have received this message in error, please advise the sender immediately by replying to this email and delete this message. We are committed to your privacy. For more information, please see our Privacy Policy at http://www.aptean.com/privacy-statement > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds > From Deepa.Umesh at aptean.com Wed Jan 9 01:52:05 2019 From: Deepa.Umesh at aptean.com (Deepa Umesh) Date: Wed, 9 Jan 2019 06:52:05 +0000 Subject: [freetds] UTF-8 issue In-Reply-To: References: Message-ID: Hi Peter, Let me summarize my installation and configuration settings : We are using FreeTDS(freetds-1.00.99) with UnixODBC(unixODBC-2.2.13) in Linux Platform and provided the following configuration in Odbc.ini in UnicODBC is as below: [sqlprog1] Driver=/usr/local/freetds-1.00.97/lib/libtdsodbc.so Server=172.16.127.134 Database=sqlprog1_catdev19 Port=1433 TDS_Version=7.3 Client Charset = CP1252 CP1252 is used in Windows Platform , is there anything similar to CP1252 in Linux? Thanks, Deepa -----Original Message----- From: FreeTDS On Behalf Of Peter Deacon Sent: Tuesday, January 8, 2019 10:58 PM To: FreeTDS Development Group Subject: Re: [freetds] UTF-8 issue On Tue, 8 Jan 2019, Deepa Umesh wrote: > Hi Peter, > I set ClientCharset=CP1252 in odbc.ini (unixODBC) But the result is as > previous : > [FreeTDS][SQL Server]Some character(s) could not be converted into > client's character set. Unconverted bytes were changed to question > marks ('?') Hi Deepa, Normally this encoding causes everything to be mapped across so above would not occur. Recommend checking FreeTDS logs to confirm this is actually encoding used by FreeTDS. Also make sure FreeTDS uses libiconv when compiling. regards, Peter > So do I need to reinstall freetds with this configuration in freetds.conf ? > Request you to provide additional info on installation stuff. > Also is there any config flags to be set? > > Thanks, > Deepa > > -----Original Message----- > From: FreeTDS On Behalf Of Peter > Deacon > Sent: Tuesday, January 8, 2019 1:50 PM > To: FreeTDS Development Group > Subject: Re: [freetds] UTF-8 issue > > On Tue, 8 Jan 2019, Deepa Umesh wrote: > >> Hi , >> I am trying to rephrase my question with more clarity, > >> We are using UTF-8 as encoding in our product, which uses single byte >> of character data, But when we attempt to use non US ASCII UTF-8 >> charecters , we are having encoding problems similar to the >> following, > >> Insert query : insert into altitem values ('????????????????'); > >> [FreeTDS][SQL Server]Some character(s) could not be converted into >> client's character set. Unconverted bytes were changed to question >> marks ('?') > >>> [sqlprog1] >>> Driver=/usr/local/freetds-1.00.97/lib/libtdsodbc.so >>> Server=172.16.127.134 >>> Database=sqlprog1_catdev19 >>> Port=1433 >>> TDS_Version=7.3 >>> Client Charset = UTF-8. > > Hi Deepa, > > Set ClientCharset=CP1252 > > regards, > Peter > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds > This message contains information that is confidential and/or may be > privileged. If you are not the intended recipient, you are hereby > notified that any use, dissemination, distribution or copy of this > message and/or its attachments is strictly prohibited. If you have > received this message in error, please advise the sender immediately > by replying to this email and delete this message. We are committed to > your privacy. For more information, please see our Privacy Policy at > http://www.aptean.com/privacy-statement > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds > _______________________________________________ FreeTDS mailing list FreeTDS at lists.ibiblio.org https://lists.ibiblio.org/mailman/listinfo/freetds This message contains information that is confidential and/or may be privileged. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution or copy of this message and/or its attachments is strictly prohibited. If you have received this message in error, please advise the sender immediately by replying to this email and delete this message. We are committed to your privacy. For more information, please see our Privacy Policy at http://www.aptean.com/privacy-statement From qinx at microsoft.com Mon Jan 7 14:16:19 2019 From: qinx at microsoft.com (Rick Qing Xu) Date: Mon, 7 Jan 2019 19:16:19 +0000 Subject: [freetds] How to have a better control on how the tds use the openssl? In-Reply-To: References: Message-ID: Yes. We want to detect which one supports bad protocols so we can ask people to stop using them. So we want to specify which protocol to use instead of having the system to choose for us. I am not actually using dblib, ctlib and odbc. I am using libtds directly. Do you think we can add some TLS protocol parameter somewhere? -----Original Message----- Hi Rick, SSL 3.0 ?? I think was declared insecure time ago, some people are disabling TLSv1.0 already. New OpenSSL provide a "MinProtocol" setting. Similar property would be good to have in libTDS too. About callback can be done. I would add a parameter to specify the SSL library kind (currently OpenSSL or GnuTLS). Which library are you using? dblib, ctlib or odbc? Frediano -----Original Message----- From: FreeTDS On Behalf Of Rick Qing Xu via FreeTDS Sent: Tuesday, December 18, 2018 10:35 AM To: Frediano Ziglio ; FreeTDS Development Group Cc: Rick Qing Xu Subject: Re: [freetds] How to have a better control on how the tds use the openssl? The actual issue is: 1. I'd like to set the TLS version to SSL 3.0 or TLS 1.2 before the handshake, instead of let the system choose for me. Disabling TLS 1 will end up with two possibilities, TLS 1.1 and TLS 1.2. In my case, it has to be very specific, my client only wants to negotiate on TLS 1.1 or even SSLv3. It would be better if we can have a TLS version parameter in TDSLOGIN structure. 2. The tds lib doesn't give me chance to call SSL_set_tlsext_host_name and SSL_set_tlsext_status_type before the TLS handshake happens. If it can provide a call back mechanism, e.g., call just before it start the handshake, it would be helpful. -----Original Message----- From: Frediano Ziglio Sent: Tuesday, December 18, 2018 10:19 AM To: FreeTDS Development Group Cc: Rick Qing Xu Subject: Re: [freetds] How to have a better control on how the tds use the openssl? Il giorno sab 15 dic 2018 alle ore 09:36 Rick Qing Xu via FreeTDS ha scritto: > > Hi FreeTDS team, > > I am new to the TDS community and hi to everyone. I am working on a project doing in-depth detection on encryption characteristics on SQL TDS protocol. For example, by only talking to the server thru network on TDS protocol, I want to detect which TLS versions the server supports, what cipher suites are supported and what the order of it. In that case, I need to have more fine control of which TLS version is going to be used. > > Usually I need to call SSL_CTX_set_verify before the handshake starts to trust all kinds of server certificate. In addition, I'd like to use SSL_set_tlsext_host_name to control whether to use Server Name Indication extension in the handshake. Another example is I want to call SSL_set_tlsext_status_type before the handshake to ask server to send back an OCSP status response to me. > > After reading the tls.c in tds project, the tds_init_openssl() function actually hardcoded the TLS method to be TLS_client_method, which is the general-purpose version-flexible SSL/TLS methods. The actual protocol version used will be negotiated to the highest version mutually supported by the client and the server. The supported protocols are TLSv1, TLSv1.1 and TLSv1.2. > > I can see that now I can control what cipher get used by setting the tds->login->openssl_ciphers to whatever I need to achieve the cipher suite ask. > > Can you give me advice on how to do it in existing code? If not in existing code, I am very happy to write some code to implement that in tds project. > > Thanks! > > Rick Qing Xu > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith > ub.com%2Fqinxgit&data=02%7C01%7Cqinx%40microsoft.com%7C1d5c081f274 > 643a3870708d665155aea%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636 > 807539737754130&sdata=EXWK4pfPIZMEa3tw8vQUiwPirpvAjxOGq8m0qG45gwg% > 3D&reserved=0 > Hi, I think you got everything right. You can set openssl_ciphers through the "openssl ciphers" settings. In master there's an option to disable TLSv1 (which for compatibility by default is enabled). It would be great to have same settings for GnuTLS/OpenSSL (the "openssl ciphers" is only available with OpenSSL). Frediano _______________________________________________ FreeTDS mailing list FreeTDS at lists.ibiblio.org https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.ibiblio.org%2Fmailman%2Flistinfo%2Ffreetds&data=02%7C01%7Cqinx%40microsoft.com%7C7238c81c58af448af4a008d66545b580%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636807747412319244&sdata=QRlNBxApz7wk3Y4y0oTBzJHa1mcFjhoDqqNLe%2F%2Fq2Xc%3D&reserved=0 From freddy77 at gmail.com Wed Jan 9 08:26:51 2019 From: freddy77 at gmail.com (Frediano Ziglio) Date: Wed, 9 Jan 2019 13:26:51 +0000 Subject: [freetds] UTF-8 issue In-Reply-To: References: Message-ID: Hi, CP1252 is available like many other encoding, but trying to use cp1252 and Japanese will just create garbage, FreeTDS is just warning you, if you want garbage in the database the configuration is fine but probably is not what you want. How is data stored into the database? Which collation is the database? Which type and collation are the columns supposed to contain Japanese? Which encoding are you using on the client. The "Client Charset" should respect this and will be use for "ANSI" function (the not wide ones, wide in UnixODBC means UTF-16 like Windows). Regards, Frediano Il giorno mer 9 gen 2019 alle ore 06:52 Deepa Umesh ha scritto: > > Hi Peter, > > Let me summarize my installation and configuration settings : > > We are using FreeTDS(freetds-1.00.99) with UnixODBC(unixODBC-2.2.13) in Linux Platform and provided the following configuration in > Odbc.ini in UnicODBC is as below: > > [sqlprog1] > Driver=/usr/local/freetds-1.00.97/lib/libtdsodbc.so > Server=172.16.127.134 > Database=sqlprog1_catdev19 > Port=1433 > TDS_Version=7.3 > Client Charset = CP1252 > > CP1252 is used in Windows Platform , is there anything similar to CP1252 in Linux? > > Thanks, > Deepa > > -----Original Message----- > From: FreeTDS On Behalf Of Peter Deacon > Sent: Tuesday, January 8, 2019 10:58 PM > To: FreeTDS Development Group > Subject: Re: [freetds] UTF-8 issue > > On Tue, 8 Jan 2019, Deepa Umesh wrote: > > > Hi Peter, > > I set ClientCharset=CP1252 in odbc.ini (unixODBC) But the result is as > > previous : > > > [FreeTDS][SQL Server]Some character(s) could not be converted into > > client's character set. Unconverted bytes were changed to question > > marks ('?') > > Hi Deepa, > > Normally this encoding causes everything to be mapped across so above would not occur. Recommend checking FreeTDS logs to confirm this is actually encoding used by FreeTDS. > > Also make sure FreeTDS uses libiconv when compiling. > > regards, > Peter > > > So do I need to reinstall freetds with this configuration in freetds.conf ? > > > > Request you to provide additional info on installation stuff. > > Also is there any config flags to be set? > > > > Thanks, > > Deepa > > > > -----Original Message----- > > From: FreeTDS On Behalf Of Peter > > Deacon > > Sent: Tuesday, January 8, 2019 1:50 PM > > To: FreeTDS Development Group > > Subject: Re: [freetds] UTF-8 issue > > > > On Tue, 8 Jan 2019, Deepa Umesh wrote: > > > >> Hi , > >> I am trying to rephrase my question with more clarity, > > > >> We are using UTF-8 as encoding in our product, which uses single byte > >> of character data, But when we attempt to use non US ASCII UTF-8 > >> charecters , we are having encoding problems similar to the > >> following, > > > >> Insert query : insert into altitem values ('????????????????'); > > > >> [FreeTDS][SQL Server]Some character(s) could not be converted into > >> client's character set. Unconverted bytes were changed to question > >> marks ('?') > > > >>> [sqlprog1] > >>> Driver=/usr/local/freetds-1.00.97/lib/libtdsodbc.so > >>> Server=172.16.127.134 > >>> Database=sqlprog1_catdev19 > >>> Port=1433 > >>> TDS_Version=7.3 > >>> Client Charset = UTF-8. > > > > Hi Deepa, > > > > Set ClientCharset=CP1252 > > > > regards, > > Peter > > _______________________________________________ > > FreeTDS mailing list > > FreeTDS at lists.ibiblio.org > > https://lists.ibiblio.org/mailman/listinfo/freetds > > This message contains information that is confidential and/or may be > > privileged. If you are not the intended recipient, you are hereby > > notified that any use, dissemination, distribution or copy of this > > message and/or its attachments is strictly prohibited. If you have > > received this message in error, please advise the sender immediately > > by replying to this email and delete this message. We are committed to > > your privacy. For more information, please see our Privacy Policy at > > http://www.aptean.com/privacy-statement > > _______________________________________________ > > FreeTDS mailing list > > FreeTDS at lists.ibiblio.org > > https://lists.ibiblio.org/mailman/listinfo/freetds > > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds > This message contains information that is confidential and/or may be privileged. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution or copy of this message and/or its attachments is strictly prohibited. If you have received this message in error, please advise the sender immediately by replying to this email and delete this message. We are committed to your privacy. For more information, please see our Privacy Policy at http://www.aptean.com/privacy-statement > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds From freddy77 at gmail.com Wed Jan 9 10:54:29 2019 From: freddy77 at gmail.com (Frediano Ziglio) Date: Wed, 9 Jan 2019 15:54:29 +0000 Subject: [freetds] How to have a better control on how the tds use the openssl? In-Reply-To: References: Message-ID: Hi, now I got the intention. It's a very specific case. libTDS is more focused on working clients, not security tools. I would add a callback for OpenSSL specifically for this purpose, maybe after tds_ssl_init all in src/tds/login.c. If you are using directly libTDS you can access to whatever field in TDSSOCKET structure, probably you'll need to change/tune conn->tls_session and conn->tls_ctx. Frediano Il giorno lun 7 gen 2019 alle ore 19:16 Rick Qing Xu ha scritto: > > Yes. We want to detect which one supports bad protocols so we can ask people to stop using them. So we want to specify which protocol to use instead of having the system to choose for us. > > I am not actually using dblib, ctlib and odbc. I am using libtds directly. > > Do you think we can add some TLS protocol parameter somewhere? > > -----Original Message----- > Hi Rick, > SSL 3.0 ?? I think was declared insecure time ago, some people are > disabling TLSv1.0 already. > New OpenSSL provide a "MinProtocol" setting. Similar property would be > good to have in libTDS too. > About callback can be done. I would add a parameter to specify the SSL > library kind (currently OpenSSL or GnuTLS). Which library are you > using? dblib, ctlib or odbc? > > Frediano > -----Original Message----- > From: FreeTDS On Behalf Of Rick Qing Xu via FreeTDS > Sent: Tuesday, December 18, 2018 10:35 AM > To: Frediano Ziglio ; FreeTDS Development Group > Cc: Rick Qing Xu > Subject: Re: [freetds] How to have a better control on how the tds use the openssl? > > The actual issue is: > > 1. I'd like to set the TLS version to SSL 3.0 or TLS 1.2 before the handshake, instead of let the system choose for me. Disabling TLS 1 will end up with two possibilities, TLS 1.1 and TLS 1.2. In my case, it has to be very specific, my client only wants to negotiate on TLS 1.1 or even SSLv3. It would be better if we can have a TLS version parameter in TDSLOGIN structure. > 2. The tds lib doesn't give me chance to call SSL_set_tlsext_host_name and SSL_set_tlsext_status_type before the TLS handshake happens. If it can provide a call back mechanism, e.g., call just before it start the handshake, it would be helpful. > > -----Original Message----- > From: Frediano Ziglio > Sent: Tuesday, December 18, 2018 10:19 AM > To: FreeTDS Development Group > Cc: Rick Qing Xu > Subject: Re: [freetds] How to have a better control on how the tds use the openssl? > > Il giorno sab 15 dic 2018 alle ore 09:36 Rick Qing Xu via FreeTDS ha scritto: > > > > Hi FreeTDS team, > > > > I am new to the TDS community and hi to everyone. I am working on a project doing in-depth detection on encryption characteristics on SQL TDS protocol. For example, by only talking to the server thru network on TDS protocol, I want to detect which TLS versions the server supports, what cipher suites are supported and what the order of it. In that case, I need to have more fine control of which TLS version is going to be used. > > > > Usually I need to call SSL_CTX_set_verify before the handshake starts to trust all kinds of server certificate. In addition, I'd like to use SSL_set_tlsext_host_name to control whether to use Server Name Indication extension in the handshake. Another example is I want to call SSL_set_tlsext_status_type before the handshake to ask server to send back an OCSP status response to me. > > > > After reading the tls.c in tds project, the tds_init_openssl() function actually hardcoded the TLS method to be TLS_client_method, which is the general-purpose version-flexible SSL/TLS methods. The actual protocol version used will be negotiated to the highest version mutually supported by the client and the server. The supported protocols are TLSv1, TLSv1.1 and TLSv1.2. > > > > I can see that now I can control what cipher get used by setting the tds->login->openssl_ciphers to whatever I need to achieve the cipher suite ask. > > > > Can you give me advice on how to do it in existing code? If not in existing code, I am very happy to write some code to implement that in tds project. > > > > Thanks! > > > > Rick Qing Xu > > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith > > ub.com%2Fqinxgit&data=02%7C01%7Cqinx%40microsoft.com%7C1d5c081f274 > > 643a3870708d665155aea%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636 > > 807539737754130&sdata=EXWK4pfPIZMEa3tw8vQUiwPirpvAjxOGq8m0qG45gwg% > > 3D&reserved=0 > > > > Hi, > I think you got everything right. You can set openssl_ciphers through the "openssl ciphers" settings. In master there's an option to disable TLSv1 (which for compatibility by default is enabled). > It would be great to have same settings for GnuTLS/OpenSSL (the "openssl ciphers" is only available with OpenSSL). > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.ibiblio.org%2Fmailman%2Flistinfo%2Ffreetds&data=02%7C01%7Cqinx%40microsoft.com%7C7238c81c58af448af4a008d66545b580%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636807747412319244&sdata=QRlNBxApz7wk3Y4y0oTBzJHa1mcFjhoDqqNLe%2F%2Fq2Xc%3D&reserved=0 From peterd at iea-software.com Wed Jan 9 12:00:05 2019 From: peterd at iea-software.com (Peter Deacon) Date: Wed, 9 Jan 2019 09:00:05 -0800 (Pacific Standard Time) Subject: [freetds] UTF-8 issue In-Reply-To: References: Message-ID: On Wed, 9 Jan 2019, Deepa Umesh wrote: >> Hi Peter, >> I set ClientCharset=CP1252 in odbc.ini (unixODBC) But the result is as >> previous : > Hi Peter, > Let me summarize my installation and configuration settings : > We are using FreeTDS(freetds-1.00.99) with UnixODBC(unixODBC-2.2.13) in Linux Platform and provided the following configuration in > Odbc.ini in UnicODBC is as below: > [sqlprog1] > Driver=/usr/local/freetds-1.00.97/lib/libtdsodbc.so > Server=172.16.127.134 > Database=sqlprog1_catdev19 > Port=1433 > TDS_Version=7.3 > Client Charset = CP1252 Hi Deepa, Just tried this here and found that: 'Client Charset' does not work 'ClientCharset' works Change 'Client Charset' to 'ClientCharset'. ClientCharset = CP1252 With no space between client and charset. > CP1252 is used in Windows Platform , is there anything similar to CP1252 in Linux? Platform does not matter. If it still is not working please get a debug log to confirm what is actually being used to make sure it isn't overridden by DSN string or something. FWIW I agree with sentiments about doing this. If you use database as a UTF-8 "dumping ground" there are a number of issues with collation, field length, truncation and external software that may not have capability to decipher data. It works but have to be careful. regards, Peter From qinx at microsoft.com Wed Jan 9 12:44:48 2019 From: qinx at microsoft.com (Rick Qing Xu) Date: Wed, 9 Jan 2019 17:44:48 +0000 Subject: [freetds] How to have a better control on how the tds use the openssl? In-Reply-To: References: , Message-ID: Sounds good! When do you think it can be added? I am available for helping too. Sent from Outlook ________________________________ From: Frediano Ziglio Sent: Wednesday, January 9, 2019 7:54:29 AM To: Rick Qing Xu Cc: FreeTDS Development Group Subject: Re: [freetds] How to have a better control on how the tds use the openssl? Hi, now I got the intention. It's a very specific case. libTDS is more focused on working clients, not security tools. I would add a callback for OpenSSL specifically for this purpose, maybe after tds_ssl_init all in src/tds/login.c. If you are using directly libTDS you can access to whatever field in TDSSOCKET structure, probably you'll need to change/tune conn->tls_session and conn->tls_ctx. Frediano Il giorno lun 7 gen 2019 alle ore 19:16 Rick Qing Xu ha scritto: > > Yes. We want to detect which one supports bad protocols so we can ask people to stop using them. So we want to specify which protocol to use instead of having the system to choose for us. > > I am not actually using dblib, ctlib and odbc. I am using libtds directly. > > Do you think we can add some TLS protocol parameter somewhere? > > -----Original Message----- > Hi Rick, > SSL 3.0 ?? I think was declared insecure time ago, some people are > disabling TLSv1.0 already. > New OpenSSL provide a "MinProtocol" setting. Similar property would be > good to have in libTDS too. > About callback can be done. I would add a parameter to specify the SSL > library kind (currently OpenSSL or GnuTLS). Which library are you > using? dblib, ctlib or odbc? > > Frediano > -----Original Message----- > From: FreeTDS On Behalf Of Rick Qing Xu via FreeTDS > Sent: Tuesday, December 18, 2018 10:35 AM > To: Frediano Ziglio ; FreeTDS Development Group > Cc: Rick Qing Xu > Subject: Re: [freetds] How to have a better control on how the tds use the openssl? > > The actual issue is: > > 1. I'd like to set the TLS version to SSL 3.0 or TLS 1.2 before the handshake, instead of let the system choose for me. Disabling TLS 1 will end up with two possibilities, TLS 1.1 and TLS 1.2. In my case, it has to be very specific, my client only wants to negotiate on TLS 1.1 or even SSLv3. It would be better if we can have a TLS version parameter in TDSLOGIN structure. > 2. The tds lib doesn't give me chance to call SSL_set_tlsext_host_name and SSL_set_tlsext_status_type before the TLS handshake happens. If it can provide a call back mechanism, e.g., call just before it start the handshake, it would be helpful. > > -----Original Message----- > From: Frediano Ziglio > Sent: Tuesday, December 18, 2018 10:19 AM > To: FreeTDS Development Group > Cc: Rick Qing Xu > Subject: Re: [freetds] How to have a better control on how the tds use the openssl? > > Il giorno sab 15 dic 2018 alle ore 09:36 Rick Qing Xu via FreeTDS ha scritto: > > > > Hi FreeTDS team, > > > > I am new to the TDS community and hi to everyone. I am working on a project doing in-depth detection on encryption characteristics on SQL TDS protocol. For example, by only talking to the server thru network on TDS protocol, I want to detect which TLS versions the server supports, what cipher suites are supported and what the order of it. In that case, I need to have more fine control of which TLS version is going to be used. > > > > Usually I need to call SSL_CTX_set_verify before the handshake starts to trust all kinds of server certificate. In addition, I'd like to use SSL_set_tlsext_host_name to control whether to use Server Name Indication extension in the handshake. Another example is I want to call SSL_set_tlsext_status_type before the handshake to ask server to send back an OCSP status response to me. > > > > After reading the tls.c in tds project, the tds_init_openssl() function actually hardcoded the TLS method to be TLS_client_method, which is the general-purpose version-flexible SSL/TLS methods. The actual protocol version used will be negotiated to the highest version mutually supported by the client and the server. The supported protocols are TLSv1, TLSv1.1 and TLSv1.2. > > > > I can see that now I can control what cipher get used by setting the tds->login->openssl_ciphers to whatever I need to achieve the cipher suite ask. > > > > Can you give me advice on how to do it in existing code? If not in existing code, I am very happy to write some code to implement that in tds project. > > > > Thanks! > > > > Rick Qing Xu > > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith > > ub.com%2Fqinxgit&data=02%7C01%7Cqinx%40microsoft.com%7C1d5c081f274 > > 643a3870708d665155aea%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636 > > 807539737754130&sdata=EXWK4pfPIZMEa3tw8vQUiwPirpvAjxOGq8m0qG45gwg% > > 3D&reserved=0 > > > > Hi, > I think you got everything right. You can set openssl_ciphers through the "openssl ciphers" settings. In master there's an option to disable TLSv1 (which for compatibility by default is enabled). > It would be great to have same settings for GnuTLS/OpenSSL (the "openssl ciphers" is only available with OpenSSL). > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.ibiblio.org%2Fmailman%2Flistinfo%2Ffreetds&data=02%7C01%7Cqinx%40microsoft.com%7Cd8ca7101d7414124439d08d6764ac525%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636826460844255366&sdata=Oy%2BUSTM6OmeHVWjLqSvXj%2BobdOdTJqsmvR5Rpd%2FTa0I%3D&reserved=0 From freddy77 at gmail.com Mon Feb 4 14:41:40 2019 From: freddy77 at gmail.com (Frediano Ziglio) Date: Mon, 4 Feb 2019 19:41:40 +0000 Subject: [freetds] FreeTDS 1.1 Release Candidate 1 Message-ID: Hi, time for a new release. Although stable branch is kept updated with bugs and minor features new big features, build improves and potential compatibility changes are not ported to stable branch. Release bring all these changes, here (available also in NEWS file) changes for next release: Summary of Changes in release 1.1 -------------------------------------------- User visible (not in a particular order): - Removed 4.2 and 7.0 as default TDS protocol versions during configure, the default if not specified is now "auto", to connect to such obsolete servers you need to specify explicitly the version ("auto" won't attempt these versions). CMake build default to version 7.1; - allows to disable TLS 1.0 support; - pool server allows to specify different username/password for server and clients allowing to hide internal server logins; - tsql utility now send final partial query to server to avoid to have to specify a final "GO" line to terminate commands; - better support for Microsoft cluster, client will attempt multiple connection to server at the same time if DNS reply multiple IPs; - MONEY/SMALLMONEY types are now formated with 4 decimal digits to avoid truncation; - MARS support is now compiled by default; - pool server is now compiled by default; - Fixed SQL_ATTR_LOGIN_TIMEOUT for ODBC; - Fixed large integer numbers for ODBC RPC constants; - Fixed encrypted logins if "auto" protocol version is used; - Support CS_TIMEOUT and CS_LOGIN_TIMEOUT properties under CTLibrary; - Added a dbacolname function in DBLibrary, similar to dbcolname but for compute columns (mainly for Sybase now, Microsoft removed support for compute columns); - NTLMv2 is now on by default. Implementation: - Improved UTF-8 performances; - Use more stdint.h style definitions (like uint32_t); - Use bool type instead of int; - pool server compile under Windows too (not as capable as Unix version); - CMake build is now able to do an installation; - Added a src/utils directory to collect all common code not strictly related to replacements or TDS; - Simplified makefiles; - Support CP1252 encoding in internal trivial iconv; - Better ODBC detection. Allows to specify a directory with --with-iodbc to specify custom iOBDC. Kind Regards, Frediano From ikorot01 at gmail.com Mon Feb 4 16:47:56 2019 From: ikorot01 at gmail.com (Igor Korot) Date: Mon, 4 Feb 2019 15:47:56 -0600 Subject: [freetds] FreeTDS 1.1 Release Candidate 1 In-Reply-To: References: Message-ID: Frediano, On Mon, Feb 4, 2019 at 1:42 PM Frediano Ziglio wrote: > > Hi, > time for a new release. > > Although stable branch is kept updated with bugs and minor features new big > features, build improves and potential compatibility changes are not ported > to stable branch. Release bring all these changes, here (available also in NEWS > file) changes for next release: > > > Summary of Changes in release 1.1 > -------------------------------------------- > User visible (not in a particular order): > - Removed 4.2 and 7.0 as default TDS protocol versions during > configure, the default if not specified is now "auto", to connect > to such obsolete servers you need to specify explicitly the version > ("auto" won't attempt these versions). CMake build default to > version 7.1; > - allows to disable TLS 1.0 support; > - pool server allows to specify different username/password for server > and clients allowing to hide internal server logins; > - tsql utility now send final partial query to server to avoid to have > to specify a final "GO" line to terminate commands; > - better support for Microsoft cluster, client will attempt multiple > connection to server at the same time if DNS reply multiple IPs; > - MONEY/SMALLMONEY types are now formated with 4 decimal digits to > avoid truncation; > - MARS support is now compiled by default; > - pool server is now compiled by default; > - Fixed SQL_ATTR_LOGIN_TIMEOUT for ODBC; > - Fixed large integer numbers for ODBC RPC constants; > - Fixed encrypted logins if "auto" protocol version is used; > - Support CS_TIMEOUT and CS_LOGIN_TIMEOUT properties under CTLibrary; > - Added a dbacolname function in DBLibrary, similar to dbcolname but > for compute columns (mainly for Sybase now, Microsoft removed > support for compute columns); > - NTLMv2 is now on by default. > > Implementation: > - Improved UTF-8 performances; > - Use more stdint.h style definitions (like uint32_t); > - Use bool type instead of int; > - pool server compile under Windows too (not as capable as Unix > version); > - CMake build is now able to do an installation; > - Added a src/utils directory to collect all common code not strictly > related to replacements or TDS; > - Simplified makefiles; > - Support CP1252 encoding in internal trivial iconv; > - Better ODBC detection. Allows to specify a directory with > --with-iodbc to specify custom iOBDC. Thank you for the new release prerparation. What is the lowest version freeTDS can connect to now (for both Sybase/SAP ASE and MS)? > > Kind Regards, > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds From fredy at opag.ch Mon Feb 4 22:30:29 2019 From: fredy at opag.ch (fredy at opag.ch) Date: Tue, 5 Feb 2019 04:30:29 +0100 (GMT+01:00) Subject: [freetds] FreeTDS 1.1 Release Candidate 1 In-Reply-To: CAHt6W4dm0t6JTfOqRc8FhzDHjcPBkCoSTVrgSMY2cN4K3bX6HQ@mail.gmail.com References: Message-ID: Isn't TDS 4.2 needed for Sybase/SAP ASE? Hopefully you don't drop support for it. -- Fredy Paquet OPAG Informatik AG Fabrikmattenweg 11 CH-4144 Arlesheim Tel. 0041 61 7169222 Fax. 0041 61 7169229 http://www.opag.ch Am 4. Februar 2019, 20:41, schrieb Frediano Ziglio: Hi, ?? time for a new release. Although stable branch is kept updated with bugs and minor features new big features, build improves and potential compatibility changes are not ported to stable branch. Release bring all these changes, here (available also in NEWS file) changes for next release: Summary of Changes in release 1.1 -------------------------------------------- User visible (not in a particular order): - Removed 4.2 and 7.0 as default TDS protocol versions during ? configure, the default if not specified is now "auto", to connect ? to such obsolete servers you need to specify explicitly the version ? ("auto" won't attempt these versions). CMake build default to ? version 7.1; - allows to disable TLS 1.0 support; - pool server allows to specify different username/password for server ? and clients allowing to hide internal server logins; - tsql utility now send final partial query to server to avoid to have ? to specify a final "GO" line to terminate commands; - better support for Microsoft cluster, client will attempt multiple ? connection to server at the same time if DNS reply multiple IPs; - MONEY/SMALLMONEY types are now formated with 4 decimal digits to ? avoid truncation; - MARS support is now compiled by default; - pool server is now compiled by default; - Fixed SQL_ATTR_LOGIN_TIMEOUT for ODBC; - Fixed large integer numbers for ODBC RPC constants; - Fixed encrypted logins if "auto" protocol version is used; - Support CS_TIMEOUT and CS_LOGIN_TIMEOUT properties under CTLibrary; - Added a dbacolname function in DBLibrary, similar to dbcolname but ? for compute columns (mainly for Sybase now, Microsoft removed ? support for compute columns); - NTLMv2 is now on by default. Implementation: - Improved UTF-8 performances; - Use more stdint.h style definitions (like uint32_t); - Use bool type instead of int; - pool server compile under Windows too (not as capable as Unix ? version); - CMake build is now able to do an installation; - Added a src/utils directory to collect all common code not strictly ? related to replacements or TDS; - Simplified makefiles; - Support CP1252 encoding in internal trivial iconv; - Better ODBC detection. Allows to specify a directory with ? --with-iodbc to specify custom iOBDC. Kind Regards, ? Frediano _______________________________________________ FreeTDS mailing list FreeTDS at lists.ibiblio.org https://lists.ibiblio.org/mailman/listinfo/freetds -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5087 bytes Desc: S/MIME Cryptographic Signature URL: From fredy at opag.ch Mon Feb 4 22:52:53 2019 From: fredy at opag.ch (Fredy Paquet) Date: Tue, 05 Feb 2019 04:52:53 +0100 Subject: [freetds] FreeTDS 1.1 Release Candidate 1 In-Reply-To: References: Message-ID: Correction: Sybase ASE is running TDS version 5.0 -- Fredy Paquet Mitglied der Gesch?ftsleitung OPAG Informatik AG Fabrikmattenweg 11 CH-4144 Arlesheim http://www.opag.ch Tel. ++41 61 716 92 22 Fax. ++41 61 716 92 29 On Tue, 2019-02-05 at 04:30 +0100, fredy at opag.ch wrote: > Isn't TDS 4.2 needed for Sybase/SAP ASE? > Hopefully you don't drop support for it. > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3482 bytes Desc: not available URL: From freddy77 at gmail.com Tue Feb 5 02:43:07 2019 From: freddy77 at gmail.com (Frediano Ziglio) Date: Tue, 5 Feb 2019 07:43:07 +0000 Subject: [freetds] FreeTDS 1.1 Release Candidate 1 In-Reply-To: References: Message-ID: > On Mon, Feb 4, 2019 at 1:42 PM Frediano Ziglio wrote: > > > > Hi, > > time for a new release. > > > > Although stable branch is kept updated with bugs and minor features new big > > features, build improves and potential compatibility changes are not ported > > to stable branch. Release bring all these changes, here (available also in NEWS > > file) changes for next release: > > > > > > Summary of Changes in release 1.1 > > -------------------------------------------- > > User visible (not in a particular order): > > - Removed 4.2 and 7.0 as default TDS protocol versions during > > configure, the default if not specified is now "auto", to connect > > to such obsolete servers you need to specify explicitly the version > > ("auto" won't attempt these versions). CMake build default to > > version 7.1; > > - allows to disable TLS 1.0 support; > > - pool server allows to specify different username/password for server > > and clients allowing to hide internal server logins; > > - tsql utility now send final partial query to server to avoid to have > > to specify a final "GO" line to terminate commands; > > - better support for Microsoft cluster, client will attempt multiple > > connection to server at the same time if DNS reply multiple IPs; > > - MONEY/SMALLMONEY types are now formated with 4 decimal digits to > > avoid truncation; > > - MARS support is now compiled by default; > > - pool server is now compiled by default; > > - Fixed SQL_ATTR_LOGIN_TIMEOUT for ODBC; > > - Fixed large integer numbers for ODBC RPC constants; > > - Fixed encrypted logins if "auto" protocol version is used; > > - Support CS_TIMEOUT and CS_LOGIN_TIMEOUT properties under CTLibrary; > > - Added a dbacolname function in DBLibrary, similar to dbcolname but > > for compute columns (mainly for Sybase now, Microsoft removed > > support for compute columns); > > - NTLMv2 is now on by default. > > > > Implementation: > > - Improved UTF-8 performances; > > - Use more stdint.h style definitions (like uint32_t); > > - Use bool type instead of int; > > - pool server compile under Windows too (not as capable as Unix > > version); > > - CMake build is now able to do an installation; > > - Added a src/utils directory to collect all common code not strictly > > related to replacements or TDS; > > - Simplified makefiles; > > - Support CP1252 encoding in internal trivial iconv; > > - Better ODBC detection. Allows to specify a directory with > > --with-iodbc to specify custom iOBDC. > > Thank you for the new release prerparation. > What is the lowest version freeTDS can connect to now (for both > Sybase/SAP ASE and MS)? > Old versions are still supported, what changes is that they are not accepted as default (global settings) but you need to force server by server. Can you help me rephrase to make more clear? Frediano From sf at 4js.com Tue Feb 5 03:39:15 2019 From: sf at 4js.com (Sebastien FLAESCH) Date: Tue, 5 Feb 2019 09:39:15 +0100 Subject: [freetds] FreeTDS 1.1 Release Candidate 1 - compilation warnings In-Reply-To: References: Message-ID: Hi all, Compiling with gcc 8.2.0, I get following warnings: ... make[4]: Entering directory '/opt3/dbs/tds/sources/freetds-1.1rc1/src/tds' CC mem.lo CC token.lo CC util.lo CC login.lo CC read.lo read.c: In function 'read_and_convert': read.c:290:6: warning: variable 'res' set but not used [-Wunused-but-set-variable] int res; ^~~ CC write.lo write.c: In function 'tds_put_string': write.c:95:6: warning: variable 'res' set but not used [-Wunused-but-set-variable] int res; ^~~ CC convert.lo CC numeric.lo CC config.lo CC query.lo query.c: In function 'tds_submit_execdirect': query.c:1383:11: warning: unused variable 'ret' [-Wunused-variable] TDSRET ret; ^~~ ... CC random.lo random.c: In function 'tds_random_buffer': random.c:59:2: warning: 'RAND_pseudo_bytes' is deprecated [-Wdeprecated-declarations] if (RAND_pseudo_bytes(out, len) >= 0) ^~ In file included from /usr/include/openssl/e_os2.h:13, from /usr/include/openssl/ossl_typ.h:19, from /usr/include/openssl/rand.h:14, from random.c:36: /usr/include/openssl/rand.h:47:1: note: declared here DEPRECATEDIN_1_1_0(int RAND_pseudo_bytes(unsigned char *buf, int num)) ^~~~~~~~~~~~~~~~~~ CC sec_negotiate.lo CC challenge.lo CC gssapi.lo CCLD libtds.la ar: `u' modifier ignored since `D' is the default (see `U') make[4]: Leaving directory '/opt3/dbs/tds/sources/freetds-1.1rc1/src/tds' ... make[3]: Entering directory '/opt3/dbs/tds/sources/freetds-1.1rc1/src/ctlib' CC ct.lo ct.c: In function '_ct_get_client_type': ct.c:1950:2: warning: enumeration value 'SYBNTEXT' not handled in switch [-Wswitch] switch (col->column_type) { ^~~~~~ ct.c:1950:2: warning: enumeration value 'SYBVOID' not handled in switch [-Wswitch] ct.c:1950:2: warning: enumeration value 'SYBNVARCHAR' not handled in switch [-Wswitch] ct.c:1950:2: warning: enumeration value 'XSYBCHAR' not handled in switch [-Wswitch] ct.c:1950:2: warning: enumeration value 'XSYBVARCHAR' not handled in switch [-Wswitch] ct.c:1950:2: warning: enumeration value 'XSYBNVARCHAR' not handled in switch [-Wswitch] ct.c:1950:2: warning: enumeration value 'XSYBNCHAR' not handled in switch [-Wswitch] ct.c:1950:2: warning: enumeration value 'XSYBVARBINARY' not handled in switch [-Wswitch] ct.c:1950:2: warning: enumeration value 'XSYBBINARY' not handled in switch [-Wswitch] ct.c:1950:2: warning: enumeration value 'SYBVARIANT' not handled in switch [-Wswitch] ct.c:1950:2: warning: enumeration value 'SYBMSUDT' not handled in switch [-Wswitch] ct.c:1950:2: warning: enumeration value 'SYBMSXML' not handled in switch [-Wswitch] ct.c:1950:2: warning: enumeration value 'SYBDATEN' not handled in switch [-Wswitch] ct.c:1950:2: warning: enumeration value 'SYB5INT8' not handled in switch [-Wswitch] ct.c:1950:2: warning: enumeration value 'SYBINTERVAL' not handled in switch [-Wswitch] ct.c:1950:2: warning: enumeration value 'SYBLONGCHAR' not handled in switch [-Wswitch] ct.c:1950:2: warning: enumeration value 'SYBSENSITIVITY' not handled in switch [-Wswitch] ct.c:1950:2: warning: enumeration value 'SYBSINT1' not handled in switch [-Wswitch] ct.c:1950:2: warning: enumeration value 'SYBTIMEN' not handled in switch [-Wswitch] ct.c:1950:2: warning: enumeration value 'SYBUINTN' not handled in switch [-Wswitch] ct.c:1950:2: warning: enumeration value 'SYBUNITEXT' not handled in switch [-Wswitch] ct.c:1950:2: warning: enumeration value 'SYBXML' not handled in switch [-Wswitch] ... make[3]: Entering directory '/opt3/dbs/tds/sources/freetds-1.1rc1/src/dblib' CC dblib.lo dblib.c:432:24: warning: 'null_BINARY' defined but not used [-Wunused-const-variable=] static const DBBINARY null_BINARY = 0; ^~~~~~~~~~~ CC dbutil.lo CC rpc.lo CC bcp.lo bcp.c: In function 'bcp_readfmt': bcp.c:1630:8: warning: variable 'lf_version' set but not used [-Wunused-but-set-variable] float lf_version = 0.0; ^~~~~~~~~~ CC xact.lo CC dbpivot.lo dbpivot.c: In function 'col_equal': dbpivot.c:137:2: warning: enumeration value 'SYBNVARCHAR' not handled in switch [-Wswitch] switch(pc1->type) { ^~~~~~ dbpivot.c:137:2: warning: enumeration value 'SYBINT8' not handled in switch [-Wswitch] dbpivot.c:137:2: warning: enumeration value 'XSYBCHAR' not handled in switch [-Wswitch] dbpivot.c:137:2: warning: enumeration value 'XSYBVARCHAR' not handled in switch [-Wswitch] dbpivot.c:137:2: warning: enumeration value 'XSYBNVARCHAR' not handled in switch [-Wswitch] ... dbpivot.c:182:2: warning: enumeration value 'SYBNVARCHAR' not handled in switch [-Wswitch] switch(pcol->type) { ^~~~~~ dbpivot.c:182:2: warning: enumeration value 'SYBINT8' not handled in switch [-Wswitch] dbpivot.c:182:2: warning: enumeration value 'XSYBCHAR' not handled in switch [-Wswitch] dbpivot.c:182:2: warning: enumeration value 'XSYBVARCHAR' not handled in switch [-Wswitch] ... defncopy.c: In function 'get_login': defncopy.c:669:6: warning: variable 'fdomain' set but not used [-Wunused-but-set-variable] int fdomain = TRUE; ^~~~~~~ CCLD defncopy CC datacopy.o ... Seb From matthew.green at datamartcomputing.com Tue Feb 5 04:17:35 2019 From: matthew.green at datamartcomputing.com (matthew.green at datamartcomputing.com) Date: Tue, 05 Feb 2019 09:17:35 +0000 Subject: [freetds] FreeTDS 1.1 Release Candidate 1 In-Reply-To: References: Message-ID: <6b9533c173cb2362ae3221cd1750e132@datamartcomputing.com> It doesn't read to badly to me but you might conisder: Changed default TDS protocol version during configurefrom, from 4.2 and 7.0 to "auto" , you may still specifcy an explicit version to connect to obsolete servers ("auto" won't attempt these versions). CMake build defaults to version 7.1; February 5, 2019 8:43 AM, "Frediano Ziglio" wrote: >> On Mon, Feb 4, 2019 at 1:42 PM Frediano Ziglio wrote: >> >> Hi, >> time for a new release. >> >> Although stable branch is kept updated with bugs and minor features new big >> features, build improves and potential compatibility changes are not ported >> to stable branch. Release bring all these changes, here (available also in NEWS >> file) changes for next release: >> >> Summary of Changes in release 1.1 >> -------------------------------------------- >> User visible (not in a particular order): >> - Removed 4.2 and 7.0 as default TDS protocol versions during >> configure, the default if not specified is now "auto", to connect >> to such obsolete servers you need to specify explicitly the version >> ("auto" won't attempt these versions). CMake build default to >> version 7.1; >> - allows to disable TLS 1.0 support; >> - pool server allows to specify different username/password for server >> and clients allowing to hide internal server logins; >> - tsql utility now send final partial query to server to avoid to have >> to specify a final "GO" line to terminate commands; >> - better support for Microsoft cluster, client will attempt multiple >> connection to server at the same time if DNS reply multiple IPs; >> - MONEY/SMALLMONEY types are now formated with 4 decimal digits to >> avoid truncation; >> - MARS support is now compiled by default; >> - pool server is now compiled by default; >> - Fixed SQL_ATTR_LOGIN_TIMEOUT for ODBC; >> - Fixed large integer numbers for ODBC RPC constants; >> - Fixed encrypted logins if "auto" protocol version is used; >> - Support CS_TIMEOUT and CS_LOGIN_TIMEOUT properties under CTLibrary; >> - Added a dbacolname function in DBLibrary, similar to dbcolname but >> for compute columns (mainly for Sybase now, Microsoft removed >> support for compute columns); >> - NTLMv2 is now on by default. >> >> Implementation: >> - Improved UTF-8 performances; >> - Use more stdint.h style definitions (like uint32_t); >> - Use bool type instead of int; >> - pool server compile under Windows too (not as capable as Unix >> version); >> - CMake build is now able to do an installation; >> - Added a src/utils directory to collect all common code not strictly >> related to replacements or TDS; >> - Simplified makefiles; >> - Support CP1252 encoding in internal trivial iconv; >> - Better ODBC detection. Allows to specify a directory with >> --with-iodbc to specify custom iOBDC. >> >> Thank you for the new release prerparation. >> What is the lowest version freeTDS can connect to now (for both >> Sybase/SAP ASE and MS)? > > Old versions are still supported, what changes is that they are not > accepted as default (global settings) but > you need to force server by server. > Can you help me rephrase to make more clear? > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds From sf at 4js.com Tue Feb 5 04:29:29 2019 From: sf at 4js.com (Sebastien FLAESCH) Date: Tue, 5 Feb 2019 10:29:29 +0100 Subject: [freetds] FreeTDS 1.1 Release Candidate 1 - testing In-Reply-To: References: Message-ID: I have executed our QA test suite with 1.1 RC1 and no issues were detected. Seb On 2/4/19 8:41 PM, Frediano Ziglio wrote: > Hi, > time for a new release. > > Although stable branch is kept updated with bugs and minor features new big > features, build improves and potential compatibility changes are not ported > to stable branch. Release bring all these changes, here (available also in NEWS > file) changes for next release: > > > Summary of Changes in release 1.1 > -------------------------------------------- > User visible (not in a particular order): > - Removed 4.2 and 7.0 as default TDS protocol versions during > configure, the default if not specified is now "auto", to connect > to such obsolete servers you need to specify explicitly the version > ("auto" won't attempt these versions). CMake build default to > version 7.1; > - allows to disable TLS 1.0 support; > - pool server allows to specify different username/password for server > and clients allowing to hide internal server logins; > - tsql utility now send final partial query to server to avoid to have > to specify a final "GO" line to terminate commands; > - better support for Microsoft cluster, client will attempt multiple > connection to server at the same time if DNS reply multiple IPs; > - MONEY/SMALLMONEY types are now formated with 4 decimal digits to > avoid truncation; > - MARS support is now compiled by default; > - pool server is now compiled by default; > - Fixed SQL_ATTR_LOGIN_TIMEOUT for ODBC; > - Fixed large integer numbers for ODBC RPC constants; > - Fixed encrypted logins if "auto" protocol version is used; > - Support CS_TIMEOUT and CS_LOGIN_TIMEOUT properties under CTLibrary; > - Added a dbacolname function in DBLibrary, similar to dbcolname but > for compute columns (mainly for Sybase now, Microsoft removed > support for compute columns); > - NTLMv2 is now on by default. > > Implementation: > - Improved UTF-8 performances; > - Use more stdint.h style definitions (like uint32_t); > - Use bool type instead of int; > - pool server compile under Windows too (not as capable as Unix > version); > - CMake build is now able to do an installation; > - Added a src/utils directory to collect all common code not strictly > related to replacements or TDS; > - Simplified makefiles; > - Support CP1252 encoding in internal trivial iconv; > - Better ODBC detection. Allows to specify a directory with > --with-iodbc to specify custom iOBDC. > > Kind Regards, > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds > From freddy77 at gmail.com Tue Feb 5 06:39:55 2019 From: freddy77 at gmail.com (Frediano Ziglio) Date: Tue, 5 Feb 2019 11:39:55 +0000 Subject: [freetds] FreeTDS 1.1 Release Candidate 1 In-Reply-To: <6b9533c173cb2362ae3221cd1750e132@datamartcomputing.com> References: <6b9533c173cb2362ae3221cd1750e132@datamartcomputing.com> Message-ID: Il giorno mar 5 feb 2019 alle ore 09:23 ha scritto: > > It doesn't read to badly to me but you might conisder: > > Changed default TDS protocol version during configurefrom, from 4.2 and 7.0 to "auto" > , you may still specifcy an explicit version to connect to obsolete servers > ("auto" won't attempt these versions). CMake build defaults to > version 7.1; > What about: - Changed default TDS protocol version during configure to "auto". Versions 4.2 and 7.0 are no more accepted for default, you may still specify an explicit version to connect to obsolete servers ("auto" won't attempt these versions). CMake build defaults to version 7.1; > > February 5, 2019 8:43 AM, "Frediano Ziglio" wrote: > > >> On Mon, Feb 4, 2019 at 1:42 PM Frediano Ziglio wrote: > >> > >> Hi, > >> time for a new release. > >> > >> Although stable branch is kept updated with bugs and minor features new big > >> features, build improves and potential compatibility changes are not ported > >> to stable branch. Release bring all these changes, here (available also in NEWS > >> file) changes for next release: > >> > >> Summary of Changes in release 1.1 > >> -------------------------------------------- > >> User visible (not in a particular order): > >> - Removed 4.2 and 7.0 as default TDS protocol versions during > >> configure, the default if not specified is now "auto", to connect > >> to such obsolete servers you need to specify explicitly the version > >> ("auto" won't attempt these versions). CMake build default to > >> version 7.1; > >> - allows to disable TLS 1.0 support; > >> - pool server allows to specify different username/password for server > >> and clients allowing to hide internal server logins; > >> - tsql utility now send final partial query to server to avoid to have > >> to specify a final "GO" line to terminate commands; > >> - better support for Microsoft cluster, client will attempt multiple > >> connection to server at the same time if DNS reply multiple IPs; > >> - MONEY/SMALLMONEY types are now formated with 4 decimal digits to > >> avoid truncation; > >> - MARS support is now compiled by default; > >> - pool server is now compiled by default; > >> - Fixed SQL_ATTR_LOGIN_TIMEOUT for ODBC; > >> - Fixed large integer numbers for ODBC RPC constants; > >> - Fixed encrypted logins if "auto" protocol version is used; > >> - Support CS_TIMEOUT and CS_LOGIN_TIMEOUT properties under CTLibrary; > >> - Added a dbacolname function in DBLibrary, similar to dbcolname but > >> for compute columns (mainly for Sybase now, Microsoft removed > >> support for compute columns); > >> - NTLMv2 is now on by default. > >> > >> Implementation: > >> - Improved UTF-8 performances; > >> - Use more stdint.h style definitions (like uint32_t); > >> - Use bool type instead of int; > >> - pool server compile under Windows too (not as capable as Unix > >> version); > >> - CMake build is now able to do an installation; > >> - Added a src/utils directory to collect all common code not strictly > >> related to replacements or TDS; > >> - Simplified makefiles; > >> - Support CP1252 encoding in internal trivial iconv; > >> - Better ODBC detection. Allows to specify a directory with > >> --with-iodbc to specify custom iOBDC. > >> > >> Thank you for the new release prerparation. > >> What is the lowest version freeTDS can connect to now (for both > >> Sybase/SAP ASE and MS)? > > > > Old versions are still supported, what changes is that they are not > > accepted as default (global settings) but > > you need to force server by server. > > Can you help me rephrase to make more clear? > > > > Frediano From matthew.green at datamartcomputing.com Tue Feb 5 07:41:22 2019 From: matthew.green at datamartcomputing.com (matthew.green at datamartcomputing.com) Date: Tue, 05 Feb 2019 12:41:22 +0000 Subject: [freetds] FreeTDS 1.1 Release Candidate 1 In-Reply-To: References: <6b9533c173cb2362ae3221cd1750e132@datamartcomputing.com> Message-ID: <6811b42e8d3b8f282796c3c06b0c75e4@datamartcomputing.com> Seems good but "no more accepted for default" should probably be "no longer accepted by default", if I've understood your meaning correctly. February 5, 2019 12:39 PM, "Frediano Ziglio" wrote: > Il giorno mar 5 feb 2019 alle ore 09:23 > ha scritto: > >> It doesn't read to badly to me but you might conisder: >> >> Changed default TDS protocol version during configurefrom, from 4.2 and 7.0 to "auto" >> , you may still specifcy an explicit version to connect to obsolete servers >> ("auto" won't attempt these versions). CMake build defaults to >> version 7.1; > > What about: > > - Changed default TDS protocol version during configure to "auto". > Versions 4.2 and 7.0 are no more accepted for default, you may > still specify an explicit version to connect to obsolete servers > ("auto" won't attempt these versions). CMake build defaults to > version 7.1; > >> February 5, 2019 8:43 AM, "Frediano Ziglio" wrote: >> >> On Mon, Feb 4, 2019 at 1:42 PM Frediano Ziglio wrote: >> >> Hi, >> time for a new release. >> >> Although stable branch is kept updated with bugs and minor features new big >> features, build improves and potential compatibility changes are not ported >> to stable branch. Release bring all these changes, here (available also in NEWS >> file) changes for next release: >> >> Summary of Changes in release 1.1 >> -------------------------------------------- >> User visible (not in a particular order): >> - Removed 4.2 and 7.0 as default TDS protocol versions during >> configure, the default if not specified is now "auto", to connect >> to such obsolete servers you need to specify explicitly the version >> ("auto" won't attempt these versions). CMake build default to >> version 7.1; >> - allows to disable TLS 1.0 support; >> - pool server allows to specify different username/password for server >> and clients allowing to hide internal server logins; >> - tsql utility now send final partial query to server to avoid to have >> to specify a final "GO" line to terminate commands; >> - better support for Microsoft cluster, client will attempt multiple >> connection to server at the same time if DNS reply multiple IPs; >> - MONEY/SMALLMONEY types are now formated with 4 decimal digits to >> avoid truncation; >> - MARS support is now compiled by default; >> - pool server is now compiled by default; >> - Fixed SQL_ATTR_LOGIN_TIMEOUT for ODBC; >> - Fixed large integer numbers for ODBC RPC constants; >> - Fixed encrypted logins if "auto" protocol version is used; >> - Support CS_TIMEOUT and CS_LOGIN_TIMEOUT properties under CTLibrary; >> - Added a dbacolname function in DBLibrary, similar to dbcolname but >> for compute columns (mainly for Sybase now, Microsoft removed >> support for compute columns); >> - NTLMv2 is now on by default. >> >> Implementation: >> - Improved UTF-8 performances; >> - Use more stdint.h style definitions (like uint32_t); >> - Use bool type instead of int; >> - pool server compile under Windows too (not as capable as Unix >> version); >> - CMake build is now able to do an installation; >> - Added a src/utils directory to collect all common code not strictly >> related to replacements or TDS; >> - Simplified makefiles; >> - Support CP1252 encoding in internal trivial iconv; >> - Better ODBC detection. Allows to specify a directory with >> --with-iodbc to specify custom iOBDC. >> >> Thank you for the new release prerparation. >> What is the lowest version freeTDS can connect to now (for both >> Sybase/SAP ASE and MS)? >> >> Old versions are still supported, what changes is that they are not >> accepted as default (global settings) but >> you need to force server by server. >> Can you help me rephrase to make more clear? >> >> Frediano > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds From no-reply at appveyor.com Thu Feb 7 06:54:47 2019 From: no-reply at appveyor.com (AppVeyor) Date: Thu, 07 Feb 2019 11:54:47 +0000 Subject: [freetds] Build failed: freetds 1313 Message-ID: <20190207115447.1.A5BBD6541370866F@appveyor.com> From no-reply at appveyor.com Fri Feb 8 08:32:02 2019 From: no-reply at appveyor.com (AppVeyor) Date: Fri, 08 Feb 2019 13:32:02 +0000 Subject: [freetds] Build completed: freetds 1318 Message-ID: <20190208133202.1.084F44FFC49F1F8E@appveyor.com> From no-reply at appveyor.com Fri Feb 8 10:12:13 2019 From: no-reply at appveyor.com (AppVeyor) Date: Fri, 08 Feb 2019 15:12:13 +0000 Subject: [freetds] Build failed: freetds 1319 Message-ID: <20190208151213.1.F9C3D920A26840C9@appveyor.com> From no-reply at appveyor.com Fri Feb 8 13:27:29 2019 From: no-reply at appveyor.com (AppVeyor) Date: Fri, 08 Feb 2019 18:27:29 +0000 Subject: [freetds] Build failed: freetds 1322 Message-ID: <20190208182729.1.2E4A91317EF61BB4@appveyor.com> From no-reply at appveyor.com Fri Feb 8 14:54:19 2019 From: no-reply at appveyor.com (AppVeyor) Date: Fri, 08 Feb 2019 19:54:19 +0000 Subject: [freetds] Build completed: freetds 1323 Message-ID: <20190208195419.1.81EBB41AE94C31D6@appveyor.com> From no-reply at appveyor.com Fri Feb 8 15:03:47 2019 From: no-reply at appveyor.com (AppVeyor) Date: Fri, 08 Feb 2019 20:03:47 +0000 Subject: [freetds] Build failed: freetds 1324 Message-ID: <20190208200347.1.DFEAED7E23EDEB72@appveyor.com> From no-reply at appveyor.com Fri Feb 8 16:45:24 2019 From: no-reply at appveyor.com (AppVeyor) Date: Fri, 08 Feb 2019 21:45:24 +0000 Subject: [freetds] Build completed: freetds 1322 Message-ID: <20190208214524.1.3DC706650FB82D3E@appveyor.com> From no-reply at appveyor.com Fri Feb 8 17:14:29 2019 From: no-reply at appveyor.com (AppVeyor) Date: Fri, 08 Feb 2019 22:14:29 +0000 Subject: [freetds] Build failed: freetds 1325 Message-ID: <20190208221429.1.33A4F9BAFBDA45F8@appveyor.com> From no-reply at appveyor.com Fri Feb 8 19:13:31 2019 From: no-reply at appveyor.com (AppVeyor) Date: Sat, 09 Feb 2019 00:13:31 +0000 Subject: [freetds] Build completed: freetds 1326 Message-ID: <20190209001331.1.A495B789279B010C@appveyor.com> From freddy77 at gmail.com Sat Feb 9 13:58:32 2019 From: freddy77 at gmail.com (Frediano Ziglio) Date: Sat, 9 Feb 2019 18:58:32 +0000 Subject: [freetds] FreeTDS 1.1 Release Candidate 2 Message-ID: Hi, just another updated release candidate. Changes since previous release candidate: - Project files for OpenVMS upgraded. Thanks to Craig for the quick update; - Updated documentation on protocol version and other minor changes; - Cleaned some code for old protocols; - Resolved some minor issues with CI and tests; - CMake build (like autotools) now default to TDS protocol version "auto"; - Improved TDS protocol detection in case of failure. General release changes (as in NEWS file): Summary of Changes in release 1.1 -------------------------------------------- User visible (not in a particular order): - Changed default TDS protocol version during configure to "auto". Versions 4.2 and 7.0 are no longer accepted for default, you may still specify an explicit version to connect to obsolete servers ("auto" won't attempt these versions); - allows to disable TLS 1.0 support; - pool server allows to specify different username/password for server and clients allowing to hide internal server logins; - tsql utility now send final partial query to server to avoid to have to specify a final "GO" line to terminate commands; - better support for Microsoft cluster, client will attempt multiple connection to server at the same time if DNS reply multiple IPs; - MONEY/SMALLMONEY types are now formated with 4 decimal digits to avoid truncation; - MARS support is now compiled by default; - pool server is now compiled by default; - Fixed SQL_ATTR_LOGIN_TIMEOUT for ODBC; - Fixed large integer numbers for ODBC RPC constants; - Fixed encrypted logins if "auto" protocol version is used; - Support CS_TIMEOUT and CS_LOGIN_TIMEOUT properties under CTLibrary; - Added a dbacolname function in DBLibrary, similar to dbcolname but for compute columns (mainly for Sybase now, Microsoft removed support for compute columns); - NTLMv2 is now on by default. Implementation: - Improved UTF-8 performances; - Use more stdint.h style definitions (like uint32_t); - Use bool type instead of int; - pool server compile under Windows too (not as capable as Unix version); - CMake build is now able to do an installation; - Added a src/utils directory to collect all common code not strictly related to replacements or TDS; - Simplified makefiles; - Support CP1252 encoding in internal trivial iconv; - Better ODBC detection. Allows to specify a directory with --with-iodbc to specify custom iOBDC. Kind Regards, Frediano From sf at 4js.com Mon Feb 11 04:17:48 2019 From: sf at 4js.com (Sebastien FLAESCH) Date: Mon, 11 Feb 2019 10:17:48 +0100 Subject: [freetds] FreeTDS 1.1 Release Candidate 2 - compiler warnings In-Reply-To: References: Message-ID: Attached, compiler warnings with gcc 8.2.0 ... Seb On 2/9/19 7:58 PM, Frediano Ziglio wrote: > Hi, > just another updated release candidate. > > Changes since previous release candidate: > - Project files for OpenVMS upgraded. Thanks to Craig for the quick update; > - Updated documentation on protocol version and other minor changes; > - Cleaned some code for old protocols; > - Resolved some minor issues with CI and tests; > - CMake build (like autotools) now default to TDS protocol version "auto"; > - Improved TDS protocol detection in case of failure. > > General release changes (as in NEWS file): > > > Summary of Changes in release 1.1 > -------------------------------------------- > User visible (not in a particular order): > - Changed default TDS protocol version during configure to "auto". > Versions 4.2 and 7.0 are no longer accepted for default, you may > still specify an explicit version to connect to obsolete servers > ("auto" won't attempt these versions); > - allows to disable TLS 1.0 support; > - pool server allows to specify different username/password for server > and clients allowing to hide internal server logins; > - tsql utility now send final partial query to server to avoid to have > to specify a final "GO" line to terminate commands; > - better support for Microsoft cluster, client will attempt multiple > connection to server at the same time if DNS reply multiple IPs; > - MONEY/SMALLMONEY types are now formated with 4 decimal digits to > avoid truncation; > - MARS support is now compiled by default; > - pool server is now compiled by default; > - Fixed SQL_ATTR_LOGIN_TIMEOUT for ODBC; > - Fixed large integer numbers for ODBC RPC constants; > - Fixed encrypted logins if "auto" protocol version is used; > - Support CS_TIMEOUT and CS_LOGIN_TIMEOUT properties under CTLibrary; > - Added a dbacolname function in DBLibrary, similar to dbcolname but > for compute columns (mainly for Sybase now, Microsoft removed > support for compute columns); > - NTLMv2 is now on by default. > > Implementation: > - Improved UTF-8 performances; > - Use more stdint.h style definitions (like uint32_t); > - Use bool type instead of int; > - pool server compile under Windows too (not as capable as Unix > version); > - CMake build is now able to do an installation; > - Added a src/utils directory to collect all common code not strictly > related to replacements or TDS; > - Simplified makefiles; > - Support CP1252 encoding in internal trivial iconv; > - Better ODBC detection. Allows to specify a directory with > --with-iodbc to specify custom iOBDC. > > > Kind Regards, > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds > -------------- next part -------------- A non-text attachment was scrubbed... Name: freetds-make.log Type: text/x-log Size: 25024 bytes Desc: not available URL: From mjetzer.cdc at gmail.com Mon Feb 11 10:20:02 2019 From: mjetzer.cdc at gmail.com (Mike Jetzer) Date: Mon, 11 Feb 2019 09:20:02 -0600 Subject: [freetds] FreeTDS 1.1 Release Candidate 2 - compiler warnings In-Reply-To: References: Message-ID: We're compiling FreeTDS as 32 bit ("gcc -m32") on RHEL 7.3 (gcc 4.8.5-11). Received most of the same warnings as Sebastien reported; we also encountered a few additional warnings plus an actual error. See attached. On Mon, Feb 11, 2019 at 3:18 AM Sebastien FLAESCH wrote: > Attached, compiler warnings with gcc 8.2.0 ... > > Seb > > On 2/9/19 7:58 PM, Frediano Ziglio wrote: > > Hi, > > just another updated release candidate. > > > > Changes since previous release candidate: > > - Project files for OpenVMS upgraded. Thanks to Craig for the quick > update; > > - Updated documentation on protocol version and other minor changes; > > - Cleaned some code for old protocols; > > - Resolved some minor issues with CI and tests; > > - CMake build (like autotools) now default to TDS protocol version > "auto"; > > - Improved TDS protocol detection in case of failure. > > > > General release changes (as in NEWS file): > > > > > > Summary of Changes in release 1.1 > > -------------------------------------------- > > User visible (not in a particular order): > > - Changed default TDS protocol version during configure to "auto". > > Versions 4.2 and 7.0 are no longer accepted for default, you may > > still specify an explicit version to connect to obsolete servers > > ("auto" won't attempt these versions); > > - allows to disable TLS 1.0 support; > > - pool server allows to specify different username/password for server > > and clients allowing to hide internal server logins; > > - tsql utility now send final partial query to server to avoid to have > > to specify a final "GO" line to terminate commands; > > - better support for Microsoft cluster, client will attempt multiple > > connection to server at the same time if DNS reply multiple IPs; > > - MONEY/SMALLMONEY types are now formated with 4 decimal digits to > > avoid truncation; > > - MARS support is now compiled by default; > > - pool server is now compiled by default; > > - Fixed SQL_ATTR_LOGIN_TIMEOUT for ODBC; > > - Fixed large integer numbers for ODBC RPC constants; > > - Fixed encrypted logins if "auto" protocol version is used; > > - Support CS_TIMEOUT and CS_LOGIN_TIMEOUT properties under CTLibrary; > > - Added a dbacolname function in DBLibrary, similar to dbcolname but > > for compute columns (mainly for Sybase now, Microsoft removed > > support for compute columns); > > - NTLMv2 is now on by default. > > > > Implementation: > > - Improved UTF-8 performances; > > - Use more stdint.h style definitions (like uint32_t); > > - Use bool type instead of int; > > - pool server compile under Windows too (not as capable as Unix > > version); > > - CMake build is now able to do an installation; > > - Added a src/utils directory to collect all common code not strictly > > related to replacements or TDS; > > - Simplified makefiles; > > - Support CP1252 encoding in internal trivial iconv; > > - Better ODBC detection. Allows to specify a directory with > > --with-iodbc to specify custom iOBDC. > > > > > > Kind Regards, > > Frediano > > _______________________________________________ > > FreeTDS mailing list > > FreeTDS at lists.ibiblio.org > > https://lists.ibiblio.org/mailman/listinfo/freetds > > > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds > -------------- next part -------------- A non-text attachment was scrubbed... Name: freetds-1.1rc2-make.log Type: application/octet-stream Size: 2006 bytes Desc: not available URL: From sf at 4js.com Wed Feb 13 05:45:07 2019 From: sf at 4js.com (Sebastien FLAESCH) Date: Wed, 13 Feb 2019 11:45:07 +0100 Subject: [freetds] FreeTDS 1.1 Release Candidate 2 In-Reply-To: References: Message-ID: Hi, I have used 1.1.rc2 on our QA tests, no issue detected. Seb On 2/9/19 7:58 PM, Frediano Ziglio wrote: > Hi, > just another updated release candidate. > > Changes since previous release candidate: > - Project files for OpenVMS upgraded. Thanks to Craig for the quick update; > - Updated documentation on protocol version and other minor changes; > - Cleaned some code for old protocols; > - Resolved some minor issues with CI and tests; > - CMake build (like autotools) now default to TDS protocol version "auto"; > - Improved TDS protocol detection in case of failure. > > General release changes (as in NEWS file): > > > Summary of Changes in release 1.1 > -------------------------------------------- > User visible (not in a particular order): > - Changed default TDS protocol version during configure to "auto". > Versions 4.2 and 7.0 are no longer accepted for default, you may > still specify an explicit version to connect to obsolete servers > ("auto" won't attempt these versions); > - allows to disable TLS 1.0 support; > - pool server allows to specify different username/password for server > and clients allowing to hide internal server logins; > - tsql utility now send final partial query to server to avoid to have > to specify a final "GO" line to terminate commands; > - better support for Microsoft cluster, client will attempt multiple > connection to server at the same time if DNS reply multiple IPs; > - MONEY/SMALLMONEY types are now formated with 4 decimal digits to > avoid truncation; > - MARS support is now compiled by default; > - pool server is now compiled by default; > - Fixed SQL_ATTR_LOGIN_TIMEOUT for ODBC; > - Fixed large integer numbers for ODBC RPC constants; > - Fixed encrypted logins if "auto" protocol version is used; > - Support CS_TIMEOUT and CS_LOGIN_TIMEOUT properties under CTLibrary; > - Added a dbacolname function in DBLibrary, similar to dbcolname but > for compute columns (mainly for Sybase now, Microsoft removed > support for compute columns); > - NTLMv2 is now on by default. > > Implementation: > - Improved UTF-8 performances; > - Use more stdint.h style definitions (like uint32_t); > - Use bool type instead of int; > - pool server compile under Windows too (not as capable as Unix > version); > - CMake build is now able to do an installation; > - Added a src/utils directory to collect all common code not strictly > related to replacements or TDS; > - Simplified makefiles; > - Support CP1252 encoding in internal trivial iconv; > - Better ODBC detection. Allows to specify a directory with > --with-iodbc to specify custom iOBDC. > > > Kind Regards, > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds > From freddy77 at gmail.com Fri Feb 15 05:20:39 2019 From: freddy77 at gmail.com (Frediano Ziglio) Date: Fri, 15 Feb 2019 10:20:39 +0000 Subject: [freetds] FreeTDS 1.1 Release Candidate 2 - compiler warnings In-Reply-To: References: Message-ID: Hi, thanks, not an issue, just normal warnings, I don't plan to remove them for version 1.1. Some fixes are part of a large series I'm slowly integrating Regards, Frediano Il giorno lun 11 feb 2019 alle ore 09:18 Sebastien FLAESCH ha scritto: > > Attached, compiler warnings with gcc 8.2.0 ... > > Seb > > On 2/9/19 7:58 PM, Frediano Ziglio wrote: > > Hi, > > just another updated release candidate. > > > > Changes since previous release candidate: > > - Project files for OpenVMS upgraded. Thanks to Craig for the quick update; > > - Updated documentation on protocol version and other minor changes; > > - Cleaned some code for old protocols; > > - Resolved some minor issues with CI and tests; > > - CMake build (like autotools) now default to TDS protocol version "auto"; > > - Improved TDS protocol detection in case of failure. > > > > General release changes (as in NEWS file): > > > > > > Summary of Changes in release 1.1 > > -------------------------------------------- > > User visible (not in a particular order): > > - Changed default TDS protocol version during configure to "auto". > > Versions 4.2 and 7.0 are no longer accepted for default, you may > > still specify an explicit version to connect to obsolete servers > > ("auto" won't attempt these versions); > > - allows to disable TLS 1.0 support; > > - pool server allows to specify different username/password for server > > and clients allowing to hide internal server logins; > > - tsql utility now send final partial query to server to avoid to have > > to specify a final "GO" line to terminate commands; > > - better support for Microsoft cluster, client will attempt multiple > > connection to server at the same time if DNS reply multiple IPs; > > - MONEY/SMALLMONEY types are now formated with 4 decimal digits to > > avoid truncation; > > - MARS support is now compiled by default; > > - pool server is now compiled by default; > > - Fixed SQL_ATTR_LOGIN_TIMEOUT for ODBC; > > - Fixed large integer numbers for ODBC RPC constants; > > - Fixed encrypted logins if "auto" protocol version is used; > > - Support CS_TIMEOUT and CS_LOGIN_TIMEOUT properties under CTLibrary; > > - Added a dbacolname function in DBLibrary, similar to dbcolname but > > for compute columns (mainly for Sybase now, Microsoft removed > > support for compute columns); > > - NTLMv2 is now on by default. > > > > Implementation: > > - Improved UTF-8 performances; > > - Use more stdint.h style definitions (like uint32_t); > > - Use bool type instead of int; > > - pool server compile under Windows too (not as capable as Unix > > version); > > - CMake build is now able to do an installation; > > - Added a src/utils directory to collect all common code not strictly > > related to replacements or TDS; > > - Simplified makefiles; > > - Support CP1252 encoding in internal trivial iconv; > > - Better ODBC detection. Allows to specify a directory with > > --with-iodbc to specify custom iOBDC. > > > > > > Kind Regards, > > Frediano > > _______________________________________________ > > FreeTDS mailing list > > FreeTDS at lists.ibiblio.org > > https://lists.ibiblio.org/mailman/listinfo/freetds > > > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds From mjetzer.cdc at gmail.com Fri Feb 15 15:35:34 2019 From: mjetzer.cdc at gmail.com (Mike Jetzer) Date: Fri, 15 Feb 2019 14:35:34 -0600 Subject: [freetds] FreeTDS 1.1 Release Candidate 2 - compiler warnings In-Reply-To: References: Message-ID: Hopefully the compiler error will be corrected: gmake[4]: Entering directory `/tmp/freetds-1.1rc2/src/odbc' CC connectparams.lo connectparams.c:94:12: error: static declaration of 'SQLGetPrivateProfileString' follows non-static declaration static int SQLGetPrivateProfileString(LPCSTR pszSection, LPCSTR pszEntry, LPCSTR pszDefault, LPSTR pRetBuffer, int nRetBuffer, ^ In file included from ../../include/freetds/odbc.h:33:0, from connectparams.c:30: /usr/local/unixODBC-2.3.7/include/odbcinst.h:205:14: note: previous declaration of 'SQLGetPrivateProfileString' was here int INSTAPI SQLGetPrivateProfileString( LPCSTR lpszSection, ^ gmake[4]: [connectparams.lo] Error 1 (ignored) We do not have the RHEL-provided version of unixODBC installed, having instead compiled our own in /usr/local/unixODBC-2.3.7. We invoked configure as ./configure --prefix=/usr/local/freetds-1.1rc2 \ --with-unixodbc=/usr/local/unixODBC-2.3.7 The "configure" output for freetds-1.1rc2 notes checking for SQLGetPrivateProfileString in -lodbcinst... no Looking at config.log, I see that configure:19411: gcc -m32 -o conftest -g -O2 -DUNIXODBC -DHAVE_UNISTD_H -DHAVE_PWD_H -HAVE_SYS_TYPES_H -DHAVE_LONG_LONG -DSIZEOF_LONG_INT=4 -I/usr/local/unixODBC-2.3.7/include conftest.c -lodbcinst -lpthread >&5 So it looks like the failure occurs because configure is not adding an "-L" with the unixODBC library directory. Also in config.log, I see that odbc_config is properly reporting the --lib-prefix correctly: ODBC_CONFIG='/usr/local/unixODBC-2.3.7/bin/odbc_config' ODBC_FALSE='#' ODBC_INC='-I/usr/local/unixODBC-2.3.7/include' ODBC_LDFLAGS='-L/usr/local/unixODBC-2.3.7/lib -lodbc' I don't know enough about autoconf to debug this any farther. We are currently using freetds-1.00.97. When running that version's configure --with-unixodbc=/usr/local/unixODBC-2.3.7, I see that configure reports checking for SQLGetPrivateProfileString in -lodbcinst... yes and that config.log shows configure:19259: checking for SQLGetPrivateProfileString in -lodbcinst configure:19284: gcc -m32 -o conftest -g -O2 -DUNIXODBC -DHAVE_UNISTD_H -DHAVE_PWD_H -DHAVE_SYS_TYPES_H -DHAVE_LONG_LONG -DSIZEOF_LONG_INT=4 -I/usr/local/unixODBC-2.3.7/include -L/usr/local/unixODBC-2.3.7/lib conftest.c -lodbcinst -lpthread >&5 I see that the "configure" in freetds-1.00.97 put the unixODBC library directory directly in LDFLAGS, rather than having a separate ODBC_LDFLAGS, as noted in config.log: LDFLAGS=' -L/usr/local/unixODBC-2.3.7/lib' On Fri, Feb 15, 2019 at 1:39 PM Frediano Ziglio wrote: > Hi, > thanks, not an issue, just normal warnings, I don't plan to remove > them for version 1.1. > Some fixes are part of a large series I'm slowly integrating > > Regards, > Frediano > > Il giorno lun 11 feb 2019 alle ore 09:18 Sebastien FLAESCH > ha scritto: > > > > Attached, compiler warnings with gcc 8.2.0 ... > > > > Seb > > > > On 2/9/19 7:58 PM, Frediano Ziglio wrote: > > > Hi, > > > just another updated release candidate. > > > > > > Changes since previous release candidate: > > > - Project files for OpenVMS upgraded. Thanks to Craig for the quick > update; > > > - Updated documentation on protocol version and other minor changes; > > > - Cleaned some code for old protocols; > > > - Resolved some minor issues with CI and tests; > > > - CMake build (like autotools) now default to TDS protocol version > "auto"; > > > - Improved TDS protocol detection in case of failure. > > > > > > General release changes (as in NEWS file): > > > > > > > > > Summary of Changes in release 1.1 > > > -------------------------------------------- > > > User visible (not in a particular order): > > > - Changed default TDS protocol version during configure to "auto". > > > Versions 4.2 and 7.0 are no longer accepted for default, you may > > > still specify an explicit version to connect to obsolete servers > > > ("auto" won't attempt these versions); > > > - allows to disable TLS 1.0 support; > > > - pool server allows to specify different username/password for server > > > and clients allowing to hide internal server logins; > > > - tsql utility now send final partial query to server to avoid to have > > > to specify a final "GO" line to terminate commands; > > > - better support for Microsoft cluster, client will attempt multiple > > > connection to server at the same time if DNS reply multiple IPs; > > > - MONEY/SMALLMONEY types are now formated with 4 decimal digits to > > > avoid truncation; > > > - MARS support is now compiled by default; > > > - pool server is now compiled by default; > > > - Fixed SQL_ATTR_LOGIN_TIMEOUT for ODBC; > > > - Fixed large integer numbers for ODBC RPC constants; > > > - Fixed encrypted logins if "auto" protocol version is used; > > > - Support CS_TIMEOUT and CS_LOGIN_TIMEOUT properties under CTLibrary; > > > - Added a dbacolname function in DBLibrary, similar to dbcolname but > > > for compute columns (mainly for Sybase now, Microsoft removed > > > support for compute columns); > > > - NTLMv2 is now on by default. > > > > > > Implementation: > > > - Improved UTF-8 performances; > > > - Use more stdint.h style definitions (like uint32_t); > > > - Use bool type instead of int; > > > - pool server compile under Windows too (not as capable as Unix > > > version); > > > - CMake build is now able to do an installation; > > > - Added a src/utils directory to collect all common code not strictly > > > related to replacements or TDS; > > > - Simplified makefiles; > > > - Support CP1252 encoding in internal trivial iconv; > > > - Better ODBC detection. Allows to specify a directory with > > > --with-iodbc to specify custom iOBDC. > > > > > > > > > Kind Regards, > > > Frediano > > > _______________________________________________ > > > FreeTDS mailing list > > > FreeTDS at lists.ibiblio.org > > > https://lists.ibiblio.org/mailman/listinfo/freetds > > > > > > > _______________________________________________ > > FreeTDS mailing list > > FreeTDS at lists.ibiblio.org > > https://lists.ibiblio.org/mailman/listinfo/freetds > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds > From freddy77 at gmail.com Tue Feb 19 03:28:15 2019 From: freddy77 at gmail.com (Frediano Ziglio) Date: Tue, 19 Feb 2019 08:28:15 +0000 Subject: [freetds] FreeTDS 1.1 Release Candidate 2 - compiler warnings In-Reply-To: References: Message-ID: Hi, can you try this? Should fix both error and md4/md5 warnings. Download from http://ge.tt/7jeAtYu2, it's the first upload website I found so check the hashes: sha1 c5dab0b83ba917aad0595d0d6d8884d2ef788b33 freetds-1.1rc2.tar.bz2 md5 7ce98e61d5490a421cab8a2b916fce90 freetds-1.1rc2.tar.bz2 Frediano Il giorno mar 19 feb 2019 alle ore 08:18 Mike Jetzer ha scritto: > > Hopefully the compiler error will be corrected: > > gmake[4]: Entering directory `/tmp/freetds-1.1rc2/src/odbc' > CC connectparams.lo > connectparams.c:94:12: error: static declaration of > 'SQLGetPrivateProfileString' follows non-static declaration > static int SQLGetPrivateProfileString(LPCSTR pszSection, LPCSTR pszEntry, > LPCSTR pszDefault, LPSTR pRetBuffer, int nRetBuffer, > ^ > In file included from ../../include/freetds/odbc.h:33:0, > from connectparams.c:30: > /usr/local/unixODBC-2.3.7/include/odbcinst.h:205:14: note: previous > declaration of 'SQLGetPrivateProfileString' was here > int INSTAPI SQLGetPrivateProfileString( LPCSTR lpszSection, > ^ > gmake[4]: [connectparams.lo] Error 1 (ignored) > > > > We do not have the RHEL-provided version of unixODBC installed, having > instead compiled our own in /usr/local/unixODBC-2.3.7. > > We invoked configure as > > ./configure --prefix=/usr/local/freetds-1.1rc2 \ > --with-unixodbc=/usr/local/unixODBC-2.3.7 > > > The "configure" output for freetds-1.1rc2 notes > > checking for SQLGetPrivateProfileString in -lodbcinst... no > > > Looking at config.log, I see that > > configure:19411: gcc -m32 -o conftest -g -O2 -DUNIXODBC -DHAVE_UNISTD_H > -DHAVE_PWD_H -HAVE_SYS_TYPES_H -DHAVE_LONG_LONG -DSIZEOF_LONG_INT=4 > -I/usr/local/unixODBC-2.3.7/include conftest.c -lodbcinst -lpthread >&5 > > > So it looks like the failure occurs because configure is not adding an "-L" > with the unixODBC library directory. > > Also in config.log, I see that odbc_config is properly reporting the > --lib-prefix correctly: > > ODBC_CONFIG='/usr/local/unixODBC-2.3.7/bin/odbc_config' > ODBC_FALSE='#' > ODBC_INC='-I/usr/local/unixODBC-2.3.7/include' > ODBC_LDFLAGS='-L/usr/local/unixODBC-2.3.7/lib -lodbc' > > > I don't know enough about autoconf to debug this any farther. > > > We are currently using freetds-1.00.97. When running that version's > configure --with-unixodbc=/usr/local/unixODBC-2.3.7, I see that configure > reports > > checking for SQLGetPrivateProfileString in -lodbcinst... yes > > and that config.log shows > > configure:19259: checking for SQLGetPrivateProfileString in -lodbcinst > configure:19284: gcc -m32 -o conftest -g -O2 -DUNIXODBC -DHAVE_UNISTD_H > -DHAVE_PWD_H -DHAVE_SYS_TYPES_H -DHAVE_LONG_LONG -DSIZEOF_LONG_INT=4 > -I/usr/local/unixODBC-2.3.7/include -L/usr/local/unixODBC-2.3.7/lib > conftest.c -lodbcinst -lpthread >&5 > > > I see that the "configure" in freetds-1.00.97 put the unixODBC library > directory directly in LDFLAGS, rather than having a separate ODBC_LDFLAGS, > as noted in config.log: > > LDFLAGS=' -L/usr/local/unixODBC-2.3.7/lib' > > > > On Fri, Feb 15, 2019 at 1:39 PM Frediano Ziglio wrote: > > > Hi, > > thanks, not an issue, just normal warnings, I don't plan to remove > > them for version 1.1. > > Some fixes are part of a large series I'm slowly integrating > > > > Regards, > > Frediano > > > > Il giorno lun 11 feb 2019 alle ore 09:18 Sebastien FLAESCH > > ha scritto: > > > > > > Attached, compiler warnings with gcc 8.2.0 ... > > > > > > Seb > > > > > > On 2/9/19 7:58 PM, Frediano Ziglio wrote: > > > > Hi, > > > > just another updated release candidate. > > > > > > > > Changes since previous release candidate: > > > > - Project files for OpenVMS upgraded. Thanks to Craig for the quick > > update; > > > > - Updated documentation on protocol version and other minor changes; > > > > - Cleaned some code for old protocols; > > > > - Resolved some minor issues with CI and tests; > > > > - CMake build (like autotools) now default to TDS protocol version > > "auto"; > > > > - Improved TDS protocol detection in case of failure. > > > > > > > > General release changes (as in NEWS file): > > > > > > > > > > > > Summary of Changes in release 1.1 > > > > -------------------------------------------- > > > > User visible (not in a particular order): > > > > - Changed default TDS protocol version during configure to "auto". > > > > Versions 4.2 and 7.0 are no longer accepted for default, you may > > > > still specify an explicit version to connect to obsolete servers > > > > ("auto" won't attempt these versions); > > > > - allows to disable TLS 1.0 support; > > > > - pool server allows to specify different username/password for server > > > > and clients allowing to hide internal server logins; > > > > - tsql utility now send final partial query to server to avoid to have > > > > to specify a final "GO" line to terminate commands; > > > > - better support for Microsoft cluster, client will attempt multiple > > > > connection to server at the same time if DNS reply multiple IPs; > > > > - MONEY/SMALLMONEY types are now formated with 4 decimal digits to > > > > avoid truncation; > > > > - MARS support is now compiled by default; > > > > - pool server is now compiled by default; > > > > - Fixed SQL_ATTR_LOGIN_TIMEOUT for ODBC; > > > > - Fixed large integer numbers for ODBC RPC constants; > > > > - Fixed encrypted logins if "auto" protocol version is used; > > > > - Support CS_TIMEOUT and CS_LOGIN_TIMEOUT properties under CTLibrary; > > > > - Added a dbacolname function in DBLibrary, similar to dbcolname but > > > > for compute columns (mainly for Sybase now, Microsoft removed > > > > support for compute columns); > > > > - NTLMv2 is now on by default. > > > > > > > > Implementation: > > > > - Improved UTF-8 performances; > > > > - Use more stdint.h style definitions (like uint32_t); > > > > - Use bool type instead of int; > > > > - pool server compile under Windows too (not as capable as Unix > > > > version); > > > > - CMake build is now able to do an installation; > > > > - Added a src/utils directory to collect all common code not strictly > > > > related to replacements or TDS; > > > > - Simplified makefiles; > > > > - Support CP1252 encoding in internal trivial iconv; > > > > - Better ODBC detection. Allows to specify a directory with > > > > --with-iodbc to specify custom iOBDC. > > > > > > > > > > > > Kind Regards, > > > > Frediano > > > > _______________________________________________ > > > > FreeTDS mailing list > > > > FreeTDS at lists.ibiblio.org > > > > https://lists.ibiblio.org/mailman/listinfo/freetds > > > > > > > > > > _______________________________________________ > > > FreeTDS mailing list > > > FreeTDS at lists.ibiblio.org > > > https://lists.ibiblio.org/mailman/listinfo/freetds > > _______________________________________________ > > FreeTDS mailing list > > FreeTDS at lists.ibiblio.org > > https://lists.ibiblio.org/mailman/listinfo/freetds > > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds From sf at 4js.com Tue Feb 19 12:51:32 2019 From: sf at 4js.com (Sebastien FLAESCH) Date: Tue, 19 Feb 2019 18:51:32 +0100 Subject: [freetds] Support for SQL Server 2019 Message-ID: <7b65aa9a-1bc1-3c31-327a-f3a707a70e3b@4js.com> Hi all, Is anyone testing FreeTDS with SQL Server 2019 CTP ? Seb From freddy77 at gmail.com Wed Feb 20 04:47:26 2019 From: freddy77 at gmail.com (Frediano Ziglio) Date: Wed, 20 Feb 2019 09:47:26 +0000 Subject: [freetds] FreeTDS 1.1 Release Candidate 2 - compiler warnings In-Reply-To: References: Message-ID: Nevermind, reproduced and fixed. Now doing some test on it. Frediano Il giorno mar 19 feb 2019 alle ore 08:28 Frediano Ziglio ha scritto: > > Hi, > can you try this? Should fix both error and md4/md5 warnings. > Download from http://ge.tt/7jeAtYu2, it's the first upload website I > found so check the hashes: > sha1 c5dab0b83ba917aad0595d0d6d8884d2ef788b33 freetds-1.1rc2.tar.bz2 > md5 7ce98e61d5490a421cab8a2b916fce90 freetds-1.1rc2.tar.bz2 > > Frediano > > Il giorno mar 19 feb 2019 alle ore 08:18 Mike Jetzer > ha scritto: > > > > Hopefully the compiler error will be corrected: > > > > gmake[4]: Entering directory `/tmp/freetds-1.1rc2/src/odbc' > > CC connectparams.lo > > connectparams.c:94:12: error: static declaration of > > 'SQLGetPrivateProfileString' follows non-static declaration > > static int SQLGetPrivateProfileString(LPCSTR pszSection, LPCSTR pszEntry, > > LPCSTR pszDefault, LPSTR pRetBuffer, int nRetBuffer, > > ^ > > In file included from ../../include/freetds/odbc.h:33:0, > > from connectparams.c:30: > > /usr/local/unixODBC-2.3.7/include/odbcinst.h:205:14: note: previous > > declaration of 'SQLGetPrivateProfileString' was here > > int INSTAPI SQLGetPrivateProfileString( LPCSTR lpszSection, > > ^ > > gmake[4]: [connectparams.lo] Error 1 (ignored) > > > > > > > > We do not have the RHEL-provided version of unixODBC installed, having > > instead compiled our own in /usr/local/unixODBC-2.3.7. > > > > We invoked configure as > > > > ./configure --prefix=/usr/local/freetds-1.1rc2 \ > > --with-unixodbc=/usr/local/unixODBC-2.3.7 > > > > > > The "configure" output for freetds-1.1rc2 notes > > > > checking for SQLGetPrivateProfileString in -lodbcinst... no > > > > > > Looking at config.log, I see that > > > > configure:19411: gcc -m32 -o conftest -g -O2 -DUNIXODBC -DHAVE_UNISTD_H > > -DHAVE_PWD_H -HAVE_SYS_TYPES_H -DHAVE_LONG_LONG -DSIZEOF_LONG_INT=4 > > -I/usr/local/unixODBC-2.3.7/include conftest.c -lodbcinst -lpthread >&5 > > > > > > So it looks like the failure occurs because configure is not adding an "-L" > > with the unixODBC library directory. > > > > Also in config.log, I see that odbc_config is properly reporting the > > --lib-prefix correctly: > > > > ODBC_CONFIG='/usr/local/unixODBC-2.3.7/bin/odbc_config' > > ODBC_FALSE='#' > > ODBC_INC='-I/usr/local/unixODBC-2.3.7/include' > > ODBC_LDFLAGS='-L/usr/local/unixODBC-2.3.7/lib -lodbc' > > > > > > I don't know enough about autoconf to debug this any farther. > > > > > > We are currently using freetds-1.00.97. When running that version's > > configure --with-unixodbc=/usr/local/unixODBC-2.3.7, I see that configure > > reports > > > > checking for SQLGetPrivateProfileString in -lodbcinst... yes > > > > and that config.log shows > > > > configure:19259: checking for SQLGetPrivateProfileString in -lodbcinst > > configure:19284: gcc -m32 -o conftest -g -O2 -DUNIXODBC -DHAVE_UNISTD_H > > -DHAVE_PWD_H -DHAVE_SYS_TYPES_H -DHAVE_LONG_LONG -DSIZEOF_LONG_INT=4 > > -I/usr/local/unixODBC-2.3.7/include -L/usr/local/unixODBC-2.3.7/lib > > conftest.c -lodbcinst -lpthread >&5 > > > > > > I see that the "configure" in freetds-1.00.97 put the unixODBC library > > directory directly in LDFLAGS, rather than having a separate ODBC_LDFLAGS, > > as noted in config.log: > > > > LDFLAGS=' -L/usr/local/unixODBC-2.3.7/lib' > > > > > > > > On Fri, Feb 15, 2019 at 1:39 PM Frediano Ziglio wrote: > > > > > Hi, > > > thanks, not an issue, just normal warnings, I don't plan to remove > > > them for version 1.1. > > > Some fixes are part of a large series I'm slowly integrating > > > > > > Regards, > > > Frediano > > > > > > Il giorno lun 11 feb 2019 alle ore 09:18 Sebastien FLAESCH > > > ha scritto: > > > > > > > > Attached, compiler warnings with gcc 8.2.0 ... > > > > > > > > Seb > > > > > > > > On 2/9/19 7:58 PM, Frediano Ziglio wrote: > > > > > Hi, > > > > > just another updated release candidate. > > > > > > > > > > Changes since previous release candidate: > > > > > - Project files for OpenVMS upgraded. Thanks to Craig for the quick > > > update; > > > > > - Updated documentation on protocol version and other minor changes; > > > > > - Cleaned some code for old protocols; > > > > > - Resolved some minor issues with CI and tests; > > > > > - CMake build (like autotools) now default to TDS protocol version > > > "auto"; > > > > > - Improved TDS protocol detection in case of failure. > > > > > > > > > > General release changes (as in NEWS file): > > > > > > > > > > > > > > > Summary of Changes in release 1.1 > > > > > -------------------------------------------- > > > > > User visible (not in a particular order): > > > > > - Changed default TDS protocol version during configure to "auto". > > > > > Versions 4.2 and 7.0 are no longer accepted for default, you may > > > > > still specify an explicit version to connect to obsolete servers > > > > > ("auto" won't attempt these versions); > > > > > - allows to disable TLS 1.0 support; > > > > > - pool server allows to specify different username/password for server > > > > > and clients allowing to hide internal server logins; > > > > > - tsql utility now send final partial query to server to avoid to have > > > > > to specify a final "GO" line to terminate commands; > > > > > - better support for Microsoft cluster, client will attempt multiple > > > > > connection to server at the same time if DNS reply multiple IPs; > > > > > - MONEY/SMALLMONEY types are now formated with 4 decimal digits to > > > > > avoid truncation; > > > > > - MARS support is now compiled by default; > > > > > - pool server is now compiled by default; > > > > > - Fixed SQL_ATTR_LOGIN_TIMEOUT for ODBC; > > > > > - Fixed large integer numbers for ODBC RPC constants; > > > > > - Fixed encrypted logins if "auto" protocol version is used; > > > > > - Support CS_TIMEOUT and CS_LOGIN_TIMEOUT properties under CTLibrary; > > > > > - Added a dbacolname function in DBLibrary, similar to dbcolname but > > > > > for compute columns (mainly for Sybase now, Microsoft removed > > > > > support for compute columns); > > > > > - NTLMv2 is now on by default. > > > > > > > > > > Implementation: > > > > > - Improved UTF-8 performances; > > > > > - Use more stdint.h style definitions (like uint32_t); > > > > > - Use bool type instead of int; > > > > > - pool server compile under Windows too (not as capable as Unix > > > > > version); > > > > > - CMake build is now able to do an installation; > > > > > - Added a src/utils directory to collect all common code not strictly > > > > > related to replacements or TDS; > > > > > - Simplified makefiles; > > > > > - Support CP1252 encoding in internal trivial iconv; > > > > > - Better ODBC detection. Allows to specify a directory with > > > > > --with-iodbc to specify custom iOBDC. > > > > > > > > > > > > > > > Kind Regards, > > > > > Frediano > > > > > _______________________________________________ > > > > > FreeTDS mailing list > > > > > FreeTDS at lists.ibiblio.org > > > > > https://lists.ibiblio.org/mailman/listinfo/freetds > > > > > > > > > > > > > _______________________________________________ > > > > FreeTDS mailing list > > > > FreeTDS at lists.ibiblio.org > > > > https://lists.ibiblio.org/mailman/listinfo/freetds > > > _______________________________________________ > > > FreeTDS mailing list > > > FreeTDS at lists.ibiblio.org > > > https://lists.ibiblio.org/mailman/listinfo/freetds > > > > > _______________________________________________ > > FreeTDS mailing list > > FreeTDS at lists.ibiblio.org > > https://lists.ibiblio.org/mailman/listinfo/freetds From mjetzer.cdc at gmail.com Tue Feb 19 09:32:32 2019 From: mjetzer.cdc at gmail.com (Mike Jetzer) Date: Tue, 19 Feb 2019 08:32:32 -0600 Subject: [freetds] FreeTDS 1.1 Release Candidate 2 - compiler warnings In-Reply-To: References: Message-ID: Yes, md4.c and md5.c errors have been corrected and not receiving a fatal error in connectparams.c regarding SQLGetPrivateProfileString(). However, "configure" is still not finding the libodbcinst.so. "configure" output: checking for SQLGetPrivateProfileString in -lodbcinst... no config.log: ODBC='' ODBCINST_LDFLAGS='' ODBC_CONFIG='/usr/local/unixODBC-2.3.7/bin/odbc_config' ODBC_FALSE='#' ODBC_INC='-I/usr/local/unixODBC-2.3.7/include' ODBC_LDFLAGS='-L/usr/local/unixODBC-2.3.7/lib -lodbc' ODBC_TRUE='' ODBC_WIDE_TESTS_FALSE='' ODBC_WIDE_TESTS_TRUE='#' . . . configure:19387: checking for SQLGetPrivateProfileString in -lodbcinst configure:19412: gcc -m32 -o conftest -g -O2 -DUNIXODBC -DHAVE_UNISTD_H -DHAVE_PWD_H -HAVE_SYS_TYPES_H -DHAVE_LONG_LONG -DSIZEOF_LONG_INT=4 -I/usr/local/unixODBC-2.3.7/include conftest.c -lodbcinst -lpthread >&5 /bin/ld: cannot find -lodbcinst But wouldn't it be more proper to properly locate the unixODBC libraries (as was done in freetds-1.00.97) rather than rename the FreeTDS implementation of SQLGetPrivateProfileString()? On Tue, Feb 19, 2019 at 2:28 AM Frediano Ziglio wrote: > Hi, > can you try this? Should fix both error and md4/md5 warnings. > Download from http://ge.tt/7jeAtYu2, it's the first upload website I > found so check the hashes: > sha1 c5dab0b83ba917aad0595d0d6d8884d2ef788b33 freetds-1.1rc2.tar.bz2 > md5 7ce98e61d5490a421cab8a2b916fce90 freetds-1.1rc2.tar.bz2 > > Frediano > > Il giorno mar 19 feb 2019 alle ore 08:18 Mike Jetzer > ha scritto: > > > > Hopefully the compiler error will be corrected: > > > > gmake[4]: Entering directory `/tmp/freetds-1.1rc2/src/odbc' > > CC connectparams.lo > > connectparams.c:94:12: error: static declaration of > > 'SQLGetPrivateProfileString' follows non-static declaration > > static int SQLGetPrivateProfileString(LPCSTR pszSection, LPCSTR > pszEntry, > > LPCSTR pszDefault, LPSTR pRetBuffer, int nRetBuffer, > > ^ > > In file included from ../../include/freetds/odbc.h:33:0, > > from connectparams.c:30: > > /usr/local/unixODBC-2.3.7/include/odbcinst.h:205:14: note: previous > > declaration of 'SQLGetPrivateProfileString' was here > > int INSTAPI SQLGetPrivateProfileString( LPCSTR lpszSection, > > ^ > > gmake[4]: [connectparams.lo] Error 1 (ignored) > > > > > > > > We do not have the RHEL-provided version of unixODBC installed, having > > instead compiled our own in /usr/local/unixODBC-2.3.7. > > > > We invoked configure as > > > > ./configure --prefix=/usr/local/freetds-1.1rc2 \ > > --with-unixodbc=/usr/local/unixODBC-2.3.7 > > > > > > The "configure" output for freetds-1.1rc2 notes > > > > checking for SQLGetPrivateProfileString in -lodbcinst... no > > > > > > Looking at config.log, I see that > > > > configure:19411: gcc -m32 -o conftest -g -O2 -DUNIXODBC -DHAVE_UNISTD_H > > -DHAVE_PWD_H -HAVE_SYS_TYPES_H -DHAVE_LONG_LONG -DSIZEOF_LONG_INT=4 > > -I/usr/local/unixODBC-2.3.7/include conftest.c -lodbcinst -lpthread > >&5 > > > > > > So it looks like the failure occurs because configure is not adding an > "-L" > > with the unixODBC library directory. > > > > Also in config.log, I see that odbc_config is properly reporting the > > --lib-prefix correctly: > > > > ODBC_CONFIG='/usr/local/unixODBC-2.3.7/bin/odbc_config' > > ODBC_FALSE='#' > > ODBC_INC='-I/usr/local/unixODBC-2.3.7/include' > > ODBC_LDFLAGS='-L/usr/local/unixODBC-2.3.7/lib -lodbc' > > > > > > I don't know enough about autoconf to debug this any farther. > > > > > > We are currently using freetds-1.00.97. When running that version's > > configure --with-unixodbc=/usr/local/unixODBC-2.3.7, I see that configure > > reports > > > > checking for SQLGetPrivateProfileString in -lodbcinst... yes > > > > and that config.log shows > > > > configure:19259: checking for SQLGetPrivateProfileString in -lodbcinst > > configure:19284: gcc -m32 -o conftest -g -O2 -DUNIXODBC -DHAVE_UNISTD_H > > -DHAVE_PWD_H -DHAVE_SYS_TYPES_H -DHAVE_LONG_LONG -DSIZEOF_LONG_INT=4 > > -I/usr/local/unixODBC-2.3.7/include -L/usr/local/unixODBC-2.3.7/lib > > conftest.c -lodbcinst -lpthread >&5 > > > > > > I see that the "configure" in freetds-1.00.97 put the unixODBC library > > directory directly in LDFLAGS, rather than having a separate > ODBC_LDFLAGS, > > as noted in config.log: > > > > LDFLAGS=' -L/usr/local/unixODBC-2.3.7/lib' > > > > > > > > On Fri, Feb 15, 2019 at 1:39 PM Frediano Ziglio > wrote: > > > > > Hi, > > > thanks, not an issue, just normal warnings, I don't plan to remove > > > them for version 1.1. > > > Some fixes are part of a large series I'm slowly integrating > > > > > > Regards, > > > Frediano > > > > > > Il giorno lun 11 feb 2019 alle ore 09:18 Sebastien FLAESCH > > > ha scritto: > > > > > > > > Attached, compiler warnings with gcc 8.2.0 ... > > > > > > > > Seb > > > > > > > > On 2/9/19 7:58 PM, Frediano Ziglio wrote: > > > > > Hi, > > > > > just another updated release candidate. > > > > > > > > > > Changes since previous release candidate: > > > > > - Project files for OpenVMS upgraded. Thanks to Craig for the quick > > > update; > > > > > - Updated documentation on protocol version and other minor > changes; > > > > > - Cleaned some code for old protocols; > > > > > - Resolved some minor issues with CI and tests; > > > > > - CMake build (like autotools) now default to TDS protocol version > > > "auto"; > > > > > - Improved TDS protocol detection in case of failure. > > > > > > > > > > General release changes (as in NEWS file): > > > > > > > > > > > > > > > Summary of Changes in release 1.1 > > > > > -------------------------------------------- > > > > > User visible (not in a particular order): > > > > > - Changed default TDS protocol version during configure to "auto". > > > > > Versions 4.2 and 7.0 are no longer accepted for default, you may > > > > > still specify an explicit version to connect to obsolete servers > > > > > ("auto" won't attempt these versions); > > > > > - allows to disable TLS 1.0 support; > > > > > - pool server allows to specify different username/password for > server > > > > > and clients allowing to hide internal server logins; > > > > > - tsql utility now send final partial query to server to avoid to > have > > > > > to specify a final "GO" line to terminate commands; > > > > > - better support for Microsoft cluster, client will attempt > multiple > > > > > connection to server at the same time if DNS reply multiple IPs; > > > > > - MONEY/SMALLMONEY types are now formated with 4 decimal digits to > > > > > avoid truncation; > > > > > - MARS support is now compiled by default; > > > > > - pool server is now compiled by default; > > > > > - Fixed SQL_ATTR_LOGIN_TIMEOUT for ODBC; > > > > > - Fixed large integer numbers for ODBC RPC constants; > > > > > - Fixed encrypted logins if "auto" protocol version is used; > > > > > - Support CS_TIMEOUT and CS_LOGIN_TIMEOUT properties under > CTLibrary; > > > > > - Added a dbacolname function in DBLibrary, similar to dbcolname > but > > > > > for compute columns (mainly for Sybase now, Microsoft removed > > > > > support for compute columns); > > > > > - NTLMv2 is now on by default. > > > > > > > > > > Implementation: > > > > > - Improved UTF-8 performances; > > > > > - Use more stdint.h style definitions (like uint32_t); > > > > > - Use bool type instead of int; > > > > > - pool server compile under Windows too (not as capable as Unix > > > > > version); > > > > > - CMake build is now able to do an installation; > > > > > - Added a src/utils directory to collect all common code not > strictly > > > > > related to replacements or TDS; > > > > > - Simplified makefiles; > > > > > - Support CP1252 encoding in internal trivial iconv; > > > > > - Better ODBC detection. Allows to specify a directory with > > > > > --with-iodbc to specify custom iOBDC. > > > > > > > > > > > > > > > Kind Regards, > > > > > Frediano > > > > > _______________________________________________ > > > > > FreeTDS mailing list > > > > > FreeTDS at lists.ibiblio.org > > > > > https://lists.ibiblio.org/mailman/listinfo/freetds > > > > > > > > > > > > > _______________________________________________ > > > > FreeTDS mailing list > > > > FreeTDS at lists.ibiblio.org > > > > https://lists.ibiblio.org/mailman/listinfo/freetds > > > _______________________________________________ > > > FreeTDS mailing list > > > FreeTDS at lists.ibiblio.org > > > https://lists.ibiblio.org/mailman/listinfo/freetds > > > > > _______________________________________________ > > FreeTDS mailing list > > FreeTDS at lists.ibiblio.org > > https://lists.ibiblio.org/mailman/listinfo/freetds > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds > From no-reply at appveyor.com Wed Feb 20 08:49:05 2019 From: no-reply at appveyor.com (AppVeyor) Date: Wed, 20 Feb 2019 13:49:05 +0000 Subject: [freetds] Build failed: freetds 1362 Message-ID: <20190220134905.1.1D7E017C6E130EEB@appveyor.com> From freddy77 at gmail.com Thu Feb 21 03:42:27 2019 From: freddy77 at gmail.com (Frediano Ziglio) Date: Thu, 21 Feb 2019 08:42:27 +0000 Subject: [freetds] FreeTDS 1.1 Release Candidate 3 Message-ID: Hi, just another updated release candidate. I expect this is the last release candidate. Changes since previous release candidate: - Fixed some build issues; - Added CS_CLIENTCHARSET option to ct_con_props; - Fix compilation in case --with-odbc-nodm is used (declaration clash); - Minor test improvements; - Prepare userguide source to be changed to XML instead of old SGML; - Fix a problem detecting SQLGetPrivateProfileString function if no standard directory was specified. General release changes (as in NEWS file): Summary of Changes in release 1.1 -------------------------------------------- User visible (not in a particular order): - Changed default TDS protocol version during configure to "auto". Versions 4.2 and 7.0 are no longer accepted for default, you may still specify an explicit version to connect to obsolete servers ("auto" won't attempt these versions); - allows to disable TLS 1.0 support; - pool server allows to specify different username/password for server and clients allowing to hide internal server logins; - tsql utility now send final partial query to server to avoid to have to specify a final "GO" line to terminate commands; - better support for Microsoft cluster, client will attempt multiple connection to server at the same time if DNS reply multiple IPs; - MONEY/SMALLMONEY types are now formated with 4 decimal digits to avoid truncation; - MARS support is now compiled by default; - pool server is now compiled by default; - Fixed SQL_ATTR_LOGIN_TIMEOUT for ODBC; - Fixed large integer numbers for ODBC RPC constants; - Fixed encrypted logins if "auto" protocol version is used; - Support CS_TIMEOUT and CS_LOGIN_TIMEOUT properties under CTLibrary; - Added a dbacolname function in DBLibrary, similar to dbcolname but for compute columns (mainly for Sybase now, Microsoft removed support for compute columns); - NTLMv2 is now on by default. Implementation: - Improved UTF-8 performances; - Use more stdint.h style definitions (like uint32_t); - Use bool type instead of int; - pool server compile under Windows too (not as capable as Unix version); - CMake build is now able to do an installation; - Added a src/utils directory to collect all common code not strictly related to replacements or TDS; - Simplified makefiles; - Support CP1252 encoding in internal trivial iconv; - Better ODBC detection. Allows to specify a directory with --with-iodbc to specify custom iOBDC. Kind Regards, Frediano From sf at 4js.com Thu Feb 21 04:24:27 2019 From: sf at 4js.com (Sebastien FLAESCH) Date: Thu, 21 Feb 2019 10:24:27 +0100 Subject: [freetds] FreeTDS 1.1 Release Candidate 3 In-Reply-To: References: Message-ID: Hi, Just recompiled 1.1rc3, make output with gcc 8.2.0 attached... We will run tests. Seb On 2/21/19 9:42 AM, Frediano Ziglio wrote: > Hi, > just another updated release candidate. > > I expect this is the last release candidate. > > Changes since previous release candidate: > - Fixed some build issues; > - Added CS_CLIENTCHARSET option to ct_con_props; > - Fix compilation in case --with-odbc-nodm is used (declaration clash); > - Minor test improvements; > - Prepare userguide source to be changed to XML instead of old SGML; > - Fix a problem detecting SQLGetPrivateProfileString function if no > standard directory was specified. > > > General release changes (as in NEWS file): > > > Summary of Changes in release 1.1 > -------------------------------------------- > User visible (not in a particular order): > - Changed default TDS protocol version during configure to "auto". > Versions 4.2 and 7.0 are no longer accepted for default, you may > still specify an explicit version to connect to obsolete servers > ("auto" won't attempt these versions); > - allows to disable TLS 1.0 support; > - pool server allows to specify different username/password for server > and clients allowing to hide internal server logins; > - tsql utility now send final partial query to server to avoid to have > to specify a final "GO" line to terminate commands; > - better support for Microsoft cluster, client will attempt multiple > connection to server at the same time if DNS reply multiple IPs; > - MONEY/SMALLMONEY types are now formated with 4 decimal digits to > avoid truncation; > - MARS support is now compiled by default; > - pool server is now compiled by default; > - Fixed SQL_ATTR_LOGIN_TIMEOUT for ODBC; > - Fixed large integer numbers for ODBC RPC constants; > - Fixed encrypted logins if "auto" protocol version is used; > - Support CS_TIMEOUT and CS_LOGIN_TIMEOUT properties under CTLibrary; > - Added a dbacolname function in DBLibrary, similar to dbcolname but > for compute columns (mainly for Sybase now, Microsoft removed > support for compute columns); > - NTLMv2 is now on by default. > > Implementation: > - Improved UTF-8 performances; > - Use more stdint.h style definitions (like uint32_t); > - Use bool type instead of int; > - pool server compile under Windows too (not as capable as Unix > version); > - CMake build is now able to do an installation; > - Added a src/utils directory to collect all common code not strictly > related to replacements or TDS; > - Simplified makefiles; > - Support CP1252 encoding in internal trivial iconv; > - Better ODBC detection. Allows to specify a directory with > --with-iodbc to specify custom iOBDC. > > > Kind Regards, > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds > -------------- next part -------------- A non-text attachment was scrubbed... Name: freetds-1.1rc3-make.log Type: text/x-log Size: 25090 bytes Desc: not available URL: From no-reply at appveyor.com Thu Feb 21 04:39:24 2019 From: no-reply at appveyor.com (AppVeyor) Date: Thu, 21 Feb 2019 09:39:24 +0000 Subject: [freetds] Build failed: freetds 1364 Message-ID: <20190221093924.1.D28C34BB41A1ECA5@appveyor.com> From sf at 4js.com Thu Feb 21 05:07:05 2019 From: sf at 4js.com (Sebastien FLAESCH) Date: Thu, 21 Feb 2019 11:07:05 +0100 Subject: [freetds] FreeTDS 1.1 Release Candidate 3 In-Reply-To: References: Message-ID: Hi, Just executed our QA tests with 1.1.rc3, no issue detected. Seb On 2/21/19 9:42 AM, Frediano Ziglio wrote: > Hi, > just another updated release candidate. > > I expect this is the last release candidate. > > Changes since previous release candidate: > - Fixed some build issues; > - Added CS_CLIENTCHARSET option to ct_con_props; > - Fix compilation in case --with-odbc-nodm is used (declaration clash); > - Minor test improvements; > - Prepare userguide source to be changed to XML instead of old SGML; > - Fix a problem detecting SQLGetPrivateProfileString function if no > standard directory was specified. > > > General release changes (as in NEWS file): > > > Summary of Changes in release 1.1 > -------------------------------------------- > User visible (not in a particular order): > - Changed default TDS protocol version during configure to "auto". > Versions 4.2 and 7.0 are no longer accepted for default, you may > still specify an explicit version to connect to obsolete servers > ("auto" won't attempt these versions); > - allows to disable TLS 1.0 support; > - pool server allows to specify different username/password for server > and clients allowing to hide internal server logins; > - tsql utility now send final partial query to server to avoid to have > to specify a final "GO" line to terminate commands; > - better support for Microsoft cluster, client will attempt multiple > connection to server at the same time if DNS reply multiple IPs; > - MONEY/SMALLMONEY types are now formated with 4 decimal digits to > avoid truncation; > - MARS support is now compiled by default; > - pool server is now compiled by default; > - Fixed SQL_ATTR_LOGIN_TIMEOUT for ODBC; > - Fixed large integer numbers for ODBC RPC constants; > - Fixed encrypted logins if "auto" protocol version is used; > - Support CS_TIMEOUT and CS_LOGIN_TIMEOUT properties under CTLibrary; > - Added a dbacolname function in DBLibrary, similar to dbcolname but > for compute columns (mainly for Sybase now, Microsoft removed > support for compute columns); > - NTLMv2 is now on by default. > > Implementation: > - Improved UTF-8 performances; > - Use more stdint.h style definitions (like uint32_t); > - Use bool type instead of int; > - pool server compile under Windows too (not as capable as Unix > version); > - CMake build is now able to do an installation; > - Added a src/utils directory to collect all common code not strictly > related to replacements or TDS; > - Simplified makefiles; > - Support CP1252 encoding in internal trivial iconv; > - Better ODBC detection. Allows to specify a directory with > --with-iodbc to specify custom iOBDC. > > > Kind Regards, > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds > From sf at 4js.com Thu Feb 21 09:54:05 2019 From: sf at 4js.com (Sebastien FLAESCH) Date: Thu, 21 Feb 2019 15:54:05 +0100 Subject: [freetds] SQL Server 2019: CHAR(N) using UTF-8 is seen as SQL_NVARCHAR by SQLDescribeCol() Message-ID: <1db01373-3210-9dbb-e073-78ab42c7729b@4js.com> Testing FreeTDS 1.1rc3 with SQL Server 2019: I get an unexpected SQL type code with a CHAR(10) column, when the database collation is using UTF-8. Instead of SQL_CHAR (or SQL_WCHAR), I get SQL_WVARCHAR. I have created a database with this collation: Latin1_General_100_CI_AS_SC_UTF8 Then created a table like this: CREATE TABLE mytab1 ( col1 CHAR(10) ) and inserted a row: INSERT INTO mytab1 VALUES ( 'abc' ) Then in the ODBC program: SQLExecDirect(.."SELECT * FROM mytab1"..) SQLDescribCol(...) TDSDUMP shows: token.c:1541:tds7_get_data_info: colname = col1 type = 39 (varchar) server's type = 231 (x UCS-2 varchar) <-- 231 ? column_varint_size = 2 column_size = 20 (20 on server) The same program, connecting to SQL Server 2017 (were DB collation is Latin1 without UTF-8): token.c:1541:tds7_get_data_info: colname = col1 type = 47 (char) server's type = 175 (xchar) <-- 175 column_varint_size = 2 column_size = 10 (10 on server) With SQL Server 2019, when using another collation (non-UTF-8) CREATE TABLE mytab2 ( col1 CHAR(10) COLLATE Latin1_General_CI_AS ) I get the expected tds type code... Seb From freddy77 at gmail.com Fri Feb 22 05:15:37 2019 From: freddy77 at gmail.com (Frediano Ziglio) Date: Fri, 22 Feb 2019 10:15:37 +0000 Subject: [freetds] SQL Server 2019: CHAR(N) using UTF-8 is seen as SQL_NVARCHAR by SQLDescribeCol() In-Reply-To: <1db01373-3210-9dbb-e073-78ab42c7729b@4js.com> References: <1db01373-3210-9dbb-e073-78ab42c7729b@4js.com> Message-ID: Il giorno gio 21 feb 2019 alle ore 14:54 Sebastien FLAESCH ha scritto: > > Testing FreeTDS 1.1rc3 with SQL Server 2019: > > I get an unexpected SQL type code with a CHAR(10) column, when the > database collation is using UTF-8. > > Instead of SQL_CHAR (or SQL_WCHAR), I get SQL_WVARCHAR. > > I have created a database with this collation: > > Latin1_General_100_CI_AS_SC_UTF8 > > Then created a table like this: > > CREATE TABLE mytab1 ( col1 CHAR(10) ) > > and inserted a row: > > INSERT INTO mytab1 VALUES ( 'abc' ) > > Then in the ODBC program: > > SQLExecDirect(.."SELECT * FROM mytab1"..) > SQLDescribCol(...) > > TDSDUMP shows: > > token.c:1541:tds7_get_data_info: > colname = col1 > type = 39 (varchar) > server's type = 231 (x UCS-2 varchar) <-- 231 ? > column_varint_size = 2 > column_size = 20 (20 on server) > > > The same program, connecting to SQL Server 2017 (were DB collation is Latin1 > without UTF-8): > > > token.c:1541:tds7_get_data_info: > colname = col1 > type = 47 (char) > server's type = 175 (xchar) <-- 175 > column_varint_size = 2 > column_size = 10 (10 on server) > > With SQL Server 2019, when using another collation (non-UTF-8) > > CREATE TABLE mytab2 ( col1 CHAR(10) COLLATE Latin1_General_CI_AS ) > > I get the expected tds type code... > > Seb > I had a quick look at the Microsoft TDS document, there seems to be no update for 2019. Maybe they are waiting for the final release. But is also possible that they are not changing the protocol and they convert the column as you seem to describe. Maybe there's a new usertype associated to the column. Or maybe the server uses another way to detect if the client support the new collations. Frediano From mjetzer.cdc at gmail.com Mon Feb 25 10:15:33 2019 From: mjetzer.cdc at gmail.com (Mike Jetzer) Date: Mon, 25 Feb 2019 09:15:33 -0600 Subject: [freetds] FreeTDS 1.1 Release Candidate 3 In-Reply-To: References: Message-ID: I've confirmed that the SQLGetPrivateProfileString() has been been resolved, and that the symbol is properly being located in the non-OS-provided unixODBC, as it was in older 1.0.x versions. The md4.c/md5.c issues are also still resolved. As expected (you had indicated that they were "expected" and that you planned on not removing them for 1.1), there are still a number of "variable set but not used", "enumeration value not handled in switch", and "variable may be used uninitialized in this function" when compiled on Red Hat Enterprise Linux 7 with gcc-4.8.5. On Thu, Feb 21, 2019 at 2:42 AM Frediano Ziglio wrote: > Hi, > just another updated release candidate. > > I expect this is the last release candidate. > > Changes since previous release candidate: > - Fixed some build issues; > - Added CS_CLIENTCHARSET option to ct_con_props; > - Fix compilation in case --with-odbc-nodm is used (declaration clash); > - Minor test improvements; > - Prepare userguide source to be changed to XML instead of old SGML; > - Fix a problem detecting SQLGetPrivateProfileString function if no > standard directory was specified. > > > General release changes (as in NEWS file): > > > Summary of Changes in release 1.1 > -------------------------------------------- > User visible (not in a particular order): > - Changed default TDS protocol version during configure to "auto". > Versions 4.2 and 7.0 are no longer accepted for default, you may > still specify an explicit version to connect to obsolete servers > ("auto" won't attempt these versions); > - allows to disable TLS 1.0 support; > - pool server allows to specify different username/password for server > and clients allowing to hide internal server logins; > - tsql utility now send final partial query to server to avoid to have > to specify a final "GO" line to terminate commands; > - better support for Microsoft cluster, client will attempt multiple > connection to server at the same time if DNS reply multiple IPs; > - MONEY/SMALLMONEY types are now formated with 4 decimal digits to > avoid truncation; > - MARS support is now compiled by default; > - pool server is now compiled by default; > - Fixed SQL_ATTR_LOGIN_TIMEOUT for ODBC; > - Fixed large integer numbers for ODBC RPC constants; > - Fixed encrypted logins if "auto" protocol version is used; > - Support CS_TIMEOUT and CS_LOGIN_TIMEOUT properties under CTLibrary; > - Added a dbacolname function in DBLibrary, similar to dbcolname but > for compute columns (mainly for Sybase now, Microsoft removed > support for compute columns); > - NTLMv2 is now on by default. > > Implementation: > - Improved UTF-8 performances; > - Use more stdint.h style definitions (like uint32_t); > - Use bool type instead of int; > - pool server compile under Windows too (not as capable as Unix > version); > - CMake build is now able to do an installation; > - Added a src/utils directory to collect all common code not strictly > related to replacements or TDS; > - Simplified makefiles; > - Support CP1252 encoding in internal trivial iconv; > - Better ODBC detection. Allows to specify a directory with > --with-iodbc to specify custom iOBDC. > > > Kind Regards, > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds > From sf at 4js.com Thu Feb 21 09:16:57 2019 From: sf at 4js.com (Sebastien FLAESCH) Date: Thu, 21 Feb 2019 15:16:57 +0100 Subject: [freetds] SQL Server 2019: CHAR(N) using UTF-8 is seen as SQL_NVARCHAR by SQLDescribeCol() Message-ID: <1609207a-0a70-5c44-cfd4-4dcbdf14dd37@4js.com> Testing FreeTDS 1.1rc3 with SQL Server 2019: I get an unexpected SQL type code with a CHAR(10) column, when the database collation is using UTF-8. Instead of SQL_CHAR (or SQL_WCHAR), I get SQL_WVARCHAR. I have created a database with this collation: Latin1_General_100_CI_AS_SC_UTF8 Then created a table like this: CREATE TABLE mytab1 ( col1 CHAR(10) ) and inserted a row: INSERT INTO mytab1 VALUES ( 'abc' ) Then in the ODBC program: SQLExecDirect(.."SELECT * FROM mytab1"..) SQLDescribCol(...) Check the TDSDUMP trace in attachment (freetds-2019-1.log) token.c:1541:tds7_get_data_info: colname = col1 type = 39 (varchar) server's type = 231 (x UCS-2 varchar) <-- 231 ? column_varint_size = 2 column_size = 20 (20 on server) The same program, connecting to SQL Server 2017 (were DB collation is Latin1 without UTF-8): token.c:1541:tds7_get_data_info: colname = col1 type = 47 (char) server's type = 175 (xchar) <-- 175 column_varint_size = 2 column_size = 10 (10 on server) With SQL Server 2019, when using another collation (non-UTF-8) CREATE TABLE mytab2 ( col1 CHAR(10) COLLATE Latin1_General_CI_AS ) I get the expected tds type code... Seb -------------- next part -------------- A non-text attachment was scrubbed... Name: freetds-2017.log Type: text/x-log Size: 41845 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freetds-2019-1.log Type: text/x-log Size: 33220 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freetds-2019-2.log Type: text/x-log Size: 29555 bytes Desc: not available URL: From TilleA at rki.de Tue Feb 26 10:52:04 2019 From: TilleA at rki.de (Tille, Andreas) Date: Tue, 26 Feb 2019 15:52:04 +0000 Subject: [freetds] Login failed. The login is from an untrusted domain and cannot be used with Integrated authentication. Message-ID: <1055d37ebc624eb597feb41032ffab02@EXCH01.rki.local> Hi, I'm accessing an MSSQL server successfully since a long time. Now this server was configured to encrypted connections and I get: $ sqsh -w 256 -h -S server -U domain\\user -D database sqsh-2.5.16.1 Copyright (C) 1995-2001 Scott C. Gray Portions Copyright (C) 2004-2014 Michael Peppler and Martin Wesdorp This is free software with ABSOLUTELY NO WARRANTY For more information type '\warranty' Msg 18452, Level 14, State 1 Server ' server', Line 1 Login failed. The login is from an untrusted domain and cannot be used with Integrated authentication. Open Client Message Layer 0, Origin 0, Severity 78, Number 34 Adaptive Server connection failed I'm using a backport of the latest Debian packages of sqsh and freetds in unstable on a Debian stretch system. This is the change I did in /etc/freetds: diff --git a/freetds/freetds.conf b/freetds/freetds.conf index 1f5f633..f38864b 100644 --- a/freetds/freetds.conf +++ b/freetds/freetds.conf @@ -13,6 +13,7 @@ ; tds version = 4.2 tds version = 8.0 client charset = UTF-8 + encryption = require # Whether to write a TDSDUMP file for diagnostic purposes # (setting this to /tmp is insecure on a multi-user system) I did no other changes to the configuration of freetds. Is there any description what to do to successfully access a MSSQL server that is configured to enforce encryption? I've found some hints to ssltunnel but I doubt that this should be a proper solution. Any hint would be welcome, Andreas. From freddy77 at gmail.com Wed Feb 27 03:50:10 2019 From: freddy77 at gmail.com (Frediano Ziglio) Date: Wed, 27 Feb 2019 08:50:10 +0000 Subject: [freetds] Login failed. The login is from an untrusted domain and cannot be used with Integrated authentication. In-Reply-To: <1055d37ebc624eb597feb41032ffab02@EXCH01.rki.local> References: <1055d37ebc624eb597feb41032ffab02@EXCH01.rki.local> Message-ID: Il giorno mar 26 feb 2019 alle ore 15:59 Tille, Andreas ha scritto: > > Hi, > I'm accessing an MSSQL server successfully since a long time. Now this server was configured to encrypted connections and I get: > > $ sqsh -w 256 -h -S server -U domain\\user -D database > sqsh-2.5.16.1 Copyright (C) 1995-2001 Scott C. Gray > Portions Copyright (C) 2004-2014 Michael Peppler and Martin Wesdorp > This is free software with ABSOLUTELY NO WARRANTY > For more information type '\warranty' > Msg 18452, Level 14, State 1 > Server ' server', Line 1 > Login failed. The login is from an untrusted domain and cannot be used with Integrated authentication. > Open Client Message > Layer 0, Origin 0, Severity 78, Number 34 > Adaptive Server connection failed > > > I'm using a backport of the latest Debian packages of sqsh and freetds in unstable on a Debian stretch system. This is the change I did in /etc/freetds: > I would try to make tsql works first. > diff --git a/freetds/freetds.conf b/freetds/freetds.conf > index 1f5f633..f38864b 100644 > --- a/freetds/freetds.conf > +++ b/freetds/freetds.conf > @@ -13,6 +13,7 @@ > ; tds version = 4.2 > tds version = 8.0 8.0? Still? See http://www.freetds.org/userguide/choosingtdsprotocol.htm. Also check http://www.freetds.org/userguide/freetdsconf.htm. > client charset = UTF-8 > + encryption = require > One option that could make a difference is also "use ntlmv2", try to set to yes or no (in Debian the default should be still no). > # Whether to write a TDSDUMP file for diagnostic purposes > # (setting this to /tmp is insecure on a multi-user system) > > > I did no other changes to the configuration of freetds. Is there any description what to do to successfully access a MSSQL server that is configured to enforce encryption? I've found some hints to ssltunnel but I doubt that this should be a proper solution. > > Any hint would be welcome, Andreas. See also http://www.freetds.org/userguide/serverthere.htm and http://www.freetds.org/userguide/logging.htm. Frediano From freddy77 at gmail.com Wed Feb 27 09:08:16 2019 From: freddy77 at gmail.com (Frediano Ziglio) Date: Wed, 27 Feb 2019 14:08:16 +0000 Subject: [freetds] SQL Server 2019: CHAR(N) using UTF-8 is seen as SQL_NVARCHAR by SQLDescribeCol() In-Reply-To: <1609207a-0a70-5c44-cfd4-4dcbdf14dd37@4js.com> References: <1609207a-0a70-5c44-cfd4-4dcbdf14dd37@4js.com> Message-ID: Hi, I would try to use TDS 7.4, not 7.3. Also I would try to use Microsoft ODBC driver and a network analyzer (like wireshark). Regards, Frediano Il giorno mar 26 feb 2019 alle ore 11:26 Sebastien FLAESCH ha scritto: > > Testing FreeTDS 1.1rc3 with SQL Server 2019: > > I get an unexpected SQL type code with a CHAR(10) column, when the > database collation is using UTF-8. > > Instead of SQL_CHAR (or SQL_WCHAR), I get SQL_WVARCHAR. > > I have created a database with this collation: > > Latin1_General_100_CI_AS_SC_UTF8 > > Then created a table like this: > > CREATE TABLE mytab1 ( col1 CHAR(10) ) > > and inserted a row: > > INSERT INTO mytab1 VALUES ( 'abc' ) > > Then in the ODBC program: > > SQLExecDirect(.."SELECT * FROM mytab1"..) > SQLDescribCol(...) > > Check the TDSDUMP trace in attachment (freetds-2019-1.log) > > token.c:1541:tds7_get_data_info: > colname = col1 > type = 39 (varchar) > server's type = 231 (x UCS-2 varchar) <-- 231 ? > column_varint_size = 2 > column_size = 20 (20 on server) > > > The same program, connecting to SQL Server 2017 (were DB collation is Latin1 > without UTF-8): > > > token.c:1541:tds7_get_data_info: > colname = col1 > type = 47 (char) > server's type = 175 (xchar) <-- 175 > column_varint_size = 2 > column_size = 10 (10 on server) > > With SQL Server 2019, when using another collation (non-UTF-8) > > CREATE TABLE mytab2 ( col1 CHAR(10) COLLATE Latin1_General_CI_AS ) > > I get the expected tds type code... > > Seb > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds From sf at 4js.com Wed Feb 27 10:27:40 2019 From: sf at 4js.com (Sebastien FLAESCH) Date: Wed, 27 Feb 2019 16:27:40 +0100 Subject: [freetds] SQL Server 2019: CHAR(N) using UTF-8 is seen as SQL_NVARCHAR by SQLDescribeCol() In-Reply-To: References: <1609207a-0a70-5c44-cfd4-4dcbdf14dd37@4js.com> Message-ID: <4110fdf8-6ea9-c671-1d14-4176342c59f8@4js.com> Hi, Just tried with TDS 7.4, it did not help. I have tested the MS ODBC driver 17.3.1.1, it works as expected ( I get 1/SQL_CHAR from SQLDescribeCol() ) You may know that it's very easy to setup an SQL Server 2019 with docker, do you? Cheers, Seb On 2/27/19 3:08 PM, Frediano Ziglio wrote: > Hi, > I would try to use TDS 7.4, not 7.3. > Also I would try to use Microsoft ODBC driver and a network analyzer > (like wireshark). > > Regards, > Frediano > > Il giorno mar 26 feb 2019 alle ore 11:26 Sebastien FLAESCH > ha scritto: >> >> Testing FreeTDS 1.1rc3 with SQL Server 2019: >> >> I get an unexpected SQL type code with a CHAR(10) column, when the >> database collation is using UTF-8. >> >> Instead of SQL_CHAR (or SQL_WCHAR), I get SQL_WVARCHAR. >> >> I have created a database with this collation: >> >> Latin1_General_100_CI_AS_SC_UTF8 >> >> Then created a table like this: >> >> CREATE TABLE mytab1 ( col1 CHAR(10) ) >> >> and inserted a row: >> >> INSERT INTO mytab1 VALUES ( 'abc' ) >> >> Then in the ODBC program: >> >> SQLExecDirect(.."SELECT * FROM mytab1"..) >> SQLDescribCol(...) >> >> Check the TDSDUMP trace in attachment (freetds-2019-1.log) >> >> token.c:1541:tds7_get_data_info: >> colname = col1 >> type = 39 (varchar) >> server's type = 231 (x UCS-2 varchar) <-- 231 ? >> column_varint_size = 2 >> column_size = 20 (20 on server) >> >> >> The same program, connecting to SQL Server 2017 (were DB collation is Latin1 >> without UTF-8): >> >> >> token.c:1541:tds7_get_data_info: >> colname = col1 >> type = 47 (char) >> server's type = 175 (xchar) <-- 175 >> column_varint_size = 2 >> column_size = 10 (10 on server) >> >> With SQL Server 2019, when using another collation (non-UTF-8) >> >> CREATE TABLE mytab2 ( col1 CHAR(10) COLLATE Latin1_General_CI_AS ) >> >> I get the expected tds type code... >> >> Seb >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> https://lists.ibiblio.org/mailman/listinfo/freetds > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds > From cejackson51 at gmail.com Wed Feb 27 10:32:28 2019 From: cejackson51 at gmail.com (Craig Jackson) Date: Wed, 27 Feb 2019 10:32:28 -0500 Subject: [freetds] SQL Server 2019: CHAR(N) using UTF-8 is seen as SQL_NVARCHAR by SQLDescribeCol() In-Reply-To: <4110fdf8-6ea9-c671-1d14-4176342c59f8@4js.com> References: <1609207a-0a70-5c44-cfd4-4dcbdf14dd37@4js.com> <4110fdf8-6ea9-c671-1d14-4176342c59f8@4js.com> Message-ID: I don't know anything about SQL Server 2019, but if they added the option to allow UTF-8 encoding of character strings, it would seem natural that said strings would be variable-length, even if declared CHAR(n). Strings encoded in UTF-8 are inherently variable length. Craig Jackson On Wed, Feb 27, 2019 at 10:27 AM Sebastien FLAESCH wrote: > Hi, > > Just tried with TDS 7.4, it did not help. > > I have tested the MS ODBC driver 17.3.1.1, it works as expected > ( I get 1/SQL_CHAR from SQLDescribeCol() ) > > You may know that it's very easy to setup an SQL Server 2019 with > docker, do you? > > Cheers, > Seb > > On 2/27/19 3:08 PM, Frediano Ziglio wrote: > > Hi, > > I would try to use TDS 7.4, not 7.3. > > Also I would try to use Microsoft ODBC driver and a network analyzer > > (like wireshark). > > > > Regards, > > Frediano > > > > Il giorno mar 26 feb 2019 alle ore 11:26 Sebastien FLAESCH > > ha scritto: > >> > >> Testing FreeTDS 1.1rc3 with SQL Server 2019: > >> > >> I get an unexpected SQL type code with a CHAR(10) column, when the > >> database collation is using UTF-8. > >> > >> Instead of SQL_CHAR (or SQL_WCHAR), I get SQL_WVARCHAR. > >> > >> I have created a database with this collation: > >> > >> Latin1_General_100_CI_AS_SC_UTF8 > >> > >> Then created a table like this: > >> > >> CREATE TABLE mytab1 ( col1 CHAR(10) ) > >> > >> and inserted a row: > >> > >> INSERT INTO mytab1 VALUES ( 'abc' ) > >> > >> Then in the ODBC program: > >> > >> SQLExecDirect(.."SELECT * FROM mytab1"..) > >> SQLDescribCol(...) > >> > >> Check the TDSDUMP trace in attachment (freetds-2019-1.log) > >> > >> token.c:1541:tds7_get_data_info: > >> colname = col1 > >> type = 39 (varchar) > >> server's type = 231 (x UCS-2 varchar) <-- 231 ? > >> column_varint_size = 2 > >> column_size = 20 (20 on server) > >> > >> > >> The same program, connecting to SQL Server 2017 (were DB collation is > Latin1 > >> without UTF-8): > >> > >> > >> token.c:1541:tds7_get_data_info: > >> colname = col1 > >> type = 47 (char) > >> server's type = 175 (xchar) <-- 175 > >> column_varint_size = 2 > >> column_size = 10 (10 on server) > >> > >> With SQL Server 2019, when using another collation (non-UTF-8) > >> > >> CREATE TABLE mytab2 ( col1 CHAR(10) COLLATE Latin1_General_CI_AS ) > >> > >> I get the expected tds type code... > >> > >> Seb > >> _______________________________________________ > >> FreeTDS mailing list > >> FreeTDS at lists.ibiblio.org > >> https://lists.ibiblio.org/mailman/listinfo/freetds > > _______________________________________________ > > FreeTDS mailing list > > FreeTDS at lists.ibiblio.org > > https://lists.ibiblio.org/mailman/listinfo/freetds > > > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds > From sf at 4js.com Thu Feb 28 05:50:09 2019 From: sf at 4js.com (Sebastien FLAESCH) Date: Thu, 28 Feb 2019 11:50:09 +0100 Subject: [freetds] SQL Server 2019: CHAR(N) using UTF-8 is seen as SQL_NVARCHAR by SQLDescribeCol() In-Reply-To: References: <1609207a-0a70-5c44-cfd4-4dcbdf14dd37@4js.com> <4110fdf8-6ea9-c671-1d14-4176342c59f8@4js.com> Message-ID: <46ec34f9-2eca-4bc1-11d8-a2268fb3181a@4js.com> Hello Craig, I don't think so: An ODBC program should be able to properly identify (as much as possible) the original database type used for a column. We must also distinguish the concept of "variable length" regarding the number of bytes used to encode characters, versus the actual length of the string in character units. Plus the fact that [N]CHAR columns can be blank-padded, while [N]VARCHAR columns are not and store the actual number of trailing white spaces of the string, try for ex: create table tab1 ( c1 char(10), c2 varchar(10) ) insert into tab1 values ( 'abc', 'abc ' ) select '['+c1+']', '['+c2+']' from tab1 You will see: [abc ] [abc ] (check SET ANSI_PADDING ON/OFF) ... UTF-8 is a variable-width encoding: a => needs 1 byte ? => needs 2 bytes ? => needs 3 bytes ... etc (there can be more than 3 bytes) In that context, one can see a "variable length" in byte units... But when counting in characters, 'a??' is 3 characters, no matter the encoding used to store this string. You have also the concept of byte-length semantics versus char-length semantics: When creating a CHAR(10) is this 10 bytes or 10 characters? Depending on the database brand, it's bytes (SQL Server), characters (PostgreSQL), or it can even be a mix and specified explicitly (like in Oracle DB). Note: You have then also the concept of "width" or "number of columns": A latin character takes one column, while an Asian logogram takes 2. See wcwidth() for more details. ... In SQL Server, NCHAR and NVARCHAR can store UTF-16 when the SC modifier is used in the database collation (they store UCS-2 when no SC is used) In UTF-16, a first range of characters are encoded on 2 bytes, but you can have "surrogate pairs" encoded on 4 bytes (two 16-bit code units). In your logic, the NCHAR/UTF-16 type could also be considered as a "variable length" type and SQLDecribeCol() could return SQL_WVARCHAR instead of SQL_WCHAR... It must not and does not. Cheers, Seb On 2/27/19 4:32 PM, Craig Jackson wrote: > I don't know anything about SQL Server 2019, but if they added the option > to allow UTF-8 encoding of character strings, it would seem natural that > said strings would be variable-length, even if declared CHAR(n). Strings > encoded in UTF-8 are inherently variable length. > > Craig Jackson > > On Wed, Feb 27, 2019 at 10:27 AM Sebastien FLAESCH wrote: > >> Hi, >> >> Just tried with TDS 7.4, it did not help. >> >> I have tested the MS ODBC driver 17.3.1.1, it works as expected >> ( I get 1/SQL_CHAR from SQLDescribeCol() ) >> >> You may know that it's very easy to setup an SQL Server 2019 with >> docker, do you? >> >> Cheers, >> Seb >> >> On 2/27/19 3:08 PM, Frediano Ziglio wrote: >>> Hi, >>> I would try to use TDS 7.4, not 7.3. >>> Also I would try to use Microsoft ODBC driver and a network analyzer >>> (like wireshark). >>> >>> Regards, >>> Frediano >>> >>> Il giorno mar 26 feb 2019 alle ore 11:26 Sebastien FLAESCH >>> ha scritto: >>>> >>>> Testing FreeTDS 1.1rc3 with SQL Server 2019: >>>> >>>> I get an unexpected SQL type code with a CHAR(10) column, when the >>>> database collation is using UTF-8. >>>> >>>> Instead of SQL_CHAR (or SQL_WCHAR), I get SQL_WVARCHAR. >>>> >>>> I have created a database with this collation: >>>> >>>> Latin1_General_100_CI_AS_SC_UTF8 >>>> >>>> Then created a table like this: >>>> >>>> CREATE TABLE mytab1 ( col1 CHAR(10) ) >>>> >>>> and inserted a row: >>>> >>>> INSERT INTO mytab1 VALUES ( 'abc' ) >>>> >>>> Then in the ODBC program: >>>> >>>> SQLExecDirect(.."SELECT * FROM mytab1"..) >>>> SQLDescribCol(...) >>>> >>>> Check the TDSDUMP trace in attachment (freetds-2019-1.log) >>>> >>>> token.c:1541:tds7_get_data_info: >>>> colname = col1 >>>> type = 39 (varchar) >>>> server's type = 231 (x UCS-2 varchar) <-- 231 ? >>>> column_varint_size = 2 >>>> column_size = 20 (20 on server) >>>> >>>> >>>> The same program, connecting to SQL Server 2017 (were DB collation is >> Latin1 >>>> without UTF-8): >>>> >>>> >>>> token.c:1541:tds7_get_data_info: >>>> colname = col1 >>>> type = 47 (char) >>>> server's type = 175 (xchar) <-- 175 >>>> column_varint_size = 2 >>>> column_size = 10 (10 on server) >>>> >>>> With SQL Server 2019, when using another collation (non-UTF-8) >>>> >>>> CREATE TABLE mytab2 ( col1 CHAR(10) COLLATE Latin1_General_CI_AS ) >>>> >>>> I get the expected tds type code... >>>> >>>> Seb >>>> _______________________________________________ >>>> FreeTDS mailing list >>>> FreeTDS at lists.ibiblio.org >>>> https://lists.ibiblio.org/mailman/listinfo/freetds >>> _______________________________________________ >>> FreeTDS mailing list >>> FreeTDS at lists.ibiblio.org >>> https://lists.ibiblio.org/mailman/listinfo/freetds >>> >> >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> https://lists.ibiblio.org/mailman/listinfo/freetds >> > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds > From freddy77 at gmail.com Thu Feb 28 05:56:03 2019 From: freddy77 at gmail.com (Frediano Ziglio) Date: Thu, 28 Feb 2019 10:56:03 +0000 Subject: [freetds] SQL Server 2019: CHAR(N) using UTF-8 is seen as SQL_NVARCHAR by SQLDescribeCol() In-Reply-To: <46ec34f9-2eca-4bc1-11d8-a2268fb3181a@4js.com> References: <1609207a-0a70-5c44-cfd4-4dcbdf14dd37@4js.com> <4110fdf8-6ea9-c671-1d14-4176342c59f8@4js.com> <46ec34f9-2eca-4bc1-11d8-a2268fb3181a@4js.com> Message-ID: Hi, so, installed a sql 2019 and tried some queries. Using the driver provided inside the docker image the "abc" is returned as "abc ", so the CHAR(10) are returned encoded in UTF-8 and the "10" is just the number of bytes. Now, why the server decided to return UTF-8 and not convert to NVARCHAR (which make sense to me for old clients) it's the issue. Maybe they bump the protocol version, maybe they are using some other flags/version (like client version passes through the pre-login). Unfortunately the login is encrypted so I'll have to dig a bit more (well, just question of setup and use the bounce utility, not sure if it supports pre-login). Frediano Il giorno gio 28 feb 2019 alle ore 10:50 Sebastien FLAESCH ha scritto: > > Hello Craig, > > I don't think so: An ODBC program should be able to properly identify > (as much as possible) the original database type used for a column. > > We must also distinguish the concept of "variable length" regarding the > number of bytes used to encode characters, versus the actual length of > the string in character units. > > Plus the fact that [N]CHAR columns can be blank-padded, while [N]VARCHAR > columns are not and store the actual number of trailing white spaces of > the string, try for ex: > > create table tab1 ( c1 char(10), c2 varchar(10) ) > insert into tab1 values ( 'abc', 'abc ' ) > select '['+c1+']', '['+c2+']' from tab1 > > You will see: > > [abc ] [abc ] > > (check SET ANSI_PADDING ON/OFF) > > ... > > UTF-8 is a variable-width encoding: > > a => needs 1 byte > ? => needs 2 bytes > ? => needs 3 bytes > ... etc (there can be more than 3 bytes) > > In that context, one can see a "variable length" in byte units... > > But when counting in characters, 'a??' is 3 characters, no matter the > encoding used to store this string. > > You have also the concept of byte-length semantics versus char-length > semantics: When creating a CHAR(10) is this 10 bytes or 10 characters? > Depending on the database brand, it's bytes (SQL Server), characters > (PostgreSQL), or it can even be a mix and specified explicitly (like > in Oracle DB). > > Note: You have then also the concept of "width" or "number of columns": > A latin character takes one column, while an Asian logogram takes 2. > See wcwidth() for more details. > > ... > > In SQL Server, NCHAR and NVARCHAR can store UTF-16 when the SC modifier > is used in the database collation (they store UCS-2 when no SC is used) > > In UTF-16, a first range of characters are encoded on 2 bytes, but you > can have "surrogate pairs" encoded on 4 bytes (two 16-bit code units). > > In your logic, the NCHAR/UTF-16 type could also be considered as a > "variable length" type and SQLDecribeCol() could return SQL_WVARCHAR > instead of SQL_WCHAR... It must not and does not. > > Cheers, > Seb > > > On 2/27/19 4:32 PM, Craig Jackson wrote: > > I don't know anything about SQL Server 2019, but if they added the option > > to allow UTF-8 encoding of character strings, it would seem natural that > > said strings would be variable-length, even if declared CHAR(n). Strings > > encoded in UTF-8 are inherently variable length. > > > > Craig Jackson > > > > On Wed, Feb 27, 2019 at 10:27 AM Sebastien FLAESCH wrote: > > > >> Hi, > >> > >> Just tried with TDS 7.4, it did not help. > >> > >> I have tested the MS ODBC driver 17.3.1.1, it works as expected > >> ( I get 1/SQL_CHAR from SQLDescribeCol() ) > >> > >> You may know that it's very easy to setup an SQL Server 2019 with > >> docker, do you? > >> > >> Cheers, > >> Seb > >> > >> On 2/27/19 3:08 PM, Frediano Ziglio wrote: > >>> Hi, > >>> I would try to use TDS 7.4, not 7.3. > >>> Also I would try to use Microsoft ODBC driver and a network analyzer > >>> (like wireshark). > >>> > >>> Regards, > >>> Frediano > >>> > >>> Il giorno mar 26 feb 2019 alle ore 11:26 Sebastien FLAESCH > >>> ha scritto: > >>>> > >>>> Testing FreeTDS 1.1rc3 with SQL Server 2019: > >>>> > >>>> I get an unexpected SQL type code with a CHAR(10) column, when the > >>>> database collation is using UTF-8. > >>>> > >>>> Instead of SQL_CHAR (or SQL_WCHAR), I get SQL_WVARCHAR. > >>>> > >>>> I have created a database with this collation: > >>>> > >>>> Latin1_General_100_CI_AS_SC_UTF8 > >>>> > >>>> Then created a table like this: > >>>> > >>>> CREATE TABLE mytab1 ( col1 CHAR(10) ) > >>>> > >>>> and inserted a row: > >>>> > >>>> INSERT INTO mytab1 VALUES ( 'abc' ) > >>>> > >>>> Then in the ODBC program: > >>>> > >>>> SQLExecDirect(.."SELECT * FROM mytab1"..) > >>>> SQLDescribCol(...) > >>>> > >>>> Check the TDSDUMP trace in attachment (freetds-2019-1.log) > >>>> > >>>> token.c:1541:tds7_get_data_info: > >>>> colname = col1 > >>>> type = 39 (varchar) > >>>> server's type = 231 (x UCS-2 varchar) <-- 231 ? > >>>> column_varint_size = 2 > >>>> column_size = 20 (20 on server) > >>>> > >>>> > >>>> The same program, connecting to SQL Server 2017 (were DB collation is > >> Latin1 > >>>> without UTF-8): > >>>> > >>>> > >>>> token.c:1541:tds7_get_data_info: > >>>> colname = col1 > >>>> type = 47 (char) > >>>> server's type = 175 (xchar) <-- 175 > >>>> column_varint_size = 2 > >>>> column_size = 10 (10 on server) > >>>> > >>>> With SQL Server 2019, when using another collation (non-UTF-8) > >>>> > >>>> CREATE TABLE mytab2 ( col1 CHAR(10) COLLATE Latin1_General_CI_AS ) > >>>> > >>>> I get the expected tds type code... > >>>> > >>>> Seb > >>>> _______________________________________________ > >>>> FreeTDS mailing list > >>>> FreeTDS at lists.ibiblio.org > >>>> https://lists.ibiblio.org/mailman/listinfo/freetds > >>> _______________________________________________ > >>> FreeTDS mailing list > >>> FreeTDS at lists.ibiblio.org > >>> https://lists.ibiblio.org/mailman/listinfo/freetds > >>> > >> > >> _______________________________________________ > >> FreeTDS mailing list > >> FreeTDS at lists.ibiblio.org > >> https://lists.ibiblio.org/mailman/listinfo/freetds > >> > > _______________________________________________ > > FreeTDS mailing list > > FreeTDS at lists.ibiblio.org > > https://lists.ibiblio.org/mailman/listinfo/freetds > > > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds From sf at 4js.com Thu Feb 28 09:19:11 2019 From: sf at 4js.com (Sebastien FLAESCH) Date: Thu, 28 Feb 2019 15:19:11 +0100 Subject: [freetds] SQL Server 2019: CHAR(N) using UTF-8 is seen as SQL_NVARCHAR by SQLDescribeCol() In-Reply-To: References: <1609207a-0a70-5c44-cfd4-4dcbdf14dd37@4js.com> <4110fdf8-6ea9-c671-1d14-4176342c59f8@4js.com> <46ec34f9-2eca-4bc1-11d8-a2268fb3181a@4js.com> Message-ID: Great! Thanks for looking at this! I guess the idea is to use UTF-8 in the whole chain: Client ODBC app (char*) in UTF-8 <=> TDS <=> UTF-8 char/varchar column Instead of having un-necessary charset conversions: Client ODBC app (char*) in UTF-8 <=> UTF-16 <=> TDS <=> UTF-16 <=> UTF-8 char/varchar column Just guessing, I am not a TDS protocol expert. Seb On 2/28/19 11:56 AM, Frediano Ziglio wrote: > Hi, > so, installed a sql 2019 and tried some queries. > Using the driver provided inside the docker image the "abc" is > returned as "abc ", so > the CHAR(10) are returned encoded in UTF-8 and the "10" is just the > number of bytes. > Now, why the server decided to return UTF-8 and not convert to NVARCHAR (which > make sense to me for old clients) it's the issue. Maybe they bump the > protocol version, > maybe they are using some other flags/version (like client version > passes through > the pre-login). Unfortunately the login is encrypted so I'll have to > dig a bit more (well, > just question of setup and use the bounce utility, not sure if it > supports pre-login). > > Frediano > > Il giorno gio 28 feb 2019 alle ore 10:50 Sebastien FLAESCH > ha scritto: >> >> Hello Craig, >> >> I don't think so: An ODBC program should be able to properly identify >> (as much as possible) the original database type used for a column. >> >> We must also distinguish the concept of "variable length" regarding the >> number of bytes used to encode characters, versus the actual length of >> the string in character units. >> >> Plus the fact that [N]CHAR columns can be blank-padded, while [N]VARCHAR >> columns are not and store the actual number of trailing white spaces of >> the string, try for ex: >> >> create table tab1 ( c1 char(10), c2 varchar(10) ) >> insert into tab1 values ( 'abc', 'abc ' ) >> select '['+c1+']', '['+c2+']' from tab1 >> >> You will see: >> >> [abc ] [abc ] >> >> (check SET ANSI_PADDING ON/OFF) >> >> ... >> >> UTF-8 is a variable-width encoding: >> >> a => needs 1 byte >> ? => needs 2 bytes >> ? => needs 3 bytes >> ... etc (there can be more than 3 bytes) >> >> In that context, one can see a "variable length" in byte units... >> >> But when counting in characters, 'a??' is 3 characters, no matter the >> encoding used to store this string. >> >> You have also the concept of byte-length semantics versus char-length >> semantics: When creating a CHAR(10) is this 10 bytes or 10 characters? >> Depending on the database brand, it's bytes (SQL Server), characters >> (PostgreSQL), or it can even be a mix and specified explicitly (like >> in Oracle DB). >> >> Note: You have then also the concept of "width" or "number of columns": >> A latin character takes one column, while an Asian logogram takes 2. >> See wcwidth() for more details. >> >> ... >> >> In SQL Server, NCHAR and NVARCHAR can store UTF-16 when the SC modifier >> is used in the database collation (they store UCS-2 when no SC is used) >> >> In UTF-16, a first range of characters are encoded on 2 bytes, but you >> can have "surrogate pairs" encoded on 4 bytes (two 16-bit code units). >> >> In your logic, the NCHAR/UTF-16 type could also be considered as a >> "variable length" type and SQLDecribeCol() could return SQL_WVARCHAR >> instead of SQL_WCHAR... It must not and does not. >> >> Cheers, >> Seb >> >> >> On 2/27/19 4:32 PM, Craig Jackson wrote: >>> I don't know anything about SQL Server 2019, but if they added the option >>> to allow UTF-8 encoding of character strings, it would seem natural that >>> said strings would be variable-length, even if declared CHAR(n). Strings >>> encoded in UTF-8 are inherently variable length. >>> >>> Craig Jackson >>> >>> On Wed, Feb 27, 2019 at 10:27 AM Sebastien FLAESCH wrote: >>> >>>> Hi, >>>> >>>> Just tried with TDS 7.4, it did not help. >>>> >>>> I have tested the MS ODBC driver 17.3.1.1, it works as expected >>>> ( I get 1/SQL_CHAR from SQLDescribeCol() ) >>>> >>>> You may know that it's very easy to setup an SQL Server 2019 with >>>> docker, do you? >>>> >>>> Cheers, >>>> Seb >>>> >>>> On 2/27/19 3:08 PM, Frediano Ziglio wrote: >>>>> Hi, >>>>> I would try to use TDS 7.4, not 7.3. >>>>> Also I would try to use Microsoft ODBC driver and a network analyzer >>>>> (like wireshark). >>>>> >>>>> Regards, >>>>> Frediano >>>>> >>>>> Il giorno mar 26 feb 2019 alle ore 11:26 Sebastien FLAESCH >>>>> ha scritto: >>>>>> >>>>>> Testing FreeTDS 1.1rc3 with SQL Server 2019: >>>>>> >>>>>> I get an unexpected SQL type code with a CHAR(10) column, when the >>>>>> database collation is using UTF-8. >>>>>> >>>>>> Instead of SQL_CHAR (or SQL_WCHAR), I get SQL_WVARCHAR. >>>>>> >>>>>> I have created a database with this collation: >>>>>> >>>>>> Latin1_General_100_CI_AS_SC_UTF8 >>>>>> >>>>>> Then created a table like this: >>>>>> >>>>>> CREATE TABLE mytab1 ( col1 CHAR(10) ) >>>>>> >>>>>> and inserted a row: >>>>>> >>>>>> INSERT INTO mytab1 VALUES ( 'abc' ) >>>>>> >>>>>> Then in the ODBC program: >>>>>> >>>>>> SQLExecDirect(.."SELECT * FROM mytab1"..) >>>>>> SQLDescribCol(...) >>>>>> >>>>>> Check the TDSDUMP trace in attachment (freetds-2019-1.log) >>>>>> >>>>>> token.c:1541:tds7_get_data_info: >>>>>> colname = col1 >>>>>> type = 39 (varchar) >>>>>> server's type = 231 (x UCS-2 varchar) <-- 231 ? >>>>>> column_varint_size = 2 >>>>>> column_size = 20 (20 on server) >>>>>> >>>>>> >>>>>> The same program, connecting to SQL Server 2017 (were DB collation is >>>> Latin1 >>>>>> without UTF-8): >>>>>> >>>>>> >>>>>> token.c:1541:tds7_get_data_info: >>>>>> colname = col1 >>>>>> type = 47 (char) >>>>>> server's type = 175 (xchar) <-- 175 >>>>>> column_varint_size = 2 >>>>>> column_size = 10 (10 on server) >>>>>> >>>>>> With SQL Server 2019, when using another collation (non-UTF-8) >>>>>> >>>>>> CREATE TABLE mytab2 ( col1 CHAR(10) COLLATE Latin1_General_CI_AS ) >>>>>> >>>>>> I get the expected tds type code... >>>>>> >>>>>> Seb >>>>>> _______________________________________________ >>>>>> FreeTDS mailing list >>>>>> FreeTDS at lists.ibiblio.org >>>>>> https://lists.ibiblio.org/mailman/listinfo/freetds >>>>> _______________________________________________ >>>>> FreeTDS mailing list >>>>> FreeTDS at lists.ibiblio.org >>>>> https://lists.ibiblio.org/mailman/listinfo/freetds >>>>> >>>> >>>> _______________________________________________ >>>> FreeTDS mailing list >>>> FreeTDS at lists.ibiblio.org >>>> https://lists.ibiblio.org/mailman/listinfo/freetds >>>> >>> _______________________________________________ >>> FreeTDS mailing list >>> FreeTDS at lists.ibiblio.org >>> https://lists.ibiblio.org/mailman/listinfo/freetds >>> >> >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> https://lists.ibiblio.org/mailman/listinfo/freetds > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds > From freddy77 at gmail.com Thu Feb 28 09:22:18 2019 From: freddy77 at gmail.com (Frediano Ziglio) Date: Thu, 28 Feb 2019 14:22:18 +0000 Subject: [freetds] SQL Server 2019: CHAR(N) using UTF-8 is seen as SQL_NVARCHAR by SQLDescribeCol() In-Reply-To: References: <1609207a-0a70-5c44-cfd4-4dcbdf14dd37@4js.com> <4110fdf8-6ea9-c671-1d14-4176342c59f8@4js.com> <46ec34f9-2eca-4bc1-11d8-a2268fb3181a@4js.com> Message-ID: Hi, there seems to be 2 new "feature" (it's like capabilities for TDS 7.4), 9 and 10, the relative ack values are 0x0101 and 0x01, client is sending 0x01 for both. Currently not documented in TDS protocol specification (https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-tds/b46a581a-39de-4745-b076-ec4dbb7d13ec). The protocol version is still 7.4. I suppose I can try to send these feature extensions and see what happens, if server changes the encoding. Frediano Il giorno gio 28 feb 2019 alle ore 10:56 Frediano Ziglio ha scritto: > > Hi, > so, installed a sql 2019 and tried some queries. > Using the driver provided inside the docker image the "abc" is > returned as "abc ", so > the CHAR(10) are returned encoded in UTF-8 and the "10" is just the > number of bytes. > Now, why the server decided to return UTF-8 and not convert to NVARCHAR (which > make sense to me for old clients) it's the issue. Maybe they bump the > protocol version, > maybe they are using some other flags/version (like client version > passes through > the pre-login). Unfortunately the login is encrypted so I'll have to > dig a bit more (well, > just question of setup and use the bounce utility, not sure if it > supports pre-login). > > Frediano > > Il giorno gio 28 feb 2019 alle ore 10:50 Sebastien FLAESCH > ha scritto: > > > > Hello Craig, > > > > I don't think so: An ODBC program should be able to properly identify > > (as much as possible) the original database type used for a column. > > > > We must also distinguish the concept of "variable length" regarding the > > number of bytes used to encode characters, versus the actual length of > > the string in character units. > > > > Plus the fact that [N]CHAR columns can be blank-padded, while [N]VARCHAR > > columns are not and store the actual number of trailing white spaces of > > the string, try for ex: > > > > create table tab1 ( c1 char(10), c2 varchar(10) ) > > insert into tab1 values ( 'abc', 'abc ' ) > > select '['+c1+']', '['+c2+']' from tab1 > > > > You will see: > > > > [abc ] [abc ] > > > > (check SET ANSI_PADDING ON/OFF) > > > > ... > > > > UTF-8 is a variable-width encoding: > > > > a => needs 1 byte > > ? => needs 2 bytes > > ? => needs 3 bytes > > ... etc (there can be more than 3 bytes) > > > > In that context, one can see a "variable length" in byte units... > > > > But when counting in characters, 'a??' is 3 characters, no matter the > > encoding used to store this string. > > > > You have also the concept of byte-length semantics versus char-length > > semantics: When creating a CHAR(10) is this 10 bytes or 10 characters? > > Depending on the database brand, it's bytes (SQL Server), characters > > (PostgreSQL), or it can even be a mix and specified explicitly (like > > in Oracle DB). > > > > Note: You have then also the concept of "width" or "number of columns": > > A latin character takes one column, while an Asian logogram takes 2. > > See wcwidth() for more details. > > > > ... > > > > In SQL Server, NCHAR and NVARCHAR can store UTF-16 when the SC modifier > > is used in the database collation (they store UCS-2 when no SC is used) > > > > In UTF-16, a first range of characters are encoded on 2 bytes, but you > > can have "surrogate pairs" encoded on 4 bytes (two 16-bit code units). > > > > In your logic, the NCHAR/UTF-16 type could also be considered as a > > "variable length" type and SQLDecribeCol() could return SQL_WVARCHAR > > instead of SQL_WCHAR... It must not and does not. > > > > Cheers, > > Seb > > > > > > On 2/27/19 4:32 PM, Craig Jackson wrote: > > > I don't know anything about SQL Server 2019, but if they added the option > > > to allow UTF-8 encoding of character strings, it would seem natural that > > > said strings would be variable-length, even if declared CHAR(n). Strings > > > encoded in UTF-8 are inherently variable length. > > > > > > Craig Jackson > > > > > > On Wed, Feb 27, 2019 at 10:27 AM Sebastien FLAESCH wrote: > > > > > >> Hi, > > >> > > >> Just tried with TDS 7.4, it did not help. > > >> > > >> I have tested the MS ODBC driver 17.3.1.1, it works as expected > > >> ( I get 1/SQL_CHAR from SQLDescribeCol() ) > > >> > > >> You may know that it's very easy to setup an SQL Server 2019 with > > >> docker, do you? > > >> > > >> Cheers, > > >> Seb > > >> > > >> On 2/27/19 3:08 PM, Frediano Ziglio wrote: > > >>> Hi, > > >>> I would try to use TDS 7.4, not 7.3. > > >>> Also I would try to use Microsoft ODBC driver and a network analyzer > > >>> (like wireshark). > > >>> > > >>> Regards, > > >>> Frediano > > >>> > > >>> Il giorno mar 26 feb 2019 alle ore 11:26 Sebastien FLAESCH > > >>> ha scritto: > > >>>> > > >>>> Testing FreeTDS 1.1rc3 with SQL Server 2019: > > >>>> > > >>>> I get an unexpected SQL type code with a CHAR(10) column, when the > > >>>> database collation is using UTF-8. > > >>>> > > >>>> Instead of SQL_CHAR (or SQL_WCHAR), I get SQL_WVARCHAR. > > >>>> > > >>>> I have created a database with this collation: > > >>>> > > >>>> Latin1_General_100_CI_AS_SC_UTF8 > > >>>> > > >>>> Then created a table like this: > > >>>> > > >>>> CREATE TABLE mytab1 ( col1 CHAR(10) ) > > >>>> > > >>>> and inserted a row: > > >>>> > > >>>> INSERT INTO mytab1 VALUES ( 'abc' ) > > >>>> > > >>>> Then in the ODBC program: > > >>>> > > >>>> SQLExecDirect(.."SELECT * FROM mytab1"..) > > >>>> SQLDescribCol(...) > > >>>> > > >>>> Check the TDSDUMP trace in attachment (freetds-2019-1.log) > > >>>> > > >>>> token.c:1541:tds7_get_data_info: > > >>>> colname = col1 > > >>>> type = 39 (varchar) > > >>>> server's type = 231 (x UCS-2 varchar) <-- 231 ? > > >>>> column_varint_size = 2 > > >>>> column_size = 20 (20 on server) > > >>>> > > >>>> > > >>>> The same program, connecting to SQL Server 2017 (were DB collation is > > >> Latin1 > > >>>> without UTF-8): > > >>>> > > >>>> > > >>>> token.c:1541:tds7_get_data_info: > > >>>> colname = col1 > > >>>> type = 47 (char) > > >>>> server's type = 175 (xchar) <-- 175 > > >>>> column_varint_size = 2 > > >>>> column_size = 10 (10 on server) > > >>>> > > >>>> With SQL Server 2019, when using another collation (non-UTF-8) > > >>>> > > >>>> CREATE TABLE mytab2 ( col1 CHAR(10) COLLATE Latin1_General_CI_AS ) > > >>>> > > >>>> I get the expected tds type code... > > >>>> > > >>>> Seb > > >>>> _______________________________________________ > > >>>> FreeTDS mailing list > > >>>> FreeTDS at lists.ibiblio.org > > >>>> https://lists.ibiblio.org/mailman/listinfo/freetds > > >>> _______________________________________________ > > >>> FreeTDS mailing list > > >>> FreeTDS at lists.ibiblio.org > > >>> https://lists.ibiblio.org/mailman/listinfo/freetds > > >>> > > >> > > >> _______________________________________________ > > >> FreeTDS mailing list > > >> FreeTDS at lists.ibiblio.org > > >> https://lists.ibiblio.org/mailman/listinfo/freetds > > >> > > > _______________________________________________ > > > FreeTDS mailing list > > > FreeTDS at lists.ibiblio.org > > > https://lists.ibiblio.org/mailman/listinfo/freetds > > > > > > > _______________________________________________ > > FreeTDS mailing list > > FreeTDS at lists.ibiblio.org > > https://lists.ibiblio.org/mailman/listinfo/freetds From freddy77 at gmail.com Thu Feb 28 13:03:35 2019 From: freddy77 at gmail.com (Frediano Ziglio) Date: Thu, 28 Feb 2019 18:03:35 +0000 Subject: [freetds] SQL Server 2019: CHAR(N) using UTF-8 is seen as SQL_NVARCHAR by SQLDescribeCol() In-Reply-To: References: <1609207a-0a70-5c44-cfd4-4dcbdf14dd37@4js.com> <4110fdf8-6ea9-c671-1d14-4176342c59f8@4js.com> <46ec34f9-2eca-4bc1-11d8-a2268fb3181a@4js.com> Message-ID: Fine, it's the not still documented extension 10. If set to 1 (1 byte) data are returned as UTF-8. I don't know what extension 9 is but 10 is enough. The collation has a weird bit set if the encoding is UTF-8. Frediano Il giorno gio 28 feb 2019 alle ore 14:22 Frediano Ziglio ha scritto: > > Hi, > there seems to be 2 new "feature" (it's like capabilities for TDS > 7.4), 9 and 10, the relative ack values are 0x0101 and 0x01, client is > sending 0x01 for both. > Currently not documented in TDS protocol specification > (https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-tds/b46a581a-39de-4745-b076-ec4dbb7d13ec). > The protocol version is still 7.4. > I suppose I can try to send these feature extensions and see what > happens, if server changes the encoding. > > Frediano > > Il giorno gio 28 feb 2019 alle ore 10:56 Frediano Ziglio > ha scritto: > > > > Hi, > > so, installed a sql 2019 and tried some queries. > > Using the driver provided inside the docker image the "abc" is > > returned as "abc ", so > > the CHAR(10) are returned encoded in UTF-8 and the "10" is just the > > number of bytes. > > Now, why the server decided to return UTF-8 and not convert to NVARCHAR (which > > make sense to me for old clients) it's the issue. Maybe they bump the > > protocol version, > > maybe they are using some other flags/version (like client version > > passes through > > the pre-login). Unfortunately the login is encrypted so I'll have to > > dig a bit more (well, > > just question of setup and use the bounce utility, not sure if it > > supports pre-login). > > > > Frediano > > > > Il giorno gio 28 feb 2019 alle ore 10:50 Sebastien FLAESCH > > ha scritto: > > > > > > Hello Craig, > > > > > > I don't think so: An ODBC program should be able to properly identify > > > (as much as possible) the original database type used for a column. > > > > > > We must also distinguish the concept of "variable length" regarding the > > > number of bytes used to encode characters, versus the actual length of > > > the string in character units. > > > > > > Plus the fact that [N]CHAR columns can be blank-padded, while [N]VARCHAR > > > columns are not and store the actual number of trailing white spaces of > > > the string, try for ex: > > > > > > create table tab1 ( c1 char(10), c2 varchar(10) ) > > > insert into tab1 values ( 'abc', 'abc ' ) > > > select '['+c1+']', '['+c2+']' from tab1 > > > > > > You will see: > > > > > > [abc ] [abc ] > > > > > > (check SET ANSI_PADDING ON/OFF) > > > > > > ... > > > > > > UTF-8 is a variable-width encoding: > > > > > > a => needs 1 byte > > > ? => needs 2 bytes > > > ? => needs 3 bytes > > > ... etc (there can be more than 3 bytes) > > > > > > In that context, one can see a "variable length" in byte units... > > > > > > But when counting in characters, 'a??' is 3 characters, no matter the > > > encoding used to store this string. > > > > > > You have also the concept of byte-length semantics versus char-length > > > semantics: When creating a CHAR(10) is this 10 bytes or 10 characters? > > > Depending on the database brand, it's bytes (SQL Server), characters > > > (PostgreSQL), or it can even be a mix and specified explicitly (like > > > in Oracle DB). > > > > > > Note: You have then also the concept of "width" or "number of columns": > > > A latin character takes one column, while an Asian logogram takes 2. > > > See wcwidth() for more details. > > > > > > ... > > > > > > In SQL Server, NCHAR and NVARCHAR can store UTF-16 when the SC modifier > > > is used in the database collation (they store UCS-2 when no SC is used) > > > > > > In UTF-16, a first range of characters are encoded on 2 bytes, but you > > > can have "surrogate pairs" encoded on 4 bytes (two 16-bit code units). > > > > > > In your logic, the NCHAR/UTF-16 type could also be considered as a > > > "variable length" type and SQLDecribeCol() could return SQL_WVARCHAR > > > instead of SQL_WCHAR... It must not and does not. > > > > > > Cheers, > > > Seb > > > > > > > > > On 2/27/19 4:32 PM, Craig Jackson wrote: > > > > I don't know anything about SQL Server 2019, but if they added the option > > > > to allow UTF-8 encoding of character strings, it would seem natural that > > > > said strings would be variable-length, even if declared CHAR(n). Strings > > > > encoded in UTF-8 are inherently variable length. > > > > > > > > Craig Jackson > > > > > > > > On Wed, Feb 27, 2019 at 10:27 AM Sebastien FLAESCH wrote: > > > > > > > >> Hi, > > > >> > > > >> Just tried with TDS 7.4, it did not help. > > > >> > > > >> I have tested the MS ODBC driver 17.3.1.1, it works as expected > > > >> ( I get 1/SQL_CHAR from SQLDescribeCol() ) > > > >> > > > >> You may know that it's very easy to setup an SQL Server 2019 with > > > >> docker, do you? > > > >> > > > >> Cheers, > > > >> Seb > > > >> > > > >> On 2/27/19 3:08 PM, Frediano Ziglio wrote: > > > >>> Hi, > > > >>> I would try to use TDS 7.4, not 7.3. > > > >>> Also I would try to use Microsoft ODBC driver and a network analyzer > > > >>> (like wireshark). > > > >>> > > > >>> Regards, > > > >>> Frediano > > > >>> > > > >>> Il giorno mar 26 feb 2019 alle ore 11:26 Sebastien FLAESCH > > > >>> ha scritto: > > > >>>> > > > >>>> Testing FreeTDS 1.1rc3 with SQL Server 2019: > > > >>>> > > > >>>> I get an unexpected SQL type code with a CHAR(10) column, when the > > > >>>> database collation is using UTF-8. > > > >>>> > > > >>>> Instead of SQL_CHAR (or SQL_WCHAR), I get SQL_WVARCHAR. > > > >>>> > > > >>>> I have created a database with this collation: > > > >>>> > > > >>>> Latin1_General_100_CI_AS_SC_UTF8 > > > >>>> > > > >>>> Then created a table like this: > > > >>>> > > > >>>> CREATE TABLE mytab1 ( col1 CHAR(10) ) > > > >>>> > > > >>>> and inserted a row: > > > >>>> > > > >>>> INSERT INTO mytab1 VALUES ( 'abc' ) > > > >>>> > > > >>>> Then in the ODBC program: > > > >>>> > > > >>>> SQLExecDirect(.."SELECT * FROM mytab1"..) > > > >>>> SQLDescribCol(...) > > > >>>> > > > >>>> Check the TDSDUMP trace in attachment (freetds-2019-1.log) > > > >>>> > > > >>>> token.c:1541:tds7_get_data_info: > > > >>>> colname = col1 > > > >>>> type = 39 (varchar) > > > >>>> server's type = 231 (x UCS-2 varchar) <-- 231 ? > > > >>>> column_varint_size = 2 > > > >>>> column_size = 20 (20 on server) > > > >>>> > > > >>>> > > > >>>> The same program, connecting to SQL Server 2017 (were DB collation is > > > >> Latin1 > > > >>>> without UTF-8): > > > >>>> > > > >>>> > > > >>>> token.c:1541:tds7_get_data_info: > > > >>>> colname = col1 > > > >>>> type = 47 (char) > > > >>>> server's type = 175 (xchar) <-- 175 > > > >>>> column_varint_size = 2 > > > >>>> column_size = 10 (10 on server) > > > >>>> > > > >>>> With SQL Server 2019, when using another collation (non-UTF-8) > > > >>>> > > > >>>> CREATE TABLE mytab2 ( col1 CHAR(10) COLLATE Latin1_General_CI_AS ) > > > >>>> > > > >>>> I get the expected tds type code... > > > >>>> > > > >>>> Seb > > > >>>> _______________________________________________ > > > >>>> FreeTDS mailing list > > > >>>> FreeTDS at lists.ibiblio.org > > > >>>> https://lists.ibiblio.org/mailman/listinfo/freetds > > > >>> _______________________________________________ > > > >>> FreeTDS mailing list > > > >>> FreeTDS at lists.ibiblio.org > > > >>> https://lists.ibiblio.org/mailman/listinfo/freetds > > > >>> > > > >> > > > >> _______________________________________________ > > > >> FreeTDS mailing list > > > >> FreeTDS at lists.ibiblio.org > > > >> https://lists.ibiblio.org/mailman/listinfo/freetds > > > >> > > > > _______________________________________________ > > > > FreeTDS mailing list > > > > FreeTDS at lists.ibiblio.org > > > > https://lists.ibiblio.org/mailman/listinfo/freetds > > > > > > > > > > _______________________________________________ > > > FreeTDS mailing list > > > FreeTDS at lists.ibiblio.org > > > https://lists.ibiblio.org/mailman/listinfo/freetds From TilleA at rki.de Mon Mar 4 09:44:27 2019 From: TilleA at rki.de (Tille, Andreas) Date: Mon, 4 Mar 2019 14:44:27 +0000 Subject: [freetds] Solved: Login failed. The login is from an untrusted domain and cannot be used with Integrated authentication. Message-ID: <23f15ea2212f41f283953521f083d6d4@EXCH01.rki.local> Hi, (sorry form my late reply but I had no access to the server in question) At Wed, 27. February 2019 09:50 you wrote > 8.0? Still? See http://www.freetds.org/userguide/choosingtdsprotocol.htm. > Also check http://www.freetds.org/userguide/freetdsconf.htm. OK, I now changed to: diff --git a/freetds/freetds.conf b/freetds/freetds.conf index f38864b..fc1dac0 100644 --- a/freetds/freetds.conf +++ b/freetds/freetds.conf @@ -11,7 +11,7 @@ [global] # TDS protocol version ; tds version = 4.2 - tds version = 8.0 + tds version = 7.4 client charset = UTF-8 encryption = require (it just worked before all the time with 8.0 - so no need to change anything ...) > One option that could make a difference is also "use ntlmv2", try to set to > yes or no (in Debian the default should be still no). Setting this to "yes" was the final clue. Thanks a lot for your quick help Andreas. From no-reply at appveyor.com Wed Mar 13 15:08:37 2019 From: no-reply at appveyor.com (AppVeyor) Date: Wed, 13 Mar 2019 19:08:37 +0000 Subject: [freetds] Build failed: freetds 1378 Message-ID: <20190313190837.1.E48AC87BFFDC3257@appveyor.com> From no-reply at appveyor.com Wed Mar 13 16:44:00 2019 From: no-reply at appveyor.com (AppVeyor) Date: Wed, 13 Mar 2019 20:44:00 +0000 Subject: [freetds] Build completed: freetds 1379 Message-ID: <20190313204400.1.8630DB0F2D06A286@appveyor.com> From freddy77 at gmail.com Thu Mar 14 04:23:23 2019 From: freddy77 at gmail.com (Frediano Ziglio) Date: Thu, 14 Mar 2019 08:23:23 +0000 Subject: [freetds] FreeTDS 1.1 is out! Message-ID: Just minor changes since release candidate 3. Summary of Changes in release 1.1 --------------------------------- User visible (not in a particular order): - Changed default TDS protocol version during configure to "auto". Versions 4.2 and 7.0 are no longer accepted for default, you may still specify an explicit version to connect to obsolete servers ("auto" won't attempt these versions); - allows to disable TLS 1.0 support; - pool server allows to specify different username/password for server and clients allowing to hide internal server logins; - tsql utility now send final partial query to server to avoid to have to specify a final "GO" line to terminate commands; - better support for Microsoft cluster, client will attempt multiple connection to server at the same time if DNS reply multiple IPs; - MONEY/SMALLMONEY types are now formated with 4 decimal digits to avoid truncation; - MARS support is now compiled by default; - pool server is now compiled by default; - Fixed SQL_ATTR_LOGIN_TIMEOUT for ODBC; - Fixed large integer numbers for ODBC RPC constants; - Fixed encrypted logins if "auto" protocol version is used; - Support CS_TIMEOUT, CS_LOGIN_TIMEOUT and CS_CLIENTCHARSET properties under CTLibrary; - Added a dbacolname function in DBLibrary, similar to dbcolname but for compute columns (mainly for Sybase now, Microsoft removed support for compute columns); - NTLMv2 is now on by default. Implementation: - Improved UTF-8 performances; - Use more stdint.h style definitions (like uint32_t); - Use bool type instead of int; - pool server compile under Windows too (not as capable as Unix version); - CMake build is now able to do an installation; - Added a src/utils directory to collect all common code not strictly related to replacements or TDS; - Simplified makefiles; - Support CP1252 encoding in internal trivial iconv; - Better ODBC detection. Allows to specify a directory with --with-iodbc to specify custom iOBDC. Kind Regards, Frediano From sf at 4js.com Thu Mar 14 06:44:54 2019 From: sf at 4js.com (Sebastien FLAESCH) Date: Thu, 14 Mar 2019 11:44:54 +0100 Subject: [freetds] FreeTDS 1.1 is out! In-Reply-To: References: Message-ID: <96f43dfd-814c-ef46-f643-b932e473a086@4js.com> Hi, I have executed our QA test suite with FreeTDS 1.1 and no issue was detected. Seb On 3/14/19 9:23 AM, Frediano Ziglio wrote: > Just minor changes since release candidate 3. > > Summary of Changes in release 1.1 > --------------------------------- > User visible (not in a particular order): > - Changed default TDS protocol version during configure to "auto". > Versions 4.2 and 7.0 are no longer accepted for default, you may > still specify an explicit version to connect to obsolete servers > ("auto" won't attempt these versions); > - allows to disable TLS 1.0 support; > - pool server allows to specify different username/password for server > and clients allowing to hide internal server logins; > - tsql utility now send final partial query to server to avoid to have > to specify a final "GO" line to terminate commands; > - better support for Microsoft cluster, client will attempt multiple > connection to server at the same time if DNS reply multiple IPs; > - MONEY/SMALLMONEY types are now formated with 4 decimal digits to > avoid truncation; > - MARS support is now compiled by default; > - pool server is now compiled by default; > - Fixed SQL_ATTR_LOGIN_TIMEOUT for ODBC; > - Fixed large integer numbers for ODBC RPC constants; > - Fixed encrypted logins if "auto" protocol version is used; > - Support CS_TIMEOUT, CS_LOGIN_TIMEOUT and CS_CLIENTCHARSET properties > under CTLibrary; > - Added a dbacolname function in DBLibrary, similar to dbcolname but > for compute columns (mainly for Sybase now, Microsoft removed > support for compute columns); > - NTLMv2 is now on by default. > > Implementation: > - Improved UTF-8 performances; > - Use more stdint.h style definitions (like uint32_t); > - Use bool type instead of int; > - pool server compile under Windows too (not as capable as Unix > version); > - CMake build is now able to do an installation; > - Added a src/utils directory to collect all common code not strictly > related to replacements or TDS; > - Simplified makefiles; > - Support CP1252 encoding in internal trivial iconv; > - Better ODBC detection. Allows to specify a directory with > --with-iodbc to specify custom iOBDC. > > > Kind Regards, > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds > From no-reply at appveyor.com Thu Mar 14 21:02:24 2019 From: no-reply at appveyor.com (AppVeyor) Date: Fri, 15 Mar 2019 01:02:24 +0000 Subject: [freetds] Build failed: freetds 1384 Message-ID: <20190315010224.1.9E7C3A3C052F55C3@appveyor.com> From no-reply at appveyor.com Thu Mar 14 22:18:56 2019 From: no-reply at appveyor.com (AppVeyor) Date: Fri, 15 Mar 2019 02:18:56 +0000 Subject: [freetds] Build completed: freetds 1385 Message-ID: <20190315021856.1.484DE72E2365E5E8@appveyor.com> From no-reply at appveyor.com Sun Mar 17 13:49:29 2019 From: no-reply at appveyor.com (AppVeyor) Date: Sun, 17 Mar 2019 17:49:29 +0000 Subject: [freetds] Build failed: freetds 1390 Message-ID: <20190317174929.1.04129CCBC92C3D8D@appveyor.com> From no-reply at appveyor.com Sun Mar 17 15:39:28 2019 From: no-reply at appveyor.com (AppVeyor) Date: Sun, 17 Mar 2019 19:39:28 +0000 Subject: [freetds] Build completed: freetds 1391 Message-ID: <20190317193928.1.92E4047881F451AB@appveyor.com> From no-reply at appveyor.com Sun Mar 17 16:58:47 2019 From: no-reply at appveyor.com (AppVeyor) Date: Sun, 17 Mar 2019 20:58:47 +0000 Subject: [freetds] Build failed: freetds 1394 Message-ID: <20190317205847.1.17EF2E0802CEAEC7@appveyor.com> From no-reply at appveyor.com Mon Mar 18 11:08:46 2019 From: no-reply at appveyor.com (AppVeyor) Date: Mon, 18 Mar 2019 15:08:46 +0000 Subject: [freetds] Build failed: freetds 1397 Message-ID: <20190318150846.1.2E09B471467CF7D5@appveyor.com> From no-reply at appveyor.com Mon Mar 18 11:20:18 2019 From: no-reply at appveyor.com (AppVeyor) Date: Mon, 18 Mar 2019 15:20:18 +0000 Subject: [freetds] Build failed: freetds 1397 Message-ID: <20190318152018.1.44125B1CB8050A56@appveyor.com> From no-reply at appveyor.com Thu Mar 21 06:28:59 2019 From: no-reply at appveyor.com (AppVeyor) Date: Thu, 21 Mar 2019 10:28:59 +0000 Subject: [freetds] Build failed: freetds 1398 Message-ID: <20190321102859.1.6DBCB98779D31639@appveyor.com>