From rick.knowler at fidessa.com Mon Oct 3 14:52:04 2016 From: rick.knowler at fidessa.com (Rick Knowler) Date: Mon, 3 Oct 2016 18:52:04 +0000 Subject: [freetds] FreeTDS with read-only intent = yes on RHEL 6.6 Message-ID: Hi I'm trying to use FreeTDS to use read-only intent. I should be using the server UKWDC-RUATSDB2, but while using FreeTDS it only connects to UKWDC-RUATSDB1 which is the master server. I would like to know have I misconfigured something? Or is there a bug which is fixed in later versions? Or should this work and there is a setting missing in Microsoft SQL server? While using the Microsoft driver (https://msdn.microsoft.com/en-us/library/hh568449(v=sql.110).aspx) with odbc this works: #isql -v TDS ghood password +---------------------------------------+ | Connected! | | | | sql-statement | | help [tablename] | | quit | | | +---------------------------------------+ SQL> select @@SERVERNAME +--------------------------------------------------------------------------------------------- | +--------------------------------------------------------------------------------------------- | UKWDC-RUATSDB2 As you can see it's select server 2. When using FreeTDS and ODBC I get the following: #isql -v TDS ghood password +---------------------------------------+ | Connected! | | | | sql-statement | | help [tablename] | | quit | | | +---------------------------------------+ SQL> select @@SERVERNAME; +---------------------------------------------------------------------------------------------------------------------------------+ | | +---------------------------------------------------------------------------------------------------------------------------------+ | UKWDC-RUATSDB1 As you can see it's picked server 1, the primary. Here are my config files: freetds.conf [RemedyUAT] host = 192.168.113.83 port = 1433 tds version = 7.4 database = RemedyUAT read-only intent = yes dump file = /fidessa/fidmgr/ghoodcol/scripts/rickTDS.log odbc.ini: [TDS] Driver = TDS Servername = RemedyUAT TDS_Version = 7.4 ReadOnly = Yes ApplicationIntent = ReadOnly odbcinst.ini [TDS] Description = MsSQL connection Driver = /usr/lib64/libtdsodbc.so.0 I can see this config being picked up by running osql (it fails at the IP part, but if I enter in the hostname and configure DNS, it goes into isql with no further information): #osql -S TDS -U ghood -P password checking shared odbc libraries linked to isql for default directories... strings: '': No such file trying /tmp/sqlH ... no trying /tmp/sqlL ... no trying /etc ... OK checking odbc.ini files reading /opt/fidmgr/.odbc.ini [TDS] found in /opt/fidmgr/.odbc.ini found this section: [TDS] Driver = TDS Servername = RemedyUAT TDS_Version = 8.0 ReadOnly = Yes ApplicationIntent = ReadOnly looking for driver for DSN [TDS] in /opt/fidmgr/.odbc.ini found driver line: " Driver = TDS" driver "TDS" found for [TDS] in .odbc.ini found driver named "TDS" "TDS" is not an executable file looking for entry named [TDS] in /etc/odbcinst.ini found driver line: " Driver = /usr/lib64/libtdsodbc.so.0" found driver /usr/lib64/libtdsodbc.so.0 for [TDS] in odbcinst.ini /usr/lib64/libtdsodbc.so.0 is an executable file Using ODBC-Combined strategy DSN [TDS] has servername "RemedyUAT" (from /opt/fidmgr/.odbc.ini) /opt/fidmgr/.freetds.conf is a readable file looking for [RemedyUAT] in /opt/fidmgr/.freetds.conf found this section: [RemedyUAT] host = 192.168.113.83 port = 1433 tds version = 7.4 database = RemedyUAT read-only intent = yes dump file = /fidessa/fidmgr/ghoodcol/scripts/rickTDS.log looking up hostname for ip address 192.168.113.83 FreeTDS was installed from the repositry we have configure, here are the compile options: #tsql -C Compile-time settings (established with the "configure" script) Version: freetds v0.91 freetds.conf directory: /etc MS db-lib source compatibility: yes Sybase binary compatibility: yes Thread safety: yes iconv library: yes TDS version: 4.2 iODBC: no unixodbc: yes SSPI "trusted" logins: no Kerberos: yes I know I've pasted a lot of information here. If I've missed anything please let me know. Also I'm sorry if I've pasted too much. Thanks Rick Rick Knowler Production Services Fidessa | Tel: +1 (212)520 3465| Mob: +1 (917) 409-8507 | rick.knowler at fidessa.com [Description: Description: Description: Description: http://www.services.fidessa.com/banneradverts/email-signature-logos/Fidessa-Logo-Email-Signature-green.png] [http://www.services.fidessa.com/htmlemails/disclaimer/_images/us-20th-horz.jpg] This message is intended only for the stated addressee(s) and may be confidential. Access to this email by anyone else is unauthorized. Any opinions expressed in this email do not necessarily reflect the opinions of Fidessa. Any unauthorized disclosure, use or dissemination, either whole or in part is prohibited. If you are not the intended recipient of this message, please notify the sender immediately. This email does not form a contract and we do not represent that it is complete, accurate, uncorrupted or free of viruses and it should not be relied upon as such. -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 10103 bytes Desc: image001.png URL: From freddy77 at gmail.com Tue Oct 4 14:11:30 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Tue, 4 Oct 2016 19:11:30 +0100 Subject: [freetds] patch Message-ID: Frediano -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Convert-project-to-autoconf.patch Type: text/x-patch Size: 4638 bytes Desc: not available URL: From freddy77 at gmail.com Tue Oct 4 14:14:15 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Tue, 4 Oct 2016 19:14:15 +0100 Subject: [freetds] patch In-Reply-To: References: Message-ID: Sorry for the spam, wrong mail address. 2016-10-04 19:11 GMT+01:00 Frediano Ziglio : > Frediano From lastovica at sciinc.com Tue Oct 4 08:26:42 2016 From: lastovica at sciinc.com (Norm Lastovica) Date: Tue, 4 Oct 2016 12:26:42 +0000 Subject: [freetds] tds version = 7.1 causes dbbind to find for me Message-ID: OpenVMS IA64 V8.4. FREETDS-1_00_15. SQL Server 2014 - 12.0.4213.0. When tds version = 7.0, everything is good. But when I set to 7.1 or later, dbbind fails with (TDS Msg 20033, Level 7, "User attempted a dbbind with mismatched column and variable types"). My sequence code is approximately this: char tt[128] = {0}; strcpy (command_string, "SELECT SERVERPROPERTY ('productversion')"); EXECUTE_CHECK_ERC (dbcmd (dbproc, command_string), "dbcmd", (char*)command_string); EXECUTE_CHECK_ERC (dbsqlsend (dbproc), "dbsqlsend", (char*)command_string); EXECUTE_CHECK_ERC (dbsqlok (dbproc), "dbsqlok", (char*)command_string); while ((erc = dbresults (dbproc)) != NO_MORE_RESULTS) { CHECK_ERC ("dbresults", command_string); EXECUTE_CHECK_ERC (dbbind (dbproc, 1, NTBSTRINGBIND, sizeof(tt), (BYTE *) &tt), "dbbind", command_string); } Is tds version 7.1 something that should be expected to work? Norman Lastovica / SCI / +1.603.879.9022 x135 / www.sciinc.com From lastovica at sciinc.com Tue Oct 4 08:52:27 2016 From: lastovica at sciinc.com (Norm Lastovica) Date: Tue, 4 Oct 2016 12:52:27 +0000 Subject: [freetds] tds version = 7.1 causes dbbind to find for me Message-ID: After reviewing the TDS log file, I came to the conclusion that the issue was related to the size of the resultant buffer (tt in the example). It is 8000 or more with 7.1 and later as the version. I've increased this buffer size to 8192 and that seems to have addressed the problem. From: Norm Lastovica Sent: 2016-10-04, Tuesday 06:27 To: 'FreeTDS Development Group' Subject: tds version = 7.1 causes dbbind to find for me OpenVMS IA64 V8.4. FREETDS-1_00_15. SQL Server 2014 - 12.0.4213.0. When tds version = 7.0, everything is good. But when I set to 7.1 or later, dbbind fails with (TDS Msg 20033, Level 7, "User attempted a dbbind with mismatched column and variable types"). My sequence code is approximately this: char tt[128] = {0}; strcpy (command_string, "SELECT SERVERPROPERTY ('productversion')"); EXECUTE_CHECK_ERC (dbcmd (dbproc, command_string), "dbcmd", (char*)command_string); EXECUTE_CHECK_ERC (dbsqlsend (dbproc), "dbsqlsend", (char*)command_string); EXECUTE_CHECK_ERC (dbsqlok (dbproc), "dbsqlok", (char*)command_string); while ((erc = dbresults (dbproc)) != NO_MORE_RESULTS) { CHECK_ERC ("dbresults", command_string); EXECUTE_CHECK_ERC (dbbind (dbproc, 1, NTBSTRINGBIND, sizeof(tt), (BYTE *) &tt), "dbbind", command_string); } Is tds version 7.1 something that should be expected to work? Norman Lastovica / SCI / +1.603.879.9022 x135 / www.sciinc.com From pascal29.moreau at gmail.com Mon Oct 10 06:45:22 2016 From: pascal29.moreau at gmail.com (Pascal Moreau) Date: Mon, 10 Oct 2016 12:45:22 +0200 Subject: [freetds] Troubles with charset ISO-8859-1 / UTF-8 Message-ID: Hello, I try to access SYBASE database from a PostgreSQL database by using FreeTDS and tds_fdw (foreign tables) but I have troubles with charset in output of Freetds. The trouble is that I can't see in output of FreeTDS the french character with accent like ?,?,? so in PostgreSQL the cells with this characters alphabet (?,?,?...) are incomplete in the foreign tables. I have try many change in FreeTDS but it's always the same thing, I have try freetds-0.95.95 and freetds-1.00.15, I have try with ./configure --disable-libiconv or not, I have change freetds.conf and locale.conf options with ISO-8859-1, LATIN1 and UTF-8 but it's always the same result. My configuration is: SYBASE 15.7 / Character set: ISO-8859-1 (LATIN-1) / Language: french PostgreSQL 9.4.4 / Encoding: UTF8 / LC_COLLATE & LC_TYPE: fr_FR.UTF8 freetds.conf: [global] dump file = /tmp/freetds.log debug flags = 0xffff text size = 64512 [SYBDEV1] host = SYBDEV1 port = 8025 tds version = 5.0 client charset = UTF-8 locale.conf: [default] date format = %d/%m/%Y %H:%M language = French charset = iso_1 And here is what I can see in the freetds.log ... 11:54:06.816788 24919 (config.c:298):Found conf file '/usr/local/etc/freetds.conf' (default). 11:54:06.816793 24919 (config.c:506):Looking for section global. 11:54:06.816803 24919 (config.c:565): Found section global. 11:54:06.816808 24919 (config.c:568):Got a match. 11:54:06.816813 24919 (config.c:591): dump file = '/tmp/freetds.log' 11:54:06.816817 24919 (config.c:591): debug flags = '0xffff' 11:54:06.816822 24919 (config.c:591): text size = '64512' 11:54:06.816827 24919 (config.c:565): Found section sybdev1. 11:54:06.816832 24919 (config.c:579): Reached EOF 11:54:06.816836 24919 (config.c:506):Looking for section SYBDEV1. 11:54:06.816842 24919 (config.c:565): Found section global. 11:54:06.816846 24919 (config.c:565): Found section sybdev1. 11:54:06.816855 24919 (config.c:568):Got a match. 11:54:06.816860 24919 (config.c:591): host = 'SYBDEV1' 11:54:06.817592 24919 (config.c:628):Found host entry SYBDEV1 11:54:06.817616 24919 (config.c:631):IP addr is 172.20.13.176. 11:54:06.817622 24919 (config.c:591): port = '8025' 11:54:06.817627 24919 (config.c:591): tds version = '5.0' 11:54:06.817631 24919 (config.c:915):Setting tds version to 5.0 (0x500). 11:54:06.817636 24919 (config.c:591): client charset = 'UTF-8' 11:54:06.817640 24919 (config.c:646):tds_parse_conf_section: client charset is UTF-8. 11:54:06.817646 24919 (config.c:579): Reached EOF 11:54:06.817650 24919 (config.c:302):Success: [SYBDEV1] defined in /usr/local/etc/freetds.conf. 11:54:06.817667 24919 (config.c:714):tds_config_login: database_name is eldro_encours. 11:54:06.817675 24919 (dblib.c:1256):tdsdbopen: Calling tds_connect_and_login(0x16c1130, 0x161b240) 11:54:06.817686 24919 (iconv.c:325):tds_iconv_open(0x16c1130, UTF-8) 11:54:06.817690 24919 (iconv.c:343):setting up conversions for client charset "UTF-8" 11:54:06.817694 24919 (iconv.c:345):preparing iconv for "UTF-8" <-> "UCS-2LE" conversion 11:54:06.817707 24919 (iconv.c:384):tds_iconv_open: done 11:54:06.817721 24919 (net.c:216):Connecting to 172.20.13.176 port 8025 (TDS version 5.0) 11:54:06.817850 24919 (net.c:242):tds_open_socket: connect(2) returned "Operation now in progress" 11:54:06.818557 24919 (net.c:343):tds_open_socket() succeeded ... 11:54:06.827003 24919 (token.c:306):looking for login token, got e3(ENVCHANGE) 11:54:06.827011 24919 (token.c:125):tds_process_default_tokens() marker is e3(ENVCHANGE) 11:54:06.827021 24919 (dblib.c:310):db_env_chg(0x16c1130, 1, master, tempdb) 11:54:06.827027 24919 (token.c:306):looking for login token, got e5(EED) 11:54:06.827032 24919 (token.c:125):tds_process_default_tokens() marker is e5(EED) 11:54:06.827037 24919 (token.c:2328):tds_process_info() reading message 5701 from server 11:54:06.827043 24919 (token.c:2400):tds_process_info() calling client msg handler 11:54:06.827047 24919 (dbutil.c:74):_dblib_handle_info_message(0x16c0b60, 0x16c1130, 0x7fffb4df4ff0) 11:54:06.827052 24919 (dbutil.c:75):msgno 5701: "Le contexte de la base de donn?es a ?t? chang? en 'tempdb'. " 11:54:06.827057 24919 (token.c:2417):tds_process_info() returning TDS_SUCCESS 11:54:06.827060 24919 (token.c:306):looking for login token, got e3(ENVCHANGE) 11:54:06.827064 24919 (token.c:125):tds_process_default_tokens() marker is e3(ENVCHANGE) 11:54:06.827069 24919 (token.c:2220):changing block size from to 2048 11:54:06.827075 24919 (dblib.c:310):db_env_chg(0x16c1130, 4, , 2048) 11:54:06.827079 24919 (token.c:306):looking for login token, got ad(LOGINACK) 11:54:06.827084 24919 (token.c:344):server reports TDS version 5.0.0.0 11:54:06.827088 24919 (token.c:346):Product name for 0x5000000 is unknown 11:54:06.827093 24919 (token.c:378):Product version F070000 11:54:06.827098 24919 (token.c:306):looking for login token, got e2(CAPABILITY) 11:54:06.827101 24919 (token.c:125):tds_process_default_tokens() marker is e2(CAPABILITY) 11:54:06.827106 24919 (token.c:306):looking for login token, got fd(DONE) 11:54:06.827109 24919 (token.c:125):tds_process_default_tokens() marker is fd(DONE) 11:54:06.827114 24919 (token.c:2065):tds_process_end: more_results = 0 was_cancelled = 0 error = 0 done_count_valid = 0 11:54:06.827118 24919 (token.c:2082): rows_affected = 70 11:54:06.827122 24919 (token.c:2085):tds_process_end() state set to TDS_IDLE ... 11:54:06.828755 24919 (token.c:525):tds_process_tokens(0x16c1130, 0x7fffb4df555c, 0x7fffb4df5558, 0x6914) 11:54:06.828760 24919 (util.c:165):Changed query state from PENDING to READING 11:54:06.831974 24919 (packet.c:639):Received packet 0000 04 00 08 00 00 00 00 00-61 40 01 00 00 06 00 00 |........ a at ......| 0010 0d 65 6c 64 72 6f 5f 65-6e 63 6f 75 72 73 03 64 |.eldro_e ncours.d| 0020 62 6f 07 63 5f 63 6f 6e-67 65 0b 63 63 6f 6e 67 |bo.c_con ge.ccong| 0030 65 5f 63 6f 64 65 10 00-00 00 01 00 00 00 2f 05 |e_code.. ....../.| 0040 00 00 0d 65 6c 64 72 6f-5f 65 6e 63 6f 75 72 73 |...eldro _encours| 0050 03 64 62 6f 07 63 5f 63-6f 6e 67 65 0b 63 63 6f |.dbo.c_c onge.cco| 0060 6e 67 65 5f 72 65 67 72-30 00 00 00 01 00 00 00 |nge_regr 0.......| 0070 27 05 00 00 0d 65 6c 64-72 6f 5f 65 6e 63 6f 75 |'....eld ro_encou| 0080 72 73 03 64 62 6f 07 63-5f 63 6f 6e 67 65 0c 63 |rs.dbo.c _conge.c| 0090 63 6f 6e 67 65 5f 6c 69-62 65 6c 30 00 00 00 02 |conge_li bel0....| 00a0 00 00 00 27 fa 00 00 0d-65 6c 64 72 6f 5f 65 6e |...'.... eldro_en| 00b0 63 6f 75 72 73 03 64 62-6f 07 63 5f 63 6f 6e 67 |cours.db o.c_cong| 00c0 65 11 63 63 6f 6e 67 65-5f 64 61 74 65 5f 64 65 |e.cconge _date_de| 00d0 62 75 74 30 00 00 00 25-00 00 00 7b 04 00 00 0d |but0...% ...{....| 00e0 65 6c 64 72 6f 5f 65 6e-63 6f 75 72 73 03 64 62 |eldro_en cours.db| 00f0 6f 07 63 5f 63 6f 6e 67-65 0f 63 63 6f 6e 67 65 |o.c_cong e.cconge| 0100 5f 64 61 74 65 5f 66 69-6e 30 00 00 00 25 00 00 |_date_fi n0...%..| 0110 00 7b 04 00 00 0d 65 6c-64 72 6f 5f 65 6e 63 6f |.{....el dro_enco| 0120 75 72 73 03 64 62 6f 07-63 5f 63 6f 6e 67 65 12 |urs.dbo. c_conge.| 0130 63 63 6f 6e 67 65 5f 6c-69 62 65 6c 5f 63 6f 75 |cconge_l ibel_cou| 0140 72 74 30 00 00 00 02 00-00 00 27 19 00 ae 06 00 |rt0..... ..'.....| 0150 00 00 00 00 00 00 d1 05-43 41 31 30 30 05 43 41 |........ CA100.CA| 0160 31 30 30 33 41 62 73 65-6e 63 65 20 70 6f 75 72 |1003Abse nce pour| 0170 20 63 65 73 73 61 74 69-6f 6e 20 63 6f 6e 63 65 | cessati on conce| 0180 72 74 e9 65 20 64 65 20-74 72 61 76 61 69 6c 20 |rt.e de travail | 0190 28 67 72 e8 76 65 29 04-00 00 00 00 04 66 21 06 |(gr.ve). .....f!.| 01a0 00 05 47 72 e8 76 65 d1-05 43 41 34 30 30 05 43 |..Gr.ve. .CA400.C| 01b0 41 34 30 30 13 41 62 73-65 6e 63 65 20 69 72 72 |A400.Abs ence irr| 01c0 e9 67 75 6c 69 e8 72 65-04 00 00 00 00 04 66 21 |.guli.re ......f!| ... On ligne 0180 I should see "|rt?e de travail |" and on ligne 0190 It should be "|(gr?ve). .....f!.|" Then when I try to see the result in my databse on PostgreSQL I have the following result where "gr?ve" is became "grve": [postgres at INST01] estim=# select * from eldroec_c_conge where cconge_code ='CA100'; cconge_code | cconge_regr | cconge_libel | cconge_date_debut | cconge_date_fin | cconge_libel_court -------------+-------------+---------------------------------------------------+-------------------+-----------------+-------------------- CA100 | CA100 | Absence pour cessation concerte de travail (grve) | 1900-01-01 | 2999-12-31 | Grve (1 ligne) Temps : 139,166 ms Can someome help me please ? Thanks. From freddy77 at gmail.com Mon Oct 10 09:45:14 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Mon, 10 Oct 2016 14:45:14 +0100 Subject: [freetds] Troubles with charset ISO-8859-1 / UTF-8 In-Reply-To: References: Message-ID: 2016-10-10 11:45 GMT+01:00 Pascal Moreau : > Hello, > > I try to access SYBASE database from a PostgreSQL database by using FreeTDS > and tds_fdw (foreign tables) but I have troubles with charset in output of > Freetds. > > The trouble is that I can't see in output of FreeTDS the french character > with accent like ?,?,? so in PostgreSQL the cells with this characters > alphabet (?,?,?...) are incomplete in the foreign tables. > Quite hard to say. It would be worth knowing how tds_fdw is supposed to address encoding. Looking at the logs below looks like they are using dblib so I would expect them to assume utf-8 to support more encodings as possible. > I have try many change in FreeTDS but it's always the same thing, I have > try freetds-0.95.95 and freetds-1.00.15, I have try with ./configure > --disable-libiconv or not, I have change freetds.conf and locale.conf > options with ISO-8859-1, LATIN1 and UTF-8 but it's always the same result. > I would try to force utf-8. > My configuration is: > SYBASE 15.7 / Character set: ISO-8859-1 (LATIN-1) / Language: french > PostgreSQL 9.4.4 / Encoding: UTF8 / LC_COLLATE & LC_TYPE: fr_FR.UTF8 > > freetds.conf: > [global] > dump file = /tmp/freetds.log > debug flags = 0xffff > text size = 64512 > [SYBDEV1] > host = SYBDEV1 > port = 8025 > tds version = 5.0 > client charset = UTF-8 > > > locale.conf: > [default] > date format = %d/%m/%Y %H:%M > language = French > charset = iso_1 > > > And here is what I can see in the freetds.log > > ... > 11:54:06.816788 24919 (config.c:298):Found conf file > '/usr/local/etc/freetds.conf' (default). > 11:54:06.816793 24919 (config.c:506):Looking for section global. > 11:54:06.816803 24919 (config.c:565): Found section global. > 11:54:06.816808 24919 (config.c:568):Got a match. > 11:54:06.816813 24919 (config.c:591): dump file = '/tmp/freetds.log' > 11:54:06.816817 24919 (config.c:591): debug flags = '0xffff' > 11:54:06.816822 24919 (config.c:591): text size = '64512' > 11:54:06.816827 24919 (config.c:565): Found section sybdev1. > 11:54:06.816832 24919 (config.c:579): Reached EOF > 11:54:06.816836 24919 (config.c:506):Looking for section SYBDEV1. > 11:54:06.816842 24919 (config.c:565): Found section global. > 11:54:06.816846 24919 (config.c:565): Found section sybdev1. > 11:54:06.816855 24919 (config.c:568):Got a match. > 11:54:06.816860 24919 (config.c:591): host = 'SYBDEV1' > 11:54:06.817592 24919 (config.c:628):Found host entry SYBDEV1 > 11:54:06.817616 24919 (config.c:631):IP addr is 172.20.13.176. > 11:54:06.817622 24919 (config.c:591): port = '8025' > 11:54:06.817627 24919 (config.c:591): tds version = '5.0' > 11:54:06.817631 24919 (config.c:915):Setting tds version to 5.0 (0x500). > 11:54:06.817636 24919 (config.c:591): client charset = 'UTF-8' > 11:54:06.817640 24919 (config.c:646):tds_parse_conf_section: client charset > is UTF-8. > 11:54:06.817646 24919 (config.c:579): Reached EOF > 11:54:06.817650 24919 (config.c:302):Success: [SYBDEV1] defined in > /usr/local/etc/freetds.conf. > 11:54:06.817667 24919 (config.c:714):tds_config_login: database_name is > eldro_encours. > 11:54:06.817675 24919 (dblib.c:1256):tdsdbopen: Calling > tds_connect_and_login(0x16c1130, 0x161b240) > 11:54:06.817686 24919 (iconv.c:325):tds_iconv_open(0x16c1130, UTF-8) > 11:54:06.817690 24919 (iconv.c:343):setting up conversions for client > charset "UTF-8" > 11:54:06.817694 24919 (iconv.c:345):preparing iconv for "UTF-8" <-> > "UCS-2LE" conversion > 11:54:06.817707 24919 (iconv.c:384):tds_iconv_open: done > 11:54:06.817721 24919 (net.c:216):Connecting to 172.20.13.176 port 8025 > (TDS version 5.0) > 11:54:06.817850 24919 (net.c:242):tds_open_socket: connect(2) returned > "Operation now in progress" > 11:54:06.818557 24919 (net.c:343):tds_open_socket() succeeded > ... > 11:54:06.827003 24919 (token.c:306):looking for login token, got > e3(ENVCHANGE) > 11:54:06.827011 24919 (token.c:125):tds_process_default_tokens() marker is > e3(ENVCHANGE) > 11:54:06.827021 24919 (dblib.c:310):db_env_chg(0x16c1130, 1, master, tempdb) > 11:54:06.827027 24919 (token.c:306):looking for login token, got e5(EED) > 11:54:06.827032 24919 (token.c:125):tds_process_default_tokens() marker is > e5(EED) > 11:54:06.827037 24919 (token.c:2328):tds_process_info() reading message > 5701 from server > 11:54:06.827043 24919 (token.c:2400):tds_process_info() calling client msg > handler > 11:54:06.827047 24919 (dbutil.c:74):_dblib_handle_info_message(0x16c0b60, > 0x16c1130, 0x7fffb4df4ff0) > 11:54:06.827052 24919 (dbutil.c:75):msgno 5701: "Le contexte de la base de > donn?es a ?t? chang? en 'tempdb'. > " > 11:54:06.827057 24919 (token.c:2417):tds_process_info() returning > TDS_SUCCESS > 11:54:06.827060 24919 (token.c:306):looking for login token, got > e3(ENVCHANGE) > 11:54:06.827064 24919 (token.c:125):tds_process_default_tokens() marker is > e3(ENVCHANGE) > 11:54:06.827069 24919 (token.c:2220):changing block size from to 2048 > 11:54:06.827075 24919 (dblib.c:310):db_env_chg(0x16c1130, 4, , 2048) > 11:54:06.827079 24919 (token.c:306):looking for login token, got > ad(LOGINACK) > 11:54:06.827084 24919 (token.c:344):server reports TDS version 5.0.0.0 > 11:54:06.827088 24919 (token.c:346):Product name for 0x5000000 is unknown > 11:54:06.827093 24919 (token.c:378):Product version F070000 > 11:54:06.827098 24919 (token.c:306):looking for login token, got > e2(CAPABILITY) > 11:54:06.827101 24919 (token.c:125):tds_process_default_tokens() marker is > e2(CAPABILITY) > 11:54:06.827106 24919 (token.c:306):looking for login token, got fd(DONE) > 11:54:06.827109 24919 (token.c:125):tds_process_default_tokens() marker is > fd(DONE) > 11:54:06.827114 24919 (token.c:2065):tds_process_end: more_results = 0 > was_cancelled = 0 > error = 0 > done_count_valid = 0 > 11:54:06.827118 24919 (token.c:2082): rows_affected = 70 > 11:54:06.827122 24919 (token.c:2085):tds_process_end() state set to TDS_IDLE > ... > 11:54:06.828755 24919 (token.c:525):tds_process_tokens(0x16c1130, > 0x7fffb4df555c, 0x7fffb4df5558, 0x6914) > 11:54:06.828760 24919 (util.c:165):Changed query state from PENDING to > READING > 11:54:06.831974 24919 (packet.c:639):Received packet > 0000 04 00 08 00 00 00 00 00-61 40 01 00 00 06 00 00 |........ a at ......| > 0010 0d 65 6c 64 72 6f 5f 65-6e 63 6f 75 72 73 03 64 |.eldro_e ncours.d| > 0020 62 6f 07 63 5f 63 6f 6e-67 65 0b 63 63 6f 6e 67 |bo.c_con ge.ccong| > 0030 65 5f 63 6f 64 65 10 00-00 00 01 00 00 00 2f 05 |e_code.. ....../.| > 0040 00 00 0d 65 6c 64 72 6f-5f 65 6e 63 6f 75 72 73 |...eldro _encours| > 0050 03 64 62 6f 07 63 5f 63-6f 6e 67 65 0b 63 63 6f |.dbo.c_c onge.cco| > 0060 6e 67 65 5f 72 65 67 72-30 00 00 00 01 00 00 00 |nge_regr 0.......| > 0070 27 05 00 00 0d 65 6c 64-72 6f 5f 65 6e 63 6f 75 |'....eld ro_encou| > 0080 72 73 03 64 62 6f 07 63-5f 63 6f 6e 67 65 0c 63 |rs.dbo.c _conge.c| > 0090 63 6f 6e 67 65 5f 6c 69-62 65 6c 30 00 00 00 02 |conge_li bel0....| > 00a0 00 00 00 27 fa 00 00 0d-65 6c 64 72 6f 5f 65 6e |...'.... eldro_en| > 00b0 63 6f 75 72 73 03 64 62-6f 07 63 5f 63 6f 6e 67 |cours.db o.c_cong| > 00c0 65 11 63 63 6f 6e 67 65-5f 64 61 74 65 5f 64 65 |e.cconge _date_de| > 00d0 62 75 74 30 00 00 00 25-00 00 00 7b 04 00 00 0d |but0...% ...{....| > 00e0 65 6c 64 72 6f 5f 65 6e-63 6f 75 72 73 03 64 62 |eldro_en cours.db| > 00f0 6f 07 63 5f 63 6f 6e 67-65 0f 63 63 6f 6e 67 65 |o.c_cong e.cconge| > 0100 5f 64 61 74 65 5f 66 69-6e 30 00 00 00 25 00 00 |_date_fi n0...%..| > 0110 00 7b 04 00 00 0d 65 6c-64 72 6f 5f 65 6e 63 6f |.{....el dro_enco| > 0120 75 72 73 03 64 62 6f 07-63 5f 63 6f 6e 67 65 12 |urs.dbo. c_conge.| > 0130 63 63 6f 6e 67 65 5f 6c-69 62 65 6c 5f 63 6f 75 |cconge_l ibel_cou| > 0140 72 74 30 00 00 00 02 00-00 00 27 19 00 ae 06 00 |rt0..... ..'.....| > 0150 00 00 00 00 00 00 d1 05-43 41 31 30 30 05 43 41 |........ CA100.CA| > 0160 31 30 30 33 41 62 73 65-6e 63 65 20 70 6f 75 72 |1003Abse nce pour| > 0170 20 63 65 73 73 61 74 69-6f 6e 20 63 6f 6e 63 65 | cessati on conce| > 0180 72 74 e9 65 20 64 65 20-74 72 61 76 61 69 6c 20 |rt.e de travail | > 0190 28 67 72 e8 76 65 29 04-00 00 00 00 04 66 21 06 |(gr.ve). .....f!.| > 01a0 00 05 47 72 e8 76 65 d1-05 43 41 34 30 30 05 43 |..Gr.ve. .CA400.C| > 01b0 41 34 30 30 13 41 62 73-65 6e 63 65 20 69 72 72 |A400.Abs ence irr| > 01c0 e9 67 75 6c 69 e8 72 65-04 00 00 00 00 04 66 21 |.guli.re ......f!| > ... > > > > On ligne 0180 I should see "|rt?e de travail |" and on ligne 0190 It > should be "|(gr?ve). .....f!.|" This is a binary dump, is not expected to support other than ASCII but you can see that the column from the server is encoded with single character. Looking at https://it.wikipedia.org/wiki/ISO/IEC_8859-1 the encoding is fine. > > Then when I try to see the result in my databse on PostgreSQL I have the > following result where "gr?ve" is became "grve": > > [postgres at INST01] estim=# select * from eldroec_c_conge where cconge_code > ='CA100'; > cconge_code | cconge_regr | > cconge_libel | cconge_date_debut | cconge_date_fin | > cconge_libel_court > -------------+-------------+---------------------------------------------------+-------------------+-----------------+-------------------- > CA100 | CA100 | Absence pour cessation concerte de travail > (grve) | 1900-01-01 | 2999-12-31 | Grve > (1 ligne) > > Temps : 139,166 ms > > > Can someome help me please ? > > Thanks. >From the log (which is partial without queries) everything is fine. Up to tds_fdw. Frediano From fredy at opag.ch Mon Oct 10 10:54:10 2016 From: fredy at opag.ch (Fredy Paquet) Date: Mon, 10 Oct 2016 16:54:10 +0200 Subject: [freetds] Troubles with charset ISO-8859-1 / UTF-8 In-Reply-To: References: Message-ID: <1476111250.13113.87.camel@montesa> We're using FreeTDS 0.91 since many years now with Sybase store configured to ISO-8859-1 and Client using utf-8. Our OPG Client is running on Linux and Windows. Conversion is absolutely no problem there. -- Fredy Paquet Mitglied der Gesch?ftsleitung OPAG Informatik AG Fabrikmattenweg 11 CH-4144 Arlesheim http://www.opag.ch Tel. ++41 61 716 92 22 Fax. ++41 61 716 92 29 On Mon, 2016-10-10 at 14:45 +0100, Frediano Ziglio wrote: > 2016-10-10 11:45 GMT+01:00 Pascal Moreau : > > Hello, > > > > I try to access SYBASE database from a PostgreSQL database by using FreeTDS > > and tds_fdw (foreign tables) but I have troubles with charset in output of > > Freetds. > > > > The trouble is that I can't see in output of FreeTDS the french character > > with accent like ?,?,? so in PostgreSQL the cells with this characters > > alphabet (?,?,?...) are incomplete in the foreign tables. > > > > Quite hard to say. It would be worth knowing how tds_fdw is supposed to address > encoding. Looking at the logs below looks like they are using dblib so I would > expect them to assume utf-8 to support more encodings as possible. > > > I have try many change in FreeTDS but it's always the same thing, I have > > try freetds-0.95.95 and freetds-1.00.15, I have try with ./configure > > --disable-libiconv or not, I have change freetds.conf and locale.conf > > options with ISO-8859-1, LATIN1 and UTF-8 but it's always the same result. > > > > I would try to force utf-8. > > > My configuration is: > > SYBASE 15.7 / Character set: ISO-8859-1 (LATIN-1) / Language: french > > PostgreSQL 9.4.4 / Encoding: UTF8 / LC_COLLATE & LC_TYPE: fr_FR.UTF8 > > > > freetds.conf: > > [global] > > dump file = /tmp/freetds.log > > debug flags = 0xffff > > text size = 64512 > > [SYBDEV1] > > host = SYBDEV1 > > port = 8025 > > tds version = 5.0 > > client charset = UTF-8 > > > > > > locale.conf: > > [default] > > date format = %d/%m/%Y %H:%M > > language = French > > charset = iso_1 > > > > > > And here is what I can see in the freetds.log > > > > ... > > 11:54:06.816788 24919 (config.c:298):Found conf file > > '/usr/local/etc/freetds.conf' (default). > > 11:54:06.816793 24919 (config.c:506):Looking for section global. > > 11:54:06.816803 24919 (config.c:565): Found section global. > > 11:54:06.816808 24919 (config.c:568):Got a match. > > 11:54:06.816813 24919 (config.c:591): dump file = '/tmp/freetds.log' > > 11:54:06.816817 24919 (config.c:591): debug flags = '0xffff' > > 11:54:06.816822 24919 (config.c:591): text size = '64512' > > 11:54:06.816827 24919 (config.c:565): Found section sybdev1. > > 11:54:06.816832 24919 (config.c:579): Reached EOF > > 11:54:06.816836 24919 (config.c:506):Looking for section SYBDEV1. > > 11:54:06.816842 24919 (config.c:565): Found section global. > > 11:54:06.816846 24919 (config.c:565): Found section sybdev1. > > 11:54:06.816855 24919 (config.c:568):Got a match. > > 11:54:06.816860 24919 (config.c:591): host = 'SYBDEV1' > > 11:54:06.817592 24919 (config.c:628):Found host entry SYBDEV1 > > 11:54:06.817616 24919 (config.c:631):IP addr is 172.20.13.176. > > 11:54:06.817622 24919 (config.c:591): port = '8025' > > 11:54:06.817627 24919 (config.c:591): tds version = '5.0' > > 11:54:06.817631 24919 (config.c:915):Setting tds version to 5.0 (0x500). > > 11:54:06.817636 24919 (config.c:591): client charset = 'UTF-8' > > 11:54:06.817640 24919 (config.c:646):tds_parse_conf_section: client charset > > is UTF-8. > > 11:54:06.817646 24919 (config.c:579): Reached EOF > > 11:54:06.817650 24919 (config.c:302):Success: [SYBDEV1] defined in > > /usr/local/etc/freetds.conf. > > 11:54:06.817667 24919 (config.c:714):tds_config_login: database_name is > > eldro_encours. > > 11:54:06.817675 24919 (dblib.c:1256):tdsdbopen: Calling > > tds_connect_and_login(0x16c1130, 0x161b240) > > 11:54:06.817686 24919 (iconv.c:325):tds_iconv_open(0x16c1130, UTF-8) > > 11:54:06.817690 24919 (iconv.c:343):setting up conversions for client > > charset "UTF-8" > > 11:54:06.817694 24919 (iconv.c:345):preparing iconv for "UTF-8" <-> > > "UCS-2LE" conversion > > 11:54:06.817707 24919 (iconv.c:384):tds_iconv_open: done > > 11:54:06.817721 24919 (net.c:216):Connecting to 172.20.13.176 port 8025 > > (TDS version 5.0) > > 11:54:06.817850 24919 (net.c:242):tds_open_socket: connect(2) returned > > "Operation now in progress" > > 11:54:06.818557 24919 (net.c:343):tds_open_socket() succeeded > > ... > > 11:54:06.827003 24919 (token.c:306):looking for login token, got > > e3(ENVCHANGE) > > 11:54:06.827011 24919 (token.c:125):tds_process_default_tokens() marker is > > e3(ENVCHANGE) > > 11:54:06.827021 24919 (dblib.c:310):db_env_chg(0x16c1130, 1, master, tempdb) > > 11:54:06.827027 24919 (token.c:306):looking for login token, got e5(EED) > > 11:54:06.827032 24919 (token.c:125):tds_process_default_tokens() marker is > > e5(EED) > > 11:54:06.827037 24919 (token.c:2328):tds_process_info() reading message > > 5701 from server > > 11:54:06.827043 24919 (token.c:2400):tds_process_info() calling client msg > > handler > > 11:54:06.827047 24919 (dbutil.c:74):_dblib_handle_info_message(0x16c0b60, > > 0x16c1130, 0x7fffb4df4ff0) > > 11:54:06.827052 24919 (dbutil.c:75):msgno 5701: "Le contexte de la base de > > donn?es a ?t? chang? en 'tempdb'. > > " > > 11:54:06.827057 24919 (token.c:2417):tds_process_info() returning > > TDS_SUCCESS > > 11:54:06.827060 24919 (token.c:306):looking for login token, got > > e3(ENVCHANGE) > > 11:54:06.827064 24919 (token.c:125):tds_process_default_tokens() marker is > > e3(ENVCHANGE) > > 11:54:06.827069 24919 (token.c:2220):changing block size from to 2048 > > 11:54:06.827075 24919 (dblib.c:310):db_env_chg(0x16c1130, 4, , 2048) > > 11:54:06.827079 24919 (token.c:306):looking for login token, got > > ad(LOGINACK) > > 11:54:06.827084 24919 (token.c:344):server reports TDS version 5.0.0.0 > > 11:54:06.827088 24919 (token.c:346):Product name for 0x5000000 is unknown > > 11:54:06.827093 24919 (token.c:378):Product version F070000 > > 11:54:06.827098 24919 (token.c:306):looking for login token, got > > e2(CAPABILITY) > > 11:54:06.827101 24919 (token.c:125):tds_process_default_tokens() marker is > > e2(CAPABILITY) > > 11:54:06.827106 24919 (token.c:306):looking for login token, got fd(DONE) > > 11:54:06.827109 24919 (token.c:125):tds_process_default_tokens() marker is > > fd(DONE) > > 11:54:06.827114 24919 (token.c:2065):tds_process_end: more_results = 0 > > was_cancelled = 0 > > error = 0 > > done_count_valid = 0 > > 11:54:06.827118 24919 (token.c:2082): rows_affected = 70 > > 11:54:06.827122 24919 (token.c:2085):tds_process_end() state set to TDS_IDLE > > ... > > 11:54:06.828755 24919 (token.c:525):tds_process_tokens(0x16c1130, > > 0x7fffb4df555c, 0x7fffb4df5558, 0x6914) > > 11:54:06.828760 24919 (util.c:165):Changed query state from PENDING to > > READING > > 11:54:06.831974 24919 (packet.c:639):Received packet > > 0000 04 00 08 00 00 00 00 00-61 40 01 00 00 06 00 00 |........ a at ......| > > 0010 0d 65 6c 64 72 6f 5f 65-6e 63 6f 75 72 73 03 64 |.eldro_e ncours.d| > > 0020 62 6f 07 63 5f 63 6f 6e-67 65 0b 63 63 6f 6e 67 |bo.c_con ge.ccong| > > 0030 65 5f 63 6f 64 65 10 00-00 00 01 00 00 00 2f 05 |e_code.. ....../.| > > 0040 00 00 0d 65 6c 64 72 6f-5f 65 6e 63 6f 75 72 73 |...eldro _encours| > > 0050 03 64 62 6f 07 63 5f 63-6f 6e 67 65 0b 63 63 6f |.dbo.c_c onge.cco| > > 0060 6e 67 65 5f 72 65 67 72-30 00 00 00 01 00 00 00 |nge_regr 0.......| > > 0070 27 05 00 00 0d 65 6c 64-72 6f 5f 65 6e 63 6f 75 |'....eld ro_encou| > > 0080 72 73 03 64 62 6f 07 63-5f 63 6f 6e 67 65 0c 63 |rs.dbo.c _conge.c| > > 0090 63 6f 6e 67 65 5f 6c 69-62 65 6c 30 00 00 00 02 |conge_li bel0....| > > 00a0 00 00 00 27 fa 00 00 0d-65 6c 64 72 6f 5f 65 6e |...'.... eldro_en| > > 00b0 63 6f 75 72 73 03 64 62-6f 07 63 5f 63 6f 6e 67 |cours.db o.c_cong| > > 00c0 65 11 63 63 6f 6e 67 65-5f 64 61 74 65 5f 64 65 |e.cconge _date_de| > > 00d0 62 75 74 30 00 00 00 25-00 00 00 7b 04 00 00 0d |but0...% ...{....| > > 00e0 65 6c 64 72 6f 5f 65 6e-63 6f 75 72 73 03 64 62 |eldro_en cours.db| > > 00f0 6f 07 63 5f 63 6f 6e 67-65 0f 63 63 6f 6e 67 65 |o.c_cong e.cconge| > > 0100 5f 64 61 74 65 5f 66 69-6e 30 00 00 00 25 00 00 |_date_fi n0...%..| > > 0110 00 7b 04 00 00 0d 65 6c-64 72 6f 5f 65 6e 63 6f |.{....el dro_enco| > > 0120 75 72 73 03 64 62 6f 07-63 5f 63 6f 6e 67 65 12 |urs.dbo. c_conge.| > > 0130 63 63 6f 6e 67 65 5f 6c-69 62 65 6c 5f 63 6f 75 |cconge_l ibel_cou| > > 0140 72 74 30 00 00 00 02 00-00 00 27 19 00 ae 06 00 |rt0..... ..'.....| > > 0150 00 00 00 00 00 00 d1 05-43 41 31 30 30 05 43 41 |........ CA100.CA| > > 0160 31 30 30 33 41 62 73 65-6e 63 65 20 70 6f 75 72 |1003Abse nce pour| > > 0170 20 63 65 73 73 61 74 69-6f 6e 20 63 6f 6e 63 65 | cessati on conce| > > 0180 72 74 e9 65 20 64 65 20-74 72 61 76 61 69 6c 20 |rt.e de travail | > > 0190 28 67 72 e8 76 65 29 04-00 00 00 00 04 66 21 06 |(gr.ve). .....f!.| > > 01a0 00 05 47 72 e8 76 65 d1-05 43 41 34 30 30 05 43 |..Gr.ve. .CA400.C| > > 01b0 41 34 30 30 13 41 62 73-65 6e 63 65 20 69 72 72 |A400.Abs ence irr| > > 01c0 e9 67 75 6c 69 e8 72 65-04 00 00 00 00 04 66 21 |.guli.re ......f!| > > ... > > > > > > > > On ligne 0180 I should see "|rt?e de travail |" and on ligne 0190 It > > should be "|(gr?ve). .....f!.|" > > This is a binary dump, is not expected to support other than ASCII but > you can see that the column from the server is encoded with single > character. Looking at https://it.wikipedia.org/wiki/ISO/IEC_8859-1 the > encoding is fine. > > > > > Then when I try to see the result in my databse on PostgreSQL I have the > > following result where "gr?ve" is became "grve": > > > > [postgres at INST01] estim=# select * from eldroec_c_conge where cconge_code > > ='CA100'; > > cconge_code | cconge_regr | > > cconge_libel | cconge_date_debut | cconge_date_fin | > > cconge_libel_court > > -------------+-------------+---------------------------------------------------+-------------------+-----------------+-------------------- > > CA100 | CA100 | Absence pour cessation concerte de travail > > (grve) | 1900-01-01 | 2999-12-31 | Grve > > (1 ligne) > > > > Temps : 139,166 ms > > > > > > Can someome help me please ? > > > > Thanks. > > From the log (which is partial without queries) everything is fine. Up > to tds_fdw. > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3866 bytes Desc: not available URL: From adam.baratz at gmail.com Tue Oct 11 14:09:27 2016 From: adam.baratz at gmail.com (Adam Baratz) Date: Tue, 11 Oct 2016 14:09:27 -0400 Subject: [freetds] missing divide by zero error In-Reply-To: References: <4A990489BF566041A7724DC577BB060417F58903@smtp_mail.bankofamerica.com> Message-ID: I dug into this issue some more. I had misread the log. There was an info response with a "Division by zero occurred." message following the result. My handler ignored it because it came with a severity of 0. The message number, 3607, came through correctly. For comparison, I tried this query: > BEGIN TRY > SELECT 1/0; > END TRY > BEGIN CATCH > SELECT > ERROR_NUMBER() AS ErrorNumber, > ERROR_SEVERITY() AS ErrorSeverity, > ERROR_STATE() AS ErrorState, > ERROR_PROCEDURE() AS ErrorProcedure, > ERROR_LINE() AS ErrorLine, > ERROR_MESSAGE() AS ErrorMessage; > END CATCH; When run in SSMS, it produces two rowsets: one with no columns, one with error info: > ErrorNumber ErrorSeverity ErrorState ErrorProcedure ErrorLine ErrorMessage > 8134 16 1 NULL 2 Divide by zero error encountered. Interestingly, the message string is different. When run with my code, it produces two rowsets: one with no columns, one with a single NULL result. It doesn't seem like FreeTDS is related to this issue. I'm wondering, more generally now, if anyone's experienced issues like this, where queries run over db-library return very different results, and how they've tried to trap these differences. Thanks, Adam From adam.baratz at gmail.com Tue Oct 11 14:42:20 2016 From: adam.baratz at gmail.com (Adam Baratz) Date: Tue, 11 Oct 2016 14:42:20 -0400 Subject: [freetds] missing divide by zero error In-Reply-To: References: <4A990489BF566041A7724DC577BB060417F58903@smtp_mail.bankofamerica.com> Message-ID: I found a key detail in the docs for a similar Perl module: http://www.sommarskog.se/mssqlperl/mssql-sqllib.html#item_alwaysprint Thanks all for entertaining my thinking out loud... From james.k.lowden at icloud.com Thu Oct 13 10:15:54 2016 From: james.k.lowden at icloud.com (James K. Lowden) Date: Thu, 13 Oct 2016 10:15:54 -0400 Subject: [freetds] missing divide by zero error In-Reply-To: References: <4A990489BF566041A7724DC577BB060417F58903@smtp_mail.bankofamerica.com> Message-ID: <20161013101554.4c73e46b441512567ab559cb@icloud.com> On Tue, 11 Oct 2016 14:09:27 -0400 Adam Baratz wrote: > I dug into this issue some more. I had misread the log. There was an > info response with a "Division by zero occurred." message following > the result. My handler ignored it because it came with a severity of > 0. The message number, 3607, came through correctly. That's odd. The severity level comes from the server, and is documented to be 10, not 0. Your log file includes the packet as received from the server. If you determine that the server actually sent a severity of zero (which vaguely ISTR seeing, too) that would be interesting. If the server sent a severity of 10 and your handler was called with 0, that would be a bug. --jkl From freddy77 at gmail.com Thu Oct 13 10:47:52 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Thu, 13 Oct 2016 15:47:52 +0100 Subject: [freetds] missing divide by zero error In-Reply-To: <20161013101554.4c73e46b441512567ab559cb@icloud.com> References: <4A990489BF566041A7724DC577BB060417F58903@smtp_mail.bankofamerica.com> <20161013101554.4c73e46b441512567ab559cb@icloud.com> Message-ID: 2016-10-13 15:15 GMT+01:00 James K. Lowden : > On Tue, 11 Oct 2016 14:09:27 -0400 > Adam Baratz wrote: > >> I dug into this issue some more. I had misread the log. There was an >> info response with a "Division by zero occurred." message following >> the result. My handler ignored it because it came with a severity of >> 0. The message number, 3607, came through correctly. > > That's odd. The severity level comes from the server, and is > documented to be 10, not 0. > > Your log file includes the packet as received from the server. If you > determine that the server actually sent a severity of zero (which > vaguely ISTR seeing, too) that would be interesting. If the server > sent a severity of 10 and your handler was called with 0, that would be > a bug. > Adam attached part of TDSDUMP in the first mail and the server is filling severity field with 0: packet.c:639:Received packet 0000 04 01 00 7c 01 7f 01 00-81 01 00 00 00 00 00 21 |...|.... .......!| 0010 00 26 04 00 d1 00 ab 56-00 17 0e 00 00 00 00 1a |.&.....V ........| 0020 00 44 00 69 00 76 00 69-00 73 00 69 00 6f 00 6e |.D.i.v.i .s.i.o.n| 0030 00 20 00 62 00 79 00 20-00 7a 00 65 00 72 00 6f |. .b.y. .z.e.r.o| 0040 00 20 00 6f 00 63 00 63-00 75 00 72 00 72 00 65 |. .o.c.c .u.r.r.e| Weird but true... Frediano From adam.baratz at gmail.com Thu Oct 13 11:07:11 2016 From: adam.baratz at gmail.com (Adam Baratz) Date: Thu, 13 Oct 2016 11:07:11 -0400 Subject: [freetds] missing divide by zero error In-Reply-To: References: <4A990489BF566041A7724DC577BB060417F58903@smtp_mail.bankofamerica.com> <20161013101554.4c73e46b441512567ab559cb@icloud.com> Message-ID: > > Adam attached part of TDSDUMP in the first mail and the server > is filling severity field with 0: It turns out you have to call SET ARITHABORT/ARITHIGNORE/ANSI_WARNINGS ON for these to come back as errors with the correct severity. MS documents this. I think most of why it's confusing is that SSMS has them enabled by default. But even with those settings, you still get a result. Mysteries of TDS... From benjamin.moody at gmail.com Thu Oct 20 12:40:49 2016 From: benjamin.moody at gmail.com (Benjamin Moody) Date: Thu, 20 Oct 2016 12:40:49 -0400 Subject: [freetds] Is it possible to use FreeTDS to implement a stub TDS server? Message-ID: Let's say that I have a black-box application which produces a massive, continuous stream of data and dumps it into an MS SQL Server database. I want to pull the data *out* of this database as quickly as it is inserted, and pass it on for further processing in near-real-time. In fact, I have no interest in keeping the data in a relational database at all; once it's been extracted I have no further use for the SQL database, and I don't have disk space to store the data permanently. The SQL server is simply acting as a (rather inefficient) message queue. So what I would really like would be to avoid the use of MS SQL Server entirely, and simply connect the application to a "stub" server. That server would pretend to be MS SQL Server, and would respond to the application's requests as a real SQL server would, but in fact would simply be relaying the inserted data to an AMQP server or similar. * Has anybody done anything like this before? * Is it feasible to emulate the behavior of MS SQL Server to the degree that a client won't know the difference, assuming that the client is treating the server as a write-only output repository? * Does FreeTDS include low-level protocol code that would be useful in implementing such a stub server, or would it be simpler to start from scratch? Benjamin From freddy77 at gmail.com Thu Oct 20 17:06:22 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Thu, 20 Oct 2016 22:06:22 +0100 Subject: [freetds] Is it possible to use FreeTDS to implement a stub TDS server? In-Reply-To: References: Message-ID: 2016-10-20 17:40 GMT+01:00 Benjamin Moody : > Let's say that I have a black-box application which produces a > massive, continuous stream of data and dumps it into an MS SQL Server > database. I want to pull the data *out* of this database as quickly > as it is inserted, and pass it on for further processing in > near-real-time. > > In fact, I have no interest in keeping the data in a relational > database at all; once it's been extracted I have no further use for > the SQL database, and I don't have disk space to store the data > permanently. The SQL server is simply acting as a (rather > inefficient) message queue. > > So what I would really like would be to avoid the use of MS SQL Server > entirely, and simply connect the application to a "stub" server. That > server would pretend to be MS SQL Server, and would respond to the > application's requests as a real SQL server would, but in fact would > simply be relaying the inserted data to an AMQP server or similar. > > * Has anybody done anything like this before? > > * Is it feasible to emulate the behavior of MS SQL Server to the > degree that a client won't know the difference, assuming that the > client is treating the server as a write-only output repository? > > * Does FreeTDS include low-level protocol code that would be useful in > implementing such a stub server, or would it be simpler to start > from scratch? > > Benjamin Hi, there is a server directory which implements part of it. The better part is the login used and tested to implement the pooling server which is in a good state. The question is perhaps why you want to do it. Wouldn't be better and more efficient to use a message queue system directly? If you can change the queries of your client I could suggest (if changing completely the client is not possible) an extended store procedure or something similar (code that run on server but you can avoid data writing). Frediano From dchang at fsautomation.com Thu Oct 20 17:38:14 2016 From: dchang at fsautomation.com (David Chang) Date: Thu, 20 Oct 2016 14:38:14 -0700 Subject: [freetds] Is it possible to use FreeTDS to implement a stub TDS server? In-Reply-To: References: Message-ID: Benjamin, I think the easiest solution is an insert trigger on the tables that this black-box application writes to. If the records are fairly small (less than 4000 Unicode chars), you could use xp_cmdshell to write the record to a text file. http://www.databasejournal.com/features/mssql/article.php/1467601/A-general-logging-t-sql-process-to-write-to-txt-files.htm There's some set-up to allow SQL Server to use xp_cmdshell, but it's not that difficult. After the data is written out, you can delete the row(s) in the trigger. DC On 10/20/2016 2:06 PM, Frediano Ziglio wrote: > 2016-10-20 17:40 GMT+01:00 Benjamin Moody : >> Let's say that I have a black-box application which produces a >> massive, continuous stream of data and dumps it into an MS SQL Server >> database. I want to pull the data *out* of this database as quickly >> as it is inserted, and pass it on for further processing in >> near-real-time. >> >> In fact, I have no interest in keeping the data in a relational >> database at all; once it's been extracted I have no further use for >> the SQL database, and I don't have disk space to store the data >> permanently. The SQL server is simply acting as a (rather >> inefficient) message queue. >> >> So what I would really like would be to avoid the use of MS SQL Server >> entirely, and simply connect the application to a "stub" server. That >> server would pretend to be MS SQL Server, and would respond to the >> application's requests as a real SQL server would, but in fact would >> simply be relaying the inserted data to an AMQP server or similar. >> >> * Has anybody done anything like this before? >> >> * Is it feasible to emulate the behavior of MS SQL Server to the >> degree that a client won't know the difference, assuming that the >> client is treating the server as a write-only output repository? >> >> * Does FreeTDS include low-level protocol code that would be useful in >> implementing such a stub server, or would it be simpler to start >> from scratch? >> >> Benjamin > > Hi, > there is a server directory which implements part of it. > The better part is the login used and tested to implement the pooling > server which is in a good state. > The question is perhaps why you want to do it. Wouldn't be better and > more efficient to use a message queue system directly? If you can > change the queries of your client I could suggest (if changing > completely the client is not possible) an extended store procedure or > something similar (code that run on server but you can avoid data > writing). > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From james.k.lowden at icloud.com Thu Oct 20 19:18:12 2016 From: james.k.lowden at icloud.com (James K. Lowden) Date: Thu, 20 Oct 2016 19:18:12 -0400 Subject: [freetds] Is it possible to use FreeTDS to implement a stub TDS server? In-Reply-To: References: Message-ID: <20161020191812.8337627de93952fdcc37a2aa@icloud.com> On Thu, 20 Oct 2016 12:40:49 -0400 Benjamin Moody wrote: > Let's say that I have a black-box application which produces a > massive, continuous stream of data and dumps it into an MS SQL Server > database. I want to pull the data *out* of this database as quickly > as it is inserted, and pass it on for further processing in > near-real-time. By "black-box", I take it you mean the application cannot be changed, and its current implementation writes to MS SQL Server. > Is it feasible to emulate the behavior of MS SQL Server Probably not. > * Does FreeTDS include low-level protocol code that would be useful in > implementing such a stub server, or would it be simpler to start > from scratch? Yes, and yes. The FreeTDS server code holds the rudiments of a beginning. As far as I know, it has never been used for anything serious. It doesn't implement any of the ACID features, nor does it recognize SQL. I have long thought that TDS is a very respectable protocol, and with the right API (and implementation) would be convenient and efficient peer-to-peer data exchange. BCP is particularly lean. It benefits from its relational origins: everything is a table, and all datatypes are strictly defined (with a blob escape valve). Sybase thought so, too; compared with their db-lib first draft, ct-lib is much more peer-oriented. While libtds could be repurposed to support a server implemementation, that was never its intended use. It would be better to begin with a state machine, and static definitions of all the varieties of packets supported by different flavors of the protocol. Client and server become co-processes exchanging data as TDS pages. A generic table-exchange service would be a boon to the industry. All popular data exchange protocols -- ftp, http, also protocol buffers & similar -- are based on files or bytestreams. None are based on the TDS model: metadata once, rows follow, all bindings at runtime. What a shame the problem isn't more broadly understood, and addressed. --jkl From ikorot01 at gmail.com Fri Oct 21 22:47:13 2016 From: ikorot01 at gmail.com (Igor Korot) Date: Fri, 21 Oct 2016 22:47:13 -0400 Subject: [freetds] Is it possible to use FreeTDS to implement a stub TDS server? In-Reply-To: <20161020191812.8337627de93952fdcc37a2aa@icloud.com> References: <20161020191812.8337627de93952fdcc37a2aa@icloud.com> Message-ID: Hi, If you can select the DB and and not connected only to MS SQL can I suggest SQLite? Thank you. On Thu, Oct 20, 2016 at 7:18 PM, James K. Lowden wrote: > On Thu, 20 Oct 2016 12:40:49 -0400 > Benjamin Moody wrote: > >> Let's say that I have a black-box application which produces a >> massive, continuous stream of data and dumps it into an MS SQL Server >> database. I want to pull the data *out* of this database as quickly >> as it is inserted, and pass it on for further processing in >> near-real-time. > > By "black-box", I take it you mean the application cannot be changed, > and its current implementation writes to MS SQL Server. > >> Is it feasible to emulate the behavior of MS SQL Server > > Probably not. > >> * Does FreeTDS include low-level protocol code that would be useful in >> implementing such a stub server, or would it be simpler to start >> from scratch? > > Yes, and yes. > > The FreeTDS server code holds the rudiments of a beginning. As far as > I know, it has never been used for anything serious. It doesn't > implement any of the ACID features, nor does it recognize SQL. > > I have long thought that TDS is a very respectable protocol, and with > the right API (and implementation) would be convenient and efficient > peer-to-peer data exchange. BCP is particularly lean. It benefits from > its relational origins: everything is a table, and all datatypes are > strictly defined (with a blob escape valve). Sybase thought so, too; > compared with their db-lib first draft, ct-lib is much more > peer-oriented. > > While libtds could be repurposed to support a server implemementation, > that was never its intended use. It would be better to begin with a > state machine, and static definitions of all the varieties of packets > supported by different flavors of the protocol. Client and server > become co-processes exchanging data as TDS pages. > > A generic table-exchange service would be a boon to the industry. > All popular data exchange protocols -- ftp, http, also protocol buffers > & similar -- are based on files or bytestreams. None are based on the > TDS model: metadata once, rows follow, all bindings at runtime. > What a shame the problem isn't more broadly understood, and addressed. > > --jkl > > > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From benjamin.moody at gmail.com Fri Oct 21 14:14:08 2016 From: benjamin.moody at gmail.com (Benjamin Moody) Date: Fri, 21 Oct 2016 14:14:08 -0400 Subject: [freetds] Is it possible to use FreeTDS to implement a stub TDS server? In-Reply-To: <20161020191812.8337627de93952fdcc37a2aa@icloud.com> References: <20161020191812.8337627de93952fdcc37a2aa@icloud.com> Message-ID: Thank you all for your helpful suggestions and questions. [Frediano Ziglio] > there is a server directory which implements part of it. > The better part is the login used and tested to implement the pooling > server which is in a good state. Sounds useful indeed. I'll have to take a look at that. > The question is perhaps why you want to do it. Wouldn't be better and > more efficient to use a message queue system directly? Probably. However, we don't have any control over the client; it's provided as-is without source and with limited documentation from the developers. That's what I meant by a black box. The only knobs we can tweak are the IP address and login credentials for the server where it will output data. That said, at this point I am simply trying to understand the scope of the problem and investigate possible ways we might go about integrating this program into our systems. [David Chang] > I think the easiest solution is an insert trigger on the tables that > this black-box application writes to. That's a good suggestion and may be what we end up doing. [James K. Lowden] >> Let's say that I have a black-box application which produces a >> massive, continuous stream of data and dumps it into an MS SQL Server >> database. I want to pull the data *out* of this database as quickly >> as it is inserted, and pass it on for further processing in >> near-real-time. > > By "black-box", I take it you mean the application cannot be changed, > and its current implementation writes to MS SQL Server. Right. >> Is it feasible to emulate the behavior of MS SQL Server > > Probably not. :) Fair enough. >> * Does FreeTDS include low-level protocol code that would be useful in >> implementing such a stub server, or would it be simpler to start >> from scratch? > > Yes, and yes. > > The FreeTDS server code holds the rudiments of a beginning. As far as > I know, it has never been used for anything serious. It doesn't > implement any of the ACID features, nor does it recognize SQL. My hunch is that for this application, we wouldn't need anything like a real SQL parser, and that we would just need to enumerate the fairly small set of SQL statements (and/or BCP transfers) that the program will use, and supply canned responses. But that remains to be seen. Benjamin From joshua.h.lang at gmail.com Tue Nov 1 19:33:31 2016 From: joshua.h.lang at gmail.com (Joshua Lang) Date: Tue, 1 Nov 2016 16:33:31 -0700 Subject: [freetds] bcp_bind with NVARCHAR with FreeTDS 1.00.15 Message-ID: I'm have issues using the programmatic bcp APIs and a table with an NVARCHAR column. If I specify a data type of NVARCHAR (0xe7) to bcp_bind's db_vartype parameter, bcp_sendrow fails in tds_convert since there is no conversion for the NVARCHAR type supported by tds_convert. This fails with an error of "Requested data conversion does not exist", though this error is generated internally from FreeTDS. If I specify VARCHAR as the data type, the server rejects the input data with an error of "Unicode data is odd byte size for column 4. Should be even byte size." Any ideas? From freddy77 at gmail.com Wed Nov 2 11:32:41 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Wed, 2 Nov 2016 15:32:41 +0000 Subject: [freetds] bcp_bind with NVARCHAR with FreeTDS 1.00.15 In-Reply-To: References: Message-ID: 2016-11-01 23:33 GMT+00:00 Joshua Lang : > I'm have issues using the programmatic bcp APIs and a table with an > NVARCHAR column. > > If I specify a data type of NVARCHAR (0xe7) to bcp_bind's db_vartype > parameter, bcp_sendrow fails in tds_convert since there is no conversion > for the NVARCHAR type supported by tds_convert. This fails with an error of > "Requested data conversion does not exist", though this error is generated > internally from FreeTDS. > > If I specify VARCHAR as the data type, the server rejects the input data > with an error of > "Unicode data is odd byte size for column 4. Should be even byte size." > > Any ideas? I was looking at the code. Maybe this conversion is not much supported Frediano From marco.baurdoux at tourisoft.com Wed Nov 2 11:43:22 2016 From: marco.baurdoux at tourisoft.com (Marco Baurdoux) Date: Wed, 2 Nov 2016 16:43:22 +0100 Subject: [freetds] Date formatting with Timezone Message-ID: <011701d2351f$d804b090$880e11b0$@tourisoft.com> Hello, We're running Freetds 1.00.15 on a CentOS Linux release 7.2.1511 and connecting to MS-SQL 2014 We're trying to obtain the date in the following format "2016-11-02 13 :28 :32.0000000 +02:00". For this we've configured the date format parameter in the locales.conf file to %Y-%m-%d %H:%M:%S.%z %Z Depending on which tdsver we configure, even the output of "%Y-%m-%d %H:%M:%S.%z %Z" is different: - With TDSVER 7.1 or 7.2 we obtain a date formatted like "2016-11-02 13:28:32.0000000 +00:00". Exactly what we want. - With TDSVER 7.3 or 7.4 we obtain a date formatted like "2016-11-02 13:28:32.0000000 CET. This breaks our PHP API but it respects the strftime description of %Z. I'm unable to find how to obtain the time zone in "+00:00" format. Is there a solution to work with the latest version of Freetds and still get the timezone is the wished format or are we doomed (:)) to stick to version 7.2? Thank you for any feedback/advice. Regards, Marco Baurdoux Business Development / Co-Founder Tourisoft / Hotel-Spider Route de Champ-Colin 18 CH-1260 Nyon Switzerland Tel: +41 22 360 03 70 Fax: +41 22 360 03 73 http://www.hotel-spider.com From freddy77 at gmail.com Thu Nov 3 07:21:05 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Thu, 3 Nov 2016 11:21:05 +0000 Subject: [freetds] Date formatting with Timezone In-Reply-To: <011701d2351f$d804b090$880e11b0$@tourisoft.com> References: <011701d2351f$d804b090$880e11b0$@tourisoft.com> Message-ID: 2016-11-02 15:43 GMT+00:00 Marco Baurdoux : > Hello, > > > > We're running Freetds 1.00.15 on a CentOS Linux release 7.2.1511 and > connecting to MS-SQL 2014 > > > > We're trying to obtain the date in the following format "2016-11-02 13 :28 > :32.0000000 +02:00". For this we've configured the date format parameter in > the locales.conf file to %Y-%m-%d %H:%M:%S.%z %Z > > Depending on which tdsver we configure, even the output of "%Y-%m-%d > %H:%M:%S.%z %Z" is different: > > - With TDSVER 7.1 or 7.2 we obtain a date formatted like > "2016-11-02 13:28:32.0000000 +00:00". Exactly what we want. > > - With TDSVER 7.3 or 7.4 we obtain a date formatted like > "2016-11-02 13:28:32.0000000 CET. This breaks our PHP API but it respects > the strftime description of %Z. I'm unable to find how to obtain the time > zone in "+00:00" format. > > > > Is there a solution to work with the latest version of Freetds and still get > the timezone is the wished format or are we doomed (:)) to stick to version > 7.2? > > > > Thank you for any feedback/advice. > > > > Regards, > > > > Marco Baurdoux > I think you are using a DATETIMEOFFSET type. This type started to be supported since TDS 7.3 (sql 2008) if you connect with a previous TDS version the server is just sending back varchar/nvarchar (I don't remember exactly) so the "2016-11-02 13:28:32.0000000 +00:00" is formatted from the server, not by the client and format string in locales.conf do not apply. Note that the most similar formatting (+/-HHMM) you can get with a standard strftime using %z however we used %z as a fractional decimal specifier. So looks like was a mistake to use %z as new modifier. Note also the %Z on Windows behave like %z (http://php.net/manual/en/function.strftime.php) but probably you are not using Windows :-) Looking at new man pages for strftime looks like you can specify E or O modifier (like %Ec) to have alternate formats. Perhaps would be a good idea to use some different way to specify fractional seconds (%OOS ??) and another to specify +/-HH:MM (%OOz ??) this these looks like new extensions. See http://pubs.opengroup.org/onlinepubs/9699919799/functions/strftime.html Frediano From joshua.h.lang at gmail.com Thu Nov 3 19:01:52 2016 From: joshua.h.lang at gmail.com (Joshua Lang) Date: Thu, 3 Nov 2016 16:01:52 -0700 Subject: [freetds] bcp_bind with NVARCHAR with FreeTDS 1.00.15 In-Reply-To: References: Message-ID: As currently implemented, it would appear not. Should I open an issue on github for this to be fixed? On Wed, Nov 2, 2016 at 8:32 AM, Frediano Ziglio wrote: > 2016-11-01 23:33 GMT+00:00 Joshua Lang : > > I'm have issues using the programmatic bcp APIs and a table with an > > NVARCHAR column. > > > > If I specify a data type of NVARCHAR (0xe7) to bcp_bind's db_vartype > > parameter, bcp_sendrow fails in tds_convert since there is no conversion > > for the NVARCHAR type supported by tds_convert. This fails with an error > of > > "Requested data conversion does not exist", though this error is > generated > > internally from FreeTDS. > > > > If I specify VARCHAR as the data type, the server rejects the input data > > with an error of > > "Unicode data is odd byte size for column 4. Should be even byte size." > > > > Any ideas? > > > I was looking at the code. Maybe this conversion is not much supported > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > From peterd at iea-software.com Tue Nov 8 01:50:40 2016 From: peterd at iea-software.com (Peter Deacon) Date: Mon, 7 Nov 2016 22:50:40 -0800 (Pacific Standard Time) Subject: [freetds] Disabling character translation Message-ID: Have data being shoveled into fields which do not represent native type reported by database and need to completely disable character translation. Looking for parity with SQL Server driver option "perform translation for character data" (ODBC.INI AutoTranslate=No) Anyone know of a trick to make it work? Tried setting Charset in local environment using replacement iconv but every conversion in the list either crashed or didn't help. If not 'll send a patch to support it :) regards, Peter From freddy77 at gmail.com Tue Nov 8 12:19:07 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Tue, 8 Nov 2016 17:19:07 +0000 Subject: [freetds] Disabling character translation In-Reply-To: References: Message-ID: 2016-11-08 6:50 GMT+00:00 Peter Deacon : > Have data being shoveled into fields which do not represent native type > reported by database and need to completely disable character translation. > > Looking for parity with SQL Server driver option "perform translation for > character data" (ODBC.INI AutoTranslate=No) > > Anyone know of a trick to make it work? Tried setting Charset in local > environment using replacement iconv but every conversion in the list either > crashed or didn't help. > > If not 'll send a patch to support it :) > > regards, > Peter Go on! Just some details. libTDS can convert to multibyte (like utf-8) directly. This is disabled by ODBC so using ODBC libTDS just store data from network. Also usually conversion function just copy data if char_conv is NULL. There should be some conversion function in src/odbc directory to deal with data conversion (I think metadata like column names are all converted in all cases... I hope you don't need these unconverted). Frediano From a-dbakin at expedia.com Fri Nov 11 12:53:32 2016 From: a-dbakin at expedia.com (David Bakin) Date: Fri, 11 Nov 2016 17:53:32 +0000 Subject: [freetds] Fault injection via man-in-the-middle proxy? Message-ID: <673d5b2bee554f7c930d0036ffbc9e7d@PHCXEXCHMBX009.SEA.CORP.EXPECN.com> (New to the list, new to TDS: I may have serious misconceptions!) I'm thinking it would be useful - in order to help diagnose certain client-side reliability issues due to network problems we occasionally experience that lead to database connections returning errors (at the client-side) - to have a sort of man-in-the-middle proxy that could do SQL-oriented fault injection - e.g. returning errors at the protocol level, or simulating network faults (e.g., abnormal delays, or timeouts). (It's hard for me to find the right keywords for a google search as it turns out that "SQL Fault Injection" has a completely different meaning ...) So ... a couple of questions: a) Does this even make sense? b) Is there an existing tool that'll do it? c) Can I use FreeTDS to create a tool that'll do it? * Does this sound like a promising approach (assuming the answer to point a is "yes")? * As to point c - an earlier message on this list pointed a requester to tdspool as a starting point. o Is tdspool a good starting point? o This message/response was in 2010 and the response was that tdspool was subject to bit rot - I do see now in git that it was last updated only 4 months ago ... so I assume it is working now? * Assuming a = yes, b = no, c = yes and I go ahead with this, do you think the end result would be of general interest? Thanks! - David P.S. The environment is Windows, ODBC, SQL Server, and the client is a C++ application. From freddy77 at gmail.com Sat Nov 12 16:02:56 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Sat, 12 Nov 2016 21:02:56 +0000 Subject: [freetds] Fault injection via man-in-the-middle proxy? In-Reply-To: <673d5b2bee554f7c930d0036ffbc9e7d@PHCXEXCHMBX009.SEA.CORP.EXPECN.com> References: <673d5b2bee554f7c930d0036ffbc9e7d@PHCXEXCHMBX009.SEA.CORP.EXPECN.com> Message-ID: 2016-11-11 17:53 GMT+00:00 David Bakin : > (New to the list, new to TDS: I may have serious misconceptions!) > > I'm thinking it would be useful - in order to help diagnose certain client-side reliability issues due to network problems we occasionally experience that lead to database connections returning errors (at the client-side) - to have a sort of man-in-the-middle proxy that could do SQL-oriented fault injection - e.g. returning errors at the protocol level, or simulating network faults (e.g., abnormal delays, or timeouts). > For network tools you should probably find lot of tools. Even using VPN software and stopping them can give good tests. > (It's hard for me to find the right keywords for a google search as it turns out that "SQL Fault Injection" has a completely different meaning ...) > > So ... a couple of questions: > > > a) Does this even make sense? > Maybe > b) Is there an existing tool that'll do it? > Not as far as I know > c) Can I use FreeTDS to create a tool that'll do it? > > * Does this sound like a promising approach (assuming the answer to point a is "yes")? > > * As to point c - an earlier message on this list pointed a requester to tdspool as a starting point. > > o Is tdspool a good starting point? > Can be, it's actually a SQL proxy. > o This message/response was in 2010 and the response was that tdspool was subject to bit rot - I do see now in git that it was last updated only 4 months ago ... so I assume it is working now? > Yes, has some limits like sql users and not encryption but works. On the other side it reads packet content only at login time. > * Assuming a = yes, b = no, c = yes and I go ahead with this, do you think the end result would be of general interest? > Don't know. > Thanks! - David > > P.S. The environment is Windows, ODBC, SQL Server, and the client is a C++ application. All FreeTDS is quite portable. Frediano From jefarr at wayfair.com Thu Nov 17 12:35:05 2016 From: jefarr at wayfair.com (Jeff Farr) Date: Thu, 17 Nov 2016 17:35:05 +0000 Subject: [freetds] Found a bug with batch statements that don't contain a select. Message-ID: <1479404105011.18510@wayfair.com> Hello all, a while back we found some unexpected behavior when sending multiple queries in a statement and, initially, thought it was a bug with PHPs PDO library (you can see the bug report here https://bugs.php.net/bug.php?id=72969). I dug into the issue and found that the underlying problem is that if you call dbresults on a result set that doesn't contain TDS_ROW_RESULT or TDS_ROWFMT_RESULT then the for loop will process every set of tokens in the data in one swoop and then return NO_MORE_ROWS to the calling function. I've made a small change to _dbresults and added a couple of unit tests that demonstrate the issue and verify that it's fixed, review and feedback from the list is much appreciated! If it's easier, I also created a PR against Branch-1_00 here: https://github.com/FreeTDS/freetds/pull/84 Thanks, -Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: batch_statements_without_select.diff Type: application/octet-stream Size: 15335 bytes Desc: batch_statements_without_select.diff URL: From no-reply at appveyor.com Thu Nov 17 15:14:28 2016 From: no-reply at appveyor.com (AppVeyor) Date: Thu, 17 Nov 2016 20:14:28 +0000 Subject: [freetds] Build failed: freetds 716 Message-ID: <20161117201428.13649.8798.D747B4FA@appveyor.com> From no-reply at appveyor.com Thu Nov 17 15:45:46 2016 From: no-reply at appveyor.com (AppVeyor) Date: Thu, 17 Nov 2016 20:45:46 +0000 Subject: [freetds] Build completed: freetds 717 Message-ID: <20161117204546.8458.7262.7FC179E0@appveyor.com> From m.becker at spider-software.net Mon Nov 21 08:07:39 2016 From: m.becker at spider-software.net (Michael Becker) Date: Mon, 21 Nov 2016 14:07:39 +0100 Subject: [freetds] FreeTDS 0.95 onwards and Windows Message-ID: Is FreeTDS 0.95 onwards requiring Windows Pro to run? It is linked against a lot of API-MS-WIN-CORE-...DLLs. Among others API-MS-WIN-CORE-WINRT-L1-1-0.DLL, which is - as far as I know - only included in the Pro version of Windows. Thanks: Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: m_becker.vcf Type: text/x-vcard Size: 135 bytes Desc: not available URL: From cramm0 at gmail.com Mon Nov 21 10:17:24 2016 From: cramm0 at gmail.com (Ramiro Morales) Date: Mon, 21 Nov 2016 12:17:24 -0300 Subject: [freetds] FreeTDS 0.95 onwards and Windows In-Reply-To: References: Message-ID: On Mon, Nov 21, 2016 at 10:07 AM, Michael Becker < m.becker at spider-software.net> wrote: > Is FreeTDS 0.95 onwards requiring Windows Pro to run? > It is linked against a lot of API-MS-WIN-CORE-...DLLs. Among others > API-MS-WIN-CORE-WINRT-L1-1-0.DLL, which is - as far as I know - only > included in the Pro version of Windows. > Can you post a dependency ttee or similar in which it can be seen if the dependency is explicit/implicit, direct/indirect, etc.? Are you building FreeTD yourself? -- Ramiro Morales @ramiromorales From m.becker at spider-software.net Mon Nov 21 10:23:50 2016 From: m.becker at spider-software.net (Michael Becker) Date: Mon, 21 Nov 2016 16:23:50 +0100 Subject: [freetds] FreeTDS 0.95 onwards and Windows In-Reply-To: References: Message-ID: Hi Ramiro, thanks for the help. Seems that this were misleading errors from dependency walker. The problem was caused by a different library, which was placed in a wrong directory. Michael On 21/11/16 16:17, Ramiro Morales wrote: > On Mon, Nov 21, 2016 at 10:07 AM, Michael Becker < > m.becker at spider-software.net> wrote: > >> Is FreeTDS 0.95 onwards requiring Windows Pro to run? >> It is linked against a lot of API-MS-WIN-CORE-...DLLs. Among others >> API-MS-WIN-CORE-WINRT-L1-1-0.DLL, which is - as far as I know - only >> included in the Pro version of Windows. >> > > Can you post a dependency ttee or similar in which it can be seen if the > dependency is explicit/implicit, direct/indirect, etc.? > > Are you building FreeTD yourself? > > -------------- next part -------------- A non-text attachment was scrubbed... Name: m_becker.vcf Type: text/x-vcard Size: 135 bytes Desc: not available URL: From no-reply at appveyor.com Mon Nov 28 15:13:39 2016 From: no-reply at appveyor.com (AppVeyor) Date: Mon, 28 Nov 2016 20:13:39 +0000 Subject: [freetds] Build failed: freetds 721 Message-ID: <20161128201332.29496.68594.621543EB@appveyor.com> From no-reply at appveyor.com Wed Nov 30 18:58:09 2016 From: no-reply at appveyor.com (AppVeyor) Date: Wed, 30 Nov 2016 23:58:09 +0000 Subject: [freetds] Build completed: freetds 723 Message-ID: <20161130235809.12711.40681.8B1C5407@appveyor.com> From no-reply at appveyor.com Wed Nov 30 19:28:19 2016 From: no-reply at appveyor.com (AppVeyor) Date: Thu, 01 Dec 2016 00:28:19 +0000 Subject: [freetds] Build failed: freetds 724 Message-ID: <20161201002819.86387.8167.7D410462@appveyor.com> From no-reply at appveyor.com Mon Dec 5 14:14:03 2016 From: no-reply at appveyor.com (AppVeyor) Date: Mon, 05 Dec 2016 19:14:03 +0000 Subject: [freetds] Build completed: freetds 727 Message-ID: <20161205191403.15102.75641.57634056@appveyor.com> From amak at mazda.com.au Mon Dec 19 18:46:05 2016 From: amak at mazda.com.au (Andrew Mak) Date: Mon, 19 Dec 2016 23:46:05 +0000 Subject: [freetds] 'make/gmake" error on Solaris 11 SPARC Message-ID: Dear members of the list, I downloaded FreeTDS version 1.00.23 (freetds-patched.tar.gz) from http://www.freetds.org/software.html and compile it on SPARC Solaris 11.3 using gcc 4.8.2 compiler. The "./configure" finished successfully without any error. However the "make" (or "gmake") generates the following error ... ... ct.c:1111:6: warning: \u2018ret\u2019 may be used uninitialized in this function [-Wmaybe-uninitialized] if (TDS_SUCCEED(ret)) ^ CC cs.lo CC blk.lo CC ctutil.lo CCLD libct.la ../../libtool[1721]: eval: syntax error at line 1: `|' unexpected gmake[3]: *** [libct.la] Error 3 gmake[3]: Leaving directory `/export/home/amak/freetds/freetds-1.00.23/src/ctlib' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/export/home/amak/freetds/freetds-1.00.23/src/ctlib' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/export/home/amak/freetds/freetds-1.00.23/src' gmake: *** [all-recursive] Error 1 root at wl-remote-deploy:/export/home/amak/freetds/freetds-1.00.23# When I search for the file "libct.la", it does not exist anywhere. root at wl-remote-deploy:/export/home/amak/freetds/freetds-1.00.23# cd .. root at wl-remote-deploy:/export/home/amak/freetds# find . -name libct.la root at wl-remote-deploy:/export/home/amak/freetds# Any suggestions? Regards Andrew Mak ************************************************************************************************* This email and its attachments contain confidential, private and/or personal information and should be strictly treated as such. If you are not the intended recipient of this email, please notify us immediately on +61 3 8540 1800 and delete and permanently erase the email, its attachments and all copies thereof, including all copies stored in any backup system or other medium. All of the emailed information is intended for a specific individual purpose and may be subject to copyright and/or professional privilege. If you are not the intended recipient of this email, you and your agents must not use, disseminate, print or copy the emailed information or any part thereof, or take action based on the emailed information or any part thereof, without Mazda's express written consent. Mazda does not guarantee that this e-mail is virus or error free. The attached files are provided and may only be used by the intended recipient on the basis that the recipient assumes all responsibility for any loss, damage or consequence resulting directly or indirectly from the use of the attached files, whether or not caused by the negligence of the sender. If this is a commercial electronic message within the meaning of the Spam Act, you may indicate that you do not wish to receive any further commercial electronic messages from Mazda Australia by sending an e-mail to mailto:privacy at mazda.com.au ************************************************************************************************* From freddy77 at gmail.com Tue Dec 20 11:53:25 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Tue, 20 Dec 2016 16:53:25 +0000 Subject: [freetds] 'make/gmake" error on Solaris 11 SPARC In-Reply-To: References: Message-ID: 2016-12-19 23:46 GMT+00:00 Andrew Mak : > Dear members of the list, > > I downloaded FreeTDS version 1.00.23 (freetds-patched.tar.gz) from http://www.freetds.org/software.html and compile it on SPARC Solaris 11.3 using gcc 4.8.2 compiler. The "./configure" finished successfully without any error. > However the "make" (or "gmake") generates the following error > ... > ... > ct.c:1111:6: warning: \u2018ret\u2019 may be used uninitialized in this function [-Wmaybe-uninitialized] > if (TDS_SUCCEED(ret)) > ^ > CC cs.lo > CC blk.lo > CC ctutil.lo > CCLD libct.la > ../../libtool[1721]: eval: syntax error at line 1: `|' unexpected The main issue here is the libtool. libtool is a shell script generated by configure adding some variable to a base script. It seems it does not like some shell syntax. If you have another shell installed you can open it and change the first line (I would try bash if it's available). Or if you have another libtool on your system you can try to replace with the one you have. What does "./libtool --version" says? If the above does not work I could try to send a distribution with another libtool version. > gmake[3]: *** [libct.la] Error 3 > gmake[3]: Leaving directory `/export/home/amak/freetds/freetds-1.00.23/src/ctlib' > gmake[2]: *** [all-recursive] Error 1 > gmake[2]: Leaving directory `/export/home/amak/freetds/freetds-1.00.23/src/ctlib' > gmake[1]: *** [all-recursive] Error 1 > gmake[1]: Leaving directory `/export/home/amak/freetds/freetds-1.00.23/src' > gmake: *** [all-recursive] Error 1 > root at wl-remote-deploy:/export/home/amak/freetds/freetds-1.00.23# > > > When I search for the file "libct.la", it does not exist anywhere. > > root at wl-remote-deploy:/export/home/amak/freetds/freetds-1.00.23# cd .. > root at wl-remote-deploy:/export/home/amak/freetds# find . -name libct.la > root at wl-remote-deploy:/export/home/amak/freetds# > > Any suggestions? > > Regards > Andrew Mak > Frediano From matthew.green at datamartcomputing.com Wed Dec 21 03:01:53 2016 From: matthew.green at datamartcomputing.com (matthew.green at datamartcomputing.com) Date: Wed, 21 Dec 2016 08:01:53 +0000 Subject: [freetds] 'make/gmake" error on Solaris 11 SPARC In-Reply-To: References: Message-ID: I've compiled older version on SPARC. I know that might not help with this problem but it does show that it's likely to either be an environmental issue or something introduced after 0.9. Cheers, Matthew. December 20 2016 5:54 PM, "Frediano Ziglio" wrote: > 2016-12-19 23:46 GMT+00:00 Andrew Mak : > >> Dear members of the list, >> >> I downloaded FreeTDS version 1.00.23 (freetds-patched.tar.gz) from >> http://www.freetds.org/software.html and compile it on SPARC Solaris 11.3 using gcc 4.8.2 > compiler. >> The "./configure" finished successfully without any error. >> However the "make" (or "gmake") generates the following error >> ... >> ... >> ct.c:1111:6: warning: \u2018ret\u2019 may be used uninitialized in this function >> [-Wmaybe-uninitialized] >> if (TDS_SUCCEED(ret)) >> ^ >> CC cs.lo >> CC blk.lo >> CC ctutil.lo >> CCLD libct.la >> ../../libtool[1721]: eval: syntax error at line 1: `|' unexpected > > The main issue here is the libtool. libtool is a shell script > generated by configure adding some variable > to a base script. It seems it does not like some shell syntax. If you > have another shell installed > you can open it and change the first line (I would try bash if it's available). > Or if you have another libtool on your system you can try to replace > with the one you > have. > What does "./libtool --version" says? > If the above does not work I could try to send a distribution with > another libtool version. > >> gmake[3]: *** [libct.la] Error 3 >> gmake[3]: Leaving directory `/export/home/amak/freetds/freetds-1.00.23/src/ctlib' >> gmake[2]: *** [all-recursive] Error 1 >> gmake[2]: Leaving directory `/export/home/amak/freetds/freetds-1.00.23/src/ctlib' >> gmake[1]: *** [all-recursive] Error 1 >> gmake[1]: Leaving directory `/export/home/amak/freetds/freetds-1.00.23/src' >> gmake: *** [all-recursive] Error 1 >> > root at wl-remote-deploy:/export/home/amak/freetds/freetds-1.00.23#> /home/amak/freetds/freetds-1.00.23#> >> >> When I search for the file "libct.la", it does not exist anywhere. >> >> root at wl-remote-deploy:/export/home/amak/freetds/freetds-1.00.23# cd .. >> root at wl-remote-deploy:/export/home/amak/freetds# find . -name libct.la >> root at wl-remote-deploy:/export/home/amak/freetds# >> >> Any suggestions? >> >> Regards >> Andrew Mak > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From amak at mazda.com.au Wed Dec 21 22:59:48 2016 From: amak at mazda.com.au (Andrew Mak) Date: Thu, 22 Dec 2016 03:59:48 +0000 Subject: [freetds] FreeTDS 1.00.23 make failed on Spacr Solaris 11 Message-ID: <2a59a704fdb44e45989720063bc042be@MAPREX01.mazda.com.au> I downloaded the tar ball and start to build FreeTDS on a SPARC Solaris 11.3 machine. The "./configure" run successfully. The "gmake" failed with ../../libtool[1721]: eval: syntax error at line 1: `|' unexpected gmake[3]: *** [libct.la] Error 3 Please refer to attached "gmake-using_orig_libtool.txt.gz" for details, the file is generated using "gmake V=1 &> gmake-using_orig_libtool.txt". 2nd attempt, copied the Solaris libtool to the FreeTDS directory, replacing the libtool from FreeTDS. The Solaris "libtool" with the following modification # sdiff -s `which libtool` libtool-modi 308c308,309 CC="cc" | #amak# CC="cc" > CC="gcc" 317c318,319 pic_flag=" -KPIC -DPIC" | #amak# pic_flag=" -KPIC -DPIC" > pic_flag=" -fPIC -DPIC" 10116c10118,10119 pic_flag=" -KPIC -DPIC" | #amak# pic_flag=" -KPIC -DPIC" > pic_flag=" -fPIC -DPIC" This get me further but still failed with libtool: link: gcc -D_REENTRANT -pthreads -g -O2 -Wdeclaration-after-statement -o .libs/fisql fisql.o terminal.o edit.o handlers.o interrupt.o ../../dblib/.libs/libsybdb.so -lnsl -lsocket -lssl -lcrypto ../../replacements/.libs/libreplacements.a -lncurses -lreadline -pthreads -R/usr/local/lib gcc: error: ../../dblib/.libs/libsybdb.so: No such file or directory gmake[3]: *** [fisql] Error 1 Please refer to attached "gmake-using_solaris_libtool.txt.gz" for details. The file is generated using "gmake V=1 &> gmake-using_solaris_libtool.txt" Any suggestion/advice? Regards Andrew Mak ************************************************************************************************* This email and its attachments contain confidential, private and/or personal information and should be strictly treated as such. If you are not the intended recipient of this email, please notify us immediately on +61 3 8540 1800 and delete and permanently erase the email, its attachments and all copies thereof, including all copies stored in any backup system or other medium. All of the emailed information is intended for a specific individual purpose and may be subject to copyright and/or professional privilege. If you are not the intended recipient of this email, you and your agents must not use, disseminate, print or copy the emailed information or any part thereof, or take action based on the emailed information or any part thereof, without Mazda's express written consent. Mazda does not guarantee that this e-mail is virus or error free. The attached files are provided and may only be used by the intended recipient on the basis that the recipient assumes all responsibility for any loss, damage or consequence resulting directly or indirectly from the use of the attached files, whether or not caused by the negligence of the sender. If this is a commercial electronic message within the meaning of the Spam Act, you may indicate that you do not wish to receive any further commercial electronic messages from Mazda Australia by sending an e-mail to mailto:privacy at mazda.com.au ************************************************************************************************* -------------- next part -------------- A non-text attachment was scrubbed... Name: gmake-using_orig_libtool.txt.gz Type: application/x-gzip Size: 4250 bytes Desc: gmake-using_orig_libtool.txt.gz URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gmake-using_solaris_libtool.txt.gz Type: application/x-gzip Size: 7098 bytes Desc: gmake-using_solaris_libtool.txt.gz URL: