From no-reply at appveyor.com Sun Apr 1 06:07:52 2018 From: no-reply at appveyor.com (AppVeyor) Date: Sun, 01 Apr 2018 10:07:52 +0000 Subject: [freetds] Build failed: freetds 1027 Message-ID: <20180401100752.1.0D6FD31EE4AC0638@appveyor.com> From no-reply at appveyor.com Sun Apr 1 06:13:28 2018 From: no-reply at appveyor.com (AppVeyor) Date: Sun, 01 Apr 2018 10:13:28 +0000 Subject: [freetds] Build completed: freetds 1028 Message-ID: <20180401101328.1.3C010FC788699BBF@appveyor.com> From no-reply at appveyor.com Tue Apr 3 17:35:16 2018 From: no-reply at appveyor.com (AppVeyor) Date: Tue, 03 Apr 2018 21:35:16 +0000 Subject: [freetds] Build failed: freetds 1031 Message-ID: <20180403213516.1.2CCE9971B611EBA4@appveyor.com> From no-reply at appveyor.com Tue Apr 3 18:46:41 2018 From: no-reply at appveyor.com (AppVeyor) Date: Tue, 03 Apr 2018 22:46:41 +0000 Subject: [freetds] Build completed: freetds 1034 Message-ID: <20180403224641.1.CF74B01AE129FDC5@appveyor.com> From sf at 4js.com Fri Apr 6 07:59:43 2018 From: sf at 4js.com (Sebastien FLAESCH) Date: Fri, 6 Apr 2018 13:59:43 +0200 Subject: [freetds] Smallmoney and money rounded to 2 decimals? Message-ID: <65d43a58-a873-b824-371b-3281e576e187@4js.com> Hi all, Using FreeTDS 1.00.9: When fetching a smallmoney or money data, SQLDescribeCol() returns the sqltype SQL_DECIMAL, precision 10 for smallmoney and or 19 for money and a scale of 4 for both types, which is fine, since smallmoney and money can store 4 decimal digits. Using an SQL_C_CHAR buffer to hold the values, we see that the decimal part is rounded to 2 digits... Is this expected? using other ODBC drivers for SQL Server we get 4 decimal digits. Is there some configuration settings to control this? Thanks! Seb From freddy77 at gmail.com Thu Apr 12 03:41:35 2018 From: freddy77 at gmail.com (Frediano Ziglio) Date: Thu, 12 Apr 2018 08:41:35 +0100 Subject: [freetds] Smallmoney and money rounded to 2 decimals? In-Reply-To: <65d43a58-a873-b824-371b-3281e576e187@4js.com> References: <65d43a58-a873-b824-371b-3281e576e187@4js.com> Message-ID: 2018-04-06 12:59 GMT+01:00 Sebastien FLAESCH : > Hi all, > > Using FreeTDS 1.00.9: > > When fetching a smallmoney or money data, SQLDescribeCol() returns > the sqltype SQL_DECIMAL, precision 10 for smallmoney and or 19 for > money and a scale of 4 for both types, which is fine, since smallmoney > and money can store 4 decimal digits. > > Using an SQL_C_CHAR buffer to hold the values, we see that the decimal > part is rounded to 2 digits... > > Is this expected? > > using other ODBC drivers for SQL Server we get 4 decimal digits. > > Is there some configuration settings to control this? > > Thanks! > Seb Just checked. Yes, apparently Microsoft ODBC drivers format money with 4 decimal digit. I think in the past tools used 2 digits but they moved to 4 along the way. There's actually no way to change that behavior but probably there should be. The 2 digits code is currently quite hard coded in src/tds/convert.c and src/tds/numeric.c. I suppose a good way would be to add a flag to TDSCONTEXT (which is used during conversion to pass locale information). Frediano From fredy at opag.ch Thu Apr 12 04:23:15 2018 From: fredy at opag.ch (Fredy Paquet) Date: Thu, 12 Apr 2018 10:23:15 +0200 Subject: [freetds] Smallmoney and money rounded to 2 decimals? In-Reply-To: References: <65d43a58-a873-b824-371b-3281e576e187@4js.com> Message-ID: <1523521395.5105.1.camel@opag.ch> The original Sybase drivers have a similar problem. Sybase internally calculates with 4 digits, but all text export (BCP) routines render only 2 digits. On Thu, 2018-04-12 at 08:41 +0100, Frediano Ziglio wrote: > 2018-04-06 12:59 GMT+01:00 Sebastien FLAESCH : > > Hi all, > > > > Using FreeTDS 1.00.9: > > > > When fetching a smallmoney or money data, SQLDescribeCol() returns > > the sqltype SQL_DECIMAL, precision 10 for smallmoney and or 19 for > > money and a scale of 4 for both types, which is fine, since > > smallmoney > > and money can store 4 decimal digits. > > > > Using an SQL_C_CHAR buffer to hold the values, we see that the > > decimal > > part is rounded to 2 digits... > > > > Is this expected? > > > > using other ODBC drivers for SQL Server we get 4 decimal digits. > > > > Is there some configuration settings to control this? > > > > Thanks! > > Seb > > Just checked. Yes, apparently Microsoft ODBC drivers format money > with > 4 decimal digit. > I think in the past tools used 2 digits but they moved to 4 along the > way. > There's actually no way to change that behavior but probably there > should be. > The 2 digits code is currently quite hard coded in src/tds/convert.c > and src/tds/numeric.c. > I suppose a good way would be to add a flag to TDSCONTEXT (which is > used during conversion to pass locale information). > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3480 bytes Desc: not available URL: From sf at 4js.com Thu Apr 12 04:37:43 2018 From: sf at 4js.com (Sebastien FLAESCH) Date: Thu, 12 Apr 2018 10:37:43 +0200 Subject: [freetds] Smallmoney and money rounded to 2 decimals? In-Reply-To: References: <65d43a58-a873-b824-371b-3281e576e187@4js.com> Message-ID: <111f0128-5280-d1d0-e3cf-be04c7ec109c@4js.com> On 04/12/2018 09:41 AM, Frediano Ziglio wrote: > 2018-04-06 12:59 GMT+01:00 Sebastien FLAESCH : >> Hi all, >> >> Using FreeTDS 1.00.9: >> >> When fetching a smallmoney or money data, SQLDescribeCol() returns >> the sqltype SQL_DECIMAL, precision 10 for smallmoney and or 19 for >> money and a scale of 4 for both types, which is fine, since smallmoney >> and money can store 4 decimal digits. >> >> Using an SQL_C_CHAR buffer to hold the values, we see that the decimal >> part is rounded to 2 digits... >> >> Is this expected? >> >> using other ODBC drivers for SQL Server we get 4 decimal digits. >> >> Is there some configuration settings to control this? >> >> Thanks! >> Seb > > Just checked. Yes, apparently Microsoft ODBC drivers format money with > 4 decimal digit. > I think in the past tools used 2 digits but they moved to 4 along the way. > There's actually no way to change that behavior but probably there should be. > The 2 digits code is currently quite hard coded in src/tds/convert.c > and src/tds/numeric.c. > I suppose a good way would be to add a flag to TDSCONTEXT (which is > used during conversion to pass locale information). > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds > Hello Frediano, and thanks for considering this! I am not familiar with FreeTDS code internals and TDSCONTEXT. I you want to keep backward compatibility, I assume that there will be a new ODBC connection attribute to control that. http://www.freetds.org/userguide/odbcconnattr.htm And if we consider the current behavior as a bug, the default should be 4 decimal digits, and people expecting 2 will have to define the parameter. MoneyFormatDecDigits=2 You may also consider rounding issues: Currently FreeTDS rounds to 2 digits... What happens with a db value like 0.1160 ? To be fetched as 0.12, or as 0.11 ? When 0.11, is this data loss or ok? It's monetary data! I vote for a bug => return always 4 digits. Seb From freddy77 at gmail.com Mon Apr 16 05:39:12 2018 From: freddy77 at gmail.com (Frediano Ziglio) Date: Mon, 16 Apr 2018 10:39:12 +0100 Subject: [freetds] Smallmoney and money rounded to 2 decimals? In-Reply-To: <111f0128-5280-d1d0-e3cf-be04c7ec109c@4js.com> References: <65d43a58-a873-b824-371b-3281e576e187@4js.com> <111f0128-5280-d1d0-e3cf-be04c7ec109c@4js.com> Message-ID: 2018-04-12 9:37 GMT+01:00 Sebastien FLAESCH : > On 04/12/2018 09:41 AM, Frediano Ziglio wrote: >> >> 2018-04-06 12:59 GMT+01:00 Sebastien FLAESCH : >>> >>> Hi all, >>> >>> Using FreeTDS 1.00.9: >>> >>> When fetching a smallmoney or money data, SQLDescribeCol() returns >>> the sqltype SQL_DECIMAL, precision 10 for smallmoney and or 19 for >>> money and a scale of 4 for both types, which is fine, since smallmoney >>> and money can store 4 decimal digits. >>> >>> Using an SQL_C_CHAR buffer to hold the values, we see that the decimal >>> part is rounded to 2 digits... >>> >>> Is this expected? >>> >>> using other ODBC drivers for SQL Server we get 4 decimal digits. >>> >>> Is there some configuration settings to control this? >>> >>> Thanks! >>> Seb >> >> >> Just checked. Yes, apparently Microsoft ODBC drivers format money with >> 4 decimal digit. >> I think in the past tools used 2 digits but they moved to 4 along the way. >> There's actually no way to change that behavior but probably there should >> be. >> The 2 digits code is currently quite hard coded in src/tds/convert.c >> and src/tds/numeric.c. >> I suppose a good way would be to add a flag to TDSCONTEXT (which is >> used during conversion to pass locale information). >> >> Frediano >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> https://lists.ibiblio.org/mailman/listinfo/freetds >> > > Hello Frediano, and thanks for considering this! > > I am not familiar with FreeTDS code internals and TDSCONTEXT. > > I you want to keep backward compatibility, I assume that there will be a new > ODBC connection attribute to control that. > > http://www.freetds.org/userguide/odbcconnattr.htm > > And if we consider the current behavior as a bug, the default should be 4 > decimal > digits, and people expecting 2 will have to define the parameter. > > MoneyFormatDecDigits=2 > > You may also consider rounding issues: > Currently FreeTDS rounds to 2 digits... > What happens with a db value like 0.1160 ? > To be fetched as 0.12, or as 0.11 ? > When 0.11, is this data loss or ok? > It's monetary data! > > I vote for a bug => return always 4 digits. > > > Seb Got some patches in both Branch-1_00 and master. On master ODBC uses always 4 digits. I'm considering if this should be backported too. Maybe I should just use 4 digits by default, I don't see much breakage, also considering Fredy comment on BCP exporting/importing MONEY with bcp surrently is loosing precision, which is not something we want. Frediano From sf at 4js.com Mon Apr 16 05:45:40 2018 From: sf at 4js.com (Sebastien FLAESCH) Date: Mon, 16 Apr 2018 11:45:40 +0200 Subject: [freetds] Smallmoney and money rounded to 2 decimals? In-Reply-To: References: <65d43a58-a873-b824-371b-3281e576e187@4js.com> <111f0128-5280-d1d0-e3cf-be04c7ec109c@4js.com> Message-ID: <3aee7335-e0fe-d521-eb20-f6a0871d4f09@4js.com> On 04/16/2018 11:39 AM, Frediano Ziglio wrote: > 2018-04-12 9:37 GMT+01:00 Sebastien FLAESCH : >> On 04/12/2018 09:41 AM, Frediano Ziglio wrote: >>> >>> 2018-04-06 12:59 GMT+01:00 Sebastien FLAESCH : >>>> >>>> Hi all, >>>> >>>> Using FreeTDS 1.00.9: >>>> >>>> When fetching a smallmoney or money data, SQLDescribeCol() returns >>>> the sqltype SQL_DECIMAL, precision 10 for smallmoney and or 19 for >>>> money and a scale of 4 for both types, which is fine, since smallmoney >>>> and money can store 4 decimal digits. >>>> >>>> Using an SQL_C_CHAR buffer to hold the values, we see that the decimal >>>> part is rounded to 2 digits... >>>> >>>> Is this expected? >>>> >>>> using other ODBC drivers for SQL Server we get 4 decimal digits. >>>> >>>> Is there some configuration settings to control this? >>>> >>>> Thanks! >>>> Seb >>> >>> >>> Just checked. Yes, apparently Microsoft ODBC drivers format money with >>> 4 decimal digit. >>> I think in the past tools used 2 digits but they moved to 4 along the way. >>> There's actually no way to change that behavior but probably there should >>> be. >>> The 2 digits code is currently quite hard coded in src/tds/convert.c >>> and src/tds/numeric.c. >>> I suppose a good way would be to add a flag to TDSCONTEXT (which is >>> used during conversion to pass locale information). >>> >>> Frediano >>> _______________________________________________ >>> FreeTDS mailing list >>> FreeTDS at lists.ibiblio.org >>> https://lists.ibiblio.org/mailman/listinfo/freetds >>> >> >> Hello Frediano, and thanks for considering this! >> >> I am not familiar with FreeTDS code internals and TDSCONTEXT. >> >> I you want to keep backward compatibility, I assume that there will be a new >> ODBC connection attribute to control that. >> >> http://www.freetds.org/userguide/odbcconnattr.htm >> >> And if we consider the current behavior as a bug, the default should be 4 >> decimal >> digits, and people expecting 2 will have to define the parameter. >> >> MoneyFormatDecDigits=2 >> >> You may also consider rounding issues: >> Currently FreeTDS rounds to 2 digits... >> What happens with a db value like 0.1160 ? >> To be fetched as 0.12, or as 0.11 ? >> When 0.11, is this data loss or ok? >> It's monetary data! >> >> I vote for a bug => return always 4 digits. >> >> >> Seb > > Got some patches in both Branch-1_00 and master. > On master ODBC uses always 4 digits. I'm considering if this should be > backported too. > Maybe I should just use 4 digits by default, I don't see much > breakage, also considering > Fredy comment on BCP exporting/importing MONEY with bcp surrently is loosing > precision, which is not something we want. > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds > Hi Frediano! Sounds good... thanks a lot. Seb From john at capps.com Tue May 8 23:43:02 2018 From: john at capps.com (John Kendall) Date: Wed, 9 May 2018 03:43:02 +0000 Subject: [freetds] Win64 ODBC driver Linked Server for MSSQL 2012 Message-ID: <41AC4B0A-A79F-4AEC-84D2-447A31E12CA2@capps.com> I have MS SQL Server 2012 (named CASTOR) running on Windows Server 2012 R2. I want to link some servers to it using the FreeTDS ODBC driver. I've had success with 3 different licensed ($) ODBC drivers, so I know I'm doing the setup right. The FreeTDS ODBC driver almost works. Here's an example select on a linked DSN (named PRODFTDS) created using the FreeTDS ODBC driver: select * from PRODFTDS...Movetype Msg 7399, Level 16, State 1 Server 'CASTOR', Line 1 The OLE DB provider "MSDASQL" for linked server "PRODFTDS" reported an error. The provider reported an unexpected catastrophic failure. Msg 7330, Level 16, State 2 Server 'CASTOR', Line 1 Cannot fetch a row from OLE DB provider "MSDASQL" for linked server "PRODFTDS". movetype move_desc move_revenue -------- -------------------- ------------ The table Movetype has 3 columns and their names are correctly returned, but that's all that is returned. I installed Win32OpenSSL 1.1.0h. I've used various versions of the ODBC driver from the AppVeyor site, Ramiro's 0.95 branch, and one I compiled myself with mingw. They all do the same thing. Can anyone verify that they have had success with the FreeTDS Win64 ODBC driver for a MSSQL Linked Server? Did I miss an important step? inconv maybe? The SQL Server logs show a stack dump that reports an access violation. Some of it is shown below. I can show more if it would be helpful. I'm not sure how to do a TDSDUMP with ODBC on Windows... Thanks, John SqlDumpExceptionHandler: Process 64 generated fatal exception c0000005 EXCEPTION_ACCESS_VIOLATION. SQL Server is terminating this process. * ******************************************************************************* * * BEGIN STACK DUMP: * 05/08/18 20:15:26 spid 64 * * * Exception Address = 000000006F7840B5 Module(tdsodbc+00000000000040B5) * Exception Code = c0000005 EXCEPTION_ACCESS_VIOLATION * Access Violation occurred writing address 0000000000000090 * Input Buffer 70 bytes - * select * from PRODFTDS...Movetype * * ... From freddy77 at gmail.com Wed May 9 13:03:27 2018 From: freddy77 at gmail.com (Frediano Ziglio) Date: Wed, 9 May 2018 18:03:27 +0100 Subject: [freetds] Win64 ODBC driver Linked Server for MSSQL 2012 In-Reply-To: <41AC4B0A-A79F-4AEC-84D2-447A31E12CA2@capps.com> References: <41AC4B0A-A79F-4AEC-84D2-447A31E12CA2@capps.com> Message-ID: 2018-05-09 4:43 GMT+01:00 John Kendall : > > I have MS SQL Server 2012 (named CASTOR) running on Windows Server 2012 R2. > I want to link some servers to it using the FreeTDS ODBC driver. > I've had success with 3 different licensed ($) ODBC drivers, so I know I'm doing the setup right. > > The FreeTDS ODBC driver almost works. Here's an example select on a linked DSN (named PRODFTDS) created using the FreeTDS ODBC driver: > > select * from PRODFTDS...Movetype > Msg 7399, Level 16, State 1 > Server 'CASTOR', Line 1 > The OLE DB provider "MSDASQL" for linked server "PRODFTDS" reported an error. The provider reported an unexpected catastrophic failure. > Msg 7330, Level 16, State 2 > Server 'CASTOR', Line 1 > Cannot fetch a row from OLE DB provider "MSDASQL" for linked server "PRODFTDS". > movetype move_desc move_revenue > -------- -------------------- ------------ > > The table Movetype has 3 columns and their names are correctly returned, but that's all that is returned. > > I installed Win32OpenSSL 1.1.0h. I've used various versions of the ODBC driver from the AppVeyor site, Ramiro's 0.95 branch, and one I compiled myself with mingw. They all do the same thing. > Ramiro's work was integrated in the main repository, you can get some updated zip files at https://ci.appveyor.com/project/FreeTDS/freetds/build/1053 for instance. > Can anyone verify that they have had success with the FreeTDS Win64 ODBC driver for a MSSQL Linked Server? Did I miss an important step? inconv maybe? > > The SQL Server logs show a stack dump that reports an access violation. Some of it is shown below. I can show more if it would be helpful. I'm not sure how to do a TDSDUMP with ODBC on Windows... > > Thanks, > John > I suppose you can use DumpFile ODBC connection attribute registering the linked server manually (there is sp_addlinkedserver store procedure to do it, there should be a way to retrieve also the current connection string, I don't remember much the details, maybe they are stored in master..sysservers?). > > SqlDumpExceptionHandler: Process 64 generated fatal exception c0000005 EXCEPTION_ACCESS_VIOLATION. SQL Server is terminating this process. > * ******************************************************************************* > * > * BEGIN STACK DUMP: > * 05/08/18 20:15:26 spid 64 > * > * > * Exception Address = 000000006F7840B5 Module(tdsodbc+00000000000040B5) > * Exception Code = c0000005 EXCEPTION_ACCESS_VIOLATION > * Access Violation occurred writing address 0000000000000090 > * Input Buffer 70 bytes - > * select * from PRODFTDS...Movetype > * > * Maybe you can enable the mini dumps and analyze with Visual Studio? Frediano From ucko at ncbi.nlm.nih.gov Wed Jun 6 17:28:23 2018 From: ucko at ncbi.nlm.nih.gov (Ucko, Aaron (NIH/NLM/NCBI) [E]) Date: Wed, 6 Jun 2018 21:28:23 +0000 Subject: [freetds] Reintegrating years of local FreeTDS changes Message-ID: Long story short, I am the primary maintainer of a convenience (aka vendorized) copy of FreeTDS's client libraries that has accumulated some local changes over the years. I have now forward-ported these changes to your master branch and would belatedly like to submit them for your consideration, both because they may also be of interest to other users and to make future releases easier to integrate. Some of the developers who contributed to (the original versions of) these changes have moved on to other jobs, but we were all working on behalf of the US federal government, which cannot hold copyright, so there shouldn't be any legal concerns; I'm just citing them in (so far unpublished) Git metadata to give credit where credit's due. I tested these changes via your test suite against both Microsoft SQL Server and Sybase ASE, and observed no regressions, just one failure that turned out to be preexisting (specifically, of the ODBC utf8_2 test against Microsoft SQL Server). We currently have Microsoft SQL Server 2014 and 2017 and Sybase ASE 15.5 and 16.0 on hand, and additionally tested many of these changes against older server versions too. That said, in a few cases (some predating my involvement with this code), we made deliberate changes to semantics. In such cases, I've updated the test suite accordingly. However, if you don't agree with these changes, I can of course instead arrange to make them conditional in some fashion; please let me know whether I should do so for any or all of these changes. I have grouped these changes into 59 patches. Please don't take this count as criticism of your code, which works well for the most part; we've just been sitting on our changes for entirely too long and gradually accumulating more along the way. Also, I suspect our needs are somewhat atypical -- we use the CT-LIB interface, and do so via a home-grown abstraction library rather than directly from application code. How would you like me to proceed? Should I send the patches here, or put them online through a GitHub fork? In the latter case, should I proceed to issue a formal pull request? Here's a quick rundown: * Fix miscellaneous configuration-specific issues, mostly on Windows. * Enable automatic TDS protocol version detection. * thread.h (tds_mutex_trylock): Disallow recursive locking on Windows. * tds_iconv: Accommodate FreeBSD/Citrus iconv. * net.c (tds_socket_write): Don't let fake short writes break headers. * Fix unit tests that manipulate raw network connections. * cancel.c: Skip return_data tests with Sybase 15+. * numeric.c: Don't force TDS 5.0 (DBVERSION_100). * threadsafe.c (tds_getservice): Set AI_CANONNAME where available. * dblib.c: Honor dbsetversion; improve dbcolinfo and dbwritetext. * odbc.c (SQLSetEnvAttr): Uncomment SQL_ATTR_OUTPUT_NTS-handling code. * ct.c (ct_describe): Populate datafmt->format per Valgrind. * connectparams.c (odbc_parse_connect_string): Handle client_charset. * ct.c (ct_connect): Set client_charset in addition to server_charset. * tds_process_tokens: For DONEPROC, always restore rows_affected. * Implement blk_textxfer, over a resumable tds_bcp_send_record. * query.c: Handle return codes of tds_put_data and tds_put_data_info. * net.c: Improve handling of certain error conditions. * ctlib: Handle CS_TIMEOUT and CS_LOGIN_TIMEOUT. * ct.c (_ct_get_server_type): Handle CS_LONGCHAR_TYPE. * blk.c (_blk_get_col_data): Use on-server size for destfmt.maxlength. * ct.c (ct_cursor): Predict cursor type for CS_CURSOR_DECLARE. * Fix server timeout handling and ctlib severity propagation. * Don't log directly to stdout or stderr. * blk.c: Handle CS_BLK_CANCEL in blk_done. * cs_convert, dbconvert: Truncate data as needed; update unit tests. * ct.c (ct_data_info): Encode/decode CS_IODESC datatype field. * ctlib: Work with non-NULL empty strings if the server supports them. * ctlib: Implement full Unicode support for TDS 7+ (MSSQL). * Improve support for TDS 5 (Sybase), mainly around bulk transfers. * Improve TDS 5 (Sybase) LONGBINARY and LONGCHAR handling. * Address miscellaneous compiler warnings. * Report system errors' descriptions to ctlib clients. * mem.c (tds_deinit_bcpinfo): Free and reset current_row for xfers in. * read.c (tds_get_n): Avoid potential hangs on short replies. * tds_checks.c (tds_check_column_extra): Skip size check for BLOBs. * Address Clang static analyzer errors, many long-standing. * Improve CTLIB support for TDS 7.2+. * cs.c (cs_convert): Fix *resultlen for conversions to SYBIMAGE. * bulk.c (tds_bcp_send_record): Reject invalid NULL data. * ctlib: Optimize blob conversion for bulk transfers in. * Declare and implement blk_sethints(_ver95). * data.c (tds_generic_row_len): Account for column_varint_size. * ct.c (ct_get_data): Populate cmd->iodesc->name more efficiently. * mem.c (tds_init_login): Enable use_utf16 by default. * query.c (tds_fix_column_size): Allow full size for output columns. * login.c (SET_FIELD_DSTR, for tds7_send_login): Cap lengths at 128. * tds/u.t./common.c (try_tds_login): Pass base name to tds_set_app. * Address more issues caught by LLVM/Clang scan-build. * odbc.c (odbc_process_tokens): Pre-zero done_flags per Valgrind. * threadsafe.c (tds_get_homedir/_WIN32): Initialize path. * data.c (tds_set_param_type): Under TDS 7.1+, send SYBBIT as SYBINT1. * ct.c (paraminfoalloc): Report long variable-width values. * packet.c (tds_write_packet): fix a TDS_ADDITIONAL_SPACE corner case. * tds5_process_dyn_result2: Don't trust Sybase to accept blob params. * net.c (tds_close_socket): Don't try to close invalid sockets. * stream.c (tds_datain_stream_read): Bail if tds_get_n returns NULL. * login.c (tds_connect): Skip non-TCP tries to connect to a host:port. * Address gaps in ctlib support for new MS date/time types. -- Aaron Ucko , NCBI C++ Toolkit core development group From ucko at ncbi.nlm.nih.gov Thu Jun 7 08:12:29 2018 From: ucko at ncbi.nlm.nih.gov (Ucko, Aaron (NIH/NLM/NCBI) [E]) Date: Thu, 7 Jun 2018 12:12:29 +0000 Subject: [freetds] Reintegrating years of local FreeTDS changes Message-ID: Long story short, I am the primary maintainer of a convenience (aka vendorized) copy of FreeTDS's client libraries that has accumulated some local changes over the years. I have now forward-ported these changes to your master branch and would belatedly like to submit them for your consideration, both because they may also be of interest to other users and to make future releases easier to integrate. Some of the developers who contributed to (the original versions of) these changes have moved on to other jobs, but we were all working on behalf of the US federal government, which cannot hold copyright, so there shouldn't be any legal concerns; I'm just citing them in (so far unpublished) Git metadata to give credit where credit's due. I tested these changes via your test suite against both Microsoft SQL Server and Sybase ASE, and observed no regressions, just one failure that turned out to be preexisting (specifically, of the ODBC utf8_2 test against Microsoft SQL Server). We currently have Microsoft SQL Server 2014 and 2017 and Sybase ASE 15.5 and 16.0 on hand, and additionally tested many of these changes against older server versions too. That said, in a few cases (some predating my involvement with this code), we made deliberate changes to semantics. In such cases, I've updated the test suite accordingly. However, if you don't agree with these changes, I can of course instead arrange to make them conditional in some fashion; please let me know whether I should do so for any or all of these changes. I have grouped these changes into 59 patches. Please don't take this count as criticism of your code, which works well for the most part; we've just been sitting on our changes for entirely too long and gradually accumulating more along the way. Also, I suspect our needs are somewhat atypical -- we use the CT-LIB interface, and do so via a home-grown abstraction library rather than directly from application code. How would you like me to proceed? Should I send the patches here, or put them online through a GitHub fork? In the latter case, should I proceed to issue a formal pull request? Here's a quick rundown: * Fix miscellaneous configuration-specific issues, mostly on Windows. * Enable automatic TDS protocol version detection. * thread.h (tds_mutex_trylock): Disallow recursive locking on Windows. * tds_iconv: Accommodate FreeBSD/Citrus iconv. * net.c (tds_socket_write): Don't let fake short writes break headers. * Fix unit tests that manipulate raw network connections. * cancel.c: Skip return_data tests with Sybase 15+. * numeric.c: Don't force TDS 5.0 (DBVERSION_100). * threadsafe.c (tds_getservice): Set AI_CANONNAME where available. * dblib.c: Honor dbsetversion; improve dbcolinfo and dbwritetext. * odbc.c (SQLSetEnvAttr): Uncomment SQL_ATTR_OUTPUT_NTS-handling code. * ct.c (ct_describe): Populate datafmt->format per Valgrind. * connectparams.c (odbc_parse_connect_string): Handle client_charset. * ct.c (ct_connect): Set client_charset in addition to server_charset. * tds_process_tokens: For DONEPROC, always restore rows_affected. * Implement blk_textxfer, over a resumable tds_bcp_send_record. * query.c: Handle return codes of tds_put_data and tds_put_data_info. * net.c: Improve handling of certain error conditions. * ctlib: Handle CS_TIMEOUT and CS_LOGIN_TIMEOUT. * ct.c (_ct_get_server_type): Handle CS_LONGCHAR_TYPE. * blk.c (_blk_get_col_data): Use on-server size for destfmt.maxlength. * ct.c (ct_cursor): Predict cursor type for CS_CURSOR_DECLARE. * Fix server timeout handling and ctlib severity propagation. * Don't log directly to stdout or stderr. * blk.c: Handle CS_BLK_CANCEL in blk_done. * cs_convert, dbconvert: Truncate data as needed; update unit tests. * ct.c (ct_data_info): Encode/decode CS_IODESC datatype field. * ctlib: Work with non-NULL empty strings if the server supports them. * ctlib: Implement full Unicode support for TDS 7+ (MSSQL). * Improve support for TDS 5 (Sybase), mainly around bulk transfers. * Improve TDS 5 (Sybase) LONGBINARY and LONGCHAR handling. * Address miscellaneous compiler warnings. * Report system errors' descriptions to ctlib clients. * mem.c (tds_deinit_bcpinfo): Free and reset current_row for xfers in. * read.c (tds_get_n): Avoid potential hangs on short replies. * tds_checks.c (tds_check_column_extra): Skip size check for BLOBs. * Address Clang static analyzer errors, many long-standing. * Improve CTLIB support for TDS 7.2+. * cs.c (cs_convert): Fix *resultlen for conversions to SYBIMAGE. * bulk.c (tds_bcp_send_record): Reject invalid NULL data. * ctlib: Optimize blob conversion for bulk transfers in. * Declare and implement blk_sethints(_ver95). * data.c (tds_generic_row_len): Account for column_varint_size. * ct.c (ct_get_data): Populate cmd->iodesc->name more efficiently. * mem.c (tds_init_login): Enable use_utf16 by default. * query.c (tds_fix_column_size): Allow full size for output columns. * login.c (SET_FIELD_DSTR, for tds7_send_login): Cap lengths at 128. * tds/u.t./common.c (try_tds_login): Pass base name to tds_set_app. * Address more issues caught by LLVM/Clang scan-build. * odbc.c (odbc_process_tokens): Pre-zero done_flags per Valgrind. * threadsafe.c (tds_get_homedir/_WIN32): Initialize path. * data.c (tds_set_param_type): Under TDS 7.1+, send SYBBIT as SYBINT1. * ct.c (paraminfoalloc): Report long variable-width values. * packet.c (tds_write_packet): fix a TDS_ADDITIONAL_SPACE corner case. * tds5_process_dyn_result2: Don't trust Sybase to accept blob params. * net.c (tds_close_socket): Don't try to close invalid sockets. * stream.c (tds_datain_stream_read): Bail if tds_get_n returns NULL. * login.c (tds_connect): Skip non-TCP tries to connect to a host:port. * Address gaps in ctlib support for new MS date/time types. -- Aaron Ucko , NCBI C++ Toolkit core development group From fredy at opag.ch Tue Jun 19 09:57:19 2018 From: fredy at opag.ch (Fredy Paquet) Date: Tue, 19 Jun 2018 15:57:19 +0200 Subject: [freetds] Reintegrating years of local FreeTDS changes In-Reply-To: References: Message-ID: <1529416639.7111.5.camel@opag.ch> Hello Ucko Will your patched code compile and run on different operating systems? - Linux 32/64 Bit ? - Windows MinGW 32/64 Bit ? regards fp On Wed, 2018-06-06 at 21:28 +0000, Ucko, Aaron (NIH/NLM/NCBI) [E] via FreeTDS wrote: > Long story short, I am the primary maintainer of a convenience (aka > vendorized) copy of FreeTDS's client libraries that has accumulated > some > local changes over the years.??I have now forward-ported these > changes > to your master branch and would belatedly like to submit them for > your > consideration, both because they may also be of interest to other > users > and to make future releases easier to integrate. > > Some of the developers who contributed to (the original versions of) > these changes have moved on to other jobs, but we were all working on > behalf of the US federal government, which cannot hold copyright, so > there shouldn't be any legal concerns; I'm just citing them in (so > far > unpublished) Git metadata to give credit where credit's due. > > I tested these changes via your test suite against both Microsoft SQL > Server and Sybase ASE, and observed no regressions, just one failure > that turned out to be preexisting (specifically, of the ODBC utf8_2 > test > against Microsoft SQL Server).??We currently have Microsoft SQL > Server > 2014 and 2017 and Sybase ASE 15.5 and 16.0 on hand, and additionally > tested many of these changes against older server versions too.??That > said, in a few cases (some predating my involvement with this code), > we > made deliberate changes to semantics.??In such cases, I've updated > the > test suite accordingly.??However, if you don't agree with these > changes, > I can of course instead arrange to make them conditional in some > fashion; please let me know whether I should do so for any or all of > these changes. > > I have grouped these changes into 59 patches.??Please don't take this > count as criticism of your code, which works well for the most part; > we've just been sitting on our changes for entirely too long and > gradually accumulating more along the way.??Also, I suspect our needs > are somewhat atypical -- we use the CT-LIB interface, and do so via a > home-grown abstraction library rather than directly from application > code. > > How would you like me to proceed???Should I send the patches here, or > put them online through a GitHub fork???In the latter case, should I > proceed to issue a formal pull request? > > Here's a quick rundown: > > * Fix miscellaneous configuration-specific issues, mostly on Windows. > * Enable automatic TDS protocol version detection. > * thread.h (tds_mutex_trylock): Disallow recursive locking on > Windows. > * tds_iconv: Accommodate FreeBSD/Citrus iconv. > * net.c (tds_socket_write): Don't let fake short writes break > headers. > * Fix unit tests that manipulate raw network connections. > * cancel.c: Skip return_data tests with Sybase 15+. > * numeric.c: Don't force TDS 5.0 (DBVERSION_100). > * threadsafe.c (tds_getservice): Set AI_CANONNAME where available. > * dblib.c: Honor dbsetversion; improve dbcolinfo and dbwritetext. > * odbc.c (SQLSetEnvAttr): Uncomment SQL_ATTR_OUTPUT_NTS-handling > code. > * ct.c (ct_describe): Populate datafmt->format per Valgrind. > * connectparams.c (odbc_parse_connect_string): Handle client_charset. > * ct.c (ct_connect): Set client_charset in addition to > server_charset. > * tds_process_tokens: For DONEPROC, always restore rows_affected. > * Implement blk_textxfer, over a resumable tds_bcp_send_record. > * query.c: Handle return codes of tds_put_data and tds_put_data_info. > * net.c: Improve handling of certain error conditions. > * ctlib: Handle CS_TIMEOUT and CS_LOGIN_TIMEOUT. > * ct.c (_ct_get_server_type): Handle CS_LONGCHAR_TYPE. > * blk.c (_blk_get_col_data): Use on-server size for > destfmt.maxlength. > * ct.c (ct_cursor): Predict cursor type for CS_CURSOR_DECLARE. > * Fix server timeout handling and ctlib severity propagation. > * Don't log directly to stdout or stderr. > * blk.c: Handle CS_BLK_CANCEL in blk_done. > * cs_convert, dbconvert: Truncate data as needed; update unit tests. > * ct.c (ct_data_info): Encode/decode CS_IODESC datatype field. > * ctlib: Work with non-NULL empty strings if the server supports > them. > * ctlib: Implement full Unicode support for TDS 7+ (MSSQL). > * Improve support for TDS 5 (Sybase), mainly around bulk transfers. > * Improve TDS 5 (Sybase) LONGBINARY and LONGCHAR handling. > * Address miscellaneous compiler warnings. > * Report system errors' descriptions to ctlib clients. > * mem.c (tds_deinit_bcpinfo): Free and reset current_row for xfers > in. > * read.c (tds_get_n): Avoid potential hangs on short replies. > * tds_checks.c (tds_check_column_extra): Skip size check for BLOBs. > * Address Clang static analyzer errors, many long-standing. > * Improve CTLIB support for TDS 7.2+. > * cs.c (cs_convert): Fix *resultlen for conversions to SYBIMAGE. > * bulk.c (tds_bcp_send_record): Reject invalid NULL data. > * ctlib: Optimize blob conversion for bulk transfers in. > * Declare and implement blk_sethints(_ver95). > * data.c (tds_generic_row_len): Account for column_varint_size. > * ct.c (ct_get_data): Populate cmd->iodesc->name more efficiently. > * mem.c (tds_init_login): Enable use_utf16 by default. > * query.c (tds_fix_column_size): Allow full size for output columns. > * login.c (SET_FIELD_DSTR, for tds7_send_login): Cap lengths at 128. > * tds/u.t./common.c (try_tds_login): Pass base name to tds_set_app. > * Address more issues caught by LLVM/Clang scan-build. > * odbc.c (odbc_process_tokens): Pre-zero done_flags per Valgrind. > * threadsafe.c (tds_get_homedir/_WIN32): Initialize path. > * data.c (tds_set_param_type): Under TDS 7.1+, send SYBBIT as > SYBINT1. > * ct.c (paraminfoalloc): Report long variable-width values. > * packet.c (tds_write_packet): fix a TDS_ADDITIONAL_SPACE corner > case. > * tds5_process_dyn_result2: Don't trust Sybase to accept blob params. > * net.c (tds_close_socket): Don't try to close invalid sockets. > * stream.c (tds_datain_stream_read): Bail if tds_get_n returns NULL. > * login.c (tds_connect): Skip non-TCP tries to connect to a > host:port. > * Address gaps in ctlib support for new MS date/time types. > -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3480 bytes Desc: not available URL: From freddy77 at gmail.com Wed Jun 20 04:58:25 2018 From: freddy77 at gmail.com (Frediano Ziglio) Date: Wed, 20 Jun 2018 09:58:25 +0100 Subject: [freetds] Reintegrating years of local FreeTDS changes In-Reply-To: References: Message-ID: Hi, a pull request seems good. Didn't read the full list, I expect some to be small, some other larger. I usually keep the vendor behavior if I can. Regards, Frediano 2018-06-06 22:28 GMT+01:00 Ucko, Aaron (NIH/NLM/NCBI) [E] via FreeTDS : > Long story short, I am the primary maintainer of a convenience (aka > vendorized) copy of FreeTDS's client libraries that has accumulated some > local changes over the years. I have now forward-ported these changes > to your master branch and would belatedly like to submit them for your > consideration, both because they may also be of interest to other users > and to make future releases easier to integrate. > > Some of the developers who contributed to (the original versions of) > these changes have moved on to other jobs, but we were all working on > behalf of the US federal government, which cannot hold copyright, so > there shouldn't be any legal concerns; I'm just citing them in (so far > unpublished) Git metadata to give credit where credit's due. > > I tested these changes via your test suite against both Microsoft SQL > Server and Sybase ASE, and observed no regressions, just one failure > that turned out to be preexisting (specifically, of the ODBC utf8_2 test > against Microsoft SQL Server). We currently have Microsoft SQL Server > 2014 and 2017 and Sybase ASE 15.5 and 16.0 on hand, and additionally > tested many of these changes against older server versions too. That > said, in a few cases (some predating my involvement with this code), we > made deliberate changes to semantics. In such cases, I've updated the > test suite accordingly. However, if you don't agree with these changes, > I can of course instead arrange to make them conditional in some > fashion; please let me know whether I should do so for any or all of > these changes. > > I have grouped these changes into 59 patches. Please don't take this > count as criticism of your code, which works well for the most part; > we've just been sitting on our changes for entirely too long and > gradually accumulating more along the way. Also, I suspect our needs > are somewhat atypical -- we use the CT-LIB interface, and do so via a > home-grown abstraction library rather than directly from application > code. > > How would you like me to proceed? Should I send the patches here, or > put them online through a GitHub fork? In the latter case, should I > proceed to issue a formal pull request? > > Here's a quick rundown: > > * Fix miscellaneous configuration-specific issues, mostly on Windows. > * Enable automatic TDS protocol version detection. > * thread.h (tds_mutex_trylock): Disallow recursive locking on Windows. > * tds_iconv: Accommodate FreeBSD/Citrus iconv. > * net.c (tds_socket_write): Don't let fake short writes break headers. > * Fix unit tests that manipulate raw network connections. > * cancel.c: Skip return_data tests with Sybase 15+. > * numeric.c: Don't force TDS 5.0 (DBVERSION_100). > * threadsafe.c (tds_getservice): Set AI_CANONNAME where available. > * dblib.c: Honor dbsetversion; improve dbcolinfo and dbwritetext. > * odbc.c (SQLSetEnvAttr): Uncomment SQL_ATTR_OUTPUT_NTS-handling code. > * ct.c (ct_describe): Populate datafmt->format per Valgrind. > * connectparams.c (odbc_parse_connect_string): Handle client_charset. > * ct.c (ct_connect): Set client_charset in addition to server_charset. > * tds_process_tokens: For DONEPROC, always restore rows_affected. > * Implement blk_textxfer, over a resumable tds_bcp_send_record. > * query.c: Handle return codes of tds_put_data and tds_put_data_info. > * net.c: Improve handling of certain error conditions. > * ctlib: Handle CS_TIMEOUT and CS_LOGIN_TIMEOUT. > * ct.c (_ct_get_server_type): Handle CS_LONGCHAR_TYPE. > * blk.c (_blk_get_col_data): Use on-server size for destfmt.maxlength. > * ct.c (ct_cursor): Predict cursor type for CS_CURSOR_DECLARE. > * Fix server timeout handling and ctlib severity propagation. > * Don't log directly to stdout or stderr. > * blk.c: Handle CS_BLK_CANCEL in blk_done. > * cs_convert, dbconvert: Truncate data as needed; update unit tests. > * ct.c (ct_data_info): Encode/decode CS_IODESC datatype field. > * ctlib: Work with non-NULL empty strings if the server supports them. > * ctlib: Implement full Unicode support for TDS 7+ (MSSQL). > * Improve support for TDS 5 (Sybase), mainly around bulk transfers. > * Improve TDS 5 (Sybase) LONGBINARY and LONGCHAR handling. > * Address miscellaneous compiler warnings. > * Report system errors' descriptions to ctlib clients. > * mem.c (tds_deinit_bcpinfo): Free and reset current_row for xfers in. > * read.c (tds_get_n): Avoid potential hangs on short replies. > * tds_checks.c (tds_check_column_extra): Skip size check for BLOBs. > * Address Clang static analyzer errors, many long-standing. > * Improve CTLIB support for TDS 7.2+. > * cs.c (cs_convert): Fix *resultlen for conversions to SYBIMAGE. > * bulk.c (tds_bcp_send_record): Reject invalid NULL data. > * ctlib: Optimize blob conversion for bulk transfers in. > * Declare and implement blk_sethints(_ver95). > * data.c (tds_generic_row_len): Account for column_varint_size. > * ct.c (ct_get_data): Populate cmd->iodesc->name more efficiently. > * mem.c (tds_init_login): Enable use_utf16 by default. > * query.c (tds_fix_column_size): Allow full size for output columns. > * login.c (SET_FIELD_DSTR, for tds7_send_login): Cap lengths at 128. > * tds/u.t./common.c (try_tds_login): Pass base name to tds_set_app. > * Address more issues caught by LLVM/Clang scan-build. > * odbc.c (odbc_process_tokens): Pre-zero done_flags per Valgrind. > * threadsafe.c (tds_get_homedir/_WIN32): Initialize path. > * data.c (tds_set_param_type): Under TDS 7.1+, send SYBBIT as SYBINT1. > * ct.c (paraminfoalloc): Report long variable-width values. > * packet.c (tds_write_packet): fix a TDS_ADDITIONAL_SPACE corner case. > * tds5_process_dyn_result2: Don't trust Sybase to accept blob params. > * net.c (tds_close_socket): Don't try to close invalid sockets. > * stream.c (tds_datain_stream_read): Bail if tds_get_n returns NULL. > * login.c (tds_connect): Skip non-TCP tries to connect to a host:port. > * Address gaps in ctlib support for new MS date/time types. > > -- > Aaron Ucko , NCBI C++ Toolkit core development group > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds From ucko at ncbi.nlm.nih.gov Fri Jun 15 10:04:33 2018 From: ucko at ncbi.nlm.nih.gov (Aaron Ucko) Date: Fri, 15 Jun 2018 10:04:33 -0400 Subject: [freetds] Reintegrating years of local FreeTDS changes Message-ID: Long story short, I am the primary maintainer of a convenience (aka vendorized) copy of FreeTDS's client libraries that has accumulated some local changes over the years. I have now forward-ported these changes to your master branch and would belatedly like to submit them for your consideration, both because they may also be of interest to other users and to make future releases easier to integrate. Some of the developers who contributed to (the original versions of) these changes have moved on to other jobs, but we were all working on behalf of the US federal government, which cannot hold copyright, so there shouldn't be any legal concerns; I'm just citing them in (so far unpublished) Git metadata to give credit where credit's due. I tested these changes via your test suite against both Microsoft SQL Server and Sybase ASE, and observed no regressions, just one failure that turned out to be preexisting (specifically, of the ODBC utf8_2 test against Microsoft SQL Server). We currently have Microsoft SQL Server 2014 and 2017 and Sybase ASE 15.5 and 16.0 on hand, and additionally tested many of these changes against older server versions too. That said, in a few cases (some predating my involvement with this code), we made deliberate changes to semantics. In such cases, I've updated the test suite accordingly. However, if you don't agree with these changes, I can of course instead arrange to make them conditional in some fashion; please let me know whether I should do so for any or all of these changes. I have grouped these changes into 59 patches. Please don't take this count as criticism of your code, which works well for the most part; we've just been sitting on our changes for entirely too long and gradually accumulating more along the way. Also, I suspect our needs are somewhat atypical -- we use the CT-LIB interface, and do so via a home-grown abstraction library rather than directly from application code. How would you like me to proceed? Should I send the patches here, or put them online through a GitHub fork? In the latter case, should I proceed to issue a formal pull request? Here's a quick rundown: * Fix miscellaneous configuration-specific issues, mostly on Windows. * Enable automatic TDS protocol version detection. * thread.h (tds_mutex_trylock): Disallow recursive locking on Windows. * tds_iconv: Accommodate FreeBSD/Citrus iconv. * net.c (tds_socket_write): Don't let fake short writes break headers. * Fix unit tests that manipulate raw network connections. * cancel.c: Skip return_data tests with Sybase 15+. * numeric.c: Don't force TDS 5.0 (DBVERSION_100). * threadsafe.c (tds_getservice): Set AI_CANONNAME where available. * dblib.c: Honor dbsetversion; improve dbcolinfo and dbwritetext. * odbc.c (SQLSetEnvAttr): Uncomment SQL_ATTR_OUTPUT_NTS-handling code. * ct.c (ct_describe): Populate datafmt->format per Valgrind. * connectparams.c (odbc_parse_connect_string): Handle client_charset. * ct.c (ct_connect): Set client_charset in addition to server_charset. * tds_process_tokens: For DONEPROC, always restore rows_affected. * Implement blk_textxfer, over a resumable tds_bcp_send_record. * query.c: Handle return codes of tds_put_data and tds_put_data_info. * net.c: Improve handling of certain error conditions. * ctlib: Handle CS_TIMEOUT and CS_LOGIN_TIMEOUT. * ct.c (_ct_get_server_type): Handle CS_LONGCHAR_TYPE. * blk.c (_blk_get_col_data): Use on-server size for destfmt.maxlength. * ct.c (ct_cursor): Predict cursor type for CS_CURSOR_DECLARE. * Fix server timeout handling and ctlib severity propagation. * Don't log directly to stdout or stderr. * blk.c: Handle CS_BLK_CANCEL in blk_done. * cs_convert, dbconvert: Truncate data as needed; update unit tests. * ct.c (ct_data_info): Encode/decode CS_IODESC datatype field. * ctlib: Work with non-NULL empty strings if the server supports them. * ctlib: Implement full Unicode support for TDS 7+ (MSSQL). * Improve support for TDS 5 (Sybase), mainly around bulk transfers. * Improve TDS 5 (Sybase) LONGBINARY and LONGCHAR handling. * Address miscellaneous compiler warnings. * Report system errors' descriptions to ctlib clients. * mem.c (tds_deinit_bcpinfo): Free and reset current_row for xfers in. * read.c (tds_get_n): Avoid potential hangs on short replies. * tds_checks.c (tds_check_column_extra): Skip size check for BLOBs. * Address Clang static analyzer errors, many long-standing. * Improve CTLIB support for TDS 7.2+. * cs.c (cs_convert): Fix *resultlen for conversions to SYBIMAGE. * bulk.c (tds_bcp_send_record): Reject invalid NULL data. * ctlib: Optimize blob conversion for bulk transfers in. * Declare and implement blk_sethints(_ver95). * data.c (tds_generic_row_len): Account for column_varint_size. * ct.c (ct_get_data): Populate cmd->iodesc->name more efficiently. * mem.c (tds_init_login): Enable use_utf16 by default. * query.c (tds_fix_column_size): Allow full size for output columns. * login.c (SET_FIELD_DSTR, for tds7_send_login): Cap lengths at 128. * tds/u.t./common.c (try_tds_login): Pass base name to tds_set_app. * Address more issues caught by LLVM/Clang scan-build. * odbc.c (odbc_process_tokens): Pre-zero done_flags per Valgrind. * threadsafe.c (tds_get_homedir/_WIN32): Initialize path. * data.c (tds_set_param_type): Under TDS 7.1+, send SYBBIT as SYBINT1. * ct.c (paraminfoalloc): Report long variable-width values. * packet.c (tds_write_packet): fix a TDS_ADDITIONAL_SPACE corner case. * tds5_process_dyn_result2: Don't trust Sybase to accept blob params. * net.c (tds_close_socket): Don't try to close invalid sockets. * stream.c (tds_datain_stream_read): Bail if tds_get_n returns NULL. * login.c (tds_connect): Skip non-TCP tries to connect to a host:port. * Address gaps in ctlib support for new MS date/time types. -- Aaron Ucko , NCBI C++ Toolkit core development group From ucko at ncbi.nlm.nih.gov Mon Jun 18 10:10:59 2018 From: ucko at ncbi.nlm.nih.gov (Ucko, Aaron (NIH/NLM/NCBI) [E]) Date: Mon, 18 Jun 2018 14:10:59 +0000 Subject: [freetds] Reintegrating years of local FreeTDS changes In-Reply-To: References: Message-ID: I?m trying to kickstart a (belated!) dialog, and would in particular appreciate outside review of my changes, which I understand will take time. Sorry for the double post, incidentally. -- Aaron Ucko , NCBI C++ Toolkit core development group From: Ken Collins [mailto:ken at actionmoniker.com] Sent: Monday, June 18, 2018 06:56 To: FreeTDS Development Group Cc: Ucko, Aaron (NIH/NLM/NCBI) [E] Subject: Re: [freetds] Reintegrating years of local FreeTDS changes Sounds like you need to be a co-maintainer and have a direct dialog and/or working relationship with the maintainers here. Have y'all ever had a discussion or is this the first time talking about all this work? - Ken On June 18, 2018 at 4:51:52 AM, Ucko, Aaron (NIH/NLM/NCBI) [E] via FreeTDS (freetds at lists.ibiblio.org) wrote: Long story short, I am the primary maintainer of a convenience (aka vendorized) copy of FreeTDS's client libraries that has accumulated some local changes over the years. I have now forward-ported these changes to your master branch and would belatedly like to submit them for your consideration, both because they may also be of interest to other users and to make future releases easier to integrate. Some of the developers who contributed to (the original versions of) these changes have moved on to other jobs, but we were all working on behalf of the US federal government, which cannot hold copyright, so there shouldn't be any legal concerns; I'm just citing them in (so far unpublished) Git metadata to give credit where credit's due. I tested these changes via your test suite against both Microsoft SQL Server and Sybase ASE, and observed no regressions, just one failure that turned out to be preexisting (specifically, of the ODBC utf8_2 test against Microsoft SQL Server). We currently have Microsoft SQL Server 2014 and 2017 and Sybase ASE 15.5 and 16.0 on hand, and additionally tested many of these changes against older server versions too. That said, in a few cases (some predating my involvement with this code), we made deliberate changes to semantics. In such cases, I've updated the test suite accordingly. However, if you don't agree with these changes, I can of course instead arrange to make them conditional in some fashion; please let me know whether I should do so for any or all of these changes. I have grouped these changes into 59 patches. Please don't take this count as criticism of your code, which works well for the most part; we've just been sitting on our changes for entirely too long and gradually accumulating more along the way. Also, I suspect our needs are somewhat atypical -- we use the CT-LIB interface, and do so via a home-grown abstraction library rather than directly from application code. How would you like me to proceed? Should I send the patches here, or put them online through a GitHub fork? In the latter case, should I proceed to issue a formal pull request? Here's a quick rundown: * Fix miscellaneous configuration-specific issues, mostly on Windows. * Enable automatic TDS protocol version detection. * thread.h (tds_mutex_trylock): Disallow recursive locking on Windows. * tds_iconv: Accommodate FreeBSD/Citrus iconv. * net.c (tds_socket_write): Don't let fake short writes break headers. * Fix unit tests that manipulate raw network connections. * cancel.c: Skip return_data tests with Sybase 15+. * numeric.c: Don't force TDS 5.0 (DBVERSION_100). * threadsafe.c (tds_getservice): Set AI_CANONNAME where available. * dblib.c: Honor dbsetversion; improve dbcolinfo and dbwritetext. * odbc.c (SQLSetEnvAttr): Uncomment SQL_ATTR_OUTPUT_NTS-handling code. * ct.c (ct_describe): Populate datafmt->format per Valgrind. * connectparams.c (odbc_parse_connect_string): Handle client_charset. * ct.c (ct_connect): Set client_charset in addition to server_charset. * tds_process_tokens: For DONEPROC, always restore rows_affected. * Implement blk_textxfer, over a resumable tds_bcp_send_record. * query.c: Handle return codes of tds_put_data and tds_put_data_info. * net.c: Improve handling of certain error conditions. * ctlib: Handle CS_TIMEOUT and CS_LOGIN_TIMEOUT. * ct.c (_ct_get_server_type): Handle CS_LONGCHAR_TYPE. * blk.c (_blk_get_col_data): Use on-server size for destfmt.maxlength. * ct.c (ct_cursor): Predict cursor type for CS_CURSOR_DECLARE. * Fix server timeout handling and ctlib severity propagation. * Don't log directly to stdout or stderr. * blk.c: Handle CS_BLK_CANCEL in blk_done. * cs_convert, dbconvert: Truncate data as needed; update unit tests. * ct.c (ct_data_info): Encode/decode CS_IODESC datatype field. * ctlib: Work with non-NULL empty strings if the server supports them. * ctlib: Implement full Unicode support for TDS 7+ (MSSQL). * Improve support for TDS 5 (Sybase), mainly around bulk transfers. * Improve TDS 5 (Sybase) LONGBINARY and LONGCHAR handling. * Address miscellaneous compiler warnings. * Report system errors' descriptions to ctlib clients. * mem.c (tds_deinit_bcpinfo): Free and reset current_row for xfers in. * read.c (tds_get_n): Avoid potential hangs on short replies. * tds_checks.c (tds_check_column_extra): Skip size check for BLOBs. * Address Clang static analyzer errors, many long-standing. * Improve CTLIB support for TDS 7.2+. * cs.c (cs_convert): Fix *resultlen for conversions to SYBIMAGE. * bulk.c (tds_bcp_send_record): Reject invalid NULL data. * ctlib: Optimize blob conversion for bulk transfers in. * Declare and implement blk_sethints(_ver95). * data.c (tds_generic_row_len): Account for column_varint_size. * ct.c (ct_get_data): Populate cmd->iodesc->name more efficiently. * mem.c (tds_init_login): Enable use_utf16 by default. * query.c (tds_fix_column_size): Allow full size for output columns. * login.c (SET_FIELD_DSTR, for tds7_send_login): Cap lengths at 128. * tds/u.t./common.c (try_tds_login): Pass base name to tds_set_app. * Address more issues caught by LLVM/Clang scan-build. * odbc.c (odbc_process_tokens): Pre-zero done_flags per Valgrind. * threadsafe.c (tds_get_homedir/_WIN32): Initialize path. * data.c (tds_set_param_type): Under TDS 7.1+, send SYBBIT as SYBINT1. * ct.c (paraminfoalloc): Report long variable-width values. * packet.c (tds_write_packet): fix a TDS_ADDITIONAL_SPACE corner case. * tds5_process_dyn_result2: Don't trust Sybase to accept blob params. * net.c (tds_close_socket): Don't try to close invalid sockets. * stream.c (tds_datain_stream_read): Bail if tds_get_n returns NULL. * login.c (tds_connect): Skip non-TCP tries to connect to a host:port. * Address gaps in ctlib support for new MS date/time types. -- Aaron Ucko , NCBI C++ Toolkit core development group _______________________________________________ FreeTDS mailing list FreeTDS at lists.ibiblio.org https://lists.ibiblio.org/mailman/listinfo/freetds From christos at zoulas.com Thu Jun 21 17:02:59 2018 From: christos at zoulas.com (Christos Zoulas) Date: Thu, 21 Jun 2018 17:02:59 -0400 Subject: [freetds] Reintegrating years of local FreeTDS changes In-Reply-To: from "Ucko, Aaron \(NIH/NLM/NCBI\) \[E\] via FreeTDS" (Jun 7, 12:12pm) Message-ID: <20180621210259.A896D17FDA1@rebar.astron.com> On Jun 7, 12:12pm, freetds at lists.ibiblio.org ("Ucko, Aaron \(NIH/NLM/NCBI\) \[E\] via FreeTDS") wrote: -- Subject: [freetds] Reintegrating years of local FreeTDS changes | How would you like me to proceed? Should I send the patches here, or | put them online through a GitHub fork? In the latter case, should I | proceed to issue a formal pull request? I am not Freddy, but I think that github sounds like the right way to proceed. Thanks for the offer! christos From freddy77 at gmail.com Fri Jun 22 18:22:00 2018 From: freddy77 at gmail.com (Frediano Ziglio) Date: Fri, 22 Jun 2018 23:22:00 +0100 Subject: [freetds] Reintegrating years of local FreeTDS changes In-Reply-To: <20180621210259.A896D17FDA1@rebar.astron.com> References: <20180621210259.A896D17FDA1@rebar.astron.com> Message-ID: Yes, agreed with GitHub. I though I already replied, apparently not. Frediano 2018-06-21 22:02 GMT+01:00 Christos Zoulas : > On Jun 7, 12:12pm, freetds at lists.ibiblio.org ("Ucko, Aaron \(NIH/NLM/NCBI\) \[E\] via FreeTDS") wrote: > -- Subject: [freetds] Reintegrating years of local FreeTDS changes > > | How would you like me to proceed? Should I send the patches here, or > | put them online through a GitHub fork? In the latter case, should I > | proceed to issue a formal pull request? > > I am not Freddy, but I think that github sounds like the right way to > proceed. Thanks for the offer! > > christos > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds From ucko at ncbi.nlm.nih.gov Mon Jun 25 10:59:15 2018 From: ucko at ncbi.nlm.nih.gov (Ucko, Aaron (NIH/NLM/NCBI) [E]) Date: Mon, 25 Jun 2018 14:59:15 +0000 Subject: [freetds] Reintegrating years of local FreeTDS changes In-Reply-To: References: Message-ID: Thanks for being open to these changes! I did get this first reply, but was having a busy week and wanted to take a closer look at the commits in which I patched unit tests before following up. Most of my commits to unit tests turned out to be pure formalities or setup fixes, but there is one commit that could well be an issue here: cs_convert, dbconvert: Truncate data as needed; update unit tests. * Automatically truncate strings that would overflow their destinations, mainly for the sake of bulk insertions. Notify the client at low severity (as a warning, essentially). Update upstream unit tests (ctlib t0006, dblib t0019) accordingly. * Fully honor *BINARY and IMAGE data buffer size limits in cs_convert. Running these tests against Sybase libraries (12.5, 15.7, and 16.0, with identical results in all cases), I see that these changes do go against upstream, but that there are already several other differences on this front for each API (details attached). I'll pull this commit out, at least for now. FWIW, there was also one commit for which I had to patch src/tds/unittests/convert.c, but not any higher-level unit tests: ctlib: Implement full Unicode support for TDS 7+ (MSSQL). * Introduce CS_NLONGCHAR_TYPE and CS_NVARCHAR_TYPE, both corresponding to SYBNVARCHAR (along with CS_UNICHAR_TYPE); have ct_param automatically promote CS_{LONG,VAR}CHAR_TYPE to CS_N{LONG,VAR}CHAR_TYPE for TDS 7+ when non-ASCII characters appear in the data. (Unnecessary use of Unicode types can make parameterized queries against 8-bit text columns run very slowly.) * ctlib/cs.c (cs_convert): Formally support Unicode destination types (SYBNVARCHAR and SYBNTEXT). * ctlib/ct.c (paraminfoalloc): When setting maximum length automatically, account for possible conversion to UCS-2. * tds/convert.c (tds_convert), tds/tds_willconvert.*: Formally support Unicode types, giving type 103 (0x67) the benefit of the doubt as SYBNVARCHAR rather than SYBSENSITIVITY. * tds/data.c (tds_set_param_type): Map SYBNVARCHAR to XSYBNVARCHAR for TDS 7+. * tds/unittests/convert.c: Accommodate Unicode types, converting ASCII input strings to (native-endian, is this correct?) UCS-2 as needed. -- Aaron Ucko , NCBI C++ Toolkit core development group -----Original Message----- From: Frediano Ziglio [mailto:freddy77 at gmail.com] Sent: Wednesday, June 20, 2018 04:58 To: FreeTDS Development Group Cc: Ucko, Aaron (NIH/NLM/NCBI) [E] Subject: Re: [freetds] Reintegrating years of local FreeTDS changes Hi, a pull request seems good. Didn't read the full list, I expect some to be small, some other larger. I usually keep the vendor behavior if I can. Regards, Frediano 2018-06-06 22:28 GMT+01:00 Ucko, Aaron (NIH/NLM/NCBI) [E] via FreeTDS : > Long story short, I am the primary maintainer of a convenience (aka > vendorized) copy of FreeTDS's client libraries that has accumulated some > local changes over the years. I have now forward-ported these changes > to your master branch and would belatedly like to submit them for your > consideration, both because they may also be of interest to other users > and to make future releases easier to integrate. > > Some of the developers who contributed to (the original versions of) > these changes have moved on to other jobs, but we were all working on > behalf of the US federal government, which cannot hold copyright, so > there shouldn't be any legal concerns; I'm just citing them in (so far > unpublished) Git metadata to give credit where credit's due. > > I tested these changes via your test suite against both Microsoft SQL > Server and Sybase ASE, and observed no regressions, just one failure > that turned out to be preexisting (specifically, of the ODBC utf8_2 test > against Microsoft SQL Server). We currently have Microsoft SQL Server > 2014 and 2017 and Sybase ASE 15.5 and 16.0 on hand, and additionally > tested many of these changes against older server versions too. That > said, in a few cases (some predating my involvement with this code), we > made deliberate changes to semantics. In such cases, I've updated the > test suite accordingly. However, if you don't agree with these changes, > I can of course instead arrange to make them conditional in some > fashion; please let me know whether I should do so for any or all of > these changes. > > I have grouped these changes into 59 patches. Please don't take this > count as criticism of your code, which works well for the most part; > we've just been sitting on our changes for entirely too long and > gradually accumulating more along the way. Also, I suspect our needs > are somewhat atypical -- we use the CT-LIB interface, and do so via a > home-grown abstraction library rather than directly from application > code. > > How would you like me to proceed? Should I send the patches here, or > put them online through a GitHub fork? In the latter case, should I > proceed to issue a formal pull request? > > Here's a quick rundown: > > * Fix miscellaneous configuration-specific issues, mostly on Windows. > * Enable automatic TDS protocol version detection. > * thread.h (tds_mutex_trylock): Disallow recursive locking on Windows. > * tds_iconv: Accommodate FreeBSD/Citrus iconv. > * net.c (tds_socket_write): Don't let fake short writes break headers. > * Fix unit tests that manipulate raw network connections. > * cancel.c: Skip return_data tests with Sybase 15+. > * numeric.c: Don't force TDS 5.0 (DBVERSION_100). > * threadsafe.c (tds_getservice): Set AI_CANONNAME where available. > * dblib.c: Honor dbsetversion; improve dbcolinfo and dbwritetext. > * odbc.c (SQLSetEnvAttr): Uncomment SQL_ATTR_OUTPUT_NTS-handling code. > * ct.c (ct_describe): Populate datafmt->format per Valgrind. > * connectparams.c (odbc_parse_connect_string): Handle client_charset. > * ct.c (ct_connect): Set client_charset in addition to server_charset. > * tds_process_tokens: For DONEPROC, always restore rows_affected. > * Implement blk_textxfer, over a resumable tds_bcp_send_record. > * query.c: Handle return codes of tds_put_data and tds_put_data_info. > * net.c: Improve handling of certain error conditions. > * ctlib: Handle CS_TIMEOUT and CS_LOGIN_TIMEOUT. > * ct.c (_ct_get_server_type): Handle CS_LONGCHAR_TYPE. > * blk.c (_blk_get_col_data): Use on-server size for destfmt.maxlength. > * ct.c (ct_cursor): Predict cursor type for CS_CURSOR_DECLARE. > * Fix server timeout handling and ctlib severity propagation. > * Don't log directly to stdout or stderr. > * blk.c: Handle CS_BLK_CANCEL in blk_done. > * cs_convert, dbconvert: Truncate data as needed; update unit tests. > * ct.c (ct_data_info): Encode/decode CS_IODESC datatype field. > * ctlib: Work with non-NULL empty strings if the server supports them. > * ctlib: Implement full Unicode support for TDS 7+ (MSSQL). > * Improve support for TDS 5 (Sybase), mainly around bulk transfers. > * Improve TDS 5 (Sybase) LONGBINARY and LONGCHAR handling. > * Address miscellaneous compiler warnings. > * Report system errors' descriptions to ctlib clients. > * mem.c (tds_deinit_bcpinfo): Free and reset current_row for xfers in. > * read.c (tds_get_n): Avoid potential hangs on short replies. > * tds_checks.c (tds_check_column_extra): Skip size check for BLOBs. > * Address Clang static analyzer errors, many long-standing. > * Improve CTLIB support for TDS 7.2+. > * cs.c (cs_convert): Fix *resultlen for conversions to SYBIMAGE. > * bulk.c (tds_bcp_send_record): Reject invalid NULL data. > * ctlib: Optimize blob conversion for bulk transfers in. > * Declare and implement blk_sethints(_ver95). > * data.c (tds_generic_row_len): Account for column_varint_size. > * ct.c (ct_get_data): Populate cmd->iodesc->name more efficiently. > * mem.c (tds_init_login): Enable use_utf16 by default. > * query.c (tds_fix_column_size): Allow full size for output columns. > * login.c (SET_FIELD_DSTR, for tds7_send_login): Cap lengths at 128. > * tds/u.t./common.c (try_tds_login): Pass base name to tds_set_app. > * Address more issues caught by LLVM/Clang scan-build. > * odbc.c (odbc_process_tokens): Pre-zero done_flags per Valgrind. > * threadsafe.c (tds_get_homedir/_WIN32): Initialize path. > * data.c (tds_set_param_type): Under TDS 7.1+, send SYBBIT as SYBINT1. > * ct.c (paraminfoalloc): Report long variable-width values. > * packet.c (tds_write_packet): fix a TDS_ADDITIONAL_SPACE corner case. > * tds5_process_dyn_result2: Don't trust Sybase to accept blob params. > * net.c (tds_close_socket): Don't try to close invalid sockets. > * stream.c (tds_datain_stream_read): Bail if tds_get_n returns NULL. > * login.c (tds_connect): Skip non-TCP tries to connect to a host:port. > * Address gaps in ctlib support for new MS date/time types. > > -- > Aaron Ucko , NCBI C++ Toolkit core development group > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ct_t0006-summary.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: db_t0019-summary.txt URL: From ucko at ncbi.nlm.nih.gov Mon Jun 25 11:08:18 2018 From: ucko at ncbi.nlm.nih.gov (Aaron Ucko) Date: Mon, 25 Jun 2018 11:08:18 -0400 Subject: [freetds] Reintegrating years of local FreeTDS changes In-Reply-To: <1529416639.7111.5.camel@opag.ch> (Fredy Paquet's message of "Tue, 19 Jun 2018 15:57:19 +0200") References: <1529416639.7111.5.camel@opag.ch> Message-ID: I haven't specifically tested this code on MinGW, but it builds on Windows under both Cygwin and Microsoft Visual Studio, and on Linux, macOS, and FreeBSD. As for word size, our builds have generally been in 64-bit mode lately; our only remaining 32-bit build is on a Linux host without access to our database servers. That said, the code compiles and passes its offline tests on that host, and much of it underwent (successful) fuller testing on 32-bit platforms back in the day. -- Aaron Ucko , NCBI C++ Toolkit core development group Fredy Paquet writes: > Hello Ucko > > Will your patched code compile and run on different operating systems? > > - Linux 32/64 Bit ? > - Windows MinGW 32/64 Bit ? > > regards > fp > > On Wed, 2018-06-06 at 21:28 +0000, Ucko, Aaron (NIH/NLM/NCBI) [E] via > FreeTDS wrote: >> Long story short, I am the primary maintainer of a convenience (aka >> vendorized) copy of FreeTDS's client libraries that has accumulated >> some >> local changes over the years.??I have now forward-ported these >> changes >> to your master branch and would belatedly like to submit them for >> your >> consideration, both because they may also be of interest to other >> users >> and to make future releases easier to integrate. >> >> Some of the developers who contributed to (the original versions of) >> these changes have moved on to other jobs, but we were all working on >> behalf of the US federal government, which cannot hold copyright, so >> there shouldn't be any legal concerns; I'm just citing them in (so >> far >> unpublished) Git metadata to give credit where credit's due. >> >> I tested these changes via your test suite against both Microsoft SQL >> Server and Sybase ASE, and observed no regressions, just one failure >> that turned out to be preexisting (specifically, of the ODBC utf8_2 >> test >> against Microsoft SQL Server).??We currently have Microsoft SQL >> Server >> 2014 and 2017 and Sybase ASE 15.5 and 16.0 on hand, and additionally >> tested many of these changes against older server versions too.??That >> said, in a few cases (some predating my involvement with this code), >> we >> made deliberate changes to semantics.??In such cases, I've updated >> the >> test suite accordingly.??However, if you don't agree with these >> changes, >> I can of course instead arrange to make them conditional in some >> fashion; please let me know whether I should do so for any or all of >> these changes. >> >> I have grouped these changes into 59 patches.??Please don't take this >> count as criticism of your code, which works well for the most part; >> we've just been sitting on our changes for entirely too long and >> gradually accumulating more along the way.??Also, I suspect our needs >> are somewhat atypical -- we use the CT-LIB interface, and do so via a >> home-grown abstraction library rather than directly from application >> code. >> >> How would you like me to proceed???Should I send the patches here, or >> put them online through a GitHub fork???In the latter case, should I >> proceed to issue a formal pull request? >> >> Here's a quick rundown: >> >> * Fix miscellaneous configuration-specific issues, mostly on Windows. >> * Enable automatic TDS protocol version detection. >> * thread.h (tds_mutex_trylock): Disallow recursive locking on >> Windows. >> * tds_iconv: Accommodate FreeBSD/Citrus iconv. >> * net.c (tds_socket_write): Don't let fake short writes break >> headers. >> * Fix unit tests that manipulate raw network connections. >> * cancel.c: Skip return_data tests with Sybase 15+. >> * numeric.c: Don't force TDS 5.0 (DBVERSION_100). >> * threadsafe.c (tds_getservice): Set AI_CANONNAME where available. >> * dblib.c: Honor dbsetversion; improve dbcolinfo and dbwritetext. >> * odbc.c (SQLSetEnvAttr): Uncomment SQL_ATTR_OUTPUT_NTS-handling >> code. >> * ct.c (ct_describe): Populate datafmt->format per Valgrind. >> * connectparams.c (odbc_parse_connect_string): Handle client_charset. >> * ct.c (ct_connect): Set client_charset in addition to >> server_charset. >> * tds_process_tokens: For DONEPROC, always restore rows_affected. >> * Implement blk_textxfer, over a resumable tds_bcp_send_record. >> * query.c: Handle return codes of tds_put_data and tds_put_data_info. >> * net.c: Improve handling of certain error conditions. >> * ctlib: Handle CS_TIMEOUT and CS_LOGIN_TIMEOUT. >> * ct.c (_ct_get_server_type): Handle CS_LONGCHAR_TYPE. >> * blk.c (_blk_get_col_data): Use on-server size for >> destfmt.maxlength. >> * ct.c (ct_cursor): Predict cursor type for CS_CURSOR_DECLARE. >> * Fix server timeout handling and ctlib severity propagation. >> * Don't log directly to stdout or stderr. >> * blk.c: Handle CS_BLK_CANCEL in blk_done. >> * cs_convert, dbconvert: Truncate data as needed; update unit tests. >> * ct.c (ct_data_info): Encode/decode CS_IODESC datatype field. >> * ctlib: Work with non-NULL empty strings if the server supports >> them. >> * ctlib: Implement full Unicode support for TDS 7+ (MSSQL). >> * Improve support for TDS 5 (Sybase), mainly around bulk transfers. >> * Improve TDS 5 (Sybase) LONGBINARY and LONGCHAR handling. >> * Address miscellaneous compiler warnings. >> * Report system errors' descriptions to ctlib clients. >> * mem.c (tds_deinit_bcpinfo): Free and reset current_row for xfers >> in. >> * read.c (tds_get_n): Avoid potential hangs on short replies. >> * tds_checks.c (tds_check_column_extra): Skip size check for BLOBs. >> * Address Clang static analyzer errors, many long-standing. >> * Improve CTLIB support for TDS 7.2+. >> * cs.c (cs_convert): Fix *resultlen for conversions to SYBIMAGE. >> * bulk.c (tds_bcp_send_record): Reject invalid NULL data. >> * ctlib: Optimize blob conversion for bulk transfers in. >> * Declare and implement blk_sethints(_ver95). >> * data.c (tds_generic_row_len): Account for column_varint_size. >> * ct.c (ct_get_data): Populate cmd->iodesc->name more efficiently. >> * mem.c (tds_init_login): Enable use_utf16 by default. >> * query.c (tds_fix_column_size): Allow full size for output columns. >> * login.c (SET_FIELD_DSTR, for tds7_send_login): Cap lengths at 128. >> * tds/u.t./common.c (try_tds_login): Pass base name to tds_set_app. >> * Address more issues caught by LLVM/Clang scan-build. >> * odbc.c (odbc_process_tokens): Pre-zero done_flags per Valgrind. >> * threadsafe.c (tds_get_homedir/_WIN32): Initialize path. >> * data.c (tds_set_param_type): Under TDS 7.1+, send SYBBIT as >> SYBINT1. >> * ct.c (paraminfoalloc): Report long variable-width values. >> * packet.c (tds_write_packet): fix a TDS_ADDITIONAL_SPACE corner >> case. >> * tds5_process_dyn_result2: Don't trust Sybase to accept blob params. >> * net.c (tds_close_socket): Don't try to close invalid sockets. >> * stream.c (tds_datain_stream_read): Bail if tds_get_n returns NULL. >> * login.c (tds_connect): Skip non-TCP tries to connect to a >> host:port. >> * Address gaps in ctlib support for new MS date/time types. >> From ucko at ncbi.nlm.nih.gov Mon Jun 25 15:47:23 2018 From: ucko at ncbi.nlm.nih.gov (Aaron Ucko) Date: Mon, 25 Jun 2018 15:47:23 -0400 Subject: [freetds] Reintegrating years of local FreeTDS changes In-Reply-To: (Aaron E. via FreeTDS Ucko's message of "Mon, 25 Jun 2018 14:59:15 +0000") References: Message-ID: OK, I created a pull request, with a few technical comments on metadata: https://github.com/FreeTDS/freetds/pull/219 -- Aaron Ucko , NCBI C++ Toolkit core development group "Ucko, Aaron (NIH/NLM/NCBI) [E] via FreeTDS" writes: > Thanks for being open to these changes! > > I did get this first reply, but was having a busy week and wanted to take a closer look at the commits in which I patched unit tests before following up. Most of my commits to unit tests turned out to be pure formalities or setup fixes, but there is one commit that could well be an issue here: > > cs_convert, dbconvert: Truncate data as needed; update unit tests. > > * Automatically truncate strings that would overflow their destinations, > mainly for the sake of bulk insertions. Notify the client at low > severity (as a warning, essentially). Update upstream unit tests > (ctlib t0006, dblib t0019) accordingly. > * Fully honor *BINARY and IMAGE data buffer size limits in cs_convert. > > Running these tests against Sybase libraries (12.5, 15.7, and 16.0, with identical results in all cases), I see that these changes do go against upstream, but that there are already several other differences on this front for each API (details attached). I'll pull this commit out, at least for now. > > FWIW, there was also one commit for which I had to patch src/tds/unittests/convert.c, but not any higher-level unit tests: > > ctlib: Implement full Unicode support for TDS 7+ (MSSQL). > > * Introduce CS_NLONGCHAR_TYPE and CS_NVARCHAR_TYPE, both corresponding to > SYBNVARCHAR (along with CS_UNICHAR_TYPE); have ct_param automatically > promote CS_{LONG,VAR}CHAR_TYPE to CS_N{LONG,VAR}CHAR_TYPE for TDS 7+ > when non-ASCII characters appear in the data. (Unnecessary use of > Unicode types can make parameterized queries against 8-bit text > columns run very slowly.) > * ctlib/cs.c (cs_convert): Formally support Unicode destination types > (SYBNVARCHAR and SYBNTEXT). > * ctlib/ct.c (paraminfoalloc): When setting maximum length automatically, > account for possible conversion to UCS-2. > * tds/convert.c (tds_convert), tds/tds_willconvert.*: Formally support > Unicode types, giving type 103 (0x67) the benefit of the doubt as > SYBNVARCHAR rather than SYBSENSITIVITY. > * tds/data.c (tds_set_param_type): Map SYBNVARCHAR to XSYBNVARCHAR for > TDS 7+. > * tds/unittests/convert.c: Accommodate Unicode types, converting ASCII > input strings to (native-endian, is this correct?) UCS-2 as needed. > > -- Aaron Ucko , NCBI C++ Toolkit core development group > > -----Original Message----- > From: Frediano Ziglio [mailto:freddy77 at gmail.com] > Sent: Wednesday, June 20, 2018 04:58 > To: FreeTDS Development Group > Cc: Ucko, Aaron (NIH/NLM/NCBI) [E] > Subject: Re: [freetds] Reintegrating years of local FreeTDS changes > > Hi, > a pull request seems good. > Didn't read the full list, I expect some to be small, some other larger. > I usually keep the vendor behavior if I can. > > Regards, > Frediano > > > 2018-06-06 22:28 GMT+01:00 Ucko, Aaron (NIH/NLM/NCBI) [E] via FreeTDS > : >> Long story short, I am the primary maintainer of a convenience (aka >> vendorized) copy of FreeTDS's client libraries that has accumulated some >> local changes over the years. I have now forward-ported these changes >> to your master branch and would belatedly like to submit them for your >> consideration, both because they may also be of interest to other users >> and to make future releases easier to integrate. >> >> Some of the developers who contributed to (the original versions of) >> these changes have moved on to other jobs, but we were all working on >> behalf of the US federal government, which cannot hold copyright, so >> there shouldn't be any legal concerns; I'm just citing them in (so far >> unpublished) Git metadata to give credit where credit's due. >> >> I tested these changes via your test suite against both Microsoft SQL >> Server and Sybase ASE, and observed no regressions, just one failure >> that turned out to be preexisting (specifically, of the ODBC utf8_2 test >> against Microsoft SQL Server). We currently have Microsoft SQL Server >> 2014 and 2017 and Sybase ASE 15.5 and 16.0 on hand, and additionally >> tested many of these changes against older server versions too. That >> said, in a few cases (some predating my involvement with this code), we >> made deliberate changes to semantics. In such cases, I've updated the >> test suite accordingly. However, if you don't agree with these changes, >> I can of course instead arrange to make them conditional in some >> fashion; please let me know whether I should do so for any or all of >> these changes. >> >> I have grouped these changes into 59 patches. Please don't take this >> count as criticism of your code, which works well for the most part; >> we've just been sitting on our changes for entirely too long and >> gradually accumulating more along the way. Also, I suspect our needs >> are somewhat atypical -- we use the CT-LIB interface, and do so via a >> home-grown abstraction library rather than directly from application >> code. >> >> How would you like me to proceed? Should I send the patches here, or >> put them online through a GitHub fork? In the latter case, should I >> proceed to issue a formal pull request? >> >> Here's a quick rundown: >> >> * Fix miscellaneous configuration-specific issues, mostly on Windows. >> * Enable automatic TDS protocol version detection. >> * thread.h (tds_mutex_trylock): Disallow recursive locking on Windows. >> * tds_iconv: Accommodate FreeBSD/Citrus iconv. >> * net.c (tds_socket_write): Don't let fake short writes break headers. >> * Fix unit tests that manipulate raw network connections. >> * cancel.c: Skip return_data tests with Sybase 15+. >> * numeric.c: Don't force TDS 5.0 (DBVERSION_100). >> * threadsafe.c (tds_getservice): Set AI_CANONNAME where available. >> * dblib.c: Honor dbsetversion; improve dbcolinfo and dbwritetext. >> * odbc.c (SQLSetEnvAttr): Uncomment SQL_ATTR_OUTPUT_NTS-handling code. >> * ct.c (ct_describe): Populate datafmt->format per Valgrind. >> * connectparams.c (odbc_parse_connect_string): Handle client_charset. >> * ct.c (ct_connect): Set client_charset in addition to server_charset. >> * tds_process_tokens: For DONEPROC, always restore rows_affected. >> * Implement blk_textxfer, over a resumable tds_bcp_send_record. >> * query.c: Handle return codes of tds_put_data and tds_put_data_info. >> * net.c: Improve handling of certain error conditions. >> * ctlib: Handle CS_TIMEOUT and CS_LOGIN_TIMEOUT. >> * ct.c (_ct_get_server_type): Handle CS_LONGCHAR_TYPE. >> * blk.c (_blk_get_col_data): Use on-server size for destfmt.maxlength. >> * ct.c (ct_cursor): Predict cursor type for CS_CURSOR_DECLARE. >> * Fix server timeout handling and ctlib severity propagation. >> * Don't log directly to stdout or stderr. >> * blk.c: Handle CS_BLK_CANCEL in blk_done. >> * cs_convert, dbconvert: Truncate data as needed; update unit tests. >> * ct.c (ct_data_info): Encode/decode CS_IODESC datatype field. >> * ctlib: Work with non-NULL empty strings if the server supports them. >> * ctlib: Implement full Unicode support for TDS 7+ (MSSQL). >> * Improve support for TDS 5 (Sybase), mainly around bulk transfers. >> * Improve TDS 5 (Sybase) LONGBINARY and LONGCHAR handling. >> * Address miscellaneous compiler warnings. >> * Report system errors' descriptions to ctlib clients. >> * mem.c (tds_deinit_bcpinfo): Free and reset current_row for xfers in. >> * read.c (tds_get_n): Avoid potential hangs on short replies. >> * tds_checks.c (tds_check_column_extra): Skip size check for BLOBs. >> * Address Clang static analyzer errors, many long-standing. >> * Improve CTLIB support for TDS 7.2+. >> * cs.c (cs_convert): Fix *resultlen for conversions to SYBIMAGE. >> * bulk.c (tds_bcp_send_record): Reject invalid NULL data. >> * ctlib: Optimize blob conversion for bulk transfers in. >> * Declare and implement blk_sethints(_ver95). >> * data.c (tds_generic_row_len): Account for column_varint_size. >> * ct.c (ct_get_data): Populate cmd->iodesc->name more efficiently. >> * mem.c (tds_init_login): Enable use_utf16 by default. >> * query.c (tds_fix_column_size): Allow full size for output columns. >> * login.c (SET_FIELD_DSTR, for tds7_send_login): Cap lengths at 128. >> * tds/u.t./common.c (try_tds_login): Pass base name to tds_set_app. >> * Address more issues caught by LLVM/Clang scan-build. >> * odbc.c (odbc_process_tokens): Pre-zero done_flags per Valgrind. >> * threadsafe.c (tds_get_homedir/_WIN32): Initialize path. >> * data.c (tds_set_param_type): Under TDS 7.1+, send SYBBIT as SYBINT1. >> * ct.c (paraminfoalloc): Report long variable-width values. >> * packet.c (tds_write_packet): fix a TDS_ADDITIONAL_SPACE corner case. >> * tds5_process_dyn_result2: Don't trust Sybase to accept blob params. >> * net.c (tds_close_socket): Don't try to close invalid sockets. >> * stream.c (tds_datain_stream_read): Bail if tds_get_n returns NULL. >> * login.c (tds_connect): Skip non-TCP tries to connect to a host:port. >> * Address gaps in ctlib support for new MS date/time types. >> >> -- >> Aaron Ucko , NCBI C++ Toolkit core development group From ucko at ncbi.nlm.nih.gov Mon Jun 25 15:47:52 2018 From: ucko at ncbi.nlm.nih.gov (Aaron Ucko) Date: Mon, 25 Jun 2018 15:47:52 -0400 Subject: [freetds] Reintegrating years of local FreeTDS changes In-Reply-To: (Aaron E. via FreeTDS Ucko's message of "Mon, 25 Jun 2018 14:59:15 +0000") References: Message-ID: OK, I created a pull request, with a few technical comments on metadata: https://github.com/FreeTDS/freetds/pull/219 -- Aaron Ucko , NCBI C++ Toolkit core development group "Ucko, Aaron (NIH/NLM/NCBI) [E] via FreeTDS" writes: > Thanks for being open to these changes! > > I did get this first reply, but was having a busy week and wanted to take a closer look at the commits in which I patched unit tests before following up. Most of my commits to unit tests turned out to be pure formalities or setup fixes, but there is one commit that could well be an issue here: > > cs_convert, dbconvert: Truncate data as needed; update unit tests. > > * Automatically truncate strings that would overflow their destinations, > mainly for the sake of bulk insertions. Notify the client at low > severity (as a warning, essentially). Update upstream unit tests > (ctlib t0006, dblib t0019) accordingly. > * Fully honor *BINARY and IMAGE data buffer size limits in cs_convert. > > Running these tests against Sybase libraries (12.5, 15.7, and 16.0, with identical results in all cases), I see that these changes do go against upstream, but that there are already several other differences on this front for each API (details attached). I'll pull this commit out, at least for now. > > FWIW, there was also one commit for which I had to patch src/tds/unittests/convert.c, but not any higher-level unit tests: > > ctlib: Implement full Unicode support for TDS 7+ (MSSQL). > > * Introduce CS_NLONGCHAR_TYPE and CS_NVARCHAR_TYPE, both corresponding to > SYBNVARCHAR (along with CS_UNICHAR_TYPE); have ct_param automatically > promote CS_{LONG,VAR}CHAR_TYPE to CS_N{LONG,VAR}CHAR_TYPE for TDS 7+ > when non-ASCII characters appear in the data. (Unnecessary use of > Unicode types can make parameterized queries against 8-bit text > columns run very slowly.) > * ctlib/cs.c (cs_convert): Formally support Unicode destination types > (SYBNVARCHAR and SYBNTEXT). > * ctlib/ct.c (paraminfoalloc): When setting maximum length automatically, > account for possible conversion to UCS-2. > * tds/convert.c (tds_convert), tds/tds_willconvert.*: Formally support > Unicode types, giving type 103 (0x67) the benefit of the doubt as > SYBNVARCHAR rather than SYBSENSITIVITY. > * tds/data.c (tds_set_param_type): Map SYBNVARCHAR to XSYBNVARCHAR for > TDS 7+. > * tds/unittests/convert.c: Accommodate Unicode types, converting ASCII > input strings to (native-endian, is this correct?) UCS-2 as needed. > > -- Aaron Ucko , NCBI C++ Toolkit core development group > > -----Original Message----- > From: Frediano Ziglio [mailto:freddy77 at gmail.com] > Sent: Wednesday, June 20, 2018 04:58 > To: FreeTDS Development Group > Cc: Ucko, Aaron (NIH/NLM/NCBI) [E] > Subject: Re: [freetds] Reintegrating years of local FreeTDS changes > > Hi, > a pull request seems good. > Didn't read the full list, I expect some to be small, some other larger. > I usually keep the vendor behavior if I can. > > Regards, > Frediano > > > 2018-06-06 22:28 GMT+01:00 Ucko, Aaron (NIH/NLM/NCBI) [E] via FreeTDS > : >> Long story short, I am the primary maintainer of a convenience (aka >> vendorized) copy of FreeTDS's client libraries that has accumulated some >> local changes over the years. I have now forward-ported these changes >> to your master branch and would belatedly like to submit them for your >> consideration, both because they may also be of interest to other users >> and to make future releases easier to integrate. >> >> Some of the developers who contributed to (the original versions of) >> these changes have moved on to other jobs, but we were all working on >> behalf of the US federal government, which cannot hold copyright, so >> there shouldn't be any legal concerns; I'm just citing them in (so far >> unpublished) Git metadata to give credit where credit's due. >> >> I tested these changes via your test suite against both Microsoft SQL >> Server and Sybase ASE, and observed no regressions, just one failure >> that turned out to be preexisting (specifically, of the ODBC utf8_2 test >> against Microsoft SQL Server). We currently have Microsoft SQL Server >> 2014 and 2017 and Sybase ASE 15.5 and 16.0 on hand, and additionally >> tested many of these changes against older server versions too. That >> said, in a few cases (some predating my involvement with this code), we >> made deliberate changes to semantics. In such cases, I've updated the >> test suite accordingly. However, if you don't agree with these changes, >> I can of course instead arrange to make them conditional in some >> fashion; please let me know whether I should do so for any or all of >> these changes. >> >> I have grouped these changes into 59 patches. Please don't take this >> count as criticism of your code, which works well for the most part; >> we've just been sitting on our changes for entirely too long and >> gradually accumulating more along the way. Also, I suspect our needs >> are somewhat atypical -- we use the CT-LIB interface, and do so via a >> home-grown abstraction library rather than directly from application >> code. >> >> How would you like me to proceed? Should I send the patches here, or >> put them online through a GitHub fork? In the latter case, should I >> proceed to issue a formal pull request? >> >> Here's a quick rundown: >> >> * Fix miscellaneous configuration-specific issues, mostly on Windows. >> * Enable automatic TDS protocol version detection. >> * thread.h (tds_mutex_trylock): Disallow recursive locking on Windows. >> * tds_iconv: Accommodate FreeBSD/Citrus iconv. >> * net.c (tds_socket_write): Don't let fake short writes break headers. >> * Fix unit tests that manipulate raw network connections. >> * cancel.c: Skip return_data tests with Sybase 15+. >> * numeric.c: Don't force TDS 5.0 (DBVERSION_100). >> * threadsafe.c (tds_getservice): Set AI_CANONNAME where available. >> * dblib.c: Honor dbsetversion; improve dbcolinfo and dbwritetext. >> * odbc.c (SQLSetEnvAttr): Uncomment SQL_ATTR_OUTPUT_NTS-handling code. >> * ct.c (ct_describe): Populate datafmt->format per Valgrind. >> * connectparams.c (odbc_parse_connect_string): Handle client_charset. >> * ct.c (ct_connect): Set client_charset in addition to server_charset. >> * tds_process_tokens: For DONEPROC, always restore rows_affected. >> * Implement blk_textxfer, over a resumable tds_bcp_send_record. >> * query.c: Handle return codes of tds_put_data and tds_put_data_info. >> * net.c: Improve handling of certain error conditions. >> * ctlib: Handle CS_TIMEOUT and CS_LOGIN_TIMEOUT. >> * ct.c (_ct_get_server_type): Handle CS_LONGCHAR_TYPE. >> * blk.c (_blk_get_col_data): Use on-server size for destfmt.maxlength. >> * ct.c (ct_cursor): Predict cursor type for CS_CURSOR_DECLARE. >> * Fix server timeout handling and ctlib severity propagation. >> * Don't log directly to stdout or stderr. >> * blk.c: Handle CS_BLK_CANCEL in blk_done. >> * cs_convert, dbconvert: Truncate data as needed; update unit tests. >> * ct.c (ct_data_info): Encode/decode CS_IODESC datatype field. >> * ctlib: Work with non-NULL empty strings if the server supports them. >> * ctlib: Implement full Unicode support for TDS 7+ (MSSQL). >> * Improve support for TDS 5 (Sybase), mainly around bulk transfers. >> * Improve TDS 5 (Sybase) LONGBINARY and LONGCHAR handling. >> * Address miscellaneous compiler warnings. >> * Report system errors' descriptions to ctlib clients. >> * mem.c (tds_deinit_bcpinfo): Free and reset current_row for xfers in. >> * read.c (tds_get_n): Avoid potential hangs on short replies. >> * tds_checks.c (tds_check_column_extra): Skip size check for BLOBs. >> * Address Clang static analyzer errors, many long-standing. >> * Improve CTLIB support for TDS 7.2+. >> * cs.c (cs_convert): Fix *resultlen for conversions to SYBIMAGE. >> * bulk.c (tds_bcp_send_record): Reject invalid NULL data. >> * ctlib: Optimize blob conversion for bulk transfers in. >> * Declare and implement blk_sethints(_ver95). >> * data.c (tds_generic_row_len): Account for column_varint_size. >> * ct.c (ct_get_data): Populate cmd->iodesc->name more efficiently. >> * mem.c (tds_init_login): Enable use_utf16 by default. >> * query.c (tds_fix_column_size): Allow full size for output columns. >> * login.c (SET_FIELD_DSTR, for tds7_send_login): Cap lengths at 128. >> * tds/u.t./common.c (try_tds_login): Pass base name to tds_set_app. >> * Address more issues caught by LLVM/Clang scan-build. >> * odbc.c (odbc_process_tokens): Pre-zero done_flags per Valgrind. >> * threadsafe.c (tds_get_homedir/_WIN32): Initialize path. >> * data.c (tds_set_param_type): Under TDS 7.1+, send SYBBIT as SYBINT1. >> * ct.c (paraminfoalloc): Report long variable-width values. >> * packet.c (tds_write_packet): fix a TDS_ADDITIONAL_SPACE corner case. >> * tds5_process_dyn_result2: Don't trust Sybase to accept blob params. >> * net.c (tds_close_socket): Don't try to close invalid sockets. >> * stream.c (tds_datain_stream_read): Bail if tds_get_n returns NULL. >> * login.c (tds_connect): Skip non-TCP tries to connect to a host:port. >> * Address gaps in ctlib support for new MS date/time types. >> >> -- >> Aaron Ucko , NCBI C++ Toolkit core development group From no-reply at appveyor.com Mon Jun 25 15:56:11 2018 From: no-reply at appveyor.com (AppVeyor) Date: Mon, 25 Jun 2018 19:56:11 +0000 Subject: [freetds] Build failed: freetds 1055 Message-ID: <20180625195611.1.3EB9F8D1FB1EFB6C@appveyor.com> From sf at 4js.com Tue Jun 26 03:25:20 2018 From: sf at 4js.com (Sebastien FLAESCH) Date: Tue, 26 Jun 2018 09:25:20 +0200 Subject: [freetds] Reintegrating years of local FreeTDS changes In-Reply-To: References: <20180621210259.A896D17FDA1@rebar.astron.com> Message-ID: <4c958af8-5b61-7c01-f4af-e86cd4bd57aa@4js.com> Hi all, If you give me the Github link where I can download the sources, I can recompile FreeTDS with all these changes and run or test suite with it. Just let me know when it's stable enough to be tested. Seb On 06/23/2018 12:22 AM, Frediano Ziglio wrote: > Yes, > agreed with GitHub. > > I though I already replied, apparently not. > > Frediano > > > 2018-06-21 22:02 GMT+01:00 Christos Zoulas : >> On Jun 7, 12:12pm, freetds at lists.ibiblio.org ("Ucko, Aaron \(NIH/NLM/NCBI\) \[E\] via FreeTDS") wrote: >> -- Subject: [freetds] Reintegrating years of local FreeTDS changes >> >> | How would you like me to proceed? Should I send the patches here, or >> | put them online through a GitHub fork? In the latter case, should I >> | proceed to issue a formal pull request? >> >> I am not Freddy, but I think that github sounds like the right way to >> proceed. Thanks for the offer! >> >> christos >> _______________________________________________ >> 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 ucko at ncbi.nlm.nih.gov Tue Jun 26 09:31:02 2018 From: ucko at ncbi.nlm.nih.gov (Ucko, Aaron (NIH/NLM/NCBI) [E]) Date: Tue, 26 Jun 2018 13:31:02 +0000 Subject: [freetds] Reintegrating years of local FreeTDS changes In-Reply-To: <4c958af8-5b61-7c01-f4af-e86cd4bd57aa@4js.com> References: <20180621210259.A896D17FDA1@rebar.astron.com> <4c958af8-5b61-7c01-f4af-e86cd4bd57aa@4js.com> Message-ID: https://github.com/ucko/freetds The ncbi-merge-request-1pre1 branch contains my full set of changes; ncbi-merge-request-1 (aka master) leaves out one roughly in the middle that changes the semantics of truncation, as discussed elsewhere in this thread. Thanks! -- Aaron Ucko , NCBI C++ Toolkit core development group -----Original Message----- From: Sebastien FLAESCH [mailto:sf at 4js.com] Sent: Tuesday, June 26, 2018 03:25 To: freetds at lists.ibiblio.org Subject: Re: [freetds] Reintegrating years of local FreeTDS changes Hi all, If you give me the Github link where I can download the sources, I can recompile FreeTDS with all these changes and run or test suite with it. Just let me know when it's stable enough to be tested. Seb On 06/23/2018 12:22 AM, Frediano Ziglio wrote: > Yes, > agreed with GitHub. > > I though I already replied, apparently not. > > Frediano > > > 2018-06-21 22:02 GMT+01:00 Christos Zoulas : >> On Jun 7, 12:12pm, freetds at lists.ibiblio.org ("Ucko, Aaron \(NIH/NLM/NCBI\) \[E\] via FreeTDS") wrote: >> -- Subject: [freetds] Reintegrating years of local FreeTDS changes >> >> | How would you like me to proceed? Should I send the patches here, or >> | put them online through a GitHub fork? In the latter case, should I >> | proceed to issue a formal pull request? >> >> I am not Freddy, but I think that github sounds like the right way to >> proceed. Thanks for the offer! >> >> christos >> _______________________________________________ >> 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 Jun 27 05:37:00 2018 From: sf at 4js.com (Sebastien FLAESCH) Date: Wed, 27 Jun 2018 11:37:00 +0200 Subject: [freetds] Reintegrating years of local FreeTDS changes In-Reply-To: References: <20180621210259.A896D17FDA1@rebar.astron.com> <4c958af8-5b61-7c01-f4af-e86cd4bd57aa@4js.com> Message-ID: <836d7e80-2800-89c2-ec01-87b4aea41d31@4js.com> Thanks for the link! FYI: ... data.c: In function 'tds_sybblob_get': data.c:1585:10: warning: unused variable 'serialization_type' [-Wunused-variable] uint8_t serialization_type = tds_get_byte(tds); ^ ... bulk.c: In function 'tds_bcp_send_record': bulk.c:622:23: warning: 'bitpos' may be used uninitialized in this function [-Wmaybe-uninitialized] rowbuffer[bitpos] |= 256 >> bitleft; ^ bulk.c:582:19: note: 'bitpos' was declared here int bitleft = 0, bitpos; ^ ... dblib.c: In function 'copy_data_to_host_var': dblib.c:7462:6: warning: unused variable 'i' [-Wunused-variable] int i, len; ^ ... defncopy.c: In function 'get_login': defncopy.c:670:6: warning: variable 'fdomain' set but not used [-Wunused-but-set-variable] int fdomain = TRUE; ^ ... $ g++ --version g++ (Debian 4.9.2-10+deb8u1) 4.9.2 Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Seb On 06/26/2018 03:31 PM, Ucko, Aaron (NIH/NLM/NCBI) [E] wrote: > https://github.com/ucko/freetds > > The ncbi-merge-request-1pre1 branch contains my full set of changes; ncbi-merge-request-1 (aka master) leaves out one roughly in the middle that changes the semantics of truncation, as discussed elsewhere in this thread. > > Thanks! > > -- Aaron Ucko , NCBI C++ Toolkit core development group > > -----Original Message----- > From: Sebastien FLAESCH [mailto:sf at 4js.com] > Sent: Tuesday, June 26, 2018 03:25 > To: freetds at lists.ibiblio.org > Subject: Re: [freetds] Reintegrating years of local FreeTDS changes > > Hi all, > > If you give me the Github link where I can download the sources, I can > recompile FreeTDS with all these changes and run or test suite with it. > > Just let me know when it's stable enough to be tested. > > Seb > > On 06/23/2018 12:22 AM, Frediano Ziglio wrote: >> Yes, >> agreed with GitHub. >> >> I though I already replied, apparently not. >> >> Frediano >> >> >> 2018-06-21 22:02 GMT+01:00 Christos Zoulas : >>> On Jun 7, 12:12pm, freetds at lists.ibiblio.org ("Ucko, Aaron \(NIH/NLM/NCBI\) \[E\] via FreeTDS") wrote: >>> -- Subject: [freetds] Reintegrating years of local FreeTDS changes >>> >>> | How would you like me to proceed? Should I send the patches here, or >>> | put them online through a GitHub fork? In the latter case, should I >>> | proceed to issue a formal pull request? >>> >>> I am not Freddy, but I think that github sounds like the right way to >>> proceed. Thanks for the offer! >>> >>> christos >>> _______________________________________________ >>> 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 Wed Jun 27 05:59:32 2018 From: sf at 4js.com (Sebastien FLAESCH) Date: Wed, 27 Jun 2018 11:59:32 +0200 Subject: [freetds] Reintegrating years of local FreeTDS changes In-Reply-To: References: <20180621210259.A896D17FDA1@rebar.astron.com> <4c958af8-5b61-7c01-f4af-e86cd4bd57aa@4js.com> Message-ID: <7c8c8ef5-bb36-32ea-8fed-30bb8ff59575@4js.com> I could execute our QA tests with SQL Server 2016 and 2017 without detecting any regression, by using the "master" branch. But it fails to connect to SQL Server 2014 (12.0). Is there some limitation regarding the supported SQL Server version? ODBCINI: [ftm_msvtest1_ida_utf8] Description = SQL Server 2014 Server = ida Database = msvtest1 Port = 1681 TDS_Version = 7.3 ClientCharset = UTF-8 Seb From ucko at ncbi.nlm.nih.gov Wed Jun 27 09:32:11 2018 From: ucko at ncbi.nlm.nih.gov (Aaron Ucko) Date: Wed, 27 Jun 2018 09:32:11 -0400 Subject: [freetds] Reintegrating years of local FreeTDS changes In-Reply-To: <836d7e80-2800-89c2-ec01-87b4aea41d31@4js.com> (Sebastien FLAESCH's message of "Wed, 27 Jun 2018 11:37:00 +0200") References: <20180621210259.A896D17FDA1@rebar.astron.com> <4c958af8-5b61-7c01-f4af-e86cd4bd57aa@4js.com> <836d7e80-2800-89c2-ec01-87b4aea41d31@4js.com> Message-ID: Responding inline. Sebastien FLAESCH writes: > Thanks for the link! Thanks for the review! These warnings, however, are all preexisting -- only one (from tds_bcp_send_record in src/tds/bulk.c) pertains to a function I touched at all, and even then I left the relevant portions alone. That said, I could of course still tweak my big warnings-cleanup commit to include fixes, and will be happy to do so if I have to revise any other commits anyway. > bulk.c: In function 'tds_bcp_send_record': > bulk.c:622:23: warning: 'bitpos' may be used uninitialized in this function [-Wmaybe-uninitialized] By my reading of this code, this warning is spurious, though I suppose it would be cheap enough to give bitpos a formal initializer to shut the compiler up. ;-) -- Aaron Ucko , NCBI C++ Toolkit core development group From ucko at ncbi.nlm.nih.gov Wed Jun 27 09:40:06 2018 From: ucko at ncbi.nlm.nih.gov (Aaron Ucko) Date: Wed, 27 Jun 2018 09:40:06 -0400 Subject: [freetds] Reintegrating years of local FreeTDS changes In-Reply-To: <7c8c8ef5-bb36-32ea-8fed-30bb8ff59575@4js.com> (Sebastien FLAESCH's message of "Wed, 27 Jun 2018 11:59:32 +0200") References: <20180621210259.A896D17FDA1@rebar.astron.com> <4c958af8-5b61-7c01-f4af-e86cd4bd57aa@4js.com> <7c8c8ef5-bb36-32ea-8fed-30bb8ff59575@4js.com> Message-ID: That's not good (or intentional!), but I'm not sure why that would be; that combination still works for me: $ TDSVER=7.3 ./src/apps/tsql -o v -H MSDEV1 -p 1433 -U DBAPI_test Password: locale is "LC_CTYPE=en_US.UTF-8;LC_NUMERIC=en_US.UTF-8;LC_TIME=en_US.UTF-8;LC_COLLATE=C;LC_MONETARY=en_US.UTF-8;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=en_US.UTF-8;LC_ADDRESS=en_US.UTF-8;LC_TELEPHONE=en_US.UTF-8;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=en_US.UTF-8" locale charset is "UTF-8" using default charset "UTF-8" 1> SELECT @@version 2> go using TDS version 7.3 Microsoft SQL Server 2014 (SP2-GDR) (KB4057120) - 12.0.5214.6 (X64) Jan 9 2018 15:03:12 Copyright (c) Microsoft Corporation Standard Edition (64-bit) on Windows NT 6.3 (Build 9600: ) (1 row affected) using TDS version 7.3 Would you mind bisecting to determine which commit broke this combination for you? -- Aaron Ucko , NCBI C++ Toolkit core development group Sebastien FLAESCH writes: > I could execute our QA tests with SQL Server 2016 and 2017 without detecting > any regression, by using the "master" branch. > > But it fails to connect to SQL Server 2014 (12.0). > > Is there some limitation regarding the supported SQL Server version? > > ODBCINI: > > [ftm_msvtest1_ida_utf8] > Description = SQL Server 2014 > Server = ida > Database = msvtest1 > Port = 1681 > TDS_Version = 7.3 > ClientCharset = UTF-8 > > > Seb From sf at 4js.com Wed Jun 27 10:45:43 2018 From: sf at 4js.com (Sebastien FLAESCH) Date: Wed, 27 Jun 2018 16:45:43 +0200 Subject: [freetds] Reintegrating years of local FreeTDS changes In-Reply-To: References: <20180621210259.A896D17FDA1@rebar.astron.com> <4c958af8-5b61-7c01-f4af-e86cd4bd57aa@4js.com> <7c8c8ef5-bb36-32ea-8fed-30bb8ff59575@4js.com> Message-ID: <34a2e800-3b75-9955-24dd-4a091ab78248@4js.com> Hummm... sf at orion:/opt3/dbs/tds/tmp/freetds$ git log | grep "Author.* Ucko" | wc -l 52 Sorry I am cannot spend too much time on this. Attached the TDSDUMP log, if it can help... Or if you have any other compile option to debug what's going on and is easily testable, let me know. Seb On 06/27/2018 03:40 PM, Aaron Ucko wrote: > That's not good (or intentional!), but I'm not sure why that would be; > that combination still works for me: > > $ TDSVER=7.3 ./src/apps/tsql -o v -H MSDEV1 -p 1433 -U DBAPI_test > Password: > locale is "LC_CTYPE=en_US.UTF-8;LC_NUMERIC=en_US.UTF-8;LC_TIME=en_US.UTF-8;LC_COLLATE=C;LC_MONETARY=en_US.UTF-8;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=en_US.UTF-8;LC_ADDRESS=en_US.UTF-8;LC_TELEPHONE=en_US.UTF-8;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=en_US.UTF-8" > locale charset is "UTF-8" > using default charset "UTF-8" > 1> SELECT @@version > 2> go > > using TDS version 7.3 > Microsoft SQL Server 2014 (SP2-GDR) (KB4057120) - 12.0.5214.6 (X64) > Jan 9 2018 15:03:12 > Copyright (c) Microsoft Corporation > Standard Edition (64-bit) on Windows NT 6.3 (Build 9600: ) > > (1 row affected) > using TDS version 7.3 > > Would you mind bisecting to determine which commit broke this > combination for you? > > -- Aaron Ucko , NCBI C++ Toolkit core development group > > Sebastien FLAESCH writes: > >> I could execute our QA tests with SQL Server 2016 and 2017 without detecting >> any regression, by using the "master" branch. >> >> But it fails to connect to SQL Server 2014 (12.0). >> >> Is there some limitation regarding the supported SQL Server version? >> >> ODBCINI: >> >> [ftm_msvtest1_ida_utf8] >> Description = SQL Server 2014 >> Server = ida >> Database = msvtest1 >> Port = 1681 >> TDS_Version = 7.3 >> ClientCharset = UTF-8 >> >> >> Seb > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds > -------------- next part -------------- A non-text attachment was scrubbed... Name: tdsdump.log Type: text/x-log Size: 7350 bytes Desc: not available URL: From ucko at ncbi.nlm.nih.gov Wed Jun 27 11:16:27 2018 From: ucko at ncbi.nlm.nih.gov (Aaron Ucko) Date: Wed, 27 Jun 2018 11:16:27 -0400 Subject: [freetds] Reintegrating years of local FreeTDS changes In-Reply-To: <34a2e800-3b75-9955-24dd-4a091ab78248@4js.com> (Sebastien FLAESCH's message of "Wed, 27 Jun 2018 16:45:43 +0200") References: <20180621210259.A896D17FDA1@rebar.astron.com> <4c958af8-5b61-7c01-f4af-e86cd4bd57aa@4js.com> <7c8c8ef5-bb36-32ea-8fed-30bb8ff59575@4js.com> <34a2e800-3b75-9955-24dd-4a091ab78248@4js.com> Message-ID: Your 52 misses a few commits for which I merely credited myself as Committer, but still amounts to at most 6 rounds of bisection, FWIW. The log points to a TLS error, but without much in the way of specifics: > tls.c:1021:handshake failed with -1 4640 1 The -1 comes from SSL_connect, meaning <0 The TLS/SSL handshake was not successful, because a fatal error occurred either at the protocol level or a connection failure occurred. The shutdown was not clean. It can also occur of action is need to continue the operation for non-blocking BIOs. Call SSL_get_error() with the return value ret to find out the reason. The 4640 (0x1220) comes from SSL_get_state, where we have #define SSL_ST_CONNECT 0x1000 #define SSL_CB_HANDSHAKE_DONE 0x20 and I'm not sure what to make of the 0x200; it may be some internal flag. (I see an SSL_state_string_long function that may be more informative.) Finally, the 1 (SSL_ERROR_SSL) comes from SSL_get_error, meaning SSL_ERROR_SSL A failure in the SSL library occurred, usually a protocol error. The OpenSSL error queue contains more information on the error. I'm not sure how you'd get at the error queue. :-/ -- Aaron Ucko , NCBI C++ Toolkit core development group Sebastien FLAESCH writes: > Hummm... > > sf at orion:/opt3/dbs/tds/tmp/freetds$ git log | grep "Author.* Ucko" | wc -l > 52 > > Sorry I am cannot spend too much time on this. > > Attached the TDSDUMP log, if it can help... > > Or if you have any other compile option to debug what's going on > and is easily testable, let me know. > > Seb > > > > On 06/27/2018 03:40 PM, Aaron Ucko wrote: >> That's not good (or intentional!), but I'm not sure why that would be; >> that combination still works for me: >> >> $ TDSVER=7.3 ./src/apps/tsql -o v -H MSDEV1 -p 1433 -U DBAPI_test >> Password: >> locale is "LC_CTYPE=en_US.UTF-8;LC_NUMERIC=en_US.UTF-8;LC_TIME=en_US.UTF-8;LC_COLLATE=C;LC_MONETARY=en_US.UTF-8;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=en_US.UTF-8;LC_ADDRESS=en_US.UTF-8;LC_TELEPHONE=en_US.UTF-8;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=en_US.UTF-8" >> locale charset is "UTF-8" >> using default charset "UTF-8" >> 1> SELECT @@version >> 2> go >> using TDS version 7.3 >> Microsoft SQL Server 2014 (SP2-GDR) (KB4057120) - 12.0.5214.6 (X64) >> Jan 9 2018 15:03:12 >> Copyright (c) Microsoft Corporation >> Standard Edition (64-bit) on Windows NT 6.3 (Build 9600: ) >> (1 row affected) >> using TDS version 7.3 >> >> Would you mind bisecting to determine which commit broke this >> combination for you? >> >> -- Aaron Ucko , NCBI C++ Toolkit core development group >> >> Sebastien FLAESCH writes: >> >>> I could execute our QA tests with SQL Server 2016 and 2017 without detecting >>> any regression, by using the "master" branch. >>> >>> But it fails to connect to SQL Server 2014 (12.0). >>> >>> Is there some limitation regarding the supported SQL Server version? >>> >>> ODBCINI: >>> >>> [ftm_msvtest1_ida_utf8] >>> Description = SQL Server 2014 >>> Server = ida >>> Database = msvtest1 >>> Port = 1681 >>> TDS_Version = 7.3 >>> ClientCharset = UTF-8 >>> >>> >>> Seb From sf at 4js.com Wed Jun 27 11:34:41 2018 From: sf at 4js.com (Sebastien FLAESCH) Date: Wed, 27 Jun 2018 17:34:41 +0200 Subject: [freetds] Reintegrating years of local FreeTDS changes In-Reply-To: References: <20180621210259.A896D17FDA1@rebar.astron.com> <4c958af8-5b61-7c01-f4af-e86cd4bd57aa@4js.com> <7c8c8ef5-bb36-32ea-8fed-30bb8ff59575@4js.com> <34a2e800-3b75-9955-24dd-4a091ab78248@4js.com> Message-ID: <427b422d-8d3c-9974-0603-43963604084d@4js.com> What I can tell is that with the standard source code compiled on my machine, I have no problem to connect to SQL Server 2014. Anyway at least no issues with SQL Server 2016 and 2017 so that's good news. Seb On 06/27/2018 05:16 PM, Aaron Ucko wrote: > Your 52 misses a few commits for which I merely credited myself as > Committer, but still amounts to at most 6 rounds of bisection, FWIW. > > The log points to a TLS error, but without much in the way of specifics: > >> tls.c:1021:handshake failed with -1 4640 1 > > The -1 comes from SSL_connect, meaning > > <0 The TLS/SSL handshake was not successful, because a fatal error > occurred either at the protocol level or a connection failure > occurred. The shutdown was not clean. It can also occur of action > is need to continue the operation for non-blocking BIOs. Call > SSL_get_error() with the return value ret to find out the reason. > > The 4640 (0x1220) comes from SSL_get_state, where we have > > #define SSL_ST_CONNECT 0x1000 > #define SSL_CB_HANDSHAKE_DONE 0x20 > > and I'm not sure what to make of the 0x200; it may be some internal > flag. (I see an SSL_state_string_long function that may be more > informative.) > > Finally, the 1 (SSL_ERROR_SSL) comes from SSL_get_error, meaning > > SSL_ERROR_SSL > A failure in the SSL library occurred, usually a protocol error. > The OpenSSL error queue contains more information on the error. > > I'm not sure how you'd get at the error queue. :-/ > > -- Aaron Ucko , NCBI C++ Toolkit core development group > > Sebastien FLAESCH writes: > >> Hummm... >> >> sf at orion:/opt3/dbs/tds/tmp/freetds$ git log | grep "Author.* Ucko" | wc -l >> 52 >> >> Sorry I am cannot spend too much time on this. >> >> Attached the TDSDUMP log, if it can help... >> >> Or if you have any other compile option to debug what's going on >> and is easily testable, let me know. >> >> Seb >> >> >> >> On 06/27/2018 03:40 PM, Aaron Ucko wrote: >>> That's not good (or intentional!), but I'm not sure why that would be; >>> that combination still works for me: >>> >>> $ TDSVER=7.3 ./src/apps/tsql -o v -H MSDEV1 -p 1433 -U DBAPI_test >>> Password: >>> locale is "LC_CTYPE=en_US.UTF-8;LC_NUMERIC=en_US.UTF-8;LC_TIME=en_US.UTF-8;LC_COLLATE=C;LC_MONETARY=en_US.UTF-8;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=en_US.UTF-8;LC_ADDRESS=en_US.UTF-8;LC_TELEPHONE=en_US.UTF-8;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=en_US.UTF-8" >>> locale charset is "UTF-8" >>> using default charset "UTF-8" >>> 1> SELECT @@version >>> 2> go >>> using TDS version 7.3 >>> Microsoft SQL Server 2014 (SP2-GDR) (KB4057120) - 12.0.5214.6 (X64) >>> Jan 9 2018 15:03:12 >>> Copyright (c) Microsoft Corporation >>> Standard Edition (64-bit) on Windows NT 6.3 (Build 9600: ) >>> (1 row affected) >>> using TDS version 7.3 >>> >>> Would you mind bisecting to determine which commit broke this >>> combination for you? >>> >>> -- Aaron Ucko , NCBI C++ Toolkit core development group >>> >>> Sebastien FLAESCH writes: >>> >>>> I could execute our QA tests with SQL Server 2016 and 2017 without detecting >>>> any regression, by using the "master" branch. >>>> >>>> But it fails to connect to SQL Server 2014 (12.0). >>>> >>>> Is there some limitation regarding the supported SQL Server version? >>>> >>>> ODBCINI: >>>> >>>> [ftm_msvtest1_ida_utf8] >>>> Description = SQL Server 2014 >>>> Server = ida >>>> Database = msvtest1 >>>> Port = 1681 >>>> TDS_Version = 7.3 >>>> ClientCharset = UTF-8 >>>> >>>> >>>> Seb > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds > From ikorot01 at gmail.com Wed Jun 27 13:37:31 2018 From: ikorot01 at gmail.com (Igor Korot) Date: Wed, 27 Jun 2018 12:37:31 -0500 Subject: [freetds] Problem with the latest Sybase ODBC driver Message-ID: Hi, ALL, This post is not directly related to the freeTDS, but I'm hoping that someone can help. I have a latest Sybase 16.0 version Development Edition installed on Linux. I also have a unixODBC installed. I'm trying to connect to the server using the default Sybase ODBC driver with the unixODBC isql program. Unfortunately I have a problem. The connection works, but then issuing the simple query, like "SELECT * FROM ;", where my table is locatedinside my local database (the one I created) segfaults. Trying to do the same with the Sybase demo database works fine. I didn't try to do anything with the freeTDS driver yet. I will probably do that over the weekend. Does anybody here have Sybase 16 installed? Did you try ODBC connection to the server? Thank you. P.S.: Software versions: 1> select @@version 2> go ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ Adaptive Server Enterprise/16.0 SP02 PL02/EBF 25320 SMP/P/x86_64/Enterprise Lin ux/ase160sp02plx/2492/64-bit/FBO/Sat Nov 21 04:05:39 2015 (1 row affected) 1> exit [/code] [code] [ebuild U ] dev-db/unixODBC-2.3.5-r1::gentoo [2.3.2-r1::gentoo] USE="minimal unicode -odbcmanual -static-libs" ABI_X86="32 (64) (-x32)" 1,596 KiB [/code] The current version of unixODBC is 2.3.2-r1 from gentoo repository. From ikorot01 at gmail.com Wed Jun 27 13:40:23 2018 From: ikorot01 at gmail.com (Igor Korot) Date: Wed, 27 Jun 2018 12:40:23 -0500 Subject: [freetds] Which API to use? Message-ID: Hi, The freeTDS supports 2 different APIs: db-lib and ct-lib? Is db-lib an older version of the API and people currently should work with ct-lib? Or db-lib is the current implementation? Asking because Sybase 16 is using the ct-lib calls.... Thank you. From john at capps.com Wed Jun 27 14:21:07 2018 From: john at capps.com (John Kendall) Date: Wed, 27 Jun 2018 18:21:07 +0000 Subject: [freetds] Which API to use? In-Reply-To: References: Message-ID: <5A885B2D-C76C-4C53-A382-D0713D55CF98@capps.com> Igor, I never could decide, and I use both. John > On Jun 27, 2018, at 10:40 AM, Igor Korot wrote: > > Hi, > The freeTDS supports 2 different APIs: db-lib and ct-lib? > Is db-lib an older version of the API and people currently should work > with ct-lib? > Or db-lib is the current implementation? > > Asking because Sybase 16 is using the ct-lib calls.... > > Thank you. > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://url.emailprotection.link/?a95lm_Yz0z4VwVi9HMyQSLtTmToR48n_2Es8x43dIoxidNPkdt4wWeUhbwN1QnbrzawQmZ1BjbOu5bK1zLGmRSw~~ From john at capps.com Wed Jun 27 14:14:40 2018 From: john at capps.com (John Kendall) Date: Wed, 27 Jun 2018 18:14:40 +0000 Subject: [freetds] Problem with the latest Sybase ODBC driver In-Reply-To: References: Message-ID: Igor, I'm on Centos 7.5 and it looks like I'm using the exact same version of ASE: Adaptive Server Enterprise/16.0 SP02 PL02/EBF 25320 SMP/P/x86_64/Enterprise Linux/ase160sp02plx/2492/64-bit/FBO/Sat Nov 21 04:05:39 2015 I'm using unixODBC 2.3.1 and the freeTDS odbc driver without issue. I recall having the Sybase ODBC driver working, but settled on the FreeTDS driver for simplicity. John On Jun 27, 2018, at 10:37 AM, Igor Korot > wrote: Hi, ALL, This post is not directly related to the freeTDS, but I'm hoping that someone can help. I have a latest Sybase 16.0 version Development Edition installed on Linux. I also have a unixODBC installed. I'm trying to connect to the server using the default Sybase ODBC driver with the unixODBC isql program. Unfortunately I have a problem. The connection works, but then issuing the simple query, like "SELECT * FROM ;", where my table is locatedinside my local database (the one I created) segfaults. Trying to do the same with the Sybase demo database works fine. I didn't try to do anything with the freeTDS driver yet. I will probably do that over the weekend. Does anybody here have Sybase 16 installed? Did you try ODBC connection to the server? Thank you. P.S.: Software versions: 1> select @@version 2> go ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ Adaptive Server Enterprise/16.0 SP02 PL02/EBF 25320 SMP/P/x86_64/Enterprise Lin ux/ase160sp02plx/2492/64-bit/FBO/Sat Nov 21 04:05:39 2015 (1 row affected) 1> exit [/code] [code] [ebuild U ] dev-db/unixODBC-2.3.5-r1::gentoo [2.3.2-r1::gentoo] USE="minimal unicode -odbcmanual -static-libs" ABI_X86="32 (64) (-x32)" 1,596 KiB [/code] The current version of unixODBC is 2.3.2-r1 from gentoo repository. _______________________________________________ FreeTDS mailing list FreeTDS at lists.ibiblio.org https://url.emailprotection.link/?a95lm_Yz0z4VwVi9HMyQSLtTmToR48n_2Es8x43dIoxidNPkdt4wWeUhbwN1QnbrzawQmZ1BjbOu5bK1zLGmRSw~~ From fredy at opag.ch Thu Jun 28 01:38:14 2018 From: fredy at opag.ch (Fredy Paquet) Date: Thu, 28 Jun 2018 07:38:14 +0200 Subject: [freetds] Which API to use? In-Reply-To: References: Message-ID: <1530164294.3524.0.camel@opag.ch> db-lib is the older API version. It has field length limitations. You should use ct-lib. On Wed, 2018-06-27 at 12:40 -0500, Igor Korot wrote: > Hi, > The freeTDS supports 2 different APIs: db-lib and ct-lib? > Is db-lib an older version of the API and people currently should > work > with ct-lib? > Or db-lib is the current implementation? > > Asking because Sybase 16 is using the ct-lib calls.... > > Thank you. > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3480 bytes Desc: not available URL: From fredy at opag.ch Thu Jun 28 01:38:58 2018 From: fredy at opag.ch (Fredy Paquet) Date: Thu, 28 Jun 2018 07:38:58 +0200 Subject: [freetds] Which API to use? In-Reply-To: References: Message-ID: <1530164338.3524.1.camel@opag.ch> db-lib is the older API version. It has field length limitations. On Wed, 2018-06-27 at 12:40 -0500, Igor Korot wrote: > Hi, > The freeTDS supports 2 different APIs: db-lib and ct-lib? > Is db-lib an older version of the API and people currently should > work > with ct-lib? > Or db-lib is the current implementation? > > Asking because Sybase 16 is using the ct-lib calls.... > > Thank you. > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3480 bytes Desc: not available URL: From freddy77 at gmail.com Thu Jun 28 02:44:56 2018 From: freddy77 at gmail.com (Frediano Ziglio) Date: Thu, 28 Jun 2018 07:44:56 +0100 Subject: [freetds] Problem with the latest Sybase ODBC driver In-Reply-To: References: Message-ID: 2018-06-27 18:37 GMT+01:00 Igor Korot : > Hi, ALL, > This post is not directly related to the freeTDS, but I'm hoping that > someone can help. > > I have a latest Sybase 16.0 version Development Edition installed on Linux. > I also have a unixODBC installed. > > I'm trying to connect to the server using the default Sybase ODBC > driver with the > unixODBC isql program. > > Unfortunately I have a problem. The connection works, but then issuing > the simple > query, like "SELECT * FROM ;", where my table is locatedinside > my local database (the one I created) segfaults. > Trying to do the same with the Sybase demo database works fine. > > I didn't try to do anything with the freeTDS driver yet. I will probably do that > over the weekend. > > Does anybody here have Sybase 16 installed? Did you try ODBC connection > to the server? > > Thank you. > > P.S.: Software versions: > 1> select @@version > 2> go > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > Adaptive Server Enterprise/16.0 SP02 PL02/EBF 25320 SMP/P/x86_64/Enterprise Lin > ux/ase160sp02plx/2492/64-bit/FBO/Sat Nov 21 04:05:39 2015 > > (1 row affected) > 1> exit > > [/code] > > [code] > > [ebuild U ] dev-db/unixODBC-2.3.5-r1::gentoo [2.3.2-r1::gentoo] > USE="minimal unicode -odbcmanual -static-libs" ABI_X86="32 (64) > (-x32)" 1,596 KiB > > [/code] > > The current version of unixODBC is 2.3.2-r1 from gentoo repository. Sounds a silly question: are unixODBC and Sybase driver using the same ABI? Yes, sounds crazy but unixODBC can be compiled with slightly different ABIs on 64 bit. You could enable ODBC tracing to see the last call producing the fault. Maybe program is using wide functions and this is the issue? Frediano From ikorot01 at gmail.com Thu Jun 28 08:27:31 2018 From: ikorot01 at gmail.com (Igor Korot) Date: Thu, 28 Jun 2018 07:27:31 -0500 Subject: [freetds] Which API to use? In-Reply-To: <1530164294.3524.0.camel@opag.ch> References: <1530164294.3524.0.camel@opag.ch> Message-ID: Fredy, On Thu, Jun 28, 2018 at 12:38 AM, Fredy Paquet wrote: > db-lib is the older API version. It has field length limitations. > > You should use ct-lib. Thank you. > > On Wed, 2018-06-27 at 12:40 -0500, Igor Korot wrote: >> Hi, >> The freeTDS supports 2 different APIs: db-lib and ct-lib? >> Is db-lib an older version of the API and people currently should >> work >> with ct-lib? >> Or db-lib is the current implementation? >> >> Asking because Sybase 16 is using the ct-lib calls.... >> >> Thank you. >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> https://lists.ibiblio.org/mailman/listinfo/freetds > -- > 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 > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds > From ikorot01 at gmail.com Thu Jun 28 08:36:41 2018 From: ikorot01 at gmail.com (Igor Korot) Date: Thu, 28 Jun 2018 05:36:41 -0700 Subject: [freetds] Problem with the latest Sybase ODBC driver In-Reply-To: References: Message-ID: Hi, John, On Wed, Jun 27, 2018 at 11:14 AM, John Kendall wrote: > Igor, > I'm on Centos 7.5 and it looks like I'm using the exact same version of ASE: > Adaptive Server Enterprise/16.0 SP02 PL02/EBF 25320 SMP/P/x86_64/Enterprise Linux/ase160sp02plx/2492/64-bit/FBO/Sat Nov 21 04:05:39 2015 > > I'm using unixODBC 2.3.1 and the freeTDS odbc driver without issue. > I recall having the Sybase ODBC driver working, but settled on the FreeTDS driver for simplicity. This is my setup: [code] igor at IgorReinCloud ~/dbhandler $ cat /etc/unixODBC/odbcinst.ini [ODBC] Trace=yes TraceFile=/tmp/sql.log Pooling=No [Sybase] Description=Sybase 16 Native Driver Driver=/opt/sap/DataAccess64/ODBC/lib/libsybdrvodb.so UsageCount=1 [Sybase_freeTDS] Description=Sybase FreeTDS Driver Driver=/usr/lib64/libtdsodbc.so UsageCount=1 igor at IgorReinCloud ~/dbhandler $ cat /etc/unixODBC/odbc.ini [ODBC Data Sources] Sybase_16_demo=Sybase 16 ODBC driver Sybase_16_test=Sybase 16 ODBC driver Sybase_16_freeTDS=Sybase_freeTDS [Sybase_16_demo] Description=Sybase 16 ODBC Driver Driver=Sybase Port=5000 Server=IGORREINCLOUD UserID=sa Password= Database=pubs2 Option=3 [Sybase_16_test] Description=Sybase 16 ODBC native driver Driver=Sybase Port=5000 Server=IG Server=IGORREINCLOUD UserID=sa Password= Database=draft Option=3 [Sybase_16_freeTDS] Description=Sybase 16 freeTDS ODBC driver Driver=Sybase_freeTDS Port=5000 Server=IGORREINCLOUD UserID=sa Password= Database=draft TDS Version=5.0 Option=3 [/code] And this is from the ODBC log for freeTDS driver: [code] [ODBC][15829][1530200010.883129][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLConnect.c][3727] Entry: Connection = 0x637050 Server Name = [Sybase_16_freeTDS][length = 17 (SQL_NTS)] User Name = [sa][length = 2 (SQL_NTS)] Authentication = [******][length = 6 (SQL_NTS)] UNICODE Using encoding ASCII 'UTF8' and UNICODE 'UTF16LE' DIAG [01000] [FreeTDS][SQL Server]Adaptive Server connection failed DIAG [S1000] [FreeTDS][SQL Server]Unable to connect to data source [ODBC][15829][1530200010.924065][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLConnect.c][4099] Exit:[SQL_ERROR] [/code] The native driver works OK - I can connect without any issues. Do you see any problems? I'm trying to connect with: isql Sybase_16_freeTDS sa Thank you. > > John > > > On Jun 27, 2018, at 10:37 AM, Igor Korot > wrote: > > Hi, ALL, > This post is not directly related to the freeTDS, but I'm hoping that > someone can help. > > I have a latest Sybase 16.0 version Development Edition installed on Linux. > I also have a unixODBC installed. > > I'm trying to connect to the server using the default Sybase ODBC > driver with the > unixODBC isql program. > > Unfortunately I have a problem. The connection works, but then issuing > the simple > query, like "SELECT * FROM ;", where my table is locatedinside > my local database (the one I created) segfaults. > Trying to do the same with the Sybase demo database works fine. > > I didn't try to do anything with the freeTDS driver yet. I will probably do that > over the weekend. > > Does anybody here have Sybase 16 installed? Did you try ODBC connection > to the server? > > Thank you. > > P.S.: Software versions: > 1> select @@version > 2> go > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > Adaptive Server Enterprise/16.0 SP02 PL02/EBF 25320 SMP/P/x86_64/Enterprise Lin > ux/ase160sp02plx/2492/64-bit/FBO/Sat Nov 21 04:05:39 2015 > > (1 row affected) > 1> exit > > [/code] > > [code] > > [ebuild U ] dev-db/unixODBC-2.3.5-r1::gentoo [2.3.2-r1::gentoo] > USE="minimal unicode -odbcmanual -static-libs" ABI_X86="32 (64) > (-x32)" 1,596 KiB > > [/code] > > The current version of unixODBC is 2.3.2-r1 from gentoo repository. > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://url.emailprotection.link/?a95lm_Yz0z4VwVi9HMyQSLtTmToR48n_2Es8x43dIoxidNPkdt4wWeUhbwN1QnbrzawQmZ1BjbOu5bK1zLGmRSw~~ > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds From ikorot01 at gmail.com Thu Jun 28 09:05:29 2018 From: ikorot01 at gmail.com (Igor Korot) Date: Thu, 28 Jun 2018 08:05:29 -0500 Subject: [freetds] License Message-ID: Hi, Is it OK to include the source code of freeTDS in my Software GitHub? Or it has to be DLL only? On top of that - is there MSVC project/solution I can use to build the library? Thank you. From john at capps.com Thu Jun 28 11:02:04 2018 From: john at capps.com (John Kendall) Date: Thu, 28 Jun 2018 15:02:04 +0000 Subject: [freetds] Problem with the latest Sybase ODBC driver In-Reply-To: References: Message-ID: > On Jun 28, 2018, at 5:36 AM, Igor Korot wrote: > > Hi, John, > > On Wed, Jun 27, 2018 at 11:14 AM, John Kendall wrote: >> Igor, >> I'm on Centos 7.5 and it looks like I'm using the exact same version of ASE: >> Adaptive Server Enterprise/16.0 SP02 PL02/EBF 25320 SMP/P/x86_64/Enterprise Linux/ase160sp02plx/2492/64-bit/FBO/Sat Nov 21 04:05:39 2015 >> >> I'm using unixODBC 2.3.1 and the freeTDS odbc driver without issue. >> I recall having the Sybase ODBC driver working, but settled on the FreeTDS driver for simplicity. > > This is my setup: > > [code] > igor at IgorReinCloud ~/dbhandler $ cat /etc/unixODBC/odbcinst.ini > [ODBC] > Trace=yes > TraceFile=/tmp/sql.log > Pooling=No > > [Sybase] > Description=Sybase 16 Native Driver > Driver=/opt/sap/DataAccess64/ODBC/lib/libsybdrvodb.so > UsageCount=1 > > [Sybase_freeTDS] > Description=Sybase FreeTDS Driver > Driver=/usr/lib64/libtdsodbc.so > UsageCount=1 > igor at IgorReinCloud ~/dbhandler $ cat /etc/unixODBC/odbc.ini > [ODBC Data Sources] > Sybase_16_demo=Sybase 16 ODBC driver > Sybase_16_test=Sybase 16 ODBC driver > Sybase_16_freeTDS=Sybase_freeTDS > > [Sybase_16_demo] > Description=Sybase 16 ODBC Driver > Driver=Sybase > Port=5000 > Server=IGORREINCLOUD > UserID=sa > Password= > Database=pubs2 > Option=3 > > [Sybase_16_test] > Description=Sybase 16 ODBC native driver > Driver=Sybase > Port=5000 > Server=IG > Server=IGORREINCLOUD > UserID=sa > Password= > Database=draft > Option=3 > > [Sybase_16_freeTDS] > Description=Sybase 16 freeTDS ODBC driver > Driver=Sybase_freeTDS > Port=5000 > Server=IGORREINCLOUD > UserID=sa > Password= > Database=draft > TDS Version=5.0 > Option=3 > [/code] > > And this is from the ODBC log for freeTDS driver: > > [code] > [ODBC][15829][1530200010.883129][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLConnect.c][3727] > Entry: > Connection = 0x637050 > Server Name = [Sybase_16_freeTDS][length = 17 (SQL_NTS)] > User Name = [sa][length = 2 (SQL_NTS)] > Authentication = [******][length = 6 (SQL_NTS)] > UNICODE Using encoding ASCII 'UTF8' and UNICODE 'UTF16LE' > > DIAG [01000] [FreeTDS][SQL Server]Adaptive Server connection failed > > DIAG [S1000] [FreeTDS][SQL Server]Unable to connect to data source > > [ODBC][15829][1530200010.924065][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLConnect.c][4099] > Exit:[SQL_ERROR] > [/code] > > The native driver works OK - I can connect without any issues. > > Do you see any problems? > > I'm trying to connect with: > > isql Sybase_16_freeTDS sa > > Thank you. Upon further investigation, my ODBC success is via PHP. I am having problems with unixODBC isql as well. So I'm no help. > >> >> John >> >> >> On Jun 27, 2018, at 10:37 AM, Igor Korot > wrote: >> >> Hi, ALL, >> This post is not directly related to the freeTDS, but I'm hoping that >> someone can help. >> >> I have a latest Sybase 16.0 version Development Edition installed on Linux. >> I also have a unixODBC installed. >> >> I'm trying to connect to the server using the default Sybase ODBC >> driver with the >> unixODBC isql program. >> >> Unfortunately I have a problem. The connection works, but then issuing >> the simple >> query, like "SELECT * FROM ;", where my table is locatedinside >> my local database (the one I created) segfaults. >> Trying to do the same with the Sybase demo database works fine. >> >> I didn't try to do anything with the freeTDS driver yet. I will probably do that >> over the weekend. >> >> Does anybody here have Sybase 16 installed? Did you try ODBC connection >> to the server? >> >> Thank you. >> >> P.S.: Software versions: >> 1> select @@version >> 2> go >> >> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ >> Adaptive Server Enterprise/16.0 SP02 PL02/EBF 25320 SMP/P/x86_64/Enterprise Lin >> ux/ase160sp02plx/2492/64-bit/FBO/Sat Nov 21 04:05:39 2015 >> >> (1 row affected) >> 1> exit >> >> [/code] >> >> [code] >> >> [ebuild U ] dev-db/unixODBC-2.3.5-r1::gentoo [2.3.2-r1::gentoo] >> USE="minimal unicode -odbcmanual -static-libs" ABI_X86="32 (64) >> (-x32)" 1,596 KiB >> >> [/code] >> >> The current version of unixODBC is 2.3.2-r1 from gentoo repository. >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> https://url.emailprotection.link/?a95lm_Yz0z4VwVi9HMyQSLtTmToR48n_2Es8x43dIoxidNPkdt4wWeUhbwN1QnbrzawQmZ1BjbOu5bK1zLGmRSw~~ >> >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> https://url.emailprotection.link/?a95lm_Yz0z4VwVi9HMyQSLtTmToR48n_2Es8x43dIoxidNPkdt4wWeUhbwN1QnbrzawQmZ1BjbOu5bK1zLGmRSw~~ > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://url.emailprotection.link/?a95lm_Yz0z4VwVi9HMyQSLtTmToR48n_2Es8x43dIoxidNPkdt4wWeUhbwN1QnbrzawQmZ1BjbOu5bK1zLGmRSw~~ From ikorot01 at gmail.com Thu Jun 28 23:26:00 2018 From: ikorot01 at gmail.com (Igor Korot) Date: Thu, 28 Jun 2018 20:26:00 -0700 Subject: [freetds] Problem with the latest Sybase ODBC driver In-Reply-To: References: Message-ID: This is the ODBC trace log for the freeTDS ODBC driver trying to connect to Sybase 16 server. On Wed, Jun 27, 2018 at 11:44 PM, Frediano Ziglio wrote: > 2018-06-27 18:37 GMT+01:00 Igor Korot : >> Hi, ALL, >> This post is not directly related to the freeTDS, but I'm hoping that >> someone can help. >> >> I have a latest Sybase 16.0 version Development Edition installed on Linux. >> I also have a unixODBC installed. >> >> I'm trying to connect to the server using the default Sybase ODBC >> driver with the >> unixODBC isql program. >> >> Unfortunately I have a problem. The connection works, but then issuing >> the simple >> query, like "SELECT * FROM ;", where my table is locatedinside >> my local database (the one I created) segfaults. >> Trying to do the same with the Sybase demo database works fine. >> >> I didn't try to do anything with the freeTDS driver yet. I will probably do that >> over the weekend. >> >> Does anybody here have Sybase 16 installed? Did you try ODBC connection >> to the server? >> >> Thank you. >> >> P.S.: Software versions: >> 1> select @@version >> 2> go >> >> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ >> Adaptive Server Enterprise/16.0 SP02 PL02/EBF 25320 SMP/P/x86_64/Enterprise Lin >> ux/ase160sp02plx/2492/64-bit/FBO/Sat Nov 21 04:05:39 2015 >> >> (1 row affected) >> 1> exit >> >> [/code] >> >> [code] >> >> [ebuild U ] dev-db/unixODBC-2.3.5-r1::gentoo [2.3.2-r1::gentoo] >> USE="minimal unicode -odbcmanual -static-libs" ABI_X86="32 (64) >> (-x32)" 1,596 KiB >> >> [/code] >> >> The current version of unixODBC is 2.3.2-r1 from gentoo repository. > > Sounds a silly question: are unixODBC and Sybase driver using the > same ABI? Yes, sounds crazy but unixODBC can be compiled with > slightly different ABIs on 64 bit. > You could enable ODBC tracing to see the last call producing the fault. > Maybe program is using wide functions and this is the issue? > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds -------------- next part -------------- [ODBC][15829][1530200010.882705][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/__handles.c][460] Exit:[SQL_SUCCESS] Environment = 0x636750 [ODBC][15829][1530200010.882949][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLAllocHandle.c][375] Entry: Handle Type = 2 Input Handle = 0x636750 [ODBC][15829][1530200010.883038][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLAllocHandle.c][493] Exit:[SQL_SUCCESS] Output Handle = 0x637050 [ODBC][15829][1530200010.883129][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLConnect.c][3727] Entry: Connection = 0x637050 Server Name = [Sybase_16_freeTDS][length = 17 (SQL_NTS)] User Name = [sa][length = 2 (SQL_NTS)] Authentication = [******][length = 6 (SQL_NTS)] UNICODE Using encoding ASCII 'UTF8' and UNICODE 'UTF16LE' DIAG [01000] [FreeTDS][SQL Server]Adaptive Server connection failed DIAG [S1000] [FreeTDS][SQL Server]Unable to connect to data source [ODBC][15829][1530200010.924065][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLConnect.c][4099] Exit:[SQL_ERROR] [ODBC][15829][1530200010.924244][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLFreeHandle.c][284] Entry: Handle Type = 2 Input Handle = 0x637050 [ODBC][15829][1530200010.924322][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLFreeHandle.c][333] Exit:[SQL_SUCCESS] [ODBC][15829][1530200010.924395][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLFreeHandle.c][219] Entry: Handle Type = 1 Input Handle = 0x636750 From ikorot01 at gmail.com Thu Jun 28 23:28:35 2018 From: ikorot01 at gmail.com (Igor Korot) Date: Thu, 28 Jun 2018 20:28:35 -0700 Subject: [freetds] Problem with the latest Sybase ODBC driver In-Reply-To: References: Message-ID: And this is the log from the segmentation fault. On Thu, Jun 28, 2018 at 8:26 PM, Igor Korot wrote: > This is the ODBC trace log for the freeTDS ODBC driver trying to > connect to Sybase 16 server. > > On Wed, Jun 27, 2018 at 11:44 PM, Frediano Ziglio wrote: >> 2018-06-27 18:37 GMT+01:00 Igor Korot : >>> Hi, ALL, >>> This post is not directly related to the freeTDS, but I'm hoping that >>> someone can help. >>> >>> I have a latest Sybase 16.0 version Development Edition installed on Linux. >>> I also have a unixODBC installed. >>> >>> I'm trying to connect to the server using the default Sybase ODBC >>> driver with the >>> unixODBC isql program. >>> >>> Unfortunately I have a problem. The connection works, but then issuing >>> the simple >>> query, like "SELECT * FROM ;", where my table is locatedinside >>> my local database (the one I created) segfaults. >>> Trying to do the same with the Sybase demo database works fine. >>> >>> I didn't try to do anything with the freeTDS driver yet. I will probably do that >>> over the weekend. >>> >>> Does anybody here have Sybase 16 installed? Did you try ODBC connection >>> to the server? >>> >>> Thank you. >>> >>> P.S.: Software versions: >>> 1> select @@version >>> 2> go >>> >>> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ >>> Adaptive Server Enterprise/16.0 SP02 PL02/EBF 25320 SMP/P/x86_64/Enterprise Lin >>> ux/ase160sp02plx/2492/64-bit/FBO/Sat Nov 21 04:05:39 2015 >>> >>> (1 row affected) >>> 1> exit >>> >>> [/code] >>> >>> [code] >>> >>> [ebuild U ] dev-db/unixODBC-2.3.5-r1::gentoo [2.3.2-r1::gentoo] >>> USE="minimal unicode -odbcmanual -static-libs" ABI_X86="32 (64) >>> (-x32)" 1,596 KiB >>> >>> [/code] >>> >>> The current version of unixODBC is 2.3.2-r1 from gentoo repository. >> >> Sounds a silly question: are unixODBC and Sybase driver using the >> same ABI? Yes, sounds crazy but unixODBC can be compiled with >> slightly different ABIs on 64 bit. >> You could enable ODBC tracing to see the last call producing the fault. >> Maybe program is using wide functions and this is the issue? >> >> Frediano >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> https://lists.ibiblio.org/mailman/listinfo/freetds -------------- next part -------------- [ODBC][19355][1530253655.545025][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/__handles.c][460] Exit:[SQL_SUCCESS] Environment = 0xc8a750 [ODBC][19355][1530253655.545139][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLAllocHandle.c][375] Entry: Handle Type = 2 Input Handle = 0xc8a750 [ODBC][19355][1530253655.545185][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLAllocHandle.c][493] Exit:[SQL_SUCCESS] Output Handle = 0xc8b050 [ODBC][19355][1530253655.545236][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLConnect.c][3727] Entry: Connection = 0xc8b050 Server Name = [Sybase_16_test][length = 14 (SQL_NTS)] User Name = [sa][length = 2 (SQL_NTS)] Authentication = [******][length = 6 (SQL_NTS)] UNICODE Using encoding ASCII 'UTF8' and UNICODE 'UTF16LE' DIAG [ZZZZZ] [SAP][ASE ODBC Driver][Adaptive Server Enterprise]Changed client character set setting to 'utf8'. DIAG [ZZZZZ] [SAP][ASE ODBC Driver][Adaptive Server Enterprise]Changed database context to 'master'. DIAG [ZZZZZ] [SAP][ASE ODBC Driver][Adaptive Server Enterprise]Changed language setting to 'us_english'. DIAG [ZZZZZ] [SAP][ASE ODBC Driver][Adaptive Server Enterprise]Changed database context to 'draft'. [ODBC][19355][1530253655.878055][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLConnect.c][4305] Exit:[SQL_SUCCESS_WITH_INFO] DIAG [ZZZZZ] [SAP][ASE ODBC Driver][Adaptive Server Enterprise]Changed client character set setting to 'utf8'. DIAG [ZZZZZ] [SAP][ASE ODBC Driver][Adaptive Server Enterprise]Changed database context to 'master'. DIAG [ZZZZZ] [SAP][ASE ODBC Driver][Adaptive Server Enterprise]Changed language setting to 'us_english'. DIAG [ZZZZZ] [SAP][ASE ODBC Driver][Adaptive Server Enterprise]Changed database context to 'draft'. [ODBC][19355][1530253655.878528][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLGetFunctions.c][151] Entry: Connection = 0xc8b050 Id = SQLMoreResults Supported = 0x607210 [ODBC][19355][1530253655.878601][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLGetFunctions.c][186] Exit:[SQL_SUCCESS] Supported = 0x607210 -> 1 [ODBC][19355][1530253669.967728][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLAllocHandle.c][540] Entry: Handle Type = 3 Input Handle = 0xc8b050 [ODBC][19355][1530253669.968000][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLAllocHandle.c][1081] Exit:[SQL_SUCCESS] Output Handle = 0xd0d500 [ODBC][19355][1530253669.968054][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLPrepare.c][196] Entry: Statement = 0xd0d500 SQL = [SELECT * FROM leagues;][length = 22] [ODBC][19355][1530253669.968249][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLPrepare.c][371] Exit:[SQL_SUCCESS] [ODBC][19355][1530253669.968291][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLExecute.c][187] Entry: Statement = 0xd0d500 [ODBC][19355][1530253669.970817][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLExecute.c][348] Exit:[SQL_SUCCESS] [ODBC][19355][1530253669.971040][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLNumResultCols.c][156] Entry: Statement = 0xd0d500 Column Count = 0x7ffd995ecd6e [ODBC][19355][1530253669.971138][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLNumResultCols.c][248] Exit:[SQL_SUCCESS] Count = 0x7ffd995ecd6e -> 8 [ODBC][19355][1530253669.971263][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLNumResultCols.c][156] Entry: Statement = 0xd0d500 Column Count = 0x7ffd995eca8e [ODBC][19355][1530253669.971337][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLNumResultCols.c][248] Exit:[SQL_SUCCESS] Count = 0x7ffd995eca8e -> 8 [ODBC][19355][1530253669.971489][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][293] Entry: Statement = 0xd0d500 Column Number = 1 Field Identifier = SQL_DESC_DISPLAY_SIZE Character Attr = (nil) Buffer Length = 0 String Length = (nil) Numeric Attribute = 0x7ffd995ec8f8 [ODBC][19355][1530253669.971568][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][666] Exit:[SQL_SUCCESS] [ODBC][19355][1530253669.971639][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][293] Entry: Statement = 0xd0d500 Column Number = 1 Field Identifier = SQL_DESC_LABEL Character Attr = 0x7ffd995ec900 Buffer Length = 301 String Length = (nil) Numeric Attribute = (nil) [ODBC][19355][1530253669.971710][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][666] Exit:[SQL_SUCCESS] [ODBC][19355][1530253669.971781][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][293] Entry: Statement = 0xd0d500 Column Number = 1 Field Identifier = SQL_DESC_LABEL Character Attr = 0x7ffd995eca90 Buffer Length = 301 String Length = (nil) Numeric Attribute = (nil) [ODBC][19355][1530253669.971848][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][666] Exit:[SQL_SUCCESS] [ODBC][19355][1530253669.971966][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][293] Entry: Statement = 0xd0d500 Column Number = 2 Field Identifier = SQL_DESC_DISPLAY_SIZE Character Attr = (nil) Buffer Length = 0 String Length = (nil) Numeric Attribute = 0x7ffd995ec8f8 [ODBC][19355][1530253669.972036][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][666] Exit:[SQL_SUCCESS] [ODBC][19355][1530253669.972104][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][293] Entry: Statement = 0xd0d500 Column Number = 2 Field Identifier = SQL_DESC_LABEL Character Attr = 0x7ffd995ec900 Buffer Length = 301 String Length = (nil) Numeric Attribute = (nil) [ODBC][19355][1530253669.972171][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][666] Exit:[SQL_SUCCESS] [ODBC][19355][1530253669.972239][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][293] Entry: Statement = 0xd0d500 Column Number = 2 Field Identifier = SQL_DESC_LABEL Character Attr = 0x7ffd995eca90 Buffer Length = 301 String Length = (nil) Numeric Attribute = (nil) [ODBC][19355][1530253669.972305][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][666] Exit:[SQL_SUCCESS] [ODBC][19355][1530253669.972382][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][293] Entry: Statement = 0xd0d500 Column Number = 3 Field Identifier = SQL_DESC_DISPLAY_SIZE Character Attr = (nil) Buffer Length = 0 String Length = (nil) Numeric Attribute = 0x7ffd995ec8f8 [ODBC][19355][1530253669.972451][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][666] Exit:[SQL_SUCCESS] [ODBC][19355][1530253669.972518][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][293] Entry: Statement = 0xd0d500 Column Number = 3 Field Identifier = SQL_DESC_LABEL Character Attr = 0x7ffd995ec900 Buffer Length = 301 String Length = (nil) Numeric Attribute = (nil) [ODBC][19355][1530253669.972584][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][666] Exit:[SQL_SUCCESS] [ODBC][19355][1530253669.972652][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][293] Entry: Statement = 0xd0d500 Column Number = 3 Field Identifier = SQL_DESC_LABEL Character Attr = 0x7ffd995eca90 Buffer Length = 301 String Length = (nil) Numeric Attribute = (nil) [ODBC][19355][1530253669.972750][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][666] Exit:[SQL_SUCCESS] [ODBC][19355][1530253669.972825][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][293] Entry: Statement = 0xd0d500 Column Number = 4 Field Identifier = SQL_DESC_DISPLAY_SIZE Character Attr = (nil) Buffer Length = 0 String Length = (nil) Numeric Attribute = 0x7ffd995ec8f8 [ODBC][19355][1530253669.972909][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][666] Exit:[SQL_SUCCESS] [ODBC][19355][1530253669.972978][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][293] Entry: Statement = 0xd0d500 Column Number = 4 Field Identifier = SQL_DESC_LABEL Character Attr = 0x7ffd995ec900 Buffer Length = 301 String Length = (nil) Numeric Attribute = (nil) [ODBC][19355][1530253669.973047][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][666] Exit:[SQL_SUCCESS] [ODBC][19355][1530253669.973115][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][293] Entry: Statement = 0xd0d500 Column Number = 4 Field Identifier = SQL_DESC_LABEL Character Attr = 0x7ffd995eca90 Buffer Length = 301 String Length = (nil) Numeric Attribute = (nil) [ODBC][19355][1530253669.973182][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][666] Exit:[SQL_SUCCESS] [ODBC][19355][1530253669.973254][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][293] Entry: Statement = 0xd0d500 Column Number = 5 Field Identifier = SQL_DESC_DISPLAY_SIZE Character Attr = (nil) Buffer Length = 0 String Length = (nil) Numeric Attribute = 0x7ffd995ec8f8 [ODBC][19355][1530253669.973320][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][666] Exit:[SQL_SUCCESS] [ODBC][19355][1530253669.973389][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][293] Entry: Statement = 0xd0d500 Column Number = 5 Field Identifier = SQL_DESC_LABEL Character Attr = 0x7ffd995ec900 Buffer Length = 301 String Length = (nil) Numeric Attribute = (nil) [ODBC][19355][1530253669.973455][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][666] Exit:[SQL_SUCCESS] [ODBC][19355][1530253669.973524][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][293] Entry: Statement = 0xd0d500 Column Number = 5 Field Identifier = SQL_DESC_LABEL Character Attr = 0x7ffd995eca90 Buffer Length = 301 String Length = (nil) Numeric Attribute = (nil) [ODBC][19355][1530253669.973589][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][666] Exit:[SQL_SUCCESS] [ODBC][19355][1530253669.973660][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][293] Entry: Statement = 0xd0d500 Column Number = 6 Field Identifier = SQL_DESC_DISPLAY_SIZE Character Attr = (nil) Buffer Length = 0 String Length = (nil) Numeric Attribute = 0x7ffd995ec8f8 [ODBC][19355][1530253669.973726][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][666] Exit:[SQL_SUCCESS] [ODBC][19355][1530253669.973794][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][293] Entry: Statement = 0xd0d500 Column Number = 6 Field Identifier = SQL_DESC_LABEL Character Attr = 0x7ffd995ec900 Buffer Length = 301 String Length = (nil) Numeric Attribute = (nil) [ODBC][19355][1530253669.974171][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][666] Exit:[SQL_SUCCESS] [ODBC][19355][1530253669.974254][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][293] Entry: Statement = 0xd0d500 Column Number = 6 Field Identifier = SQL_DESC_LABEL Character Attr = 0x7ffd995eca90 Buffer Length = 301 String Length = (nil) Numeric Attribute = (nil) [ODBC][19355][1530253669.974324][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][666] Exit:[SQL_SUCCESS] [ODBC][19355][1530253669.974399][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][293] Entry: Statement = 0xd0d500 Column Number = 7 Field Identifier = SQL_DESC_DISPLAY_SIZE Character Attr = (nil) Buffer Length = 0 String Length = (nil) Numeric Attribute = 0x7ffd995ec8f8 [ODBC][19355][1530253669.974467][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][666] Exit:[SQL_SUCCESS] [ODBC][19355][1530253669.974535][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][293] Entry: Statement = 0xd0d500 Column Number = 7 Field Identifier = SQL_DESC_LABEL Character Attr = 0x7ffd995ec900 Buffer Length = 301 String Length = (nil) Numeric Attribute = (nil) [ODBC][19355][1530253669.974600][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][666] Exit:[SQL_SUCCESS] [ODBC][19355][1530253669.974668][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][293] Entry: Statement = 0xd0d500 Column Number = 7 Field Identifier = SQL_DESC_LABEL Character Attr = 0x7ffd995eca90 Buffer Length = 301 String Length = (nil) Numeric Attribute = (nil) [ODBC][19355][1530253669.974734][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][666] Exit:[SQL_SUCCESS] [ODBC][19355][1530253669.974807][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][293] Entry: Statement = 0xd0d500 Column Number = 8 Field Identifier = SQL_DESC_DISPLAY_SIZE Character Attr = (nil) Buffer Length = 0 String Length = (nil) Numeric Attribute = 0x7ffd995ec8f8 [ODBC][19355][1530253669.974893][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][666] Exit:[SQL_SUCCESS] [ODBC][19355][1530253669.974966][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][293] Entry: Statement = 0xd0d500 Column Number = 8 Field Identifier = SQL_DESC_LABEL Character Attr = 0x7ffd995ec900 Buffer Length = 301 String Length = (nil) Numeric Attribute = (nil) [ODBC][19355][1530253669.975033][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][666] Exit:[SQL_SUCCESS] [ODBC][19355][1530253669.975101][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][293] Entry: Statement = 0xd0d500 Column Number = 8 Field Identifier = SQL_DESC_LABEL Character Attr = 0x7ffd995eca90 Buffer Length = 301 String Length = (nil) Numeric Attribute = (nil) [ODBC][19355][1530253669.975165][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][666] Exit:[SQL_SUCCESS] [ODBC][19355][1530253669.975529][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLNumResultCols.c][156] Entry: Statement = 0xd0d500 Column Count = 0x7ffd995eca96 [ODBC][19355][1530253669.975669][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLNumResultCols.c][248] Exit:[SQL_SUCCESS] Count = 0x7ffd995eca96 -> 8 [ODBC][19355][1530253669.975741][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLFetch.c][162] Entry: Statement = 0xd0d500 [ODBC][19355][1530253669.975907][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLFetch.c][348] Exit:[SQL_SUCCESS] [ODBC][19355][1530253669.975981][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][293] Entry: Statement = 0xd0d500 Column Number = 1 Field Identifier = SQL_DESC_DISPLAY_SIZE Character Attr = (nil) Buffer Length = 0 String Length = (nil) Numeric Attribute = 0x7ffd995ec918 [ODBC][19355][1530253669.976050][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][666] Exit:[SQL_SUCCESS] [ODBC][19355][1530253669.976118][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][293] Entry: Statement = 0xd0d500 Column Number = 1 Field Identifier = SQL_DESC_LABEL Character Attr = 0x7ffd995ec920 Buffer Length = 301 String Length = (nil) Numeric Attribute = (nil) [ODBC][19355][1530253669.976187][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][666] Exit:[SQL_SUCCESS] [ODBC][19355][1530253669.976262][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLGetData.c][237] Entry: Statement = 0xd0d500 Column Number = 1 Target Type = 1 SQL_CHAR Buffer Length = 301 Target Value = 0x7ffd995ecaa0 StrLen Or Ind = 0x7ffd995eca98 [ODBC][19355][1530253669.976379][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLGetData.c][501] Exit:[SQL_SUCCESS] Buffer = [1] Strlen Or Ind = 0x7ffd995eca98 -> 1 [ODBC][19355][1530253669.976457][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][293] Entry: Statement = 0xd0d500 Column Number = 2 Field Identifier = SQL_DESC_DISPLAY_SIZE Character Attr = (nil) Buffer Length = 0 String Length = (nil) Numeric Attribute = 0x7ffd995ec918 [ODBC][19355][1530253669.976527][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][666] Exit:[SQL_SUCCESS] [ODBC][19355][1530253669.976595][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][293] Entry: Statement = 0xd0d500 Column Number = 2 Field Identifier = SQL_DESC_LABEL Character Attr = 0x7ffd995ec920 Buffer Length = 301 String Length = (nil) Numeric Attribute = (nil) [ODBC][19355][1530253669.976661][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][666] Exit:[SQL_SUCCESS] [ODBC][19355][1530253669.976730][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLGetData.c][237] Entry: Statement = 0xd0d500 Column Number = 2 Target Type = 1 SQL_CHAR Buffer Length = 301 Target Value = 0x7ffd995ecaa0 StrLen Or Ind = 0x7ffd995eca98 [ODBC][19355][1530253669.976860][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLGetData.c][501] Exit:[SQL_SUCCESS] Buffer = [Demo - Roto (Auction)] Strlen Or Ind = 0x7ffd995eca98 -> 21 [ODBC][19355][1530253669.976989][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][293] Entry: Statement = 0xd0d500 Column Number = 3 Field Identifier = SQL_DESC_DISPLAY_SIZE Character Attr = (nil) Buffer Length = 0 String Length = (nil) Numeric Attribute = 0x7ffd995ec918 [ODBC][19355][1530253669.977057][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][666] Exit:[SQL_SUCCESS] [ODBC][19355][1530253669.977126][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][293] Entry: Statement = 0xd0d500 Column Number = 3 Field Identifier = SQL_DESC_LABEL Character Attr = 0x7ffd995ec920 Buffer Length = 301 String Length = (nil) Numeric Attribute = (nil) [ODBC][19355][1530253669.977225][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][666] Exit:[SQL_SUCCESS] [ODBC][19355][1530253669.977295][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLGetData.c][237] Entry: Statement = 0xd0d500 Column Number = 3 Target Type = 1 SQL_CHAR Buffer Length = 301 Target Value = 0x7ffd995ecaa0 StrLen Or Ind = 0x7ffd995eca98 [ODBC][19355][1530253669.977393][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLGetData.c][501] Exit:[SQL_SUCCESS] Buffer = [1] Strlen Or Ind = 0x7ffd995eca98 -> 1 [ODBC][19355][1530253669.977467][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][293] Entry: Statement = 0xd0d500 Column Number = 4 Field Identifier = SQL_DESC_DISPLAY_SIZE Character Attr = (nil) Buffer Length = 0 String Length = (nil) Numeric Attribute = 0x7ffd995ec918 [ODBC][19355][1530253669.977532][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][666] Exit:[SQL_SUCCESS] [ODBC][19355][1530253669.977600][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][293] Entry: Statement = 0xd0d500 Column Number = 4 Field Identifier = SQL_DESC_LABEL Character Attr = 0x7ffd995ec920 Buffer Length = 301 String Length = (nil) Numeric Attribute = (nil) [ODBC][19355][1530253669.977666][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][666] Exit:[SQL_SUCCESS] [ODBC][19355][1530253669.977734][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLGetData.c][237] Entry: Statement = 0xd0d500 Column Number = 4 Target Type = 1 SQL_CHAR Buffer Length = 301 Target Value = 0x7ffd995ecaa0 StrLen Or Ind = 0x7ffd995eca98 [ODBC][19355][1530253669.977829][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLGetData.c][501] Exit:[SQL_SUCCESS] Buffer = [1] Strlen Or Ind = 0x7ffd995eca98 -> 1 [ODBC][19355][1530253669.977948][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][293] Entry: Statement = 0xd0d500 Column Number = 5 Field Identifier = SQL_DESC_DISPLAY_SIZE Character Attr = (nil) Buffer Length = 0 String Length = (nil) Numeric Attribute = 0x7ffd995ec918 [ODBC][19355][1530253669.978016][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][666] Exit:[SQL_SUCCESS] [ODBC][19355][1530253669.978084][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][293] Entry: Statement = 0xd0d500 Column Number = 5 Field Identifier = SQL_DESC_LABEL Character Attr = 0x7ffd995ec920 Buffer Length = 301 String Length = (nil) Numeric Attribute = (nil) [ODBC][19355][1530253669.978150][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][666] Exit:[SQL_SUCCESS] [ODBC][19355][1530253669.978217][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLGetData.c][237] Entry: Statement = 0xd0d500 Column Number = 5 Target Type = 1 SQL_CHAR Buffer Length = 301 Target Value = 0x7ffd995ecaa0 StrLen Or Ind = 0x7ffd995eca98 [ODBC][19355][1530253669.978311][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLGetData.c][501] Exit:[SQL_SUCCESS] Buffer = [1] Strlen Or Ind = 0x7ffd995eca98 -> 1 [ODBC][19355][1530253669.978385][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][293] Entry: Statement = 0xd0d500 Column Number = 6 Field Identifier = SQL_DESC_DISPLAY_SIZE Character Attr = (nil) Buffer Length = 0 String Length = (nil) Numeric Attribute = 0x7ffd995ec918 [ODBC][19355][1530253669.978480][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][666] Exit:[SQL_SUCCESS] [ODBC][19355][1530253669.978549][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][293] Entry: Statement = 0xd0d500 Column Number = 6 Field Identifier = SQL_DESC_LABEL Character Attr = 0x7ffd995ec920 Buffer Length = 301 String Length = (nil) Numeric Attribute = (nil) [ODBC][19355][1530253669.978615][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][666] Exit:[SQL_SUCCESS] [ODBC][19355][1530253669.978683][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLGetData.c][237] Entry: Statement = 0xd0d500 Column Number = 6 Target Type = 1 SQL_CHAR Buffer Length = 301 Target Value = 0x7ffd995ecaa0 StrLen Or Ind = 0x7ffd995eca98 [ODBC][19355][1530253669.978806][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLGetData.c][501] Exit:[SQL_SUCCESS] Buffer = [demo ] Strlen Or Ind = 0x7ffd995eca98 -> 5 [ODBC][19355][1530253669.978900][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][293] Entry: Statement = 0xd0d500 Column Number = 7 Field Identifier = SQL_DESC_DISPLAY_SIZE Character Attr = (nil) Buffer Length = 0 String Length = (nil) Numeric Attribute = 0x7ffd995ec918 [ODBC][19355][1530253669.978969][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][666] Exit:[SQL_SUCCESS] [ODBC][19355][1530253669.979036][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][293] Entry: Statement = 0xd0d500 Column Number = 7 Field Identifier = SQL_DESC_LABEL Character Attr = 0x7ffd995ec920 Buffer Length = 301 String Length = (nil) Numeric Attribute = (nil) [ODBC][19355][1530253669.979103][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][666] Exit:[SQL_SUCCESS] [ODBC][19355][1530253669.979171][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLGetData.c][237] Entry: Statement = 0xd0d500 Column Number = 7 Target Type = 1 SQL_CHAR Buffer Length = 301 Target Value = 0x7ffd995ecaa0 StrLen Or Ind = 0x7ffd995eca98 [ODBC][19355][1530253669.979271][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLGetData.c][501] Exit:[SQL_SUCCESS] Buffer = [260] Strlen Or Ind = 0x7ffd995eca98 -> 3 [ODBC][19355][1530253669.979346][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][293] Entry: Statement = 0xd0d500 Column Number = 8 Field Identifier = SQL_DESC_DISPLAY_SIZE Character Attr = (nil) Buffer Length = 0 String Length = (nil) Numeric Attribute = 0x7ffd995ec918 [ODBC][19355][1530253669.979412][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][666] Exit:[SQL_SUCCESS] [ODBC][19355][1530253669.979482][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][293] Entry: Statement = 0xd0d500 Column Number = 8 Field Identifier = SQL_DESC_LABEL Character Attr = 0x7ffd995ec920 Buffer Length = 301 String Length = (nil) Numeric Attribute = (nil) [ODBC][19355][1530253669.979548][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLColAttribute.c][666] Exit:[SQL_SUCCESS] [ODBC][19355][1530253669.979617][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLGetData.c][237] Entry: Statement = 0xd0d500 Column Number = 8 Target Type = 1 SQL_CHAR Buffer Length = 301 Target Value = 0x7ffd995ecaa0 StrLen Or Ind = 0x7ffd995eca98 [ODBC][19355][1530253669.979712][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLGetData.c][501] Exit:[SQL_SUCCESS] Buffer = [0] Strlen Or Ind = 0x7ffd995eca98 -> 1 [ODBC][19355][1530253669.983036][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLFetch.c][162] Entry: Statement = 0xd0d500 From freddy77 at gmail.com Fri Jun 29 07:30:30 2018 From: freddy77 at gmail.com (Frediano Ziglio) Date: Fri, 29 Jun 2018 12:30:30 +0100 Subject: [freetds] License In-Reply-To: References: Message-ID: 2018-06-28 14:05 GMT+01:00 Igor Korot : > Hi, > Is it OK to include the source code of freeTDS in my Software GitHub? > Or it has to be DLL only? > The main libraries are covered by LGPL. You can include them if your software is OpenSource. You don't need to be LGPL too, the main requirement is being able to change the LGPL part, would be also fine if your code was only in binary format linking with the LGPL sources. For more information see license. > On top of that - is there MSVC project/solution I can use to build the library? > You can create any project file you need with cmake. I think newer Visual Studio has embedded cmake support, if not just download and install cmake. > Thank you. Frediano From sf at 4js.com Fri Jun 29 09:09:09 2018 From: sf at 4js.com (Sebastien FLAESCH) Date: Fri, 29 Jun 2018 15:09:09 +0200 Subject: [freetds] SQLExecDirect() + SQLDataParam() + SQLPutData() fails Message-ID: <468b6021-9fb9-2738-ae70-1618b035490c@4js.com> 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 From sf at 4js.com Fri Jun 29 09:50:59 2018 From: sf at 4js.com (Sebastien FLAESCH) Date: Fri, 29 Jun 2018 15:50:59 +0200 Subject: [freetds] SQLExecDirect() + SQLDataParam() + SQLPutData() fails In-Reply-To: <468b6021-9fb9-2738-ae70-1618b035490c@4js.com> References: <468b6021-9fb9-2738-ae70-1618b035490c@4js.com> Message-ID: 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 > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds > -------------- next part -------------- A non-text attachment was scrubbed... Name: odbctest3.c Type: text/x-csrc Size: 6168 bytes Desc: not available URL: From no-reply at appveyor.com Fri Jun 29 12:37:19 2018 From: no-reply at appveyor.com (AppVeyor) Date: Fri, 29 Jun 2018 16:37:19 +0000 Subject: [freetds] Build failed: freetds 1059 Message-ID: <20180629163719.1.3EA88D94C34FC1D2@appveyor.com> From no-reply at appveyor.com Sat Jun 30 14:29:42 2018 From: no-reply at appveyor.com (AppVeyor) Date: Sat, 30 Jun 2018 18:29:42 +0000 Subject: [freetds] Build failed: freetds 1063 Message-ID: <20180630182942.1.073956770AE149A3@appveyor.com> From ikorot01 at gmail.com Sat Jun 30 21:08:03 2018 From: ikorot01 at gmail.com (Igor Korot) Date: Sat, 30 Jun 2018 20:08:03 -0500 Subject: [freetds] Problem with the latest Sybase ODBC driver In-Reply-To: References: Message-ID: Frediano, Any idea why freeTDS fails to connect? Thank you. On Thu, Jun 28, 2018 at 8:02 AM, John Kendall wrote: > >> On Jun 28, 2018, at 5:36 AM, Igor Korot wrote: >> >> Hi, John, >> >> On Wed, Jun 27, 2018 at 11:14 AM, John Kendall wrote: >>> Igor, >>> I'm on Centos 7.5 and it looks like I'm using the exact same version of ASE: >>> Adaptive Server Enterprise/16.0 SP02 PL02/EBF 25320 SMP/P/x86_64/Enterprise Linux/ase160sp02plx/2492/64-bit/FBO/Sat Nov 21 04:05:39 2015 >>> >>> I'm using unixODBC 2.3.1 and the freeTDS odbc driver without issue. >>> I recall having the Sybase ODBC driver working, but settled on the FreeTDS driver for simplicity. >> >> This is my setup: >> >> [code] >> igor at IgorReinCloud ~/dbhandler $ cat /etc/unixODBC/odbcinst.ini >> [ODBC] >> Trace=yes >> TraceFile=/tmp/sql.log >> Pooling=No >> >> [Sybase] >> Description=Sybase 16 Native Driver >> Driver=/opt/sap/DataAccess64/ODBC/lib/libsybdrvodb.so >> UsageCount=1 >> >> [Sybase_freeTDS] >> Description=Sybase FreeTDS Driver >> Driver=/usr/lib64/libtdsodbc.so >> UsageCount=1 >> igor at IgorReinCloud ~/dbhandler $ cat /etc/unixODBC/odbc.ini >> [ODBC Data Sources] >> Sybase_16_demo=Sybase 16 ODBC driver >> Sybase_16_test=Sybase 16 ODBC driver >> Sybase_16_freeTDS=Sybase_freeTDS >> >> [Sybase_16_demo] >> Description=Sybase 16 ODBC Driver >> Driver=Sybase >> Port=5000 >> Server=IGORREINCLOUD >> UserID=sa >> Password= >> Database=pubs2 >> Option=3 >> >> [Sybase_16_test] >> Description=Sybase 16 ODBC native driver >> Driver=Sybase >> Port=5000 >> Server=IG >> Server=IGORREINCLOUD >> UserID=sa >> Password= >> Database=draft >> Option=3 >> >> [Sybase_16_freeTDS] >> Description=Sybase 16 freeTDS ODBC driver >> Driver=Sybase_freeTDS >> Port=5000 >> Server=IGORREINCLOUD >> UserID=sa >> Password= >> Database=draft >> TDS Version=5.0 >> Option=3 >> [/code] >> >> And this is from the ODBC log for freeTDS driver: >> >> [code] >> [ODBC][15829][1530200010.883129][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLConnect.c][3727] >> Entry: >> Connection = 0x637050 >> Server Name = [Sybase_16_freeTDS][length = 17 (SQL_NTS)] >> User Name = [sa][length = 2 (SQL_NTS)] >> Authentication = [******][length = 6 (SQL_NTS)] >> UNICODE Using encoding ASCII 'UTF8' and UNICODE 'UTF16LE' >> >> DIAG [01000] [FreeTDS][SQL Server]Adaptive Server connection failed >> >> DIAG [S1000] [FreeTDS][SQL Server]Unable to connect to data source >> >> [ODBC][15829][1530200010.924065][/var/tmp/portage/dev-db/unixODBC-2.3.2-r1/work/unixODBC-2.3.2/DriverManager/SQLConnect.c][4099] >> Exit:[SQL_ERROR] >> [/code] >> >> The native driver works OK - I can connect without any issues. >> >> Do you see any problems? >> >> I'm trying to connect with: >> >> isql Sybase_16_freeTDS sa >> >> Thank you. > > Upon further investigation, my ODBC success is via PHP. I am having problems with unixODBC isql as well. > So I'm no help. > >> >>> >>> John >>> >>> >>> On Jun 27, 2018, at 10:37 AM, Igor Korot > wrote: >>> >>> Hi, ALL, >>> This post is not directly related to the freeTDS, but I'm hoping that >>> someone can help. >>> >>> I have a latest Sybase 16.0 version Development Edition installed on Linux. >>> I also have a unixODBC installed. >>> >>> I'm trying to connect to the server using the default Sybase ODBC >>> driver with the >>> unixODBC isql program. >>> >>> Unfortunately I have a problem. The connection works, but then issuing >>> the simple >>> query, like "SELECT * FROM ;", where my table is locatedinside >>> my local database (the one I created) segfaults. >>> Trying to do the same with the Sybase demo database works fine. >>> >>> I didn't try to do anything with the freeTDS driver yet. I will probably do that >>> over the weekend. >>> >>> Does anybody here have Sybase 16 installed? Did you try ODBC connection >>> to the server? >>> >>> Thank you. >>> >>> P.S.: Software versions: >>> 1> select @@version >>> 2> go >>> >>> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ >>> Adaptive Server Enterprise/16.0 SP02 PL02/EBF 25320 SMP/P/x86_64/Enterprise Lin >>> ux/ase160sp02plx/2492/64-bit/FBO/Sat Nov 21 04:05:39 2015 >>> >>> (1 row affected) >>> 1> exit >>> >>> [/code] >>> >>> [code] >>> >>> [ebuild U ] dev-db/unixODBC-2.3.5-r1::gentoo [2.3.2-r1::gentoo] >>> USE="minimal unicode -odbcmanual -static-libs" ABI_X86="32 (64) >>> (-x32)" 1,596 KiB >>> >>> [/code] >>> >>> The current version of unixODBC is 2.3.2-r1 from gentoo repository. >>> _______________________________________________ >>> FreeTDS mailing list >>> FreeTDS at lists.ibiblio.org >>> https://url.emailprotection.link/?a95lm_Yz0z4VwVi9HMyQSLtTmToR48n_2Es8x43dIoxidNPkdt4wWeUhbwN1QnbrzawQmZ1BjbOu5bK1zLGmRSw~~ >>> >>> _______________________________________________ >>> FreeTDS mailing list >>> FreeTDS at lists.ibiblio.org >>> https://url.emailprotection.link/?a95lm_Yz0z4VwVi9HMyQSLtTmToR48n_2Es8x43dIoxidNPkdt4wWeUhbwN1QnbrzawQmZ1BjbOu5bK1zLGmRSw~~ >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> https://url.emailprotection.link/?a95lm_Yz0z4VwVi9HMyQSLtTmToR48n_2Es8x43dIoxidNPkdt4wWeUhbwN1QnbrzawQmZ1BjbOu5bK1zLGmRSw~~ > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds