From no-reply at appveyor.com Sat Oct 6 13:11:09 2018 From: no-reply at appveyor.com (AppVeyor) Date: Sat, 06 Oct 2018 17:11:09 +0000 Subject: [freetds] Build failed: freetds 1175 Message-ID: <20181006171109.1.DFDC50FC7312135C@appveyor.com> From ikorot01 at gmail.com Sat Oct 6 01:21:23 2018 From: ikorot01 at gmail.com (Igor Korot) Date: Sat, 6 Oct 2018 00:21:23 -0500 Subject: [freetds] SQLDescribeCol Message-ID: Hi, Is there a plans to implement the subject? Thank you. From freddy77 at gmail.com Sat Oct 6 13:26:49 2018 From: freddy77 at gmail.com (Frediano Ziglio) Date: Sat, 6 Oct 2018 18:26:49 +0100 Subject: [freetds] SQLDescribeCol In-Reply-To: References: Message-ID: Well, maybe there was 10 years ago when it was implemented :-) If you refer to SQLDescribeParam currently there's no plan although with some MSSQL seems not that hard using a new store procedure, see https://github.com/FreeTDS/freetds/issues/104 Frediano Il giorno sab 6 ott 2018 alle ore 18:21 Igor Korot ha scritto: > > Hi, > Is there a plans to implement the subject? > > Thank you. From DJacopille at MFS.com Fri Oct 5 17:39:41 2018 From: DJacopille at MFS.com (Jacopille, David) Date: Fri, 5 Oct 2018 21:39:41 +0000 Subject: [freetds] FreeTDS question about text size Message-ID: <9EC4B226-D694-430B-9C97-92D40A291F0B@mfs.com> General question for a FreeTDS guru: We saw the warning in the freetds.conf file: # If you get out-of-memory errors, it may mean that your client # is trying to allocate a huge buffer for a TEXT field. # Try setting 'text size' to a more reasonable limit text size = 64512 We needed more but we still tried to be reasonable: #text size = 64512 client charset = UTF-8 text size = 200000 Of course we encountered a nvarchar(max) column that is holding way more than 200000 bytes and it seems to be getting truncated. What is the impact of increasing text size to 10 MB? Are any of these three scenarios true? A. Every column, even an nvarchar(8), is allocated 10 MB B. The memory utilization is only what the column actually holds...up to 10 MB C. The memory utilization is determined by table design: an nvarchar(8) col would be allocated 16 bytes, and an nvarchar(max) would be allocated 10 MB Thanks, Dave MFS Email system made the following annotation --------------------------------------------------------------------------------------------------------------------------------------- This email communication and any attachments may contain proprietary, confidential, or privileged information. If you are not the intended recipient, you are hereby notified that you have received this email in error and that any review, disclosure, dissemination, distribution or copying of it or its contents is prohibited. The sender does not waive confidentiality or any privilege by mistransmission. If you have received this email in error, please notify the sender immediately, delete this email, and destroy all copies and any attachments. From ikorot01 at gmail.com Sat Oct 6 01:48:17 2018 From: ikorot01 at gmail.com (Igor Korot) Date: Sat, 6 Oct 2018 00:48:17 -0500 Subject: [freetds] SQLDescribeCol In-Reply-To: References: Message-ID: Frediano, On Sat, Oct 6, 2018 at 12:27 PM Frediano Ziglio wrote: > > Well, maybe there was 10 years ago when it was implemented :-) Oops, sorry about that. > If you refer to SQLDescribeParam currently there's no plan although > with some MSSQL seems not that hard using a new store procedure, see > https://github.com/FreeTDS/freetds/issues/104 Will it be compatible with Sybase? Or this will be MS SQL-specific? Thank you. > > Frediano > > Il giorno sab 6 ott 2018 alle ore 18:21 Igor Korot > ha scritto: > > > > Hi, > > Is there a plans to implement the subject? > > > > Thank you. > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds From ikorot01 at gmail.com Sat Oct 6 01:50:25 2018 From: ikorot01 at gmail.com (Igor Korot) Date: Sat, 6 Oct 2018 00:50:25 -0500 Subject: [freetds] FreeTDS question about text size In-Reply-To: <9EC4B226-D694-430B-9C97-92D40A291F0B@mfs.com> References: <9EC4B226-D694-430B-9C97-92D40A291F0B@mfs.com> Message-ID: Hi, On Sat, Oct 6, 2018 at 12:35 PM Jacopille, David wrote: > > General question for a FreeTDS guru: > > We saw the warning in the freetds.conf file: > > # If you get out-of-memory errors, it may mean that your client > # is trying to allocate a huge buffer for a TEXT field. > # Try setting 'text size' to a more reasonable limit > text size = 64512 > > We needed more but we still tried to be reasonable: > > #text size = 64512 > client charset = UTF-8 > text size = 200000 > > Of course we encountered a nvarchar(max) column that is holding way more than 200000 bytes and it seems to be getting truncated. I would be curious why this field is not declared as BLOB? Thank you. > > What is the impact of increasing text size to 10 MB? > > Are any of these three scenarios true? > > A. Every column, even an nvarchar(8), is allocated 10 MB > B. The memory utilization is only what the column actually holds...up to 10 MB > C. The memory utilization is determined by table design: an nvarchar(8) col would be allocated 16 bytes, and an nvarchar(max) would be allocated 10 MB > > Thanks, > Dave > > MFS Email system made the following annotation > --------------------------------------------------------------------------------------------------------------------------------------- > This email communication and any attachments may contain proprietary, confidential, or privileged information. If you are not the intended recipient, you are hereby notified that you have received this email in error and that any review, disclosure, dissemination, distribution or copying of it or its contents is prohibited. The sender does not waive confidentiality or any privilege by mistransmission. If you have received this email in error, please notify the sender immediately, delete this email, and destroy all copies and any attachments. > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds From freddy77 at gmail.com Sat Oct 6 13:51:23 2018 From: freddy77 at gmail.com (Frediano Ziglio) Date: Sat, 6 Oct 2018 18:51:23 +0100 Subject: [freetds] FreeTDS question about text size In-Reply-To: <9EC4B226-D694-430B-9C97-92D40A291F0B@mfs.com> References: <9EC4B226-D694-430B-9C97-92D40A291F0B@mfs.com> Message-ID: Il giorno sab 6 ott 2018 alle ore 18:35 Jacopille, David ha scritto: > > General question for a FreeTDS guru: > > We saw the warning in the freetds.conf file: > > # If you get out-of-memory errors, it may mean that your client > # is trying to allocate a huge buffer for a TEXT field. > # Try setting 'text size' to a more reasonable limit > text size = 64512 > > We needed more but we still tried to be reasonable: > > #text size = 64512 > client charset = UTF-8 > text size = 200000 > > Of course we encountered a nvarchar(max) column that is holding way more than 200000 bytes and it seems to be getting truncated. > > What is the impact of increasing text size to 10 MB? > > Are any of these three scenarios true? > > A. Every column, even an nvarchar(8), is allocated 10 MB > B. The memory utilization is only what the column actually holds...up to 10 MB > C. The memory utilization is determined by table design: an nvarchar(8) col would be allocated 16 bytes, and an nvarchar(max) would be allocated 10 MB > > Thanks, > Dave > Hi, yes, the message is quite scaring but actually is not much true anymore. Memory to store BLOBs is allocated dynamically, if TEXT/IMAGE/VARCHAR(MAX) or similar are used more or less the memory required to store column data used (not surely the maximum) is used. So: A) no, NVARCHAR(8) should allocate maximum 32 bytes (to take into account character encoding conversions, like to UTF-8) B) yes, we can say that, TEXTSIZE is send to server so is the server that do the truncation. Considering characters conversion (for instance for nvarchar(max)) can take more (potentially 30mb for a 10mb column written in Klingon). C) no, as said BLOBs use the amount of memory specific column data requires In the past the full size (so like 10MB for an IMAGE column) were used, so the worrying comment. Regards, Frediano From no-reply at appveyor.com Sat Oct 6 14:19:48 2018 From: no-reply at appveyor.com (AppVeyor) Date: Sat, 06 Oct 2018 18:19:48 +0000 Subject: [freetds] Build completed: freetds 1176 Message-ID: <20181006181948.1.F32275CB83D7D648@appveyor.com> From sf at 4js.com Wed Oct 10 06:04:35 2018 From: sf at 4js.com (Sebastien FLAESCH) Date: Wed, 10 Oct 2018 12:04:35 +0200 Subject: [freetds] SQLExecDirect() + SQLDataParam() + SQLPutData() fails In-Reply-To: References: <468b6021-9fb9-2738-ae70-1618b035490c@4js.com> Message-ID: <491221b9-7168-a513-6d7b-1aceeae2ceaf@4js.com> Hello! Regarding this fix in Branch-1_00, where can I download sources ready for compilation? https://github.com/FreeTDS/freetds/tree/Branch-1_00 Once compiled and installed, how can I distinguish a 1.00 installation with and without the fix? I see there are only major tags: https://github.com/FreeTDS/freetds/tags What is the policy? "Just always keep it up to date with Branch-1_00" ? Cheers, Seb On 9/11/18 10:42 PM, Frediano Ziglio wrote: > Il giorno sab 30 giu 2018 alle ore 13:07 Sebastien FLAESCH > ha scritto: >> >> Attached, the code example to reproduce: >> >> When using SQLPrepare() + SQLExecute(): >> >> $ gcc -D USE_PREP_EXEC -o odbctest3.bin odbctest3.c ... >> >> $ ./odbctest3.bin >> >> prepare insert... >> >> bind ... >> >> execute... >> >> param data... >> >>>>> put varchar(max) >> >> param data... >> >> >> When using SQLExecDirect(): >> >> $ gcc -o odbctest3.bin odbctest3.c ... >> >> $ ./odbctest3.bin >> >> bind ... >> >> exec direct... >> >> param data... >> >>>>> put varchar(max) >> Error -1 at: SQLPutData 1 >> Diagnostic info: >> SQL State: HY010 >> SQL code : 0 >> Message : [FreeTDS][SQL Server]Function sequence error >> >> >> What is wrong in my ODBC function sequence? >> >> Cheers, >> Seb >> >> >> On 06/29/2018 03:09 PM, Sebastien FLAESCH wrote: >>> Hi all, >>> >>> Just asking before sending a little code sample to reproduce: >>> >>> Is there a know limitation regarding VARCHAR(MAX)/VARBINARY(MAX) parameters >>> and SQLExecDirect() + SQLParamData() + SQLPutData() ? >>> >>> When using SQLPrepare() + SQLExecute() + SQLParamData() + SQLPutData(), I can >>> send Large Objects, but with SQLExecDirect(), I get the error: >>> >>> [FreeTDS][SQL Server]Function sequence error >>> >>> When doing the first SQLPutData() ... >>> >>> Seb > > Sorry for the delay, very easy to fix. Fixed in Branch-1_00 and master. > I'll integrate the test. > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds > From sf at 4js.com Wed Oct 10 06:17:54 2018 From: sf at 4js.com (Sebastien FLAESCH) Date: Wed, 10 Oct 2018 12:17:54 +0200 Subject: [freetds] SQLExecDirect() + SQLDataParam() + SQLPutData() fails In-Reply-To: <491221b9-7168-a513-6d7b-1aceeae2ceaf@4js.com> References: <468b6021-9fb9-2738-ae70-1618b035490c@4js.com> <491221b9-7168-a513-6d7b-1aceeae2ceaf@4js.com> Message-ID: <6f828620-1665-9b93-260f-abba28458a46@4js.com> I have downloaded 1.00.104 from: http://www.freetds.org/files/stable/ But where can I find that the fix is in a given version? Seb On 10/10/18 12:04 PM, Sebastien FLAESCH wrote: > Hello! > > Regarding this fix in Branch-1_00, where can I download sources ready > for compilation? > > https://github.com/FreeTDS/freetds/tree/Branch-1_00 > > Once compiled and installed, how can I distinguish a 1.00 installation > with and without the fix? > > I see there are only major tags: > > https://github.com/FreeTDS/freetds/tags > > What is the policy? > > "Just always keep it up to date with Branch-1_00" ? > > Cheers, > Seb > > On 9/11/18 10:42 PM, Frediano Ziglio wrote: >> Il giorno sab 30 giu 2018 alle ore 13:07 Sebastien FLAESCH >> ha scritto: >>> >>> Attached, the code example to reproduce: >>> >>> When using SQLPrepare() + SQLExecute(): >>> >>> $ gcc -D USE_PREP_EXEC -o odbctest3.bin odbctest3.c ... >>> >>> $ ./odbctest3.bin >>> ? >> prepare insert... >>> ? >> bind ... >>> ? >> execute... >>> ? >> param data... >>> ? >>>>> put varchar(max) >>> ? >> param data... >>> >>> >>> When using SQLExecDirect(): >>> >>> $ gcc -o odbctest3.bin odbctest3.c ... >>> >>> $ ./odbctest3.bin >>> ? >> bind ... >>> ? >> exec direct... >>> ? >> param data... >>> ? >>>>> put varchar(max) >>> Error -1 at: SQLPutData 1 >>> Diagnostic info: >>> ??? SQL State: HY010 >>> ??? SQL code : 0 >>> ??? Message? : [FreeTDS][SQL Server]Function sequence error >>> >>> >>> What is wrong in my ODBC function sequence? >>> >>> Cheers, >>> Seb >>> >>> >>> On 06/29/2018 03:09 PM, Sebastien FLAESCH wrote: >>>> Hi all, >>>> >>>> Just asking before sending a little code sample to reproduce: >>>> >>>> Is there a know limitation regarding VARCHAR(MAX)/VARBINARY(MAX) parameters >>>> and SQLExecDirect() + SQLParamData() + SQLPutData() ? >>>> >>>> When using SQLPrepare() + SQLExecute() + SQLParamData() + SQLPutData(), I can >>>> send Large Objects, but with SQLExecDirect(), I get the error: >>>> >>>> [FreeTDS][SQL Server]Function sequence error >>>> >>>> When doing the first SQLPutData() ... >>>> >>>> Seb >> >> Sorry for the delay, very easy to fix. Fixed in Branch-1_00 and master. >> I'll integrate the test. >> >> 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 sf at 4js.com Wed Oct 10 10:43:37 2018 From: sf at 4js.com (Sebastien FLAESCH) Date: Wed, 10 Oct 2018 16:43:37 +0200 Subject: [freetds] SQL_SUCCEEDED macro / SQL_NO_DATA for CREATE TABLE Message-ID: <525e6680-74d6-dcc9-d652-c20eb00c858e@4js.com> Hi all, Must have been discussed several times: Why does FreeTDS APIs return SQL_NO_DATA for an DDL SQL such as CREATE TABLE, when other ODBC drivers just return 0/SQL_SUCCESS (or 1/SQL_SUCCESS_WITH_INFO)? This prevents us to use the standard SQL_SUCCEEDED() macro. Seb From freddy77 at gmail.com Wed Oct 10 12:14:07 2018 From: freddy77 at gmail.com (Frediano Ziglio) Date: Wed, 10 Oct 2018 17:14:07 +0100 Subject: [freetds] SQLExecDirect() + SQLDataParam() + SQLPutData() fails In-Reply-To: <491221b9-7168-a513-6d7b-1aceeae2ceaf@4js.com> References: <468b6021-9fb9-2738-ae70-1618b035490c@4js.com> <491221b9-7168-a513-6d7b-1aceeae2ceaf@4js.com> Message-ID: Il giorno mer 10 ott 2018 alle ore 11:14 Sebastien FLAESCH ha scritto: > > Hello! > > Regarding this fix in Branch-1_00, where can I download sources ready > for compilation? > > https://github.com/FreeTDS/freetds/tree/Branch-1_00 > > Once compiled and installed, how can I distinguish a 1.00 installation > with and without the fix? > > I see there are only major tags: > > https://github.com/FreeTDS/freetds/tags > > What is the policy? > > "Just always keep it up to date with Branch-1_00" ? > Last stable branch is updated only with fixes. New commit get automatically packages, you can find links at www.freetds.org. For instance the "Stable Release" link on the main page will download always the last stable version. So I would say yes, keep up to date with the stable version. Frediano > Cheers, > Seb > > On 9/11/18 10:42 PM, Frediano Ziglio wrote: > > Il giorno sab 30 giu 2018 alle ore 13:07 Sebastien FLAESCH > > ha scritto: > >> > >> Attached, the code example to reproduce: > >> > >> When using SQLPrepare() + SQLExecute(): > >> > >> $ gcc -D USE_PREP_EXEC -o odbctest3.bin odbctest3.c ... > >> > >> $ ./odbctest3.bin > >> >> prepare insert... > >> >> bind ... > >> >> execute... > >> >> param data... > >> >>>>> put varchar(max) > >> >> param data... > >> > >> > >> When using SQLExecDirect(): > >> > >> $ gcc -o odbctest3.bin odbctest3.c ... > >> > >> $ ./odbctest3.bin > >> >> bind ... > >> >> exec direct... > >> >> param data... > >> >>>>> put varchar(max) > >> Error -1 at: SQLPutData 1 > >> Diagnostic info: > >> SQL State: HY010 > >> SQL code : 0 > >> Message : [FreeTDS][SQL Server]Function sequence error > >> > >> > >> What is wrong in my ODBC function sequence? > >> > >> Cheers, > >> Seb > >> > >> > >> On 06/29/2018 03:09 PM, Sebastien FLAESCH wrote: > >>> Hi all, > >>> > >>> Just asking before sending a little code sample to reproduce: > >>> > >>> Is there a know limitation regarding VARCHAR(MAX)/VARBINARY(MAX) parameters > >>> and SQLExecDirect() + SQLParamData() + SQLPutData() ? > >>> > >>> When using SQLPrepare() + SQLExecute() + SQLParamData() + SQLPutData(), I can > >>> send Large Objects, but with SQLExecDirect(), I get the error: > >>> > >>> [FreeTDS][SQL Server]Function sequence error > >>> > >>> When doing the first SQLPutData() ... > >>> > >>> Seb > > > > Sorry for the delay, very easy to fix. Fixed in Branch-1_00 and master. > > I'll integrate the test. > > From freddy77 at gmail.com Wed Oct 10 12:15:15 2018 From: freddy77 at gmail.com (Frediano Ziglio) Date: Wed, 10 Oct 2018 17:15:15 +0100 Subject: [freetds] SQLExecDirect() + SQLDataParam() + SQLPutData() fails In-Reply-To: <6f828620-1665-9b93-260f-abba28458a46@4js.com> References: <468b6021-9fb9-2738-ae70-1618b035490c@4js.com> <491221b9-7168-a513-6d7b-1aceeae2ceaf@4js.com> <6f828620-1665-9b93-260f-abba28458a46@4js.com> Message-ID: Il giorno mer 10 ott 2018 alle ore 11:18 Sebastien FLAESCH ha scritto: > > I have downloaded 1.00.104 from: > > http://www.freetds.org/files/stable/ > > But where can I find that the fix is in a given version? > Only checking the version, for instance with tsql -C. Never pop up into my mind that updating the NEWS file could be indeed helpful. > Seb > > On 10/10/18 12:04 PM, Sebastien FLAESCH wrote: > > Hello! > > > > Regarding this fix in Branch-1_00, where can I download sources ready > > for compilation? > > > > https://github.com/FreeTDS/freetds/tree/Branch-1_00 > > > > Once compiled and installed, how can I distinguish a 1.00 installation > > with and without the fix? > > > > I see there are only major tags: > > > > https://github.com/FreeTDS/freetds/tags > > > > What is the policy? > > > > "Just always keep it up to date with Branch-1_00" ? > > > > Cheers, > > Seb > > > > On 9/11/18 10:42 PM, Frediano Ziglio wrote: > >> Il giorno sab 30 giu 2018 alle ore 13:07 Sebastien FLAESCH > >> ha scritto: > >>> > >>> Attached, the code example to reproduce: > >>> > >>> When using SQLPrepare() + SQLExecute(): > >>> > >>> $ gcc -D USE_PREP_EXEC -o odbctest3.bin odbctest3.c ... > >>> > >>> $ ./odbctest3.bin > >>> >> prepare insert... > >>> >> bind ... > >>> >> execute... > >>> >> param data... > >>> >>>>> put varchar(max) > >>> >> param data... > >>> > >>> > >>> When using SQLExecDirect(): > >>> > >>> $ gcc -o odbctest3.bin odbctest3.c ... > >>> > >>> $ ./odbctest3.bin > >>> >> bind ... > >>> >> exec direct... > >>> >> param data... > >>> >>>>> put varchar(max) > >>> Error -1 at: SQLPutData 1 > >>> Diagnostic info: > >>> SQL State: HY010 > >>> SQL code : 0 > >>> Message : [FreeTDS][SQL Server]Function sequence error > >>> > >>> > >>> What is wrong in my ODBC function sequence? > >>> > >>> Cheers, > >>> Seb > >>> > >>> > >>> On 06/29/2018 03:09 PM, Sebastien FLAESCH wrote: > >>>> Hi all, > >>>> > >>>> Just asking before sending a little code sample to reproduce: > >>>> > >>>> Is there a know limitation regarding VARCHAR(MAX)/VARBINARY(MAX) parameters > >>>> and SQLExecDirect() + SQLParamData() + SQLPutData() ? > >>>> > >>>> When using SQLPrepare() + SQLExecute() + SQLParamData() + SQLPutData(), I can > >>>> send Large Objects, but with SQLExecDirect(), I get the error: > >>>> > >>>> [FreeTDS][SQL Server]Function sequence error > >>>> > >>>> When doing the first SQLPutData() ... > >>>> > >>>> Seb > >> > >> Sorry for the delay, very easy to fix. Fixed in Branch-1_00 and master. > >> I'll integrate the test. > >> > >> 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 sf at 4js.com Wed Oct 10 12:29:43 2018 From: sf at 4js.com (Sebastien FLAESCH) Date: Wed, 10 Oct 2018 18:29:43 +0200 Subject: [freetds] Asynchronous calls Message-ID: <9224e0e1-f15b-b221-6307-3f62cc4efce7@4js.com> Any chance to support asynchronous calls short term? https://docs.microsoft.com/en-us/sql/odbc/reference/develop-app/asynchronous-execution-polling-method?view=sql-server-2017 At least, for SQLExecDirect() / SQLExecute() ? Seb From ikorot01 at gmail.com Sun Oct 14 01:15:49 2018 From: ikorot01 at gmail.com (Igor Korot) Date: Sun, 14 Oct 2018 00:15:49 -0500 Subject: [freetds] Debugging Message-ID: Hi, Frediano, The page at https://docs.huihoo.com/freetds/user-guide/config.htm states: [quote] --disable-debug Debug-mode compiles are enabled by default, and will remain so at least until version 1.0. You can speed things up ever so slightly by disabling it. [/quote] Does this mean that starting from the version 1.00 debug builds are disabled by default? Or they are still enabled? Thank you. From freddy77 at gmail.com Mon Oct 15 13:31:52 2018 From: freddy77 at gmail.com (Frediano Ziglio) Date: Mon, 15 Oct 2018 18:31:52 +0100 Subject: [freetds] Debugging In-Reply-To: References: Message-ID: Il giorno dom 14 ott 2018 alle ore 18:16 Igor Korot ha scritto: > > Hi, Frediano, > The page at https://docs.huihoo.com/freetds/user-guide/config.htm states: > > [quote] > --disable-debug > > Debug-mode compiles are enabled by default, and will remain so at > least until version 1.0. You can speed things up ever so slightly by > disabling it. > [/quote] > > Does this mean that starting from the version 1.00 debug builds are > disabled by default? Or they are still enabled? > > Thank you. Hi, I would say good catch. They are still enabled by default. They enabled some assert in the code. I don't think would change much disabling them. The --enable-extra-checks (which actually is ignored if --disable-debug is used) is MUCH more expensive. I think Windows build by default have these debug disabled. Frediano From ikorot01 at gmail.com Mon Oct 15 13:37:50 2018 From: ikorot01 at gmail.com (Igor Korot) Date: Mon, 15 Oct 2018 12:37:50 -0500 Subject: [freetds] Debugging In-Reply-To: References: Message-ID: Hi, Frediano, On Mon, Oct 15, 2018 at 12:32 PM Frediano Ziglio wrote: > > Il giorno dom 14 ott 2018 alle ore 18:16 Igor Korot > ha scritto: > > > > Hi, Frediano, > > The page at https://docs.huihoo.com/freetds/user-guide/config.htm states: > > > > [quote] > > --disable-debug > > > > Debug-mode compiles are enabled by default, and will remain so at > > least until version 1.0. You can speed things up ever so slightly by > > disabling it. > > [/quote] > > > > Does this mean that starting from the version 1.00 debug builds are > > disabled by default? Or they are still enabled? > > > > Thank you. > > Hi, > I would say good catch. They are still enabled by default. They > enabled some assert in the code. So on Linux if I download the tarball and just do: ../configure && make the default will be "--enable-debug"? I'm asking because this is not what I see on my Gentoo box. It just does configure && make, but the configure line and later make commands does not include "-g/--enable-debug" options. Thank you. > I don't think would change much disabling them. > The --enable-extra-checks (which actually is ignored if > --disable-debug is used) is MUCH more > expensive. > I think Windows build by default have these debug disabled. > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds From freddy77 at gmail.com Fri Oct 19 07:08:27 2018 From: freddy77 at gmail.com (Frediano Ziglio) Date: Fri, 19 Oct 2018 12:08:27 +0100 Subject: [freetds] SQL_SUCCEEDED macro / SQL_NO_DATA for CREATE TABLE In-Reply-To: <525e6680-74d6-dcc9-d652-c20eb00c858e@4js.com> References: <525e6680-74d6-dcc9-d652-c20eb00c858e@4js.com> Message-ID: I think mostly historic reasons. I remember I wrote a macro that considered SQL_NO_DATA as success too to use in these cases. Is not clear the distinction between SQL_NO_DATA and SQL_SUCCESS in these cases, seems that for instance updates/inserts should return SQL_NO_DATA and not SQL_SUCCESS according to the documentation. Maybe would be good to check and change for version 1.1. Frediano Il giorno mer 10 ott 2018 alle ore 15:43 Sebastien FLAESCH ha scritto: > > Hi all, > > Must have been discussed several times: > > Why does FreeTDS APIs return SQL_NO_DATA for an DDL SQL such as > CREATE TABLE, when other ODBC drivers just return 0/SQL_SUCCESS > (or 1/SQL_SUCCESS_WITH_INFO)? > > This prevents us to use the standard SQL_SUCCEEDED() macro. > > Seb > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds From sf at 4js.com Fri Oct 19 10:35:17 2018 From: sf at 4js.com (Sebastien FLAESCH) Date: Fri, 19 Oct 2018 16:35:17 +0200 Subject: [freetds] SQL_SUCCEEDED macro / SQL_NO_DATA for CREATE TABLE In-Reply-To: References: <525e6680-74d6-dcc9-d652-c20eb00c858e@4js.com> Message-ID: Hi Frediano, Good point, I saw now in the doc that there is a different expectation with ODBC 2.x and ODBC 3.x! So that means that we should prepare the code to check for SQL_SUCCEEDED() or SQL_NO_DATA after SQLExec*() I guess you mean this macro: #define SQL_SUCCEEDED_EX(R) (((R) & 2) == 0) ODBC standard headers should then provide such macro to cover all valid return values. Seb On 10/19/18 1:08 PM, Frediano Ziglio wrote: > I think mostly historic reasons. > I remember I wrote a macro that considered SQL_NO_DATA as success too > to use in these cases. > Is not clear the distinction between SQL_NO_DATA and SQL_SUCCESS in > these cases, seems that for instance updates/inserts should return > SQL_NO_DATA and not SQL_SUCCESS according to the documentation. > Maybe would be good to check and change for version 1.1. > > Frediano > > Il giorno mer 10 ott 2018 alle ore 15:43 Sebastien FLAESCH > ha scritto: >> >> Hi all, >> >> Must have been discussed several times: >> >> Why does FreeTDS APIs return SQL_NO_DATA for an DDL SQL such as >> CREATE TABLE, when other ODBC drivers just return 0/SQL_SUCCESS >> (or 1/SQL_SUCCESS_WITH_INFO)? >> >> This prevents us to use the standard SQL_SUCCEEDED() macro. >> >> 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 no-reply at appveyor.com Mon Oct 22 14:27:04 2018 From: no-reply at appveyor.com (AppVeyor) Date: Mon, 22 Oct 2018 18:27:04 +0000 Subject: [freetds] Build failed: freetds 1202 Message-ID: <20181022182704.1.8F8B1E9E85B44752@appveyor.com> From no-reply at appveyor.com Tue Oct 23 05:21:19 2018 From: no-reply at appveyor.com (AppVeyor) Date: Tue, 23 Oct 2018 09:21:19 +0000 Subject: [freetds] Build failed: freetds 1208 Message-ID: <20181023092119.1.EA0C93DD9CAE960D@appveyor.com> From no-reply at appveyor.com Tue Oct 23 11:04:54 2018 From: no-reply at appveyor.com (AppVeyor) Date: Tue, 23 Oct 2018 15:04:54 +0000 Subject: [freetds] Build failed: freetds 1211 Message-ID: <20181023150454.1.38502937AA959BD1@appveyor.com> From ucko at ncbi.nlm.nih.gov Tue Oct 23 11:18:08 2018 From: ucko at ncbi.nlm.nih.gov (Ucko, Aaron (NIH/NLM/NCBI) [E]) Date: Tue, 23 Oct 2018 15:18:08 +0000 Subject: [freetds] Pending patches In-Reply-To: References: Message-ID: https://github.com/FreeTDS/freetds/pull/219 updated (rebased against c5b1299). To quote my latest comment there: Sorry for the delay, and thanks for cherry-picking a few more fixes in the mean time! -- Aaron Ucko , NCBI C++ Toolkit core development group -----Original Message----- From: Ucko, Aaron (NIH/NLM/NCBI) [E] Sent: Wednesday, August 22, 2018 11:40 To: Frediano Ziglio ; FreeTDS Development Group Subject: Re: [freetds] Pending patches Yes, I plan to when I get a chance, but have been busy (and intermittently out of the office) lately. Meanwhile, thanks again for the merges you've already done! -- Aaron Ucko , NCBI C++ Toolkit core development group -----Original Message----- From: Frediano Ziglio Sent: Saturday, August 11, 2018 03:08 To: Ucko, Aaron (NIH/NLM/NCBI) [E] ; FreeTDS Development Group Subject: Pending patches Hi Aaron, I'm starting to get confused on what was merged and what not. Can you rebase and send an updated pull request? Would be really helpful. Regards, Frediano _______________________________________________ FreeTDS mailing list FreeTDS at lists.ibiblio.org https://lists.ibiblio.org/mailman/listinfo/freetds From no-reply at appveyor.com Tue Oct 23 13:09:37 2018 From: no-reply at appveyor.com (AppVeyor) Date: Tue, 23 Oct 2018 17:09:37 +0000 Subject: [freetds] Build completed: freetds 1212 Message-ID: <20181023170937.1.D30C37B10D5D775D@appveyor.com> From no-reply at appveyor.com Tue Oct 23 13:23:43 2018 From: no-reply at appveyor.com (AppVeyor) Date: Tue, 23 Oct 2018 17:23:43 +0000 Subject: [freetds] Build failed: freetds 1213 Message-ID: <20181023172343.1.0187382BEFF8CF00@appveyor.com> From no-reply at appveyor.com Wed Oct 24 14:38:41 2018 From: no-reply at appveyor.com (AppVeyor) Date: Wed, 24 Oct 2018 18:38:41 +0000 Subject: [freetds] Build completed: freetds 1214 Message-ID: <20181024183841.1.E51FA522218A36E6@appveyor.com> From no-reply at appveyor.com Mon Nov 5 12:18:57 2018 From: no-reply at appveyor.com (AppVeyor) Date: Mon, 05 Nov 2018 17:18:57 +0000 Subject: [freetds] Build failed: freetds 1254 Message-ID: <20181105171857.1.13D68642F6A8832C@appveyor.com> From no-reply at appveyor.com Mon Nov 5 14:23:02 2018 From: no-reply at appveyor.com (AppVeyor) Date: Mon, 05 Nov 2018 19:23:02 +0000 Subject: [freetds] Build failed: freetds 1256 Message-ID: <20181105192302.1.7EAB63416EC1CA3E@appveyor.com> From no-reply at appveyor.com Mon Nov 5 19:43:19 2018 From: no-reply at appveyor.com (AppVeyor) Date: Tue, 06 Nov 2018 00:43:19 +0000 Subject: [freetds] Build failed: freetds 1260 Message-ID: <20181106004319.1.A2C8519FD815D681@appveyor.com> From freddy77 at gmail.com Fri Nov 30 16:43:37 2018 From: freddy77 at gmail.com (Frediano Ziglio) Date: Fri, 30 Nov 2018 21:43:37 +0000 Subject: [freetds] Asynchronous calls In-Reply-To: <9224e0e1-f15b-b221-6307-3f62cc4efce7@4js.com> References: <9224e0e1-f15b-b221-6307-3f62cc4efce7@4js.com> Message-ID: Il giorno mer 10 ott 2018 alle ore 17:29 Sebastien FLAESCH ha scritto: > > Any chance to support asynchronous calls short term? > > https://docs.microsoft.com/en-us/sql/odbc/reference/develop-app/asynchronous-execution-polling-method?view=sql-server-2017 > > At least, for SQLExecDirect() / SQLExecute() ? > > Seb Hi, sorry for very late reply. There's no plan, not much requests for this feature. I think the better option would be to use thread. I don't think you can support only for some function and not for something else. Frediano From qinx at microsoft.com Thu Dec 13 14:58:25 2018 From: qinx at microsoft.com (Rick Qing Xu) Date: Thu, 13 Dec 2018 19:58:25 +0000 Subject: [freetds] How to have a better control on how the tds use the openssl? Message-ID: 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://github.com/qinxgit From freddy77 at gmail.com Tue Dec 18 13:19:18 2018 From: freddy77 at gmail.com (Frediano Ziglio) Date: Tue, 18 Dec 2018 18:19:18 +0000 Subject: [freetds] How to have a better control on how the tds use the openssl? In-Reply-To: References: Message-ID: 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://github.com/qinxgit > 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 From qinx at microsoft.com Tue Dec 18 13:35:02 2018 From: qinx at microsoft.com (Rick Qing Xu) Date: Tue, 18 Dec 2018 18:35:02 +0000 Subject: [freetds] How to have a better control on how the tds use the openssl? In-Reply-To: References: Message-ID: 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 From freddy77 at gmail.com Fri Dec 21 17:39:17 2018 From: freddy77 at gmail.com (Frediano Ziglio) Date: Fri, 21 Dec 2018 22:39:17 +0000 Subject: [freetds] How to have a better control on how the tds use the openssl? In-Reply-To: References: Message-ID: 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 Il giorno mar 18 dic 2018 alle ore 18:35 Rick Qing Xu ha scritto: > > 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