From no-reply at appveyor.com Thu Oct 12 03:18:27 2017 From: no-reply at appveyor.com (AppVeyor) Date: Thu, 12 Oct 2017 07:18:27 +0000 Subject: [freetds] Build failed: freetds 946 Message-ID: <20171012071326.61583.BFEC50B682358175@appveyor.com> From no-reply at appveyor.com Thu Oct 12 04:18:00 2017 From: no-reply at appveyor.com (AppVeyor) Date: Thu, 12 Oct 2017 08:18:00 +0000 Subject: [freetds] Build completed: freetds 948 Message-ID: <20171012081800.126086.2BEB6D4C04EF7ED5@appveyor.com> From sf at 4js.com Mon Oct 23 07:44:33 2017 From: sf at 4js.com (Sebastien FLAESCH) Date: Mon, 23 Oct 2017 13:44:33 +0200 Subject: [freetds] Using Fast Forward cursors (SQL_CO_FFO) Message-ID: <0e2f5a79-6afd-4293-0282-b988d5503e15@4js.com> Hi all, It appears that the cursor option SQL_CO_FFO is not defined in odbcss.h. This can be set with SQLSetStmtAttr() using SQL_SOPT_SS_CURSOR_OPTIONS, to get fast forward cursors. Will this be supported by FreeTDS? Seb From lacak at zoznam.sk Wed Oct 25 06:38:40 2017 From: lacak at zoznam.sk (LacaK) Date: Wed, 25 Oct 2017 12:38:40 +0200 Subject: [freetds] FreeTDS and buffering on client side Message-ID: <6bbf7c78-4347-c7a8-7a83-76dbb7131c5b@zoznam.sk> Hi *, I would like to ask how FreeTDS performs buffering on client side. I use dblib as my client library (I do not set there DBBUFFER using "dbsetopt") I am trying simulate network failure in such way: 1. connect to MS SQL Server using dbopen() 2. I send SQL select using dbcmd(), dbsqlexec() 3. then I call dbresults() 4. here I pause program and unplug network cable to simulate network error 5. next I process rows in loop calling dbnextrow() Strange thing is that I can perform step 5 also when network cable is unpluged. So I have suspection, that all rows from select are already somewhere on client side. Probably handled already by underlaying libtds ? What is going to happen? Why I can still read rows when there is already broken network connection ? Thanks -Laco. From freddy77 at gmail.com Wed Oct 25 10:11:30 2017 From: freddy77 at gmail.com (Frediano Ziglio) Date: Wed, 25 Oct 2017 15:11:30 +0100 Subject: [freetds] FreeTDS and buffering on client side In-Reply-To: <6bbf7c78-4347-c7a8-7a83-76dbb7131c5b@zoznam.sk> References: <6bbf7c78-4347-c7a8-7a83-76dbb7131c5b@zoznam.sk> Message-ID: 2017-10-25 11:38 GMT+01:00 LacaK : > Hi *, > > I would like to ask how FreeTDS performs buffering on client side. > I use dblib as my client library (I do not set there DBBUFFER using > "dbsetopt") > > I am trying simulate network failure in such way: > 1. connect to MS SQL Server using dbopen() > 2. I send SQL select using dbcmd(), dbsqlexec() > 3. then I call dbresults() > 4. here I pause program and unplug network cable to simulate network error > 5. next I process rows in loop calling dbnextrow() > > Strange thing is that I can perform step 5 also when network cable is > unpluged. So I have suspection, that all rows from select are already > somewhere on client side. Probably handled already by underlaying libtds ? > > What is going to happen? Why I can still read rows when there is already > broken network connection ? > Thanks > > -Laco. > There are a lot of caching in between. The server execute the query and starts sending back results. Probably the results you are expecting are already sent by the server when you disconnect the cable and are in the tcp socket buffer ready to be parsed from your program. Try to return 1000000 rows and at some point the program will fail (unless connection is really fast and network buffer is big enough!). Frediano From lacak at zoznam.sk Thu Oct 26 02:14:20 2017 From: lacak at zoznam.sk (LacaK) Date: Thu, 26 Oct 2017 08:14:20 +0200 Subject: [freetds] FreeTDS and buffering on client side In-Reply-To: References: <6bbf7c78-4347-c7a8-7a83-76dbb7131c5b@zoznam.sk> Message-ID: Thank you very much Frediano, now , when I increase number of rows in table I can reproduce network failure. But behavior is other than I have expected. I was expecting, that dbnextrow() will return FAIL, but it seems, that call to dbnextrow() never returns ... it freezes somewhere in dblib.dll (I can not debug more because I use dblib.dll from Pascal program) Is it expected behavior? L. > 2017-10-25 11:38 GMT+01:00 LacaK : >> Hi *, >> >> I would like to ask how FreeTDS performs buffering on client side. >> I use dblib as my client library (I do not set there DBBUFFER using >> "dbsetopt") >> >> I am trying simulate network failure in such way: >> 1. connect to MS SQL Server using dbopen() >> 2. I send SQL select using dbcmd(), dbsqlexec() >> 3. then I call dbresults() >> 4. here I pause program and unplug network cable to simulate network error >> 5. next I process rows in loop calling dbnextrow() >> >> Strange thing is that I can perform step 5 also when network cable is >> unpluged. So I have suspection, that all rows from select are already >> somewhere on client side. Probably handled already by underlaying libtds ? >> >> What is going to happen? Why I can still read rows when there is already >> broken network connection ? >> Thanks >> >> -Laco. >> > There are a lot of caching in between. > The server execute the query and starts sending back results. > Probably the results you are expecting are already sent by the server > when you disconnect the cable and are in the tcp socket buffer ready > to be parsed from your program. Try to return 1000000 rows and at > some point the program will fail (unless connection is really fast and > network buffer is big enough!). > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds > From dsgrillo at gmail.com Wed Oct 25 10:11:25 2017 From: dsgrillo at gmail.com (Diogo de Araujo Sgrillo) Date: Wed, 25 Oct 2017 16:11:25 +0200 Subject: [freetds] SQL Server error not being raised to PHP Message-ID: Hi, I?m not completely sure this is an FreeTDS issue, but I have no more ideas what it could be. We developed a system a few months ago using PHP and MySQL. Recently, it was migrated to SQL Server and some issues started to appear. We have a middleware which starts a transaction at the beginning of request, and commit if no exception is caught. Some requests started to crash PHP ? and the errors were hard to track because I think FreeTDS is swallowing them. If the request causes some specific kind of SQL error (not every kind), the transaction is rolled back before the ROLLBACK command is issued by PHP ? and when PHP sends the rollback it prints ?The COMMIT TRANSACTION request has no corresponding BEGIN TRANSACTION? on log and the PHP process crashes. Notes: tsql ?C: Compile-time settings (established with the "configure" script) Version: freetds v1.00.55 freetds.conf directory: /usr/local/Cellar/freetds/1.00.55/etc MS db-lib source compatibility: no Sybase binary compatibility: no Thread safety: yes iconv library: yes TDS version: 7.3 iODBC: no unixodbc: no SSPI "trusted" logins: no Kerberos: no OpenSSL: yes GnuTLS: no MARS: no I?m running PHP 5.6 on a MacOS, and it is a SQL Server 2017 running on Docker (https://hub.docker.com/r/microsoft/mssql-server-linux/) PDO::ATTR_ERRMODE is set to PDO::ERRMODE_EXCEPTION (some other SQL Server errors are being raised.) I'm using pdo_dblib to connect. How to reproduce: create table funcionario (FUN_ID int); insert into table a (1); select FUN_ID from funcionario where FUN_ID = ?a?; -- doesn?t raise an exception to PHP, although the error is printed in freetds.log. If I start a transaction before, and commit it after ? the commit will break and PHP process will crash. tdsdump: 16:51:56.475861 79248 (packet.c:742):Sending packet 0000 01 01 00 82 00 00 01 00-16 00 00 00 12 00 00 00 |........ ........| 0010 02 00 00 00 00 00 00 00-00 00 01 00 00 00 73 00 |........ ......s.| 0020 65 00 6c 00 65 00 63 00-74 00 20 00 46 00 55 00 |e.l.e.c. t. .F.U.| 0030 4e 00 5f 00 49 00 44 00-20 00 66 00 72 00 6f 00 |N._.I.D. .f.r.o.| 0040 6d 00 20 00 66 00 75 00-6e 00 63 00 69 00 6f 00 |m. .f.u. n.c.i.o.| 0050 6e 00 61 00 72 00 69 00-6f 00 20 00 77 00 68 00 |n.a.r.i. o. .w.h.| 0060 65 00 72 00 65 00 20 00-46 00 55 00 4e 00 5f 00 |e.r.e. . F.U.N._.| 0070 49 00 44 00 20 00 3d 00-20 00 27 00 61 00 27 00 |I.D. .=. .'.a.'.| 0080 20 00 - | .| 16:51:56.475906 79248 (dblib.c:4657):dbsqlok(0x7ffe57592d10) 16:51:56.475926 79248 (dblib.c:4686):dbsqlok() not done, calling tds_process_tokens() 16:51:56.475939 79248 (token.c:532):tds_process_tokens(0x7ffe57591f70, 0x7fff59ce595c, 0x7fff59ce596c, 0x6914) 16:51:56.475947 79248 (util.c:165):Changed query state from PENDING to READING 16:51:56.477510 79248 (packet.c:640):Received packet 0000 04 01 00 e7 00 34 01 00-81 01 00 00 00 00 00 08 |...?.4.. ........| 0010 00 38 06 46 00 55 00 4e-00 5f 00 49 00 44 00 aa |.8.F.U.N ._.I.D.?| 0020 b8 00 f5 00 00 00 01 10-49 00 43 00 6f 00 6e 00 |?.?..... I.C.o.n.| 0030 76 00 65 00 72 00 73 00-69 00 6f 00 6e 00 20 00 |v.e.r.s. i.o.n. .| 0040 66 00 61 00 69 00 6c 00-65 00 64 00 20 00 77 00 |f.a.i.l. e.d. .w.| 0050 68 00 65 00 6e 00 20 00-63 00 6f 00 6e 00 76 00 |h.e.n. . c.o.n.v.| 0060 65 00 72 00 74 00 69 00-6e 00 67 00 20 00 74 00 |e.r.t.i. n.g. .t.| 0070 68 00 65 00 20 00 76 00-61 00 72 00 63 00 68 00 |h.e. .v. a.r.c.h.| 0080 61 00 72 00 20 00 76 00-61 00 6c 00 75 00 65 00 |a.r. .v. a.l.u.e.| 0090 20 00 27 00 61 00 27 00-20 00 74 00 6f 00 20 00 | .'.a.'. .t.o. .| 00a0 64 00 61 00 74 00 61 00-20 00 74 00 79 00 70 00 |d.a.t.a. .t.y.p.| 00b0 65 00 20 00 69 00 6e 00-74 00 2e 00 0c 32 00 32 |e. .i.n. t....2.2| 00c0 00 37 00 63 00 64 00 39-00 38 00 32 00 35 00 39 |.7.c.d.9 .8.2.5.9| 00d0 00 63 00 34 00 00 01 00-00 00 fd 02 00 c1 00 00 |.c.4.... ..?..?..| 00e0 00 00 00 00 00 00 00 - |.......| 16:51:56.477593 79248 (token.c:547):processing result tokens. marker is 81(TDS7_RESULT) 16:51:56.477602 79248 (token.c:1554):processing TDS7 result metadata. 16:51:56.477607 79248 (mem.c:651):tds_free_all_results() 16:51:56.477613 79248 (token.c:1579):set current_results (1 column) to tds->res_info 16:51:56.477618 79248 (token.c:1586):setting up 1 columns 16:51:56.477635 79248 (token.c:1523):tds7_get_data_info: colname = FUN_ID type = 56 (int) server's type = 56 (int) column_varint_size = 0 column_size = 4 (4 on server) 16:51:56.477644 79248 (token.c:1597): name size/wsize type/wtype utype 16:51:56.477651 79248 (token.c:1598): -------------------- --------------- --------------- ------- 16:51:56.477658 79248 (token.c:1603): FUN_ID 4/4 56/56 0 16:51:56.477665 79248 (util.c:165):Changed query state from READING to PENDING 16:51:56.477673 79248 (dblib.c:4712):dbsqlok() found result token 16:51:56.477680 79248 (dblib.c:1700):dbresults(0x7ffe57592d10) 16:51:56.477687 79248 (dblib.c:1705):dbresults: dbresults_state is 1 (_DB_RES_RESULTSET_EMPTY) 16:51:56.477693 79248 (token.c:532):tds_process_tokens(0x7ffe57591f70, 0x7fff59ce591c, 0x7fff59ce5918, 0x6914) 16:51:56.477700 79248 (util.c:165):Changed query state from PENDING to READING 16:51:56.477708 79248 (token.c:547):processing result tokens. marker is aa(ERROR) 16:51:56.477722 79248 (token.c:132):tds_process_default_tokens() marker is aa(ERROR) 16:51:56.477735 79248 (token.c:2345):tds_process_info() reading message 245 from server 16:51:56.477748 79248 (token.c:2417):tds_process_info() calling client msg handler 16:51:56.477755 79248 (dbutil.c:74):_dblib_handle_info_message(0x7ffe57700110, 0x7ffe57591f70, 0x7fff59ce5790) 16:51:56.477761 79248 (dbutil.c:75):msgno 245: "Conversion failed when converting the varchar value 'a' to data type int." 16:51:56.477768 79248 (dblib.c:5797):dbgetuserdata(0x7ffe57592d10) 16:51:56.477776 79248 (dblib.c:5797):dbgetuserdata(0x7ffe57592d10) 16:51:56.477787 79248 (token.c:2434):tds_process_info() returning TDS_SUCCESS 16:51:56.477794 79248 (token.c:547):processing result tokens. marker is fd(DONE) 16:51:56.477800 79248 (token.c:2082):tds_process_end: more_results = 0 was_cancelled = 0 error = 1 done_count_valid = 0 16:51:56.477807 79248 (token.c:2099): rows_affected = 0 16:51:56.477814 79248 (token.c:2102):tds_process_end() state set to TDS_IDLE 16:51:56.477820 79248 (util.c:165):Changed query state from READING to IDLE 16:51:56.477826 79248 (util.c:83):logic error: cannot change query state from IDLE to PENDING 16:51:56.477832 79248 (util.c:165):Changed query state from IDLE to IDLE 16:51:56.477838 79248 (dblib.c:1726):dbresults() tds_process_tokens returned 0 (TDS_SUCCESS), result_type TDS_DONE_RESULT 16:51:56.477845 79248 (dblib.c:1753):dbresults(): dbresults_state is 1 (_DB_RES_RESULTSET_EMPTY) 16:51:56.477851 79248 (dblib.c:1689):dbresults returning 1 (SUCCEED) 16:51:56.477858 79248 (dblib.c:2791):dbcount(0x7ffe57592d10) 16:51:56.477864 79248 (dblib.c:1840):dbnumcols(0x7ffe57592d10) 16:51:56.477870 79248 (dblib.c:2791):dbcount(0x7ffe57592d10) 16:51:56.477876 79248 (dblib.c:1840):dbnumcols(0x7ffe57592d10) 16:51:56.477883 79248 (dblib.c:1866):dbcolname(0x7ffe57592d10, 1) 16:51:56.477887 79248 (dblib.c:3063):dbcollen(0x7ffe57592d10, 1) 16:51:56.477911 79248 (dblib.c:2049):dbnextrow(0x7ffe57592d10) 16:51:56.477916 79248 (dblib.c:2055):dbnextrow() dbresults_state = 3 (_DB_RES_NEXT_RESULT) 16:51:56.477920 79248 (dblib.c:2060):leaving dbnextrow() returning -2 (NO_MORE_ROWS) 16:51:56.524837 79248 (dblib.c:1476):dbclose(0x7ffe57592d10) 16:51:56.524865 79248 (dblib.c:241):dblib_del_connection(0x106cdf0e0, 0x7ffe57591f70) 16:51:56.524874 79248 (query.c:3796):tds_disconnect() 16:51:56.524939 79248 (util.c:165):Changed query state from IDLE to DEAD 16:51:56.524950 79248 (mem.c:651):tds_free_all_results() 16:51:56.532415 79248 (dblib.c:288):dblib_release_tds_ctx(1) 16:51:56.532457 79248 (dblib.c:5901):dbfreebuf(0x7ffe57592d10) 16:51:56.532467 79248 (dblib.c:749):dbloginfree(0x7ffe575be6b0) select FUN_ID from funcionario where FUN_ID = ?a? OR FUN_ID = 1; -- same as before ? returns an empty result set select FUN_ID from unexistingTable; -- **raise** an exception to PHP and prints the error in freetds.log Hope you can help. Sincerely, Diogo Sgrillo From freddy77 at gmail.com Thu Oct 26 04:20:09 2017 From: freddy77 at gmail.com (Frediano Ziglio) Date: Thu, 26 Oct 2017 09:20:09 +0100 Subject: [freetds] FreeTDS and buffering on client side In-Reply-To: References: <6bbf7c78-4347-c7a8-7a83-76dbb7131c5b@zoznam.sk> Message-ID: 2017-10-26 7:14 GMT+01:00 LacaK : > Thank you very much Frediano, > > now , when I increase number of rows in table I can reproduce network > failure. > > But behavior is other than I have expected. > > I was expecting, that dbnextrow() will return FAIL, but it seems, that call > to dbnextrow() never returns ... it freezes somewhere in dblib.dll > (I can not debug more because I use dblib.dll from Pascal program) > > Is it expected behavior? > > L. > No, should return an error. TDSDUMP could help. Frediano >> 2017-10-25 11:38 GMT+01:00 LacaK : >>> >>> Hi *, >>> >>> I would like to ask how FreeTDS performs buffering on client side. >>> I use dblib as my client library (I do not set there DBBUFFER using >>> "dbsetopt") >>> >>> I am trying simulate network failure in such way: >>> 1. connect to MS SQL Server using dbopen() >>> 2. I send SQL select using dbcmd(), dbsqlexec() >>> 3. then I call dbresults() >>> 4. here I pause program and unplug network cable to simulate network >>> error >>> 5. next I process rows in loop calling dbnextrow() >>> >>> Strange thing is that I can perform step 5 also when network cable is >>> unpluged. So I have suspection, that all rows from select are already >>> somewhere on client side. Probably handled already by underlaying libtds >>> ? >>> >>> What is going to happen? Why I can still read rows when there is already >>> broken network connection ? >>> Thanks >>> >>> -Laco. >>> >> There are a lot of caching in between. >> The server execute the query and starts sending back results. >> Probably the results you are expecting are already sent by the server >> when you disconnect the cable and are in the tcp socket buffer ready >> to be parsed from your program. Try to return 1000000 rows and at >> some point the program will fail (unless connection is really fast and >> network buffer is big enough!). >> >> Frediano >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> https://lists.ibiblio.org/mailman/listinfo/freetds >> > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds From lacak at zoznam.sk Thu Oct 26 04:40:31 2017 From: lacak at zoznam.sk (LacaK) Date: Thu, 26 Oct 2017 10:40:31 +0200 Subject: [freetds] FreeTDS and buffering on client side In-Reply-To: References: <6bbf7c78-4347-c7a8-7a83-76dbb7131c5b@zoznam.sk> Message-ID: <55fd45f0-cd12-d48e-9581-74502af934fb@zoznam.sk> >> Thank you very much Frediano, >> >> now , when I increase number of rows in table I can reproduce network >> failure. >> >> But behavior is other than I have expected. >> >> I was expecting, that dbnextrow() will return FAIL, but it seems, that call >> to dbnextrow() never returns ... it freezes somewhere in dblib.dll >> (I can not debug more because I use dblib.dll from Pascal program) >> >> Is it expected behavior? >> >> L. >> > No, should return an error. > TDSDUMP could help. I have recompiled dblib from todays git master to ensure that problem persist. And yes persists. When rows are reading in loop and I unplug network cable loop stops. When I plug-in cable in few seconds loop continues and rows are returned. But when I unplug for longer time say 1 minute loop does not continue and program freezes. Then I must force end of program. Here are last lines in tdsdump (nothing special IMO): Whole dump has 265MB (as I transfer big rows with TEXT fields) 10:29:32.620 (dblib.c:2064):dbnextrow(032F9D10) 10:29:32.620 (dblib.c:2070):dbnextrow() dbresults_state = 2 (_DB_RES_RESULTSET_ROWS) 10:29:32.620 (token.c:532):tds_process_tokens(032F14A8, 015BFDE0, 00000000, 0x1508) 10:29:32.620 (util.c:165):Changed query state from PENDING to READING 10:29:32.620 (token.c:547):processing result tokens. marker is d2(NBC_ROW) 10:29:32.620 (token.c:1969):tds_process_nbcrow(): reading column 0 10:29:32.620 (data.c:740):tds_get_data: type 56, varint size 0 10:29:32.620 (data.c:784):tds_get_data(): wire column size is 4 10:29:32.620 (token.c:1969):tds_process_nbcrow(): reading column 1 10:29:32.620 (data.c:740):tds_get_data: type 56, varint size 0 10:29:32.620 (data.c:784):tds_get_data(): wire column size is 4 10:29:32.620 (token.c:1969):tds_process_nbcrow(): reading column 2 10:29:32.620 (data.c:740):tds_get_data: type 39, varint size 2 10:29:32.620 (data.c:784):tds_get_data(): wire column size is 4 10:29:32.620 (token.c:1969):tds_process_nbcrow(): reading column 3 10:29:32.620 (token.c:1969):tds_process_nbcrow(): reading column 4 10:29:32.620 (data.c:740):tds_get_data: type 35, varint size 4 10:29:32.620 (data.c:784):tds_get_data(): wire column size is 5000 10:29:32.620 (packet.c:640):Received packet ...follows binary dump of packet Thank you L. >>>> Hi *, >>>> >>>> I would like to ask how FreeTDS performs buffering on client side. >>>> I use dblib as my client library (I do not set there DBBUFFER using >>>> "dbsetopt") >>>> >>>> I am trying simulate network failure in such way: >>>> 1. connect to MS SQL Server using dbopen() >>>> 2. I send SQL select using dbcmd(), dbsqlexec() >>>> 3. then I call dbresults() >>>> 4. here I pause program and unplug network cable to simulate network >>>> error >>>> 5. next I process rows in loop calling dbnextrow() >>>> >>>> Strange thing is that I can perform step 5 also when network cable is >>>> unpluged. So I have suspection, that all rows from select are already >>>> somewhere on client side. Probably handled already by underlaying libtds >>>> ? >>>> >>>> What is going to happen? Why I can still read rows when there is already >>>> broken network connection ? >>>> Thanks >>>> >>>> -Laco. >>>> >>> There are a lot of caching in between. >>> The server execute the query and starts sending back results. >>> Probably the results you are expecting are already sent by the server >>> when you disconnect the cable and are in the tcp socket buffer ready >>> to be parsed from your program. Try to return 1000000 rows and at >>> some point the program will fail (unless connection is really fast and >>> network buffer is big enough!). >>> >>> Frediano >>> _______________________________________________ >>> FreeTDS mailing list >>> FreeTDS at lists.ibiblio.org >>> https://lists.ibiblio.org/mailman/listinfo/freetds >>> >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> https://lists.ibiblio.org/mailman/listinfo/freetds > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds > From m.becker at spider-software.net Thu Oct 26 05:15:33 2017 From: m.becker at spider-software.net (Michael Becker) Date: Thu, 26 Oct 2017 11:15:33 +0200 Subject: [freetds] problem with ct_send command in FreeTDS 1.* Message-ID: Hi, starting with FreeTDS 1.00.1 ct_send works as follows: ------------------- CS_RETCODE ct_send(CS_COMMAND * cmd) { ... if (cmd->command_type == CS_DYNAMIC_CMD) { ... switch (cmd->dynamic_cmd) { ... case CS_EXECUTE: ... if (!pparam_info) return CS_FAIL; ... ------------------- The check "if (!pparam_info)" is added in version 1, up to 0.95.95 pparam_info was allowed to be NULL. This behaviour runs into an error if ct_send is performed on a cursor having bind arguments only. Without this check it's working fine. So please remove this check. Regards: Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: m_becker.vcf Type: text/x-vcard Size: 135 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From lacak at zoznam.sk Fri Oct 27 08:37:48 2017 From: lacak at zoznam.sk (LacaK) Date: Fri, 27 Oct 2017 14:37:48 +0200 Subject: [freetds] FreeTDS and buffering on client side In-Reply-To: <55fd45f0-cd12-d48e-9581-74502af934fb@zoznam.sk> References: <6bbf7c78-4347-c7a8-7a83-76dbb7131c5b@zoznam.sk> <55fd45f0-cd12-d48e-9581-74502af934fb@zoznam.sk> Message-ID: <41ee2f99-c309-53fe-f21a-e1b9b4707749@zoznam.sk> Same behavior also on Windows (current master) and on Linux (Ubuntu with installed libsybdb5 package) Once network cable is unpluged loop freezes and FAIL is not returned from dbnextrow() So I think, that it is reproducible case ... L. > >>> Thank you very much Frediano, >>> >>> now , when I increase number of rows in table I can reproduce network >>> failure. >>> >>> But behavior is other than I have expected. >>> >>> I was expecting, that dbnextrow() will return FAIL, but it seems, >>> that call >>> to dbnextrow() never returns ... it freezes somewhere in dblib.dll >>> (I can not debug more because I use dblib.dll from Pascal program) >>> >>> Is it expected behavior? >>> >>> L. >>> >> No, should return an error. >> TDSDUMP could help. > I have recompiled dblib from todays git master to ensure that problem > persist. > And yes persists. > When rows are reading in loop and I unplug network cable loop stops. > When I plug-in cable in few seconds loop continues and rows are returned. > But when I unplug for longer time say 1 minute loop does not continue > and program freezes. > > Then I must force end of program. Here are last lines in tdsdump > (nothing special IMO): > Whole dump has 265MB (as I transfer big rows with TEXT fields) > > 10:29:32.620 (dblib.c:2064):dbnextrow(032F9D10) > 10:29:32.620 (dblib.c:2070):dbnextrow() dbresults_state = 2 > (_DB_RES_RESULTSET_ROWS) > 10:29:32.620 (token.c:532):tds_process_tokens(032F14A8, 015BFDE0, > 00000000, 0x1508) > 10:29:32.620 (util.c:165):Changed query state from PENDING to READING > 10:29:32.620 (token.c:547):processing result tokens. marker is > d2(NBC_ROW) > 10:29:32.620 (token.c:1969):tds_process_nbcrow(): reading column 0 > 10:29:32.620 (data.c:740):tds_get_data: type 56, varint size 0 > 10:29:32.620 (data.c:784):tds_get_data(): wire column size is 4 > 10:29:32.620 (token.c:1969):tds_process_nbcrow(): reading column 1 > 10:29:32.620 (data.c:740):tds_get_data: type 56, varint size 0 > 10:29:32.620 (data.c:784):tds_get_data(): wire column size is 4 > 10:29:32.620 (token.c:1969):tds_process_nbcrow(): reading column 2 > 10:29:32.620 (data.c:740):tds_get_data: type 39, varint size 2 > 10:29:32.620 (data.c:784):tds_get_data(): wire column size is 4 > 10:29:32.620 (token.c:1969):tds_process_nbcrow(): reading column 3 > 10:29:32.620 (token.c:1969):tds_process_nbcrow(): reading column 4 > 10:29:32.620 (data.c:740):tds_get_data: type 35, varint size 4 > 10:29:32.620 (data.c:784):tds_get_data(): wire column size is 5000 > 10:29:32.620 (packet.c:640):Received packet > ...follows binary dump of packet > > Thank you > L. >>>>> Hi *, >>>>> >>>>> I would like to ask how FreeTDS performs buffering on client side. >>>>> I use dblib as my client library (I do not set there DBBUFFER using >>>>> "dbsetopt") >>>>> >>>>> I am trying simulate network failure in such way: >>>>> 1. connect to MS SQL Server using dbopen() >>>>> 2. I send SQL select using dbcmd(), dbsqlexec() >>>>> 3. then I call dbresults() >>>>> 4. here I pause program and unplug network cable to simulate network >>>>> error >>>>> 5. next I process rows in loop calling dbnextrow() >>>>> >>>>> Strange thing is that I can perform step 5 also when network cable is >>>>> unpluged. So I have suspection, that all rows from select are already >>>>> somewhere on client side. Probably handled already by underlaying >>>>> libtds >>>>> ? >>>>> >>>>> What is going to happen? Why I can still read rows when there is >>>>> already >>>>> broken network connection ? >>>>> Thanks >>>>> >>>>> -Laco. >>>>> >>>> There are a lot of caching in between. >>>> The server execute the query and starts sending back results. >>>> Probably the results you are expecting are already sent by the server >>>> when you disconnect the cable and are in the tcp socket buffer ready >>>> to be parsed from your program. Try to return 1000000 rows and at >>>> some point the program will fail (unless connection is really fast and >>>> network buffer is big enough!). >>>> >>>> Frediano >>>> _______________________________________________ >>>> FreeTDS mailing list >>>> FreeTDS at lists.ibiblio.org >>>> https://lists.ibiblio.org/mailman/listinfo/freetds >>>> >>> _______________________________________________ >>> FreeTDS mailing list >>> FreeTDS at lists.ibiblio.org >>> https://lists.ibiblio.org/mailman/listinfo/freetds >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> https://lists.ibiblio.org/mailman/listinfo/freetds >> > From freddy77 at gmail.com Sun Oct 29 05:01:02 2017 From: freddy77 at gmail.com (Frediano Ziglio) Date: Sun, 29 Oct 2017 09:01:02 +0000 Subject: [freetds] FreeTDS and buffering on client side In-Reply-To: <41ee2f99-c309-53fe-f21a-e1b9b4707749@zoznam.sk> References: <6bbf7c78-4347-c7a8-7a83-76dbb7131c5b@zoznam.sk> <55fd45f0-cd12-d48e-9581-74502af934fb@zoznam.sk> <41ee2f99-c309-53fe-f21a-e1b9b4707749@zoznam.sk> Message-ID: I cannot reproduce, for me I get an error. What are you doing in your error/message callback? Frediano 2017-10-27 13:37 GMT+01:00 LacaK : > Same behavior also on Windows (current master) and on Linux (Ubuntu with > installed libsybdb5 package) > Once network cable is unpluged loop freezes and FAIL is not returned from > dbnextrow() > > So I think, that it is reproducible case ... > > L. > > > >> >>>> Thank you very much Frediano, >>>> >>>> now , when I increase number of rows in table I can reproduce network >>>> failure. >>>> >>>> But behavior is other than I have expected. >>>> >>>> I was expecting, that dbnextrow() will return FAIL, but it seems, that >>>> call >>>> to dbnextrow() never returns ... it freezes somewhere in dblib.dll >>>> (I can not debug more because I use dblib.dll from Pascal program) >>>> >>>> Is it expected behavior? >>>> >>>> L. >>>> >>> No, should return an error. >>> TDSDUMP could help. >> >> I have recompiled dblib from todays git master to ensure that problem >> persist. >> And yes persists. >> When rows are reading in loop and I unplug network cable loop stops. >> When I plug-in cable in few seconds loop continues and rows are returned. >> But when I unplug for longer time say 1 minute loop does not continue and >> program freezes. >> >> Then I must force end of program. Here are last lines in tdsdump (nothing >> special IMO): >> Whole dump has 265MB (as I transfer big rows with TEXT fields) >> >> 10:29:32.620 (dblib.c:2064):dbnextrow(032F9D10) >> 10:29:32.620 (dblib.c:2070):dbnextrow() dbresults_state = 2 >> (_DB_RES_RESULTSET_ROWS) >> 10:29:32.620 (token.c:532):tds_process_tokens(032F14A8, 015BFDE0, >> 00000000, 0x1508) >> 10:29:32.620 (util.c:165):Changed query state from PENDING to READING >> 10:29:32.620 (token.c:547):processing result tokens. marker is >> d2(NBC_ROW) >> 10:29:32.620 (token.c:1969):tds_process_nbcrow(): reading column 0 >> 10:29:32.620 (data.c:740):tds_get_data: type 56, varint size 0 >> 10:29:32.620 (data.c:784):tds_get_data(): wire column size is 4 >> 10:29:32.620 (token.c:1969):tds_process_nbcrow(): reading column 1 >> 10:29:32.620 (data.c:740):tds_get_data: type 56, varint size 0 >> 10:29:32.620 (data.c:784):tds_get_data(): wire column size is 4 >> 10:29:32.620 (token.c:1969):tds_process_nbcrow(): reading column 2 >> 10:29:32.620 (data.c:740):tds_get_data: type 39, varint size 2 >> 10:29:32.620 (data.c:784):tds_get_data(): wire column size is 4 >> 10:29:32.620 (token.c:1969):tds_process_nbcrow(): reading column 3 >> 10:29:32.620 (token.c:1969):tds_process_nbcrow(): reading column 4 >> 10:29:32.620 (data.c:740):tds_get_data: type 35, varint size 4 >> 10:29:32.620 (data.c:784):tds_get_data(): wire column size is 5000 >> 10:29:32.620 (packet.c:640):Received packet >> ...follows binary dump of packet >> >> Thank you >> L. >>>>>> >>>>>> Hi *, >>>>>> >>>>>> I would like to ask how FreeTDS performs buffering on client side. >>>>>> I use dblib as my client library (I do not set there DBBUFFER using >>>>>> "dbsetopt") >>>>>> >>>>>> I am trying simulate network failure in such way: >>>>>> 1. connect to MS SQL Server using dbopen() >>>>>> 2. I send SQL select using dbcmd(), dbsqlexec() >>>>>> 3. then I call dbresults() >>>>>> 4. here I pause program and unplug network cable to simulate network >>>>>> error >>>>>> 5. next I process rows in loop calling dbnextrow() >>>>>> >>>>>> Strange thing is that I can perform step 5 also when network cable is >>>>>> unpluged. So I have suspection, that all rows from select are already >>>>>> somewhere on client side. Probably handled already by underlaying >>>>>> libtds >>>>>> ? >>>>>> >>>>>> What is going to happen? Why I can still read rows when there is >>>>>> already >>>>>> broken network connection ? >>>>>> Thanks >>>>>> >>>>>> -Laco. >>>>>> >>>>> There are a lot of caching in between. >>>>> The server execute the query and starts sending back results. >>>>> Probably the results you are expecting are already sent by the server >>>>> when you disconnect the cable and are in the tcp socket buffer ready >>>>> to be parsed from your program. Try to return 1000000 rows and at >>>>> some point the program will fail (unless connection is really fast and >>>>> network buffer is big enough!). >>>>> >>>>> Frediano >>>>> _______________________________________________ >>>>> FreeTDS mailing list >>>>> FreeTDS at lists.ibiblio.org >>>>> https://lists.ibiblio.org/mailman/listinfo/freetds >>>>> >>>> _______________________________________________ >>>> FreeTDS mailing list >>>> FreeTDS at lists.ibiblio.org >>>> https://lists.ibiblio.org/mailman/listinfo/freetds >>> >>> _______________________________________________ >>> FreeTDS mailing list >>> FreeTDS at lists.ibiblio.org >>> https://lists.ibiblio.org/mailman/listinfo/freetds >>> >> > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds From peterd at iea-software.com Sun Oct 29 12:38:34 2017 From: peterd at iea-software.com (Peter Deacon) Date: Sun, 29 Oct 2017 09:38:34 -0700 (Pacific Daylight Time) Subject: [freetds] FreeTDS and buffering on client side In-Reply-To: <41ee2f99-c309-53fe-f21a-e1b9b4707749@zoznam.sk> References: <6bbf7c78-4347-c7a8-7a83-76dbb7131c5b@zoznam.sk> <55fd45f0-cd12-d48e-9581-74502af934fb@zoznam.sk> <41ee2f99-c309-53fe-f21a-e1b9b4707749@zoznam.sk> Message-ID: On Fri, 27 Oct 2017, LacaK wrote: > Same behavior also on Windows (current master) and on Linux (Ubuntu with > installed libsybdb5 package) Once network cable is unpluged loop freezes > and FAIL is not returned from dbnextrow() > So I think, that it is reproducible case ... Some systems depending on configuration when physical link is lost actively close logical interface and associated sockets. These systems should return an error right away. Some do nothing. The difference you are seeing in your testing after waiting longer than a certain period is a result of server side of the session giving up and shutting down the TCP session. Under your test condition the client is likely to have no idea this has occurred. All it knows is more data may or may not arrive at some undetermined point in the future. With TCP a client can find out in one of three ways: 1. Something is transmitted over TCP session such as request for more data or app layer keep-alive - at which point lack of connectivity is detected when transmission timeout expires. 2. A TCP layer keep-alive fires off and time outs. On windows the default keep-alive interval is 2 hours. 3. Local application timeout such as a configured query timeout? Otherwise I would expect the application to sit and wait forever for data that may never arrive over a server/network/socket that may no longer exist. On Windows you are likely looking at 2 hours maximum wait before anything times out. On Windows try waiting 2 hours, using a query timeout or sysinternals tcpview/process explorer to force close socket of database session from client process and see if you get an error. regards, Peter From freddy77 at gmail.com Mon Oct 30 04:20:37 2017 From: freddy77 at gmail.com (Frediano Ziglio) Date: Mon, 30 Oct 2017 08:20:37 +0000 Subject: [freetds] FreeTDS and buffering on client side In-Reply-To: References: <6bbf7c78-4347-c7a8-7a83-76dbb7131c5b@zoznam.sk> <55fd45f0-cd12-d48e-9581-74502af934fb@zoznam.sk> <41ee2f99-c309-53fe-f21a-e1b9b4707749@zoznam.sk> Message-ID: 2017-10-29 16:38 GMT+00:00 Peter Deacon : > On Fri, 27 Oct 2017, LacaK wrote: > >> Same behavior also on Windows (current master) and on Linux (Ubuntu with >> installed libsybdb5 package) Once network cable is unpluged loop freezes and >> FAIL is not returned from dbnextrow() > > >> So I think, that it is reproducible case ... > > > Some systems depending on configuration when physical link is lost actively > close logical interface and associated sockets. These systems should return > an error right away. Some do nothing. > > The difference you are seeing in your testing after waiting longer than a > certain period is a result of server side of the session giving up and > shutting down the TCP session. Under your test condition the client is > likely to have no idea this has occurred. All it knows is more data may or > may not arrive at some undetermined point in the future. With TCP a client > can find out in one of three ways: > > 1. Something is transmitted over TCP session such as request for more data > or app layer keep-alive - at which point lack of connectivity is detected > when transmission timeout expires. > > 2. A TCP layer keep-alive fires off and time outs. On windows the default > keep-alive interval is 2 hours. > > 3. Local application timeout such as a configured query timeout? > > Otherwise I would expect the application to sit and wait forever for data > that may never arrive over a server/network/socket that may no longer exist. > On Windows you are likely looking at 2 hours maximum wait before anything > times out. > > On Windows try waiting 2 hours, using a query timeout or sysinternals > tcpview/process explorer to force close socket of database session from > client process and see if you get an error. > > regards, > Peter > You are right. Linux should have a total keep alive or 1 minute. Weird that is not set that way. I think for Windows is not set so yes, default is 2 hours. You can set query timeout of use interrupt. Frediano From cejackson51 at gmail.com Thu Oct 26 13:11:49 2017 From: cejackson51 at gmail.com (Craig Jackson) Date: Thu, 26 Oct 2017 13:11:49 -0400 Subject: [freetds] FreeTDS and buffering on client side In-Reply-To: <55fd45f0-cd12-d48e-9581-74502af934fb@zoznam.sk> References: <6bbf7c78-4347-c7a8-7a83-76dbb7131c5b@zoznam.sk> <55fd45f0-cd12-d48e-9581-74502af934fb@zoznam.sk> Message-ID: How long does it stop? By default, a TCP connection can take as 10 minutes to time out. Are you specifying timeouts on your freetds calls? Craig On Thu, Oct 26, 2017 at 4:40 AM, LacaK wrote: > > Thank you very much Frediano, >>> >>> now , when I increase number of rows in table I can reproduce network >>> failure. >>> >>> But behavior is other than I have expected. >>> >>> I was expecting, that dbnextrow() will return FAIL, but it seems, that >>> call >>> to dbnextrow() never returns ... it freezes somewhere in dblib.dll >>> (I can not debug more because I use dblib.dll from Pascal program) >>> >>> Is it expected behavior? >>> >>> L. >>> >>> No, should return an error. >> TDSDUMP could help. >> > I have recompiled dblib from todays git master to ensure that problem > persist. > And yes persists. > When rows are reading in loop and I unplug network cable loop stops. > When I plug-in cable in few seconds loop continues and rows are returned. > But when I unplug for longer time say 1 minute loop does not continue and > program freezes. > > Then I must force end of program. Here are last lines in tdsdump (nothing > special IMO): > Whole dump has 265MB (as I transfer big rows with TEXT fields) > > 10:29:32.620 (dblib.c:2064):dbnextrow(032F9D10) > 10:29:32.620 (dblib.c:2070):dbnextrow() dbresults_state = 2 > (_DB_RES_RESULTSET_ROWS) > 10:29:32.620 (token.c:532):tds_process_tokens(032F14A8, 015BFDE0, > 00000000, 0x1508) > 10:29:32.620 (util.c:165):Changed query state from PENDING to READING > 10:29:32.620 (token.c:547):processing result tokens. marker is d2(NBC_ROW) > 10:29:32.620 (token.c:1969):tds_process_nbcrow(): reading column 0 > 10:29:32.620 (data.c:740):tds_get_data: type 56, varint size 0 > 10:29:32.620 (data.c:784):tds_get_data(): wire column size is 4 > 10:29:32.620 (token.c:1969):tds_process_nbcrow(): reading column 1 > 10:29:32.620 (data.c:740):tds_get_data: type 56, varint size 0 > 10:29:32.620 (data.c:784):tds_get_data(): wire column size is 4 > 10:29:32.620 (token.c:1969):tds_process_nbcrow(): reading column 2 > 10:29:32.620 (data.c:740):tds_get_data: type 39, varint size 2 > 10:29:32.620 (data.c:784):tds_get_data(): wire column size is 4 > 10:29:32.620 (token.c:1969):tds_process_nbcrow(): reading column 3 > 10:29:32.620 (token.c:1969):tds_process_nbcrow(): reading column 4 > 10:29:32.620 (data.c:740):tds_get_data: type 35, varint size 4 > 10:29:32.620 (data.c:784):tds_get_data(): wire column size is 5000 > 10:29:32.620 (packet.c:640):Received packet > ...follows binary dump of packet > > Thank you > L. > > Hi *, >>>>> >>>>> I would like to ask how FreeTDS performs buffering on client side. >>>>> I use dblib as my client library (I do not set there DBBUFFER using >>>>> "dbsetopt") >>>>> >>>>> I am trying simulate network failure in such way: >>>>> 1. connect to MS SQL Server using dbopen() >>>>> 2. I send SQL select using dbcmd(), dbsqlexec() >>>>> 3. then I call dbresults() >>>>> 4. here I pause program and unplug network cable to simulate network >>>>> error >>>>> 5. next I process rows in loop calling dbnextrow() >>>>> >>>>> Strange thing is that I can perform step 5 also when network cable is >>>>> unpluged. So I have suspection, that all rows from select are already >>>>> somewhere on client side. Probably handled already by underlaying >>>>> libtds >>>>> ? >>>>> >>>>> What is going to happen? Why I can still read rows when there is >>>>> already >>>>> broken network connection ? >>>>> Thanks >>>>> >>>>> -Laco. >>>>> >>>>> There are a lot of caching in between. >>>> The server execute the query and starts sending back results. >>>> Probably the results you are expecting are already sent by the server >>>> when you disconnect the cable and are in the tcp socket buffer ready >>>> to be parsed from your program. Try to return 1000000 rows and at >>>> some point the program will fail (unless connection is really fast and >>>> network buffer is big enough!). >>>> >>>> Frediano >>>> _______________________________________________ >>>> FreeTDS mailing list >>>> FreeTDS at lists.ibiblio.org >>>> https://lists.ibiblio.org/mailman/listinfo/freetds >>>> >>>> _______________________________________________ >>> FreeTDS mailing list >>> FreeTDS at lists.ibiblio.org >>> https://lists.ibiblio.org/mailman/listinfo/freetds >>> >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> https://lists.ibiblio.org/mailman/listinfo/freetds >> >> > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds > From cwthomas at llu.edu Thu Oct 26 13:48:27 2017 From: cwthomas at llu.edu (Thomas, Christopher (LLU)) Date: Thu, 26 Oct 2017 17:48:27 +0000 Subject: [freetds] SQL Server error not being raised to PHP In-Reply-To: References: Message-ID: Some sample code would be nice. You didn?t mention which API you were using inside PHP. Mssql, odbc, pdo_dblib, something else? Chris -----Original Message----- From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of Diogo de Araujo Sgrillo Sent: Wednesday, October 25, 2017 7:11 AM To: freetds at lists.ibiblio.org Subject: [freetds] SQL Server error not being raised to PHP Hi, I?m not completely sure this is an FreeTDS issue, but I have no more ideas what it could be. We developed a system a few months ago using PHP and MySQL. Recently, it was migrated to SQL Server and some issues started to appear. We have a middleware which starts a transaction at the beginning of request, and commit if no exception is caught. Some requests started to crash PHP ? and the errors were hard to track because I think FreeTDS is swallowing them. If the request causes some specific kind of SQL error (not every kind), the transaction is rolled back before the ROLLBACK command is issued by PHP ? and when PHP sends the rollback it prints ?The COMMIT TRANSACTION request has no corresponding BEGIN TRANSACTION? on log and the PHP process crashes. Notes: tsql ?C: Compile-time settings (established with the "configure" script) Version: freetds v1.00.55 freetds.conf directory: /usr/local/Cellar/freetds/1.00.55/etc MS db-lib source compatibility: no Sybase binary compatibility: no Thread safety: yes iconv library: yes TDS version: 7.3 iODBC: no unixodbc: no SSPI "trusted" logins: no Kerberos: no OpenSSL: yes GnuTLS: no MARS: no I?m running PHP 5.6 on a MacOS, and it is a SQL Server 2017 running on Docker (https://urldefense.proofpoint.com/v2/url?u=https-3A__hub.docker.com_r_microsoft_mssql-2Dserver-2Dlinux_&d=DwIGaQ&c=2au6Wc4YyA9xDf1Xwd-ZHbREYaQgjsJ8ttjU4m7jy4w&r=8C89e7MEyWEPYBkPd60c6w&m=dhxsH-C0EoTeYLWXqyN5i-eDZU0xNyyvTn5j-xdwTrc&s=QJLzOrk09zLKc7gcS0H8C87jZ9aWrdPakoDGxjfwvYc&e= ) PDO::ATTR_ERRMODE is set to PDO::ERRMODE_EXCEPTION (some other SQL Server errors are being raised.) I'm using pdo_dblib to connect. How to reproduce: create table funcionario (FUN_ID int); insert into table a (1); select FUN_ID from funcionario where FUN_ID = ?a?; -- doesn?t raise an exception to PHP, although the error is printed in freetds.log. If I start a transaction before, and commit it after ? the commit will break and PHP process will crash. tdsdump: 16:51:56.475861 79248 (packet.c:742):Sending packet 0000 01 01 00 82 00 00 01 00-16 00 00 00 12 00 00 00 |........ ........| 0010 02 00 00 00 00 00 00 00-00 00 01 00 00 00 73 00 |........ ......s.| 0020 65 00 6c 00 65 00 63 00-74 00 20 00 46 00 55 00 |e.l.e.c. t. .F.U.| 0030 4e 00 5f 00 49 00 44 00-20 00 66 00 72 00 6f 00 |N._.I.D. .f.r.o.| 0040 6d 00 20 00 66 00 75 00-6e 00 63 00 69 00 6f 00 |m. .f.u. n.c.i.o.| 0050 6e 00 61 00 72 00 69 00-6f 00 20 00 77 00 68 00 |n.a.r.i. o. .w.h.| 0060 65 00 72 00 65 00 20 00-46 00 55 00 4e 00 5f 00 |e.r.e. . F.U.N._.| 0070 49 00 44 00 20 00 3d 00-20 00 27 00 61 00 27 00 |I.D. .=. .'.a.'.| 0080 20 00 - | .| 16:51:56.475906 79248 (dblib.c:4657):dbsqlok(0x7ffe57592d10) 16:51:56.475926 79248 (dblib.c:4686):dbsqlok() not done, calling tds_process_tokens() 16:51:56.475939 79248 (token.c:532):tds_process_tokens(0x7ffe57591f70, 0x7fff59ce595c, 0x7fff59ce596c, 0x6914) 16:51:56.475947 79248 (util.c:165):Changed query state from PENDING to READING 16:51:56.477510 79248 (packet.c:640):Received packet 0000 04 01 00 e7 00 34 01 00-81 01 00 00 00 00 00 08 |...?.4.. ........| 0010 00 38 06 46 00 55 00 4e-00 5f 00 49 00 44 00 aa |.8.F.U.N ._.I.D.?| 0020 b8 00 f5 00 00 00 01 10-49 00 43 00 6f 00 6e 00 |?.?..... I.C.o.n.| 0030 76 00 65 00 72 00 73 00-69 00 6f 00 6e 00 20 00 |v.e.r.s. i.o.n. .| 0040 66 00 61 00 69 00 6c 00-65 00 64 00 20 00 77 00 |f.a.i.l. e.d. .w.| 0050 68 00 65 00 6e 00 20 00-63 00 6f 00 6e 00 76 00 |h.e.n. . c.o.n.v.| 0060 65 00 72 00 74 00 69 00-6e 00 67 00 20 00 74 00 |e.r.t.i. n.g. .t.| 0070 68 00 65 00 20 00 76 00-61 00 72 00 63 00 68 00 |h.e. .v. a.r.c.h.| 0080 61 00 72 00 20 00 76 00-61 00 6c 00 75 00 65 00 |a.r. .v. a.l.u.e.| 0090 20 00 27 00 61 00 27 00-20 00 74 00 6f 00 20 00 | .'.a.'. .t.o. .| 00a0 64 00 61 00 74 00 61 00-20 00 74 00 79 00 70 00 |d.a.t.a. .t.y.p.| 00b0 65 00 20 00 69 00 6e 00-74 00 2e 00 0c 32 00 32 |e. .i.n. t....2.2| 00c0 00 37 00 63 00 64 00 39-00 38 00 32 00 35 00 39 |.7.c.d.9 .8.2.5.9| 00d0 00 63 00 34 00 00 01 00-00 00 fd 02 00 c1 00 00 |.c.4.... ..?..?..| 00e0 00 00 00 00 00 00 00 - |.......| 16:51:56.477593 79248 (token.c:547):processing result tokens. marker is 81(TDS7_RESULT) 16:51:56.477602 79248 (token.c:1554):processing TDS7 result metadata. 16:51:56.477607 79248 (mem.c:651):tds_free_all_results() 16:51:56.477613 79248 (token.c:1579):set current_results (1 column) to tds->res_info 16:51:56.477618 79248 (token.c:1586):setting up 1 columns 16:51:56.477635 79248 (token.c:1523):tds7_get_data_info: colname = FUN_ID type = 56 (int) server's type = 56 (int) column_varint_size = 0 column_size = 4 (4 on server) 16:51:56.477644 79248 (token.c:1597): name size/wsize type/wtype utype 16:51:56.477651 79248 (token.c:1598): -------------------- --------------- --------------- ------- 16:51:56.477658 79248 (token.c:1603): FUN_ID 4/4 56/56 0 16:51:56.477665 79248 (util.c:165):Changed query state from READING to PENDING 16:51:56.477673 79248 (dblib.c:4712):dbsqlok() found result token 16:51:56.477680 79248 (dblib.c:1700):dbresults(0x7ffe57592d10) 16:51:56.477687 79248 (dblib.c:1705):dbresults: dbresults_state is 1 (_DB_RES_RESULTSET_EMPTY) 16:51:56.477693 79248 (token.c:532):tds_process_tokens(0x7ffe57591f70, 0x7fff59ce591c, 0x7fff59ce5918, 0x6914) 16:51:56.477700 79248 (util.c:165):Changed query state from PENDING to READING 16:51:56.477708 79248 (token.c:547):processing result tokens. marker is aa(ERROR) 16:51:56.477722 79248 (token.c:132):tds_process_default_tokens() marker is aa(ERROR) 16:51:56.477735 79248 (token.c:2345):tds_process_info() reading message 245 from server 16:51:56.477748 79248 (token.c:2417):tds_process_info() calling client msg handler 16:51:56.477755 79248 (dbutil.c:74):_dblib_handle_info_message(0x7ffe57700110, 0x7ffe57591f70, 0x7fff59ce5790) 16:51:56.477761 79248 (dbutil.c:75):msgno 245: "Conversion failed when converting the varchar value 'a' to data type int." 16:51:56.477768 79248 (dblib.c:5797):dbgetuserdata(0x7ffe57592d10) 16:51:56.477776 79248 (dblib.c:5797):dbgetuserdata(0x7ffe57592d10) 16:51:56.477787 79248 (token.c:2434):tds_process_info() returning TDS_SUCCESS 16:51:56.477794 79248 (token.c:547):processing result tokens. marker is fd(DONE) 16:51:56.477800 79248 (token.c:2082):tds_process_end: more_results = 0 was_cancelled = 0 error = 1 done_count_valid = 0 16:51:56.477807 79248 (token.c:2099): rows_affected = 0 16:51:56.477814 79248 (token.c:2102):tds_process_end() state set to TDS_IDLE 16:51:56.477820 79248 (util.c:165):Changed query state from READING to IDLE 16:51:56.477826 79248 (util.c:83):logic error: cannot change query state from IDLE to PENDING 16:51:56.477832 79248 (util.c:165):Changed query state from IDLE to IDLE 16:51:56.477838 79248 (dblib.c:1726):dbresults() tds_process_tokens returned 0 (TDS_SUCCESS), result_type TDS_DONE_RESULT 16:51:56.477845 79248 (dblib.c:1753):dbresults(): dbresults_state is 1 (_DB_RES_RESULTSET_EMPTY) 16:51:56.477851 79248 (dblib.c:1689):dbresults returning 1 (SUCCEED) 16:51:56.477858 79248 (dblib.c:2791):dbcount(0x7ffe57592d10) 16:51:56.477864 79248 (dblib.c:1840):dbnumcols(0x7ffe57592d10) 16:51:56.477870 79248 (dblib.c:2791):dbcount(0x7ffe57592d10) 16:51:56.477876 79248 (dblib.c:1840):dbnumcols(0x7ffe57592d10) 16:51:56.477883 79248 (dblib.c:1866):dbcolname(0x7ffe57592d10, 1) 16:51:56.477887 79248 (dblib.c:3063):dbcollen(0x7ffe57592d10, 1) 16:51:56.477911 79248 (dblib.c:2049):dbnextrow(0x7ffe57592d10) 16:51:56.477916 79248 (dblib.c:2055):dbnextrow() dbresults_state = 3 (_DB_RES_NEXT_RESULT) 16:51:56.477920 79248 (dblib.c:2060):leaving dbnextrow() returning -2 (NO_MORE_ROWS) 16:51:56.524837 79248 (dblib.c:1476):dbclose(0x7ffe57592d10) 16:51:56.524865 79248 (dblib.c:241):dblib_del_connection(0x106cdf0e0, 0x7ffe57591f70) 16:51:56.524874 79248 (query.c:3796):tds_disconnect() 16:51:56.524939 79248 (util.c:165):Changed query state from IDLE to DEAD 16:51:56.524950 79248 (mem.c:651):tds_free_all_results() 16:51:56.532415 79248 (dblib.c:288):dblib_release_tds_ctx(1) 16:51:56.532457 79248 (dblib.c:5901):dbfreebuf(0x7ffe57592d10) 16:51:56.532467 79248 (dblib.c:749):dbloginfree(0x7ffe575be6b0) select FUN_ID from funcionario where FUN_ID = ?a? OR FUN_ID = 1; -- same as before ? returns an empty result set select FUN_ID from unexistingTable; -- **raise** an exception to PHP and prints the error in freetds.log Hope you can help. Sincerely, Diogo Sgrillo _______________________________________________ FreeTDS mailing list FreeTDS at lists.ibiblio.org https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.ibiblio.org_mailman_listinfo_freetds&d=DwIGaQ&c=2au6Wc4YyA9xDf1Xwd-ZHbREYaQgjsJ8ttjU4m7jy4w&r=8C89e7MEyWEPYBkPd60c6w&m=dhxsH-C0EoTeYLWXqyN5i-eDZU0xNyyvTn5j-xdwTrc&s=qs0aoU8Wz1O8nJ6fnbcK5WgTrRKxMOMEFbAgeufLtDs&e= ________________________________ WARNING: Please be vigilant when opening emails that appear to be the least bit out of the ordinary, e.g. someone you usually don?t hear from, or attachments you usually don?t receive or didn?t expect, requests to click links or log into systems, etc. If you receive suspicious emails, please do not open attachments or links and immediately forward the suspicious email to EmailAbuse at llu.edu and then delete the suspicious email. CONFIDENTIALITY NOTICE: This e-mail communication and any attachments may contain confidential and privileged information for the use of the designated recipients named above. If you are not the intended recipient, you are hereby notified that you have received this communication in error and that any review, disclosure, dissemination, distribution or copying of it or its contents is prohibited. If you have received this communication in error, please notify me immediately by replying to this message and destroy all copies of this communication and any attachments. Thank you. From raj4721 at gmail.com Thu Oct 26 08:38:52 2017 From: raj4721 at gmail.com (Rajesh M) Date: Thu, 26 Oct 2017 18:08:52 +0530 Subject: [freetds] Need help for @table_qualifier Message-ID: Hello Team, Connection from Oracle to MS SQL working fine. But when passing below query like sp_columns @table_name='slcustm_sap', at table_owner='test_owner', at table_qualifier='test_qualifier', at ODBCVer=3 but what is seen by mssql as sp_columns @table_name='slcustm_sap', at table_owner='test_owner', at ODBCVer=3 with no table_qualifier query I have is from where Oracle picks up table_qualifier details 1. odbc.ini 2. init*.ora for DG4ODBC 3. dblink or any other place ? Thanks Raj From raj4721 at gmail.com Sun Oct 29 22:11:41 2017 From: raj4721 at gmail.com (Rajesh) Date: Mon, 30 Oct 2017 07:41:41 +0530 Subject: [freetds] Need help for @table_qualifier In-Reply-To: References: Message-ID: Any update pls ? Thanks, Rajesh > On 26-Oct-2017, at 18:08, Rajesh M wrote: > > Hello Team, > > Connection from Oracle to MS SQL working fine. But when passing below query like > > sp_columns @table_name='slcustm_sap', at table_owner='test_owner', at table_qualifier='test_qualifier', at ODBCVer=3 > > but what is seen by mssql as > > sp_columns @table_name='slcustm_sap', at table_owner='test_owner', at ODBCVer=3 with no table_qualifier > > query I have is from where Oracle picks up table_qualifier details > > 1. odbc.ini 2. init*.ora for DG4ODBC 3. dblink or any other place ? > > Thanks > Raj From zhangjie at beijing101.com Thu Oct 26 04:15:54 2017 From: zhangjie at beijing101.com (zhangjie at beijing101.com) Date: Thu, 26 Oct 2017 16:15:54 +0800 Subject: [freetds] Auto-Re: SQL Server error not being raised to PHP Message-ID: <171026161554f1860509b45af034fb61e8404cbdc5ea@beijing101.com> ??????????????????????????? ?? From zhangjie at beijing101.com Thu Oct 26 05:20:40 2017 From: zhangjie at beijing101.com (zhangjie at beijing101.com) Date: Thu, 26 Oct 2017 17:20:40 +0800 Subject: [freetds] Auto-Re: problem with ct_send command in FreeTDS 1.* Message-ID: <171026172040acb67f4ed61ac772aff05b78ed970538@beijing101.com> ??????????????????????????? ?? From zhangjie at beijing101.com Mon Oct 30 04:21:30 2017 From: zhangjie at beijing101.com (zhangjie at beijing101.com) Date: Mon, 30 Oct 2017 16:21:30 +0800 Subject: [freetds] Auto-Re: Need help for @table_qualifier Message-ID: <1710301621304fbc49d0a87da5f04e83c5a594dbc8b4@beijing101.com> ??????????????????????????? ?? From freddy77 at gmail.com Mon Oct 30 13:43:47 2017 From: freddy77 at gmail.com (Frediano Ziglio) Date: Mon, 30 Oct 2017 17:43:47 +0000 Subject: [freetds] Need help for @table_qualifier In-Reply-To: References: Message-ID: 2017-10-26 13:38 GMT+01:00 Rajesh M : > Hello Team, > > Connection from Oracle to MS SQL working fine. But when passing below query > like > > sp_columns > @table_name='slcustm_sap', at table_owner='test_owner', at table_qualifier='test_qualifier', at ODBCVer=3 > How do you pass this query? Do you have a TDSDUMP? Network trace? Or the query should be generated by FreeTDS ODBC driver? > > but what is seen by mssql as > > sp_columns @table_name='slcustm_sap', at table_owner='test_owner', at ODBCVer=3 > with no table_qualifier > > query I have is from where Oracle picks up table_qualifier details > > 1. odbc.ini 2. init*.ora for DG4ODBC 3. dblink or any other place ? > > Thanks > Raj Frediano From freddy77 at gmail.com Mon Oct 30 13:48:28 2017 From: freddy77 at gmail.com (Frediano Ziglio) Date: Mon, 30 Oct 2017 17:48:28 +0000 Subject: [freetds] FreeTDS and buffering on client side In-Reply-To: References: <6bbf7c78-4347-c7a8-7a83-76dbb7131c5b@zoznam.sk> <55fd45f0-cd12-d48e-9581-74502af934fb@zoznam.sk> Message-ID: 2017-10-26 18:11 GMT+01:00 Craig Jackson : > How long does it stop? By default, a TCP connection can take as 10 minutes > to time out. > When you are just waiting data from the remote end there's no timeout by default. If keep alive is active the client generate some activity that than trigger some timeout. As Peter was saying can be quite long (2 hours on Windows). On Linux we set the keep alive to about 1 minute to support Azure servers (which are behind a stateful firewall). > Are you specifying timeouts on your freetds calls? > > Craig > Frediano > On Thu, Oct 26, 2017 at 4:40 AM, LacaK wrote: > >> >> Thank you very much Frediano, >>>> >>>> now , when I increase number of rows in table I can reproduce network >>>> failure. >>>> >>>> But behavior is other than I have expected. >>>> >>>> I was expecting, that dbnextrow() will return FAIL, but it seems, that >>>> call >>>> to dbnextrow() never returns ... it freezes somewhere in dblib.dll >>>> (I can not debug more because I use dblib.dll from Pascal program) >>>> >>>> Is it expected behavior? >>>> >>>> L. >>>> >>>> No, should return an error. >>> TDSDUMP could help. >>> >> I have recompiled dblib from todays git master to ensure that problem >> persist. >> And yes persists. >> When rows are reading in loop and I unplug network cable loop stops. >> When I plug-in cable in few seconds loop continues and rows are returned. >> But when I unplug for longer time say 1 minute loop does not continue and >> program freezes. >> >> Then I must force end of program. Here are last lines in tdsdump (nothing >> special IMO): >> Whole dump has 265MB (as I transfer big rows with TEXT fields) >> >> 10:29:32.620 (dblib.c:2064):dbnextrow(032F9D10) >> 10:29:32.620 (dblib.c:2070):dbnextrow() dbresults_state = 2 >> (_DB_RES_RESULTSET_ROWS) >> 10:29:32.620 (token.c:532):tds_process_tokens(032F14A8, 015BFDE0, >> 00000000, 0x1508) >> 10:29:32.620 (util.c:165):Changed query state from PENDING to READING >> 10:29:32.620 (token.c:547):processing result tokens. marker is d2(NBC_ROW) >> 10:29:32.620 (token.c:1969):tds_process_nbcrow(): reading column 0 >> 10:29:32.620 (data.c:740):tds_get_data: type 56, varint size 0 >> 10:29:32.620 (data.c:784):tds_get_data(): wire column size is 4 >> 10:29:32.620 (token.c:1969):tds_process_nbcrow(): reading column 1 >> 10:29:32.620 (data.c:740):tds_get_data: type 56, varint size 0 >> 10:29:32.620 (data.c:784):tds_get_data(): wire column size is 4 >> 10:29:32.620 (token.c:1969):tds_process_nbcrow(): reading column 2 >> 10:29:32.620 (data.c:740):tds_get_data: type 39, varint size 2 >> 10:29:32.620 (data.c:784):tds_get_data(): wire column size is 4 >> 10:29:32.620 (token.c:1969):tds_process_nbcrow(): reading column 3 >> 10:29:32.620 (token.c:1969):tds_process_nbcrow(): reading column 4 >> 10:29:32.620 (data.c:740):tds_get_data: type 35, varint size 4 >> 10:29:32.620 (data.c:784):tds_get_data(): wire column size is 5000 >> 10:29:32.620 (packet.c:640):Received packet >> ...follows binary dump of packet >> >> Thank you >> L. >> >> Hi *, >>>>>> >>>>>> I would like to ask how FreeTDS performs buffering on client side. >>>>>> I use dblib as my client library (I do not set there DBBUFFER using >>>>>> "dbsetopt") >>>>>> >>>>>> I am trying simulate network failure in such way: >>>>>> 1. connect to MS SQL Server using dbopen() >>>>>> 2. I send SQL select using dbcmd(), dbsqlexec() >>>>>> 3. then I call dbresults() >>>>>> 4. here I pause program and unplug network cable to simulate network >>>>>> error >>>>>> 5. next I process rows in loop calling dbnextrow() >>>>>> >>>>>> Strange thing is that I can perform step 5 also when network cable is >>>>>> unpluged. So I have suspection, that all rows from select are already >>>>>> somewhere on client side. Probably handled already by underlaying >>>>>> libtds >>>>>> ? >>>>>> >>>>>> What is going to happen? Why I can still read rows when there is >>>>>> already >>>>>> broken network connection ? >>>>>> Thanks >>>>>> >>>>>> -Laco. >>>>>> >>>>>> There are a lot of caching in between. >>>>> The server execute the query and starts sending back results. >>>>> Probably the results you are expecting are already sent by the server >>>>> when you disconnect the cable and are in the tcp socket buffer ready >>>>> to be parsed from your program. Try to return 1000000 rows and at >>>>> some point the program will fail (unless connection is really fast and >>>>> network buffer is big enough!). >>>>> From lacak at zoznam.sk Tue Oct 31 04:36:46 2017 From: lacak at zoznam.sk (LacaK) Date: Tue, 31 Oct 2017 09:36:46 +0100 Subject: [freetds] FreeTDS and buffering on client side In-Reply-To: References: <6bbf7c78-4347-c7a8-7a83-76dbb7131c5b@zoznam.sk> <55fd45f0-cd12-d48e-9581-74502af934fb@zoznam.sk> <41ee2f99-c309-53fe-f21a-e1b9b4707749@zoznam.sk> Message-ID: Hello *, thanks very much for all answers. I can confirm that: 1. when I set query timeout by call to dbsettime() then after specified number of seconds dbnextrow() returns FAIL and error handler is called with 20004 "Read from server failed" (any subsequent call to db-lib function returns 20047 "DB-process is dead or not enabled" 2. when I do not set query timeout and I break TCP connection using "Close connection" in TCPView same as in 1 happens 3. when I set in registry in HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters "KeepAliveTime" (and restart PC) this value is taken as timeout 4. when I do not set registry value and wait 2 hours on Windows same as in 1 happens Thanks again -Laco. > 2017-10-29 16:38 GMT+00:00 Peter Deacon: >> On Fri, 27 Oct 2017, LacaK wrote: >> >>> Same behavior also on Windows (current master) and on Linux (Ubuntu with >>> installed libsybdb5 package) Once network cable is unpluged loop freezes and >>> FAIL is not returned from dbnextrow() >>> So I think, that it is reproducible case ... >> Some systems depending on configuration when physical link is lost actively >> close logical interface and associated sockets. These systems should return >> an error right away. Some do nothing. >> >> The difference you are seeing in your testing after waiting longer than a >> certain period is a result of server side of the session giving up and >> shutting down the TCP session. Under your test condition the client is >> likely to have no idea this has occurred. All it knows is more data may or >> may not arrive at some undetermined point in the future. With TCP a client >> can find out in one of three ways: >> >> 1. Something is transmitted over TCP session such as request for more data >> or app layer keep-alive - at which point lack of connectivity is detected >> when transmission timeout expires. >> >> 2. A TCP layer keep-alive fires off and time outs. On windows the default >> keep-alive interval is 2 hours. >> >> 3. Local application timeout such as a configured query timeout? >> >> Otherwise I would expect the application to sit and wait forever for data >> that may never arrive over a server/network/socket that may no longer exist. >> On Windows you are likely looking at 2 hours maximum wait before anything >> times out. >> >> On Windows try waiting 2 hours, using a query timeout or sysinternals >> tcpview/process explorer to force close socket of database session from >> client process and see if you get an error. >> >> regards, >> Peter >> > You are right. > > Linux should have a total keep alive or 1 minute. Weird that is not > set that way. > I think for Windows is not set so yes, default is 2 hours. > You can set query timeout of use interrupt. > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds > From freddy77 at gmail.com Tue Oct 31 05:10:26 2017 From: freddy77 at gmail.com (Frediano Ziglio) Date: Tue, 31 Oct 2017 09:10:26 +0000 Subject: [freetds] FreeTDS and buffering on client side In-Reply-To: References: <6bbf7c78-4347-c7a8-7a83-76dbb7131c5b@zoznam.sk> <55fd45f0-cd12-d48e-9581-74502af934fb@zoznam.sk> <41ee2f99-c309-53fe-f21a-e1b9b4707749@zoznam.sk> Message-ID: 2017-10-31 8:36 GMT+00:00 LacaK : > Hello *, > > thanks very much for all answers. > > I can confirm that: > > 1. when I set query timeout by call to dbsettime() then after specified > number of seconds dbnextrow() returns FAIL and error handler is called with > 20004 "Read from server failed" (any subsequent call to db-lib function > returns 20047 "DB-process is dead or not enabled" > > 2. when I do not set query timeout and I break TCP connection using "Close > connection" in TCPView same as in 1 happens > > 3. when I set in registry in > HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters "KeepAliveTime" (and > restart PC) this value is taken as timeout > > 4. when I do not set registry value and wait 2 hours on Windows same as in 1 > happens > > Thanks again > > -Laco. > Just merged (backported) a patch to set keep alive values on Windows with similar values to Linux/Unix. Tested with wine. Still not sure why Linux version you have does not use these settings. It's working for me. Frediano > >> 2017-10-29 16:38 GMT+00:00 Peter Deacon: >>> >>> On Fri, 27 Oct 2017, LacaK wrote: >>> >>>> Same behavior also on Windows (current master) and on Linux (Ubuntu with >>>> installed libsybdb5 package) Once network cable is unpluged loop freezes >>>> and >>>> FAIL is not returned from dbnextrow() >>>> So I think, that it is reproducible case ... >>> >>> Some systems depending on configuration when physical link is lost >>> actively >>> close logical interface and associated sockets. These systems should >>> return >>> an error right away. Some do nothing. >>> >>> The difference you are seeing in your testing after waiting longer than a >>> certain period is a result of server side of the session giving up and >>> shutting down the TCP session. Under your test condition the client is >>> likely to have no idea this has occurred. All it knows is more data may >>> or >>> may not arrive at some undetermined point in the future. With TCP a >>> client >>> can find out in one of three ways: >>> >>> 1. Something is transmitted over TCP session such as request for more >>> data >>> or app layer keep-alive - at which point lack of connectivity is detected >>> when transmission timeout expires. >>> >>> 2. A TCP layer keep-alive fires off and time outs. On windows the >>> default >>> keep-alive interval is 2 hours. >>> >>> 3. Local application timeout such as a configured query timeout? >>> >>> Otherwise I would expect the application to sit and wait forever for data >>> that may never arrive over a server/network/socket that may no longer >>> exist. >>> On Windows you are likely looking at 2 hours maximum wait before anything >>> times out. >>> >>> On Windows try waiting 2 hours, using a query timeout or sysinternals >>> tcpview/process explorer to force close socket of database session from >>> client process and see if you get an error. >>> >>> regards, >>> Peter >>> >> You are right. >> >> Linux should have a total keep alive or 1 minute. Weird that is not >> set that way. >> I think for Windows is not set so yes, default is 2 hours. >> You can set query timeout of use interrupt. >> >> Frediano >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> https://lists.ibiblio.org/mailman/listinfo/freetds >> > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds From lacak at zoznam.sk Tue Oct 31 05:42:52 2017 From: lacak at zoznam.sk (LacaK) Date: Tue, 31 Oct 2017 10:42:52 +0100 Subject: [freetds] FreeTDS and buffering on client side In-Reply-To: References: <6bbf7c78-4347-c7a8-7a83-76dbb7131c5b@zoznam.sk> <55fd45f0-cd12-d48e-9581-74502af934fb@zoznam.sk> <41ee2f99-c309-53fe-f21a-e1b9b4707749@zoznam.sk> Message-ID: <759f262a-73ca-bed1-3856-8eecb996f229@zoznam.sk> > Still not sure why Linux version you have does not use these settings. > It's working for me. Probably I use old version of libsybdb. As I wrote I use package from Ubuntu repository. Which I am sure is not up to date ... (I test with Ubuntu Linux in Oracle VM on Windows) L. From freddy77 at gmail.com Fri Nov 10 07:49:42 2017 From: freddy77 at gmail.com (Frediano Ziglio) Date: Fri, 10 Nov 2017 12:49:42 +0000 Subject: [freetds] Version 1.00.15 select @@spid In-Reply-To: References: Message-ID: 2017-11-09 15:06 GMT+00:00 Ganesh, Ravi Chandran < ravi.chandran.ganesh at volvocars.com>: > Hello Frediano, > > > > I am writing this email after going through your reply on the post in the > below link. > > https://lists.ibiblio.org/pipermail/freetds/2016q3/030095.html > > > > We are facing similar challenge in our environment and unable to sort it > out. We followed all the steps mentioned in the link below. > > http://www.orb-data.com/index.php/accessing-objectserver- > databases-with-perl.html > > > > > > However still we get below error message when we try to connect to Netcool > ObjectServer which uses Sybase database. > > > > netcool at netcoolhost:> perl -MDBI -e'my $db=DBI->connect("DBI:Sybase:server=NEW_AGP", > netcool, netcool);print $DBI::errstr.$/' > > Server message number=17001 severity=10 state=0 line=0 server=NEW_AGP > text=No SRV_OPTION handler installed. Server message number=20000 > severity=0 state=0 line=0 server=NEW_AGP text=ERROR=Parse failure on line 1 > of statement 'select @@version', at or near '@' > > > > netcool at netcoolhost:> tsql -C > > Compile-time settings (established with the "configure" script) > > Version: freetds v0.91.49 > > freetds.conf directory: /usr/local/etc > > MS db-lib source compatibility: no > > Sybase binary compatibility: no > > Thread safety: yes > > iconv library: yes > > TDS version: 5.0 > > iODBC: no > > unixodbc: no > > SSPI "trusted" logins: no > > Kerberos: no > > > > I have also attached FreeTDS log and conf files for your reference. Please > do let me know if you need any other information to look into this case. > > > > If you could help us with this issue it would be much appreciated. > > > > Awaiting your reply! > > > This is a completely different issue. You are using 0.91 version which does not send the "select @@spid" query and the error came from a "select @@version" which we (FreeTDS) don't send so probably is coming from DBI::Sybase. Frediano From joshua.h.lang at gmail.com Wed Nov 15 21:28:49 2017 From: joshua.h.lang at gmail.com (Joshua Lang) Date: Wed, 15 Nov 2017 18:28:49 -0800 Subject: [freetds] read-only intent with SQL Server availability group Message-ID: When attempting to connect to SQL Server 2016 availability group listener, I'm seeing a "Unexpected EOF from the server" error if read-only intent is specified (this can be done via the freetds.conf file, for example). This is using the latest dev1.00.308 code and an availability group with a single secondary replica. The failure seems to come from the listener closing the connection after sending an ENVCHANGE routing message (type 20) message to the client. See https://msdn.microsoft.com/en-us/library/dd303449.aspx >From my reading of the TDS protocol specification, it seems as though a TDS 7.1 client and later should handle the ENVCHANGE routing message and reconnect to the host specified in the routing message when the read-only intent flag is set. Isn't the whole point of the read-only intent flag so that clients can be routed to read-only replicas when possible? Note that FreeTDS does connect successfully to the secondary (read-only) replica, and writes to it fail as one would expect. From freddy77 at gmail.com Thu Nov 16 11:32:43 2017 From: freddy77 at gmail.com (Frediano Ziglio) Date: Thu, 16 Nov 2017 16:32:43 +0000 Subject: [freetds] read-only intent with SQL Server availability group In-Reply-To: References: Message-ID: 2017-11-16 2:28 GMT+00:00 Joshua Lang : > When attempting to connect to SQL Server 2016 availability group listener, > I'm seeing a "Unexpected EOF from the server" error if read-only intent is > specified (this can be done via the freetds.conf file, for example). This > is using the latest dev1.00.308 code and an availability group with a > single secondary replica. > > The failure seems to come from the listener closing the connection after > sending an ENVCHANGE routing message (type 20) message to the client. See > https://msdn.microsoft.com/en-us/library/dd303449.aspx > > From my reading of the TDS protocol specification, it seems as though a TDS > 7.1 client and later should handle the ENVCHANGE routing message and > reconnect to the host specified in the routing message when the read-only > intent flag is set. > > Isn't the whole point of the read-only intent flag so that clients can be > routed to read-only replicas when possible? Note that FreeTDS does connect > successfully to the secondary (read-only) replica, and writes to it fail as > one would expect. Not implemented at all... but I don't think is hard to implement it, just a kind of reconnecting if you see the environment. Can you post a TDSDUMP (even privately) ? Frediano From joshua.h.lang at gmail.com Thu Nov 16 13:29:55 2017 From: joshua.h.lang at gmail.com (Joshua Lang) Date: Thu, 16 Nov 2017 10:29:55 -0800 Subject: [freetds] read-only intent with SQL Server availability group In-Reply-To: References: Message-ID: The tds code is currently written to discard ENVCHANGE info types it doesn't know about, include the routing (20 type). See https://github.com/FreeTDS/freetds/blob/master/src/tds/token.c#L2219 Here is the output after receiving the LOGIN7 response (I've redacted some specific info, like hostnames, etc). Let me know if you need more info. token.c:313:looking for login token, got e3(ENVCHANGE) token.c:132:tds_process_default_tokens() marker is e3(ENVCHANGE) dblib.c:310:db_env_chg(0x558b3a75cfe0, 1, master, **REDACTED***) token.c:313:looking for login token, got ab(INFO) token.c:132:tds_process_default_tokens() marker is ab(INFO) mem.c:656:tds_free_all_results() token.c:2355:tds_process_info() reading message 5701 from server token.c:2427:tds_process_info() calling client msg handler dbutil.c:75:_dblib_handle_info_message(0x558b3a724410, 0x558b3a75cfe0, 0x7ffd1ca86eb0) dbutil.c:76:msgno 5701: "Changed database context to '**REDACTED***'." dblib.c:5936:dbgetuserdata(0x558b3a75c330) token.c:2444:tds_process_info() returning TDS_SUCCESS token.c:313:looking for login token, got e3(ENVCHANGE) token.c:132:tds_process_default_tokens() marker is e3(ENVCHANGE) token.c:2187:tds_process_env_chg(): 5 bytes of collation data received token.c:2188:tds->conn->collation was 0000 00 00 00 00 00 - |.....| iconv.c:784:setting server single-byte charset to "CP1252" token.c:2198:tds->conn->collation now 0000 09 04 d0 00 34 - |....4| token.c:313:looking for login token, got e3(ENVCHANGE) token.c:132:tds_process_default_tokens() marker is e3(ENVCHANGE) dblib.c:310:db_env_chg(0x558b3a75cfe0, 2, , us_english) token.c:313:looking for login token, got ab(INFO) token.c:132:tds_process_default_tokens() marker is ab(INFO) mem.c:656:tds_free_all_results() token.c:2355:tds_process_info() reading message 5703 from server token.c:2427:tds_process_info() calling client msg handler dbutil.c:75:_dblib_handle_info_message(0x558b3a724410, 0x558b3a75cfe0, 0x7ffd1ca86eb0) dbutil.c:76:msgno 5703: "Changed language setting to us_english." dblib.c:5936:dbgetuserdata(0x558b3a75c330) token.c:2444:tds_process_info() returning TDS_SUCCESS token.c:313:looking for login token, got ad(LOGINACK) token.c:351:server reports TDS version 74.0.0.4 token.c:353:Product name for 0x74000004 is unknown token.c:385:Product version 8D000FA1 token.c:313:looking for login token, got e3(ENVCHANGE) token.c:132:tds_process_default_tokens() marker is e3(ENVCHANGE) token.c:313:looking for login token, got e3(ENVCHANGE) token.c:132:tds_process_default_tokens() marker is e3(ENVCHANGE) token.c:2244:changing block size from 4096 to 4096 dblib.c:310:db_env_chg(0x558b3a75cfe0, 4, 4096, 4096) token.c:313:looking for login token, got fd(DONE) token.c:132:tds_process_default_tokens() marker is fd(DONE) token.c:2087:tds_process_end: more_results = 0 was_cancelled = 0 error = 0 done_count_valid = 0 token.c:2106: rows_affected = 0 token.c:2109:tds_process_end() state set to TDS_IDLE token.c:422:tds_process_login_tokens() returning TDS_SUCCESS mem.c:656:tds_free_all_results() util.c:165:Changed query state from IDLE to WRITING packet.c:801:Sending packet 0000 01 01 00 44 00 00 00 00-16 00 00 00 12 00 00 00 |...D.... ........| 0010 02 00 00 00 00 00 00 00-00 00 01 00 00 00 73 00 |........ ......s.| 0020 65 00 74 00 20 00 74 00-65 00 78 00 74 00 73 00 |e.t. .t. e.x.t.s.| 0030 69 00 7a 00 65 00 20 00-36 00 34 00 35 00 31 00 |i.z.e. . 6.4.5.1.| 0040 32 00 20 00 - |2. .| util.c:165:Changed query state from WRITING to PENDING token.c:532:tds_process_tokens(0x558b3a75cfe0, 0x7ffd1ca86fa0, 0x7ffd1ca86fa4, 0x100) util.c:165:Changed query state from PENDING to READING util.c:165:Changed query state from READING to DEAD util.c:319:tdserror(0x558b3a724410, 0x558b3a75cfe0, 20017, 0) dblib.c:8102:dbperror(0x558b3a75c330, 20017, 0) dblib.c:8170:dbperror: Calling dblib_err_handler with msgno = 20017; msg->msgtext = "Unexpected EOF from the server (**REDACTED***)" dblib.c:5936:dbgetuserdata(0x558b3a75c330) dblib.c:8192:dbperror: dblib_err_handler for msgno = 20017; msg->msgtext = "Unexpected EOF from the server (***REDACTED***)" -- returns 2 (INT_CANCEL) util.c:349:tdserror: client library returned TDS_INT_CANCEL(2) util.c:372:tdserror: returning TDS_INT_CANCEL(2) packet.c:542:Read attempt when state is TDS_DEAD token.c:547:processing result tokens. marker is 0() token.c:132:tds_process_default_tokens() marker is 0() token.c:135:leaving tds_process_default_tokens() connection dead dblib.c:1264:tdsdbopen: tds_connect_and_login failed for "**REDACTED***"! dblib.c:1477:dbclose(0x558b3a75c330) dblib.c:241:dblib_del_connection(0x7f8986bdd900, 0x558b3a75cfe0) mem.c:656:tds_free_all_results() dblib.c:288:dblib_release_tds_ctx(1) dblib.c:6037:dbfreebuf(0x558b3a75c330) dblib.c:774:dbsetlname(0x558b3a7b6860, , 14) dblib.c:749:dbloginfree(0x558b3a7b6860) On Thu, Nov 16, 2017 at 8:32 AM, Frediano Ziglio wrote: > 2017-11-16 2:28 GMT+00:00 Joshua Lang : > > When attempting to connect to SQL Server 2016 availability group > listener, > > I'm seeing a "Unexpected EOF from the server" error if read-only intent > is > > specified (this can be done via the freetds.conf file, for example). This > > is using the latest dev1.00.308 code and an availability group with a > > single secondary replica. > > > > The failure seems to come from the listener closing the connection after > > sending an ENVCHANGE routing message (type 20) message to the client. See > > https://msdn.microsoft.com/en-us/library/dd303449.aspx > > > > From my reading of the TDS protocol specification, it seems as though a > TDS > > 7.1 client and later should handle the ENVCHANGE routing message and > > reconnect to the host specified in the routing message when the read-only > > intent flag is set. > > > > Isn't the whole point of the read-only intent flag so that clients can be > > routed to read-only replicas when possible? Note that FreeTDS does > connect > > successfully to the secondary (read-only) replica, and writes to it fail > as > > one would expect. > > > Not implemented at all... but I don't think is hard to implement it, > just a kind of > reconnecting if you see the environment. > Can you post a TDSDUMP (even privately) ? > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds > From no-reply at appveyor.com Fri Nov 17 14:55:23 2017 From: no-reply at appveyor.com (AppVeyor) Date: Fri, 17 Nov 2017 19:55:23 +0000 Subject: [freetds] Build failed: freetds 965 Message-ID: <20171117195014.71944.9468F315991171C4@appveyor.com> From no-reply at appveyor.com Fri Nov 17 15:34:13 2017 From: no-reply at appveyor.com (AppVeyor) Date: Fri, 17 Nov 2017 20:34:13 +0000 Subject: [freetds] Build completed: freetds 966 Message-ID: <20171117203404.96512.4A4780BA30F823A6@appveyor.com> From fandrieu at gmail.com Fri Nov 17 12:27:54 2017 From: fandrieu at gmail.com (frank) Date: Fri, 17 Nov 2017 18:27:54 +0100 Subject: [freetds] freerpc: a dblib rpc debugging tool Message-ID: Hi all, I'm a long time user and wanted to contribute someting I recently worked on. While trying to add RPC support to the php pdo_dblib driver ( https://github.com/php/php-src/pull/2914 ), I put together a simple debugging tool based on freebcp. It has grown to something of limited use, but flexible enough to put the dblib rpc api to the test. It's available here: https://github.com/fandrieu/freetds/commits/freerpc. In the process I found some bugs and just opened two pull requests to help improve blob support. Anyway, would this be valuable addition to the distribution ? would anyone care to comment on this implementation, notably the use of the dblib API ? Thanks ! frank. PS: I didn't write a manpage, but for those interested: the first argument is the procedure name then parameters values are passed with the "-p value" option repeated. Parameters can be configured using those options before -p: -t = data type (persists for other params) -n = name -N = is null, ignore value -o = is output -f = value is a file with raw data The usual -S -U etc are used to setup the connection. Here's some usage examples: freerpc sp_help -p sp_help -S mssqlf reerpc sp_executesql -p "select a=@a" -p "@a varchar(max)" -t char -n @a -p test -S mssql freerpc sp_executesql -p "set @i=@i+1" -p "@i int out" -t int1 -op 4 freerpc sp_executesql -p "set @b=upper(@a)" -p "@a text, @b text out" -t text -fp configure -oNfp CONFIGURE -S mssql From sergey_pashkov at valentina-db.com Fri Nov 17 05:26:22 2017 From: sergey_pashkov at valentina-db.com (Sergey Pashkov) Date: Fri, 17 Nov 2017 12:26:22 +0200 Subject: [freetds] How to get the value type returned from the SQL_VARIANT column (db-lib) Message-ID: Hello, I'm using: 1) db-lib freetds-1.00.70, on macOS 2) SQL Server 2017 on Linux TDS protocol is set to 7.2 Here's a sample table: CREATE TABLE t1( f1 SQL_VARIANT ); INSERT INTO t1 VALUES( 'string' ); INSERT INTO t1 VALUES( 55 ); I retrieve the data from this table SELECT * FROM t1; BYTE* msData = dbdata( hnd, i + 1 ); msData points to correct data - string and number respectively. But how can I get the type of this data? Is it possible at all? I can see internally it is stored in the TDSVARIANT structure, but dbdata returns just the data. Thank you! -- Best regards, Sergey Pashkov From no-reply at appveyor.com Sat Nov 18 17:13:36 2017 From: no-reply at appveyor.com (AppVeyor) Date: Sat, 18 Nov 2017 22:13:36 +0000 Subject: [freetds] Build failed: freetds 970 Message-ID: <20171118221335.22147.C93241A17B533940@appveyor.com> From no-reply at appveyor.com Sat Nov 18 20:18:23 2017 From: no-reply at appveyor.com (AppVeyor) Date: Sun, 19 Nov 2017 01:18:23 +0000 Subject: [freetds] Build completed: freetds 971 Message-ID: <20171119011823.80727.37314AB0E3A10C75@appveyor.com> From no-reply at appveyor.com Sun Nov 19 09:16:41 2017 From: no-reply at appveyor.com (AppVeyor) Date: Sun, 19 Nov 2017 14:16:41 +0000 Subject: [freetds] Build failed: freetds 972 Message-ID: <20171119141640.125055.F24890918647579E@appveyor.com> From no-reply at appveyor.com Mon Nov 20 18:29:30 2017 From: no-reply at appveyor.com (AppVeyor) Date: Mon, 20 Nov 2017 23:29:30 +0000 Subject: [freetds] Build completed: freetds 974 Message-ID: <20171120232928.35472.67193E0A21FE5947@appveyor.com> From sf at 4js.com Mon Dec 11 11:08:35 2017 From: sf at 4js.com (Sebastien FLAESCH) Date: Mon, 11 Dec 2017 17:08:35 +0100 Subject: [freetds] TDS Handshake failed when connecting to MS SQL Server 2017 on Windows Message-ID: <1d64417b-9adb-57e8-9f95-82f001cc37a9@4js.com> Hello, We try to connect with FreeTDS 1.00.15 from HP/UX to SQL Server 2017 on Linux or Windows. On Window we have SQL Server version: 14.0.1000.169 On RHE7 Linux we have SQL Server version: 14.0.3006.16-3 We can connect to the Linux server (freetds-ok.log), but we get a handshake error when connecting to the Windows server (freetds-fail.log) We see: 0460 fc 77 c8 1c f7 5c a5 f9-6f 5d 48 b0 61 fc d5 c8 |?w?.?\?? o]H?a???| 0470 34 de cf 04 67 dd 95 92-b0 15 6c e3 cb c6 8a e5 |4??.g?.. ?.l???.?| 0480 5d ed 52 98 e3 b8 64 c3-ca 5a e7 93 2d 0e 00 00 |]?R.??d? ?Z?.-...| 0490 00 - |.| tls.c:86:in tds_pull_func_login tls.c:116:in tds_push_func_login packet.c:741:Sending packet 0000 12 01 00 0f 00 00 00 00-15 03 01 00 02 02 50 |........ ......P| tls.c:924:handshake failed login.c:530:login packet rejected query.c:3796:tds_disconnect() util.c:165:Changed query state from IDLE to DEAD Any idea? See attached logs. Thanks! Seb -------------- next part -------------- A non-text attachment was scrubbed... Name: freetds-fail.log Type: text/x-log Size: 8379 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freetds-ok.log Type: text/x-log Size: 56966 bytes Desc: not available URL: From Steve.Wagner at 49ers.com Tue Nov 28 16:40:55 2017 From: Steve.Wagner at 49ers.com (Wagner, Steve) Date: Tue, 28 Nov 2017 21:40:55 +0000 Subject: [freetds] DB-Lib error message 20017, severity 9:Unexpected EOF from the server Message-ID: <16B74D10F9D66440AE2D7BC2C82642A150673F8B@SFVX2010.sf.NFL.NET> We've been using pymssql and FreeTDS for over 2 years now without problems. We recently upgraded pymssql to 2.1.3 and also from Python 3.4 to 3.6. Since that upgrade we've been getting the following error intermittently (but frequently). (20017, b'DB-Lib error message 20017, severity 9:\nUnexpected EOF from the server (FBOps-Prod:1433)\nDB-Lib error message 20002, severity 9:\nAdaptive Server connection failed (FBOps-Prod:1433)\n') There is no apparent pattern to the failures that we have been able to discover. Well over 95% of the DB calls succeed. It can fail on any stored proc or sql query. The database calls apparently do not even get to the database because nothing shows up in any DB log or trace. I've scoured the web and come up empty. I've reinstalled pymssql and FreeTDS but it still fails. Failures occur when connected to a DB server that is remote to the app but when connected to localhost. I've checked max number of connections and it's 4096 which should be plenty as there are no more than 10 active users at a time. Below is an excerpt from the TDS log file (full log file at the end). packet.c:639:Received packet 0000 04 01 00 11 00 5c 01 00-fd 00 00 d4 00 00 00 00 |.....\.. ........| 0010 00 - |.| token.c:565:processing result tokens. marker is fd(DONE) token.c:2081:tds_process_end: more_results = 0 was_cancelled = 0 error = 0 done_count_valid = 0 token.c:2098: rows_affected = 0 token.c:2101:tds_process_end() state set to TDS_IDLE util.c:165:Changed query state from READING to IDLE util.c:83:logic error: cannot change query state from IDLE to PENDING I've looked at the relevant code but don't have sufficient knowledge to understand why it's failing. Any help is appreciated. Given that it's sporadic and the packet received just before the failure is identical (or at least very similar), I suspect it might be a networking issue. And that is DEFINITELY beyond my expertise although I'm ready to try anything if given some guidance. Full log below... I appreciate any and all help. Steve log.c:167:Starting log file for FreeTDS 0.95 on 2017-11-28 09:19:48 with debug flags 0x4fff. dblib.c:1160:tdsdbopen(0000000006F7C9B0, FBOps-Prod:1433, [microsoft]) dblib.c:1186:tdsdbopen: dbproc->dbopts = 0000000007422E90 dblib.c:1193:tdsdbopen: tds_set_server(0000000006E3D920, "FBOps-Prod:1433") dblib.c:258:dblib_get_tds_ctx(void) dblib.c:1210:tdsdbopen: About to call tds_read_config_info... config.c:168:Getting connection information for [FBOps-Prod:1433]. config.c:172:Attempting to read conf files. config.c:353:... $FREETDSCONF not set. Trying $FREETDS/etc. config.c:366:... $FREETDS not set. Trying $HOME. config.c:292:Could not open 'C:\Users\prospector.user\AppData\Roaming/.freetds.conf' ((.freetds.conf)). config.c:296:Found conf file 'c:\freetds.conf' (default). config.c:495:Looking for section global. config.c:554: Found section global. config.c:557:Got a match. config.c:580: tds version = '7.3' config.c:886:Setting tds version to 7.3 (0x703). config.c:554: Found section fbops-prod. config.c:568: Reached EOF config.c:495:Looking for section FBOps-Prod:1433. config.c:554: Found section global. config.c:554: Found section fbops-prod. config.c:568: Reached EOF config.c:302:[FBOps-Prod:1433] not found. config.c:353:... $FREETDSCONF not set. Trying $FREETDS/etc. config.c:366:... $FREETDS not set. Trying $HOME. config.c:292:Could not open 'C:\Users\prospector.user\AppData\Roaming/.freetds.conf' ((.freetds.conf)). config.c:296:Found conf file 'c:\freetds.conf' (default). config.c:495:Looking for section global. config.c:554: Found section global. config.c:557:Got a match. config.c:580: tds version = '7.3' config.c:886:Setting tds version to 7.3 (0x703). config.c:554: Found section fbops-prod. config.c:568: Reached EOF config.c:495:Looking for section FBOps-Prod. config.c:554: Found section global. config.c:554: Found section fbops-prod. config.c:557:Got a match. config.c:580: host = 'fbops-prod' config.c:617:Found host entry fbops-prod config.c:620:IP addr is 10.164.222.55. config.c:568: Reached EOF config.c:300:Success: [FBOps-Prod] defined in c:\freetds.conf. config.c:765:Setting 'dump_file' to 'c:\freetds.log' from $TDSDUMP. config.c:689:tds_config_login: client_charset is UTF-8. config.c:696:tds_config_login: database_name is Goldmine. config.c:765:Setting 'dump_file' to 'c:\freetds.log' from $TDSDUMP. dblib.c:1237:tdsdbopen: Calling tds_connect_and_login(00000000075359E0, 0000000006E3DA10) iconv.c:328:tds_iconv_open(00000000075359E0, UTF-8) iconv.c:346:setting up conversions for client charset "UTF-8" iconv.c:348:preparing iconv for "UTF-8" <-> "UCS-2LE" conversion iconv.c:395:preparing iconv for "ISO-8859-1" <-> "UCS-2LE" conversion iconv.c:400:tds_iconv_open: done net.c:202:Connecting to 10.164.222.55 port 1433 (TDS version 7.1) net.c:275:tds_open_socket: connect(2) returned "WSAEWOULDBLOCK: Resource temporarily unavailable." net.c:314:tds_open_socket() succeeded packet.c:740:Sending packet 0000 12 01 00 34 00 00 00 00-00 00 15 00 06 01 00 1b |...4.... ........| 0010 00 01 02 00 1c 00 0c 03-00 28 00 04 ff 08 00 01 |........ .(......| 0020 55 00 00 00 4d 53 53 51-4c 53 65 72 76 65 72 00 |U...MSSQ LServer.| 0030 bc 11 00 00 - |....| packet.c:639:Received packet 0000 04 01 00 25 00 00 01 00-00 00 15 00 06 01 00 1b |...%.... ........| 0010 00 01 02 00 1c 00 01 03-00 1d 00 00 ff 0c 00 14 |........ ........| 0020 57 00 00 00 00 - |W....| login.c:1106:detected flag 0 tls.c:116:in tds_push_func_login tls.c:82:in tds_pull_func_login packet.c:740:Sending packet 0000 12 01 00 5c 00 00 00 00-16 03 01 00 4f 01 00 00 |...\.... ....O...| 0010 4b 03 01 af 63 5a 07 d9-79 47 24 fb 55 ed 88 a0 |K...cZ.. yG$.U...| 0020 9a 82 5b ed e3 70 c1 27-6d c2 9b 47 b7 d0 a9 af |..[..p.' m..G....| 0030 a4 e4 68 00 00 18 00 39-00 38 00 35 00 16 00 13 |..h....9 .8.5....| 0040 00 0a 00 33 00 32 00 2f-00 05 00 04 00 ff 02 01 |...3.2./ ........| 0050 00 00 09 00 23 00 00 00-0f 00 01 01 |....#... ....| tls.c:94:have 0 tls.c:98:before read packet.c:639:Received packet 0000 12 01 04 75 00 00 00 00-16 03 01 04 68 02 00 00 |...u.... ....h...| 0010 4d 03 01 5a 1d 9a b4 c9-30 fb 36 35 f3 31 8f ab |M..Z.... 0.65.1..| 0020 a6 ec 20 2e 78 a4 dd 18-35 7f c6 12 94 d9 da 35 |.. .x... 5......5| 0030 9a 11 0c 20 07 08 00 00-3e c0 5b 8b 15 27 db 2c |... .... >.[..'.,| 0040 9a 2b 21 78 60 39 f2 bd-5e 86 0a bf 1a b0 07 93 |.+!x`9.. ^.......| 0050 71 47 ec e7 00 39 00 00-05 ff 01 00 01 00 0b 00 |qG...9.. ........| 0060 02 03 00 02 00 00 01 fd-30 82 01 f9 30 82 01 62 |........ 0...0..b| 0070 a0 03 02 01 02 02 10 12-4b b2 71 c2 96 23 b0 42 |........ K.q..#.B| 0080 41 e3 e3 28 a3 4a 45 30-0d 06 09 2a 86 48 86 f7 |A..(.JE0 ...*.H..| 0090 0d 01 01 05 05 00 30 3b-31 39 30 37 06 03 55 04 |......0; 1907..U.| 00a0 03 1e 30 00 53 00 53 00-4c 00 5f 00 53 00 65 00 |..0.S.S. L._.S.e.| 00b0 6c 00 66 00 5f 00 53 00-69 00 67 00 6e 00 65 00 |l.f._.S. i.g.n.e.| 00c0 64 00 5f 00 46 00 61 00-6c 00 6c 00 62 00 61 00 |d._.F.a. l.l.b.a.| 00d0 63 00 6b 30 1e 17 0d 31-37 31 31 32 31 31 37 30 |c.k0...1 71121170| 00e0 35 35 34 5a 17 0d 34 37-31 31 32 31 31 37 30 35 |554Z..47 11211705| 00f0 35 34 5a 30 3b 31 39 30-37 06 03 55 04 03 1e 30 |54Z0;190 7..U...0| 0100 00 53 00 53 00 4c 00 5f-00 53 00 65 00 6c 00 66 |.S.S.L._ .S.e.l.f| 0110 00 5f 00 53 00 69 00 67-00 6e 00 65 00 64 00 5f |._.S.i.g .n.e.d._| 0120 00 46 00 61 00 6c 00 6c-00 62 00 61 00 63 00 6b |.F.a.l.l .b.a.c.k| 0130 30 81 9f 30 0d 06 09 2a-86 48 86 f7 0d 01 01 01 |0..0...* .H......| 0140 05 00 03 81 8d 00 30 81-89 02 81 81 00 ca 61 00 |......0. ......a.| 0150 0d a1 71 34 93 f1 82 5d-55 f5 cf 11 26 96 e0 70 |..q4...] U...&..p| 0160 cf 55 c2 20 e3 48 27 e7-12 c5 8d 0d 02 1e 13 68 |.U. .H'. .......h| 0170 17 1b fe 8f 66 4b d0 79-a6 a7 94 0a 5f 0d 47 4c |....fK.y ...._.GL| 0180 04 c0 07 95 37 34 76 64-5c 33 14 96 62 2e 75 44 |....74vd \3..b.uD| 0190 1d 1b 68 00 1b 24 27 6d-d1 fe 17 55 26 71 97 28 |..h..$'m ...U&q.(| 01a0 6f 1a a7 62 2e 78 8f 7d-96 53 44 e7 4c 8a 08 3f |o..b.x.} .SD.L..?| 01b0 cd a7 57 3c 58 80 8f a1-f0 f5 f4 c2 d0 b7 4c c5 |..W..D| 0380 ed 4b f7 04 87 9d 13 18-e5 8f 9d 00 b6 b3 53 67 |.K...... ......Sg| 0390 be 7d f9 39 59 df 06 2a-16 9e fa 5c e8 31 54 e0 |.}.9Y..* ...\.1T.| 03a0 ea 4d 2e 0d 85 9c 53 80-d3 a0 97 67 74 df ff ab |.M....S. ...gt...| 03b0 dd f7 ae af 50 5d d7 e4-a0 70 e2 fb a3 3b 59 41 |....P].. .p...;YA| 03c0 98 4f 2a 0f 91 dc 5a bf-22 79 27 db f2 0b 93 9a |.O*...Z. "y'.....| 03d0 8d 46 c5 ec 18 cf d4 36-92 d2 3c 55 57 97 36 ef |.F.....6 ...#8| 0050 f2 bf 39 82 69 4e 93 aa-5d 90 e0 02 88 d4 30 d6 |..9.iN.. ].....0.| 0060 40 45 04 b9 a1 0f 2f 6e-e0 da 2d 4c ca e1 22 2a |@E..../n ..-L.."*| 0070 b5 fc 94 e1 d1 2f 24 20-a3 00 7a 4b 0e c7 ff d1 |...../$ ..zK....| 0080 12 66 84 98 b8 50 3a 16-1e 9c 88 ac 97 1e 09 19 |.f...P:. ........| 0090 a3 c0 d6 14 03 01 00 01-01 16 03 01 00 30 8a 9c |........ .....0..| 00a0 74 4d 32 74 59 cd 96 0e-33 06 ed 27 60 f2 28 3e |tM2tY... 3..'`.(>| 00b0 a3 cc 82 e4 db 69 5d 50-e4 98 7a e4 62 61 5e 3f |.....i]P ..z.ba^?| 00c0 3e 32 bf a1 ce 08 c6 08-09 29 5c 22 c4 33 |>2...... .)\".3| tls.c:82:in tds_pull_func_login tls.c:94:have 0 tls.c:98:before read packet.c:639:Received packet 0000 12 01 00 43 00 00 00 00-14 03 01 00 01 01 16 03 |...C.... ........| 0010 01 00 30 8e 55 4d 00 d4-8a cc 3e c1 bc b6 07 4d |..0.UM.. ..>....M| 0020 ec de 3c c8 2b 8f a1 54-16 71 22 69 14 fb d1 1e |..<.+..T .q"i....| 0030 2b a0 09 1d bb 46 21 67-d5 66 cf fb c1 9f 31 3b |+....F!g .f....1;| 0040 f0 5a 75 - |.Zu| tls.c:101:after read tls.c:94:have 59 tls.c:105:read 5 bytes tls.c:82:in tds_pull_func_login tls.c:94:have 54 tls.c:105:read 1 bytes tls.c:82:in tds_pull_func_login tls.c:94:have 53 tls.c:105:read 5 bytes tls.c:82:in tds_pull_func_login tls.c:94:have 48 tls.c:105:read 48 bytes tls.c:855:handshake succeeded!! login.c:852:quietly sending TDS 7+ login packet token.c:327:tds_process_login_tokens() packet.c:639:Received packet 0000 04 01 01 89 00 4e 01 00-e3 1f 00 01 08 47 00 6f |.....N.. .....G.o| 0010 00 6c 00 64 00 6d 00 69-00 6e 00 65 00 06 6d 00 |.l.d.m.i .n.e..m.| 0020 61 00 73 00 74 00 65 00-72 00 ab 6e 00 45 16 00 |a.s.t.e. r..n.E..| 0030 00 02 00 27 00 43 00 68-00 61 00 6e 00 67 00 65 |...'.C.h .a.n.g.e| 0040 00 64 00 20 00 64 00 61-00 74 00 61 00 62 00 61 |.d. .d.a .t.a.b.a| 0050 00 73 00 65 00 20 00 63-00 6f 00 6e 00 74 00 65 |.s.e. .c .o.n.t.e| 0060 00 78 00 74 00 20 00 74-00 6f 00 20 00 27 00 47 |.x.t. .t .o. .'.G| 0070 00 6f 00 6c 00 64 00 6d-00 69 00 6e 00 65 00 27 |.o.l.d.m .i.n.e.'| 0080 00 2e 00 0a 46 00 42 00-4f 00 50 00 53 00 2d 00 |....F.B. O.P.S.-.| 0090 50 00 52 00 4f 00 44 00-00 01 00 e3 08 00 07 05 |P.R.O.D. ........| 00a0 09 04 d0 00 34 00 e3 17-00 02 0a 75 00 73 00 5f |....4... ...u.s._| 00b0 00 65 00 6e 00 67 00 6c-00 69 00 73 00 68 00 00 |.e.n.g.l .i.s.h..| 00c0 ab 6e 00 47 16 00 00 01-00 27 00 43 00 68 00 61 |.n.G.... .'.C.h.a| 00d0 00 6e 00 67 00 65 00 64-00 20 00 6c 00 61 00 6e |.n.g.e.d . .l.a.n| 00e0 00 67 00 75 00 61 00 67-00 65 00 20 00 73 00 65 |.g.u.a.g .e. .s.e| 00f0 00 74 00 74 00 69 00 6e-00 67 00 20 00 74 00 6f |.t.t.i.n .g. .t.o| 0100 00 20 00 75 00 73 00 5f-00 65 00 6e 00 67 00 6c |. .u.s._ .e.n.g.l| 0110 00 69 00 73 00 68 00 2e-00 0a 46 00 42 00 4f 00 |.i.s.h.. ..F.B.O.| 0120 50 00 53 00 2d 00 50 00-52 00 4f 00 44 00 00 01 |P.S.-.P. R.O.D...| 0130 00 ad 36 00 01 71 00 00-01 16 4d 00 69 00 63 00 |..6..q.. ..M.i.c.| 0140 72 00 6f 00 73 00 6f 00-66 00 74 00 20 00 53 00 |r.o.s.o. f.t. .S.| 0150 51 00 4c 00 20 00 53 00-65 00 72 00 76 00 65 00 |Q.L. .S. e.r.v.e.| 0160 72 00 00 00 00 00 0c 00-14 57 e3 13 00 04 04 34 |r....... .W.....4| 0170 00 30 00 39 00 36 00 04-34 00 30 00 39 00 36 00 |.0.9.6.. 4.0.9.6.| 0180 fd 00 00 00 00 00 00 00-00 |........ .| token.c:336:looking for login token, got e3(ENVCHANGE) token.c:116:tds_process_default_tokens() marker is e3(ENVCHANGE) dblib.c:312:db_env_chg(00000000075359E0, 1, master, Goldmine) token.c:336:looking for login token, got ab(INFO) token.c:116:tds_process_default_tokens() marker is ab(INFO) token.c:2345:tds_process_msg() reading message 5701 from server token.c:2417:tds_process_msg() calling client msg handler dbutil.c:76:_dblib_handle_info_message(0000000002C2CFA0, 00000000075359E0, 000000000A58B3F0) dbutil.c:77:msgno 5701: "Changed database context to 'Goldmine'." token.c:2430:tds_process_msg() returning TDS_SUCCESS token.c:336:looking for login token, got e3(ENVCHANGE) token.c:116:tds_process_default_tokens() marker is e3(ENVCHANGE) token.c:2179:tds_process_env_chg(): 5 bytes of collation data received token.c:2180:tds->conn->collation was 0000 00 00 00 00 00 - |.....| iconv.c:796:setting server single-byte charset to "CP1252" token.c:2190:tds->conn->collation now 0000 09 04 d0 00 34 - |....4| token.c:336:looking for login token, got e3(ENVCHANGE) token.c:116:tds_process_default_tokens() marker is e3(ENVCHANGE) dblib.c:312:db_env_chg(00000000075359E0, 2, , us_english) token.c:336:looking for login token, got ab(INFO) token.c:116:tds_process_default_tokens() marker is ab(INFO) token.c:2345:tds_process_msg() reading message 5703 from server token.c:2417:tds_process_msg() calling client msg handler dbutil.c:76:_dblib_handle_info_message(0000000002C2CFA0, 00000000075359E0, 000000000A58B3F0) dbutil.c:77:msgno 5703: "Changed language setting to us_english." token.c:2430:tds_process_msg() returning TDS_SUCCESS token.c:336:looking for login token, got ad(LOGINACK) token.c:374:server reports TDS version 71.0.0.1 token.c:376:Product name for 0x71000001 is 2000 SP1 token.c:408:Product version 8C001457 token.c:336:looking for login token, got e3(ENVCHANGE) token.c:116:tds_process_default_tokens() marker is e3(ENVCHANGE) token.c:2236:changing block size from 4096 to 4096 dblib.c:312:db_env_chg(00000000075359E0, 4, 4096, 4096) token.c:336:looking for login token, got fd(DONE) token.c:116:tds_process_default_tokens() marker is fd(DONE) token.c:2081:tds_process_end: more_results = 0 was_cancelled = 0 error = 0 done_count_valid = 0 token.c:2098: rows_affected = 0 token.c:2101:tds_process_end() state set to TDS_IDLE token.c:440:tds_process_login_tokens() returning TDS_SUCCESS dblib.c:224:dblib_add_connection(000007FEF8B0FA70, 00000000075359E0) dblib.c:1280:tdsdbopen: Returning dbproc = 000000000775B3B0 dblib.c:743:dbloginfree(0000000006F7C9B0) dblib.c:1338:dbcmd(000000000775B3B0, SET ARITHABORT ON;SET CONCAT_NULL_YIELDS_NULL ON;SET ANSI_NULLS ON;SET ANSI_NULL_DFLT_ON ON;SET ANSI_PADDING ON;SET ANSI_WARNINGS ON;SET ANSI_NULL_DFLT_ON ON;SET CURSOR_CLOSE_ON_COMMIT ON;SET QUOTED_IDENTIFIER ON;SET TEXTSIZE 2147483647;) dblib.c:1344:dbcmd() bufsz = 0 dblib.c:6845:dbsqlsend(000000000775B3B0) mem.c:648:tds_free_all_results() util.c:165:Changed query state from IDLE to WRITING util.c:165:Changed query state from WRITING to PENDING packet.c:740:Sending packet 0000 01 01 01 e2 00 00 01 00-53 00 45 00 54 00 20 00 |........ S.E.T. .| 0010 41 00 52 00 49 00 54 00-48 00 41 00 42 00 4f 00 |A.R.I.T. H.A.B.O.| 0020 52 00 54 00 20 00 4f 00-4e 00 3b 00 53 00 45 00 |R.T. .O. N.;.S.E.| 0030 54 00 20 00 43 00 4f 00-4e 00 43 00 41 00 54 00 |T. .C.O. N.C.A.T.| 0040 5f 00 4e 00 55 00 4c 00-4c 00 5f 00 59 00 49 00 |_.N.U.L. L._.Y.I.| 0050 45 00 4c 00 44 00 53 00-5f 00 4e 00 55 00 4c 00 |E.L.D.S. _.N.U.L.| 0060 4c 00 20 00 4f 00 4e 00-3b 00 53 00 45 00 54 00 |L. .O.N. ;.S.E.T.| 0070 20 00 41 00 4e 00 53 00-49 00 5f 00 4e 00 55 00 | .A.N.S. I._.N.U.| 0080 4c 00 4c 00 53 00 20 00-4f 00 4e 00 3b 00 53 00 |L.L.S. . O.N.;.S.| 0090 45 00 54 00 20 00 41 00-4e 00 53 00 49 00 5f 00 |E.T. .A. N.S.I._.| 00a0 4e 00 55 00 4c 00 4c 00-5f 00 44 00 46 00 4c 00 |N.U.L.L. _.D.F.L.| 00b0 54 00 5f 00 4f 00 4e 00-20 00 4f 00 4e 00 3b 00 |T._.O.N. .O.N.;.| 00c0 53 00 45 00 54 00 20 00-41 00 4e 00 53 00 49 00 |S.E.T. . A.N.S.I.| 00d0 5f 00 50 00 41 00 44 00-44 00 49 00 4e 00 47 00 |_.P.A.D. D.I.N.G.| 00e0 20 00 4f 00 4e 00 3b 00-53 00 45 00 54 00 20 00 | .O.N.;. S.E.T. .| 00f0 41 00 4e 00 53 00 49 00-5f 00 57 00 41 00 52 00 |A.N.S.I. _.W.A.R.| 0100 4e 00 49 00 4e 00 47 00-53 00 20 00 4f 00 4e 00 |N.I.N.G. S. .O.N.| 0110 3b 00 53 00 45 00 54 00-20 00 41 00 4e 00 53 00 |;.S.E.T. .A.N.S.| 0120 49 00 5f 00 4e 00 55 00-4c 00 4c 00 5f 00 44 00 |I._.N.U. L.L._.D.| 0130 46 00 4c 00 54 00 5f 00-4f 00 4e 00 20 00 4f 00 |F.L.T._. O.N. .O.| 0140 4e 00 3b 00 53 00 45 00-54 00 20 00 43 00 55 00 |N.;.S.E. T. .C.U.| 0150 52 00 53 00 4f 00 52 00-5f 00 43 00 4c 00 4f 00 |R.S.O.R. _.C.L.O.| 0160 53 00 45 00 5f 00 4f 00-4e 00 5f 00 43 00 4f 00 |S.E._.O. N._.C.O.| 0170 4d 00 4d 00 49 00 54 00-20 00 4f 00 4e 00 3b 00 |M.M.I.T. .O.N.;.| 0180 53 00 45 00 54 00 20 00-51 00 55 00 4f 00 54 00 |S.E.T. . Q.U.O.T.| 0190 45 00 44 00 5f 00 49 00-44 00 45 00 4e 00 54 00 |E.D._.I. D.E.N.T.| 01a0 49 00 46 00 49 00 45 00-52 00 20 00 4f 00 4e 00 |I.F.I.E. R. .O.N.| 01b0 3b 00 53 00 45 00 54 00-20 00 54 00 45 00 58 00 |;.S.E.T. .T.E.X.| 01c0 54 00 53 00 49 00 5a 00-45 00 20 00 32 00 31 00 |T.S.I.Z. E. .2.1.| 01d0 34 00 37 00 34 00 38 00-33 00 36 00 34 00 37 00 |4.7.4.8. 3.6.4.7.| 01e0 3b 00 - |;.| dblib.c:4625:dbsqlok(000000000775B3B0) dblib.c:4654:dbsqlok() not done, calling tds_process_tokens() token.c:550:tds_process_tokens(00000000075359E0, 000000000A58B918, 000000000A58B910, 0x6914) util.c:165:Changed query state from PENDING to READING packet.c:639:Received packet 0000 04 01 00 59 00 4e 01 00-fd 01 00 b9 00 00 00 00 |...Y.N.. ........| 0010 00 fd 01 00 b9 00 00 00-00 00 fd 01 00 b9 00 00 |........ ........| 0020 00 00 00 fd 01 00 b9 00-00 00 00 00 fd 01 00 b9 |........ ........| 0030 00 00 00 00 00 fd 01 00-b9 00 00 00 00 00 fd 01 |........ ........| 0040 00 b9 00 00 00 00 00 fd-01 00 b9 00 00 00 00 00 |........ ........| 0050 fd 00 00 be 00 00 00 00-00 |........ .| token.c:565:processing result tokens. marker is fd(DONE) token.c:2081:tds_process_end: more_results = 1 was_cancelled = 0 error = 0 done_count_valid = 0 token.c:2098: rows_affected = 0 util.c:165:Changed query state from READING to PENDING dblib.c:4687:dbsqlok() end status is SUCCEED dblib.c:4698:dbsqlok() end status was success dblib.c:3203:dbcancel(000000000775B3B0) query.c:2189:tds_send_cancel: not in_cancel and not idle packet.c:770:Sending packet 0000 06 01 00 08 00 00 01 00- |........| token.c:550:tds_process_tokens(00000000075359E0, 000000000A58B900, 0000000000000000, 0x0) util.c:165:Changed query state from PENDING to READING token.c:565:processing result tokens. marker is fd(DONE) token.c:2081:tds_process_end: more_results = 1 was_cancelled = 0 error = 0 done_count_valid = 0 token.c:2098: rows_affected = 0 token.c:565:processing result tokens. marker is fd(DONE) token.c:2081:tds_process_end: more_results = 1 was_cancelled = 0 error = 0 done_count_valid = 0 token.c:2098: rows_affected = 0 token.c:565:processing result tokens. marker is fd(DONE) token.c:2081:tds_process_end: more_results = 1 was_cancelled = 0 error = 0 done_count_valid = 0 token.c:2098: rows_affected = 0 token.c:565:processing result tokens. marker is fd(DONE) token.c:2081:tds_process_end: more_results = 1 was_cancelled = 0 error = 0 done_count_valid = 0 token.c:2098: rows_affected = 0 token.c:565:processing result tokens. marker is fd(DONE) token.c:2081:tds_process_end: more_results = 1 was_cancelled = 0 error = 0 done_count_valid = 0 token.c:2098: rows_affected = 0 token.c:565:processing result tokens. marker is fd(DONE) token.c:2081:tds_process_end: more_results = 1 was_cancelled = 0 error = 0 done_count_valid = 0 token.c:2098: rows_affected = 0 token.c:565:processing result tokens. marker is fd(DONE) token.c:2081:tds_process_end: more_results = 1 was_cancelled = 0 error = 0 done_count_valid = 0 token.c:2098: rows_affected = 0 token.c:565:processing result tokens. marker is fd(DONE) token.c:2081:tds_process_end: more_results = 0 was_cancelled = 0 error = 0 done_count_valid = 0 token.c:2098: rows_affected = 0 packet.c:639:Received packet 0000 04 01 00 11 00 4e 01 00-fd 20 00 fd 00 00 00 00 |.....N.. . ......| 0010 00 - |.| token.c:565:processing result tokens. marker is fd(DONE) token.c:2081:tds_process_end: more_results = 0 was_cancelled = 1 error = 0 done_count_valid = 0 token.c:2098: rows_affected = 0 token.c:2101:tds_process_end() state set to TDS_IDLE util.c:165:Changed query state from READING to IDLE util.c:83:logic error: cannot change query state from IDLE to PENDING util.c:165:Changed query state from IDLE to IDLE dblib.c:1419:dbuse(000000000775B3B0, Goldmine) dblib.c:1338:dbcmd(000000000775B3B0, use [Goldmine]) dblib.c:1344:dbcmd() bufsz = 238 dblib.c:5873:dbfreebuf(000000000775B3B0) dblib.c:1392:dbsqlexec(000000000775B3B0) dblib.c:6845:dbsqlsend(000000000775B3B0) mem.c:648:tds_free_all_results() util.c:165:Changed query state from IDLE to WRITING util.c:165:Changed query state from WRITING to PENDING packet.c:740:Sending packet 0000 01 01 00 24 00 00 01 00-75 00 73 00 65 00 20 00 |...$.... u.s.e. .| 0010 5b 00 47 00 6f 00 6c 00-64 00 6d 00 69 00 6e 00 |[.G.o.l. d.m.i.n.| 0020 65 00 5d 00 - |e.].| dblib.c:4625:dbsqlok(000000000775B3B0) dblib.c:4654:dbsqlok() not done, calling tds_process_tokens() token.c:550:tds_process_tokens(00000000075359E0, 000000000A58B8D8, 000000000A58B8D0, 0x6914) util.c:165:Changed query state from PENDING to READING packet.c:639:Received packet 0000 04 01 00 b3 00 4e 01 00-e3 23 00 01 08 47 00 6f |.....N.. .#...G.o| 0010 00 6c 00 64 00 6d 00 69-00 6e 00 65 00 08 47 00 |.l.d.m.i .n.e..G.| 0020 6f 00 6c 00 64 00 6d 00-69 00 6e 00 65 00 ab 6e |o.l.d.m. i.n.e..n| 0030 00 45 16 00 00 01 00 27-00 43 00 68 00 61 00 6e |.E.....' .C.h.a.n| 0040 00 67 00 65 00 64 00 20-00 64 00 61 00 74 00 61 |.g.e.d. .d.a.t.a| 0050 00 62 00 61 00 73 00 65-00 20 00 63 00 6f 00 6e |.b.a.s.e . .c.o.n| 0060 00 74 00 65 00 78 00 74-00 20 00 74 00 6f 00 20 |.t.e.x.t . .t.o. | 0070 00 27 00 47 00 6f 00 6c-00 64 00 6d 00 69 00 6e |.'.G.o.l .d.m.i.n| 0080 00 65 00 27 00 2e 00 0a-46 00 42 00 4f 00 50 00 |.e.'.... F.B.O.P.| 0090 53 00 2d 00 50 00 52 00-4f 00 44 00 00 01 00 e3 |S.-.P.R. O.D.....| 00a0 08 00 07 05 09 04 d0 00-34 00 fd 00 00 e2 00 00 |........ 4.......| 00b0 00 00 00 - |...| token.c:565:processing result tokens. marker is e3(ENVCHANGE) token.c:116:tds_process_default_tokens() marker is e3(ENVCHANGE) dblib.c:312:db_env_chg(00000000075359E0, 1, Goldmine, Goldmine) token.c:565:processing result tokens. marker is ab(INFO) token.c:116:tds_process_default_tokens() marker is ab(INFO) token.c:2345:tds_process_msg() reading message 5701 from server token.c:2417:tds_process_msg() calling client msg handler dbutil.c:76:_dblib_handle_info_message(0000000002C2CFA0, 00000000075359E0, 000000000A58B750) dbutil.c:77:msgno 5701: "Changed database context to 'Goldmine'." token.c:2430:tds_process_msg() returning TDS_SUCCESS token.c:565:processing result tokens. marker is e3(ENVCHANGE) token.c:116:tds_process_default_tokens() marker is e3(ENVCHANGE) token.c:2179:tds_process_env_chg(): 5 bytes of collation data received token.c:2180:tds->conn->collation was 0000 09 04 d0 00 34 - |....4| iconv.c:796:setting server single-byte charset to "CP1252" token.c:2190:tds->conn->collation now 0000 09 04 d0 00 34 - |....4| token.c:565:processing result tokens. marker is fd(DONE) token.c:2081:tds_process_end: more_results = 0 was_cancelled = 0 error = 0 done_count_valid = 0 token.c:2098: rows_affected = 0 token.c:2101:tds_process_end() state set to TDS_IDLE util.c:165:Changed query state from READING to IDLE util.c:83:logic error: cannot change query state from IDLE to PENDING util.c:165:Changed query state from IDLE to IDLE dblib.c:4687:dbsqlok() end status is SUCCEED dblib.c:4698:dbsqlok() end status was success dblib.c:1689:dbresults(000000000775B3B0) dblib.c:1694:dbresults: dbresults_state is 5 (_DB_RES_SUCCEED) dblib.c:1679:dbresults returning 1 (SUCCEED) dblib.c:5846:dbcanquery(000000000775B3B0) token.c:550:tds_process_tokens(00000000075359E0, 000000000A58B8D0, 0000000000000000, 0x108) token.c:553:tds_process_tokens() state is COMPLETED dblib.c:3203:dbcancel(000000000775B3B0) query.c:2189:tds_send_cancel: not in_cancel and idle dblib.c:1338:dbcmd(000000000775B3B0, BEGIN TRAN) dblib.c:1344:dbcmd() bufsz = 15 dblib.c:5873:dbfreebuf(000000000775B3B0) dblib.c:6845:dbsqlsend(000000000775B3B0) mem.c:648:tds_free_all_results() util.c:165:Changed query state from IDLE to WRITING util.c:165:Changed query state from WRITING to PENDING packet.c:740:Sending packet 0000 01 01 00 1c 00 00 01 00-42 00 45 00 47 00 49 00 |........ B.E.G.I.| 0010 4e 00 20 00 54 00 52 00-41 00 4e 00 |N. .T.R. A.N.| dblib.c:4625:dbsqlok(000000000775B3B0) dblib.c:4654:dbsqlok() not done, calling tds_process_tokens() token.c:550:tds_process_tokens(00000000075359E0, 000000000A58B828, 000000000A58B820, 0x6914) util.c:165:Changed query state from PENDING to READING packet.c:639:Received packet 0000 04 01 00 11 00 4e 01 00-fd 00 00 d4 00 00 00 00 |.....N.. ........| 0010 00 - |.| token.c:565:processing result tokens. marker is fd(DONE) token.c:2081:tds_process_end: more_results = 0 was_cancelled = 0 error = 0 done_count_valid = 0 token.c:2098: rows_affected = 0 token.c:2101:tds_process_end() state set to TDS_IDLE util.c:165:Changed query state from READING to IDLE util.c:83:logic error: cannot change query state from IDLE to PENDING util.c:165:Changed query state from IDLE to IDLE dblib.c:4687:dbsqlok() end status is SUCCEED dblib.c:4698:dbsqlok() end status was success dblib.c:1689:dbresults(000000000775B3B0) dblib.c:1694:dbresults: dbresults_state is 5 (_DB_RES_SUCCEED) dblib.c:1679:dbresults returning 1 (SUCCEED) dblib.c:2772:dbcount(000000000775B3B0) dblib.c:3203:dbcancel(000000000775B3B0) query.c:2189:tds_send_cancel: not in_cancel and idle dblib.c:3203:dbcancel(000000000775B3B0) query.c:2189:tds_send_cancel: not in_cancel and idle dblib.c:1338:dbcmd(000000000775B3B0, sp_PlayerFactors_iud 54, N'U', 241406, 236120, 501, 74815, 7, 1) dblib.c:1344:dbcmd() bufsz = 11 dblib.c:5873:dbfreebuf(000000000775B3B0) dblib.c:6845:dbsqlsend(000000000775B3B0) mem.c:648:tds_free_all_results() util.c:165:Changed query state from IDLE to WRITING util.c:165:Changed query state from WRITING to PENDING packet.c:740:Sending packet 0000 01 01 00 86 00 00 01 00-73 00 70 00 5f 00 50 00 |........ s.p._.P.| 0010 6c 00 61 00 79 00 65 00-72 00 46 00 61 00 63 00 |l.a.y.e. r.F.a.c.| 0020 74 00 6f 00 72 00 73 00-5f 00 69 00 75 00 64 00 |t.o.r.s. _.i.u.d.| 0030 20 00 35 00 34 00 2c 00-20 00 4e 00 27 00 55 00 | .5.4.,. .N.'.U.| 0040 27 00 2c 00 20 00 32 00-34 00 31 00 34 00 30 00 |'.,. .2. 4.1.4.0.| 0050 36 00 2c 00 20 00 32 00-33 00 36 00 31 00 32 00 |6.,. .2. 3.6.1.2.| 0060 30 00 2c 00 20 00 35 00-30 00 31 00 2c 00 20 00 |0.,. .5. 0.1.,. .| 0070 37 00 34 00 38 00 31 00-35 00 2c 00 20 00 37 00 |7.4.8.1. 5.,. .7.| 0080 2c 00 20 00 31 00 - |,. .1.| dblib.c:4625:dbsqlok(000000000775B3B0) dblib.c:4654:dbsqlok() not done, calling tds_process_tokens() token.c:550:tds_process_tokens(00000000075359E0, 000000000A58BB08, 000000000A58BB00, 0x6914) util.c:165:Changed query state from PENDING to READING packet.c:639:Received packet 0000 04 01 00 7b 00 4e 01 00-81 03 00 00 00 21 00 a7 |...{.N.. .....!..| 0010 32 00 09 04 d0 00 34 06-52 00 65 00 73 00 75 00 |2.....4. R.e.s.u.| 0020 6c 00 74 00 00 00 21 00-26 04 0a 50 00 72 00 69 |l.t...!. &..P.r.i| 0030 00 6d 00 61 00 72 00 79-00 4b 00 65 00 79 00 00 |.m.a.r.y .K.e.y..| 0040 00 21 00 26 04 07 4d 00-65 00 73 00 73 00 61 00 |.!.&..M. e.s.s.a.| 0050 67 00 65 00 d1 07 00 55-70 64 61 74 65 64 04 fe |g.e....U pdated..| 0060 ae 03 00 00 ff 01 00 c1-00 01 00 00 00 79 00 00 |........ .....y..| 0070 00 00 fe 00 00 e0 00 00-00 00 00 |........ ...| token.c:565:processing result tokens. marker is 81(TDS7_RESULT) token.c:1574:processing TDS7 result metadata. mem.c:648:tds_free_all_results() token.c:1599:set current_results (3 columns) to tds->res_info token.c:1606:setting up 3 columns token.c:3165:adjust_character_column_size: Server charset: CP1252 Server column_size: 50 Client charset: UTF-8 Client column_size: 200 token.c:1543:tds7_get_data_info: colname = Result type = 39 (varchar) server's type = 167 (xvarchar) column_varint_size = 2 column_size = 200 (50 on server) token.c:1543:tds7_get_data_info: colname = PrimaryKey type = 38 (integer-null) server's type = 38 (integer-null) column_varint_size = 1 column_size = 4 (4 on server) token.c:1543:tds7_get_data_info: colname = Message type = 38 (integer-null) server's type = 38 (integer-null) column_varint_size = 1 column_size = 4 (4 on server) token.c:1615: name size/wsize type/wtype utype token.c:1616: -------------------- --------------- --------------- ------- token.c:1621: Result 200/50 39/167 0 token.c:1621: PrimaryKey 4/4 38/38 0 token.c:1621: Message 4/4 38/38 0 util.c:165:Changed query state from READING to PENDING dblib.c:4680:dbsqlok() found result token dblib.c:1689:dbresults(000000000775B3B0) dblib.c:1694:dbresults: dbresults_state is 1 (_DB_RES_RESULTSET_EMPTY) token.c:550:tds_process_tokens(00000000075359E0, 000000000A58BA50, 000000000A58BA58, 0x6914) util.c:165:Changed query state from PENDING to READING token.c:565:processing result tokens. marker is d1(ROW) token.c:681:tds_process_tokens::SET_RETURN stopping on current token util.c:165:Changed query state from READING to PENDING dblib.c:1715:dbresults() tds_process_tokens returned 0 (TDS_SUCCESS), result_type TDS_ROW_RESULT dblib.c:1679:dbresults returning 1 (SUCCEED) dblib.c:1827:dbnumcols(000000000775B3B0) dblib.c:2772:dbcount(000000000775B3B0) dblib.c:1827:dbnumcols(000000000775B3B0) dblib.c:1853:dbcolname(000000000775B3B0, 1) dblib.c:2841:dbcoltype(000000000775B3B0, 1) dblib.c:1853:dbcolname(000000000775B3B0, 2) dblib.c:2841:dbcoltype(000000000775B3B0, 2) dblib.c:1853:dbcolname(000000000775B3B0, 3) dblib.c:2841:dbcoltype(000000000775B3B0, 3) dblib.c:2031:dbnextrow(000000000775B3B0) dblib.c:2043:dbnextrow() dbresults_state = 2 (_DB_RES_RESULTSET_ROWS) token.c:550:tds_process_tokens(00000000075359E0, 000000000A58BB40, 0000000000000000, 0x1508) util.c:165:Changed query state from PENDING to READING token.c:565:processing result tokens. marker is d1(ROW) token.c:1952:tds_process_row(): reading column 0 data.c:534:tds_get_data: type 39, varint size 2 data.c:587:tds_get_data(): wire column size is 7 token.c:1952:tds_process_row(): reading column 1 data.c:534:tds_get_data: type 38, varint size 1 data.c:587:tds_get_data(): wire column size is 4 token.c:1952:tds_process_row(): reading column 2 data.c:534:tds_get_data: type 38, varint size 1 data.c:587:tds_get_data(): wire column size is -1 util.c:165:Changed query state from READING to PENDING buffering.h:305:buffer_transfer_bound_data(000000000775B3C0 4040 -1 000000000775B3B0 0) dblib.c:2117:leaving dbnextrow() returning REG_ROW/MORE_ROWS dblib.c:3172:dbdata(000000000775B3B0, 1) dblib.c:2841:dbcoltype(000000000775B3B0, 1) dblib.c:3143:dbdatlen(000000000775B3B0, 1) dblib.c:3151:dbdatlen() type = 39, len= 7 dblib.c:3172:dbdata(000000000775B3B0, 2) dblib.c:2841:dbcoltype(000000000775B3B0, 2) dblib.c:3143:dbdatlen(000000000775B3B0, 2) dblib.c:3151:dbdatlen() type = 38, len= 4 dblib.c:3172:dbdata(000000000775B3B0, 3) dblib.c:2841:dbcoltype(000000000775B3B0, 3) dblib.c:3143:dbdatlen(000000000775B3B0, 3) dblib.c:3151:dbdatlen() type = 38, len= 0 dblib.c:2031:dbnextrow(000000000775B3B0) dblib.c:2043:dbnextrow() dbresults_state = 2 (_DB_RES_RESULTSET_ROWS) token.c:550:tds_process_tokens(00000000075359E0, 000000000A58BB40, 0000000000000000, 0x1508) util.c:165:Changed query state from PENDING to READING token.c:565:processing result tokens. marker is ff(DONEINPROC) token.c:2081:tds_process_end: more_results = 1 was_cancelled = 0 error = 0 done_count_valid = 0 token.c:2098: rows_affected = 1 util.c:165:Changed query state from READING to PENDING dblib.c:2117:leaving dbnextrow() returning NO_MORE_ROWS dblib.c:2772:dbcount(000000000775B3B0) dblib.c:3203:dbcancel(000000000775B3B0) query.c:2189:tds_send_cancel: not in_cancel and not idle packet.c:770:Sending packet 0000 06 01 00 08 00 00 01 00- |........| token.c:550:tds_process_tokens(00000000075359E0, 000000000A58BB60, 0000000000000000, 0x0) util.c:165:Changed query state from PENDING to READING token.c:565:processing result tokens. marker is 79(RETURNSTATUS) token.c:712:tds_process_tokens: return status is 0 token.c:565:processing result tokens. marker is fe(DONEPROC) token.c:2081:tds_process_end: more_results = 0 was_cancelled = 0 error = 0 done_count_valid = 0 token.c:2098: rows_affected = 0 packet.c:639:Received packet 0000 04 01 00 11 00 4e 01 00-fd 20 00 fd 00 00 00 00 |.....N.. . ......| 0010 00 - |.| token.c:565:processing result tokens. marker is fd(DONE) token.c:2081:tds_process_end: more_results = 0 was_cancelled = 1 error = 0 done_count_valid = 0 token.c:2098: rows_affected = 0 token.c:2101:tds_process_end() state set to TDS_IDLE util.c:165:Changed query state from READING to IDLE util.c:83:logic error: cannot change query state from IDLE to PENDING util.c:165:Changed query state from IDLE to IDLE dblib.c:1338:dbcmd(000000000775B3B0, COMMIT TRAN) dblib.c:1344:dbcmd() bufsz = 64 dblib.c:5873:dbfreebuf(000000000775B3B0) dblib.c:6845:dbsqlsend(000000000775B3B0) mem.c:648:tds_free_all_results() util.c:165:Changed query state from IDLE to WRITING util.c:165:Changed query state from WRITING to PENDING packet.c:740:Sending packet 0000 01 01 00 1e 00 00 01 00-43 00 4f 00 4d 00 4d 00 |........ C.O.M.M.| 0010 49 00 54 00 20 00 54 00-52 00 41 00 4e 00 |I.T. .T. R.A.N.| dblib.c:4625:dbsqlok(000000000775B3B0) dblib.c:4654:dbsqlok() not done, calling tds_process_tokens() token.c:550:tds_process_tokens(00000000075359E0, 000000000A58BBA8, 000000000A58BBA0, 0x6914) util.c:165:Changed query state from PENDING to READING packet.c:639:Received packet 0000 04 01 00 11 00 4e 01 00-fd 00 00 d5 00 00 00 00 |.....N.. ........| 0010 00 - |.| token.c:565:processing result tokens. marker is fd(DONE) token.c:2081:tds_process_end: more_results = 0 was_cancelled = 0 error = 0 done_count_valid = 0 token.c:2098: rows_affected = 0 token.c:2101:tds_process_end() state set to TDS_IDLE util.c:165:Changed query state from READING to IDLE util.c:83:logic error: cannot change query state from IDLE to PENDING util.c:165:Changed query state from IDLE to IDLE dblib.c:4687:dbsqlok() end status is SUCCEED dblib.c:4698:dbsqlok() end status was success dblib.c:1689:dbresults(000000000775B3B0) dblib.c:1694:dbresults: dbresults_state is 5 (_DB_RES_SUCCEED) dblib.c:1679:dbresults returning 1 (SUCCEED) dblib.c:2772:dbcount(000000000775B3B0) dblib.c:3203:dbcancel(000000000775B3B0) query.c:2189:tds_send_cancel: not in_cancel and idle dblib.c:3203:dbcancel(000000000775B3B0) query.c:2189:tds_send_cancel: not in_cancel and idle dblib.c:1338:dbcmd(000000000775B3B0, BEGIN TRAN) dblib.c:1344:dbcmd() bufsz = 12 dblib.c:5873:dbfreebuf(000000000775B3B0) dblib.c:6845:dbsqlsend(000000000775B3B0) mem.c:648:tds_free_all_results() util.c:165:Changed query state from IDLE to WRITING util.c:165:Changed query state from WRITING to PENDING packet.c:740:Sending packet 0000 01 01 00 1c 00 00 01 00-42 00 45 00 47 00 49 00 |........ B.E.G.I.| 0010 4e 00 20 00 54 00 52 00-41 00 4e 00 |N. .T.R. A.N.| dblib.c:4625:dbsqlok(000000000775B3B0) dblib.c:4654:dbsqlok() not done, calling tds_process_tokens() token.c:550:tds_process_tokens(00000000075359E0, 000000000A58BBA8, 000000000A58BBA0, 0x6914) util.c:165:Changed query state from PENDING to READING packet.c:639:Received packet 0000 04 01 00 11 00 4e 01 00-fd 00 00 d4 00 00 00 00 |.....N.. ........| 0010 00 - |.| token.c:565:processing result tokens. marker is fd(DONE) token.c:2081:tds_process_end: more_results = 0 was_cancelled = 0 error = 0 done_count_valid = 0 token.c:2098: rows_affected = 0 token.c:2101:tds_process_end() state set to TDS_IDLE util.c:165:Changed query state from READING to IDLE util.c:83:logic error: cannot change query state from IDLE to PENDING util.c:165:Changed query state from IDLE to IDLE dblib.c:4687:dbsqlok() end status is SUCCEED dblib.c:4698:dbsqlok() end status was success dblib.c:1689:dbresults(000000000775B3B0) dblib.c:1694:dbresults: dbresults_state is 5 (_DB_RES_SUCCEED) dblib.c:1679:dbresults returning 1 (SUCCEED) dblib.c:2772:dbcount(000000000775B3B0) dblib.c:3203:dbcancel(000000000775B3B0) query.c:2189:tds_send_cancel: not in_cancel and idle dblib.c:1463:dbclose(000000000775B3B0) dblib.c:243:dblib_del_connection(000007FEF8B0FA70, 00000000075359E0) query.c:3772:tds_disconnect() util.c:165:Changed query state from IDLE to DEAD mem.c:648:tds_free_all_results() dblib.c:290:dblib_release_tds_ctx(1) dblib.c:5873:dbfreebuf(000000000775B3B0) Steve From Steve.Wagner at 49ers.com Wed Nov 29 21:34:36 2017 From: Steve.Wagner at 49ers.com (Wagner, Steve) Date: Thu, 30 Nov 2017 02:34:36 +0000 Subject: [freetds] DB-Lib error message 20017, severity 9:Unexpected EOF from the server Message-ID: <16B74D10F9D66440AE2D7BC2C82642A1506761BE@SFVX2010.sf.NFL.NET> Sorry to repost but I haven't received any response to this email so I don't even know if the original post has been seen. This is a newbie question but how can I see recent activity on this mailing list. The latest post in the archives is from Nov 20. I am subscribed to the list.sd Steve From: Wagner, Steve Sent: Tuesday, November 28, 2017 1:41 PM To: 'freetds at lists.ibiblio.org' Subject: DB-Lib error message 20017, severity 9:Unexpected EOF from the server We've been using pymssql and FreeTDS for over 2 years now without problems. We recently upgraded pymssql to 2.1.3 and also from Python 3.4 to 3.6. Since that upgrade we've been getting the following error intermittently (but frequently). (20017, b'DB-Lib error message 20017, severity 9:\nUnexpected EOF from the server (FBOps-Prod:1433)\nDB-Lib error message 20002, severity 9:\nAdaptive Server connection failed (FBOps-Prod:1433)\n') There is no apparent pattern to the failures that we have been able to discover. Well over 95% of the DB calls succeed. It can fail on any stored proc or sql query. The database calls apparently do not even get to the database because nothing shows up in any DB log or trace. I've scoured the web and come up empty. I've reinstalled pymssql and FreeTDS but it still fails. Failures occur when connected to a DB server that is remote to the app but when connected to localhost. I've checked max number of connections and it's 4096 which should be plenty as there are no more than 10 active users at a time. Below is an excerpt from the TDS log file (full log file at the end). packet.c:639:Received packet 0000 04 01 00 11 00 5c 01 00-fd 00 00 d4 00 00 00 00 |.....\.. ........| 0010 00 - |.| token.c:565:processing result tokens. marker is fd(DONE) token.c:2081:tds_process_end: more_results = 0 was_cancelled = 0 error = 0 done_count_valid = 0 token.c:2098: rows_affected = 0 token.c:2101:tds_process_end() state set to TDS_IDLE util.c:165:Changed query state from READING to IDLE util.c:83:logic error: cannot change query state from IDLE to PENDING I've looked at the relevant code but don't have sufficient knowledge to understand why it's failing. Any help is appreciated. Given that it's sporadic and the packet received just before the failure is identical (or at least very similar), I suspect it might be a networking issue. And that is DEFINITELY beyond my expertise although I'm ready to try anything if given some guidance. Full log below... I appreciate any and all help. Steve log.c:167:Starting log file for FreeTDS 0.95 on 2017-11-28 09:19:48 with debug flags 0x4fff. dblib.c:1160:tdsdbopen(0000000006F7C9B0, FBOps-Prod:1433, [microsoft]) dblib.c:1186:tdsdbopen: dbproc->dbopts = 0000000007422E90 dblib.c:1193:tdsdbopen: tds_set_server(0000000006E3D920, "FBOps-Prod:1433") dblib.c:258:dblib_get_tds_ctx(void) dblib.c:1210:tdsdbopen: About to call tds_read_config_info... config.c:168:Getting connection information for [FBOps-Prod:1433]. config.c:172:Attempting to read conf files. config.c:353:... $FREETDSCONF not set. Trying $FREETDS/etc. config.c:366:... $FREETDS not set. Trying $HOME. config.c:292:Could not open 'C:\Users\prospector.user\AppData\Roaming/.freetds.conf' ((.freetds.conf)). config.c:296:Found conf file 'c:\freetds.conf' (default). config.c:495:Looking for section global. config.c:554: Found section global. config.c:557:Got a match. config.c:580: tds version = '7.3' config.c:886:Setting tds version to 7.3 (0x703). config.c:554: Found section fbops-prod. config.c:568: Reached EOF config.c:495:Looking for section FBOps-Prod:1433. config.c:554: Found section global. config.c:554: Found section fbops-prod. config.c:568: Reached EOF config.c:302:[FBOps-Prod:1433] not found. config.c:353:... $FREETDSCONF not set. Trying $FREETDS/etc. config.c:366:... $FREETDS not set. Trying $HOME. config.c:292:Could not open 'C:\Users\prospector.user\AppData\Roaming/.freetds.conf' ((.freetds.conf)). config.c:296:Found conf file 'c:\freetds.conf' (default). config.c:495:Looking for section global. config.c:554: Found section global. config.c:557:Got a match. config.c:580: tds version = '7.3' config.c:886:Setting tds version to 7.3 (0x703). config.c:554: Found section fbops-prod. config.c:568: Reached EOF config.c:495:Looking for section FBOps-Prod. config.c:554: Found section global. config.c:554: Found section fbops-prod. config.c:557:Got a match. config.c:580: host = 'fbops-prod' config.c:617:Found host entry fbops-prod config.c:620:IP addr is 10.164.222.55. config.c:568: Reached EOF config.c:300:Success: [FBOps-Prod] defined in c:\freetds.conf. config.c:765:Setting 'dump_file' to 'c:\freetds.log' from $TDSDUMP. config.c:689:tds_config_login: client_charset is UTF-8. config.c:696:tds_config_login: database_name is Goldmine. config.c:765:Setting 'dump_file' to 'c:\freetds.log' from $TDSDUMP. dblib.c:1237:tdsdbopen: Calling tds_connect_and_login(00000000075359E0, 0000000006E3DA10) iconv.c:328:tds_iconv_open(00000000075359E0, UTF-8) iconv.c:346:setting up conversions for client charset "UTF-8" iconv.c:348:preparing iconv for "UTF-8" <-> "UCS-2LE" conversion iconv.c:395:preparing iconv for "ISO-8859-1" <-> "UCS-2LE" conversion iconv.c:400:tds_iconv_open: done net.c:202:Connecting to 10.164.222.55 port 1433 (TDS version 7.1) net.c:275:tds_open_socket: connect(2) returned "WSAEWOULDBLOCK: Resource temporarily unavailable." net.c:314:tds_open_socket() succeeded packet.c:740:Sending packet 0000 12 01 00 34 00 00 00 00-00 00 15 00 06 01 00 1b |...4.... ........| 0010 00 01 02 00 1c 00 0c 03-00 28 00 04 ff 08 00 01 |........ .(......| 0020 55 00 00 00 4d 53 53 51-4c 53 65 72 76 65 72 00 |U...MSSQ LServer.| 0030 bc 11 00 00 - |....| packet.c:639:Received packet 0000 04 01 00 25 00 00 01 00-00 00 15 00 06 01 00 1b |...%.... ........| 0010 00 01 02 00 1c 00 01 03-00 1d 00 00 ff 0c 00 14 |........ ........| 0020 57 00 00 00 00 - |W....| login.c:1106:detected flag 0 tls.c:116:in tds_push_func_login tls.c:82:in tds_pull_func_login packet.c:740:Sending packet 0000 12 01 00 5c 00 00 00 00-16 03 01 00 4f 01 00 00 |...\.... ....O...| 0010 4b 03 01 af 63 5a 07 d9-79 47 24 fb 55 ed 88 a0 |K...cZ.. yG$.U...| 0020 9a 82 5b ed e3 70 c1 27-6d c2 9b 47 b7 d0 a9 af |..[..p.' m..G....| 0030 a4 e4 68 00 00 18 00 39-00 38 00 35 00 16 00 13 |..h....9 .8.5....| 0040 00 0a 00 33 00 32 00 2f-00 05 00 04 00 ff 02 01 |...3.2./ ........| 0050 00 00 09 00 23 00 00 00-0f 00 01 01 |....#... ....| tls.c:94:have 0 tls.c:98:before read packet.c:639:Received packet 0000 12 01 04 75 00 00 00 00-16 03 01 04 68 02 00 00 |...u.... ....h...| 0010 4d 03 01 5a 1d 9a b4 c9-30 fb 36 35 f3 31 8f ab |M..Z.... 0.65.1..| 0020 a6 ec 20 2e 78 a4 dd 18-35 7f c6 12 94 d9 da 35 |.. .x... 5......5| 0030 9a 11 0c 20 07 08 00 00-3e c0 5b 8b 15 27 db 2c |... .... >.[..'.,| 0040 9a 2b 21 78 60 39 f2 bd-5e 86 0a bf 1a b0 07 93 |.+!x`9.. ^.......| 0050 71 47 ec e7 00 39 00 00-05 ff 01 00 01 00 0b 00 |qG...9.. ........| 0060 02 03 00 02 00 00 01 fd-30 82 01 f9 30 82 01 62 |........ 0...0..b| 0070 a0 03 02 01 02 02 10 12-4b b2 71 c2 96 23 b0 42 |........ K.q..#.B| 0080 41 e3 e3 28 a3 4a 45 30-0d 06 09 2a 86 48 86 f7 |A..(.JE0 ...*.H..| 0090 0d 01 01 05 05 00 30 3b-31 39 30 37 06 03 55 04 |......0; 1907..U.| 00a0 03 1e 30 00 53 00 53 00-4c 00 5f 00 53 00 65 00 |..0.S.S. L._.S.e.| 00b0 6c 00 66 00 5f 00 53 00-69 00 67 00 6e 00 65 00 |l.f._.S. i.g.n.e.| 00c0 64 00 5f 00 46 00 61 00-6c 00 6c 00 62 00 61 00 |d._.F.a. l.l.b.a.| 00d0 63 00 6b 30 1e 17 0d 31-37 31 31 32 31 31 37 30 |c.k0...1 71121170| 00e0 35 35 34 5a 17 0d 34 37-31 31 32 31 31 37 30 35 |554Z..47 11211705| 00f0 35 34 5a 30 3b 31 39 30-37 06 03 55 04 03 1e 30 |54Z0;190 7..U...0| 0100 00 53 00 53 00 4c 00 5f-00 53 00 65 00 6c 00 66 |.S.S.L._ .S.e.l.f| 0110 00 5f 00 53 00 69 00 67-00 6e 00 65 00 64 00 5f |._.S.i.g .n.e.d._| 0120 00 46 00 61 00 6c 00 6c-00 62 00 61 00 63 00 6b |.F.a.l.l .b.a.c.k| 0130 30 81 9f 30 0d 06 09 2a-86 48 86 f7 0d 01 01 01 |0..0...* .H......| 0140 05 00 03 81 8d 00 30 81-89 02 81 81 00 ca 61 00 |......0. ......a.| 0150 0d a1 71 34 93 f1 82 5d-55 f5 cf 11 26 96 e0 70 |..q4...] U...&..p| 0160 cf 55 c2 20 e3 48 27 e7-12 c5 8d 0d 02 1e 13 68 |.U. .H'. .......h| 0170 17 1b fe 8f 66 4b d0 79-a6 a7 94 0a 5f 0d 47 4c |....fK.y ...._.GL| 0180 04 c0 07 95 37 34 76 64-5c 33 14 96 62 2e 75 44 |....74vd \3..b.uD| 0190 1d 1b 68 00 1b 24 27 6d-d1 fe 17 55 26 71 97 28 |..h..$'m ...U&q.(| 01a0 6f 1a a7 62 2e 78 8f 7d-96 53 44 e7 4c 8a 08 3f |o..b.x.} .SD.L..?| 01b0 cd a7 57 3c 58 80 8f a1-f0 f5 f4 c2 d0 b7 4c c5 |..W 0240 2c 19 bf aa 3d eb 7c 8b-f4 45 48 21 e6 11 a7 37 |,...=.|. .EH!...7| 0250 70 16 f3 d3 aa f8 1e 98-b7 a4 dd 92 db a1 b5 fb |p....... ........| 0260 ae d0 55 bb af 0c 00 02-08 00 80 ff ff ff ff ff |..U..... ........| 0270 ff ff ff c9 0f da a2 21-68 c2 34 c4 c6 62 8b 80 |.......! h.4..b..| 0280 dc 1c d1 29 02 4e 08 8a-67 cc 74 02 0b be a6 3b |...).N.. g.t....;| 0290 13 9b 22 51 4a 08 79 8e-34 04 dd ef 95 19 b3 cd |.."QJ.y. 4.......| 02a0 3a 43 1b 30 2b 0a 6d f2-5f 14 37 4f e1 35 6d 6d |:C.0+.m. _.7O.5mm| 02b0 51 c2 45 e4 85 b5 76 62-5e 7e c6 f4 4c 42 e9 a6 |Q.E...vb ^~..LB..| 02c0 37 ed 6b 0b ff 5c b6 f4-06 b7 ed ee 38 6b fb 5a |7.k..\.. ....8k.Z| 02d0 89 9f a5 ae 9f 24 11 7c-4b 1f e6 49 28 66 51 ec |.....$.| K..I(fQ.| 02e0 e6 53 81 ff ff ff ff ff-ff ff ff 00 80 00 00 00 |.S...... ........| 02f0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 |........ ........| 0300 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 |........ ........| 0310 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 |........ ........| 0320 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 |........ ........| 0330 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 |........ ........| 0340 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 |........ ........| 0350 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 |........ ........| 0360 00 00 00 00 00 00 00 00-00 00 00 00 02 00 80 75 |........ .......u| 0370 eb 3c 53 f2 04 55 1d 8c-37 cd 60 27 3e 07 dc 44 |...D| 0380 ed 4b f7 04 87 9d 13 18-e5 8f 9d 00 b6 b3 53 67 |.K...... ......Sg| 0390 be 7d f9 39 59 df 06 2a-16 9e fa 5c e8 31 54 e0 |.}.9Y..* ...\.1T.| 03a0 ea 4d 2e 0d 85 9c 53 80-d3 a0 97 67 74 df ff ab |.M....S. ...gt...| 03b0 dd f7 ae af 50 5d d7 e4-a0 70 e2 fb a3 3b 59 41 |....P].. .p...;YA| 03c0 98 4f 2a 0f 91 dc 5a bf-22 79 27 db f2 0b 93 9a |.O*...Z. "y'.....| 03d0 8d 46 c5 ec 18 cf d4 36-92 d2 3c 55 57 97 36 ef |.F.....6 ...#8| 0050 f2 bf 39 82 69 4e 93 aa-5d 90 e0 02 88 d4 30 d6 |..9.iN.. ].....0.| 0060 40 45 04 b9 a1 0f 2f 6e-e0 da 2d 4c ca e1 22 2a |@E..../n ..-L.."*| 0070 b5 fc 94 e1 d1 2f 24 20-a3 00 7a 4b 0e c7 ff d1 |...../$ ..zK....| 0080 12 66 84 98 b8 50 3a 16-1e 9c 88 ac 97 1e 09 19 |.f...P:. ........| 0090 a3 c0 d6 14 03 01 00 01-01 16 03 01 00 30 8a 9c |........ .....0..| 00a0 74 4d 32 74 59 cd 96 0e-33 06 ed 27 60 f2 28 3e |tM2tY... 3..'`.(>| 00b0 a3 cc 82 e4 db 69 5d 50-e4 98 7a e4 62 61 5e 3f |.....i]P ..z.ba^?| 00c0 3e 32 bf a1 ce 08 c6 08-09 29 5c 22 c4 33 |>2...... .)\".3| tls.c:82:in tds_pull_func_login tls.c:94:have 0 tls.c:98:before read packet.c:639:Received packet 0000 12 01 00 43 00 00 00 00-14 03 01 00 01 01 16 03 |...C.... ........| 0010 01 00 30 8e 55 4d 00 d4-8a cc 3e c1 bc b6 07 4d |..0.UM.. ..>....M| 0020 ec de 3c c8 2b 8f a1 54-16 71 22 69 14 fb d1 1e |..<.+..T .q"i....| 0030 2b a0 09 1d bb 46 21 67-d5 66 cf fb c1 9f 31 3b |+....F!g .f....1;| 0040 f0 5a 75 - |.Zu| tls.c:101:after read tls.c:94:have 59 tls.c:105:read 5 bytes tls.c:82:in tds_pull_func_login tls.c:94:have 54 tls.c:105:read 1 bytes tls.c:82:in tds_pull_func_login tls.c:94:have 53 tls.c:105:read 5 bytes tls.c:82:in tds_pull_func_login tls.c:94:have 48 tls.c:105:read 48 bytes tls.c:855:handshake succeeded!! login.c:852:quietly sending TDS 7+ login packet token.c:327:tds_process_login_tokens() packet.c:639:Received packet 0000 04 01 01 89 00 4e 01 00-e3 1f 00 01 08 47 00 6f |.....N.. .....G.o| 0010 00 6c 00 64 00 6d 00 69-00 6e 00 65 00 06 6d 00 |.l.d.m.i .n.e..m.| 0020 61 00 73 00 74 00 65 00-72 00 ab 6e 00 45 16 00 |a.s.t.e. r..n.E..| 0030 00 02 00 27 00 43 00 68-00 61 00 6e 00 67 00 65 |...'.C.h .a.n.g.e| 0040 00 64 00 20 00 64 00 61-00 74 00 61 00 62 00 61 |.d. .d.a .t.a.b.a| 0050 00 73 00 65 00 20 00 63-00 6f 00 6e 00 74 00 65 |.s.e. .c .o.n.t.e| 0060 00 78 00 74 00 20 00 74-00 6f 00 20 00 27 00 47 |.x.t. .t .o. .'.G| 0070 00 6f 00 6c 00 64 00 6d-00 69 00 6e 00 65 00 27 |.o.l.d.m .i.n.e.'| 0080 00 2e 00 0a 46 00 42 00-4f 00 50 00 53 00 2d 00 |....F.B. O.P.S.-.| 0090 50 00 52 00 4f 00 44 00-00 01 00 e3 08 00 07 05 |P.R.O.D. ........| 00a0 09 04 d0 00 34 00 e3 17-00 02 0a 75 00 73 00 5f |....4... ...u.s._| 00b0 00 65 00 6e 00 67 00 6c-00 69 00 73 00 68 00 00 |.e.n.g.l .i.s.h..| 00c0 ab 6e 00 47 16 00 00 01-00 27 00 43 00 68 00 61 |.n.G.... .'.C.h.a| 00d0 00 6e 00 67 00 65 00 64-00 20 00 6c 00 61 00 6e |.n.g.e.d . .l.a.n| 00e0 00 67 00 75 00 61 00 67-00 65 00 20 00 73 00 65 |.g.u.a.g .e. .s.e| 00f0 00 74 00 74 00 69 00 6e-00 67 00 20 00 74 00 6f |.t.t.i.n .g. .t.o| 0100 00 20 00 75 00 73 00 5f-00 65 00 6e 00 67 00 6c |. .u.s._ .e.n.g.l| 0110 00 69 00 73 00 68 00 2e-00 0a 46 00 42 00 4f 00 |.i.s.h.. ..F.B.O.| 0120 50 00 53 00 2d 00 50 00-52 00 4f 00 44 00 00 01 |P.S.-.P. R.O.D...| 0130 00 ad 36 00 01 71 00 00-01 16 4d 00 69 00 63 00 |..6..q.. ..M.i.c.| 0140 72 00 6f 00 73 00 6f 00-66 00 74 00 20 00 53 00 |r.o.s.o. f.t. .S.| 0150 51 00 4c 00 20 00 53 00-65 00 72 00 76 00 65 00 |Q.L. .S. e.r.v.e.| 0160 72 00 00 00 00 00 0c 00-14 57 e3 13 00 04 04 34 |r....... .W.....4| 0170 00 30 00 39 00 36 00 04-34 00 30 00 39 00 36 00 |.0.9.6.. 4.0.9.6.| 0180 fd 00 00 00 00 00 00 00-00 |........ .| token.c:336:looking for login token, got e3(ENVCHANGE) token.c:116:tds_process_default_tokens() marker is e3(ENVCHANGE) dblib.c:312:db_env_chg(00000000075359E0, 1, master, Goldmine) token.c:336:looking for login token, got ab(INFO) token.c:116:tds_process_default_tokens() marker is ab(INFO) token.c:2345:tds_process_msg() reading message 5701 from server token.c:2417:tds_process_msg() calling client msg handler dbutil.c:76:_dblib_handle_info_message(0000000002C2CFA0, 00000000075359E0, 000000000A58B3F0) dbutil.c:77:msgno 5701: "Changed database context to 'Goldmine'." token.c:2430:tds_process_msg() returning TDS_SUCCESS token.c:336:looking for login token, got e3(ENVCHANGE) token.c:116:tds_process_default_tokens() marker is e3(ENVCHANGE) token.c:2179:tds_process_env_chg(): 5 bytes of collation data received token.c:2180:tds->conn->collation was 0000 00 00 00 00 00 - |.....| iconv.c:796:setting server single-byte charset to "CP1252" token.c:2190:tds->conn->collation now 0000 09 04 d0 00 34 - |....4| token.c:336:looking for login token, got e3(ENVCHANGE) token.c:116:tds_process_default_tokens() marker is e3(ENVCHANGE) dblib.c:312:db_env_chg(00000000075359E0, 2, , us_english) token.c:336:looking for login token, got ab(INFO) token.c:116:tds_process_default_tokens() marker is ab(INFO) token.c:2345:tds_process_msg() reading message 5703 from server token.c:2417:tds_process_msg() calling client msg handler dbutil.c:76:_dblib_handle_info_message(0000000002C2CFA0, 00000000075359E0, 000000000A58B3F0) dbutil.c:77:msgno 5703: "Changed language setting to us_english." token.c:2430:tds_process_msg() returning TDS_SUCCESS token.c:336:looking for login token, got ad(LOGINACK) token.c:374:server reports TDS version 71.0.0.1 token.c:376:Product name for 0x71000001 is 2000 SP1 token.c:408:Product version 8C001457 token.c:336:looking for login token, got e3(ENVCHANGE) token.c:116:tds_process_default_tokens() marker is e3(ENVCHANGE) token.c:2236:changing block size from 4096 to 4096 dblib.c:312:db_env_chg(00000000075359E0, 4, 4096, 4096) token.c:336:looking for login token, got fd(DONE) token.c:116:tds_process_default_tokens() marker is fd(DONE) token.c:2081:tds_process_end: more_results = 0 was_cancelled = 0 error = 0 done_count_valid = 0 token.c:2098: rows_affected = 0 token.c:2101:tds_process_end() state set to TDS_IDLE token.c:440:tds_process_login_tokens() returning TDS_SUCCESS dblib.c:224:dblib_add_connection(000007FEF8B0FA70, 00000000075359E0) dblib.c:1280:tdsdbopen: Returning dbproc = 000000000775B3B0 dblib.c:743:dbloginfree(0000000006F7C9B0) dblib.c:1338:dbcmd(000000000775B3B0, SET ARITHABORT ON;SET CONCAT_NULL_YIELDS_NULL ON;SET ANSI_NULLS ON;SET ANSI_NULL_DFLT_ON ON;SET ANSI_PADDING ON;SET ANSI_WARNINGS ON;SET ANSI_NULL_DFLT_ON ON;SET CURSOR_CLOSE_ON_COMMIT ON;SET QUOTED_IDENTIFIER ON;SET TEXTSIZE 2147483647;) dblib.c:1344:dbcmd() bufsz = 0 dblib.c:6845:dbsqlsend(000000000775B3B0) mem.c:648:tds_free_all_results() util.c:165:Changed query state from IDLE to WRITING util.c:165:Changed query state from WRITING to PENDING packet.c:740:Sending packet 0000 01 01 01 e2 00 00 01 00-53 00 45 00 54 00 20 00 |........ S.E.T. .| 0010 41 00 52 00 49 00 54 00-48 00 41 00 42 00 4f 00 |A.R.I.T. H.A.B.O.| 0020 52 00 54 00 20 00 4f 00-4e 00 3b 00 53 00 45 00 |R.T. .O. N.;.S.E.| 0030 54 00 20 00 43 00 4f 00-4e 00 43 00 41 00 54 00 |T. .C.O. N.C.A.T.| 0040 5f 00 4e 00 55 00 4c 00-4c 00 5f 00 59 00 49 00 |_.N.U.L. L._.Y.I.| 0050 45 00 4c 00 44 00 53 00-5f 00 4e 00 55 00 4c 00 |E.L.D.S. _.N.U.L.| 0060 4c 00 20 00 4f 00 4e 00-3b 00 53 00 45 00 54 00 |L. .O.N. ;.S.E.T.| 0070 20 00 41 00 4e 00 53 00-49 00 5f 00 4e 00 55 00 | .A.N.S. I._.N.U.| 0080 4c 00 4c 00 53 00 20 00-4f 00 4e 00 3b 00 53 00 |L.L.S. . O.N.;.S.| 0090 45 00 54 00 20 00 41 00-4e 00 53 00 49 00 5f 00 |E.T. .A. N.S.I._.| 00a0 4e 00 55 00 4c 00 4c 00-5f 00 44 00 46 00 4c 00 |N.U.L.L. _.D.F.L.| 00b0 54 00 5f 00 4f 00 4e 00-20 00 4f 00 4e 00 3b 00 |T._.O.N. .O.N.;.| 00c0 53 00 45 00 54 00 20 00-41 00 4e 00 53 00 49 00 |S.E.T. . A.N.S.I.| 00d0 5f 00 50 00 41 00 44 00-44 00 49 00 4e 00 47 00 |_.P.A.D. D.I.N.G.| 00e0 20 00 4f 00 4e 00 3b 00-53 00 45 00 54 00 20 00 | .O.N.;. S.E.T. .| 00f0 41 00 4e 00 53 00 49 00-5f 00 57 00 41 00 52 00 |A.N.S.I. _.W.A.R.| 0100 4e 00 49 00 4e 00 47 00-53 00 20 00 4f 00 4e 00 |N.I.N.G. S. .O.N.| 0110 3b 00 53 00 45 00 54 00-20 00 41 00 4e 00 53 00 |;.S.E.T. .A.N.S.| 0120 49 00 5f 00 4e 00 55 00-4c 00 4c 00 5f 00 44 00 |I._.N.U. L.L._.D.| 0130 46 00 4c 00 54 00 5f 00-4f 00 4e 00 20 00 4f 00 |F.L.T._. O.N. .O.| 0140 4e 00 3b 00 53 00 45 00-54 00 20 00 43 00 55 00 |N.;.S.E. T. .C.U.| 0150 52 00 53 00 4f 00 52 00-5f 00 43 00 4c 00 4f 00 |R.S.O.R. _.C.L.O.| 0160 53 00 45 00 5f 00 4f 00-4e 00 5f 00 43 00 4f 00 |S.E._.O. N._.C.O.| 0170 4d 00 4d 00 49 00 54 00-20 00 4f 00 4e 00 3b 00 |M.M.I.T. .O.N.;.| 0180 53 00 45 00 54 00 20 00-51 00 55 00 4f 00 54 00 |S.E.T. . Q.U.O.T.| 0190 45 00 44 00 5f 00 49 00-44 00 45 00 4e 00 54 00 |E.D._.I. D.E.N.T.| 01a0 49 00 46 00 49 00 45 00-52 00 20 00 4f 00 4e 00 |I.F.I.E. R. .O.N.| 01b0 3b 00 53 00 45 00 54 00-20 00 54 00 45 00 58 00 |;.S.E.T. .T.E.X.| 01c0 54 00 53 00 49 00 5a 00-45 00 20 00 32 00 31 00 |T.S.I.Z. E. .2.1.| 01d0 34 00 37 00 34 00 38 00-33 00 36 00 34 00 37 00 |4.7.4.8. 3.6.4.7.| 01e0 3b 00 - |;.| dblib.c:4625:dbsqlok(000000000775B3B0) dblib.c:4654:dbsqlok() not done, calling tds_process_tokens() token.c:550:tds_process_tokens(00000000075359E0, 000000000A58B918, 000000000A58B910, 0x6914) util.c:165:Changed query state from PENDING to READING packet.c:639:Received packet 0000 04 01 00 59 00 4e 01 00-fd 01 00 b9 00 00 00 00 |...Y.N.. ........| 0010 00 fd 01 00 b9 00 00 00-00 00 fd 01 00 b9 00 00 |........ ........| 0020 00 00 00 fd 01 00 b9 00-00 00 00 00 fd 01 00 b9 |........ ........| 0030 00 00 00 00 00 fd 01 00-b9 00 00 00 00 00 fd 01 |........ ........| 0040 00 b9 00 00 00 00 00 fd-01 00 b9 00 00 00 00 00 |........ ........| 0050 fd 00 00 be 00 00 00 00-00 |........ .| token.c:565:processing result tokens. marker is fd(DONE) token.c:2081:tds_process_end: more_results = 1 was_cancelled = 0 error = 0 done_count_valid = 0 token.c:2098: rows_affected = 0 util.c:165:Changed query state from READING to PENDING dblib.c:4687:dbsqlok() end status is SUCCEED dblib.c:4698:dbsqlok() end status was success dblib.c:3203:dbcancel(000000000775B3B0) query.c:2189:tds_send_cancel: not in_cancel and not idle packet.c:770:Sending packet 0000 06 01 00 08 00 00 01 00- |........| token.c:550:tds_process_tokens(00000000075359E0, 000000000A58B900, 0000000000000000, 0x0) util.c:165:Changed query state from PENDING to READING token.c:565:processing result tokens. marker is fd(DONE) token.c:2081:tds_process_end: more_results = 1 was_cancelled = 0 error = 0 done_count_valid = 0 token.c:2098: rows_affected = 0 token.c:565:processing result tokens. marker is fd(DONE) token.c:2081:tds_process_end: more_results = 1 was_cancelled = 0 error = 0 done_count_valid = 0 token.c:2098: rows_affected = 0 token.c:565:processing result tokens. marker is fd(DONE) token.c:2081:tds_process_end: more_results = 1 was_cancelled = 0 error = 0 done_count_valid = 0 token.c:2098: rows_affected = 0 token.c:565:processing result tokens. marker is fd(DONE) token.c:2081:tds_process_end: more_results = 1 was_cancelled = 0 error = 0 done_count_valid = 0 token.c:2098: rows_affected = 0 token.c:565:processing result tokens. marker is fd(DONE) token.c:2081:tds_process_end: more_results = 1 was_cancelled = 0 error = 0 done_count_valid = 0 token.c:2098: rows_affected = 0 token.c:565:processing result tokens. marker is fd(DONE) token.c:2081:tds_process_end: more_results = 1 was_cancelled = 0 error = 0 done_count_valid = 0 token.c:2098: rows_affected = 0 token.c:565:processing result tokens. marker is fd(DONE) token.c:2081:tds_process_end: more_results = 1 was_cancelled = 0 error = 0 done_count_valid = 0 token.c:2098: rows_affected = 0 token.c:565:processing result tokens. marker is fd(DONE) token.c:2081:tds_process_end: more_results = 0 was_cancelled = 0 error = 0 done_count_valid = 0 token.c:2098: rows_affected = 0 packet.c:639:Received packet 0000 04 01 00 11 00 4e 01 00-fd 20 00 fd 00 00 00 00 |.....N.. . ......| 0010 00 - |.| token.c:565:processing result tokens. marker is fd(DONE) token.c:2081:tds_process_end: more_results = 0 was_cancelled = 1 error = 0 done_count_valid = 0 token.c:2098: rows_affected = 0 token.c:2101:tds_process_end() state set to TDS_IDLE util.c:165:Changed query state from READING to IDLE util.c:83:logic error: cannot change query state from IDLE to PENDING util.c:165:Changed query state from IDLE to IDLE dblib.c:1419:dbuse(000000000775B3B0, Goldmine) dblib.c:1338:dbcmd(000000000775B3B0, use [Goldmine]) dblib.c:1344:dbcmd() bufsz = 238 dblib.c:5873:dbfreebuf(000000000775B3B0) dblib.c:1392:dbsqlexec(000000000775B3B0) dblib.c:6845:dbsqlsend(000000000775B3B0) mem.c:648:tds_free_all_results() util.c:165:Changed query state from IDLE to WRITING util.c:165:Changed query state from WRITING to PENDING packet.c:740:Sending packet 0000 01 01 00 24 00 00 01 00-75 00 73 00 65 00 20 00 |...$.... u.s.e. .| 0010 5b 00 47 00 6f 00 6c 00-64 00 6d 00 69 00 6e 00 |[.G.o.l. d.m.i.n.| 0020 65 00 5d 00 - |e.].| dblib.c:4625:dbsqlok(000000000775B3B0) dblib.c:4654:dbsqlok() not done, calling tds_process_tokens() token.c:550:tds_process_tokens(00000000075359E0, 000000000A58B8D8, 000000000A58B8D0, 0x6914) util.c:165:Changed query state from PENDING to READING packet.c:639:Received packet 0000 04 01 00 b3 00 4e 01 00-e3 23 00 01 08 47 00 6f |.....N.. .#...G.o| 0010 00 6c 00 64 00 6d 00 69-00 6e 00 65 00 08 47 00 |.l.d.m.i .n.e..G.| 0020 6f 00 6c 00 64 00 6d 00-69 00 6e 00 65 00 ab 6e |o.l.d.m. i.n.e..n| 0030 00 45 16 00 00 01 00 27-00 43 00 68 00 61 00 6e |.E.....' .C.h.a.n| 0040 00 67 00 65 00 64 00 20-00 64 00 61 00 74 00 61 |.g.e.d. .d.a.t.a| 0050 00 62 00 61 00 73 00 65-00 20 00 63 00 6f 00 6e |.b.a.s.e . .c.o.n| 0060 00 74 00 65 00 78 00 74-00 20 00 74 00 6f 00 20 |.t.e.x.t . .t.o. | 0070 00 27 00 47 00 6f 00 6c-00 64 00 6d 00 69 00 6e |.'.G.o.l .d.m.i.n| 0080 00 65 00 27 00 2e 00 0a-46 00 42 00 4f 00 50 00 |.e.'.... F.B.O.P.| 0090 53 00 2d 00 50 00 52 00-4f 00 44 00 00 01 00 e3 |S.-.P.R. O.D.....| 00a0 08 00 07 05 09 04 d0 00-34 00 fd 00 00 e2 00 00 |........ 4.......| 00b0 00 00 00 - |...| token.c:565:processing result tokens. marker is e3(ENVCHANGE) token.c:116:tds_process_default_tokens() marker is e3(ENVCHANGE) dblib.c:312:db_env_chg(00000000075359E0, 1, Goldmine, Goldmine) token.c:565:processing result tokens. marker is ab(INFO) token.c:116:tds_process_default_tokens() marker is ab(INFO) token.c:2345:tds_process_msg() reading message 5701 from server token.c:2417:tds_process_msg() calling client msg handler dbutil.c:76:_dblib_handle_info_message(0000000002C2CFA0, 00000000075359E0, 000000000A58B750) dbutil.c:77:msgno 5701: "Changed database context to 'Goldmine'." token.c:2430:tds_process_msg() returning TDS_SUCCESS token.c:565:processing result tokens. marker is e3(ENVCHANGE) token.c:116:tds_process_default_tokens() marker is e3(ENVCHANGE) token.c:2179:tds_process_env_chg(): 5 bytes of collation data received token.c:2180:tds->conn->collation was 0000 09 04 d0 00 34 - |....4| iconv.c:796:setting server single-byte charset to "CP1252" token.c:2190:tds->conn->collation now 0000 09 04 d0 00 34 - |....4| token.c:565:processing result tokens. marker is fd(DONE) token.c:2081:tds_process_end: more_results = 0 was_cancelled = 0 error = 0 done_count_valid = 0 token.c:2098: rows_affected = 0 token.c:2101:tds_process_end() state set to TDS_IDLE util.c:165:Changed query state from READING to IDLE util.c:83:logic error: cannot change query state from IDLE to PENDING util.c:165:Changed query state from IDLE to IDLE dblib.c:4687:dbsqlok() end status is SUCCEED dblib.c:4698:dbsqlok() end status was success dblib.c:1689:dbresults(000000000775B3B0) dblib.c:1694:dbresults: dbresults_state is 5 (_DB_RES_SUCCEED) dblib.c:1679:dbresults returning 1 (SUCCEED) dblib.c:5846:dbcanquery(000000000775B3B0) token.c:550:tds_process_tokens(00000000075359E0, 000000000A58B8D0, 0000000000000000, 0x108) token.c:553:tds_process_tokens() state is COMPLETED dblib.c:3203:dbcancel(000000000775B3B0) query.c:2189:tds_send_cancel: not in_cancel and idle dblib.c:1338:dbcmd(000000000775B3B0, BEGIN TRAN) dblib.c:1344:dbcmd() bufsz = 15 dblib.c:5873:dbfreebuf(000000000775B3B0) dblib.c:6845:dbsqlsend(000000000775B3B0) mem.c:648:tds_free_all_results() util.c:165:Changed query state from IDLE to WRITING util.c:165:Changed query state from WRITING to PENDING packet.c:740:Sending packet 0000 01 01 00 1c 00 00 01 00-42 00 45 00 47 00 49 00 |........ B.E.G.I.| 0010 4e 00 20 00 54 00 52 00-41 00 4e 00 |N. .T.R. A.N.| dblib.c:4625:dbsqlok(000000000775B3B0) dblib.c:4654:dbsqlok() not done, calling tds_process_tokens() token.c:550:tds_process_tokens(00000000075359E0, 000000000A58B828, 000000000A58B820, 0x6914) util.c:165:Changed query state from PENDING to READING packet.c:639:Received packet 0000 04 01 00 11 00 4e 01 00-fd 00 00 d4 00 00 00 00 |.....N.. ........| 0010 00 - |.| token.c:565:processing result tokens. marker is fd(DONE) token.c:2081:tds_process_end: more_results = 0 was_cancelled = 0 error = 0 done_count_valid = 0 token.c:2098: rows_affected = 0 token.c:2101:tds_process_end() state set to TDS_IDLE util.c:165:Changed query state from READING to IDLE util.c:83:logic error: cannot change query state from IDLE to PENDING util.c:165:Changed query state from IDLE to IDLE dblib.c:4687:dbsqlok() end status is SUCCEED dblib.c:4698:dbsqlok() end status was success dblib.c:1689:dbresults(000000000775B3B0) dblib.c:1694:dbresults: dbresults_state is 5 (_DB_RES_SUCCEED) dblib.c:1679:dbresults returning 1 (SUCCEED) dblib.c:2772:dbcount(000000000775B3B0) dblib.c:3203:dbcancel(000000000775B3B0) query.c:2189:tds_send_cancel: not in_cancel and idle dblib.c:3203:dbcancel(000000000775B3B0) query.c:2189:tds_send_cancel: not in_cancel and idle dblib.c:1338:dbcmd(000000000775B3B0, sp_PlayerFactors_iud 54, N'U', 241406, 236120, 501, 74815, 7, 1) dblib.c:1344:dbcmd() bufsz = 11 dblib.c:5873:dbfreebuf(000000000775B3B0) dblib.c:6845:dbsqlsend(000000000775B3B0) mem.c:648:tds_free_all_results() util.c:165:Changed query state from IDLE to WRITING util.c:165:Changed query state from WRITING to PENDING packet.c:740:Sending packet 0000 01 01 00 86 00 00 01 00-73 00 70 00 5f 00 50 00 |........ s.p._.P.| 0010 6c 00 61 00 79 00 65 00-72 00 46 00 61 00 63 00 |l.a.y.e. r.F.a.c.| 0020 74 00 6f 00 72 00 73 00-5f 00 69 00 75 00 64 00 |t.o.r.s. _.i.u.d.| 0030 20 00 35 00 34 00 2c 00-20 00 4e 00 27 00 55 00 | .5.4.,. .N.'.U.| 0040 27 00 2c 00 20 00 32 00-34 00 31 00 34 00 30 00 |'.,. .2. 4.1.4.0.| 0050 36 00 2c 00 20 00 32 00-33 00 36 00 31 00 32 00 |6.,. .2. 3.6.1.2.| 0060 30 00 2c 00 20 00 35 00-30 00 31 00 2c 00 20 00 |0.,. .5. 0.1.,. .| 0070 37 00 34 00 38 00 31 00-35 00 2c 00 20 00 37 00 |7.4.8.1. 5.,. .7.| 0080 2c 00 20 00 31 00 - |,. .1.| dblib.c:4625:dbsqlok(000000000775B3B0) dblib.c:4654:dbsqlok() not done, calling tds_process_tokens() token.c:550:tds_process_tokens(00000000075359E0, 000000000A58BB08, 000000000A58BB00, 0x6914) util.c:165:Changed query state from PENDING to READING packet.c:639:Received packet 0000 04 01 00 7b 00 4e 01 00-81 03 00 00 00 21 00 a7 |...{.N.. .....!..| 0010 32 00 09 04 d0 00 34 06-52 00 65 00 73 00 75 00 |2.....4. R.e.s.u.| 0020 6c 00 74 00 00 00 21 00-26 04 0a 50 00 72 00 69 |l.t...!. &..P.r.i| 0030 00 6d 00 61 00 72 00 79-00 4b 00 65 00 79 00 00 |.m.a.r.y .K.e.y..| 0040 00 21 00 26 04 07 4d 00-65 00 73 00 73 00 61 00 |.!.&..M. e.s.s.a.| 0050 67 00 65 00 d1 07 00 55-70 64 61 74 65 64 04 fe |g.e....U pdated..| 0060 ae 03 00 00 ff 01 00 c1-00 01 00 00 00 79 00 00 |........ .....y..| 0070 00 00 fe 00 00 e0 00 00-00 00 00 |........ ...| token.c:565:processing result tokens. marker is 81(TDS7_RESULT) token.c:1574:processing TDS7 result metadata. mem.c:648:tds_free_all_results() token.c:1599:set current_results (3 columns) to tds->res_info token.c:1606:setting up 3 columns token.c:3165:adjust_character_column_size: Server charset: CP1252 Server column_size: 50 Client charset: UTF-8 Client column_size: 200 token.c:1543:tds7_get_data_info: colname = Result type = 39 (varchar) server's type = 167 (xvarchar) column_varint_size = 2 column_size = 200 (50 on server) token.c:1543:tds7_get_data_info: colname = PrimaryKey type = 38 (integer-null) server's type = 38 (integer-null) column_varint_size = 1 column_size = 4 (4 on server) token.c:1543:tds7_get_data_info: colname = Message type = 38 (integer-null) server's type = 38 (integer-null) column_varint_size = 1 column_size = 4 (4 on server) token.c:1615: name size/wsize type/wtype utype token.c:1616: -------------------- --------------- --------------- ------- token.c:1621: Result 200/50 39/167 0 token.c:1621: PrimaryKey 4/4 38/38 0 token.c:1621: Message 4/4 38/38 0 util.c:165:Changed query state from READING to PENDING dblib.c:4680:dbsqlok() found result token dblib.c:1689:dbresults(000000000775B3B0) dblib.c:1694:dbresults: dbresults_state is 1 (_DB_RES_RESULTSET_EMPTY) token.c:550:tds_process_tokens(00000000075359E0, 000000000A58BA50, 000000000A58BA58, 0x6914) util.c:165:Changed query state from PENDING to READING token.c:565:processing result tokens. marker is d1(ROW) token.c:681:tds_process_tokens::SET_RETURN stopping on current token util.c:165:Changed query state from READING to PENDING dblib.c:1715:dbresults() tds_process_tokens returned 0 (TDS_SUCCESS), result_type TDS_ROW_RESULT dblib.c:1679:dbresults returning 1 (SUCCEED) dblib.c:1827:dbnumcols(000000000775B3B0) dblib.c:2772:dbcount(000000000775B3B0) dblib.c:1827:dbnumcols(000000000775B3B0) dblib.c:1853:dbcolname(000000000775B3B0, 1) dblib.c:2841:dbcoltype(000000000775B3B0, 1) dblib.c:1853:dbcolname(000000000775B3B0, 2) dblib.c:2841:dbcoltype(000000000775B3B0, 2) dblib.c:1853:dbcolname(000000000775B3B0, 3) dblib.c:2841:dbcoltype(000000000775B3B0, 3) dblib.c:2031:dbnextrow(000000000775B3B0) dblib.c:2043:dbnextrow() dbresults_state = 2 (_DB_RES_RESULTSET_ROWS) token.c:550:tds_process_tokens(00000000075359E0, 000000000A58BB40, 0000000000000000, 0x1508) util.c:165:Changed query state from PENDING to READING token.c:565:processing result tokens. marker is d1(ROW) token.c:1952:tds_process_row(): reading column 0 data.c:534:tds_get_data: type 39, varint size 2 data.c:587:tds_get_data(): wire column size is 7 token.c:1952:tds_process_row(): reading column 1 data.c:534:tds_get_data: type 38, varint size 1 data.c:587:tds_get_data(): wire column size is 4 token.c:1952:tds_process_row(): reading column 2 data.c:534:tds_get_data: type 38, varint size 1 data.c:587:tds_get_data(): wire column size is -1 util.c:165:Changed query state from READING to PENDING buffering.h:305:buffer_transfer_bound_data(000000000775B3C0 4040 -1 000000000775B3B0 0) dblib.c:2117:leaving dbnextrow() returning REG_ROW/MORE_ROWS dblib.c:3172:dbdata(000000000775B3B0, 1) dblib.c:2841:dbcoltype(000000000775B3B0, 1) dblib.c:3143:dbdatlen(000000000775B3B0, 1) dblib.c:3151:dbdatlen() type = 39, len= 7 dblib.c:3172:dbdata(000000000775B3B0, 2) dblib.c:2841:dbcoltype(000000000775B3B0, 2) dblib.c:3143:dbdatlen(000000000775B3B0, 2) dblib.c:3151:dbdatlen() type = 38, len= 4 dblib.c:3172:dbdata(000000000775B3B0, 3) dblib.c:2841:dbcoltype(000000000775B3B0, 3) dblib.c:3143:dbdatlen(000000000775B3B0, 3) dblib.c:3151:dbdatlen() type = 38, len= 0 dblib.c:2031:dbnextrow(000000000775B3B0) dblib.c:2043:dbnextrow() dbresults_state = 2 (_DB_RES_RESULTSET_ROWS) token.c:550:tds_process_tokens(00000000075359E0, 000000000A58BB40, 0000000000000000, 0x1508) util.c:165:Changed query state from PENDING to READING token.c:565:processing result tokens. marker is ff(DONEINPROC) token.c:2081:tds_process_end: more_results = 1 was_cancelled = 0 error = 0 done_count_valid = 0 token.c:2098: rows_affected = 1 util.c:165:Changed query state from READING to PENDING dblib.c:2117:leaving dbnextrow() returning NO_MORE_ROWS dblib.c:2772:dbcount(000000000775B3B0) dblib.c:3203:dbcancel(000000000775B3B0) query.c:2189:tds_send_cancel: not in_cancel and not idle packet.c:770:Sending packet 0000 06 01 00 08 00 00 01 00- |........| token.c:550:tds_process_tokens(00000000075359E0, 000000000A58BB60, 0000000000000000, 0x0) util.c:165:Changed query state from PENDING to READING token.c:565:processing result tokens. marker is 79(RETURNSTATUS) token.c:712:tds_process_tokens: return status is 0 token.c:565:processing result tokens. marker is fe(DONEPROC) token.c:2081:tds_process_end: more_results = 0 was_cancelled = 0 error = 0 done_count_valid = 0 token.c:2098: rows_affected = 0 packet.c:639:Received packet 0000 04 01 00 11 00 4e 01 00-fd 20 00 fd 00 00 00 00 |.....N.. . ......| 0010 00 - |.| token.c:565:processing result tokens. marker is fd(DONE) token.c:2081:tds_process_end: more_results = 0 was_cancelled = 1 error = 0 done_count_valid = 0 token.c:2098: rows_affected = 0 token.c:2101:tds_process_end() state set to TDS_IDLE util.c:165:Changed query state from READING to IDLE util.c:83:logic error: cannot change query state from IDLE to PENDING util.c:165:Changed query state from IDLE to IDLE dblib.c:1338:dbcmd(000000000775B3B0, COMMIT TRAN) dblib.c:1344:dbcmd() bufsz = 64 dblib.c:5873:dbfreebuf(000000000775B3B0) dblib.c:6845:dbsqlsend(000000000775B3B0) mem.c:648:tds_free_all_results() util.c:165:Changed query state from IDLE to WRITING util.c:165:Changed query state from WRITING to PENDING packet.c:740:Sending packet 0000 01 01 00 1e 00 00 01 00-43 00 4f 00 4d 00 4d 00 |........ C.O.M.M.| 0010 49 00 54 00 20 00 54 00-52 00 41 00 4e 00 |I.T. .T. R.A.N.| dblib.c:4625:dbsqlok(000000000775B3B0) dblib.c:4654:dbsqlok() not done, calling tds_process_tokens() token.c:550:tds_process_tokens(00000000075359E0, 000000000A58BBA8, 000000000A58BBA0, 0x6914) util.c:165:Changed query state from PENDING to READING packet.c:639:Received packet 0000 04 01 00 11 00 4e 01 00-fd 00 00 d5 00 00 00 00 |.....N.. ........| 0010 00 - |.| token.c:565:processing result tokens. marker is fd(DONE) token.c:2081:tds_process_end: more_results = 0 was_cancelled = 0 error = 0 done_count_valid = 0 token.c:2098: rows_affected = 0 token.c:2101:tds_process_end() state set to TDS_IDLE util.c:165:Changed query state from READING to IDLE util.c:83:logic error: cannot change query state from IDLE to PENDING util.c:165:Changed query state from IDLE to IDLE dblib.c:4687:dbsqlok() end status is SUCCEED dblib.c:4698:dbsqlok() end status was success dblib.c:1689:dbresults(000000000775B3B0) dblib.c:1694:dbresults: dbresults_state is 5 (_DB_RES_SUCCEED) dblib.c:1679:dbresults returning 1 (SUCCEED) dblib.c:2772:dbcount(000000000775B3B0) dblib.c:3203:dbcancel(000000000775B3B0) query.c:2189:tds_send_cancel: not in_cancel and idle dblib.c:3203:dbcancel(000000000775B3B0) query.c:2189:tds_send_cancel: not in_cancel and idle dblib.c:1338:dbcmd(000000000775B3B0, BEGIN TRAN) dblib.c:1344:dbcmd() bufsz = 12 dblib.c:5873:dbfreebuf(000000000775B3B0) dblib.c:6845:dbsqlsend(000000000775B3B0) mem.c:648:tds_free_all_results() util.c:165:Changed query state from IDLE to WRITING util.c:165:Changed query state from WRITING to PENDING packet.c:740:Sending packet 0000 01 01 00 1c 00 00 01 00-42 00 45 00 47 00 49 00 |........ B.E.G.I.| 0010 4e 00 20 00 54 00 52 00-41 00 4e 00 |N. .T.R. A.N.| dblib.c:4625:dbsqlok(000000000775B3B0) dblib.c:4654:dbsqlok() not done, calling tds_process_tokens() token.c:550:tds_process_tokens(00000000075359E0, 000000000A58BBA8, 000000000A58BBA0, 0x6914) util.c:165:Changed query state from PENDING to READING packet.c:639:Received packet 0000 04 01 00 11 00 4e 01 00-fd 00 00 d4 00 00 00 00 |.....N.. ........| 0010 00 - |.| token.c:565:processing result tokens. marker is fd(DONE) token.c:2081:tds_process_end: more_results = 0 was_cancelled = 0 error = 0 done_count_valid = 0 token.c:2098: rows_affected = 0 token.c:2101:tds_process_end() state set to TDS_IDLE util.c:165:Changed query state from READING to IDLE util.c:83:logic error: cannot change query state from IDLE to PENDING util.c:165:Changed query state from IDLE to IDLE dblib.c:4687:dbsqlok() end status is SUCCEED dblib.c:4698:dbsqlok() end status was success dblib.c:1689:dbresults(000000000775B3B0) dblib.c:1694:dbresults: dbresults_state is 5 (_DB_RES_SUCCEED) dblib.c:1679:dbresults returning 1 (SUCCEED) dblib.c:2772:dbcount(000000000775B3B0) dblib.c:3203:dbcancel(000000000775B3B0) query.c:2189:tds_send_cancel: not in_cancel and idle dblib.c:1463:dbclose(000000000775B3B0) dblib.c:243:dblib_del_connection(000007FEF8B0FA70, 00000000075359E0) query.c:3772:tds_disconnect() util.c:165:Changed query state from IDLE to DEAD mem.c:648:tds_free_all_results() dblib.c:290:dblib_release_tds_ctx(1) dblib.c:5873:dbfreebuf(000000000775B3B0) Steve From freddy77 at gmail.com Tue Dec 12 07:52:37 2017 From: freddy77 at gmail.com (Frediano Ziglio) Date: Tue, 12 Dec 2017 12:52:37 +0000 Subject: [freetds] TDS Handshake failed when connecting to MS SQL Server 2017 on Windows In-Reply-To: <1d64417b-9adb-57e8-9f95-82f001cc37a9@4js.com> References: <1d64417b-9adb-57e8-9f95-82f001cc37a9@4js.com> Message-ID: 2017-12-11 16:08 GMT+00:00 Sebastien FLAESCH : > Hello, > > We try to connect with FreeTDS 1.00.15 from HP/UX to SQL Server 2017 on > Linux or Windows. > > On Window we have SQL Server version: > > 14.0.1000.169 > > On RHE7 Linux we have SQL Server version: > > 14.0.3006.16-3 > > We can connect to the Linux server (freetds-ok.log), but we get a handshake > error when > connecting to the Windows server (freetds-fail.log) > > We see: > > 0460 fc 77 c8 1c f7 5c a5 f9-6f 5d 48 b0 61 fc d5 c8 |?w?.?\?? o]H?a???| > 0470 34 de cf 04 67 dd 95 92-b0 15 6c e3 cb c6 8a e5 |4??.g?.. ?.l???.?| > 0480 5d ed 52 98 e3 b8 64 c3-ca 5a e7 93 2d 0e 00 00 |]?R.??d? ?Z?.-...| > 0490 00 - |.| > > tls.c:86:in tds_pull_func_login > tls.c:116:in tds_push_func_login > packet.c:741:Sending packet > 0000 12 01 00 0f 00 00 00 00-15 03 01 00 02 02 50 |........ ......P| > > tls.c:924:handshake failed > login.c:530:login packet rejected > query.c:3796:tds_disconnect() > util.c:165:Changed query state from IDLE to DEAD > > > Any idea? > > See attached logs. > > Thanks! > Seb > Usually at that stage is a TLS problem. Can you try to use a new version? Last is 1.00.80. Are you using OpenSSL or GnuTLS ? Regards, Frediano From freddy77 at gmail.com Sat Dec 16 12:18:25 2017 From: freddy77 at gmail.com (Frediano Ziglio) Date: Sat, 16 Dec 2017 17:18:25 +0000 Subject: [freetds] DB-Lib error message 20017, severity 9:Unexpected EOF from the server In-Reply-To: <16B74D10F9D66440AE2D7BC2C82642A150673F8B@SFVX2010.sf.NFL.NET> References: <16B74D10F9D66440AE2D7BC2C82642A150673F8B@SFVX2010.sf.NFL.NET> Message-ID: 2017-11-28 21:40 GMT+00:00 Wagner, Steve : > We've been using pymssql and FreeTDS for over 2 years now without problems. We recently upgraded pymssql to 2.1.3 and also from Python 3.4 to 3.6. Since that upgrade we've been getting the following error intermittently (but frequently). > > (20017, b'DB-Lib error message 20017, severity 9:\nUnexpected EOF from the server (FBOps-Prod:1433)\nDB-Lib error message 20002, severity 9:\nAdaptive Server connection failed (FBOps-Prod:1433)\n') > This usually means server closed the connection. This can happen if there's a firewall between or if client send some garbage. > There is no apparent pattern to the failures that we have been able to discover. Well over 95% of the DB calls succeed. It can fail on any stored proc or sql query. > > The database calls apparently do not even get to the database because nothing shows up in any DB log or trace. > > I've scoured the web and come up empty. > > I've reinstalled pymssql and FreeTDS but it still fails. > > Failures occur when connected to a DB server that is remote to the app but when connected to localhost. > > I've checked max number of connections and it's 4096 which should be plenty as there are no more than 10 active users at a time. > > Below is an excerpt from the TDS log file (full log file at the end). > > > packet.c:639:Received packet > > ....... > > > dblib.c:6845:dbsqlsend(000000000775B3B0) > > > mem.c:648:tds_free_all_results() > > > util.c:165:Changed query state from IDLE to WRITING > > > util.c:165:Changed query state from WRITING to PENDING > > > packet.c:740:Sending packet > > > 0000 01 01 00 1c 00 00 01 00-42 00 45 00 47 00 49 00 |........ B.E.G.I.| > > > 0010 4e 00 20 00 54 00 52 00-41 00 4e 00 |N. .T.R. A.N.| > > > > > dblib.c:4625:dbsqlok(000000000775B3B0) > > > dblib.c:4654:dbsqlok() not done, calling tds_process_tokens() > > > token.c:550:tds_process_tokens(00000000075359E0, 000000000A58BBA8, 000000000A58BBA0, 0x6914) > > > util.c:165:Changed query state from PENDING to READING > > > packet.c:639:Received packet > > > 0000 04 01 00 11 00 4e 01 00-fd 00 00 d4 00 00 00 00 |.....N.. ........| > > > 0010 00 - |.| > > Here server replied correctly so accepted the query. > > > token.c:565:processing result tokens. marker is fd(DONE) > > > token.c:2081:tds_process_end: more_results = 0 > > > was_cancelled = 0 > > > error = 0 > > > done_count_valid = 0 > > > token.c:2098: rows_affected = 0 > > > token.c:2101:tds_process_end() state set to TDS_IDLE > > > util.c:165:Changed query state from READING to IDLE > > > util.c:83:logic error: cannot change query state from IDLE to PENDING > > > util.c:165:Changed query state from IDLE to IDLE > > > dblib.c:4687:dbsqlok() end status is SUCCEED > > > dblib.c:4698:dbsqlok() end status was success > > > dblib.c:1689:dbresults(000000000775B3B0) > > > dblib.c:1694:dbresults: dbresults_state is 5 (_DB_RES_SUCCEED) > > > dblib.c:1679:dbresults returning 1 (SUCCEED) > > > dblib.c:2772:dbcount(000000000775B3B0) > > > dblib.c:3203:dbcancel(000000000775B3B0) > > > query.c:2189:tds_send_cancel: not in_cancel and idle > > > dblib.c:1463:dbclose(000000000775B3B0) > Here client is closing the connection, in this case there's no "Unexpected EOF". > > dblib.c:243:dblib_del_connection(000007FEF8B0FA70, 00000000075359E0) > > > query.c:3772:tds_disconnect() > > > util.c:165:Changed query state from IDLE to DEAD > > > mem.c:648:tds_free_all_results() > > > dblib.c:290:dblib_release_tds_ctx(1) > > > dblib.c:5873:dbfreebuf(000000000775B3B0) > > > Steve > Looks like this log is correct and do not present the error you are reporting. Frediano From Steve.Wagner at 49ers.com Mon Dec 18 15:44:26 2017 From: Steve.Wagner at 49ers.com (Wagner, Steve) Date: Mon, 18 Dec 2017 20:44:26 +0000 Subject: [freetds] DB-Lib error message 20017, severity 9:Unexpected EOF from the server In-Reply-To: References: <16B74D10F9D66440AE2D7BC2C82642A150673F8B@SFVX2010.sf.NFL.NET> Message-ID: <16B74D10F9D66440AE2D7BC2C82642A150698513@SFVX2010.sf.NFL.NET> Right, that was fairly obvious. The question is why these errors started showing up after working fine for 2+ years. Steve -----Original Message----- From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of Frediano Ziglio Sent: Saturday, December 16, 2017 9:18 AM To: FreeTDS Development Group Subject: Re: [freetds] DB-Lib error message 20017, severity 9:Unexpected EOF from the server 2017-11-28 21:40 GMT+00:00 Wagner, Steve : > We've been using pymssql and FreeTDS for over 2 years now without problems. We recently upgraded pymssql to 2.1.3 and also from Python 3.4 to 3.6. Since that upgrade we've been getting the following error intermittently (but frequently). > > (20017, b'DB-Lib error message 20017, severity 9:\nUnexpected EOF from > the server (FBOps-Prod:1433)\nDB-Lib error message 20002, severity > 9:\nAdaptive Server connection failed (FBOps-Prod:1433)\n') > This usually means server closed the connection. This can happen if there's a firewall between or if client send some garbage. > There is no apparent pattern to the failures that we have been able to discover. Well over 95% of the DB calls succeed. It can fail on any stored proc or sql query. > > The database calls apparently do not even get to the database because nothing shows up in any DB log or trace. > > I've scoured the web and come up empty. > > I've reinstalled pymssql and FreeTDS but it still fails. > > Failures occur when connected to a DB server that is remote to the app but when connected to localhost. > > I've checked max number of connections and it's 4096 which should be plenty as there are no more than 10 active users at a time. > > Below is an excerpt from the TDS log file (full log file at the end). > > > packet.c:639:Received packet > > ....... > > > dblib.c:6845:dbsqlsend(000000000775B3B0) > > > mem.c:648:tds_free_all_results() > > > util.c:165:Changed query state from IDLE to WRITING > > > util.c:165:Changed query state from WRITING to PENDING > > > packet.c:740:Sending packet > > > 0000 01 01 00 1c 00 00 01 00-42 00 45 00 47 00 49 00 |........ > B.E.G.I.| > > > 0010 4e 00 20 00 54 00 52 00-41 00 4e 00 |N. .T.R. A.N.| > > > > > dblib.c:4625:dbsqlok(000000000775B3B0) > > > dblib.c:4654:dbsqlok() not done, calling tds_process_tokens() > > > token.c:550:tds_process_tokens(00000000075359E0, 000000000A58BBA8, > 000000000A58BBA0, 0x6914) > > > util.c:165:Changed query state from PENDING to READING > > > packet.c:639:Received packet > > > 0000 04 01 00 11 00 4e 01 00-fd 00 00 d4 00 00 00 00 |.....N.. > ........| > > > 0010 00 - |.| > > Here server replied correctly so accepted the query. > > > token.c:565:processing result tokens. marker is fd(DONE) > > > token.c:2081:tds_process_end: more_results = 0 > > > was_cancelled = 0 > > > error = 0 > > > done_count_valid = 0 > > > token.c:2098: rows_affected = 0 > > > token.c:2101:tds_process_end() state set to TDS_IDLE > > > util.c:165:Changed query state from READING to IDLE > > > util.c:83:logic error: cannot change query state from IDLE to PENDING > > > util.c:165:Changed query state from IDLE to IDLE > > > dblib.c:4687:dbsqlok() end status is SUCCEED > > > dblib.c:4698:dbsqlok() end status was success > > > dblib.c:1689:dbresults(000000000775B3B0) > > > dblib.c:1694:dbresults: dbresults_state is 5 (_DB_RES_SUCCEED) > > > dblib.c:1679:dbresults returning 1 (SUCCEED) > > > dblib.c:2772:dbcount(000000000775B3B0) > > > dblib.c:3203:dbcancel(000000000775B3B0) > > > query.c:2189:tds_send_cancel: not in_cancel and idle > > > dblib.c:1463:dbclose(000000000775B3B0) > Here client is closing the connection, in this case there's no "Unexpected EOF". > > dblib.c:243:dblib_del_connection(000007FEF8B0FA70, 00000000075359E0) > > > query.c:3772:tds_disconnect() > > > util.c:165:Changed query state from IDLE to DEAD > > > mem.c:648:tds_free_all_results() > > > dblib.c:290:dblib_release_tds_ctx(1) > > > dblib.c:5873:dbfreebuf(000000000775B3B0) > > > Steve > Looks like this log is correct and do not present the error you are reporting. Frediano _______________________________________________ FreeTDS mailing list FreeTDS at lists.ibiblio.org https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.ibiblio.org_mailman_listinfo_freetds&d=DwICAg&c=vR7hPPKGMb3Dfu46XtMMgQ&r=je4dO7ALeRs9qC-IdE73W0NJmM3ANuI-8MLiQOInOqc&m=4CYqillzKz8R49n7FsOKRo7ymawoDbgL9yQldOLi3uc&s=sdjthWiBW_msYeakF_MY-4YKJ-EVmR1c73Ks7F1-UsA&e= From freddy77 at gmail.com Fri Dec 22 13:39:12 2017 From: freddy77 at gmail.com (Frediano Ziglio) Date: Fri, 22 Dec 2017 18:39:12 +0000 Subject: [freetds] DB-Lib error message 20017, severity 9:Unexpected EOF from the server In-Reply-To: <16B74D10F9D66440AE2D7BC2C82642A150698513@SFVX2010.sf.NFL.NET> References: <16B74D10F9D66440AE2D7BC2C82642A150673F8B@SFVX2010.sf.NFL.NET> <16B74D10F9D66440AE2D7BC2C82642A150698513@SFVX2010.sf.NFL.NET> Message-ID: No idea. A failing log would help, no idea how to get one without enabling logs everywhere. Code sending garbage should not be that intermittent unless if a really specific condition. About a possible firewall difference can be a firmwate update or a different configuration. If this happened just after the update I would try to narrow down the change like updating only pymssql or only Python. I suppose you updated the system entirely and you got all a set of updates. Frediano 2017-12-18 20:44 GMT+00:00 Wagner, Steve : > Right, that was fairly obvious. The question is why these errors started showing up after working fine for 2+ years. > > Steve > > -----Original Message----- > From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of Frediano Ziglio > Sent: Saturday, December 16, 2017 9:18 AM > To: FreeTDS Development Group > Subject: Re: [freetds] DB-Lib error message 20017, severity 9:Unexpected EOF from the server > > 2017-11-28 21:40 GMT+00:00 Wagner, Steve : >> We've been using pymssql and FreeTDS for over 2 years now without problems. We recently upgraded pymssql to 2.1.3 and also from Python 3.4 to 3.6. Since that upgrade we've been getting the following error intermittently (but frequently). >> >> (20017, b'DB-Lib error message 20017, severity 9:\nUnexpected EOF from >> the server (FBOps-Prod:1433)\nDB-Lib error message 20002, severity >> 9:\nAdaptive Server connection failed (FBOps-Prod:1433)\n') >> > > This usually means server closed the connection. This can happen if there's a firewall between or if client send some garbage. > >> There is no apparent pattern to the failures that we have been able to discover. Well over 95% of the DB calls succeed. It can fail on any stored proc or sql query. >> >> The database calls apparently do not even get to the database because nothing shows up in any DB log or trace. >> >> I've scoured the web and come up empty. >> >> I've reinstalled pymssql and FreeTDS but it still fails. >> >> Failures occur when connected to a DB server that is remote to the app but when connected to localhost. >> >> I've checked max number of connections and it's 4096 which should be plenty as there are no more than 10 active users at a time. >> >> Below is an excerpt from the TDS log file (full log file at the end). >> >> >> packet.c:639:Received packet >> >> > ....... >> >> >> dblib.c:6845:dbsqlsend(000000000775B3B0) >> >> >> mem.c:648:tds_free_all_results() >> >> >> util.c:165:Changed query state from IDLE to WRITING >> >> >> util.c:165:Changed query state from WRITING to PENDING >> >> >> packet.c:740:Sending packet >> >> >> 0000 01 01 00 1c 00 00 01 00-42 00 45 00 47 00 49 00 |........ >> B.E.G.I.| >> >> >> 0010 4e 00 20 00 54 00 52 00-41 00 4e 00 |N. .T.R. A.N.| >> >> >> >> >> dblib.c:4625:dbsqlok(000000000775B3B0) >> >> >> dblib.c:4654:dbsqlok() not done, calling tds_process_tokens() >> >> >> token.c:550:tds_process_tokens(00000000075359E0, 000000000A58BBA8, >> 000000000A58BBA0, 0x6914) >> >> >> util.c:165:Changed query state from PENDING to READING >> >> >> packet.c:639:Received packet >> >> >> 0000 04 01 00 11 00 4e 01 00-fd 00 00 d4 00 00 00 00 |.....N.. >> ........| >> >> >> 0010 00 - |.| >> >> > > Here server replied correctly so accepted the query. > >> >> >> token.c:565:processing result tokens. marker is fd(DONE) >> >> >> token.c:2081:tds_process_end: more_results = 0 >> >> >> was_cancelled = 0 >> >> >> error = 0 >> >> >> done_count_valid = 0 >> >> >> token.c:2098: rows_affected = 0 >> >> >> token.c:2101:tds_process_end() state set to TDS_IDLE >> >> >> util.c:165:Changed query state from READING to IDLE >> >> >> util.c:83:logic error: cannot change query state from IDLE to PENDING >> >> >> util.c:165:Changed query state from IDLE to IDLE >> >> >> dblib.c:4687:dbsqlok() end status is SUCCEED >> >> >> dblib.c:4698:dbsqlok() end status was success >> >> >> dblib.c:1689:dbresults(000000000775B3B0) >> >> >> dblib.c:1694:dbresults: dbresults_state is 5 (_DB_RES_SUCCEED) >> >> >> dblib.c:1679:dbresults returning 1 (SUCCEED) >> >> >> dblib.c:2772:dbcount(000000000775B3B0) >> >> >> dblib.c:3203:dbcancel(000000000775B3B0) >> >> >> query.c:2189:tds_send_cancel: not in_cancel and idle >> >> >> dblib.c:1463:dbclose(000000000775B3B0) >> > > Here client is closing the connection, in this case there's no "Unexpected EOF". > >> >> dblib.c:243:dblib_del_connection(000007FEF8B0FA70, 00000000075359E0) >> >> >> query.c:3772:tds_disconnect() >> >> >> util.c:165:Changed query state from IDLE to DEAD >> >> >> mem.c:648:tds_free_all_results() >> >> >> dblib.c:290:dblib_release_tds_ctx(1) >> >> >> dblib.c:5873:dbfreebuf(000000000775B3B0) >> >> >> Steve >> > > Looks like this log is correct and do not present the error you are reporting. > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.ibiblio.org_mailman_listinfo_freetds&d=DwICAg&c=vR7hPPKGMb3Dfu46XtMMgQ&r=je4dO7ALeRs9qC-IdE73W0NJmM3ANuI-8MLiQOInOqc&m=4CYqillzKz8R49n7FsOKRo7ymawoDbgL9yQldOLi3uc&s=sdjthWiBW_msYeakF_MY-4YKJ-EVmR1c73Ks7F1-UsA&e= > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds From Steve.Wagner at 49ers.com Fri Dec 22 14:30:40 2017 From: Steve.Wagner at 49ers.com (Wagner, Steve) Date: Fri, 22 Dec 2017 19:30:40 +0000 Subject: [freetds] DB-Lib error message 20017, severity 9:Unexpected EOF from the server In-Reply-To: References: <16B74D10F9D66440AE2D7BC2C82642A150673F8B@SFVX2010.sf.NFL.NET> <16B74D10F9D66440AE2D7BC2C82642A150698513@SFVX2010.sf.NFL.NET> Message-ID: <16B74D10F9D66440AE2D7BC2C82642A15069DCFC@SFVX2010.sf.NFL.NET> Thanks for the response. We decided to move to pyodbc since we couldn't find an answer. Steve -----Original Message----- From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of Frediano Ziglio Sent: Friday, December 22, 2017 10:39 AM To: FreeTDS Development Group Subject: Re: [freetds] DB-Lib error message 20017, severity 9:Unexpected EOF from the server No idea. A failing log would help, no idea how to get one without enabling logs everywhere. Code sending garbage should not be that intermittent unless if a really specific condition. About a possible firewall difference can be a firmwate update or a different configuration. If this happened just after the update I would try to narrow down the change like updating only pymssql or only Python. I suppose you updated the system entirely and you got all a set of updates. Frediano 2017-12-18 20:44 GMT+00:00 Wagner, Steve : > Right, that was fairly obvious. The question is why these errors started showing up after working fine for 2+ years. > > Steve > > -----Original Message----- > From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of > Frediano Ziglio > Sent: Saturday, December 16, 2017 9:18 AM > To: FreeTDS Development Group > Subject: Re: [freetds] DB-Lib error message 20017, severity > 9:Unexpected EOF from the server > > 2017-11-28 21:40 GMT+00:00 Wagner, Steve : >> We've been using pymssql and FreeTDS for over 2 years now without problems. We recently upgraded pymssql to 2.1.3 and also from Python 3.4 to 3.6. Since that upgrade we've been getting the following error intermittently (but frequently). >> >> (20017, b'DB-Lib error message 20017, severity 9:\nUnexpected EOF >> from the server (FBOps-Prod:1433)\nDB-Lib error message 20002, >> severity 9:\nAdaptive Server connection failed (FBOps-Prod:1433)\n') >> > > This usually means server closed the connection. This can happen if there's a firewall between or if client send some garbage. > >> There is no apparent pattern to the failures that we have been able to discover. Well over 95% of the DB calls succeed. It can fail on any stored proc or sql query. >> >> The database calls apparently do not even get to the database because nothing shows up in any DB log or trace. >> >> I've scoured the web and come up empty. >> >> I've reinstalled pymssql and FreeTDS but it still fails. >> >> Failures occur when connected to a DB server that is remote to the app but when connected to localhost. >> >> I've checked max number of connections and it's 4096 which should be plenty as there are no more than 10 active users at a time. >> >> Below is an excerpt from the TDS log file (full log file at the end). >> >> >> packet.c:639:Received packet >> >> > ....... >> >> >> dblib.c:6845:dbsqlsend(000000000775B3B0) >> >> >> mem.c:648:tds_free_all_results() >> >> >> util.c:165:Changed query state from IDLE to WRITING >> >> >> util.c:165:Changed query state from WRITING to PENDING >> >> >> packet.c:740:Sending packet >> >> >> 0000 01 01 00 1c 00 00 01 00-42 00 45 00 47 00 49 00 |........ >> B.E.G.I.| >> >> >> 0010 4e 00 20 00 54 00 52 00-41 00 4e 00 |N. .T.R. A.N.| >> >> >> >> >> dblib.c:4625:dbsqlok(000000000775B3B0) >> >> >> dblib.c:4654:dbsqlok() not done, calling tds_process_tokens() >> >> >> token.c:550:tds_process_tokens(00000000075359E0, 000000000A58BBA8, >> 000000000A58BBA0, 0x6914) >> >> >> util.c:165:Changed query state from PENDING to READING >> >> >> packet.c:639:Received packet >> >> >> 0000 04 01 00 11 00 4e 01 00-fd 00 00 d4 00 00 00 00 |.....N.. >> ........| >> >> >> 0010 00 - |.| >> >> > > Here server replied correctly so accepted the query. > >> >> >> token.c:565:processing result tokens. marker is fd(DONE) >> >> >> token.c:2081:tds_process_end: more_results = 0 >> >> >> was_cancelled = 0 >> >> >> error = 0 >> >> >> done_count_valid = 0 >> >> >> token.c:2098: rows_affected = 0 >> >> >> token.c:2101:tds_process_end() state set to TDS_IDLE >> >> >> util.c:165:Changed query state from READING to IDLE >> >> >> util.c:83:logic error: cannot change query state from IDLE to PENDING >> >> >> util.c:165:Changed query state from IDLE to IDLE >> >> >> dblib.c:4687:dbsqlok() end status is SUCCEED >> >> >> dblib.c:4698:dbsqlok() end status was success >> >> >> dblib.c:1689:dbresults(000000000775B3B0) >> >> >> dblib.c:1694:dbresults: dbresults_state is 5 (_DB_RES_SUCCEED) >> >> >> dblib.c:1679:dbresults returning 1 (SUCCEED) >> >> >> dblib.c:2772:dbcount(000000000775B3B0) >> >> >> dblib.c:3203:dbcancel(000000000775B3B0) >> >> >> query.c:2189:tds_send_cancel: not in_cancel and idle >> >> >> dblib.c:1463:dbclose(000000000775B3B0) >> > > Here client is closing the connection, in this case there's no "Unexpected EOF". > >> >> dblib.c:243:dblib_del_connection(000007FEF8B0FA70, 00000000075359E0) >> >> >> query.c:3772:tds_disconnect() >> >> >> util.c:165:Changed query state from IDLE to DEAD >> >> >> mem.c:648:tds_free_all_results() >> >> >> dblib.c:290:dblib_release_tds_ctx(1) >> >> >> dblib.c:5873:dbfreebuf(000000000775B3B0) >> >> >> Steve >> > > Looks like this log is correct and do not present the error you are reporting. > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.ibiblio.org > _mailman_listinfo_freetds&d=DwICAg&c=vR7hPPKGMb3Dfu46XtMMgQ&r=je4dO7AL > eRs9qC-IdE73W0NJmM3ANuI-8MLiQOInOqc&m=4CYqillzKz8R49n7FsOKRo7ymawoDbgL > 9yQldOLi3uc&s=sdjthWiBW_msYeakF_MY-4YKJ-EVmR1c73Ks7F1-UsA&e= > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.ibiblio.org > _mailman_listinfo_freetds&d=DwICAg&c=vR7hPPKGMb3Dfu46XtMMgQ&r=je4dO7AL > eRs9qC-IdE73W0NJmM3ANuI-8MLiQOInOqc&m=UBANYr1Fhj2G-yeVj8swxsK_kapREFBJ > LyNloQnx87k&s=oUZcw1ZN6iwb-PtIkdsm2UYwSWTS_YqaArnJoh54D9o&e= _______________________________________________ FreeTDS mailing list FreeTDS at lists.ibiblio.org https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.ibiblio.org_mailman_listinfo_freetds&d=DwICAg&c=vR7hPPKGMb3Dfu46XtMMgQ&r=je4dO7ALeRs9qC-IdE73W0NJmM3ANuI-8MLiQOInOqc&m=UBANYr1Fhj2G-yeVj8swxsK_kapREFBJLyNloQnx87k&s=oUZcw1ZN6iwb-PtIkdsm2UYwSWTS_YqaArnJoh54D9o&e=