From fergus_smith111 at hotmail.com Wed Jul 1 10:25:13 2015 From: fergus_smith111 at hotmail.com (Fergus Smith) Date: Wed, 1 Jul 2015 14:25:13 +0000 Subject: [freetds] ct-lib error handling In-Reply-To: References: , Message-ID: Hi, I've come across this same problem in every version of FreeTDS I've tried. http://lists.ibiblio.org/pipermail/freetds/2007q3/022165.html Running against MSSQL the error isn't trapped. I think the ct-lib error handler isn't working properly. The test environments are; TDS version: 4.2 Version: freetds vdev.0.96.85 Windows 7 SP1 Sybase ASE 12.5.4 Microsoft SQL Server 2012 (SP1) Running on windows against sybase this is the relevant part of the dump file; ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ct.c:994:ct_send() succeeded ct.c:1129:ct_results(0058B5C0, 0031A910) token.c:549:tds_process_tokens(00588068, 0031A768, 0031A75C, 0x6914) util.c:165:Changed query state from PENDING to READING packet.c:639:Received packet 0000 04 01 00 dd 00 00 00 00-e5 c9 00 fc 0a 00 00 05 |........ ........| 0010 10 05 5a 5a 5a 5a 5a 00-01 00 ae 00 53 74 6f 72 |..ZZZZZ. ....Stor| 0020 65 64 20 70 72 6f 63 65-64 75 72 65 20 27 63 75 |ed proce dure 'cu| 0030 73 74 6f 6d 65 72 64 62-5f 74 73 74 2e 2e 73 70 |stomerdb _tst..sp| 0040 44 6f 65 73 4e 6f 74 45-78 69 73 74 27 20 6e 6f |DoesNotE xist' no| 0050 74 20 66 6f 75 6e 64 2e-20 53 70 65 63 69 66 79 |t found. Specify| 0060 20 6f 77 6e 65 72 2e 6f-62 6a 65 63 74 6e 61 6d | owner.o bjectnam| 0070 65 20 6f 72 20 75 73 65-20 73 70 5f 68 65 6c 70 |e or use sp_help| 0080 20 74 6f 20 63 68 65 63-6b 20 77 68 65 74 68 65 | to chec k whethe| 0090 72 20 74 68 65 20 6f 62-6a 65 63 74 20 65 78 69 |r the ob ject exi| 00a0 73 74 73 20 28 73 70 5f-68 65 6c 70 20 6d 61 79 |sts (sp_ help may| 00b0 20 70 72 6f 64 75 63 65-20 6c 6f 74 73 20 6f 66 | produce lots of| 00c0 20 6f 75 74 70 75 74 29-2e 0a 06 61 73 65 63 64 | output) ...asecd| 00d0 74 00 01 00 fd 02 00 02-00 00 00 00 00 |t....... .....| token.c:564:processing result tokens. marker is e5(EED) token.c:115:tds_process_default_tokens() marker is e5(EED) token.c:2339:tds_process_msg() reading message 2812 from server token.c:2411:tds_process_msg() calling client msg handler ctutil.c:142:_ct_handle_server_message(005872A0, 00588068, 0031A660) ct.c:4330:ct_diag_storeservermsg(005871D8, 00587ED0, 0031A0F4) token.c:2424:tds_process_msg() returning TDS_SUCCESS token.c:564:processing result tokens. marker is fd(DONE) token.c:2075:tds_process_end: more_results = 0 was_cancelled = 0 error = 1 done_count_valid = 0 token.c:2092: rows_affected = 0 token.c:2095: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 ct.c:1186:ct_results() process_result_tokens returned 0 (type 4052) ct.c:1292:ct_results() results state = 0 ct.c:1293:ct_results() command type = 148 ct.c:1294:ct_results() dynamic cmd = 0 ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- On windows against MS SQL this is the same part of the dump file; ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ct.c:994:ct_send() succeeded ct.c:1129:ct_results(0084C658, 0032AB00) token.c:549:tds_process_tokens(00847FD0, 0032A958, 0032A94C, 0x6914) util.c:165:Changed query state from PENDING to READING packet.c:639:Received packet 0000 04 01 00 c8 00 3d 01 00-aa b4 00 fc 0a 00 00 3e |.....=.. .......>| 0010 10 45 00 43 00 6f 00 75-00 6c 00 64 00 20 00 6e |.E.C.o.u .l.d. .n| 0020 00 6f 00 74 00 20 00 66-00 69 00 6e 00 64 00 20 |.o.t. .f .i.n.d. | 0030 00 73 00 74 00 6f 00 72-00 65 00 64 00 20 00 70 |.s.t.o.r .e.d. .p| 0040 00 72 00 6f 00 63 00 65-00 64 00 75 00 72 00 65 |.r.o.c.e .d.u.r.e| 0050 00 20 00 27 00 62 00 69-00 6c 00 6c 00 69 00 6e |. .'.b.i .l.l.i.n| 0060 00 67 00 5f 00 64 00 65-00 76 00 2e 00 2e 00 73 |.g._.d.e .v.....s| 0070 00 70 00 52 00 75 00 61-00 69 00 72 00 69 00 50 |.p.R.u.a .i.r.i.P| 0080 00 50 00 47 00 65 00 74-00 44 00 65 00 66 00 61 |.P.G.e.t .D.e.f.a| 0090 00 75 00 6c 00 74 00 73-00 27 00 2e 00 0f 41 00 |.u.l.t.s .'....A.| 00a0 4c 00 50 00 2d 00 4d 00-41 00 54 00 52 00 49 00 |L.P.-.M. A.T.R.I.| 00b0 58 00 53 00 51 00 4c 00-53 00 56 00 00 01 00 fe |X.S.Q.L. S.V.....| 00c0 02 00 e0 00 00 00 00 00- |........| token.c:564:processing result tokens. marker is aa(ERROR) token.c:115:tds_process_default_tokens() marker is aa(ERROR) token.c:2339:tds_process_msg() reading message 2812 from server token.c:2411:tds_process_msg() calling client msg handler ctutil.c:142:_ct_handle_server_message(008472A0, 00847FD0, 0032A850) ct.c:4330:ct_diag_storeservermsg(008471D8, 00847ED0, 0032A2E4) token.c:2424:tds_process_msg() returning TDS_SUCCESS token.c:564:processing result tokens. marker is fe(DONEPROC) token.c:2075:tds_process_end: more_results = 0 was_cancelled = 0 error = 1 done_count_valid = 0 token.c:2092: rows_affected = 0 token.c:2095: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 ct.c:1186:ct_results() process_result_tokens returned 0 (type 4053) token.c:549:tds_process_tokens(00847FD0, 0032A958, 0032A94C, 0x6914) token.c:552:tds_process_tokens() state is COMPLETED ct.c:1186:ct_results() process_result_tokens returned 1 (type 4052) ct.c:235:ct_describe_cmd_state(3) ct.c:235:ct_describe_cmd_state(2) ct.c:223:setting command state to READY (from SENT) ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- I was wondering has anyone made an attempt to fix this? Thanks a million, Fergus From sf at 4js.com Thu Jul 2 05:28:43 2015 From: sf at 4js.com (Sebastien FLAESCH) Date: Thu, 02 Jul 2015 11:28:43 +0200 Subject: [freetds] XML type returns SQL_CHAR type In-Reply-To: References: <5583F4A6.3030200@4js.com> Message-ID: <5595044B.80808@4js.com> Back to the inital problem: For now with 0.95.5 I get invalid SQLDescribeCol info when using the XML type: sqltype = SQL_CHAR (1) precision = 2147483647 With other ODBC drivers I get: sqltype = SQL_SS_XML (-152) precision = 0 Attached, the TDSDUMP. You can see: token.c:1537:tds7_get_data_info: colname = t type = 241 (xml) server's type = 241 (xml) column_varint_size = 8 column_size = 2147483647 (2147483647 on server) Seb On 06/20/2015 12:30 PM, Frediano Ziglio wrote: > Il 19/Giu/2015 11:53, "Sebastien FLAESCH" ha scritto: >> >> Seems that when using the XML type, SQLDescribeCol() returns SQL_CHAR, and >> precision=2147483647 ... expected? >> >> BTW what are [N]VARCHAR(MAX) types supposed to return in SQLDescribeCol()? >> >> Seb >> > > don't remember. Should be part of describecol test. > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > -------------- next part -------------- A non-text attachment was scrubbed... Name: tdsdump.log Type: text/x-log Size: 38709 bytes Desc: not available URL: From sf at 4js.com Thu Jul 2 05:31:33 2015 From: sf at 4js.com (Sebastien FLAESCH) Date: Thu, 02 Jul 2015 11:31:33 +0200 Subject: [freetds] XML type returns SQL_CHAR type In-Reply-To: References: <5583F4A6.3030200@4js.com> Message-ID: <559504F5.3040103@4js.com> My platform: $ uname -a Linux orion 3.14-1-amd64 #1 SMP Debian 3.14.4-1 (2014-05-13) x86_64 GNU/Linux Compiling with UnixODBC 2.3.2 ... Seb On 06/20/2015 12:30 PM, Frediano Ziglio wrote: > Il 19/Giu/2015 11:53, "Sebastien FLAESCH" ha scritto: >> >> Seems that when using the XML type, SQLDescribeCol() returns SQL_CHAR, and >> precision=2147483647 ... expected? >> >> BTW what are [N]VARCHAR(MAX) types supposed to return in SQLDescribeCol()? >> >> Seb >> > > don't remember. Should be part of describecol test. > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > From freddy77 at gmail.com Thu Jul 2 15:42:02 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Thu, 2 Jul 2015 20:42:02 +0100 Subject: [freetds] XML type returns SQL_CHAR type In-Reply-To: <5595044B.80808@4js.com> References: <5583F4A6.3030200@4js.com> <5595044B.80808@4js.com> Message-ID: 2015-07-02 10:28 GMT+01:00 Sebastien FLAESCH : > Back to the inital problem: For now with 0.95.5 I get invalid SQLDescribeCol > info when using the XML type: > > sqltype = SQL_CHAR (1) > precision = 2147483647 > Well, not invalid just perhaps wrong. XML is represented as text and SQL_CHAR is text data. Is not like returning date instead of int. > With other ODBC drivers I get: > > sqltype = SQL_SS_XML (-152) > precision = 0 > > Attached, the TDSDUMP. > > You can see: > > token.c:1537:tds7_get_data_info: > colname = t > type = 241 (xml) > server's type = 241 (xml) > column_varint_size = 8 > column_size = 2147483647 (2147483647 on server) > > Seb > I'm changing in master but I don't think to port back to stable release or at least not before having these stuff all at once. I would prefer to update as much information as possible Frediano > On 06/20/2015 12:30 PM, Frediano Ziglio wrote: >> >> Il 19/Giu/2015 11:53, "Sebastien FLAESCH" ha scritto: >>> >>> >>> Seems that when using the XML type, SQLDescribeCol() returns SQL_CHAR, >>> and >>> precision=2147483647 ... expected? >>> >>> BTW what are [N]VARCHAR(MAX) types supposed to return in >>> SQLDescribeCol()? >>> >>> Seb >>> >> >> don't remember. Should be part of describecol test. >> >> Frediano >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> http://lists.ibiblio.org/mailman/listinfo/freetds >> > > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > From sf at 4js.com Fri Jul 3 04:10:55 2015 From: sf at 4js.com (Sebastien FLAESCH) Date: Fri, 03 Jul 2015 10:10:55 +0200 Subject: [freetds] XML type returns SQL_CHAR type In-Reply-To: References: <5583F4A6.3030200@4js.com> <5595044B.80808@4js.com> Message-ID: <5596438F.1030901@4js.com> Ok thank you Frediano. I can workaround by testing SQL_CHAR + 2147483647 Seb On 07/02/2015 09:42 PM, Frediano Ziglio wrote: > 2015-07-02 10:28 GMT+01:00 Sebastien FLAESCH : >> Back to the inital problem: For now with 0.95.5 I get invalid SQLDescribeCol >> info when using the XML type: >> >> sqltype = SQL_CHAR (1) >> precision = 2147483647 >> > > Well, not invalid just perhaps wrong. XML is represented as text and > SQL_CHAR is text data. Is not like returning date instead of int. > >> With other ODBC drivers I get: >> >> sqltype = SQL_SS_XML (-152) >> precision = 0 >> >> Attached, the TDSDUMP. >> >> You can see: >> >> token.c:1537:tds7_get_data_info: >> colname = t >> type = 241 (xml) >> server's type = 241 (xml) >> column_varint_size = 8 >> column_size = 2147483647 (2147483647 on server) >> >> Seb >> > > I'm changing in master but I don't think to port back to stable > release or at least not before having these stuff all at once. I would > prefer to update as much information as possible > > Frediano > >> On 06/20/2015 12:30 PM, Frediano Ziglio wrote: >>> >>> Il 19/Giu/2015 11:53, "Sebastien FLAESCH" ha scritto: >>>> >>>> >>>> Seems that when using the XML type, SQLDescribeCol() returns SQL_CHAR, >>>> and >>>> precision=2147483647 ... expected? >>>> >>>> BTW what are [N]VARCHAR(MAX) types supposed to return in >>>> SQLDescribeCol()? >>>> >>>> Seb >>>> >>> >>> don't remember. Should be part of describecol test. >>> >>> Frediano >>> _______________________________________________ >>> FreeTDS mailing list >>> FreeTDS at lists.ibiblio.org >>> http://lists.ibiblio.org/mailman/listinfo/freetds >>> >> >> >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> http://lists.ibiblio.org/mailman/listinfo/freetds >> > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > From freddy77 at gmail.com Fri Jul 3 08:23:08 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Fri, 3 Jul 2015 13:23:08 +0100 Subject: [freetds] XML type returns SQL_CHAR type In-Reply-To: <5596438F.1030901@4js.com> References: <5583F4A6.3030200@4js.com> <5595044B.80808@4js.com> <5596438F.1030901@4js.com> Message-ID: Hi Sebastian, why don't help with developing/testing for the next release? I hope will be much sooner than last one. I just push on master changes to improve XML and SQL_VARIANT. Frediano 2015-07-03 9:10 GMT+01:00 Sebastien FLAESCH : > Ok thank you Frediano. > I can workaround by testing SQL_CHAR + 2147483647 > Seb > > > On 07/02/2015 09:42 PM, Frediano Ziglio wrote: >> >> 2015-07-02 10:28 GMT+01:00 Sebastien FLAESCH : >>> >>> Back to the inital problem: For now with 0.95.5 I get invalid >>> SQLDescribeCol >>> info when using the XML type: >>> >>> sqltype = SQL_CHAR (1) >>> precision = 2147483647 >>> >> >> Well, not invalid just perhaps wrong. XML is represented as text and >> SQL_CHAR is text data. Is not like returning date instead of int. >> >>> With other ODBC drivers I get: >>> >>> sqltype = SQL_SS_XML (-152) >>> precision = 0 >>> >>> Attached, the TDSDUMP. >>> >>> You can see: >>> >>> token.c:1537:tds7_get_data_info: >>> colname = t >>> type = 241 (xml) >>> server's type = 241 (xml) >>> column_varint_size = 8 >>> column_size = 2147483647 (2147483647 on server) >>> >>> Seb >>> >> >> I'm changing in master but I don't think to port back to stable >> release or at least not before having these stuff all at once. I would >> prefer to update as much information as possible >> >> Frediano >> >>> On 06/20/2015 12:30 PM, Frediano Ziglio wrote: >>>> >>>> >>>> Il 19/Giu/2015 11:53, "Sebastien FLAESCH" ha scritto: >>>>> >>>>> >>>>> >>>>> Seems that when using the XML type, SQLDescribeCol() returns SQL_CHAR, >>>>> and >>>>> precision=2147483647 ... expected? >>>>> >>>>> BTW what are [N]VARCHAR(MAX) types supposed to return in >>>>> SQLDescribeCol()? >>>>> >>>>> Seb >>>>> >>>> >>>> don't remember. Should be part of describecol test. >>>> >>>> Frediano >>>> _______________________________________________ >>>> FreeTDS mailing list >>>> FreeTDS at lists.ibiblio.org >>>> http://lists.ibiblio.org/mailman/listinfo/freetds >>>> >>> >>> >>> _______________________________________________ >>> FreeTDS mailing list >>> FreeTDS at lists.ibiblio.org >>> http://lists.ibiblio.org/mailman/listinfo/freetds >>> >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> http://lists.ibiblio.org/mailman/listinfo/freetds >> > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From freddy77 at gmail.com Sun Jul 5 12:16:14 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Sun, 5 Jul 2015 17:16:14 +0100 Subject: [freetds] ct-lib error handling In-Reply-To: References: Message-ID: 2015-07-01 15:25 GMT+01:00 Fergus Smith : > Hi, > > > > I've come across this same problem in every version of FreeTDS I've tried. > > http://lists.ibiblio.org/pipermail/freetds/2007q3/022165.html > Running against MSSQL the error isn't trapped. > I think the ct-lib error handler isn't working properly. > > > > The test environments are; > > TDS version: 4.2 > I hope you are not really using this version :) At least 5.0 (Sybase) or 7.1 (mssql) > Version: freetds vdev.0.96.85 > > Windows 7 SP1 > > Sybase ASE 12.5.4 > > Microsoft SQL Server 2012 (SP1) > > > > > > Running on windows against sybase this is the relevant part of the dump file; > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > ct.c:994:ct_send() succeeded > > ct.c:1129:ct_results(0058B5C0, 0031A910) > > token.c:549:tds_process_tokens(00588068, 0031A768, 0031A75C, 0x6914) > > util.c:165:Changed query state from PENDING to READING > > packet.c:639:Received packet > > 0000 04 01 00 dd 00 00 00 00-e5 c9 00 fc 0a 00 00 05 |........ ........| > > 0010 10 05 5a 5a 5a 5a 5a 00-01 00 ae 00 53 74 6f 72 |..ZZZZZ. ....Stor| > > 0020 65 64 20 70 72 6f 63 65-64 75 72 65 20 27 63 75 |ed proce dure 'cu| > > 0030 73 74 6f 6d 65 72 64 62-5f 74 73 74 2e 2e 73 70 |stomerdb _tst..sp| > > 0040 44 6f 65 73 4e 6f 74 45-78 69 73 74 27 20 6e 6f |DoesNotE xist' no| > > 0050 74 20 66 6f 75 6e 64 2e-20 53 70 65 63 69 66 79 |t found. Specify| > > 0060 20 6f 77 6e 65 72 2e 6f-62 6a 65 63 74 6e 61 6d | owner.o bjectnam| > > 0070 65 20 6f 72 20 75 73 65-20 73 70 5f 68 65 6c 70 |e or use sp_help| > > 0080 20 74 6f 20 63 68 65 63-6b 20 77 68 65 74 68 65 | to chec k whethe| > > 0090 72 20 74 68 65 20 6f 62-6a 65 63 74 20 65 78 69 |r the ob ject exi| > > 00a0 73 74 73 20 28 73 70 5f-68 65 6c 70 20 6d 61 79 |sts (sp_ help may| > > 00b0 20 70 72 6f 64 75 63 65-20 6c 6f 74 73 20 6f 66 | produce lots of| > > 00c0 20 6f 75 74 70 75 74 29-2e 0a 06 61 73 65 63 64 | output) ...asecd| > > 00d0 74 00 01 00 fd 02 00 02-00 00 00 00 00 |t....... .....| > > > > token.c:564:processing result tokens. marker is e5(EED) > > token.c:115:tds_process_default_tokens() marker is e5(EED) > > token.c:2339:tds_process_msg() reading message 2812 from server > > token.c:2411:tds_process_msg() calling client msg handler > > ctutil.c:142:_ct_handle_server_message(005872A0, 00588068, 0031A660) > > ct.c:4330:ct_diag_storeservermsg(005871D8, 00587ED0, 0031A0F4) > > token.c:2424:tds_process_msg() returning TDS_SUCCESS > > token.c:564:processing result tokens. marker is fd(DONE) > > token.c:2075:tds_process_end: more_results = 0 > > was_cancelled = 0 > > error = 1 > > done_count_valid = 0 > > token.c:2092: rows_affected = 0 > > token.c:2095: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 > > ct.c:1186:ct_results() process_result_tokens returned 0 (type 4052) > > ct.c:1292:ct_results() results state = 0 > > ct.c:1293:ct_results() command type = 148 > > ct.c:1294:ct_results() dynamic cmd = 0 > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > > > On windows against MS SQL this is the same part of the dump file; > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > ct.c:994:ct_send() succeeded > > ct.c:1129:ct_results(0084C658, 0032AB00) > > token.c:549:tds_process_tokens(00847FD0, 0032A958, 0032A94C, 0x6914) > > util.c:165:Changed query state from PENDING to READING > > packet.c:639:Received packet > > 0000 04 01 00 c8 00 3d 01 00-aa b4 00 fc 0a 00 00 3e |.....=.. .......>| > > 0010 10 45 00 43 00 6f 00 75-00 6c 00 64 00 20 00 6e |.E.C.o.u .l.d. .n| > > 0020 00 6f 00 74 00 20 00 66-00 69 00 6e 00 64 00 20 |.o.t. .f .i.n.d. | > Good, surely you are not using 4.2 here! > 0030 00 73 00 74 00 6f 00 72-00 65 00 64 00 20 00 70 |.s.t.o.r .e.d. .p| > > 0040 00 72 00 6f 00 63 00 65-00 64 00 75 00 72 00 65 |.r.o.c.e .d.u.r.e| > > 0050 00 20 00 27 00 62 00 69-00 6c 00 6c 00 69 00 6e |. .'.b.i .l.l.i.n| > > 0060 00 67 00 5f 00 64 00 65-00 76 00 2e 00 2e 00 73 |.g._.d.e .v.....s| > > 0070 00 70 00 52 00 75 00 61-00 69 00 72 00 69 00 50 |.p.R.u.a .i.r.i.P| > > 0080 00 50 00 47 00 65 00 74-00 44 00 65 00 66 00 61 |.P.G.e.t .D.e.f.a| > > 0090 00 75 00 6c 00 74 00 73-00 27 00 2e 00 0f 41 00 |.u.l.t.s .'....A.| > > 00a0 4c 00 50 00 2d 00 4d 00-41 00 54 00 52 00 49 00 |L.P.-.M. A.T.R.I.| > > 00b0 58 00 53 00 51 00 4c 00-53 00 56 00 00 01 00 fe |X.S.Q.L. S.V.....| > > 00c0 02 00 e0 00 00 00 00 00- |........| > > > > token.c:564:processing result tokens. marker is aa(ERROR) > > token.c:115:tds_process_default_tokens() marker is aa(ERROR) > > token.c:2339:tds_process_msg() reading message 2812 from server > > token.c:2411:tds_process_msg() calling client msg handler > > ctutil.c:142:_ct_handle_server_message(008472A0, 00847FD0, 0032A850) > > ct.c:4330:ct_diag_storeservermsg(008471D8, 00847ED0, 0032A2E4) > > token.c:2424:tds_process_msg() returning TDS_SUCCESS > > token.c:564:processing result tokens. marker is fe(DONEPROC) > > token.c:2075:tds_process_end: more_results = 0 > > was_cancelled = 0 > > error = 1 > > done_count_valid = 0 > > token.c:2092: rows_affected = 0 > > token.c:2095: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 > > ct.c:1186:ct_results() process_result_tokens returned 0 (type 4053) > > token.c:549:tds_process_tokens(00847FD0, 0032A958, 0032A94C, 0x6914) > > token.c:552:tds_process_tokens() state is COMPLETED > > ct.c:1186:ct_results() process_result_tokens returned 1 (type 4052) > > ct.c:235:ct_describe_cmd_state(3) > > ct.c:235:ct_describe_cmd_state(2) > > ct.c:223:setting command state to READY (from SENT) > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > > > > > I was wondering has anyone made an attempt to fix this? > > > > Thanks a million, > > Fergus > I actually cannot test if everything is ok, but in src/ctlib/ct.c there are these lines case TDS_DONEPROC_RESULT: /* * A DONEPROC result means the end of a logical * command only if it was one of the commands * directly sent from ct_send, not as a result * of a nested stored procedure call. We know * if this is the case if a STATUS_RESULT was * received immediately prior to the DONE_PROC */ if (cmd->results_state == _CS_RES_STATUS) { if (done_flags & TDS_DONE_ERROR) *result_type = CS_CMD_FAIL; else *result_type = CS_CMD_SUCCEED; cmd->results_state = _CS_RES_CMD_DONE; return CS_SUCCEED; } else { if (cmd->command_type == CS_DYNAMIC_CMD) { *result_type = CS_CMD_SUCCEED; cmd->results_state = _CS_RES_CMD_DONE; return CS_SUCCEED; } } break; which seems to me broken! There are some types of commands: - LANG - RPC - SEND_DATA - SEND_BULK - CUR - DYNAMIC Now for LANG, SEND_DATA and SEND_BULK DONEPROC is not send back, you are using RPC which should be returning some data, DYNAMIC is handled by code above but error is not detected and if cursors probably are using RPCs (for instance using mssql, I don't know Sybase but if they are not using RPC they are not returning DONEPROC) should be handled. So I would change the code to (much easier) case TDS_DONEPROC_RESULT: if (done_flags & TDS_DONE_ERROR) *result_type = CS_CMD_FAIL; else *result_type = CS_CMD_SUCCEED; cmd->results_state = _CS_RES_CMD_DONE; return CS_SUCCEED; I don't agree with the comment to check status as for instance in your example status is not returned (as is returned when you call an RPC but if the RPC does not exists status is not returned). Can you try if this code solve the problem for you? I'll need to do some additional tests (for instance with cursors, dynamic and so on). Frediano From croberts at gilsongraphics.com Wed Jul 8 12:17:58 2015 From: croberts at gilsongraphics.com (Chuck Roberts) Date: Wed, 8 Jul 2015 12:17:58 -0400 Subject: [freetds] Cannot get tsql to connect Message-ID: I'm trying to test my ODBC with Freetds installation and I can't get tsql to connect. My end result is to use DBD::ODBC with Perl 5.18.2. In the meantime I'm trying to test with tsql per FreeTDS instructions. - Machine: Ubuntu 14.04.1 LTS 64-bit, it's a virtual machine. - Several ODBC packages installed on Ubuntu. /etc/odbc.ini points to driver: /usr/lib/x86_64-linux-gnu/odbc/libtdsodbc.so - Trying to connect to MS SQL Server 2005 (yes, we know it will be unsupported soon). Username is \domain\username, no password. - FreeTDS 0.91 (most recent I could find) - Output of tsql -C: chuck at ubuntucomp:~/perl/gilson/jimv/fedex$ tsql -C Compile-time settings (established with the "configure" script) Version: freetds v0.91 freetds.conf directory: /etc/freetds MS db-lib source compatibility: no Sybase binary compatibility: yes Thread safety: yes iconv library: yes TDS version: 4.2 iODBC: no unixodbc: yes SSPI "trusted" logins: no Kerberos: yes - In my /etc/freetds/freetds.conf, bottom part I added for my connection: [responsetds] host = 10.20.30.40 port = 1433 tds version = 7.0 connect timeout = 20 timeout = 20 dump file = /tmp/freetds-resp.log - tsql command and result. (IP, domain, user and password are fake) chuck at ubuntucomp:~/perl/gilson/jimv/fedex$ tsql -S 10.20.30.40 -U "DOMAIN\user" -P passwd locale is "en_US.UTF-8" locale charset is "UTF-8" using default charset "UTF-8" Msg 18452 (severity 14, state 1) from EDISON Line 1: "Login failed for user ''. The user is not associated with a trusted SQL Server connection." Error 20002 (severity 9): Adaptive Server connection failed There was a problem connecting to the server It looks like the user "DOMAIN\user" needs to be associated with a trusted SQL server connection. I'm not the IT guy, so what do I tell my IT guy? Other people on Windows are already using this domain\username to log in without a password. Also, specifying the command line with tsql means I bypassed the freetds.conf, right? Even though I'm using a domain logon, I don't have SSPI with FreeTDS. Do I need SSPI? If so, how do I enable it? I have already used Perl to connect to a Postgresql db but connecting to MS SQL 2005 is brand new to me, please explain like I'm 5, I may have missed a configuration step. I found instructions and it appears there are several ways to configure this. Thanks! From james.k.lowden at icloud.com Wed Jul 8 14:10:29 2015 From: james.k.lowden at icloud.com (James K. Lowden) Date: Wed, 08 Jul 2015 14:10:29 -0400 Subject: [freetds] Cannot get tsql to connect In-Reply-To: References: Message-ID: <20150708141029.5509503c.james.k.lowden@icloud.com> On Wed, 8 Jul 2015 12:17:58 -0400 Chuck Roberts wrote: > - Machine: Ubuntu 14.04.1 LTS 64-bit, it's a virtual machine. ... > - tsql command and result. (IP, domain, user and password are fake) > chuck at ubuntucomp:~/perl/gilson/jimv/fedex$ tsql -S 10.20.30.40 -U > "DOMAIN\user" -P passwd > locale is "en_US.UTF-8" > locale charset is "UTF-8" > using default charset "UTF-8" > Msg 18452 (severity 14, state 1) from EDISON Line 1: > "Login failed for user ''. The user is not associated with a > trusted SQL Server connection." ... > It looks like the user "DOMAIN\user" needs to be associated with a > trusted SQL server connection. I'm not the IT guy, so what do I tell > my IT guy? Other people on Windows are already using this domain > \username to log in without a password. Bourne shells interpret double-quoted strings. I recommend using single quotes, e.g. 'DOMAIN\user' just in case the first letter in the username is interpolated. You don't have to tell your IT guy anything. The MS-CHAP authentication protocol involves only the two ends of the connection, client and server. The primary domain controller is not consulted. All that's required is that the username you're providing does indeed belong to that domain, meaning you can log on that way to a Windows machine. > Also, specifying the command line with tsql means I bypassed the > freetds.conf, right? No, when you use the -S option, you're naming a servername entry in freetds.conf. If that lookup fails, IIRC the library will try to convert the name by DNS lookup or by converting the string to an IP address. If freetds.conf is not used, the TDS version comes from the value of TDSVER or the compiled-in default. I suspect what's happening is that you're not supplying a servername that appears in freetds.conf, and consequently the connection is made by decoding the -S argument as an IP address, and the TDS version used is 4.2. In that scenario, the username is not treated as a domain login, and SQL Server rejects it as invalid because no such user is defined to it. You can confirm that by setting TDSDUMP and looking at the top of the file. For the record: I have this "decode the name as address" filed under Not Helpful. It would be better if the library returned a name-lookup failure, because that's what the user specified with -S. > Even though I'm using a domain logon, I don't have SSPI with FreeTDS. > Do I need SSPI? If so, how do I enable it? You would use SSPI if you had a Windows client; it's the API that lets an application log in to SQL Server without a password by using the fact that the user has already logged on to the Windows machine. The underlying technology is Kerberos, and FreeTDS on a Linux machine configured with Kerberos can also log in to SQL Server without a password. The difference is this: with Kerberos or SSPI, the application can log in to SQL Server without a password. Authentication credentials are provided by a third machine (that Kerberos calls a KDC and Microsoft calls a PDC). Without them, the user provides a username & password, and SQL Server authenticates the client all by itself. HTH. --jkl From cramm0 at gmail.com Fri Jul 10 20:01:45 2015 From: cramm0 at gmail.com (Ramiro Morales) Date: Fri, 10 Jul 2015 21:01:45 -0300 Subject: [freetds] Progress on AppVeyour In-Reply-To: References: Message-ID: Hi Frediano, Sorry for such a belated reply. Life insists on keeping me away from having fun with this. Thanks for making me realise I never posted to the list. On Fri, Jun 19, 2015 at 9:49 PM, Frediano Ziglio wrote: > Hi Ramiro, > I'm following your progress on AppVeyor, quite interesting. > > Some things I notes: > - you register odbc driver with odbcconf, you can use regsvr32, the > driver should be able to register itself. Strange to use this program > for registering an odbc driver instead of a COM component but I added > this feature; Actually I tried the regsrv32 path but it fails for some reason I can't understand (IIRC OS reported error level 3), that's why the [1]relevant line is commented out. The lines below it (the ones that execute dbconf.exe) aren't sucessful either, as I uderstand they also try to register the driver with the ODBC manager. I copied all this from old posts to this list. > - iconv seems not compiled (as tsql output), looks like some checks > are not done in CMakeLists.txt and so some variable are not defined > correctly; Exactly, I managed to get iconv to get linked in by using the win-iconv project but the [2]technique I used is too hacky and that's why I haven't proposed it (hacky = too windows-specific and too win-iconv-specific.) Actually, I set up thing such that if openssl or iconv aren't available the build doen'st fail and CMake proceeds to buld FreeTDS with these features turned off. That's what's happening. I have some work in progress to get iconv (GNU libiconv, win-iconv) detected and linked in when using CMake by grabbing ideas and snippets from multiple sources around the Net. Unfortunately a module that performs such detection hasn't been added yet to CMake itself even when people has been proposing it for something like the last seven years. If/when we add it to our CMakeLists.txt then it will find and link in the win-iconv copy we already build on AppVeyor. > - similar for ODBC, on 64 bit for instance you get lot of problems as > some define are not there (like HAVE_SQLLEN). Not your fault but can > cause problems. Ok, in fact 64 bit ODBC stuff can be completely borked because I didn't care about ii at all, hoping to get the basic ODBC stuff working at leats with one configuration first. > > I also added a fix for thread declatation, I'll look forward to see > results from next compile with updated master to to check if they > disappeared. It's a pity a thread returns a DWORD instead of a > DWORD_PTR it's useful to pass a pointerand thread process data passes > and return other data with another pointer. Thanks for your continued work on master. I see you are already planning a second release this year. Wow. While we are at the AppVeyor Window CI builds topic and now that the needed files are alredy in the tree I'd like to suggest a remaining step I described in a [3]comment to the Pull Request: Note: If/when this gets merged, an account needs to be created in Appveyor by a GitHub FreeTDS organization member/owner (possibly using GitHub credentials) and then project settings on Appveyor need to be changed so it scans for the appveyor.yml file in the misc/ subdir instead of the source tree root. This would be the only Web UI action needed. Everything else can be handled with the appveyor.yml file. Doing this would give us builds that are automatically triggered on AppVeyor under the FreeTDS account from every new commit/PR (and having the build results getting reported in the GitHub UI) without having to rely on me manually rebasing my ramiro/appveyor branch on master from time to time and getting these build/results under my personal account/URL hierarchy. Regards, 1. https://github.com/ramiro/freetds/blob/e138e8c410cb4ce1f943975b5018c69c82521a67/misc/appveyor.yml#L103 2. https://github.com/ramiro/freetds/commit/e19d808d25042cd551d42ca51db259ccab8ffdca 3. https://github.com/FreeTDS/freetds/pull/14#issuecomment-111882545 -- Ramiro Morales @ramiromorales From fergus_smith111 at hotmail.com Mon Jul 13 09:39:11 2015 From: fergus_smith111 at hotmail.com (Fergus Smith) Date: Mon, 13 Jul 2015 13:39:11 +0000 Subject: [freetds] ct-lib error handling In-Reply-To: References: , , , Message-ID: Hi, Thanks very much for your help.I had said TDS Version 4.2 - as that's what tsql -c returns.When I look at the dump files, I see the versions you suggest.It's getting set to 8.0 in freetds.conf ! Sybase;net.c:202:Connecting to xx.xx.xx.xx port 4115 (TDS version 5.0) MS SQL;net.c:202:Connecting to xx.xx.xx.xx port 1603 (TDS version 7.1) I've made the change you suggest to src/ctlib/ct.cIn initial testing it's working exactly as I'd hoped. Here's the extract from the MSSQL dump file now;------------------------------------------------------------------------------------token.c:2075:tds_process_end: more_results = 0 was_cancelled = 0 error = 1 done_count_valid = 0token.c:2092: rows_affected = 0token.c:2095:tds_process_end() state set to TDS_IDLEutil.c:165:Changed query state from READING to IDLEutil.c:83:logic error: cannot change query state from IDLE to PENDINGutil.c:165:Changed query state from IDLE to IDLEct.c:1186:ct_results() process_result_tokens returned 0 (type 4053) ct.c:4192:ct_diag(00847F30, 37, 4701, -99999, 0026AA20)ct.c:4488:ct_diag_countmsg(00847238, 4701, 0026AA20)ct.c:4192:ct_diag(00847F30, 33, 4701, 1, 0026B37C)ct.c:4423:ct_diag_getservermsg(00847238, 1, 0026B37C)ct.c:4192:ct_diag(00847F30, 33, 4701, 2, 0026B37C)ct.c:4423:ct_diag_getservermsg(00847238, 2, 0026B37C)ct.c:4192:ct_diag(00847F30, 35, 4701, -99999, 00000000)ct.c:4452:_ct_diag_clearmsg(00847238, 4701)ct.c:1867:ct_close(00847F30, 301)query.c:3761:tds_disconnect() ------------------------------------------------------------------------------------I'll let you know if I run into any problems with it. Thanks a million,Fergus > Date: Sun, 5 Jul 2015 17:16:14 +0100 > From: freddy77 at gmail.com > To: freetds at lists.ibiblio.org > Subject: Re: [freetds] ct-lib error handling > > 2015-07-01 15:25 GMT+01:00 Fergus Smith : > > Hi, > > > > > > > > I've come across this same problem in every version of FreeTDS I've tried. > > > > http://lists.ibiblio.org/pipermail/freetds/2007q3/022165.html > > Running against MSSQL the error isn't trapped. > > I think the ct-lib error handler isn't working properly. > > > > > > > > The test environments are; > > > > TDS version: 4.2 > > > > I hope you are not really using this version :) > At least 5.0 (Sybase) or 7.1 (mssql) > > > Version: freetds vdev.0.96.85 > > > > Windows 7 SP1 > > > > Sybase ASE 12.5.4 > > > > Microsoft SQL Server 2012 (SP1) > > > > > > > > > > > > Running on windows against sybase this is the relevant part of the dump file; > > > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > > > ct.c:994:ct_send() succeeded > > > > ct.c:1129:ct_results(0058B5C0, 0031A910) > > > > token.c:549:tds_process_tokens(00588068, 0031A768, 0031A75C, 0x6914) > > > > util.c:165:Changed query state from PENDING to READING > > > > packet.c:639:Received packet > > > > 0000 04 01 00 dd 00 00 00 00-e5 c9 00 fc 0a 00 00 05 |........ ........| > > > > 0010 10 05 5a 5a 5a 5a 5a 00-01 00 ae 00 53 74 6f 72 |..ZZZZZ. ....Stor| > > > > 0020 65 64 20 70 72 6f 63 65-64 75 72 65 20 27 63 75 |ed proce dure 'cu| > > > > 0030 73 74 6f 6d 65 72 64 62-5f 74 73 74 2e 2e 73 70 |stomerdb _tst..sp| > > > > 0040 44 6f 65 73 4e 6f 74 45-78 69 73 74 27 20 6e 6f |DoesNotE xist' no| > > > > 0050 74 20 66 6f 75 6e 64 2e-20 53 70 65 63 69 66 79 |t found. Specify| > > > > 0060 20 6f 77 6e 65 72 2e 6f-62 6a 65 63 74 6e 61 6d | owner.o bjectnam| > > > > 0070 65 20 6f 72 20 75 73 65-20 73 70 5f 68 65 6c 70 |e or use sp_help| > > > > 0080 20 74 6f 20 63 68 65 63-6b 20 77 68 65 74 68 65 | to chec k whethe| > > > > 0090 72 20 74 68 65 20 6f 62-6a 65 63 74 20 65 78 69 |r the ob ject exi| > > > > 00a0 73 74 73 20 28 73 70 5f-68 65 6c 70 20 6d 61 79 |sts (sp_ help may| > > > > 00b0 20 70 72 6f 64 75 63 65-20 6c 6f 74 73 20 6f 66 | produce lots of| > > > > 00c0 20 6f 75 74 70 75 74 29-2e 0a 06 61 73 65 63 64 | output) ...asecd| > > > > 00d0 74 00 01 00 fd 02 00 02-00 00 00 00 00 |t....... .....| > > > > > > > > token.c:564:processing result tokens. marker is e5(EED) > > > > token.c:115:tds_process_default_tokens() marker is e5(EED) > > > > token.c:2339:tds_process_msg() reading message 2812 from server > > > > token.c:2411:tds_process_msg() calling client msg handler > > > > ctutil.c:142:_ct_handle_server_message(005872A0, 00588068, 0031A660) > > > > ct.c:4330:ct_diag_storeservermsg(005871D8, 00587ED0, 0031A0F4) > > > > token.c:2424:tds_process_msg() returning TDS_SUCCESS > > > > token.c:564:processing result tokens. marker is fd(DONE) > > > > token.c:2075:tds_process_end: more_results = 0 > > > > was_cancelled = 0 > > > > error = 1 > > > > done_count_valid = 0 > > > > token.c:2092: rows_affected = 0 > > > > token.c:2095: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 > > > > ct.c:1186:ct_results() process_result_tokens returned 0 (type 4052) > > > > ct.c:1292:ct_results() results state = 0 > > > > ct.c:1293:ct_results() command type = 148 > > > > ct.c:1294:ct_results() dynamic cmd = 0 > > > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > > > > > > > On windows against MS SQL this is the same part of the dump file; > > > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > > > ct.c:994:ct_send() succeeded > > > > ct.c:1129:ct_results(0084C658, 0032AB00) > > > > token.c:549:tds_process_tokens(00847FD0, 0032A958, 0032A94C, 0x6914) > > > > util.c:165:Changed query state from PENDING to READING > > > > packet.c:639:Received packet > > > > 0000 04 01 00 c8 00 3d 01 00-aa b4 00 fc 0a 00 00 3e |.....=.. .......>| > > > > 0010 10 45 00 43 00 6f 00 75-00 6c 00 64 00 20 00 6e |.E.C.o.u .l.d. .n| > > > > 0020 00 6f 00 74 00 20 00 66-00 69 00 6e 00 64 00 20 |.o.t. .f .i.n.d. | > > > > Good, surely you are not using 4.2 here! > > > 0030 00 73 00 74 00 6f 00 72-00 65 00 64 00 20 00 70 |.s.t.o.r .e.d. .p| > > > > 0040 00 72 00 6f 00 63 00 65-00 64 00 75 00 72 00 65 |.r.o.c.e .d.u.r.e| > > > > 0050 00 20 00 27 00 62 00 69-00 6c 00 6c 00 69 00 6e |. .'.b.i .l.l.i.n| > > > > 0060 00 67 00 5f 00 64 00 65-00 76 00 2e 00 2e 00 73 |.g._.d.e .v.....s| > > > > 0070 00 70 00 52 00 75 00 61-00 69 00 72 00 69 00 50 |.p.R.u.a .i.r.i.P| > > > > 0080 00 50 00 47 00 65 00 74-00 44 00 65 00 66 00 61 |.P.G.e.t .D.e.f.a| > > > > 0090 00 75 00 6c 00 74 00 73-00 27 00 2e 00 0f 41 00 |.u.l.t.s .'....A.| > > > > 00a0 4c 00 50 00 2d 00 4d 00-41 00 54 00 52 00 49 00 |L.P.-.M. A.T.R.I.| > > > > 00b0 58 00 53 00 51 00 4c 00-53 00 56 00 00 01 00 fe |X.S.Q.L. S.V.....| > > > > 00c0 02 00 e0 00 00 00 00 00- |........| > > > > > > > > token.c:564:processing result tokens. marker is aa(ERROR) > > > > token.c:115:tds_process_default_tokens() marker is aa(ERROR) > > > > token.c:2339:tds_process_msg() reading message 2812 from server > > > > token.c:2411:tds_process_msg() calling client msg handler > > > > ctutil.c:142:_ct_handle_server_message(008472A0, 00847FD0, 0032A850) > > > > ct.c:4330:ct_diag_storeservermsg(008471D8, 00847ED0, 0032A2E4) > > > > token.c:2424:tds_process_msg() returning TDS_SUCCESS > > > > token.c:564:processing result tokens. marker is fe(DONEPROC) > > > > token.c:2075:tds_process_end: more_results = 0 > > > > was_cancelled = 0 > > > > error = 1 > > > > done_count_valid = 0 > > > > token.c:2092: rows_affected = 0 > > > > token.c:2095: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 > > > > ct.c:1186:ct_results() process_result_tokens returned 0 (type 4053) > > > > token.c:549:tds_process_tokens(00847FD0, 0032A958, 0032A94C, 0x6914) > > > > token.c:552:tds_process_tokens() state is COMPLETED > > > > ct.c:1186:ct_results() process_result_tokens returned 1 (type 4052) > > > > ct.c:235:ct_describe_cmd_state(3) > > > > ct.c:235:ct_describe_cmd_state(2) > > > > ct.c:223:setting command state to READY (from SENT) > > > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > > > > > > > > > > > I was wondering has anyone made an attempt to fix this? > > > > > > > > Thanks a million, > > > > Fergus > > > > I actually cannot test if everything is ok, but in src/ctlib/ct.c > there are these lines > > > > case TDS_DONEPROC_RESULT: > > /* > * A DONEPROC result means the end of a logical > * command only if it was one of the commands > * directly sent from ct_send, not as a result > * of a nested stored procedure call. We know > * if this is the case if a STATUS_RESULT was > * received immediately prior to the DONE_PROC > */ > > if (cmd->results_state == _CS_RES_STATUS) { > if (done_flags & TDS_DONE_ERROR) > *result_type = CS_CMD_FAIL; > else > *result_type = CS_CMD_SUCCEED; > cmd->results_state = _CS_RES_CMD_DONE; > return CS_SUCCEED; > } else { > if (cmd->command_type == CS_DYNAMIC_CMD) { > *result_type = CS_CMD_SUCCEED; > cmd->results_state = _CS_RES_CMD_DONE; > return CS_SUCCEED; > } > } > > break; > > > > which seems to me broken! There are some types of commands: > - LANG > - RPC > - SEND_DATA > - SEND_BULK > - CUR > - DYNAMIC > Now for LANG, SEND_DATA and SEND_BULK DONEPROC is not send back, you > are using RPC which should be returning some data, DYNAMIC is handled > by code above but error is not detected and if cursors probably are > using RPCs (for instance using mssql, I don't know Sybase but if they > are not using RPC they are not returning DONEPROC) should be handled. > So I would change the code to (much easier) > > > > case TDS_DONEPROC_RESULT: > > if (done_flags & TDS_DONE_ERROR) > *result_type = CS_CMD_FAIL; > else > *result_type = CS_CMD_SUCCEED; > cmd->results_state = _CS_RES_CMD_DONE; > return CS_SUCCEED; > > > > I don't agree with the comment to check status as for instance in your > example status is not returned (as is returned when you call an RPC > but if the RPC does not exists status is not returned). Can you try if > this code solve the problem for you? I'll need to do some additional > tests (for instance with cursors, dynamic and so on). > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From freddy77 at gmail.com Mon Jul 13 15:13:51 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Mon, 13 Jul 2015 20:13:51 +0100 Subject: [freetds] Progress on AppVeyour In-Reply-To: References: Message-ID: 2015-07-11 1:01 GMT+01:00 Ramiro Morales : > Hi Frediano, > > Sorry for such a belated reply. Life insists on keeping me away from > having fun with this. Thanks for making me realise I never posted to > the list. > No problem, I'm quite busy too. > On Fri, Jun 19, 2015 at 9:49 PM, Frediano Ziglio wrote: >> Hi Ramiro, >> I'm following your progress on AppVeyor, quite interesting. >> >> Some things I notes: >> - you register odbc driver with odbcconf, you can use regsvr32, the >> driver should be able to register itself. Strange to use this program >> for registering an odbc driver instead of a COM component but I added >> this feature; > > Actually I tried the regsrv32 path but it fails for some reason I > can't understand (IIRC OS reported error level 3), that's why the > [1]relevant line is commented out. The lines below it (the ones that > execute dbconf.exe) aren't sucessful either, as I uderstand they also > try to register the driver with the ODBC manager. I copied all this > from old posts to this list. > Weird. By the way I implemented some registration in odbc tests like for unixODBC. Basically a temporary "odbc.ini" is created with a dummy DSN pointing at freetds.conf section. Should work as long as tests are able to find the driver. >> - iconv seems not compiled (as tsql output), looks like some checks >> are not done in CMakeLists.txt and so some variable are not defined >> correctly; > > Exactly, I managed to get iconv to get linked in by using the > win-iconv project but the [2]technique I used is too hacky and that's > why I haven't proposed it (hacky = too windows-specific and too > win-iconv-specific.) > Today I was fighting with win-iconv (there is a package ready in fedora) and MingW trying to use the static version... well... libtool finally won this round. > Actually, I set up thing such that if openssl or iconv aren't > available the build doen'st fail and CMake proceeds to buld FreeTDS > with these features turned off. That's what's happening. > > I have some work in progress to get iconv (GNU libiconv, win-iconv) > detected and linked in when using CMake by grabbing ideas and snippets > from multiple sources around the Net. Unfortunately a module that > performs such detection hasn't been added yet to CMake itself even > when people has been proposing it for something like the last seven > years. > > If/when we add it to our CMakeLists.txt then it will find and link in > the win-iconv copy we already build on AppVeyor. > Good! >> - similar for ODBC, on 64 bit for instance you get lot of problems as >> some define are not there (like HAVE_SQLLEN). Not your fault but can >> cause problems. > > Ok, in fact 64 bit ODBC stuff can be completely borked because I > didn't care about ii at all, hoping to get the basic ODBC stuff > working at leats with one configuration first. > They should be fixed now. >> >> I also added a fix for thread declatation, I'll look forward to see >> results from next compile with updated master to to check if they >> disappeared. It's a pity a thread returns a DWORD instead of a >> DWORD_PTR it's useful to pass a pointerand thread process data passes >> and return other data with another pointer. > > Thanks for your continued work on master. I see you are already > planning a second release this year. Wow. > Well, with all tests and changes that are going on is time for a 1.x > While we are at the AppVeyor Window CI builds topic and now that the > needed files are alredy in the tree I'd like to suggest a remaining > step I described in a [3]comment to the Pull Request: > > > Note: If/when this gets merged, an account needs to be created in > Appveyor by a GitHub FreeTDS organization member/owner (possibly using > GitHub credentials) and then project settings on Appveyor need to be > changed so it scans for the appveyor.yml file in the misc/ subdir > instead of the source tree root. > > This would be the only Web UI action needed. Everything else can be > handled with the appveyor.yml file. > > Sure! > Doing this would give us builds that are automatically triggered on > AppVeyor under the FreeTDS account from every new commit/PR (and > having the build results getting reported in the GitHub UI) without > having to rely on me manually rebasing my ramiro/appveyor branch on > master from time to time and getting these build/results under my > personal account/URL hierarchy. > > Regards, > > > 1. https://github.com/ramiro/freetds/blob/e138e8c410cb4ce1f943975b5018c69c82521a67/misc/appveyor.yml#L103 > 2. https://github.com/ramiro/freetds/commit/e19d808d25042cd551d42ca51db259ccab8ffdca > 3. https://github.com/FreeTDS/freetds/pull/14#issuecomment-111882545 > > -- > Ramiro Morales > @ramiromorales I should put your effort as a TODO for next release bye Frediano From freddy77 at gmail.com Tue Jul 14 13:44:09 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Tue, 14 Jul 2015 18:44:09 +0100 Subject: [freetds] ct-lib error handling In-Reply-To: References: Message-ID: 2015-07-13 14:39 GMT+01:00 Fergus Smith : > Hi, > Thanks very much for your help.I had said TDS Version 4.2 - as that's what tsql -c returns.When I look at the dump files, I see the versions you suggest.It's getting set to 8.0 in freetds.conf ! Please do not use 8.0, see http://www.freetds.org/userguide/choosingtdsprotocol.htm. I plan to remove "8.0" support on next version. > Sybase;net.c:202:Connecting to xx.xx.xx.xx port 4115 (TDS version 5.0) > MS SQL;net.c:202:Connecting to xx.xx.xx.xx port 1603 (TDS version 7.1) > I've made the change you suggest to src/ctlib/ct.cIn initial testing it's working exactly as I'd hoped. > Here's the extract from the MSSQL dump file now;------------------------------------------------------------------------------------token.c:2075:tds_process_end: more_results = 0 was_cancelled = 0 error = 1 done_count_valid = 0token.c:2092: rows_affected = 0token.c:2095:tds_process_end() state set to TDS_IDLEutil.c:165:Changed query state from READING to IDLEutil.c:83:logic error: cannot change query state from IDLE to PENDINGutil.c:165:Changed query state from IDLE to IDLEct.c:1186:ct_results() process_result_tokens returned 0 (type 4053) ct.c:4192:ct_diag(00847F30, 37, 4701, -99999, 0026AA20)ct.c:4488:ct_diag_countmsg(00847238, 4701, 0026AA20)ct.c:4192:ct_diag(00847F30, 33, 4701, 1, 0026B37C)ct.c:4423:ct_diag_getservermsg(00847238, 1, 0026B37C)ct.c:4192:ct_diag(00847F30, 33, 4701, 2, 0026B37C)ct.c:4423:ct_diag_getservermsg(00847238, 2, 0026B37C)ct.c:4192:ct_diag(00847F30, 35, 4701, -99999, 00000000)ct.c:4452:_ct_diag_clearmsg(00847238, 4701)ct.c:1867:ct_cl > ose(00847F30, 301)query.c:3761:tds_disconnect() ------------------------------------------------------------------------------------I'll let you know if I run into any problems with it. My tests seems to work with mssql (all ctlib) however I would like to test against some Sybase products and also check how Sybase ctlib library behave. Frediano > Thanks a million,Fergus >> Date: Sun, 5 Jul 2015 17:16:14 +0100 >> From: freddy77 at gmail.com >> To: freetds at lists.ibiblio.org >> Subject: Re: [freetds] ct-lib error handling >> >> 2015-07-01 15:25 GMT+01:00 Fergus Smith : >> > Hi, >> > >> > >> > >> > I've come across this same problem in every version of FreeTDS I've tried. >> > >> > http://lists.ibiblio.org/pipermail/freetds/2007q3/022165.html >> > Running against MSSQL the error isn't trapped. >> > I think the ct-lib error handler isn't working properly. >> > >> > >> > >> > The test environments are; >> > >> > TDS version: 4.2 >> > >> >> I hope you are not really using this version :) >> At least 5.0 (Sybase) or 7.1 (mssql) >> >> > Version: freetds vdev.0.96.85 >> > >> > Windows 7 SP1 >> > >> > Sybase ASE 12.5.4 >> > >> > Microsoft SQL Server 2012 (SP1) >> > >> > >> > >> > >> > >> > Running on windows against sybase this is the relevant part of the dump file; >> > >> > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >> > >> > ct.c:994:ct_send() succeeded >> > >> > ct.c:1129:ct_results(0058B5C0, 0031A910) >> > >> > token.c:549:tds_process_tokens(00588068, 0031A768, 0031A75C, 0x6914) >> > >> > util.c:165:Changed query state from PENDING to READING >> > >> > packet.c:639:Received packet >> > >> > 0000 04 01 00 dd 00 00 00 00-e5 c9 00 fc 0a 00 00 05 |........ ........| >> > >> > 0010 10 05 5a 5a 5a 5a 5a 00-01 00 ae 00 53 74 6f 72 |..ZZZZZ. ....Stor| >> > >> > 0020 65 64 20 70 72 6f 63 65-64 75 72 65 20 27 63 75 |ed proce dure 'cu| >> > >> > 0030 73 74 6f 6d 65 72 64 62-5f 74 73 74 2e 2e 73 70 |stomerdb _tst..sp| >> > >> > 0040 44 6f 65 73 4e 6f 74 45-78 69 73 74 27 20 6e 6f |DoesNotE xist' no| >> > >> > 0050 74 20 66 6f 75 6e 64 2e-20 53 70 65 63 69 66 79 |t found. Specify| >> > >> > 0060 20 6f 77 6e 65 72 2e 6f-62 6a 65 63 74 6e 61 6d | owner.o bjectnam| >> > >> > 0070 65 20 6f 72 20 75 73 65-20 73 70 5f 68 65 6c 70 |e or use sp_help| >> > >> > 0080 20 74 6f 20 63 68 65 63-6b 20 77 68 65 74 68 65 | to chec k whethe| >> > >> > 0090 72 20 74 68 65 20 6f 62-6a 65 63 74 20 65 78 69 |r the ob ject exi| >> > >> > 00a0 73 74 73 20 28 73 70 5f-68 65 6c 70 20 6d 61 79 |sts (sp_ help may| >> > >> > 00b0 20 70 72 6f 64 75 63 65-20 6c 6f 74 73 20 6f 66 | produce lots of| >> > >> > 00c0 20 6f 75 74 70 75 74 29-2e 0a 06 61 73 65 63 64 | output) ...asecd| >> > >> > 00d0 74 00 01 00 fd 02 00 02-00 00 00 00 00 |t....... .....| >> > >> > >> > >> > token.c:564:processing result tokens. marker is e5(EED) >> > >> > token.c:115:tds_process_default_tokens() marker is e5(EED) >> > >> > token.c:2339:tds_process_msg() reading message 2812 from server >> > >> > token.c:2411:tds_process_msg() calling client msg handler >> > >> > ctutil.c:142:_ct_handle_server_message(005872A0, 00588068, 0031A660) >> > >> > ct.c:4330:ct_diag_storeservermsg(005871D8, 00587ED0, 0031A0F4) >> > >> > token.c:2424:tds_process_msg() returning TDS_SUCCESS >> > >> > token.c:564:processing result tokens. marker is fd(DONE) >> > >> > token.c:2075:tds_process_end: more_results = 0 >> > >> > was_cancelled = 0 >> > >> > error = 1 >> > >> > done_count_valid = 0 >> > >> > token.c:2092: rows_affected = 0 >> > >> > token.c:2095: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 >> > >> > ct.c:1186:ct_results() process_result_tokens returned 0 (type 4052) >> > >> > ct.c:1292:ct_results() results state = 0 >> > >> > ct.c:1293:ct_results() command type = 148 >> > >> > ct.c:1294:ct_results() dynamic cmd = 0 >> > >> > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >> > >> > >> > >> > On windows against MS SQL this is the same part of the dump file; >> > >> > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >> > >> > ct.c:994:ct_send() succeeded >> > >> > ct.c:1129:ct_results(0084C658, 0032AB00) >> > >> > token.c:549:tds_process_tokens(00847FD0, 0032A958, 0032A94C, 0x6914) >> > >> > util.c:165:Changed query state from PENDING to READING >> > >> > packet.c:639:Received packet >> > >> > 0000 04 01 00 c8 00 3d 01 00-aa b4 00 fc 0a 00 00 3e |.....=.. .......>| >> > >> > 0010 10 45 00 43 00 6f 00 75-00 6c 00 64 00 20 00 6e |.E.C.o.u .l.d. .n| >> > >> > 0020 00 6f 00 74 00 20 00 66-00 69 00 6e 00 64 00 20 |.o.t. .f .i.n.d. | >> > >> >> Good, surely you are not using 4.2 here! >> >> > 0030 00 73 00 74 00 6f 00 72-00 65 00 64 00 20 00 70 |.s.t.o.r .e.d. .p| >> > >> > 0040 00 72 00 6f 00 63 00 65-00 64 00 75 00 72 00 65 |.r.o.c.e .d.u.r.e| >> > >> > 0050 00 20 00 27 00 62 00 69-00 6c 00 6c 00 69 00 6e |. .'.b.i .l.l.i.n| >> > >> > 0060 00 67 00 5f 00 64 00 65-00 76 00 2e 00 2e 00 73 |.g._.d.e .v.....s| >> > >> > 0070 00 70 00 52 00 75 00 61-00 69 00 72 00 69 00 50 |.p.R.u.a .i.r.i.P| >> > >> > 0080 00 50 00 47 00 65 00 74-00 44 00 65 00 66 00 61 |.P.G.e.t .D.e.f.a| >> > >> > 0090 00 75 00 6c 00 74 00 73-00 27 00 2e 00 0f 41 00 |.u.l.t.s .'....A.| >> > >> > 00a0 4c 00 50 00 2d 00 4d 00-41 00 54 00 52 00 49 00 |L.P.-.M. A.T.R.I.| >> > >> > 00b0 58 00 53 00 51 00 4c 00-53 00 56 00 00 01 00 fe |X.S.Q.L. S.V.....| >> > >> > 00c0 02 00 e0 00 00 00 00 00- |........| >> > >> > >> > >> > token.c:564:processing result tokens. marker is aa(ERROR) >> > >> > token.c:115:tds_process_default_tokens() marker is aa(ERROR) >> > >> > token.c:2339:tds_process_msg() reading message 2812 from server >> > >> > token.c:2411:tds_process_msg() calling client msg handler >> > >> > ctutil.c:142:_ct_handle_server_message(008472A0, 00847FD0, 0032A850) >> > >> > ct.c:4330:ct_diag_storeservermsg(008471D8, 00847ED0, 0032A2E4) >> > >> > token.c:2424:tds_process_msg() returning TDS_SUCCESS >> > >> > token.c:564:processing result tokens. marker is fe(DONEPROC) >> > >> > token.c:2075:tds_process_end: more_results = 0 >> > >> > was_cancelled = 0 >> > >> > error = 1 >> > >> > done_count_valid = 0 >> > >> > token.c:2092: rows_affected = 0 >> > >> > token.c:2095: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 >> > >> > ct.c:1186:ct_results() process_result_tokens returned 0 (type 4053) >> > >> > token.c:549:tds_process_tokens(00847FD0, 0032A958, 0032A94C, 0x6914) >> > >> > token.c:552:tds_process_tokens() state is COMPLETED >> > >> > ct.c:1186:ct_results() process_result_tokens returned 1 (type 4052) >> > >> > ct.c:235:ct_describe_cmd_state(3) >> > >> > ct.c:235:ct_describe_cmd_state(2) >> > >> > ct.c:223:setting command state to READY (from SENT) >> > >> > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >> > >> > >> > >> > >> > >> > I was wondering has anyone made an attempt to fix this? >> > >> > >> > >> > Thanks a million, >> > >> > Fergus >> > >> >> I actually cannot test if everything is ok, but in src/ctlib/ct.c >> there are these lines >> >> >> >> case TDS_DONEPROC_RESULT: >> >> /* >> * A DONEPROC result means the end of a logical >> * command only if it was one of the commands >> * directly sent from ct_send, not as a result >> * of a nested stored procedure call. We know >> * if this is the case if a STATUS_RESULT was >> * received immediately prior to the DONE_PROC >> */ >> >> if (cmd->results_state == _CS_RES_STATUS) { >> if (done_flags & TDS_DONE_ERROR) >> *result_type = CS_CMD_FAIL; >> else >> *result_type = CS_CMD_SUCCEED; >> cmd->results_state = _CS_RES_CMD_DONE; >> return CS_SUCCEED; >> } else { >> if (cmd->command_type == CS_DYNAMIC_CMD) { >> *result_type = CS_CMD_SUCCEED; >> cmd->results_state = _CS_RES_CMD_DONE; >> return CS_SUCCEED; >> } >> } >> >> break; >> >> >> >> which seems to me broken! There are some types of commands: >> - LANG >> - RPC >> - SEND_DATA >> - SEND_BULK >> - CUR >> - DYNAMIC >> Now for LANG, SEND_DATA and SEND_BULK DONEPROC is not send back, you >> are using RPC which should be returning some data, DYNAMIC is handled >> by code above but error is not detected and if cursors probably are >> using RPCs (for instance using mssql, I don't know Sybase but if they >> are not using RPC they are not returning DONEPROC) should be handled. >> So I would change the code to (much easier) >> >> >> >> case TDS_DONEPROC_RESULT: >> >> if (done_flags & TDS_DONE_ERROR) >> *result_type = CS_CMD_FAIL; >> else >> *result_type = CS_CMD_SUCCEED; >> cmd->results_state = _CS_RES_CMD_DONE; >> return CS_SUCCEED; >> >> >> >> I don't agree with the comment to check status as for instance in your >> example status is not returned (as is returned when you call an RPC >> but if the RPC does not exists status is not returned). Can you try if >> this code solve the problem for you? I'll need to do some additional >> tests (for instance with cursors, dynamic and so on). >> >> Frediano >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> http://lists.ibiblio.org/mailman/listinfo/freetds > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From freddy77 at gmail.com Thu Jul 16 14:07:57 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Thu, 16 Jul 2015 19:07:57 +0100 Subject: [freetds] ct-lib error handling In-Reply-To: References: Message-ID: Sybase is quite different. It use dbrpc token which returns done and not done proc. Status is returned even in case of error. Also cs_cmd_done is returned in any case after cs_cmd_success (procedure exists) or cs_cmd_fail. Il 14/Lug/2015 19:44, "Frediano Ziglio" ha scritto: > 2015-07-13 14:39 GMT+01:00 Fergus Smith : > > Hi, > > Thanks very much for your help.I had said TDS Version 4.2 - as that's > what tsql -c returns.When I look at the dump files, I see the versions you > suggest.It's getting set to 8.0 in freetds.conf ! > > Please do not use 8.0, see > http://www.freetds.org/userguide/choosingtdsprotocol.htm. I plan to > remove "8.0" support on next version. > > > Sybase;net.c:202:Connecting to xx.xx.xx.xx port 4115 (TDS version 5.0) > > MS SQL;net.c:202:Connecting to xx.xx.xx.xx port 1603 (TDS version 7.1) > > I've made the change you suggest to src/ctlib/ct.cIn initial testing > it's working exactly as I'd hoped. > > Here's the extract from the MSSQL dump file > now;------------------------------------------------------------------------------------token.c:2075:tds_process_end: > more_results = 0 was_cancelled = 0 error = 1 > done_count_valid = 0token.c:2092: rows_affected = > 0token.c:2095:tds_process_end() state set to TDS_IDLEutil.c:165:Changed > query state from READING to IDLEutil.c:83:logic error: cannot change query > state from IDLE to PENDINGutil.c:165:Changed query state from IDLE to > IDLEct.c:1186:ct_results() process_result_tokens returned 0 (type 4053) > ct.c:4192:ct_diag(00847F30, 37, 4701, -99999, > 0026AA20)ct.c:4488:ct_diag_countmsg(00847238, 4701, > 0026AA20)ct.c:4192:ct_diag(00847F30, 33, 4701, 1, > 0026B37C)ct.c:4423:ct_diag_getservermsg(00847238, 1, > 0026B37C)ct.c:4192:ct_diag(00847F30, 33, 4701, 2, > 0026B37C)ct.c:4423:ct_diag_getservermsg(00847238, 2, > 0026B37C)ct.c:4192:ct_diag(00847F30, 35, 4701, -99999, > 00000000)ct.c:4452:_ct_diag_clearmsg(00847238, 4701)ct.c:1867:ct_cl > > ose(00847F30, 301)query.c:3761:tds_disconnect() > ------------------------------------------------------------------------------------I'll > let you know if I run into any problems with it. > > My tests seems to work with mssql (all ctlib) however I would like to > test against some Sybase products and also check how Sybase ctlib > library behave. > > Frediano > > > Thanks a million,Fergus > >> Date: Sun, 5 Jul 2015 17:16:14 +0100 > >> From: freddy77 at gmail.com > >> To: freetds at lists.ibiblio.org > >> Subject: Re: [freetds] ct-lib error handling > >> > >> 2015-07-01 15:25 GMT+01:00 Fergus Smith : > >> > Hi, > >> > > >> > > >> > > >> > I've come across this same problem in every version of FreeTDS I've > tried. > >> > > >> > http://lists.ibiblio.org/pipermail/freetds/2007q3/022165.html > >> > Running against MSSQL the error isn't trapped. > >> > I think the ct-lib error handler isn't working properly. > >> > > >> > > >> > > >> > The test environments are; > >> > > >> > TDS version: 4.2 > >> > > >> > >> I hope you are not really using this version :) > >> At least 5.0 (Sybase) or 7.1 (mssql) > >> > >> > Version: freetds vdev.0.96.85 > >> > > >> > Windows 7 SP1 > >> > > >> > Sybase ASE 12.5.4 > >> > > >> > Microsoft SQL Server 2012 (SP1) > >> > > >> > > >> > > >> > > >> > > >> > Running on windows against sybase this is the relevant part of the > dump file; > >> > > >> > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > >> > > >> > ct.c:994:ct_send() succeeded > >> > > >> > ct.c:1129:ct_results(0058B5C0, 0031A910) > >> > > >> > token.c:549:tds_process_tokens(00588068, 0031A768, 0031A75C, 0x6914) > >> > > >> > util.c:165:Changed query state from PENDING to READING > >> > > >> > packet.c:639:Received packet > >> > > >> > 0000 04 01 00 dd 00 00 00 00-e5 c9 00 fc 0a 00 00 05 |........ > ........| > >> > > >> > 0010 10 05 5a 5a 5a 5a 5a 00-01 00 ae 00 53 74 6f 72 |..ZZZZZ. > ....Stor| > >> > > >> > 0020 65 64 20 70 72 6f 63 65-64 75 72 65 20 27 63 75 |ed proce dure > 'cu| > >> > > >> > 0030 73 74 6f 6d 65 72 64 62-5f 74 73 74 2e 2e 73 70 |stomerdb > _tst..sp| > >> > > >> > 0040 44 6f 65 73 4e 6f 74 45-78 69 73 74 27 20 6e 6f |DoesNotE xist' > no| > >> > > >> > 0050 74 20 66 6f 75 6e 64 2e-20 53 70 65 63 69 66 79 |t found. > Specify| > >> > > >> > 0060 20 6f 77 6e 65 72 2e 6f-62 6a 65 63 74 6e 61 6d | owner.o > bjectnam| > >> > > >> > 0070 65 20 6f 72 20 75 73 65-20 73 70 5f 68 65 6c 70 |e or use > sp_help| > >> > > >> > 0080 20 74 6f 20 63 68 65 63-6b 20 77 68 65 74 68 65 | to chec k > whethe| > >> > > >> > 0090 72 20 74 68 65 20 6f 62-6a 65 63 74 20 65 78 69 |r the ob ject > exi| > >> > > >> > 00a0 73 74 73 20 28 73 70 5f-68 65 6c 70 20 6d 61 79 |sts (sp_ help > may| > >> > > >> > 00b0 20 70 72 6f 64 75 63 65-20 6c 6f 74 73 20 6f 66 | produce lots > of| > >> > > >> > 00c0 20 6f 75 74 70 75 74 29-2e 0a 06 61 73 65 63 64 | output) > ...asecd| > >> > > >> > 00d0 74 00 01 00 fd 02 00 02-00 00 00 00 00 |t....... .....| > >> > > >> > > >> > > >> > token.c:564:processing result tokens. marker is e5(EED) > >> > > >> > token.c:115:tds_process_default_tokens() marker is e5(EED) > >> > > >> > token.c:2339:tds_process_msg() reading message 2812 from server > >> > > >> > token.c:2411:tds_process_msg() calling client msg handler > >> > > >> > ctutil.c:142:_ct_handle_server_message(005872A0, 00588068, 0031A660) > >> > > >> > ct.c:4330:ct_diag_storeservermsg(005871D8, 00587ED0, 0031A0F4) > >> > > >> > token.c:2424:tds_process_msg() returning TDS_SUCCESS > >> > > >> > token.c:564:processing result tokens. marker is fd(DONE) > >> > > >> > token.c:2075:tds_process_end: more_results = 0 > >> > > >> > was_cancelled = 0 > >> > > >> > error = 1 > >> > > >> > done_count_valid = 0 > >> > > >> > token.c:2092: rows_affected = 0 > >> > > >> > token.c:2095: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 > >> > > >> > ct.c:1186:ct_results() process_result_tokens returned 0 (type 4052) > >> > > >> > ct.c:1292:ct_results() results state = 0 > >> > > >> > ct.c:1293:ct_results() command type = 148 > >> > > >> > ct.c:1294:ct_results() dynamic cmd = 0 > >> > > >> > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > >> > > >> > > >> > > >> > On windows against MS SQL this is the same part of the dump file; > >> > > >> > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > >> > > >> > ct.c:994:ct_send() succeeded > >> > > >> > ct.c:1129:ct_results(0084C658, 0032AB00) > >> > > >> > token.c:549:tds_process_tokens(00847FD0, 0032A958, 0032A94C, 0x6914) > >> > > >> > util.c:165:Changed query state from PENDING to READING > >> > > >> > packet.c:639:Received packet > >> > > >> > 0000 04 01 00 c8 00 3d 01 00-aa b4 00 fc 0a 00 00 3e |.....=.. > .......>| > >> > > >> > 0010 10 45 00 43 00 6f 00 75-00 6c 00 64 00 20 00 6e |.E.C.o.u .l.d. > .n| > >> > > >> > 0020 00 6f 00 74 00 20 00 66-00 69 00 6e 00 64 00 20 |.o.t. .f > .i.n.d. | > >> > > >> > >> Good, surely you are not using 4.2 here! > >> > >> > 0030 00 73 00 74 00 6f 00 72-00 65 00 64 00 20 00 70 |.s.t.o.r .e.d. > .p| > >> > > >> > 0040 00 72 00 6f 00 63 00 65-00 64 00 75 00 72 00 65 |.r.o.c.e > .d.u.r.e| > >> > > >> > 0050 00 20 00 27 00 62 00 69-00 6c 00 6c 00 69 00 6e |. .'.b.i > .l.l.i.n| > >> > > >> > 0060 00 67 00 5f 00 64 00 65-00 76 00 2e 00 2e 00 73 |.g._.d.e > .v.....s| > >> > > >> > 0070 00 70 00 52 00 75 00 61-00 69 00 72 00 69 00 50 |.p.R.u.a > .i.r.i.P| > >> > > >> > 0080 00 50 00 47 00 65 00 74-00 44 00 65 00 66 00 61 |.P.G.e.t > .D.e.f.a| > >> > > >> > 0090 00 75 00 6c 00 74 00 73-00 27 00 2e 00 0f 41 00 |.u.l.t.s > .'....A.| > >> > > >> > 00a0 4c 00 50 00 2d 00 4d 00-41 00 54 00 52 00 49 00 |L.P.-.M. > A.T.R.I.| > >> > > >> > 00b0 58 00 53 00 51 00 4c 00-53 00 56 00 00 01 00 fe |X.S.Q.L. > S.V.....| > >> > > >> > 00c0 02 00 e0 00 00 00 00 00- |........| > >> > > >> > > >> > > >> > token.c:564:processing result tokens. marker is aa(ERROR) > >> > > >> > token.c:115:tds_process_default_tokens() marker is aa(ERROR) > >> > > >> > token.c:2339:tds_process_msg() reading message 2812 from server > >> > > >> > token.c:2411:tds_process_msg() calling client msg handler > >> > > >> > ctutil.c:142:_ct_handle_server_message(008472A0, 00847FD0, 0032A850) > >> > > >> > ct.c:4330:ct_diag_storeservermsg(008471D8, 00847ED0, 0032A2E4) > >> > > >> > token.c:2424:tds_process_msg() returning TDS_SUCCESS > >> > > >> > token.c:564:processing result tokens. marker is fe(DONEPROC) > >> > > >> > token.c:2075:tds_process_end: more_results = 0 > >> > > >> > was_cancelled = 0 > >> > > >> > error = 1 > >> > > >> > done_count_valid = 0 > >> > > >> > token.c:2092: rows_affected = 0 > >> > > >> > token.c:2095: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 > >> > > >> > ct.c:1186:ct_results() process_result_tokens returned 0 (type 4053) > >> > > >> > token.c:549:tds_process_tokens(00847FD0, 0032A958, 0032A94C, 0x6914) > >> > > >> > token.c:552:tds_process_tokens() state is COMPLETED > >> > > >> > ct.c:1186:ct_results() process_result_tokens returned 1 (type 4052) > >> > > >> > ct.c:235:ct_describe_cmd_state(3) > >> > > >> > ct.c:235:ct_describe_cmd_state(2) > >> > > >> > ct.c:223:setting command state to READY (from SENT) > >> > > >> > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > >> > > >> > > >> > > >> > > >> > > >> > I was wondering has anyone made an attempt to fix this? > >> > > >> > > >> > > >> > Thanks a million, > >> > > >> > Fergus > >> > > >> > >> I actually cannot test if everything is ok, but in src/ctlib/ct.c > >> there are these lines > >> > >> > >> > >> case TDS_DONEPROC_RESULT: > >> > >> /* > >> * A DONEPROC result means the end of a logical > >> * command only if it was one of the commands > >> * directly sent from ct_send, not as a result > >> * of a nested stored procedure call. We know > >> * if this is the case if a STATUS_RESULT was > >> * received immediately prior to the DONE_PROC > >> */ > >> > >> if (cmd->results_state == _CS_RES_STATUS) { > >> if (done_flags & TDS_DONE_ERROR) > >> *result_type = CS_CMD_FAIL; > >> else > >> *result_type = CS_CMD_SUCCEED; > >> cmd->results_state = _CS_RES_CMD_DONE; > >> return CS_SUCCEED; > >> } else { > >> if (cmd->command_type == CS_DYNAMIC_CMD) { > >> *result_type = CS_CMD_SUCCEED; > >> cmd->results_state = _CS_RES_CMD_DONE; > >> return CS_SUCCEED; > >> } > >> } > >> > >> break; > >> > >> > >> > >> which seems to me broken! There are some types of commands: > >> - LANG > >> - RPC > >> - SEND_DATA > >> - SEND_BULK > >> - CUR > >> - DYNAMIC > >> Now for LANG, SEND_DATA and SEND_BULK DONEPROC is not send back, you > >> are using RPC which should be returning some data, DYNAMIC is handled > >> by code above but error is not detected and if cursors probably are > >> using RPCs (for instance using mssql, I don't know Sybase but if they > >> are not using RPC they are not returning DONEPROC) should be handled. > >> So I would change the code to (much easier) > >> > >> > >> > >> case TDS_DONEPROC_RESULT: > >> > >> if (done_flags & TDS_DONE_ERROR) > >> *result_type = CS_CMD_FAIL; > >> else > >> *result_type = CS_CMD_SUCCEED; > >> cmd->results_state = _CS_RES_CMD_DONE; > >> return CS_SUCCEED; > >> > >> > >> > >> I don't agree with the comment to check status as for instance in your > >> example status is not returned (as is returned when you call an RPC > >> but if the RPC does not exists status is not returned). Can you try if > >> this code solve the problem for you? I'll need to do some additional > >> tests (for instance with cursors, dynamic and so on). > >> > >> Frediano > >> _______________________________________________ > >> FreeTDS mailing list > >> FreeTDS at lists.ibiblio.org > >> http://lists.ibiblio.org/mailman/listinfo/freetds > > > > _______________________________________________ > > FreeTDS mailing list > > FreeTDS at lists.ibiblio.org > > http://lists.ibiblio.org/mailman/listinfo/freetds > From randy at thesyrings.us Mon Jul 20 11:46:24 2015 From: randy at thesyrings.us (Randy Syring) Date: Mon, 20 Jul 2015 11:46:24 -0400 Subject: [freetds] Appveyor Builds & Testing In-Reply-To: References: <55A92E62.4030004@thesyrings.us> Message-ID: <55AD17D0.5070003@thesyrings.us> Ha! I forgot I opened that. Are you making any progress on FreeTDS windows binaries? FYI, we have a paid AppVeyor account which makes the builds go much faster vs the free version. I could set up FreeTDS and pymssql on our account if you think that would be helpful. FYI, we are going to PyOhio next weekend and I'm hoping to sprint on pymssql on Friday and Saturday night. I'm thinking getting FreeTDS and pymssql appveyor support going might be a hug win for that sprint. *Randy Syring* Husband | Father | Redeemed Sinner /"For what does it profit a man to gain the whole world and forfeit his soul?" (Mark 8:36 ESV)/ On 07/18/2015 05:16 PM, Ramiro Morales wrote: > Randy, > > There is, of course issse #303 you opened: > https://github.com/pymssql/pymssql/issues/303 > > I see now I had posted a comment with links there. > > On Fri, Jul 17, 2015 at 4:43 PM, Ramiro Morales wrote: >> Randy, >> >> On Fri, Jul 17, 2015 at 1:33 PM, Randy Syring wrote: >>> Ramiro, >>> >>> I've been doing some work on Appveyor lately as we move to get a CI environment setup for some of our apps that run on Windows servers. I thought I remembered you saying something about working on this for pymssql. Have you got anywhere with it or should I start from scratch? I've worked out all the bugs already with getting a the SQL Server going in a way we can connect to: >>> >>> https://github.com/level12/sqlalchemy-appveyor/blob/appveyor/appveyor.yml >>> >>> So starting from scratch isn't a big deal. I just didn't want to step on your toes. >> >> My work on this is on the appveyor branch of the pymssql repo: >> >> https://github.com/ramiro/pymssql/commits/appveyor >> >> and is composed by the appveyor.yml file: >> >> https://github.com/ramiro/pymssql/blob/appveyor/appveyor.yml >> >> and helper files under the appveyor/ subdir: >> >> https://github.com/ramiro/pymssql/tree/appveyor/appveyor >> >> These files actually do build pymssql on Windows with the two MS >> Visual C compilers needed to generate binaries for Python 2.7 -3.3. >> and run our test suite against SQL server instance in Appveyor: >> >> https://ci.appveyor.com/project/ramiro/pymssql >> >> There is one hacky step which is fetching and usage of the FreeTDS >> binaries because it downloads it from a build I perfomed in Appveyor >> of the 0.91 maintenance branch of FreeTDS. >> >> Once I reached that point I kind of stopped working on pymssql and >> switched to work on using Appveyor as a CI platform and for building >> FreeTDS under Windows but in a cleaner way and to actually get the >> needed changes merged in upstream for the FreeTDS 0.95 release. >> Unfortunately didn't achieve that in time for the 0.95 release >> (although once things are finished on master it's cleanly backportable >> to the 0.95 maintenance branch.) >> >> Plan is in the future possibly to use the release API of GitGub to, >> once a build (of a tag?) of FreeTDS is successful, upload a Windows >> FreeTD binaries zipball to GitHub. And use (ie.e download, unpack) >> these release zipballs from the pymssql appveyor.yml CI recipe. >> >> Fell free to ping if you need any help with this. >> >> Regards, >> >>> >>> Thanks. >>> >>> Randy Syring >>> Husband | Father | Redeemed Sinner >>> >>> "For what does it profit a man to gain the whole world >>> and forfeit his soul?" (Mark 8:36 ESV) >>> >> >> >> -- >> Ramiro Morales >> @ramiromorales > > From freddy77 at gmail.com Tue Jul 21 07:06:48 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Tue, 21 Jul 2015 12:06:48 +0100 Subject: [freetds] ct-lib error handling In-Reply-To: References: Message-ID: Fixed. Frediano 2015-07-13 14:39 GMT+01:00 Fergus Smith : > Hi, > Thanks very much for your help.I had said TDS Version 4.2 - as that's what tsql -c returns.When I look at the dump files, I see the versions you suggest.It's getting set to 8.0 in freetds.conf ! > Sybase;net.c:202:Connecting to xx.xx.xx.xx port 4115 (TDS version 5.0) > MS SQL;net.c:202:Connecting to xx.xx.xx.xx port 1603 (TDS version 7.1) > I've made the change you suggest to src/ctlib/ct.cIn initial testing it's working exactly as I'd hoped. > Here's the extract from the MSSQL dump file now;------------------------------------------------------------------------------------token.c:2075:tds_process_end: more_results = 0 was_cancelled = 0 error = 1 done_count_valid = 0token.c:2092: rows_affected = 0token.c:2095:tds_process_end() state set to TDS_IDLEutil.c:165:Changed query state from READING to IDLEutil.c:83:logic error: cannot change query state from IDLE to PENDINGutil.c:165:Changed query state from IDLE to IDLEct.c:1186:ct_results() process_result_tokens returned 0 (type 4053) ct.c:4192:ct_diag(00847F30, 37, 4701, -99999, 0026AA20)ct.c:4488:ct_diag_countmsg(00847238, 4701, 0026AA20)ct.c:4192:ct_diag(00847F30, 33, 4701, 1, 0026B37C)ct.c:4423:ct_diag_getservermsg(00847238, 1, 0026B37C)ct.c:4192:ct_diag(00847F30, 33, 4701, 2, 0026B37C)ct.c:4423:ct_diag_getservermsg(00847238, 2, 0026B37C)ct.c:4192:ct_diag(00847F30, 35, 4701, -99999, 00000000)ct.c:4452:_ct_diag_clearmsg(00847238, 4701)ct.c:1867:ct_cl > ose(00847F30, 301)query.c:3761:tds_disconnect() ------------------------------------------------------------------------------------I'll let you know if I run into any problems with it. > Thanks a million,Fergus >> Date: Sun, 5 Jul 2015 17:16:14 +0100 >> From: freddy77 at gmail.com >> To: freetds at lists.ibiblio.org >> Subject: Re: [freetds] ct-lib error handling >> >> 2015-07-01 15:25 GMT+01:00 Fergus Smith : >> > Hi, >> > >> > >> > >> > I've come across this same problem in every version of FreeTDS I've tried. >> > >> > http://lists.ibiblio.org/pipermail/freetds/2007q3/022165.html >> > Running against MSSQL the error isn't trapped. >> > I think the ct-lib error handler isn't working properly. >> > >> > >> > >> > The test environments are; >> > >> > TDS version: 4.2 >> > >> >> I hope you are not really using this version :) >> At least 5.0 (Sybase) or 7.1 (mssql) >> >> > Version: freetds vdev.0.96.85 >> > >> > Windows 7 SP1 >> > >> > Sybase ASE 12.5.4 >> > >> > Microsoft SQL Server 2012 (SP1) >> > >> > >> > >> > >> > >> > Running on windows against sybase this is the relevant part of the dump file; >> > >> > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >> > >> > ct.c:994:ct_send() succeeded >> > >> > ct.c:1129:ct_results(0058B5C0, 0031A910) >> > >> > token.c:549:tds_process_tokens(00588068, 0031A768, 0031A75C, 0x6914) >> > >> > util.c:165:Changed query state from PENDING to READING >> > >> > packet.c:639:Received packet >> > >> > 0000 04 01 00 dd 00 00 00 00-e5 c9 00 fc 0a 00 00 05 |........ ........| >> > >> > 0010 10 05 5a 5a 5a 5a 5a 00-01 00 ae 00 53 74 6f 72 |..ZZZZZ. ....Stor| >> > >> > 0020 65 64 20 70 72 6f 63 65-64 75 72 65 20 27 63 75 |ed proce dure 'cu| >> > >> > 0030 73 74 6f 6d 65 72 64 62-5f 74 73 74 2e 2e 73 70 |stomerdb _tst..sp| >> > >> > 0040 44 6f 65 73 4e 6f 74 45-78 69 73 74 27 20 6e 6f |DoesNotE xist' no| >> > >> > 0050 74 20 66 6f 75 6e 64 2e-20 53 70 65 63 69 66 79 |t found. Specify| >> > >> > 0060 20 6f 77 6e 65 72 2e 6f-62 6a 65 63 74 6e 61 6d | owner.o bjectnam| >> > >> > 0070 65 20 6f 72 20 75 73 65-20 73 70 5f 68 65 6c 70 |e or use sp_help| >> > >> > 0080 20 74 6f 20 63 68 65 63-6b 20 77 68 65 74 68 65 | to chec k whethe| >> > >> > 0090 72 20 74 68 65 20 6f 62-6a 65 63 74 20 65 78 69 |r the ob ject exi| >> > >> > 00a0 73 74 73 20 28 73 70 5f-68 65 6c 70 20 6d 61 79 |sts (sp_ help may| >> > >> > 00b0 20 70 72 6f 64 75 63 65-20 6c 6f 74 73 20 6f 66 | produce lots of| >> > >> > 00c0 20 6f 75 74 70 75 74 29-2e 0a 06 61 73 65 63 64 | output) ...asecd| >> > >> > 00d0 74 00 01 00 fd 02 00 02-00 00 00 00 00 |t....... .....| >> > >> > >> > >> > token.c:564:processing result tokens. marker is e5(EED) >> > >> > token.c:115:tds_process_default_tokens() marker is e5(EED) >> > >> > token.c:2339:tds_process_msg() reading message 2812 from server >> > >> > token.c:2411:tds_process_msg() calling client msg handler >> > >> > ctutil.c:142:_ct_handle_server_message(005872A0, 00588068, 0031A660) >> > >> > ct.c:4330:ct_diag_storeservermsg(005871D8, 00587ED0, 0031A0F4) >> > >> > token.c:2424:tds_process_msg() returning TDS_SUCCESS >> > >> > token.c:564:processing result tokens. marker is fd(DONE) >> > >> > token.c:2075:tds_process_end: more_results = 0 >> > >> > was_cancelled = 0 >> > >> > error = 1 >> > >> > done_count_valid = 0 >> > >> > token.c:2092: rows_affected = 0 >> > >> > token.c:2095: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 >> > >> > ct.c:1186:ct_results() process_result_tokens returned 0 (type 4052) >> > >> > ct.c:1292:ct_results() results state = 0 >> > >> > ct.c:1293:ct_results() command type = 148 >> > >> > ct.c:1294:ct_results() dynamic cmd = 0 >> > >> > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >> > >> > >> > >> > On windows against MS SQL this is the same part of the dump file; >> > >> > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >> > >> > ct.c:994:ct_send() succeeded >> > >> > ct.c:1129:ct_results(0084C658, 0032AB00) >> > >> > token.c:549:tds_process_tokens(00847FD0, 0032A958, 0032A94C, 0x6914) >> > >> > util.c:165:Changed query state from PENDING to READING >> > >> > packet.c:639:Received packet >> > >> > 0000 04 01 00 c8 00 3d 01 00-aa b4 00 fc 0a 00 00 3e |.....=.. .......>| >> > >> > 0010 10 45 00 43 00 6f 00 75-00 6c 00 64 00 20 00 6e |.E.C.o.u .l.d. .n| >> > >> > 0020 00 6f 00 74 00 20 00 66-00 69 00 6e 00 64 00 20 |.o.t. .f .i.n.d. | >> > >> >> Good, surely you are not using 4.2 here! >> >> > 0030 00 73 00 74 00 6f 00 72-00 65 00 64 00 20 00 70 |.s.t.o.r .e.d. .p| >> > >> > 0040 00 72 00 6f 00 63 00 65-00 64 00 75 00 72 00 65 |.r.o.c.e .d.u.r.e| >> > >> > 0050 00 20 00 27 00 62 00 69-00 6c 00 6c 00 69 00 6e |. .'.b.i .l.l.i.n| >> > >> > 0060 00 67 00 5f 00 64 00 65-00 76 00 2e 00 2e 00 73 |.g._.d.e .v.....s| >> > >> > 0070 00 70 00 52 00 75 00 61-00 69 00 72 00 69 00 50 |.p.R.u.a .i.r.i.P| >> > >> > 0080 00 50 00 47 00 65 00 74-00 44 00 65 00 66 00 61 |.P.G.e.t .D.e.f.a| >> > >> > 0090 00 75 00 6c 00 74 00 73-00 27 00 2e 00 0f 41 00 |.u.l.t.s .'....A.| >> > >> > 00a0 4c 00 50 00 2d 00 4d 00-41 00 54 00 52 00 49 00 |L.P.-.M. A.T.R.I.| >> > >> > 00b0 58 00 53 00 51 00 4c 00-53 00 56 00 00 01 00 fe |X.S.Q.L. S.V.....| >> > >> > 00c0 02 00 e0 00 00 00 00 00- |........| >> > >> > >> > >> > token.c:564:processing result tokens. marker is aa(ERROR) >> > >> > token.c:115:tds_process_default_tokens() marker is aa(ERROR) >> > >> > token.c:2339:tds_process_msg() reading message 2812 from server >> > >> > token.c:2411:tds_process_msg() calling client msg handler >> > >> > ctutil.c:142:_ct_handle_server_message(008472A0, 00847FD0, 0032A850) >> > >> > ct.c:4330:ct_diag_storeservermsg(008471D8, 00847ED0, 0032A2E4) >> > >> > token.c:2424:tds_process_msg() returning TDS_SUCCESS >> > >> > token.c:564:processing result tokens. marker is fe(DONEPROC) >> > >> > token.c:2075:tds_process_end: more_results = 0 >> > >> > was_cancelled = 0 >> > >> > error = 1 >> > >> > done_count_valid = 0 >> > >> > token.c:2092: rows_affected = 0 >> > >> > token.c:2095: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 >> > >> > ct.c:1186:ct_results() process_result_tokens returned 0 (type 4053) >> > >> > token.c:549:tds_process_tokens(00847FD0, 0032A958, 0032A94C, 0x6914) >> > >> > token.c:552:tds_process_tokens() state is COMPLETED >> > >> > ct.c:1186:ct_results() process_result_tokens returned 1 (type 4052) >> > >> > ct.c:235:ct_describe_cmd_state(3) >> > >> > ct.c:235:ct_describe_cmd_state(2) >> > >> > ct.c:223:setting command state to READY (from SENT) >> > >> > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >> > >> > >> > >> > >> > >> > I was wondering has anyone made an attempt to fix this? >> > >> > >> > >> > Thanks a million, >> > >> > Fergus >> > >> >> I actually cannot test if everything is ok, but in src/ctlib/ct.c >> there are these lines >> >> >> >> case TDS_DONEPROC_RESULT: >> >> /* >> * A DONEPROC result means the end of a logical >> * command only if it was one of the commands >> * directly sent from ct_send, not as a result >> * of a nested stored procedure call. We know >> * if this is the case if a STATUS_RESULT was >> * received immediately prior to the DONE_PROC >> */ >> >> if (cmd->results_state == _CS_RES_STATUS) { >> if (done_flags & TDS_DONE_ERROR) >> *result_type = CS_CMD_FAIL; >> else >> *result_type = CS_CMD_SUCCEED; >> cmd->results_state = _CS_RES_CMD_DONE; >> return CS_SUCCEED; >> } else { >> if (cmd->command_type == CS_DYNAMIC_CMD) { >> *result_type = CS_CMD_SUCCEED; >> cmd->results_state = _CS_RES_CMD_DONE; >> return CS_SUCCEED; >> } >> } >> >> break; >> >> >> >> which seems to me broken! There are some types of commands: >> - LANG >> - RPC >> - SEND_DATA >> - SEND_BULK >> - CUR >> - DYNAMIC >> Now for LANG, SEND_DATA and SEND_BULK DONEPROC is not send back, you >> are using RPC which should be returning some data, DYNAMIC is handled >> by code above but error is not detected and if cursors probably are >> using RPCs (for instance using mssql, I don't know Sybase but if they >> are not using RPC they are not returning DONEPROC) should be handled. >> So I would change the code to (much easier) >> >> >> >> case TDS_DONEPROC_RESULT: >> >> if (done_flags & TDS_DONE_ERROR) >> *result_type = CS_CMD_FAIL; >> else >> *result_type = CS_CMD_SUCCEED; >> cmd->results_state = _CS_RES_CMD_DONE; >> return CS_SUCCEED; >> >> >> >> I don't agree with the comment to check status as for instance in your >> example status is not returned (as is returned when you call an RPC >> but if the RPC does not exists status is not returned). Can you try if >> this code solve the problem for you? I'll need to do some additional >> tests (for instance with cursors, dynamic and so on). >> >> Frediano >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> http://lists.ibiblio.org/mailman/listinfo/freetds > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From freddy77 at gmail.com Tue Jul 21 16:53:25 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Tue, 21 Jul 2015 21:53:25 +0100 Subject: [freetds] Appveyor Builds & Testing In-Reply-To: <55AD17D0.5070003@thesyrings.us> References: <55A92E62.4030004@thesyrings.us> <55AD17D0.5070003@thesyrings.us> Message-ID: 2015-07-20 16:46 GMT+01:00 Randy Syring : > Ha! I forgot I opened that. > > Are you making any progress on FreeTDS windows binaries? FYI, we have a > paid AppVeyor account which makes the builds go much faster vs the free > version. I could set up FreeTDS and pymssql on our account if you think > that would be helpful. > Actually I was waiting for you. If you refer to my tries with MingW I usually use it to do some test, I was just trying to compile under Fedora using static win-iconv instead of dynamic one to avoid having to copy dll while doing tests. > FYI, we are going to PyOhio next weekend and I'm hoping to sprint on pymssql > on Friday and Saturday night. I'm thinking getting FreeTDS and pymssql > appveyor support going might be a hug win for that sprint. > I still don't know completely how AppVeyor works. If I can help with something specific just ask. I saw your pull request but I didn't see any following compiling build on AppVeyor so I suppose is not jet finished. > *Randy Syring* > Husband | Father | Redeemed Sinner > > /"For what does it profit a man to gain the whole world > and forfeit his soul?" (Mark 8:36 ESV)/ > Frediano > On 07/18/2015 05:16 PM, Ramiro Morales wrote: >> >> Randy, >> >> There is, of course issse #303 you opened: >> https://github.com/pymssql/pymssql/issues/303 >> >> I see now I had posted a comment with links there. >> >> On Fri, Jul 17, 2015 at 4:43 PM, Ramiro Morales wrote: >>> >>> Randy, >>> >>> On Fri, Jul 17, 2015 at 1:33 PM, Randy Syring >>> wrote: >>>> >>>> Ramiro, >>>> >>>> I've been doing some work on Appveyor lately as we move to get a CI >>>> environment setup for some of our apps that run on Windows servers. I >>>> thought I remembered you saying something about working on this for pymssql. >>>> Have you got anywhere with it or should I start from scratch? I've worked >>>> out all the bugs already with getting a the SQL Server going in a way we can >>>> connect to: >>>> >>>> >>>> https://github.com/level12/sqlalchemy-appveyor/blob/appveyor/appveyor.yml >>>> >>>> So starting from scratch isn't a big deal. I just didn't want to step >>>> on your toes. >>> >>> >>> My work on this is on the appveyor branch of the pymssql repo: >>> >>> https://github.com/ramiro/pymssql/commits/appveyor >>> >>> and is composed by the appveyor.yml file: >>> >>> https://github.com/ramiro/pymssql/blob/appveyor/appveyor.yml >>> >>> and helper files under the appveyor/ subdir: >>> >>> https://github.com/ramiro/pymssql/tree/appveyor/appveyor >>> >>> These files actually do build pymssql on Windows with the two MS >>> Visual C compilers needed to generate binaries for Python 2.7 -3.3. >>> and run our test suite against SQL server instance in Appveyor: >>> >>> https://ci.appveyor.com/project/ramiro/pymssql >>> >>> There is one hacky step which is fetching and usage of the FreeTDS >>> binaries because it downloads it from a build I perfomed in Appveyor >>> of the 0.91 maintenance branch of FreeTDS. >>> >>> Once I reached that point I kind of stopped working on pymssql and >>> switched to work on using Appveyor as a CI platform and for building >>> FreeTDS under Windows but in a cleaner way and to actually get the >>> needed changes merged in upstream for the FreeTDS 0.95 release. >>> Unfortunately didn't achieve that in time for the 0.95 release >>> (although once things are finished on master it's cleanly backportable >>> to the 0.95 maintenance branch.) >>> >>> Plan is in the future possibly to use the release API of GitGub to, >>> once a build (of a tag?) of FreeTDS is successful, upload a Windows >>> FreeTD binaries zipball to GitHub. And use (ie.e download, unpack) >>> these release zipballs from the pymssql appveyor.yml CI recipe. >>> >>> Fell free to ping if you need any help with this. >>> >>> Regards, >>> >>>> >>>> Thanks. >>>> >>>> Randy Syring >>>> Husband | Father | Redeemed Sinner >>>> >>>> "For what does it profit a man to gain the whole world >>>> and forfeit his soul?" (Mark 8:36 ESV) >>>> >>> >>> >>> -- >>> Ramiro Morales >>> @ramiromorales >> >> >> > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From randy at thesyrings.us Tue Jul 21 18:02:43 2015 From: randy at thesyrings.us (Randy Syring) Date: Tue, 21 Jul 2015 18:02:43 -0400 Subject: [freetds] Appveyor Builds & Testing In-Reply-To: References: <55A92E62.4030004@thesyrings.us> <55AD17D0.5070003@thesyrings.us> Message-ID: <55AEC183.8050003@thesyrings.us> On 07/21/2015 04:53 PM, Frediano Ziglio wrote: > Actually I was waiting for you. You were probably waiting for Ramiro, he posted about this previously. :) He and I work together on pymssql and in order for us to get complete CI support there, we will likely need to get FreeTDS building on appveyor as well. Appveyor is pretty cool. My biggest problem is that I don't really know how to build FreeTDS or pymssql on Windows. I'm sure we'll get there though. *Randy Syring* Husband | Father | Redeemed Sinner /"For what does it profit a man to gain the whole world and forfeit his soul?" (Mark 8:36 ESV)/ From sfhacker at hotmail.com Tue Jul 21 19:47:56 2015 From: sfhacker at hotmail.com (Sergio NNX) Date: Wed, 22 Jul 2015 09:47:56 +1000 Subject: [freetds] Appveyor Builds & Testing In-Reply-To: <55AEC183.8050003@thesyrings.us> References: <55A92E62.4030004@thesyrings.us> <55AD17D0.5070003@thesyrings.us>, , <55AEC183.8050003@thesyrings.us> Message-ID: > Appveyor is pretty cool. My biggest problem is that I don't really know > how to build FreeTDS or pymssql on Windows. I'm sure we'll get there > though. I don't have experience with AppVeyor but with other CI products. If you need a hand (or two) building FreeTDS on Windows, let me/us know. It's pretty much an automated process. Have fun. Sergio. From cramm0 at gmail.com Wed Jul 22 07:25:44 2015 From: cramm0 at gmail.com (Ramiro Morales) Date: Wed, 22 Jul 2015 08:25:44 -0300 Subject: [freetds] Appveyor Builds & Testing In-Reply-To: References: <55A92E62.4030004@thesyrings.us> <55AD17D0.5070003@thesyrings.us> Message-ID: On Tue, Jul 21, 2015 at 5:53 PM, Frediano Ziglio wrote: > 2015-07-20 16:46 GMT+01:00 Randy Syring : >> Ha! I forgot I opened that. >> >> Are you making any progress on FreeTDS windows binaries? FYI, we have a >> paid AppVeyor account which makes the builds go much faster vs the free >> version. I could set up FreeTDS and pymssql on our account if you think >> that would be helpful. >> > > Actually I was waiting for you. If you refer to my tries with MingW I > usually use it to do some test, I was just trying to compile under > Fedora using static win-iconv instead of dynamic one to avoid having > to copy dll while doing tests. > [wall of text warning :)] The FreeTDS AppVeyor builds aren't perfect but are perfectly usable (and IMHO useful). My problem is that if I'm a a bit when twisted when explaining things in Spanish, then even much more in English so it seems until now I haven't been able to convey a full description of the status of this. I will try to itemize so to be more clear: 1. What is missing? a) The ability to link in an implementation of iconv under Windows, b) The ability of uploading the artifacts/builds somewhere else e.g. GitHub and c) Fix the problem by which the test_script section of appveyor.yml can't install the ODBC driver and so get the ODBC tests to run successfully. 2. Are these missing things critical? IMHO not. The setup can be useful right now. See item 5 below. 3. What pieces have been merged in already into FreeTDS? Most of it. Frediano merged my PR a few weeks ago to the master branch and the misc/appveyor.yml file plus its helper files are already part of the tree. 4. What the FreeTDS project needs do to get the CI setup to actually trigger builds on AppVeyor? a) An owner of the GitHub organization/project (Frediano?) should create a free account on AppVeyor for the FreeTDS organization/user. This can be done easily as AppVeyor allows one to use GitHub federated/oauth auth. The result will be the ability to create a https://ci.appveyor.com/project/FreeTDS/freetds URL/project associated with the FreeTDS/freetds GitHub repo (similar to how I have https://ci.appveyor.com/project/ramiro/freetds which is the one I use to work on this.) What would this achieve? This GitHub-Appveyor association will allow that every commit to master branch in GitHub triggers a git checkout and a build from an AppVeyor build slave. b) Important: Once the freetds project is created on AppVeyor then the web UI for editing its settings should be used to configure so it lookups appveyor.yml in misc/ instead of in the root of the tree (the default.) c) Merge in the https://github.com/FreeTDS/freetds/pull/17 PR which is the first fixup to the AppVeyor infrastructure. It modifies appveyor.yml so it can detect automatically the version of the Windows OpenSSL binaries published by Shining Light Productions at https://slproweb.com/products/Win32OpenSSL.html. Currently the version needs to be updated manually by editing the OPENSSL_VER envvar and for instance it's value is now 1.0.2c but the available binaries are 1.0.2d. 5. What's the current CI status? AFAICT the last commit that built successfully on AppVeyor (Windows + Visual C compilers (x86/x64) + OpenSSL + SQL Server 2008) is https://github.com/ramiro/freetds/commit/b70875f6ffad487e82300f8813a2ebc4f019029b. See https://ci.appveyor.com/project/ramiro/freetds/build/220 OTOH a later master revision (https://github.com/ramiro/freetds/commit/d170981ad449ff845d8482c84cef4e01e816af64) fails when trying to compile the first .c file: https://ci.appveyor.com/project/ramiro/freetds/build/230/job/hecy80f0pnghbxko#L404 So it seems some of the changes in master between b70875f6ffad487e82300f8813a2ebc4f019029b and d170981ad449ff845d8482c84cef4e01e816af64 broke building on Windows with MS toolchains. 6. How did I set up things to work on this? a) I created an 'appveyor' Git branch in my GitHub fork of freetds. b) I set up Appveyor as explained in item 4 above, every new 'appveyor' branch commit I pushed to GitHub while working on the AppVeyor integration feature triggered a new build. c) In order to be able to also get changes committed to the FreeTDS official repository to be built I periodically merged in changes from master or simply rebased my 'appveyor' branch on top of master. If at this point anyone creates an AppVeyor account and performs these steps (plus item 4 above) then he/she can have a Windows CI environment for FreeTDS but reusing the work already done. This works for an an individual contributor, but not so much for a project like FreeTDS because it depends on a manual step (the merge/rebase one) which needs to be performed periodically by a human. This goes against one basic characteristic of CI which is to automatically attempt building the project after every change. This causes for example that once a regression occurs there is no granularity to know which of the intermediate commit (between the merges/rebases) is the culprit. See item 5 above for an example. This is why IMHO it would be great if Frediano can implement what's described in item 4 above. HTH and keep the good work! Regards, -- Ramiro Morales @ramiromorales From freddy77 at gmail.com Fri Jul 24 13:03:11 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Fri, 24 Jul 2015 18:03:11 +0100 Subject: [freetds] Appveyor Builds & Testing In-Reply-To: References: <55A92E62.4030004@thesyrings.us> <55AD17D0.5070003@thesyrings.us> Message-ID: 2015-07-22 12:25 GMT+01:00 Ramiro Morales : > On Tue, Jul 21, 2015 at 5:53 PM, Frediano Ziglio wrote: >> 2015-07-20 16:46 GMT+01:00 Randy Syring : >>> Ha! I forgot I opened that. >>> >>> Are you making any progress on FreeTDS windows binaries? FYI, we have a >>> paid AppVeyor account which makes the builds go much faster vs the free >>> version. I could set up FreeTDS and pymssql on our account if you think >>> that would be helpful. >>> >> >> Actually I was waiting for you. If you refer to my tries with MingW I >> usually use it to do some test, I was just trying to compile under >> Fedora using static win-iconv instead of dynamic one to avoid having >> to copy dll while doing tests. >> > > [wall of text warning :)] > > The FreeTDS AppVeyor builds aren't perfect but are perfectly usable > (and IMHO useful). > > My problem is that if I'm a a bit when twisted when explaining things > in Spanish, then even much more in English so it seems until now I > haven't been able to convey a full description of the status of this. > > I will try to itemize so to be more clear: > > 1. What is missing? > > a) The ability to link in an implementation of iconv under Windows, b) > The ability of uploading the artifacts/builds somewhere else e.g. > GitHub and c) Fix the problem by which the test_script section of > appveyor.yml can't install the ODBC driver and so get the ODBC tests > to run successfully. > I did some progress, see https://ci.appveyor.com/project/FreeTDS/freetds/build/41 Basically: - account setup correctly; - odbc tests now works (one left does not pass); - registration with regsvr32 now works (strange); - iconv (the one you compile) is now linked in > 2. Are these missing things critical? IMHO not. The setup can be > useful right now. See item 5 below. > > 3. What pieces have been merged in already into FreeTDS? > > Most of it. Frediano merged my PR a few weeks ago to the master branch > and the misc/appveyor.yml file plus its helper files are already part > of the tree. > > 4. What the FreeTDS project needs do to get the CI setup to actually > trigger builds on AppVeyor? > > a) An owner of the GitHub organization/project (Frediano?) should > create a free account on AppVeyor for the FreeTDS organization/user. > This can be done easily as AppVeyor allows one to use GitHub > federated/oauth auth. The result will be the ability to create a > https://ci.appveyor.com/project/FreeTDS/freetds URL/project associated > with the FreeTDS/freetds GitHub repo (similar to how I have > https://ci.appveyor.com/project/ramiro/freetds which is the one I use > to work on this.) > I don't know if I did everything in the right way but works. > What would this achieve? This GitHub-Appveyor association will allow > that every commit to master branch in GitHub triggers a git checkout > and a build from an AppVeyor build slave. > Done > b) Important: Once the freetds project is created on AppVeyor then the > web UI for editing its settings should be used to configure so it > lookups appveyor.yml in misc/ instead of in the root of the tree (the > default.) > Done > c) Merge in the https://github.com/FreeTDS/freetds/pull/17 PR which is > the first fixup to the AppVeyor infrastructure. It modifies > appveyor.yml so it can detect automatically the version of the Windows > OpenSSL binaries published by Shining Light Productions at > https://slproweb.com/products/Win32OpenSSL.html. Currently the version > needs to be updated manually by editing the OPENSSL_VER envvar and for > instance it's value is now 1.0.2c but the available binaries are > 1.0.2d. > I'll try it. Is quite weird the linker warnings about libraries (mix of debug and release) > 5. What's the current CI status? > > AFAICT the last commit that built successfully on AppVeyor (Windows + > Visual C compilers (x86/x64) + OpenSSL + SQL Server 2008) is > https://github.com/ramiro/freetds/commit/b70875f6ffad487e82300f8813a2ebc4f019029b. > See https://ci.appveyor.com/project/ramiro/freetds/build/220 > > OTOH a later master revision > (https://github.com/ramiro/freetds/commit/d170981ad449ff845d8482c84cef4e01e816af64) > fails when trying to compile the first .c file: > > https://ci.appveyor.com/project/ramiro/freetds/build/230/job/hecy80f0pnghbxko#L404 > Yes, fixed in master > So it seems some of the changes in master between > b70875f6ffad487e82300f8813a2ebc4f019029b and > d170981ad449ff845d8482c84cef4e01e816af64 broke building on Windows > with MS toolchains. > > 6. How did I set up things to work on this? > > a) I created an 'appveyor' Git branch in my GitHub fork of freetds. > > b) I set up Appveyor as explained in item 4 above, every new > 'appveyor' branch commit I pushed to GitHub while working on the > AppVeyor integration feature triggered a new build. > > c) In order to be able to also get changes committed to the FreeTDS > official repository to be built I periodically merged in changes from > master or simply rebased my 'appveyor' branch on top of master. > > If at this point anyone creates an AppVeyor account and performs these > steps (plus item 4 above) then he/she can have a Windows CI > environment for FreeTDS but reusing the work already done. > > This works for an an individual contributor, but not so much for a > project like FreeTDS because it depends on a manual step (the > merge/rebase one) which needs to be performed periodically by a human. > This goes against one basic characteristic of CI which is to > automatically attempt building the project after every change. > Obviously it will be merged. > This causes for example that once a regression occurs there is no > granularity to know which of the intermediate commit (between the > merges/rebases) is the culprit. See item 5 above for an example. > Not clear here what you mean. > This is why IMHO it would be great if Frediano can implement what's > described in item 4 above. > > HTH and keep the good work! > > Regards, > > -- > Ramiro Morales > @ramiromorales Frediano From luisdv at icon.co.za Sat Jul 25 07:14:52 2015 From: luisdv at icon.co.za (luisdv at icon.co.za) Date: Sat, 25 Jul 2015 13:14:52 +0200 Subject: [freetds] Appveyor Builds & Testing References: <55A92E62.4030004@thesyrings.us> <55AD17D0.5070003@thesyrings.us>, , <55AEC183.8050003@thesyrings.us> Message-ID: <003001d0c6cb$23474b40$69d5e1c0$@icon.co.za> > I don't have experience with AppVeyor but with other CI products. If > you need a hand (or two) building FreeTDS on Windows, let me/us know. > It's pretty much an automated process. Thanks Sergio. Can you explain the process? How do I build FreeTDS on Windows? From freddy77 at gmail.com Sun Jul 26 10:32:27 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Sun, 26 Jul 2015 15:32:27 +0100 Subject: [freetds] Appveyor Builds & Testing In-Reply-To: References: <55A92E62.4030004@thesyrings.us> <55AD17D0.5070003@thesyrings.us> Message-ID: 2015-07-22 12:25 GMT+01:00 Ramiro Morales : > On Tue, Jul 21, 2015 at 5:53 PM, Frediano Ziglio wrote: >> 2015-07-20 16:46 GMT+01:00 Randy Syring : >>> Ha! I forgot I opened that. >>> >>> Are you making any progress on FreeTDS windows binaries? FYI, we have a >>> paid AppVeyor account which makes the builds go much faster vs the free >>> version. I could set up FreeTDS and pymssql on our account if you think >>> that would be helpful. >>> >> >> Actually I was waiting for you. If you refer to my tries with MingW I >> usually use it to do some test, I was just trying to compile under >> Fedora using static win-iconv instead of dynamic one to avoid having >> to copy dll while doing tests. >> > > [wall of text warning :)] > > The FreeTDS AppVeyor builds aren't perfect but are perfectly usable > (and IMHO useful). > > My problem is that if I'm a a bit when twisted when explaining things > in Spanish, then even much more in English so it seems until now I > haven't been able to convey a full description of the status of this. > > I will try to itemize so to be more clear: > > 1. What is missing? > ... Updates: - merged PR for discovery last OpenSSL version; - all tests now work correctly; - build now fails if tests fail to execute; - updated tds protocol for tests to 7.3 (mssql 2012) do test new types and all feature of test server; - added missing includes to artifacts generated by AppVeyor Frediano From cramm0 at gmail.com Sun Jul 26 12:37:45 2015 From: cramm0 at gmail.com (Ramiro Morales) Date: Sun, 26 Jul 2015 13:37:45 -0300 Subject: [freetds] Appveyor Builds & Testing In-Reply-To: References: <55A92E62.4030004@thesyrings.us> <55AD17D0.5070003@thesyrings.us> Message-ID: On Fri, Jul 24, 2015 at 2:03 PM, Frediano Ziglio wrote: > 2015-07-22 12:25 GMT+01:00 Ramiro Morales : ill be merged. > >> This causes for example that once a regression occurs there is no >> granularity to know which of the intermediate commit (between the >> merges/rebases) is the culprit. See item 5 above for an example. >> > > Not clear here what you mean. > What I tried to say was that in the manual-merge-from-master-from-time-to-time setup it was hard to spot the individual commit that introduced a build error/test regression because in that case Appveyor performed only one build with the changes of all intermediate commits. But you've fixed this and Appveyor already is bulding from master. -- Ramiro Morales @ramiromorales From cramm0 at gmail.com Sun Jul 26 12:44:23 2015 From: cramm0 at gmail.com (Ramiro Morales) Date: Sun, 26 Jul 2015 13:44:23 -0300 Subject: [freetds] Appveyor Builds & Testing In-Reply-To: <003001d0c6cb$23474b40$69d5e1c0$@icon.co.za> References: <55A92E62.4030004@thesyrings.us> <55AD17D0.5070003@thesyrings.us> <55AEC183.8050003@thesyrings.us> <003001d0c6cb$23474b40$69d5e1c0$@icon.co.za> Message-ID: On Sat, Jul 25, 2015 at 8:14 AM, wrote: >> I don't have experience with AppVeyor but with other CI products. If >> you need a hand (or two) building FreeTDS on Windows, let me/us know. >> It's pretty much an automated process. > > Thanks Sergio. Can you explain the process? How do I build FreeTDS on > Windows? Download and install CMake. Optionally download and install OpenSSL from https://slproweb.com/ 8a non-Light version so it includes header and import lib files.) Then execute these steps: https://github.com/FreeTDS/freetds/blob/a9975b9906f62d9fdbb9c9334a9f62fd39b43364/misc/appveyor.yml#L79-L83 in the command line symbol of you MS Visual C studio compiler. You can ignore the %WITH_COMPILER% prefix. HTH -- Ramiro Morales @ramiromorales From cramm0 at gmail.com Sun Jul 26 15:11:47 2015 From: cramm0 at gmail.com (Ramiro Morales) Date: Sun, 26 Jul 2015 16:11:47 -0300 Subject: [freetds] Appveyor Builds & Testing In-Reply-To: References: <55A92E62.4030004@thesyrings.us> <55AD17D0.5070003@thesyrings.us> Message-ID: On Sun, Jul 26, 2015 at 11:32 AM, Frediano Ziglio wrote: > > ... > > Updates: > - merged PR for discovery last OpenSSL version; > - all tests now work correctly; > - build now fails if tests fail to execute; > - updated tds protocol for tests to 7.3 (mssql 2012) do test new types > and all feature of test server; > - added missing includes to artifacts generated by AppVeyor > This is wonderful. Thanks Frediano. I somehow had the idea the GitHub integration with hosted CI providers at the UI level was more explicit for work dode in the main branch of a project. Definitely it's biased towards the PR workflow because the UI feedback about CI results there is definitely more visible. The CI status of a branch can be seen in the 'Branches' [1]tab of the GitHub project main page. The attached image shows master branch as of now (All-green. Yay!) Also, there are [2]dynamically-generated gif/svg/png badges available. e.g.: https://ci.appveyor.com/api/projects/status/github/freetds/freetds?branch=master Perhaps they can be added to some HTML document? Also, maybe it's time to revive the dedicated mailing list for CI notifications idea [3]from March 2014 now that we have two CI platforms? Unfortunately Appveyor [4]doesn't suppport notifications via IRC like Travis. Regards and thanks again, 1. https://github.com/FreeTDS/freetds/branches 2. https://ci.appveyor.com/api/projects/status/github/freetds/freetds?branch=master 3. http://lists.ibiblio.org/pipermail/freetds/2014q1/028849.html 4. http://www.appveyor.com/docs/notifications -- Ramiro Morales @ramiromorales -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot from 2015-07-26 14:31:15.png Type: image/png Size: 83342 bytes Desc: not available URL: From freddy77 at gmail.com Tue Jul 28 13:07:13 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Tue, 28 Jul 2015 18:07:13 +0100 Subject: [freetds] Appveyor Builds & Testing In-Reply-To: References: <55A92E62.4030004@thesyrings.us> <55AD17D0.5070003@thesyrings.us> Message-ID: 2015-07-26 20:11 GMT+01:00 Ramiro Morales : > On Sun, Jul 26, 2015 at 11:32 AM, Frediano Ziglio wrote: > >> >> ... >> >> Updates: >> - merged PR for discovery last OpenSSL version; >> - all tests now work correctly; >> - build now fails if tests fail to execute; >> - updated tds protocol for tests to 7.3 (mssql 2012) do test new types >> and all feature of test server; >> - added missing includes to artifacts generated by AppVeyor >> > > This is wonderful. Thanks Frediano. > > I somehow had the idea the GitHub integration with hosted CI providers > at the UI level was more explicit for work dode in the main branch of > a project. > > Definitely it's biased towards the PR workflow because the UI feedback > about CI results there is definitely more visible. > > The CI status of a branch can be seen in the 'Branches' [1]tab of the > GitHub project main page. The attached image shows master branch as of > now (All-green. Yay!) > > Also, there are [2]dynamically-generated gif/svg/png badges available. e.g.: > > https://ci.appveyor.com/api/projects/status/github/freetds/freetds?branch=master > > Perhaps they can be added to some HTML document? > > Also, maybe it's time to revive the dedicated mailing list for CI > notifications idea [3]from March 2014 now that we have two CI > platforms? Unfortunately Appveyor [4]doesn't suppport notifications > via IRC like Travis. > Would be an idea. I was thinking something in the main page or other of www.freetds.org with main branches, something like https://ci.appveyor.com/api/projects/status/kdlem8y26f8uu8xa/branch/master?svg=true&pendingText=master%20...&passingText=master%20-%20OK&failingText=master%20-%20KO I was thinking a mail on change status would be very low traffic. I enabled it adding the address to the list manually. Let see how does it goes. It would be good also to test with different database and not only with mssql 2012. Perhaps we can test every configuration with a different server version? Actually I'm trying with different tds versions, same server. > Regards and thanks again, > > 1. https://github.com/FreeTDS/freetds/branches > 2. https://ci.appveyor.com/api/projects/status/github/freetds/freetds?branch=master > 3. http://lists.ibiblio.org/pipermail/freetds/2014q1/028849.html > 4. http://www.appveyor.com/docs/notifications > Frediano From no-reply at appveyor.com Tue Jul 28 13:31:36 2015 From: no-reply at appveyor.com (AppVeyor) Date: Tue, 28 Jul 2015 17:31:36 +0000 Subject: [freetds] Build failed: freetds 84 Message-ID: <20150728172123.17735.59623@appveyor.com> From no-reply at appveyor.com Tue Jul 28 13:50:27 2015 From: no-reply at appveyor.com (AppVeyor) Date: Tue, 28 Jul 2015 17:50:27 +0000 Subject: [freetds] Build completed: freetds 85 Message-ID: <20150728175027.17725.54518@appveyor.com> From m.becker at spider-software.net Wed Jul 29 12:17:17 2015 From: m.becker at spider-software.net (Michael Becker) Date: Wed, 29 Jul 2015 18:17:17 +0200 Subject: [freetds] Win32 Make Message-ID: <55B8FC8D.9070000@spider-software.net> Hi, I am using Visual Studio 2015 cmake 3.3.0-rc4 freetds-0.95.18 running cmake -G "NMake Makefiles" . does not find vsnprintf nor _vsnprintf as result of this the file src\replacements\vasprintf.c can not be compiled adding "#define _VSNPRINTF 1" to include\config.h solves the problem is there a better solution? Thanks: Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: m_becker.vcf Type: text/x-vcard Size: 135 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4269 bytes Desc: S/MIME Cryptographic Signature URL: From cramm0 at gmail.com Wed Jul 29 17:29:34 2015 From: cramm0 at gmail.com (Ramiro Morales) Date: Wed, 29 Jul 2015 18:29:34 -0300 Subject: [freetds] Win32 Make In-Reply-To: <55B8FC8D.9070000@spider-software.net> References: <55B8FC8D.9070000@spider-software.net> Message-ID: On Wed, Jul 29, 2015 at 1:17 PM, Michael Becker wrote: > Hi, > > I am using > Visual Studio 2015 > cmake 3.3.0-rc4 > freetds-0.95.18 > > running > > cmake -G "NMake Makefiles" . > > does not find vsnprintf nor _vsnprintf Exactly, I've seen also this because I've started experimenting to add VS 2015 to the Appveyor build matrix (VS 2015 is used to compile soon to-be-released Python 3.5 so we'll need that to build pymssql): https://github.com/FreeTDS/freetds/compare/master...ramiro:ci-appveyor-visual-studio-2015 https://ci.appveyor.com/project/ramiro/freetds/build/246/job/2lgrjkmg2w5agf72#L307 I wonder if Visual Studio 2012/2013/etc has the same issue we know VS 2008/2010 don't because we have them in the matrix already. Doesn't seem to be a Cmake problem, we are using an older version (but not so much and certainly non-RC). > as result of this the file src\replacements\vasprintf.c can not be compiled > adding "#define _VSNPRINTF 1" to include\config.h solves the problem > > is there a better solution? Haven't found one so far. I've been able to extract the following information from the Appveyor build slave VM though (the ability con connect via RDP to the slave is super-useful in these cases): Console excerpt: Using MSVC 2008 build environment for 32 bit architecture Setting environment for using Microsoft Visual Studio 2008 x86 tools. Executing: cmake -G "NMake Makefiles" -DCMAKE_BUILD_TYPE=Release .. -- The C compiler identification is MSVC 15.0.30729.1 -- The CXX compiler identification is MSVC 15.0.30729.1 -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 9.0/VC/bin/cl.exe -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 9.0/VC/bin/cl.exe -- works -- Detecting C compiler ABI info build\CMakeFiles\CMakeError.log file excerpt (presence of msvcrtd.lib is strange, we aren't performing a Debug build): [...] Determining if the function vsnprintf exists failed with the following output: Change Dir: C:/projects/freetds/build/CMakeFiles/CMakeTmp Run Build Command:"nmake" "/NOLOGO" "cmTryCompileExec3758173506\fast" "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\nmake.exe" -f CMakeFiles\cmTryCompileExec3758173506.dir\build.make /nologo -L CMakeFiles\cmTryCompileExec3758173506.dir\build "C:\Program Files (x86)\CMake\bin\cmake.exe" -E cmake_progress_report C:\projects\freetds\build\CMakeFiles\CMakeTmp\CMakeFiles 1 Building C object CMakeFiles/cmTryCompileExec3758173506.dir/CheckFunctionExists.c.obj C:\PROGRA~2\MI0E91~1.0\VC\bin\cl.exe @C:\Users\appveyor\AppData\Local\Temp\nm8F52.tmp CheckFunctionExists.c Linking C executable cmTryCompileExec3758173506.exe "C:\Program Files (x86)\CMake\bin\cmake.exe" -E vs_link_exe C:\PROGRA~2\MI0E91~1.0\VC\bin\link.exe /nologo @CMakeFiles\cmTryCompileExec3758173506.dir\objects1.rsp @C:\Users\appveyor\AppData\Local\Temp\nm901E.tmp CheckFunctionExists.c.obj : error LNK2019: unresolved external symbol _vsnprintf referenced in function _main MSVCRTD.lib(vsnprintf.obj) : error LNK2001: unresolved external symbol _vsnprintf MSVCRTD.lib(vsnprintf.obj) : error LNK2001: unresolved external symbol __vsnprintf cmTryCompileExec3758173506.exe : fatal error LNK1120: 2 unresolved externals LINK Pass 1 failed. with 1120 NMAKE : fatal error U1077: '"C:\Program Files (x86)\CMake\bin\cmake.exe"' : return code '0xffffffff' Stop. NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\nmake.exe"' : return code '0x2' Stop. Determining if the function _vsnprintf exists failed with the following output: Change Dir: C:/projects/freetds/build/CMakeFiles/CMakeTmp Run Build Command:"nmake" "/NOLOGO" "cmTryCompileExec430257698\fast" "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\nmake.exe" -f CMakeFiles\cmTryCompileExec430257698.dir\build.make /nologo -L CMakeFiles\cmTryCompileExec430257698.dir\build "C:\Program Files (x86)\CMake\bin\cmake.exe" -E cmake_progress_report C:\projects\freetds\build\CMakeFiles\CMakeTmp\CMakeFiles 1 Building C object CMakeFiles/cmTryCompileExec430257698.dir/CheckFunctionExists.c.obj C:\PROGRA~2\MI0E91~1.0\VC\bin\cl.exe @C:\Users\appveyor\AppData\Local\Temp\nm932A.tmp CheckFunctionExists.c Linking C executable cmTryCompileExec430257698.exe "C:\Program Files (x86)\CMake\bin\cmake.exe" -E vs_link_exe C:\PROGRA~2\MI0E91~1.0\VC\bin\link.exe /nologo @CMakeFiles\cmTryCompileExec430257698.dir\objects1.rsp @C:\Users\appveyor\AppData\Local\Temp\nm93E7.tmp CheckFunctionExists.c.obj : error LNK2019: unresolved external symbol __vsnprintf referenced in function _main cmTryCompileExec430257698.exe : fatal error LNK1120: 1 unresolved externals LINK Pass 1 failed. with 1120 NMAKE : fatal error U1077: '"C:\Program Files (x86)\CMake\bin\cmake.exe"' : return code '0xffffffff' Stop. NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\nmake.exe"' : return code '0x2' Stop. [...] Regards, -- Ramiro Morales @ramiromorales From cramm0 at gmail.com Wed Jul 29 19:57:43 2015 From: cramm0 at gmail.com (Ramiro Morales) Date: Wed, 29 Jul 2015 20:57:43 -0300 Subject: [freetds] Win32 Make In-Reply-To: References: <55B8FC8D.9070000@spider-software.net> Message-ID: Oops. Please ignore this part of my previous message, it's from an unrelated build: On Wed, Jul 29, 2015 at 6:29 PM, Ramiro Morales wrote: > Console excerpt: > > Using MSVC 2008 build environment for 32 bit architecture > Setting environment for using Microsoft Visual Studio 2008 x86 tools. > Executing: cmake -G "NMake Makefiles" -DCMAKE_BUILD_TYPE=Release .. > -- The C compiler identification is MSVC 15.0.30729.1 > -- The CXX compiler identification is MSVC 15.0.30729.1 > -- Check for working C compiler: C:/Program Files (x86)/Microsoft > Visual Studio 9.0/VC/bin/cl.exe > -- Check for working C compiler: C:/Program Files (x86)/Microsoft > Visual Studio 9.0/VC/bin/cl.exe -- works > -- Detecting C compiler ABI info -- Ramiro Morales @ramiromorales From freddy77 at gmail.com Thu Jul 30 02:27:53 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Thu, 30 Jul 2015 07:27:53 +0100 Subject: [freetds] Win32 Make In-Reply-To: References: <55B8FC8D.9070000@spider-software.net> Message-ID: Il 30/Lug/2015 00:58, "Ramiro Morales" ha scritto: > > Oops. Please ignore this part of my previous message, it's from an > unrelated build: > > On Wed, Jul 29, 2015 at 6:29 PM, Ramiro Morales wrote: > > Console excerpt: > > > > Using MSVC 2008 build environment for 32 bit architecture > > Setting environment for using Microsoft Visual Studio 2008 x86 tools. > > Executing: cmake -G "NMake Makefiles" -DCMAKE_BUILD_TYPE=Release .. > > -- The C compiler identification is MSVC 15.0.30729.1 > > -- The CXX compiler identification is MSVC 15.0.30729.1 > > -- Check for working C compiler: C:/Program Files (x86)/Microsoft > > Visual Studio 9.0/VC/bin/cl.exe > > -- Check for working C compiler: C:/Program Files (x86)/Microsoft > > Visual Studio 9.0/VC/bin/cl.exe -- works > > -- Detecting C compiler ABI info > > There are different possibilities. Function is inline (I suspect it is). Function is non __cdecl. Function is declared as C++ (I don't think so). Can you find function declaration into the headers? Frediano From m.becker at spider-software.net Thu Jul 30 06:41:02 2015 From: m.becker at spider-software.net (Michael Becker) Date: Thu, 30 Jul 2015 12:41:02 +0200 Subject: [freetds] Win32 Make In-Reply-To: References: <55B8FC8D.9070000@spider-software.net> Message-ID: <55B9FF3E.9050204@spider-software.net> > > There are different possibilities. Function is inline (I suspect it is). > Function is non __cdecl. Function is declared as C++ (I don't think so). > Can you find function declaration into the headers? > both (vsnprintf and _vsnprintf) are in stdio.h and both are inlines ... -------------- 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: smime.p7s Type: application/pkcs7-signature Size: 4269 bytes Desc: S/MIME Cryptographic Signature URL: From m.becker at spider-software.net Thu Jul 30 07:04:09 2015 From: m.becker at spider-software.net (Michael Becker) Date: Thu, 30 Jul 2015 13:04:09 +0200 Subject: [freetds] Win32 Make In-Reply-To: <55B9FF3E.9050204@spider-software.net> References: <55B8FC8D.9070000@spider-software.net> <55B9FF3E.9050204@spider-software.net> Message-ID: <55BA04A9.6040404@spider-software.net> have created an entry in cmake bugtracker On 30/07/15 12:41, Michael Becker wrote: >> >> There are different possibilities. Function is inline (I suspect it is). >> Function is non __cdecl. Function is declared as C++ (I don't think so). >> Can you find function declaration into the headers? >> > > both (vsnprintf and _vsnprintf) are in stdio.h and both are inlines ... > > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > -------------- 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: smime.p7s Type: application/pkcs7-signature Size: 4269 bytes Desc: S/MIME Cryptographic Signature URL: From m.becker at spider-software.net Thu Jul 30 10:26:39 2015 From: m.becker at spider-software.net (Michael Becker) Date: Thu, 30 Jul 2015 16:26:39 +0200 Subject: [freetds] Win32 Make In-Reply-To: <55BA04A9.6040404@spider-software.net> References: <55B8FC8D.9070000@spider-software.net> <55B9FF3E.9050204@spider-software.net> <55BA04A9.6040404@spider-software.net> Message-ID: <55BA341F.2000204@spider-software.net> these functions must be checked using check_symbol_exists I have changed CMakeLists.txt as follows: ============================================== # find functions set(CMAKE_REQUIRED_LIBRARIES ${CMAKE_THREAD_LIBS_INIT}) set(FUNCS _atoi64 strtok_r readpassphrase strlcpy strlcat basename getopt strsep gettimeofday nl_langinfo locale_charset setenv putenv getuid getpwuid getpwuid_r fstat alarm fork gethrtime localtime_r setitimer _fseeki64 _ftelli64 setrlimit inet_ntoa_r getipnodebyaddr getipnodebyname getaddrinfo inet_ntop gethostname poll socketpair clock_gettime fseeko pthread_cond_timedwait pthread_condattr_setclock _lock_file _unlock_file usleep nanosleep readdir_r) foreach(func ${FUNCS}) string(TOUPPER "HAVE_${func}" var) check_function_exists(${func} ${var}) set(HAVE_GETADDRINFO 1 CACHE INTERNAL "") config_write("/* Define to 1 if you have function <${func}>. */\n") config_write("#cmakedefine ${var} 1\n\n") endforeach(func) set(VSPRINTF asprintf vasprintf vsnprintf _vsnprintf snprintf _snprintf _vscprintf) foreach(func ${VSPRINTF}) string(TOUPPER "HAVE_${func}" var) check_symbol_exists(${func} stdio.h ${var}) config_write("/* Define to 1 if you have function <${func}>. */\n") config_write("#cmakedefine ${var} 1\n\n") endforeach(func) set(CMAKE_REQUIRED_LIBRARIES) ============================================== This works for the replacement functions but runs into an error when linking tdsodbc.dll because some stdio functions seem to have moved to legacy_stdio_definitions.lib How can this lib be included optional into cmake? On 30/07/15 13:04, Michael Becker wrote: > have created an entry in cmake bugtracker > > On 30/07/15 12:41, Michael Becker wrote: >>> >>> There are different possibilities. Function is inline (I suspect it is). >>> Function is non __cdecl. Function is declared as C++ (I don't think so). >>> Can you find function declaration into the headers? >>> >> >> both (vsnprintf and _vsnprintf) are in stdio.h and both are inlines ... >> >> >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> http://lists.ibiblio.org/mailman/listinfo/freetds >> > > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > -------------- 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: smime.p7s Type: application/pkcs7-signature Size: 4269 bytes Desc: S/MIME Cryptographic Signature URL: From freddy77 at gmail.com Thu Jul 30 14:23:22 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Thu, 30 Jul 2015 19:23:22 +0100 Subject: [freetds] Win32 Make In-Reply-To: <55BA341F.2000204@spider-software.net> References: <55B8FC8D.9070000@spider-software.net> <55B9FF3E.9050204@spider-software.net> <55BA04A9.6040404@spider-software.net> <55BA341F.2000204@spider-software.net> Message-ID: 2015-07-30 15:26 GMT+01:00 Michael Becker : > these functions must be checked using check_symbol_exists > > I have changed CMakeLists.txt as follows: > > ============================================== > # find functions > set(CMAKE_REQUIRED_LIBRARIES ${CMAKE_THREAD_LIBS_INIT}) > set(FUNCS _atoi64 strtok_r readpassphrase > strlcpy strlcat basename getopt strsep gettimeofday > nl_langinfo locale_charset setenv putenv > getuid getpwuid getpwuid_r fstat alarm fork > gethrtime localtime_r setitimer > _fseeki64 _ftelli64 setrlimit > inet_ntoa_r getipnodebyaddr getipnodebyname > getaddrinfo inet_ntop gethostname poll socketpair > clock_gettime fseeko pthread_cond_timedwait > pthread_condattr_setclock _lock_file _unlock_file usleep nanosleep > readdir_r) > > foreach(func ${FUNCS}) > string(TOUPPER "HAVE_${func}" var) > check_function_exists(${func} ${var}) > set(HAVE_GETADDRINFO 1 CACHE INTERNAL "") > config_write("/* Define to 1 if you have function <${func}>. */\n") > config_write("#cmakedefine ${var} 1\n\n") > endforeach(func) > > set(VSPRINTF asprintf vasprintf vsnprintf _vsnprintf snprintf _snprintf > _vscprintf) > > foreach(func ${VSPRINTF}) > string(TOUPPER "HAVE_${func}" var) > check_symbol_exists(${func} stdio.h ${var}) > config_write("/* Define to 1 if you have function <${func}>. */\n") > config_write("#cmakedefine ${var} 1\n\n") > endforeach(func) > > set(CMAKE_REQUIRED_LIBRARIES) > ============================================== > Change a bit to do both the tests, it continues to build on old Visual Studio versions. > This works for the replacement functions but runs into an error when linking > tdsodbc.dll because some stdio functions seem to have moved to > legacy_stdio_definitions.lib > Which functions? > How can this lib be included optional into cmake? > I think just include in lib_BASE define but perhaps would be better to avoid to use them. Depends on the functions. Frediano > > > > > > On 30/07/15 13:04, Michael Becker wrote: >> >> have created an entry in cmake bugtracker >> >> On 30/07/15 12:41, Michael Becker wrote: >>>> >>>> >>>> There are different possibilities. Function is inline (I suspect it is). >>>> Function is non __cdecl. Function is declared as C++ (I don't think so). >>>> Can you find function declaration into the headers? >>>> >>> >>> both (vsnprintf and _vsnprintf) are in stdio.h and both are inlines ... >>> >>> >>> _______________________________________________ >>> FreeTDS mailing list >>> FreeTDS at lists.ibiblio.org >>> http://lists.ibiblio.org/mailman/listinfo/freetds >>> >> >> >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> http://lists.ibiblio.org/mailman/listinfo/freetds >> > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > From craigberry at mac.com Thu Jul 30 22:03:19 2015 From: craigberry at mac.com (Craig A. Berry) Date: Thu, 30 Jul 2015 21:03:19 -0500 Subject: [freetds] Win32 Make In-Reply-To: References: <55B8FC8D.9070000@spider-software.net> <55B9FF3E.9050204@spider-software.net> <55BA04A9.6040404@spider-software.net> <55BA341F.2000204@spider-software.net> Message-ID: <63B71A62-ED31-480F-AB8C-47B7B68B2F5C@mac.com> > On Jul 30, 2015, at 1:23 PM, Frediano Ziglio wrote: > > 2015-07-30 15:26 GMT+01:00 Michael Becker : >> these functions must be checked using check_symbol_exists >> >> I have changed CMakeLists.txt as follows: >> >> ============================================== >> # find functions >> set(CMAKE_REQUIRED_LIBRARIES ${CMAKE_THREAD_LIBS_INIT}) >> set(FUNCS _atoi64 strtok_r readpassphrase >> strlcpy strlcat basename getopt strsep gettimeofday >> nl_langinfo locale_charset setenv putenv >> getuid getpwuid getpwuid_r fstat alarm fork >> gethrtime localtime_r setitimer >> _fseeki64 _ftelli64 setrlimit >> inet_ntoa_r getipnodebyaddr getipnodebyname >> getaddrinfo inet_ntop gethostname poll socketpair >> clock_gettime fseeko pthread_cond_timedwait >> pthread_condattr_setclock _lock_file _unlock_file usleep nanosleep >> readdir_r) >> >> foreach(func ${FUNCS}) >> string(TOUPPER "HAVE_${func}" var) >> check_function_exists(${func} ${var}) >> set(HAVE_GETADDRINFO 1 CACHE INTERNAL "") >> config_write("/* Define to 1 if you have function <${func}>. */\n") >> config_write("#cmakedefine ${var} 1\n\n") >> endforeach(func) >> >> set(VSPRINTF asprintf vasprintf vsnprintf _vsnprintf snprintf _snprintf >> _vscprintf) >> >> foreach(func ${VSPRINTF}) >> string(TOUPPER "HAVE_${func}" var) >> check_symbol_exists(${func} stdio.h ${var}) >> config_write("/* Define to 1 if you have function <${func}>. */\n") >> config_write("#cmakedefine ${var} 1\n\n") >> endforeach(func) >> >> set(CMAKE_REQUIRED_LIBRARIES) >> ============================================== >> > > Change a bit to do both the tests, it continues to build on old Visual > Studio versions. > >> This works for the replacement functions but runs into an error when linking >> tdsodbc.dll because some stdio functions seem to have moved to >> legacy_stdio_definitions.lib Assuming we are still talking about the printf/scanf family of functions, according to: you should get the inline functions and no link errors if you are including the correct headers. This is the recommended solution. Only if you are unable or unwilling to include the necessary headers would you need to link against legacy_stdio_definitions.lib. I don?t know how check_function_exists in the code quoted above works. If it?s just looking for a symbol in a library, that?s not really adequate to determine what the compiler will see. >> > > Which functions? > >> How can this lib be included optional into cmake? >> > > I think just include in lib_BASE define but perhaps would be better to > avoid to use them. Depends on the functions. ________________________________________ Craig A. Berry mailto:craigberry at mac.com "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser From m.becker at spider-software.net Fri Jul 31 02:50:23 2015 From: m.becker at spider-software.net (Michael Becker) Date: Fri, 31 Jul 2015 08:50:23 +0200 Subject: [freetds] Win32 Make In-Reply-To: <63B71A62-ED31-480F-AB8C-47B7B68B2F5C@mac.com> References: <55B8FC8D.9070000@spider-software.net> <55B9FF3E.9050204@spider-software.net> <55BA04A9.6040404@spider-software.net> <55BA341F.2000204@spider-software.net> <63B71A62-ED31-480F-AB8C-47B7B68B2F5C@mac.com> Message-ID: <55BB1AAF.403@spider-software.net> >> >> Which functions? >> I get a linker error: unresolved external symbol "__vsnwprintf_s" according https://connect.microsoft.com/VisualStudio/feedback/details/1039102 it is in legacy_stdio_definitions.lib -------------- 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: smime.p7s Type: application/pkcs7-signature Size: 4269 bytes Desc: S/MIME Cryptographic Signature URL: From no-reply at appveyor.com Fri Jul 31 06:18:28 2015 From: no-reply at appveyor.com (AppVeyor) Date: Fri, 31 Jul 2015 10:18:28 +0000 Subject: [freetds] Build failed: freetds 88 Message-ID: <20150731101828.17719.60849@appveyor.com> From cramm0 at gmail.com Fri Jul 31 06:41:49 2015 From: cramm0 at gmail.com (Ramiro Morales) Date: Fri, 31 Jul 2015 07:41:49 -0300 Subject: [freetds] Win32 Make In-Reply-To: References: <55B8FC8D.9070000@spider-software.net> <55B9FF3E.9050204@spider-software.net> <55BA04A9.6040404@spider-software.net> <55BA341F.2000204@spider-software.net> Message-ID: On Thu, Jul 30, 2015 at 3:23 PM, Frediano Ziglio wrote: > 2015-07-30 15:26 GMT+01:00 Michael Becker : >> these functions must be checked using check_symbol_exists >> >> I have changed CMakeLists.txt as follows: >> [...] >> > > Change a bit to do both the tests, it continues to build on old Visual > Studio versions. > I see Frediano commited a variation of the proposed patch, but it seems it still doesn't detect them (at least on AppVeyor): https://ci.appveyor.com/project/FreeTDS/freetds/build/89#L304 Michael: Do you get same failure in your local VS2015 environment? Had been playing with CheckSymbolExists and another strategy but can't get it to work either: https://github.com/ramiro/freetds/commit/7c089c360d52114f12c54b3e4923468f4fd0ae86 https://ci.appveyor.com/project/ramiro/freetds/build/260 Regards, -- Ramiro Morales @ramiromorales From m.becker at spider-software.net Fri Jul 31 06:58:56 2015 From: m.becker at spider-software.net (Michael Becker) Date: Fri, 31 Jul 2015 12:58:56 +0200 Subject: [freetds] Win32 Make In-Reply-To: References: <55B8FC8D.9070000@spider-software.net> <55B9FF3E.9050204@spider-software.net> <55BA04A9.6040404@spider-software.net> <55BA341F.2000204@spider-software.net> Message-ID: <55BB54F0.1020808@spider-software.net> On 31/07/15 12:41, Ramiro Morales wrote: > On Thu, Jul 30, 2015 at 3:23 PM, Frediano Ziglio wrote: >> 2015-07-30 15:26 GMT+01:00 Michael Becker : >>> these functions must be checked using check_symbol_exists >>> >>> I have changed CMakeLists.txt as follows: >>> [...] >>> >> >> Change a bit to do both the tests, it continues to build on old Visual >> Studio versions. >> > > I see Frediano commited a variation of the proposed patch, but it > seems it still doesn't detect them (at least on AppVeyor): > > https://ci.appveyor.com/project/FreeTDS/freetds/build/89#L304 > > Michael: Do you get same failure in your local VS2015 environment? > > Had been playing with CheckSymbolExists and another strategy but can't > get it to work either: > > https://github.com/ramiro/freetds/commit/7c089c360d52114f12c54b3e4923468f4fd0ae86 > https://ci.appveyor.com/project/ramiro/freetds/build/260 > > Regards, > probabely you have to add "C:\Program Files (x86)\Windows Kits\10\Include\10.0.10150.0\ucrt" to your include directories, because stdio.h went into "Windows Kits" this is done in my environment by setting the env-variable INCLUDE compilation works fine with that, but I am still hanging at the link problem -------------- 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: smime.p7s Type: application/pkcs7-signature Size: 4269 bytes Desc: S/MIME Cryptographic Signature URL: From freddy77 at gmail.com Fri Jul 31 12:18:56 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Fri, 31 Jul 2015 17:18:56 +0100 Subject: [freetds] Win32 Make In-Reply-To: <55BB54F0.1020808@spider-software.net> References: <55B8FC8D.9070000@spider-software.net> <55B9FF3E.9050204@spider-software.net> <55BA04A9.6040404@spider-software.net> <55BA341F.2000204@spider-software.net> <55BB54F0.1020808@spider-software.net> Message-ID: 2015-07-31 11:58 GMT+01:00 Michael Becker : > > > On 31/07/15 12:41, Ramiro Morales wrote: >> >> On Thu, Jul 30, 2015 at 3:23 PM, Frediano Ziglio >> wrote: >>> >>> 2015-07-30 15:26 GMT+01:00 Michael Becker : >>>> >>>> these functions must be checked using check_symbol_exists >>>> >>>> I have changed CMakeLists.txt as follows: >>>> [...] >>>> >>> >>> Change a bit to do both the tests, it continues to build on old Visual >>> Studio versions. >>> >> >> I see Frediano commited a variation of the proposed patch, but it >> seems it still doesn't detect them (at least on AppVeyor): >> >> https://ci.appveyor.com/project/FreeTDS/freetds/build/89#L304 >> >> Michael: Do you get same failure in your local VS2015 environment? >> >> Had been playing with CheckSymbolExists and another strategy but can't >> get it to work either: >> >> >> https://github.com/ramiro/freetds/commit/7c089c360d52114f12c54b3e4923468f4fd0ae86 >> https://ci.appveyor.com/project/ramiro/freetds/build/260 >> >> Regards, >> > > probabely you have to add "C:\Program Files (x86)\Windows > Kits\10\Include\10.0.10150.0\ucrt" to your include directories, because > stdio.h went into "Windows Kits" > this is done in my environment by setting the env-variable INCLUDE > compilation works fine with that, but I am still hanging at the link problem > For the printf problem I ended up with this patch https://github.com/FreeTDS/freetds/commit/9503e9accecd47f6c7e71a57b846c3f234313993. Looks fine and works in both Windows and Linux. I started having a problem with linking however. https://ci.appveyor.com/project/FreeTDS/freetds/build/91/job/3wp9db8c3uqvgq0n. Looks like library that visual studio try to use are not compiled with same options :( Could be SDKs used is the wrong one ? Frediano From m.becker at spider-software.net Fri Jul 31 13:30:14 2015 From: m.becker at spider-software.net (Michael Becker) Date: Fri, 31 Jul 2015 19:30:14 +0200 Subject: [freetds] Win32 Make In-Reply-To: References: <55B8FC8D.9070000@spider-software.net> <55B9FF3E.9050204@spider-software.net> <55BA04A9.6040404@spider-software.net> <55BA341F.2000204@spider-software.net> <55BB54F0.1020808@spider-software.net> Message-ID: <55BBB0A6.1000906@spider-software.net> > For the printf problem I ended up with this patch > https://github.com/FreeTDS/freetds/commit/9503e9accecd47f6c7e71a57b846c3f234313993. > Looks fine and works in both Windows and Linux. > I started having a problem with linking however. > https://ci.appveyor.com/project/FreeTDS/freetds/build/91/job/3wp9db8c3uqvgq0n. > Looks like library that visual studio try to use are not compiled with > same options :( Could be SDKs used is the wrong one ? > for that reason I tried to include legacy_stdio_definitions.lib if I change the makefile by hand it works fine with the lib, but I didn't manage to adjust the CMakeLists.txt in the right way ... -------------- 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: smime.p7s Type: application/pkcs7-signature Size: 4269 bytes Desc: S/MIME Cryptographic Signature URL: From mewalig at gmail.com Sat Aug 1 13:25:32 2015 From: mewalig at gmail.com (mew_alig) Date: Sat, 1 Aug 2015 17:25:32 +0000 (UTC) Subject: [freetds] License Question References: <55F7E71F-755C-400C-8000-EE564E92D6AA@metaskills.net> <20110527221652.4385A56540@rebar.astron.com> <20110528151318.318ef7c1.jklowden@freetds.org> Message-ID: James K. Lowden freetds.org> writes: > > On Fri, 27 May 2011 18:16:52 -0400 > christos zoulas.com (Christos Zoulas) wrote: > > > I think that you are on dangerous ground > > by statically linking, because the functionality your gem is > > presenting to the rest of the world, is the functionality provided by > > freetds and nothing more, so you would end up being considered a > > derivative work. > > I disagree. I think it's worth discussing, because anyone contributing > to FreeTDS wants to understand what the LGPL means. > > Whether or not a work is "derived" is independent of how it's linked. > > The method of linking changes the technical requirements on the > distributor because the same *effect* -- substituting a different > version of the LGPL library -- requires different procedures. (Static > linking obviously requires relinking, ergo object code.) > > The LGPL doesn't discuss language-binding adpators, doesn't distinguish > among the kinds of "applications" that might link to a library. I > don't see how, from a nontechnical point of view, one can distinguish > between providing a new interface for another programming language and > providing a new interface to standard input. > > http://www.schemamania.org/dbstreams/ > > dbstreams is analogous. I put it in the public domain because I would > rather see it used than involve the SFLC. But I would maintain that a > C ++ program linked to dbstreams and using FreeTDS is untouched by the > LGPL. > > I don't see any difference between a Ruby library and a C++ library > other than the language it supports. ISTM a library supporting > another language is an "application" of the library, not a "derivation" > of it. > > Regards, > > --jkl > I know this thread is a few years old so please forgive me if I'm beating a dead horse. I suppose these questions are more about LGPL in general, but would appreciate any thoughts given that the specific LGPL-covered software that we are concerned about is FreeTDS. I am involved in a closed-source commercial project which includes some functionality to connect to and interact with a SQL server database. Below are the distribution choices we are considering. Are #1, #2 and/or #3 allowable under the FreeTDS license terms, assuming that a) all required notices are provided, b) no source or object code is made available to the client, other than that of FreeTDS, and c) FreeTDS is incorporated into the end solution either by one of our executables making a system call to execute a FreeTDS executable (such as freebcp), or by calling a function that is available via dynamically linking to the FreeTDS library. 1. Provide client with a physical box that provides services over the network. Client has no access to files of any sort inside the box. The box ships with various object code including the FreeTDS executable(s) and/or dynamically-linked libraries that are used by some of our commercial, closed-source executables. 2. Provide client with means to install software on its own computers. This is the same as #1 except that now, the client owns the physical box that holds the files, and has access to those files (including FreeTDS executables and/or DLLs that are bundled with installation). 3. Same as #2 except that we do not ship with any FreeTDS executables or libraries. Instead, client must install FreeTDS components on their own. 4. Same as #3 except that instead of client installing FreeTDS, client installs the Microsoft SQL Server tools. Thanks in advance for your help From freddy77 at gmail.com Sat Aug 1 13:57:32 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Sat, 1 Aug 2015 18:57:32 +0100 Subject: [freetds] License Question In-Reply-To: References: <55F7E71F-755C-400C-8000-EE564E92D6AA@metaskills.net> <20110527221652.4385A56540@rebar.astron.com> <20110528151318.318ef7c1.jklowden@freetds.org> Message-ID: Il 01/Ago/2015 18:48, "mew_alig" ha scritto: > > James K. Lowden freetds.org> writes: > > > > > On Fri, 27 May 2011 18:16:52 -0400 > > christos zoulas.com (Christos Zoulas) wrote: > > > > > I think that you are on dangerous ground > > > by statically linking, because the functionality your gem is > > > presenting to the rest of the world, is the functionality provided by > > > freetds and nothing more, so you would end up being considered a > > > derivative work. > > > > I disagree. I think it's worth discussing, because anyone contributing > > to FreeTDS wants to understand what the LGPL means. > > > > Whether or not a work is "derived" is independent of how it's linked. > > > > The method of linking changes the technical requirements on the > > distributor because the same *effect* -- substituting a different > > version of the LGPL library -- requires different procedures. (Static > > linking obviously requires relinking, ergo object code.) > > > > The LGPL doesn't discuss language-binding adpators, doesn't distinguish > > among the kinds of "applications" that might link to a library. I > > don't see how, from a nontechnical point of view, one can distinguish > > between providing a new interface for another programming language and > > providing a new interface to standard input. > > > > http://www.schemamania.org/dbstreams/ > > > > dbstreams is analogous. I put it in the public domain because I would > > rather see it used than involve the SFLC. But I would maintain that a > > C ++ program linked to dbstreams and using FreeTDS is untouched by the > > LGPL. > > > > I don't see any difference between a Ruby library and a C++ library > > other than the language it supports. ISTM a library supporting > > another language is an "application" of the library, not a "derivation" > > of it. > > > > Regards, > > > > --jkl > > > > > I know this thread is a few years old so please forgive me > if I'm beating a dead horse. I suppose these questions are > more about LGPL in general, but would appreciate any thoughts > given that the specific LGPL-covered software that we are > concerned about is FreeTDS. > > I am involved in a closed-source commercial project which > includes some functionality to connect to and interact with a > SQL server database. Below are the distribution choices we are > considering. Are #1, #2 and/or #3 allowable under the FreeTDS > license terms, assuming that a) all required notices are provided, > b) no source or object code is made available to the client, other > than that of FreeTDS, and c) FreeTDS is incorporated into the end > solution either by one of our executables making a system call to > execute a FreeTDS executable (such as freebcp), or by calling a > function that is available via dynamically linking to the FreeTDS > library. > > 1. Provide client with a physical box that provides services over the > network. Client has no access to files of any sort inside the box. > The box ships with various object code including the FreeTDS > executable(s) and/or dynamically-linked libraries that are used by > some of our commercial, closed-source executables. > > 2. Provide client with means to install software on its own computers. > This is the same as #1 except that now, the client owns the physical > box that holds the files, and has access to those files (including > FreeTDS executables and/or DLLs that are bundled with installation). > > 3. Same as #2 except that we do not ship with any FreeTDS > executables or libraries. Instead, client must install FreeTDS > components on their own. > > 4. Same as #3 except that instead of client installing FreeTDS, > client installs the Microsoft SQL Server tools. > > Thanks in advance for your help > I don't see many problems. Unless you static link FreeTDS (which is possible but in this case you need customer to change the lgpl code of your executable... that is provide a blob for the rest of code and source for freetds) I don't see the problem. You can use the tsql output as you like, just you need to provide sources if client request them. I think a link at the version you used if you don't change sources. You didn't specify which OS and platform is using your system. Frediano From acraigwest at gmail.com Sun Aug 2 20:01:57 2015 From: acraigwest at gmail.com (A. Craig West) Date: Sun, 2 Aug 2015 20:01:57 -0400 Subject: [freetds] Building as a DLL on Windows In-Reply-To: References: Message-ID: Well, I finally got the time to look at CMake. Seems like a pretty excellent tool, really. We could probably use better documentation for it in the context of freetds, though.I finally figured out where it build the DLL's and what they are named, so I think it is all good... On Tue, Jun 30, 2015 at 4:40 AM, Frediano Ziglio wrote: > Are you sure is not something related to dependency? > > The problem of nmakefile is that is lack lot of stuff. Is not able to > detect additional libraries (openssl, iconv, gnutls and so on). It > does not take version from same sources (configure) so it has to be > manually changed every time. It does not compile all full package > (tests). It does not generate files like versions scripts (for > instance resource versioning for dlls). It does not generate files > from git sources. To add all these feature is quite hard and is mainly > a duplication effort. Actually even cmake+autoconf is a bit a > duplication but first serve very much fine Windows while second is > better for *nixes. > > Frediano > > > 2015-06-29 19:01 GMT+01:00 A. Craig West : > > I tend to agree, it is pretty much guaranteed to be a compiler bug, but > > fixing compilers is outside the scope of my current project :-) > > I find that the first time I build after a clean, it fails, and if I > build > > again it succeeds. I'm not sure if this is actually an error, as it is > > possible there is a broken object file produced from the failed build > that > > satisfies the time stamps... > > I will have to look into the cmake option, my nmakefile is working quite > > well, though. > > > > On Mon, Jun 29, 2015 at 2:30 AM, Frediano Ziglio > wrote: > > > >> 2015-06-29 0:42 GMT+01:00 A. Craig West : > >> > I discovered that I require freetds to be buildable as a DLL file > under > >> > Windows, so I have modified the Nmakefile to add some new build > targets > >> and > >> > directories. After I have tested it a bit, I will port my changes up > to > >> > head. > >> > >> We are removing nmake support moving to cmake. > >> > >> > I am also getting a fault in the compiler on one of the files, but > have > >> not > >> > investigated the cause yet. It is possible that the issue is already > >> > resolved in head. I am currently building with Visual Studio 2008 > command > >> > line. > >> > >> We released quite recently possibly problem is still there. Or could > >> be you called a function with wrong arguments. Technically "a fault in > >> the compiler" looks like a compiler bug to me. > >> > >> > Jas anybody else dealt with similar issues lately? It seems to have > been > >> a > >> > while since anybody tried to build DLL's, although it turned out to be > >> > pretty easy to implement... > >> > -Craig > >> > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > From no-reply at appveyor.com Mon Aug 3 07:53:50 2015 From: no-reply at appveyor.com (AppVeyor) Date: Mon, 03 Aug 2015 11:53:50 +0000 Subject: [freetds] Build failed: freetds 99 Message-ID: <20150803115350.29406.1624@appveyor.com> From mewalig at gmail.com Mon Aug 3 12:00:16 2015 From: mewalig at gmail.com (mew_alig) Date: Mon, 3 Aug 2015 16:00:16 +0000 (UTC) Subject: [freetds] License Question References: <55F7E71F-755C-400C-8000-EE564E92D6AA@metaskills.net> <20110527221652.4385A56540@rebar.astron.com> <20110528151318.318ef7c1.jklowden@freetds.org> Message-ID: Frediano Ziglio gmail.com> writes: > > I know this thread is a few years old so please forgive me > > if I'm beating a dead horse. I suppose these questions are > > more about LGPL in general, but would appreciate any thoughts > > given that the specific LGPL-covered software that we are > > concerned about is FreeTDS. > > > > I am involved in a closed-source commercial project which > > includes some functionality to connect to and interact with a > > SQL server database. Below are the distribution choices we are > > considering. Are #1, #2 and/or #3 allowable under the FreeTDS > > license terms, assuming that a) all required notices are provided, > > b) no source or object code is made available to the client, other > > than that of FreeTDS, and c) FreeTDS is incorporated into the end > > solution either by one of our executables making a system call to > > execute a FreeTDS executable (such as freebcp), or by calling a > > function that is available via dynamically linking to the FreeTDS > > library. > > > > 1. Provide client with a physical box that provides services over the > > network. Client has no access to files of any sort inside the box. > > The box ships with various object code including the FreeTDS > > executable(s) and/or dynamically-linked libraries that are used by > > some of our commercial, closed-source executables. > > > > 2. Provide client with means to install software on its own computers. > > This is the same as #1 except that now, the client owns the physical > > box that holds the files, and has access to those files (including > > FreeTDS executables and/or DLLs that are bundled with installation). > > > > 3. Same as #2 except that we do not ship with any FreeTDS > > executables or libraries. Instead, client must install FreeTDS > > components on their own. > > > > 4. Same as #3 except that instead of client installing FreeTDS, > > client installs the Microsoft SQL Server tools. > > > > Thanks in advance for your help > > > > I don't see many problems. Unless you static link FreeTDS (which is > possible but in this case you need customer to change the lgpl code of your > executable... that is provide a blob for the rest of code and source for > freetds) I don't see the problem. You can use the tsql output as you like, > just you need to provide sources if client request them. I think a link at > the version you used if you don't change sources. > > You didn't specify which OS and platform is using your system. > > Frediano > Thank you. The OS's for options 1, 2, 3, and 4 would be, respectively: 1. OSX (10.10+) or Linux (not sure which, but a stable release from 2013 or later) 2, 3, and 4: Windows 7. So just to be crystal clear, am I right in saying that it is your understanding (with the caveat that you're not giving me legal advice and I need to get my own lawyer to do that) that if I never static link (and always dynamic link), and I include the proper notice provisions related to FreeTDS's license, then under options 1 or 2 (as well as 3), I am not obligated to disclose any of my company's proprietary source code or object code (other than executable binaries)? Again-- sorry to beat this one so much but staying within the bounds of the licensing while keeping our code closed-source is extremely important to us and is the only way we would be able to use (and in doing so, potentially contribute to) FreeTDS. From freddy77 at gmail.com Mon Aug 3 20:08:51 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Tue, 4 Aug 2015 01:08:51 +0100 Subject: [freetds] Win32 Make In-Reply-To: <55BBB0A6.1000906@spider-software.net> References: <55B8FC8D.9070000@spider-software.net> <55B9FF3E.9050204@spider-software.net> <55BA04A9.6040404@spider-software.net> <55BA341F.2000204@spider-software.net> <55BB54F0.1020808@spider-software.net> <55BBB0A6.1000906@spider-software.net> Message-ID: 2015-07-31 18:30 GMT+01:00 Michael Becker : >> For the printf problem I ended up with this patch >> >> https://github.com/FreeTDS/freetds/commit/9503e9accecd47f6c7e71a57b846c3f234313993. >> Looks fine and works in both Windows and Linux. >> I started having a problem with linking however. >> >> https://ci.appveyor.com/project/FreeTDS/freetds/build/91/job/3wp9db8c3uqvgq0n. >> Looks like library that visual studio try to use are not compiled with >> same options :( Could be SDKs used is the wrong one ? >> > for that reason I tried to include legacy_stdio_definitions.lib > if I change the makefile by hand it works fine with the lib, but I didn't > manage to adjust the CMakeLists.txt in the right way ... > I did some updates. printf family function are correctly detected. Also if needed the legacy_stdio_definitions is included. Still the 64 bit version on AppVeyor does not work. Don't know why. Hope Ramiros can shed some light. Frediano From corentin.leal at geolink.com Wed Aug 5 12:35:10 2015 From: corentin.leal at geolink.com (Corentin Leal) Date: Wed, 5 Aug 2015 18:35:10 +0200 Subject: [freetds] Connection problem using pymssql Message-ID: Hello, I have an issue regarding the connection to a Sybase SQL Anywhere database using a Python library using FreeTDS called pymssql. I can connect to the database using tsql but not with the library when I use FreeTDS v0.95. When I use the release 0.91 it works perfectly. What is the problem ? Should I consider it is a compatibility problem between pymssql and FreeTDS v0.95 ? Thanks for your answers. From no-reply at appveyor.com Fri Aug 7 00:47:32 2015 From: no-reply at appveyor.com (AppVeyor) Date: Fri, 07 Aug 2015 04:47:32 +0000 Subject: [freetds] Build completed: freetds 109 Message-ID: <20150807044732.5539.88044@appveyor.com> From eda at waniasset.com Wed Aug 5 10:09:50 2015 From: eda at waniasset.com (Ed Avis) Date: Wed, 5 Aug 2015 14:09:50 +0000 (UTC) Subject: [freetds] freebcp -c and newlines Message-ID: freebcp -c writes rows in a simple text format with a newline character at the end of each row. But if one of the columns itself contains a literal newline the output will be corrupt. It would be better for freebcp -c to check for newlines when writing data, and exit with an error status if it finds one. Probably it should also check for the separator character. If you want to write arbitrary data to a file you should use the binary bcp output format. If you agree that this would be a useful safety check to prevent corrupt output, I could submit a patch. -- Ed Avis From matthew.green at datamartcomputing.com Fri Aug 7 04:05:35 2015 From: matthew.green at datamartcomputing.com (matthew.green at datamartcomputing.com) Date: Fri, 07 Aug 2015 08:05:35 +0000 Subject: [freetds] freebcp -c and newlines In-Reply-To: References: Message-ID: <8611b2df62921d9e34db8fe765d342c2@datamartcomputing.com> The vendor tools behave in the same way as freebcp, so in some respects it would be better to keep it "as is". Most people simply use the column separator and row separator options to get round this and if you get it wrong it usually fails part way through the "bcp in" with an error anyway. I usually use grep to check the file for separators I'm considering using. However, improving on what the vendors do without breaking compatibility seems like a good idea. So if the bcp out checks to make sure the data doesn't contain the separators and it doesn't slow it down then I'm all for it. Hope you'll excuse my "thinking out loud" style of reply! Matthew. August 7 2015 9:15 AM, "Ed Avis" wrote: > freebcp -c writes rows in a simple text format with a newline character at > the end of each row. But if one of the columns itself contains a literal > newline the output will be corrupt. It would be better for freebcp -c to > check for newlines when writing data, and exit with an error status if it > finds one. Probably it should also check for the separator character. If > you want to write arbitrary data to a file you should use the binary bcp > output format. > > If you agree that this would be a useful safety check to prevent corrupt > output, I could submit a patch. > > -- > Ed Avis > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From freddy77 at gmail.com Fri Aug 7 10:19:31 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Fri, 7 Aug 2015 15:19:31 +0100 Subject: [freetds] License Question In-Reply-To: References: <55F7E71F-755C-400C-8000-EE564E92D6AA@metaskills.net> <20110527221652.4385A56540@rebar.astron.com> <20110528151318.318ef7c1.jklowden@freetds.org> Message-ID: 2015-08-03 17:00 GMT+01:00 mew_alig : > Frediano Ziglio gmail.com> writes: > >> > I know this thread is a few years old so please forgive me >> > if I'm beating a dead horse. I suppose these questions are >> > more about LGPL in general, but would appreciate any thoughts >> > given that the specific LGPL-covered software that we are >> > concerned about is FreeTDS. >> > >> > I am involved in a closed-source commercial project which >> > includes some functionality to connect to and interact with a >> > SQL server database. Below are the distribution choices we are >> > considering. Are #1, #2 and/or #3 allowable under the FreeTDS >> > license terms, assuming that a) all required notices are provided, >> > b) no source or object code is made available to the client, other >> > than that of FreeTDS, and c) FreeTDS is incorporated into the end >> > solution either by one of our executables making a system call to >> > execute a FreeTDS executable (such as freebcp), or by calling a >> > function that is available via dynamically linking to the FreeTDS >> > library. >> > >> > 1. Provide client with a physical box that provides services over the >> > network. Client has no access to files of any sort inside the box. >> > The box ships with various object code including the FreeTDS >> > executable(s) and/or dynamically-linked libraries that are used by >> > some of our commercial, closed-source executables. >> > >> > 2. Provide client with means to install software on its own computers. >> > This is the same as #1 except that now, the client owns the physical >> > box that holds the files, and has access to those files (including >> > FreeTDS executables and/or DLLs that are bundled with installation). >> > >> > 3. Same as #2 except that we do not ship with any FreeTDS >> > executables or libraries. Instead, client must install FreeTDS >> > components on their own. >> > >> > 4. Same as #3 except that instead of client installing FreeTDS, >> > client installs the Microsoft SQL Server tools. >> > >> > Thanks in advance for your help >> > >> >> I don't see many problems. Unless you static link FreeTDS (which is >> possible but in this case you need customer to change the lgpl code of your >> executable... that is provide a blob for the rest of code and source for >> freetds) I don't see the problem. You can use the tsql output as you like, >> just you need to provide sources if client request them. I think a link at >> the version you used if you don't change sources. >> >> You didn't specify which OS and platform is using your system. >> >> Frediano >> > > Thank you. The OS's for options 1, 2, 3, and 4 would be, respectively: > 1. OSX (10.10+) or Linux (not sure which, but a stable release from 2013 > or later) > 2, 3, and 4: Windows 7. > > So just to be crystal clear, am I right in saying that it is your understanding > (with the caveat that you're not giving me legal advice and I need to get my > own lawyer to do that) that if I never static link (and always dynamic link), > and I include the proper notice provisions related to FreeTDS's license, then > under options 1 or 2 (as well as 3), I am not obligated to disclose any of my > company's proprietary source code or object code (other than executable > binaries)? > Yes, these are the common rules. Is not really LGPL == dynamic linking actually you could use even static one but this require some technical way as LGPL require customer to be able to change the LGPL part. Putting into a dynamic library make much easier to do it. If you just use code as is you can safely say to customer "Go on their website and use version X". Is always better to ask to lawyer. A license (closed or open) is a contract between you and who provided it but is bound to laws which depends on country and other factors. > Again-- sorry to beat this one so much but staying within the bounds of the > licensing while keeping our code closed-source is extremely important to us > and is the only way we would be able to use (and in doing so, potentially > contribute to) FreeTDS. > Well.. this is why we (well, I should actually say they) decided to use LGPL. We all want to have big interoperability with both closed and open world! Helps others and us. Regards, Frediano From freddy77 at gmail.com Fri Aug 7 10:23:43 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Fri, 7 Aug 2015 15:23:43 +0100 Subject: [freetds] Win32 Make In-Reply-To: References: <55B8FC8D.9070000@spider-software.net> <55B9FF3E.9050204@spider-software.net> <55BA04A9.6040404@spider-software.net> <55BA341F.2000204@spider-software.net> Message-ID: Hi Ramiros, I finally found the cause while was not compiling properly with Visual Studio 2015 for 64 bit. Basically you had to use amd64 instead of x86_amd64 (as documented). Don't know why but the artifacts are 64 bit and working. I committed your original patch with this small change (https://github.com/FreeTDS/freetds/commit/a8d7d01aaa9e22a30bdbc077319ea30e8acbb73e). As you can see master is building correctly (https://ci.appveyor.com/project/FreeTDS/freetds/build/111). Moved the Trello todo item to done! Thank you, Frediano 2015-07-31 11:41 GMT+01:00 Ramiro Morales : > On Thu, Jul 30, 2015 at 3:23 PM, Frediano Ziglio wrote: >> 2015-07-30 15:26 GMT+01:00 Michael Becker : >>> these functions must be checked using check_symbol_exists >>> >>> I have changed CMakeLists.txt as follows: >>> [...] >>> >> >> Change a bit to do both the tests, it continues to build on old Visual >> Studio versions. >> > > I see Frediano commited a variation of the proposed patch, but it > seems it still doesn't detect them (at least on AppVeyor): > > https://ci.appveyor.com/project/FreeTDS/freetds/build/89#L304 > > Michael: Do you get same failure in your local VS2015 environment? > > Had been playing with CheckSymbolExists and another strategy but can't > get it to work either: > > https://github.com/ramiro/freetds/commit/7c089c360d52114f12c54b3e4923468f4fd0ae86 > https://ci.appveyor.com/project/ramiro/freetds/build/260 > > Regards, > > -- > Ramiro Morales > @ramiromorales > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From mewalig at gmail.com Mon Aug 10 13:57:34 2015 From: mewalig at gmail.com (mew_alig) Date: Mon, 10 Aug 2015 17:57:34 +0000 (UTC) Subject: [freetds] License Question References: <55F7E71F-755C-400C-8000-EE564E92D6AA@metaskills.net> <20110527221652.4385A56540@rebar.astron.com> <20110528151318.318ef7c1.jklowden@freetds.org> Message-ID: Thank you! much appreciate your answers and your patience. From craigberry at mac.com Thu Aug 27 19:54:07 2015 From: craigberry at mac.com (Craig A. Berry) Date: Thu, 27 Aug 2015 18:54:07 -0500 Subject: [freetds] build broken on OS X Message-ID: <8246BD3E-699B-4A70-875D-E09159666C85@mac.com> This is what I see with master as of 6ac57ef9e7eed5fcbcfa80. I don?t see anything obvious or recent that caused it, though 9b57e2ad99f7cc32 ("Allow to include replacements/readpassphrase.h directly?) from back in May is surely part of the picture. fisql.c itself has not changed in a year. Making all in apps Making all in fisql CC fisql.o fisql.c:414:3: warning: implicit declaration of function 'readpassphrase' is invalid in C99 [-Wimplicit-function-declaration] readpassphrase("Password: ", password, READPASSPHRASE_MAXLEN, RPP_ECHO_OFF); ^ fisql.c:414:65: error: use of undeclared identifier 'RPP_ECHO_OFF' readpassphrase("Password: ", password, READPASSPHRASE_MAXLEN, RPP_ECHO_OFF); ^ 1 warning and 1 error generated. make[3]: *** [fisql.o] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all-recursive] Error 1 I am getting this defined: $ grep READPASS include/config.h #define HAVE_READPASSPHRASE 1 ________________________________________ Craig A. Berry mailto:craigberry at mac.com "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser From craigberry at mac.com Fri Aug 28 09:12:52 2015 From: craigberry at mac.com (Craig A. Berry) Date: Fri, 28 Aug 2015 08:12:52 -0500 Subject: [freetds] [PATCH] Drop prefixes from replacements in VMS config.h. Message-ID: <35FC67C3-A4FF-497E-BEF6-3BECAE69965A@mac.com> [Inline and attached] These conflict with the inline prefixes now in use. We keep our own prefixes for routines defined in vms/ rather than in src/replacements. --- vms/config_h.vms | 26 +++++--------------------- 1 file changed, 5 insertions(+), 21 deletions(-) diff --git a/vms/config_h.vms b/vms/config_h.vms index 1f731d2..8da6c11 100644 --- a/vms/config_h.vms +++ b/vms/config_h.vms @@ -337,27 +337,6 @@ #pragma extern_prefix "freetds_" (getpass) char *getpass( const char* prompt ); -#if !HAVE_ASPRINTF -#pragma extern_prefix "freetds_" (asprintf) -#endif /* !HAVE_ASPRINTF */ - -#if !HAVE_VASPRINTF -#pragma extern_prefix "freetds_" (vasprintf) -#endif /* !HAVE_VASPRINTF */ - -#if !HAVE_SNPRINTF -#pragma extern_prefix "portable_" (snprintf) -extern int snprintf(char *, size_t, const char *, /*args*/ ...); -#endif /* !HAVE_SNPRINTF */ - -#if !HAVE_STRTOK_R -#pragma extern_prefix "freetds_" (strtok_r) -#endif /* !HAVE_STRTOK_R */ - -#pragma extern_prefix restore - -#define tds_sysdep_intptr_type int /* 32-bit int */ - #pragma extern_prefix "freetds_" (readpassphrase) char * readpassphrase(const char *, char *, size_t, int); #ifdef HAVE_READPASSPHRASE @@ -365,6 +344,11 @@ char * readpassphrase(const char *, char *, size_t, int); # undef HAVE_READPASSPHRASE #endif +#pragma extern_prefix restore + +#define tds_sysdep_intptr_type int /* 32-bit int */ + + #include "replacements.h" /* If the CRTL ever complies with UNIX98 and defines socklen_t in ? 2.2.1 ________________________________________ Craig A. Berry mailto:craigberry at mac.com "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Drop-prefixes-from-replacements-in-VMS-config.h.patch Type: application/octet-stream Size: 1694 bytes Desc: not available URL: From craigberry at mac.com Fri Aug 28 09:14:37 2015 From: craigberry at mac.com (Craig A. Berry) Date: Fri, 28 Aug 2015 08:14:37 -0500 Subject: [freetds] [PATCH] VMS does have getopt. Message-ID: <4AE66D32-F603-4FBC-9AA0-17EE356D522F@mac.com> --- vms/config_h.vms | 3 +++ 1 file changed, 3 insertions(+) diff --git a/vms/config_h.vms b/vms/config_h.vms index 8da6c11..662e918 100644 --- a/vms/config_h.vms +++ b/vms/config_h.vms @@ -108,6 +108,9 @@ /* Define to 1 if you have the `gettimeofday' function. */ #define HAVE_GETTIMEOFDAY 1 +/* Define to 1 if you have the `getopt' function. */ +#define HAVE_GETOPT 1 + /* Define to 1 if you have the `getuid' function. */ #define HAVE_GETUID 1 ? 2.2.1 ________________________________________ Craig A. Berry mailto:craigberry at mac.com "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-VMS-does-have-getopt.patch Type: application/octet-stream Size: 666 bytes Desc: not available URL: From craigberry at mac.com Fri Aug 28 09:16:50 2015 From: craigberry at mac.com (Craig A. Berry) Date: Fri, 28 Aug 2015 08:16:50 -0500 Subject: [freetds] [PATCH] Don't disable system's readpassphrase.h. Message-ID: <08835F1B-F884-4006-9D18-106166E5218C@mac.com> We were defining _READPASSPHRASE_H_ in our replacement version, and then, when HAVE_READPASSPHRASE was defined, including the system version of readpassphrase.h. At least on BSD-like systems, the contents of that file are skipped when _READPASSPHRASE_H_ is already defined. So use our own macro to guard our own header rather stealing the guard macro that is also used by the system. --- include/replacements/readpassphrase.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/replacements/readpassphrase.h b/include/replacements/readpassphrase.h index db6312f..bba3190 100644 --- a/include/replacements/readpassphrase.h +++ b/include/replacements/readpassphrase.h @@ -29,8 +29,8 @@ * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ -#ifndef _READPASSPHRASE_H_ -#define _READPASSPHRASE_H_ +#ifndef _FREETDS_READPASSPHRASE_H_ +#define _FREETDS_READPASSPHRASE_H_ #ifdef HAVE_READPASSPHRASE ? 2.2.1 ________________________________________ Craig A. Berry mailto:craigberry at mac.com "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Don-t-disable-system-s-readpassphrase.h.patch Type: application/octet-stream Size: 1155 bytes Desc: not available URL: From freddy77 at gmail.com Fri Aug 28 11:45:32 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Fri, 28 Aug 2015 16:45:32 +0100 Subject: [freetds] build broken on OS X In-Reply-To: <8246BD3E-699B-4A70-875D-E09159666C85@mac.com> References: <8246BD3E-699B-4A70-875D-E09159666C85@mac.com> Message-ID: 2015-08-28 0:54 GMT+01:00 Craig A. Berry : > This is what I see with master as of 6ac57ef9e7eed5fcbcfa80. I don?t see anything obvious or recent that caused it, though 9b57e2ad99f7cc32 ("Allow to include replacements/readpassphrase.h directly?) from back in May is surely part of the picture. fisql.c itself has not changed in a year. > > Making all in apps > Making all in fisql > CC fisql.o > fisql.c:414:3: warning: implicit declaration of function 'readpassphrase' is invalid in C99 [-Wimplicit-function-declaration] > readpassphrase("Password: ", password, READPASSPHRASE_MAXLEN, RPP_ECHO_OFF); > ^ > fisql.c:414:65: error: use of undeclared identifier 'RPP_ECHO_OFF' > readpassphrase("Password: ", password, READPASSPHRASE_MAXLEN, RPP_ECHO_OFF); > ^ > 1 warning and 1 error generated. > make[3]: *** [fisql.o] Error 1 > make[2]: *** [all-recursive] Error 1 > make[1]: *** [all-recursive] Error 1 > make: *** [all-recursive] Error 1 > > I am getting this defined: > > $ grep READPASS include/config.h > #define HAVE_READPASSPHRASE 1 > > ________________________________________ > Craig A. Berry > mailto:craigberry at mac.com > > "... getting out of a sonnet is much more > difficult than getting in." > Brad Leithauser > I didn't test it but I think last commit will help Mac OS X :) https://github.com/FreeTDS/freetds/commit/be1ec52d1cfe14a80a886d1e2edccf40eeff69d8 (happily I have a Mac to test the header source). Frediano From craigberry at mac.com Fri Aug 28 12:17:58 2015 From: craigberry at mac.com (Craig A. Berry) Date: Fri, 28 Aug 2015 11:17:58 -0500 Subject: [freetds] build broken on OS X In-Reply-To: References: <8246BD3E-699B-4A70-875D-E09159666C85@mac.com> Message-ID: <2BEAF168-02B7-4FBC-8164-165B2036933B@mac.com> > On Aug 28, 2015, at 10:45 AM, Frediano Ziglio wrote: > > I didn't test it but I think last commit will help Mac OS X :) > > https://github.com/FreeTDS/freetds/commit/be1ec52d1cfe14a80a886d1e2edccf40eeff69d8 > > (happily I have a Mac to test the header source). Yep, that does the trick. You can ignore the patch I sent that does the same thing. ________________________________________ Craig A. Berry mailto:craigberry at mac.com "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser From freddy77 at gmail.com Sat Aug 29 08:24:40 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Sat, 29 Aug 2015 13:24:40 +0100 Subject: [freetds] [PATCH] Don't disable system's readpassphrase.h. In-Reply-To: <08835F1B-F884-4006-9D18-106166E5218C@mac.com> References: <08835F1B-F884-4006-9D18-106166E5218C@mac.com> Message-ID: Il 29/Ago/2015 02:42, "Craig A. Berry" ha scritto: > > We were defining _READPASSPHRASE_H_ in our replacement version, > and then, when HAVE_READPASSPHRASE was defined, including the > system version of readpassphrase.h. At least on BSD-like systems, > the contents of that file are skipped when _READPASSPHRASE_H_ is > already defined. So use our own macro to guard our own header > rather stealing the guard macro that is also used by the system. > --- > include/replacements/readpassphrase.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/include/replacements/readpassphrase.h b/include/replacements/readpassphrase.h > index db6312f..bba3190 100644 > --- a/include/replacements/readpassphrase.h > +++ b/include/replacements/readpassphrase.h > @@ -29,8 +29,8 @@ > * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. > */ > > -#ifndef _READPASSPHRASE_H_ > -#define _READPASSPHRASE_H_ > +#ifndef _FREETDS_READPASSPHRASE_H_ > +#define _FREETDS_READPASSPHRASE_H_ > > #ifdef HAVE_READPASSPHRASE > > ? > 2.2.1 Looks like this patch is very similar to mine Frediano From ikorot01 at gmail.com Fri Aug 28 13:09:08 2015 From: ikorot01 at gmail.com (Igor Korot) Date: Fri, 28 Aug 2015 13:09:08 -0400 Subject: [freetds] build broken on OS X In-Reply-To: <8246BD3E-699B-4A70-875D-E09159666C85@mac.com> References: <8246BD3E-699B-4A70-875D-E09159666C85@mac.com> Message-ID: Hi, Craig, On Thu, Aug 27, 2015 at 7:54 PM, Craig A. Berry wrote: > This is what I see with master as of 6ac57ef9e7eed5fcbcfa80. I don?t see anything obvious or recent that caused it, though 9b57e2ad99f7cc32 ("Allow to include replacements/readpassphrase.h directly?) from back in May is surely part of the picture. fisql.c itself has not changed in a year. Whats your OS/compiler version? Thank you. > > Making all in apps > Making all in fisql > CC fisql.o > fisql.c:414:3: warning: implicit declaration of function 'readpassphrase' is invalid in C99 [-Wimplicit-function-declaration] > readpassphrase("Password: ", password, READPASSPHRASE_MAXLEN, RPP_ECHO_OFF); > ^ > fisql.c:414:65: error: use of undeclared identifier 'RPP_ECHO_OFF' > readpassphrase("Password: ", password, READPASSPHRASE_MAXLEN, RPP_ECHO_OFF); > ^ > 1 warning and 1 error generated. > make[3]: *** [fisql.o] Error 1 > make[2]: *** [all-recursive] Error 1 > make[1]: *** [all-recursive] Error 1 > make: *** [all-recursive] Error 1 > > I am getting this defined: > > $ grep READPASS include/config.h > #define HAVE_READPASSPHRASE 1 > > ________________________________________ > Craig A. Berry > mailto:craigberry at mac.com > > "... getting out of a sonnet is much more > difficult than getting in." > Brad Leithauser > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From craigberry at mac.com Sat Aug 29 08:50:46 2015 From: craigberry at mac.com (Craig A. Berry) Date: Sat, 29 Aug 2015 07:50:46 -0500 Subject: [freetds] build broken on OS X In-Reply-To: References: <8246BD3E-699B-4A70-875D-E09159666C85@mac.com> Message-ID: > On Aug 28, 2015, at 12:09 PM, Igor Korot wrote: > > Hi, Craig, > > On Thu, Aug 27, 2015 at 7:54 PM, Craig A. Berry wrote: >> This is what I see with master as of 6ac57ef9e7eed5fcbcfa80. I don?t see anything obvious or recent that caused it, though 9b57e2ad99f7cc32 ("Allow to include replacements/readpassphrase.h directly?) from back in May is surely part of the picture. fisql.c itself has not changed in a year. > > Whats your OS/compiler version? $ sw_vers ProductName: Mac OS X ProductVersion: 10.10.5 BuildVersion: 14F27 $ gcc --version Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn) Target: x86_64-apple-darwin14.5.0 Thread model: posix but it doesn?t matter as Freddy already fixed the problem: https://github.com/FreeTDS/freetds/commit/be1ec52d1cfe14a80a886d1e2edccf40eeff69d8 ________________________________________ Craig A. Berry mailto:craigberry at mac.com "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser From freddy77 at gmail.com Sat Aug 29 15:27:45 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Sat, 29 Aug 2015 20:27:45 +0100 Subject: [freetds] [PATCH] Drop prefixes from replacements in VMS config.h. In-Reply-To: <35FC67C3-A4FF-497E-BEF6-3BECAE69965A@mac.com> References: <35FC67C3-A4FF-497E-BEF6-3BECAE69965A@mac.com> Message-ID: 2015-08-28 14:12 GMT+01:00 Craig A. Berry : > [Inline and attached] > > These conflict with the inline prefixes now in use. We keep > our own prefixes for routines defined in vms/ rather than in > src/replacements. > --- > vms/config_h.vms | 26 +++++--------------------- > 1 file changed, 5 insertions(+), 21 deletions(-) > > diff --git a/vms/config_h.vms b/vms/config_h.vms > index 1f731d2..8da6c11 100644 > --- a/vms/config_h.vms > +++ b/vms/config_h.vms > @@ -337,27 +337,6 @@ > #pragma extern_prefix "freetds_" (getpass) > char *getpass( const char* prompt ); > > -#if !HAVE_ASPRINTF > -#pragma extern_prefix "freetds_" (asprintf) > -#endif /* !HAVE_ASPRINTF */ > - > -#if !HAVE_VASPRINTF > -#pragma extern_prefix "freetds_" (vasprintf) > -#endif /* !HAVE_VASPRINTF */ > - > -#if !HAVE_SNPRINTF > -#pragma extern_prefix "portable_" (snprintf) > -extern int snprintf(char *, size_t, const char *, /*args*/ ...); > -#endif /* !HAVE_SNPRINTF */ > - > -#if !HAVE_STRTOK_R > -#pragma extern_prefix "freetds_" (strtok_r) > -#endif /* !HAVE_STRTOK_R */ > - > -#pragma extern_prefix restore > - > -#define tds_sysdep_intptr_type int /* 32-bit int */ > - > #pragma extern_prefix "freetds_" (readpassphrase) > char * readpassphrase(const char *, char *, size_t, int); > #ifdef HAVE_READPASSPHRASE > @@ -365,6 +344,11 @@ char * readpassphrase(const char *, char *, size_t, int); > # undef HAVE_READPASSPHRASE > #endif > > +#pragma extern_prefix restore > + > +#define tds_sysdep_intptr_type int /* 32-bit int */ > + > + > #include "replacements.h" > > /* If the CRTL ever complies with UNIX98 and defines socklen_t in > ? > 2.2.1 > Pushed! Not that I have way to verify anyway... and all your patches was good! Frediano From no-reply at appveyor.com Sun Aug 30 05:01:17 2015 From: no-reply at appveyor.com (AppVeyor) Date: Sun, 30 Aug 2015 09:01:17 +0000 Subject: [freetds] Build failed: freetds 131 Message-ID: <20150830090117.27011.73568@appveyor.com> From no-reply at appveyor.com Sun Aug 30 13:02:34 2015 From: no-reply at appveyor.com (AppVeyor) Date: Sun, 30 Aug 2015 17:02:34 +0000 Subject: [freetds] Build completed: freetds 133 Message-ID: <20150830170233.82686.76403@appveyor.com> From morinr at us.ibm.com Mon Aug 31 10:15:10 2015 From: morinr at us.ibm.com (Rob Morin) Date: Mon, 31 Aug 2015 10:15:10 -0400 Subject: [freetds] Problem with a query against MS SQL 2005 Message-ID: All, First, please let me apologize if this already went to the group. I think I tried to send it before I was officially a member, so I don't know if it actually went or not. I'm upgrading a server from PHP 4.3 to PHP 5.6 and doing the necessary code remediation. I've got most things working, but I'm having a problem on certain queries and I'm to the point that I believe it is the driver (PHP 4.3 used a mssql driver, PHP 5.6 uses FreeTDS) that's causing the problem. The Environment CentOS 7.1 with PHP 5.6.8 and php56w-mssql from webtatic This comes with FreeTDS 0.91 from epel I've set the FreeTDS global protocol version to 7.2 in freetds.conf. When it starts, I see an error in the log : "TDS version downgraded to 7.1!" The wait time is also set to 180. The log of the downgrade: util.c:331:tdserror(0x7fd16ec064c0, 0x7fd16ec9edd0, 100, 0) dblib.c:7929:dbperror(0x7fd16ec9e360, 100, 0) dblib.c:7981:100: "TDS version downgraded to 7.1!" dblib.c:8002:"TDS version downgraded to 7.1!", client returns 2 (INT_CANCEL) util.c:361:tdserror: client library returned TDS_INT_CANCEL(2) util.c:384:tdserror: returning TDS_INT_CANCEL(2) iconv.c:330:tds_iconv_open(0x7fd16ec9edd0, UTF-8) iconv.c:187:local name for ISO-8859-1 is ISO-8859-1 iconv.c:187:local name for UTF-8 is UTF-8 iconv.c:187:local name for UCS-2LE is UCS-2LE iconv.c:187:local name for UCS-2BE is UCS-2BE iconv.c:349:setting up conversions for client charset "UTF-8" iconv.c:351:preparing iconv for "UTF-8" <-> "UCS-2LE" conversion iconv.c:391:preparing iconv for "ISO-8859-1" <-> "UCS-2LE" conversion iconv.c:394:tds_iconv_open: done net.c:205:Connecting to 10.100.5.201 port 1433 (TDS version 7.1) net.c:270:tds_open_socket: connect(2) returned "Operation now in progress" net.c:310:tds_open_socket() succeeded util.c:156:Changed query state from DEAD to IDLE I've established that the server is able to connect to the SQL server and run 'normal' queries. Apparently this one is 'special', but I'm not sure at what level. Here's the query: IF OBJECT_ID('tempdb..#EarlyRenewals') IS NULL SELECT * INTO #EarlyRenewals FROM [atl-sportal01].sportal.dbo.EarlyRenewalsBasedOnDates) It appears to be timing out while waiting on the SQL server (SQL 2005). It takes the server ~8-10 secs to respond to the query. The php script is 'failing' after waiting ~3 minutes. Here's the log after the query is sent: dblib.c:4639:dbsqlok(0x7fd16ecc1540) dblib.c:4669:dbsqlok() not done, calling tds_process_tokens() token.c:540:tds_process_tokens(0x7fd16ecc2890, 0x7fff3872e248, 0x7fff3872e24c, 0x6914) util.c:156:Changed query state from PENDING to READING util.c:331:tdserror(0x7fd16ec064c0, 0x7fd16ecc2890, 20003, 0) dblib.c:7929:dbperror(0x7fd16ecc1540, 20003, 0) dblib.c:7981:20003: "Adaptive Server connection timed out" dblib.c:8002:"Adaptive Server connection timed out", client returns 2 (INT_CANCEL) util.c:361:tdserror: client library returned TDS_INT_CANCEL(2) util.c:384:tdserror: returning TDS_INT_CANCEL(2) util.c:156:Changed query state from READING to DEAD token.c:555:processing result tokens. marker is 0() token.c:122:tds_process_default_tokens() marker is 0() token.c:125:leaving tds_process_default_tokens() connection dead util.c:104:logic error: cannot change query state from DEAD to PENDING dblib.c:3196:dbcancel(0x7fd16ecc1540) dblib.c:7929:dbperror(0x7fd16ecc1540, 20047, 0) dblib.c:7981:20047: "DBPROCESS is dead or not enabled" dblib.c:8002:"DBPROCESS is dead or not enabled", client returns 2 (INT_CANCEL) Any help or guidance you can provide is greatly appreciated. Please let me know if there's any additional information I can provide. Thank you, Rob Rob Morin Systems Integration Architect Silverpop, an IBM Company Office: 404.348.9124 Email: morinr at us.ibm.com 6303 Barfield Rd Atlanta, GA 30328 Twitter | Facebook | LinkedIn -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2103 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1299 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 990 bytes Desc: not available URL: From freddy77 at gmail.com Wed Sep 2 03:14:46 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Wed, 2 Sep 2015 08:14:46 +0100 Subject: [freetds] Problem with a query against MS SQL 2005 In-Reply-To: References: Message-ID: 2015-08-31 15:15 GMT+01:00 Rob Morin : > All, > > First, please let me apologize if this already went to the group. I think > I tried to send it before I was officially a member, so I don't know if it > actually went or not. > > I'm upgrading a server from PHP 4.3 to PHP 5.6 and doing the necessary > code remediation. I've got most things working, but I'm having a problem > on certain queries and I'm to the point that I believe it is the driver > (PHP 4.3 used a mssql driver, PHP 5.6 uses FreeTDS) that's causing the > problem. > > The Environment > CentOS 7.1 with PHP 5.6.8 and php56w-mssql from webtatic > This comes with FreeTDS 0.91 from epel > > I've set the FreeTDS global protocol version to 7.2 in freetds.conf. When > it starts, I see an error in the log : "TDS version downgraded to 7.1!" This is expected, newer version use 7.2 even for dblib. > The wait time is also set to 180. > Which make sense with the 3 minutes wait (180 seconds for cancel, 180 for error). > The log of the downgrade: > util.c:331:tdserror(0x7fd16ec064c0, 0x7fd16ec9edd0, 100, 0) > dblib.c:7929:dbperror(0x7fd16ec9e360, 100, 0) > dblib.c:7981:100: "TDS version downgraded to 7.1!" > dblib.c:8002:"TDS version downgraded to 7.1!", client returns 2 > (INT_CANCEL) > util.c:361:tdserror: client library returned TDS_INT_CANCEL(2) > util.c:384:tdserror: returning TDS_INT_CANCEL(2) > iconv.c:330:tds_iconv_open(0x7fd16ec9edd0, UTF-8) > iconv.c:187:local name for ISO-8859-1 is ISO-8859-1 > iconv.c:187:local name for UTF-8 is UTF-8 > iconv.c:187:local name for UCS-2LE is UCS-2LE > iconv.c:187:local name for UCS-2BE is UCS-2BE > iconv.c:349:setting up conversions for client charset "UTF-8" > iconv.c:351:preparing iconv for "UTF-8" <-> "UCS-2LE" conversion > iconv.c:391:preparing iconv for "ISO-8859-1" <-> "UCS-2LE" > conversion > iconv.c:394:tds_iconv_open: done > net.c:205:Connecting to 10.100.5.201 port 1433 (TDS version 7.1) > net.c:270:tds_open_socket: connect(2) returned "Operation now in > progress" > net.c:310:tds_open_socket() succeeded > util.c:156:Changed query state from DEAD to IDLE > > I've established that the server is able to connect to the SQL server and > run 'normal' queries. Apparently this one is 'special', but I'm not sure > at what level. > Can you enable timestamps on logs? > Here's the query: > IF OBJECT_ID('tempdb..#EarlyRenewals') IS NULL > SELECT * INTO #EarlyRenewals FROM > [atl-sportal01].sportal.dbo.EarlyRenewalsBasedOnDates) > > It appears to be timing out while waiting on the SQL server (SQL 2005). It > takes the server ~8-10 secs to respond to the query. The php script is > 'failing' after waiting ~3 minutes. > Weird... would like to understand the type of columns. Could be that for some reasons the query is much slower with different connection settings. > Here's the log after the query is sent: > dblib.c:4639:dbsqlok(0x7fd16ecc1540) > dblib.c:4669:dbsqlok() not done, calling tds_process_tokens() > token.c:540:tds_process_tokens(0x7fd16ecc2890, 0x7fff3872e248, > 0x7fff3872e24c, 0x6914) > util.c:156:Changed query state from PENDING to READING > util.c:331:tdserror(0x7fd16ec064c0, 0x7fd16ecc2890, 20003, 0) > dblib.c:7929:dbperror(0x7fd16ecc1540, 20003, 0) > dblib.c:7981:20003: "Adaptive Server connection timed out" > dblib.c:8002:"Adaptive Server connection timed out", client > returns 2 (INT_CANCEL) > util.c:361:tdserror: client library returned TDS_INT_CANCEL(2) > util.c:384:tdserror: returning TDS_INT_CANCEL(2) > util.c:156:Changed query state from READING to DEAD > token.c:555:processing result tokens. marker is 0() > token.c:122:tds_process_default_tokens() marker is 0() > token.c:125:leaving tds_process_default_tokens() connection dead > util.c:104:logic error: cannot change query state from DEAD to > PENDING > dblib.c:3196:dbcancel(0x7fd16ecc1540) > dblib.c:7929:dbperror(0x7fd16ecc1540, 20047, 0) > dblib.c:7981:20047: "DBPROCESS is dead or not enabled" > dblib.c:8002:"DBPROCESS is dead or not enabled", client returns 2 > (INT_CANCEL) > > Any help or guidance you can provide is greatly appreciated. Please let me > know if there's any additional information I can provide. > > Thank you, > Rob > > > > > Rob Morin > > > Systems Integration Architect > Silverpop, an IBM Company > Frediano From cramm0 at gmail.com Thu Sep 3 09:29:55 2015 From: cramm0 at gmail.com (Ramiro Morales) Date: Thu, 3 Sep 2015 10:29:55 -0300 Subject: [freetds] Microsoft want to help django-mssql, pymssql, FreeTDS, etc. Message-ID: Hi all, Just wanted point you all to an email message (and related thread) posted by an MS engineer to the mailing list of the Django Python Web development framework a few days ago. https://groups.google.com/d/topic/django-developers/FbBcUCzrSZo/discussion It seems there is a good chance of collaboration there for FreeTDS. And it's good to know Microsoft is recommending to al least some of its customers to use a stack which includes FreeTDS. Regards, -- Ramiro Morales @ramiromorales From freddy77 at gmail.com Fri Sep 4 00:12:16 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Fri, 4 Sep 2015 05:12:16 +0100 Subject: [freetds] Problem with a query against MS SQL 2005 In-Reply-To: References: Message-ID: Il 01/Set/2015 13:21, "Rob Morin" ha scritto: > > All, > > First, please let me apologize if this already went to the group. I think > I tried to send it before I was officially a member, so I don't know if it > actually went or not. > > I'm upgrading a server from PHP 4.3 to PHP 5.6 and doing the necessary > code remediation. I've got most things working, but I'm having a problem > on certain queries and I'm to the point that I believe it is the driver > (PHP 4.3 used a mssql driver, PHP 5.6 uses FreeTDS) that's causing the > problem. > > The Environment > CentOS 7.1 with PHP 5.6.8 and php56w-mssql from webtatic > This comes with FreeTDS 0.91 from epel > > I've set the FreeTDS global protocol version to 7.2 in freetds.conf. When > it starts, I see an error in the log : "TDS version downgraded to 7.1!" > The wait time is also set to 180. > > The log of the downgrade: > util.c:331:tdserror(0x7fd16ec064c0, 0x7fd16ec9edd0, 100, 0) > dblib.c:7929:dbperror(0x7fd16ec9e360, 100, 0) > dblib.c:7981:100: "TDS version downgraded to 7.1!" > dblib.c:8002:"TDS version downgraded to 7.1!", client returns 2 > (INT_CANCEL) > util.c:361:tdserror: client library returned TDS_INT_CANCEL(2) > util.c:384:tdserror: returning TDS_INT_CANCEL(2) > iconv.c:330:tds_iconv_open(0x7fd16ec9edd0, UTF-8) > iconv.c:187:local name for ISO-8859-1 is ISO-8859-1 > iconv.c:187:local name for UTF-8 is UTF-8 > iconv.c:187:local name for UCS-2LE is UCS-2LE > iconv.c:187:local name for UCS-2BE is UCS-2BE > iconv.c:349:setting up conversions for client charset "UTF-8" > iconv.c:351:preparing iconv for "UTF-8" <-> "UCS-2LE" conversion > iconv.c:391:preparing iconv for "ISO-8859-1" <-> "UCS-2LE" > conversion > iconv.c:394:tds_iconv_open: done > net.c:205:Connecting to 10.100.5.201 port 1433 (TDS version 7.1) > net.c:270:tds_open_socket: connect(2) returned "Operation now in > progress" > net.c:310:tds_open_socket() succeeded > util.c:156:Changed query state from DEAD to IDLE > > I've established that the server is able to connect to the SQL server and > run 'normal' queries. Apparently this one is 'special', but I'm not sure > at what level. > > Here's the query: > IF OBJECT_ID('tempdb..#EarlyRenewals') IS NULL > SELECT * INTO #EarlyRenewals FROM > [atl-sportal01].sportal.dbo.EarlyRenewalsBasedOnDates) > > It appears to be timing out while waiting on the SQL server (SQL 2005). It > takes the server ~8-10 secs to respond to the query. The php script is > 'failing' after waiting ~3 minutes. > > Here's the log after the query is sent: > dblib.c:4639:dbsqlok(0x7fd16ecc1540) > dblib.c:4669:dbsqlok() not done, calling tds_process_tokens() > token.c:540:tds_process_tokens(0x7fd16ecc2890, 0x7fff3872e248, > 0x7fff3872e24c, 0x6914) > util.c:156:Changed query state from PENDING to READING > util.c:331:tdserror(0x7fd16ec064c0, 0x7fd16ecc2890, 20003, 0) > dblib.c:7929:dbperror(0x7fd16ecc1540, 20003, 0) > dblib.c:7981:20003: "Adaptive Server connection timed out" > dblib.c:8002:"Adaptive Server connection timed out", client > returns 2 (INT_CANCEL) > util.c:361:tdserror: client library returned TDS_INT_CANCEL(2) > util.c:384:tdserror: returning TDS_INT_CANCEL(2) > util.c:156:Changed query state from READING to DEAD > token.c:555:processing result tokens. marker is 0() > token.c:122:tds_process_default_tokens() marker is 0() > token.c:125:leaving tds_process_default_tokens() connection dead > util.c:104:logic error: cannot change query state from DEAD to > PENDING > dblib.c:3196:dbcancel(0x7fd16ecc1540) > dblib.c:7929:dbperror(0x7fd16ecc1540, 20047, 0) > dblib.c:7981:20047: "DBPROCESS is dead or not enabled" > dblib.c:8002:"DBPROCESS is dead or not enabled", client returns 2 > (INT_CANCEL) > > Any help or guidance you can provide is greatly appreciated. Please let me > know if there's any additional information I can provide. > > Thank you, > Rob > One thing you can do to try if is a problem with connection settings is to try different freetds libraries. We provide dblib (that you are using), ODBC and ctlib. The key is mainly ODBC or not ODBC so you should try same query with ODBC. So run the query with tsql on one test and the other with bsqlodbc, isql or any other ODBC tool using freetds driver (many distribution package ODBC driver in a different package). All Microsoft tools use ODBC settings for connection (beside dblib which Microsoft declared obsolete) Frediano From no-reply at appveyor.com Mon Sep 7 03:01:38 2015 From: no-reply at appveyor.com (AppVeyor) Date: Mon, 07 Sep 2015 07:01:38 +0000 Subject: [freetds] Build failed: freetds 140 Message-ID: <20150907070138.15734.47048@appveyor.com> From no-reply at appveyor.com Mon Sep 7 03:36:20 2015 From: no-reply at appveyor.com (AppVeyor) Date: Mon, 07 Sep 2015 07:36:20 +0000 Subject: [freetds] Build completed: freetds 141 Message-ID: <20150907073620.15704.53358@appveyor.com> From morinr at us.ibm.com Tue Sep 8 13:04:55 2015 From: morinr at us.ibm.com (Rob Morin) Date: Tue, 8 Sep 2015 13:04:55 -0400 Subject: [freetds] Problem with a query against MS SQL 2005 In-Reply-To: References: Message-ID: <201509081706.t88H6ivW025952@d03av05.boulder.ibm.com> Frediano, Thank you for your guidance. I dug in more deeply. The second part of the execute statement is obviously the most critical. I ran it directly on the database server and it is exceeding the time-outs. So, what once took 8-10 seconds to run is now taking the SQL server 15+ minutes to produce the same results. Clearly that isn't a problem with freetds. (I started looking there, since the commands shouldn't actually return anything to freetds other than a 'success' status. At one point, I thought it might be returning multiple result sets (from the IF.. and then the SELECT...), which is why I thought it might be freetds (since 7.1 doesn't handle MARS).) Thank you again, Rob Rob Morin Systems Integration Architect Silverpop, an IBM Company Office: 404.348.9124 Email: morinr at us.ibm.com 6303 Barfield Rd Atlanta, GA 30328 Twitter | Facebook | LinkedIn From: Frediano Ziglio To: FreeTDS Development Group Date: 09/04/2015 04:37 PM Subject: Re: [freetds] Problem with a query against MS SQL 2005 Sent by: freetds-bounces at lists.ibiblio.org Il 01/Set/2015 13:21, "Rob Morin" ha scritto: > > All, > > First, please let me apologize if this already went to the group. I think > I tried to send it before I was officially a member, so I don't know if it > actually went or not. > > I'm upgrading a server from PHP 4.3 to PHP 5.6 and doing the necessary > code remediation. I've got most things working, but I'm having a problem > on certain queries and I'm to the point that I believe it is the driver > (PHP 4.3 used a mssql driver, PHP 5.6 uses FreeTDS) that's causing the > problem. > > The Environment > CentOS 7.1 with PHP 5.6.8 and php56w-mssql from webtatic > This comes with FreeTDS 0.91 from epel > > I've set the FreeTDS global protocol version to 7.2 in freetds.conf. When > it starts, I see an error in the log : "TDS version downgraded to 7.1!" > The wait time is also set to 180. > > The log of the downgrade: > util.c:331:tdserror(0x7fd16ec064c0, 0x7fd16ec9edd0, 100, 0) > dblib.c:7929:dbperror(0x7fd16ec9e360, 100, 0) > dblib.c:7981:100: "TDS version downgraded to 7.1!" > dblib.c:8002:"TDS version downgraded to 7.1!", client returns 2 > (INT_CANCEL) > util.c:361:tdserror: client library returned TDS_INT_CANCEL(2) > util.c:384:tdserror: returning TDS_INT_CANCEL(2) > iconv.c:330:tds_iconv_open(0x7fd16ec9edd0, UTF-8) > iconv.c:187:local name for ISO-8859-1 is ISO-8859-1 > iconv.c:187:local name for UTF-8 is UTF-8 > iconv.c:187:local name for UCS-2LE is UCS-2LE > iconv.c:187:local name for UCS-2BE is UCS-2BE > iconv.c:349:setting up conversions for client charset "UTF-8" > iconv.c:351:preparing iconv for "UTF-8" <-> "UCS-2LE" conversion > iconv.c:391:preparing iconv for "ISO-8859-1" <-> "UCS-2LE" > conversion > iconv.c:394:tds_iconv_open: done > net.c:205:Connecting to 10.100.5.201 port 1433 (TDS version 7.1) > net.c:270:tds_open_socket: connect(2) returned "Operation now in > progress" > net.c:310:tds_open_socket() succeeded > util.c:156:Changed query state from DEAD to IDLE > > I've established that the server is able to connect to the SQL server and > run 'normal' queries. Apparently this one is 'special', but I'm not sure > at what level. > > Here's the query: > IF OBJECT_ID('tempdb..#EarlyRenewals') IS NULL > SELECT * INTO #EarlyRenewals FROM > [atl-sportal01].sportal.dbo.EarlyRenewalsBasedOnDates) > > It appears to be timing out while waiting on the SQL server (SQL 2005). It > takes the server ~8-10 secs to respond to the query. The php script is > 'failing' after waiting ~3 minutes. > > Here's the log after the query is sent: > dblib.c:4639:dbsqlok(0x7fd16ecc1540) > dblib.c:4669:dbsqlok() not done, calling tds_process_tokens() > token.c:540:tds_process_tokens(0x7fd16ecc2890, 0x7fff3872e248, > 0x7fff3872e24c, 0x6914) > util.c:156:Changed query state from PENDING to READING > util.c:331:tdserror(0x7fd16ec064c0, 0x7fd16ecc2890, 20003, 0) > dblib.c:7929:dbperror(0x7fd16ecc1540, 20003, 0) > dblib.c:7981:20003: "Adaptive Server connection timed out" > dblib.c:8002:"Adaptive Server connection timed out", client > returns 2 (INT_CANCEL) > util.c:361:tdserror: client library returned TDS_INT_CANCEL(2) > util.c:384:tdserror: returning TDS_INT_CANCEL(2) > util.c:156:Changed query state from READING to DEAD > token.c:555:processing result tokens. marker is 0() > token.c:122:tds_process_default_tokens() marker is 0() > token.c:125:leaving tds_process_default_tokens() connection dead > util.c:104:logic error: cannot change query state from DEAD to > PENDING > dblib.c:3196:dbcancel(0x7fd16ecc1540) > dblib.c:7929:dbperror(0x7fd16ecc1540, 20047, 0) > dblib.c:7981:20047: "DBPROCESS is dead or not enabled" > dblib.c:8002:"DBPROCESS is dead or not enabled", client returns 2 > (INT_CANCEL) > > Any help or guidance you can provide is greatly appreciated. Please let me > know if there's any additional information I can provide. > > Thank you, > Rob > One thing you can do to try if is a problem with connection settings is to try different freetds libraries. We provide dblib (that you are using), ODBC and ctlib. The key is mainly ODBC or not ODBC so you should try same query with ODBC. So run the query with tsql on one test and the other with bsqlodbc, isql or any other ODBC tool using freetds driver (many distribution package ODBC driver in a different package). All Microsoft tools use ODBC settings for connection (beside dblib which Microsoft declared obsolete) Frediano _______________________________________________ FreeTDS mailing list FreeTDS at lists.ibiblio.org http://lists.ibiblio.org/mailman/listinfo/freetds -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2103 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1299 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 990 bytes Desc: not available URL: From Sean.Harris at nordstrom.com Tue Sep 8 17:08:57 2015 From: Sean.Harris at nordstrom.com (Harris, Sean) Date: Tue, 8 Sep 2015 21:08:57 +0000 Subject: [freetds] tdspool troubles Message-ID: <9E20DF48-0B72-44D2-A0A0-122850A216D4@nordstrom.com> Hello everyone! My team and I are exploring the use of tdspool for a small project and we have run into a snag. The documentation on tdspool is very sparse and so is it?s use from what we can see. Starting the pool seems to go off without a hitch. Here is our pool.conf [global] min pool conn = 5 max pool conn = 10 max member age = 120 [sampool] user = [REDACTED] password = [REDACTED] database = [REDACTED] server = [REDACTED] port = 1313 ;change to a non standard port so we can see the connection details in the debug log Connecting to 127.0.0.1:1313 using TSQL or any sql client tdspool outputs ?accepting connection? and nothing else. The freetds.log outputs the following: dblib.c:1237:tdsdbopen: Calling tds_connect_and_login(0x2b3fec0, 0x2b40580) iconv.c:328:tds_iconv_open(0x2b3fec0, UTF-8) iconv.c:187:local name for ISO-8859-1 is ISO-8859-1 iconv.c:187:local name for UTF-8 is UTF-8 iconv.c:187:local name for UCS-2LE is UCS-2LE iconv.c:187:local name for UCS-2BE is UCS-2BE 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 127.0.0.1 port 1313 (TDS version 7.3) net.c:274:tds_open_socket: connect(2) returned "Operation now in progress" net.c:313:tds_open_socket() succeeded util.c:165:Changed query state from DEAD to IDLE packet.c:740:Sending packet 0000 12 01 00 3a 00 00 00 00-00 00 1a 00 06 01 00 20 |...:.... ....... | 0010 00 01 02 00 21 00 0c 03-00 2d 00 04 04 00 31 00 |....!... .-....1.| 0020 01 ff 09 00 00 00 00 00-02 4d 53 53 51 4c 53 65 |........ .MSSQLSe| 0030 72 76 65 72 00 96 24 00-00 00 |rver..$. ..| util.c:322:tdserror(0x2a6b8c0, 0x2b3fec0, 20003, 115) dblib.c:7897:dbperror(0x2b3f3b0, 20003, 115) dblib.c:7965:dbperror: Calling dblib_err_handler with msgno = 20003; msg->msgtext = "Adaptive Server connection timed out (127.0.0.1:1313)" dblib.c:5743:dbgetuserdata(0x2b3f3b0) dblib.c:7987:dbperror: dblib_err_handler for msgno = 20003; msg->msgtext = "Adaptive Server connection timed out (127.0.0.1:1313)" -- returns 2 (INT_CANCEL) util.c:352:tdserror: client library returned TDS_INT_CANCEL(2) util.c:375:tdserror: returning TDS_INT_CANCEL(2) query.c:3769:tds_disconnect() util.c:165:Changed query state from IDLE to DEAD login.c:472:login packet rejected util.c:322:tdserror(0x2a6b8c0, 0x2b3fec0, 20002, 0) dblib.c:7897:dbperror(0x2b3f3b0, 20002, 0) dblib.c:7965:dbperror: Calling dblib_err_handler with msgno = 20002; msg->msgtext = "Adaptive Server connection failed (127.0.0.1:1313)" dblib.c:5743:dbgetuserdata(0x2b3f3b0) dblib.c:7987:dbperror: dblib_err_handler for msgno = 20002; msg->msgtext = "Adaptive Server connection failed (127.0.0.1:1313)" -- returns 2 (INT_CANCEL) util.c:352:tdserror: client library returned TDS_INT_CANCEL(2) util.c:375:tdserror: returning TDS_INT_CANCEL(2) dblib.c:1241:tdsdbopen: tds_connect_and_login failed for "127.0.0.1:1313"! dblib.c:1463:dbclose(0x2b3f3b0) dblib.c:243:dblib_del_connection(0x7fa27f9644a0, 0x2b3fec0) mem.c:648:tds_free_all_results() dblib.c:290:dblib_release_tds_ctx(1) dblib.c:5845:dbfreebuf(0x2b3f3b0) dblib.c:743:dbloginfree(0x2b3ef10) dblib.c:1533:dbexit(void) dblib.c:1533:dbexit(void) dblib.c:290:dblib_release_tds_ctx(1) Version: freetds v0.95.19 freetds.conf directory: /etc MS db-lib source compatibility: yes Sybase binary compatibility: no Thread safety: yes iconv library: yes TDS version: 5.0 iODBC: no unixodbc: yes SSPI "trusted" logins: no Kerberos: no OpenSSL: no OS: CentOS 6.5 (though the same issue happens on Mac) Sean Harris Content Solutions Senior Software Engineer From freddy77 at gmail.com Fri Sep 11 03:28:36 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Fri, 11 Sep 2015 08:28:36 +0100 Subject: [freetds] reply In-Reply-To: References: Message-ID: 2015-09-11 7:53 GMT+01:00 Frediano Ziglio : > Hello everyone! > > My team and I are exploring the use of tdspool for a small project and > we have run into a snag. The documentation on tdspool is very sparse > and so is it?s use from what we can see. > > Client libraries are used and well tested but pool and server are really not in a good shape. The current state of tdspool is.... it compiles! I'm not surprised it does not run correctly. That said it's open source. Any help/suggestion/patch is welcome. Frediano > > Starting the pool seems to go off without a hitch. Here is our pool.conf > > > [global] > min pool conn = 5 > max pool conn = 10 > max member age = 120 > > [sampool] > user = [REDACTED] > password = [REDACTED] > database = [REDACTED] > server = [REDACTED] > port = 1313 ;change to a non standard port so we can see the > connection details in the debug log > > Connecting to 127.0.0.1:1313 using TSQL or any sql client tdspool > outputs ?accepting connection? and nothing else. The freetds.log > outputs the following: > > > dblib.c:1237:tdsdbopen: Calling tds_connect_and_login(0x2b3fec0, 0x2b40580) > iconv.c:328:tds_iconv_open(0x2b3fec0, UTF-8) > iconv.c:187:local name for ISO-8859-1 is ISO-8859-1 > iconv.c:187:local name for UTF-8 is UTF-8 > iconv.c:187:local name for UCS-2LE is UCS-2LE > iconv.c:187:local name for UCS-2BE is UCS-2BE > 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 127.0.0.1 port 1313 (TDS version 7.3) > net.c:274:tds_open_socket: connect(2) returned "Operation now in progress" > net.c:313:tds_open_socket() succeeded > util.c:165:Changed query state from DEAD to IDLE > packet.c:740:Sending packet > 0000 12 01 00 3a 00 00 00 00-00 00 1a 00 06 01 00 20 |...:.... ....... | > 0010 00 01 02 00 21 00 0c 03-00 2d 00 04 04 00 31 00 |....!... .-....1.| > 0020 01 ff 09 00 00 00 00 00-02 4d 53 53 51 4c 53 65 |........ .MSSQLSe| > 0030 72 76 65 72 00 96 24 00-00 00 |rver..$. ..| > > util.c:322:tdserror(0x2a6b8c0, 0x2b3fec0, 20003, 115) > dblib.c:7897:dbperror(0x2b3f3b0, 20003, 115) > dblib.c:7965:dbperror: Calling dblib_err_handler with msgno = 20003; > msg->msgtext = "Adaptive Server connection timed out (127.0.0.1:1313)" > dblib.c:5743:dbgetuserdata(0x2b3f3b0) > dblib.c:7987:dbperror: dblib_err_handler for msgno = 20003; > msg->msgtext = "Adaptive Server connection timed out (127.0.0.1:1313)" > -- returns 2 (INT_CANCEL) > util.c:352:tdserror: client library returned TDS_INT_CANCEL(2) > util.c:375:tdserror: returning TDS_INT_CANCEL(2) > query.c:3769:tds_disconnect() > util.c:165:Changed query state from IDLE to DEAD > login.c:472:login packet rejected > util.c:322:tdserror(0x2a6b8c0, 0x2b3fec0, 20002, 0) > dblib.c:7897:dbperror(0x2b3f3b0, 20002, 0) > dblib.c:7965:dbperror: Calling dblib_err_handler with msgno = 20002; > msg->msgtext = "Adaptive Server connection failed (127.0.0.1:1313)" > dblib.c:5743:dbgetuserdata(0x2b3f3b0) > dblib.c:7987:dbperror: dblib_err_handler for msgno = 20002; > msg->msgtext = "Adaptive Server connection failed (127.0.0.1:1313)" -- > returns 2 (INT_CANCEL) > util.c:352:tdserror: client library returned TDS_INT_CANCEL(2) > util.c:375:tdserror: returning TDS_INT_CANCEL(2) > dblib.c:1241:tdsdbopen: tds_connect_and_login failed for "127.0.0.1:1313"! > dblib.c:1463:dbclose(0x2b3f3b0) > dblib.c:243:dblib_del_connection(0x7fa27f9644a0, 0x2b3fec0) > mem.c:648:tds_free_all_results() > dblib.c:290:dblib_release_tds_ctx(1) > dblib.c:5845:dbfreebuf(0x2b3f3b0) > dblib.c:743:dbloginfree(0x2b3ef10) > dblib.c:1533:dbexit(void) > dblib.c:1533:dbexit(void) > dblib.c:290:dblib_release_tds_ctx(1) > > > Version: freetds v0.95.19 > freetds.conf directory: /etc > MS db-lib source compatibility: yes > Sybase binary compatibility: no > Thread safety: yes > iconv library: yes > TDS version: 5.0 > iODBC: no > unixodbc: yes > SSPI "trusted" logins: no > Kerberos: no > OpenSSL: no > > > OS: CentOS 6.5 (though the same issue happens on Mac) > > > Sean Harris > Content Solutions > Senior Software Engineer From matthew.green at datamartcomputing.com Fri Sep 11 05:04:58 2015 From: matthew.green at datamartcomputing.com (matthew.green at datamartcomputing.com) Date: Fri, 11 Sep 2015 09:04:58 +0000 Subject: [freetds] Sybase DATE and TIME data types In-Reply-To: References: Message-ID: Dear All, I'm not really a C programmer (or C++ for that matter) but I wanted to be able to use datacopy to copy tables with DATE and TIME data types. So, I decided to have a crack at adding them to FreeTDS. My testing has been successful, although I'm not sure the way I've coded it is correct so any help/fixes would be appreciated. I've attached a rich text document with the details. The first part proposes a quick and dirty fix, while the second is my best guess at the "correct" way of doing things. Bare in mind that this is currently only for Sybase to Sybase. I'm going to look at doing this for SQL Server too but that's a bit more complicated! Cheers, Matthew. -------------- next part -------------- A non-text attachment was scrubbed... Name: Getting datacopy to correctly copy date and time data.rtf Type: application/rtf Size: 95400 bytes Desc: not available URL: From ophorie1 at gmail.com Fri Sep 11 11:51:33 2015 From: ophorie1 at gmail.com (ophorie1 at gmail.com) Date: Fri, 11 Sep 2015 10:51:33 -0500 Subject: [freetds] Sybase DATE and TIME data types In-Reply-To: References: Message-ID: <8F26AD8A-8322-490F-A236-BE280F6BC6AC@gmail.com> Please remove me from this mailing list. Thanks. Sent from my iPhone > On Sep 11, 2015, at 4:04 AM, matthew.green at datamartcomputing.com wrote: > > Dear All, > > I'm not really a C programmer (or C++ for that matter) but I wanted to be able to use datacopy to copy tables with DATE and TIME data types. So, I decided to have a crack at adding them to FreeTDS. > > My testing has been successful, although I'm not sure the way I've coded it is correct so any help/fixes would be appreciated. > > I've attached a rich text document with the details. The first part proposes a quick and dirty fix, while the second is my best guess at the "correct" way of doing things. > > Bare in mind that this is currently only for Sybase to Sybase. I'm going to look at doing this for SQL Server too but that's a bit more complicated! > > Cheers, > > Matthew. > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From no-reply at appveyor.com Sat Sep 12 10:59:30 2015 From: no-reply at appveyor.com (AppVeyor) Date: Sat, 12 Sep 2015 14:59:30 +0000 Subject: [freetds] Build failed: freetds 157 Message-ID: <20150912145930.15714.70981@appveyor.com> From no-reply at appveyor.com Sat Sep 12 14:29:18 2015 From: no-reply at appveyor.com (AppVeyor) Date: Sat, 12 Sep 2015 18:29:18 +0000 Subject: [freetds] Build completed: freetds 158 Message-ID: <20150912182917.17981.67316@appveyor.com> From freddy77 at gmail.com Sun Sep 13 05:55:47 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Sun, 13 Sep 2015 10:55:47 +0100 Subject: [freetds] Sybase DATE and TIME data types In-Reply-To: References: Message-ID: 2015-09-11 10:04 GMT+01:00 : > Dear All, > > I'm not really a C programmer (or C++ for that matter) but I wanted to be able to use datacopy to copy tables with DATE and TIME data types. So, I decided to have a crack at adding them to FreeTDS. > > My testing has been successful, although I'm not sure the way I've coded it is correct so any help/fixes would be appreciated. > > I've attached a rich text document with the details. The first part proposes a quick and dirty fix, while the second is my best guess at the "correct" way of doing things. > > Bare in mind that this is currently only for Sybase to Sybase. I'm going to look at doing this for SQL Server too but that's a bit more complicated! > > Cheers, > > Matthew. > Patch and effort are really appreciated. So appreciated that I already pushed some changes and is actually testing deeply (but I don't think there will be any regression). datacopy still does not work as SYBDATE/SYBTIME are not supported by dblib (you added support for libTDS not upper libraries and datacopy is based on dblib). Currently converting from string will use datetime format in all cases. ODBC has its standard so format strings are well defined for it. I added some improvements too based on previously patches on some other types. Yes, adding a new type in FreeTDS is really a nightmare !!! Frediano From matthew.green at datamartcomputing.com Sun Sep 13 06:19:02 2015 From: matthew.green at datamartcomputing.com (Matthew) Date: Sun, 13 Sep 2015 12:19:02 +0200 Subject: [freetds] Sybase DATE and TIME data types In-Reply-To: References: Message-ID: <55F54D96.7070208@datamartcomputing.com> Thanks for the kind words. It seems I must have missed something as datacopy is working for me when copying DATE and TIME columns from ASE 15.7 to ASE 15.7. A lot of what I did was trial and error and I tried to remember to leave a comment so I could find what I'd changed in order to write it up at the end. Any idea which file I would have changed to get it working with dblib? If not I'll untar the package somewhere else and run a find and diff to see if I can spot it. Cheers, Matthew. On 13/09/15 11:55, Frediano Ziglio wrote: > 2015-09-11 10:04 GMT+01:00 : >> Dear All, >> >> I'm not really a C programmer (or C++ for that matter) but I wanted to be able to use datacopy to copy tables with DATE and TIME data types. So, I decided to have a crack at adding them to FreeTDS. >> >> My testing has been successful, although I'm not sure the way I've coded it is correct so any help/fixes would be appreciated. >> >> I've attached a rich text document with the details. The first part proposes a quick and dirty fix, while the second is my best guess at the "correct" way of doing things. >> >> Bare in mind that this is currently only for Sybase to Sybase. I'm going to look at doing this for SQL Server too but that's a bit more complicated! >> >> Cheers, >> >> Matthew. >> > > Patch and effort are really appreciated. > So appreciated that I already pushed some changes and is actually > testing deeply (but I don't think there will be any regression). > > datacopy still does not work as SYBDATE/SYBTIME are not supported by > dblib (you added support for libTDS not upper libraries and datacopy > is based on dblib). > > Currently converting from string will use datetime format in all > cases. ODBC has its standard so format strings are well defined for > it. > > I added some improvements too based on previously patches on some other types. > > Yes, adding a new type in FreeTDS is really a nightmare !!! > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From no-reply at appveyor.com Sun Sep 13 13:05:35 2015 From: no-reply at appveyor.com (AppVeyor) Date: Sun, 13 Sep 2015 17:05:35 +0000 Subject: [freetds] Build failed: freetds 162 Message-ID: <20150913170535.15724.98251@appveyor.com> From matthew.green at datamartcomputing.com Mon Sep 14 04:19:39 2015 From: matthew.green at datamartcomputing.com (matthew.green at datamartcomputing.com) Date: Mon, 14 Sep 2015 08:19:39 +0000 Subject: [freetds] Sybase DATE and TIME data types In-Reply-To: <55F54D96.7070208@datamartcomputing.com> References: <55F54D96.7070208@datamartcomputing.com> Message-ID: <2363cb4fab47e3fd5f20a3f2b0d3bd0c@datamartcomputing.com> I've found one file I modified which wasn't in my document... sorry about that. The change is to include/sybdb.h, around line 154: enum { ??????? SYBCHAR = 47,?????????? /* 0x2F */ #define SYBCHAR SYBCHAR ??????? SYBVARCHAR = 39,??????? /* 0x27 */ #define SYBVARCHAR????? SYBVARCHAR ??????? SYBINTN = 38,?????????? /* 0x26 */ #define SYBINTN SYBINTN ??????? SYBINT1 = 48,?????????? /* 0x30 */ #define SYBINT1 SYBINT1 ??????? SYBINT2 = 52,?????????? /* 0x34 */ #define SYBINT2 SYBINT2 ??????? SYBINT4 = 56,?????????? /* 0x38 */ #define SYBINT4 SYBINT4 ??????? SYBINT8 = 127,????????? /* 0x7F */ #define SYBINT8 SYBINT8 ??????? SYBFLT8 = 62,?????????? /* 0x3E */ #define SYBFLT8 SYBFLT8 ??????? SYBDATETIME = 61,?????? /* 0x3D */ #define SYBDATETIME???? SYBDATETIME ??????? SYBDATE = 49,?????????? /* 0x31 */ #define SYBDATE???????? SYBDATE ??????? SYBTIME = 51,?????????? /* 0x33 */ #define SYBTIME???????? SYBTIME ??????? SYBBIT = 50,??????????? /* 0x32 */ #define SYBBIT? SYBBIT ??????? SYBBITN = 104,????????? /* 0x68 */ I'll keep looking in case there's anything else..... Cheers, Matthew. September 13 2015 12:19 PM, "Matthew" wrote:Thanks for the kind words. It seems I must have missed something as datacopy is working for me when copying DATE and TIME columns from ASE 15.7 to ASE 15.7. A lot of what I did was trial and error and I tried to remember to leave a comment so I could find what I'd changed in order to write it up at the end. Any idea which file I would have changed to get it working with dblib? If not I'll untar the package somewhere else and run a find and diff to see if I can spot it. Cheers, Matthew. On 13/09/15 11:55, Frediano Ziglio wrote: ?2015-09-11 10:04 GMT+01:00 :Dear All, I'm not really a C programmer (or C++ for that matter) but I wanted to be able to use datacopy tocopy tables with DATE and TIME data types. So, I decided to have a crack at adding them to FreeTDS.My testing has been successful, although I'm not sure the way I've coded it is correct so any help/fixes would be appreciated. I've attached a rich text document with the details. The first part proposes a quick and dirty fix,while the second is my best guess at the "correct" way of doing things. Bare in mind that this is currently only for Sybase to Sybase. I'm going to look at doing this forSQL Server too but that's a bit more complicated! Cheers, Matthew. Patch and effort are really appreciated. So appreciated that I already pushed some changes and is actually testing deeply (but I don't think there will be any regression). datacopy still does not work as SYBDATE/SYBTIME are not supported by dblib (you added support for libTDS not upper libraries and datacopy is based on dblib). Currently converting from string will use datetime format in all cases. ODBC has its standard so format strings are well defined for it. I added some improvements too based on previously patches on some other types. Yes, adding a new type in FreeTDS is really a nightmare !!! Frediano _______________________________________________ FreeTDS mailing list FreeTDS at lists.ibiblio.org (mailto:FreeTDS at lists.ibiblio.org) http://lists.ibiblio.org/mailman/listinfo/freetds (http://lists.ibiblio.org/mailman/listinfo/freetds) From freddy77 at gmail.com Mon Sep 14 04:46:34 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Mon, 14 Sep 2015 09:46:34 +0100 Subject: [freetds] Sybase DATE and TIME data types In-Reply-To: <2363cb4fab47e3fd5f20a3f2b0d3bd0c@datamartcomputing.com> References: <55F54D96.7070208@datamartcomputing.com> <2363cb4fab47e3fd5f20a3f2b0d3bd0c@datamartcomputing.com> Message-ID: Thanks, did patches yesterday. See https://github.com/FreeTDS/freetds/commit/235019b7342cea9bd200e7a7b00bb1bc26e37096 and https://github.com/FreeTDS/freetds/commit/526c035f66cc297943690fd4096444921a764206. Is not easier to do a diff? Currently only ODBC is missing to the list. Frediano 2015-09-14 9:19 GMT+01:00 : > I've found one file I modified which wasn't in my document... sorry about that. > > The change is to include/sybdb.h, around line 154: > > enum > { > SYBCHAR = 47, /* 0x2F */ > #define SYBCHAR SYBCHAR > SYBVARCHAR = 39, /* 0x27 */ > #define SYBVARCHAR SYBVARCHAR > SYBINTN = 38, /* 0x26 */ > #define SYBINTN SYBINTN > SYBINT1 = 48, /* 0x30 */ > #define SYBINT1 SYBINT1 > SYBINT2 = 52, /* 0x34 */ > #define SYBINT2 SYBINT2 > SYBINT4 = 56, /* 0x38 */ > #define SYBINT4 SYBINT4 > SYBINT8 = 127, /* 0x7F */ > #define SYBINT8 SYBINT8 > SYBFLT8 = 62, /* 0x3E */ > #define SYBFLT8 SYBFLT8 > SYBDATETIME = 61, /* 0x3D */ > #define SYBDATETIME SYBDATETIME > SYBDATE = 49, /* 0x31 */ > #define SYBDATE SYBDATE > SYBTIME = 51, /* 0x33 */ > #define SYBTIME SYBTIME > SYBBIT = 50, /* 0x32 */ > #define SYBBIT SYBBIT > SYBBITN = 104, /* 0x68 */ > > I'll keep looking in case there's anything else..... > > Cheers, > > Matthew. > September 13 2015 12:19 PM, "Matthew" wrote:Thanks for the kind words. It seems I must have missed something as > datacopy is working for me when copying DATE and TIME columns from ASE > 15.7 to ASE 15.7. > > A lot of what I did was trial and error and I tried to remember to leave > a comment so I could find what I'd changed in order to write it up at > the end. > > Any idea which file I would have changed to get it working with dblib? > If not I'll untar the package somewhere else and run a find and diff to > see if I can spot it. > > Cheers, > > Matthew. > > On 13/09/15 11:55, Frediano Ziglio wrote: > 2015-09-11 10:04 GMT+01:00 :Dear All, > > I'm not really a C programmer (or C++ for that matter) but I wanted to be able to use datacopy > tocopy tables with DATE and TIME data types. So, I decided to have a crack at adding them to > FreeTDS.My testing has been successful, although I'm not sure the way I've coded it is correct so any > help/fixes would be appreciated. > > I've attached a rich text document with the details. The first part proposes a quick and dirty > fix,while the second is my best guess at the "correct" way of doing things. > > Bare in mind that this is currently only for Sybase to Sybase. I'm going to look at doing this > forSQL Server too but that's a bit more complicated! > > Cheers, > > Matthew. > > Patch and effort are really appreciated. > So appreciated that I already pushed some changes and is actually > testing deeply (but I don't think there will be any regression). > > datacopy still does not work as SYBDATE/SYBTIME are not supported by > dblib (you added support for libTDS not upper libraries and datacopy > is based on dblib). > > Currently converting from string will use datetime format in all > cases. ODBC has its standard so format strings are well defined for > it. > > I added some improvements too based on previously patches on some other types. > > Yes, adding a new type in FreeTDS is really a nightmare !!! > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org (mailto:FreeTDS at lists.ibiblio.org) > http://lists.ibiblio.org/mailman/listinfo/freetds (http://lists.ibiblio.org/mailman/listinfo/freetds) > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From matthew.green at datamartcomputing.com Mon Sep 14 08:13:19 2015 From: matthew.green at datamartcomputing.com (matthew.green at datamartcomputing.com) Date: Mon, 14 Sep 2015 12:13:19 +0000 Subject: [freetds] Sybase DATE and TIME data types In-Reply-To: References: <55F54D96.7070208@datamartcomputing.com> <2363cb4fab47e3fd5f20a3f2b0d3bd0c@datamartcomputing.com> Message-ID: Hi Frediano, Yes, a diff is the thing to do :-) I've got access again so I ran it and the results are (I removed references to compiled objects and documentation): diff -r ../compare/freetds-dev.0.99.220/include/sybdb.h ./include/sybdb.h diff -r ../compare/freetds-dev.0.99.220/include/freetds/convert.h ./include/freetds/convert.h diff -r ../compare/freetds-dev.0.99.220/include/freetds/proto.h ./include/freetds/proto.h diff -r ../compare/freetds-dev.0.99.220/src/apps/datacopy.c ./src/apps/datacopy.c diff -r ../compare/freetds-dev.0.99.220/src/tds/convert.c ./src/tds/convert.c diff -r ../compare/freetds-dev.0.99.220/src/tds/mem.c ./src/tds/mem.c diff -r ../compare/freetds-dev.0.99.220/src/tds/query.c ./src/tds/query.c diff -r ../compare/freetds-dev.0.99.220/src/tds/tds_types.h ./src/tds/tds_types.h So, I'd missed two files (in bold) which have now been updated in my attached document. It's still working for me :-) Cheers, Matthew. September 14 2015 10:46 AM, "Frediano Ziglio" wrote:Thanks, did patches yesterday. See https://github.com/FreeTDS/freetds/commit/235019b7342cea9bd200e7a7b00bb1bc26e37096 (https://github.com/FreeTDS/freetds/commit/235019b7342cea9bd200e7a7b00bb1bc26e37096) and https://github.com/FreeTDS/freetds/commit/526c035f66cc297943690fd4096444921a764206 (https://github.com/FreeTDS/freetds/commit/526c035f66cc297943690fd4096444921a764206). Is not easier to do a diff? Currently only ODBC is missing to the list. Frediano 2015-09-14 9:19 GMT+01:00 : ?I've found one file I modified which wasn't in my document... sorry about that. The change is to include/sybdb.h, around line 154: enum { SYBCHAR = 47, /* 0x2F */ #define SYBCHAR SYBCHAR SYBVARCHAR = 39, /* 0x27 */ #define SYBVARCHAR SYBVARCHAR SYBINTN = 38, /* 0x26 */ #define SYBINTN SYBINTN SYBINT1 = 48, /* 0x30 */ #define SYBINT1 SYBINT1 SYBINT2 = 52, /* 0x34 */ #define SYBINT2 SYBINT2 SYBINT4 = 56, /* 0x38 */ #define SYBINT4 SYBINT4 SYBINT8 = 127, /* 0x7F */ #define SYBINT8 SYBINT8 SYBFLT8 = 62, /* 0x3E */ #define SYBFLT8 SYBFLT8 SYBDATETIME = 61, /* 0x3D */ #define SYBDATETIME SYBDATETIME SYBDATE = 49, /* 0x31 */ #define SYBDATE SYBDATE SYBTIME = 51, /* 0x33 */ #define SYBTIME SYBTIME SYBBIT = 50, /* 0x32 */ #define SYBBIT SYBBIT SYBBITN = 104, /* 0x68 */ I'll keep looking in case there's anything else..... Cheers, Matthew. September 13 2015 12:19 PM, "Matthew" wrote:Thanks for the kind words. It seems I must have missedsomething as datacopy is working for me when copying DATE and TIME columns from ASE 15.7 to ASE 15.7. A lot of what I did was trial and error and I tried to remember to leave a comment so I could find what I'd changed in order to write it up at the end. Any idea which file I would have changed to get it working with dblib? If not I'll untar the package somewhere else and run a find and diff to see if I can spot it. Cheers, Matthew. On 13/09/15 11:55, Frediano Ziglio wrote: 2015-09-11 10:04 GMT+01:00 :Dear All, I'm not really a C programmer (or C++ for that matter) but I wanted to be able to use datacopy tocopy tables with DATE and TIME data types. So, I decided to have a crack at adding them to FreeTDS.My testing has been successful, although I'm not sure the way I've coded it is correct so any help/fixes would be appreciated. I've attached a rich text document with the details. The first part proposes a quick and dirty fix,while the second is my best guess at the "correct" way of doing things. Bare in mind that this is currently only for Sybase to Sybase. I'm going to look at doing this forSQL Server too but that's a bit more complicated! Cheers, Matthew. Patch and effort are really appreciated. So appreciated that I already pushed some changes and is actually testing deeply (but I don't think there will be any regression). datacopy still does not work as SYBDATE/SYBTIME are not supported by dblib (you added support for libTDS not upper libraries and datacopy is based on dblib). Currently converting from string will use datetime format in all cases. ODBC has its standard so format strings are well defined for it. I added some improvements too based on previously patches on some other types. Yes, adding a new type in FreeTDS is really a nightmare !!! Frediano _______________________________________________ FreeTDS mailing list FreeTDS at lists.ibiblio.org (mailto:FreeTDS at lists.ibiblio.org) (mailto:FreeTDS at lists.ibiblio.org (mailto:mailto:FreeTDS at lists.ibiblio.org)) http://lists.ibiblio.org/mailman/listinfo/freetds (http://lists.ibiblio.org/mailman/listinfo/freetds) (http://lists.ibiblio.org/mailman/listinfo/freetds (http://lists.ibiblio.org/mailman/listinfo/freetds)) _______________________________________________ FreeTDS mailing list FreeTDS at lists.ibiblio.org (mailto:FreeTDS at lists.ibiblio.org) http://lists.ibiblio.org/mailman/listinfo/freetds (http://lists.ibiblio.org/mailman/listinfo/freetds) _______________________________________________ FreeTDS mailing list FreeTDS at lists.ibiblio.org (mailto:FreeTDS at lists.ibiblio.org) http://lists.ibiblio.org/mailman/listinfo/freetds (http://lists.ibiblio.org/mailman/listinfo/freetds) -------------- next part -------------- A non-text attachment was scrubbed... Name: Getting datacopy to correctly copy date and time data.rtf Type: application/rtf Size: 99778 bytes Desc: not available URL: From freddy77 at gmail.com Mon Sep 14 08:37:14 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Mon, 14 Sep 2015 13:37:14 +0100 Subject: [freetds] Sybase DATE and TIME data types In-Reply-To: References: <55F54D96.7070208@datamartcomputing.com> <2363cb4fab47e3fd5f20a3f2b0d3bd0c@datamartcomputing.com> Message-ID: The change for tds_types.h is not necessary, the invalid constant is actually 0. Also tds_types.h is auto generated from misc/types.cvs. The change in include/sybdb.h is also in my patches to support these types (with new bindings) in dblib. So... please grab the last snapshot and try again, should work! Actually there is no automatic tests for freebcp and datacopy (but the base functions they use are tested). Frediano 2015-09-14 13:13 GMT+01:00 : > Hi Frediano, > > Yes, a diff is the thing to do :-) I've got access again so I ran it and the results are (I removed references to compiled objects and documentation): > > diff -r ../compare/freetds-dev.0.99.220/include/sybdb.h ./include/sybdb.h > diff -r ../compare/freetds-dev.0.99.220/include/freetds/convert.h ./include/freetds/convert.h > diff -r ../compare/freetds-dev.0.99.220/include/freetds/proto.h ./include/freetds/proto.h > diff -r ../compare/freetds-dev.0.99.220/src/apps/datacopy.c ./src/apps/datacopy.c > diff -r ../compare/freetds-dev.0.99.220/src/tds/convert.c ./src/tds/convert.c > diff -r ../compare/freetds-dev.0.99.220/src/tds/mem.c ./src/tds/mem.c > diff -r ../compare/freetds-dev.0.99.220/src/tds/query.c ./src/tds/query.c > diff -r ../compare/freetds-dev.0.99.220/src/tds/tds_types.h ./src/tds/tds_types.h > > So, I'd missed two files (in bold) which have now been updated in my attached document. > > It's still working for me :-) > > Cheers, > > Matthew. > September 14 2015 10:46 AM, "Frediano Ziglio" wrote:Thanks, > did patches yesterday. See > https://github.com/FreeTDS/freetds/commit/235019b7342cea9bd200e7a7b00bb1bc26e37096 (https://github.com/FreeTDS/freetds/commit/235019b7342cea9bd200e7a7b00bb1bc26e37096) > and https://github.com/FreeTDS/freetds/commit/526c035f66cc297943690fd4096444921a764206 (https://github.com/FreeTDS/freetds/commit/526c035f66cc297943690fd4096444921a764206). > > Is not easier to do a diff? > > Currently only ODBC is missing to the list. > > Frediano > > 2015-09-14 9:19 GMT+01:00 : > I've found one file I modified which wasn't in my document... sorry about that. > > The change is to include/sybdb.h, around line 154: > > enum > { > SYBCHAR = 47, /* 0x2F */ > #define SYBCHAR SYBCHAR > SYBVARCHAR = 39, /* 0x27 */ > #define SYBVARCHAR SYBVARCHAR > SYBINTN = 38, /* 0x26 */ > #define SYBINTN SYBINTN > SYBINT1 = 48, /* 0x30 */ > #define SYBINT1 SYBINT1 > SYBINT2 = 52, /* 0x34 */ > #define SYBINT2 SYBINT2 > SYBINT4 = 56, /* 0x38 */ > #define SYBINT4 SYBINT4 > SYBINT8 = 127, /* 0x7F */ > #define SYBINT8 SYBINT8 > SYBFLT8 = 62, /* 0x3E */ > #define SYBFLT8 SYBFLT8 > SYBDATETIME = 61, /* 0x3D */ > #define SYBDATETIME SYBDATETIME > SYBDATE = 49, /* 0x31 */ > #define SYBDATE SYBDATE > SYBTIME = 51, /* 0x33 */ > #define SYBTIME SYBTIME > SYBBIT = 50, /* 0x32 */ > #define SYBBIT SYBBIT > SYBBITN = 104, /* 0x68 */ > > I'll keep looking in case there's anything else..... > > Cheers, > > Matthew. > September 13 2015 12:19 PM, "Matthew" wrote:Thanks for the kind words. It seems I must have > missedsomething as > datacopy is working for me when copying DATE and TIME columns from ASE > 15.7 to ASE 15.7. > > A lot of what I did was trial and error and I tried to remember to leave > a comment so I could find what I'd changed in order to write it up at > the end. > > Any idea which file I would have changed to get it working with dblib? > If not I'll untar the package somewhere else and run a find and diff to > see if I can spot it. > > Cheers, > > Matthew. > > On 13/09/15 11:55, Frediano Ziglio wrote: > 2015-09-11 10:04 GMT+01:00 :Dear All, > > I'm not really a C programmer (or C++ for that matter) but I wanted to be able to use datacopy > tocopy tables with DATE and TIME data types. So, I decided to have a crack at adding them to > FreeTDS.My testing has been successful, although I'm not sure the way I've coded it is correct so > any > help/fixes would be appreciated. > > I've attached a rich text document with the details. The first part proposes a quick and dirty > fix,while the second is my best guess at the "correct" way of doing things. > > Bare in mind that this is currently only for Sybase to Sybase. I'm going to look at doing this > forSQL Server too but that's a bit more complicated! > > Cheers, > > Matthew. > > Patch and effort are really appreciated. > So appreciated that I already pushed some changes and is actually > testing deeply (but I don't think there will be any regression). > > datacopy still does not work as SYBDATE/SYBTIME are not supported by > dblib (you added support for libTDS not upper libraries and datacopy > is based on dblib). > > Currently converting from string will use datetime format in all > cases. ODBC has its standard so format strings are well defined for > it. > > I added some improvements too based on previously patches on some other types. > > Yes, adding a new type in FreeTDS is really a nightmare !!! > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org (mailto:FreeTDS at lists.ibiblio.org) (mailto:FreeTDS at lists.ibiblio.org (mailto:mailto:FreeTDS at lists.ibiblio.org)) > http://lists.ibiblio.org/mailman/listinfo/freetds (http://lists.ibiblio.org/mailman/listinfo/freetds) > (http://lists.ibiblio.org/mailman/listinfo/freetds (http://lists.ibiblio.org/mailman/listinfo/freetds)) > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org (mailto:FreeTDS at lists.ibiblio.org) > http://lists.ibiblio.org/mailman/listinfo/freetds (http://lists.ibiblio.org/mailman/listinfo/freetds) > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org (mailto:FreeTDS at lists.ibiblio.org) > http://lists.ibiblio.org/mailman/listinfo/freetds (http://lists.ibiblio.org/mailman/listinfo/freetds) > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > From matthew.green at datamartcomputing.com Tue Sep 15 09:32:52 2015 From: matthew.green at datamartcomputing.com (matthew.green at datamartcomputing.com) Date: Tue, 15 Sep 2015 13:32:52 +0000 Subject: [freetds] Sybase DATE and TIME data types In-Reply-To: References: <55F54D96.7070208@datamartcomputing.com> <2363cb4fab47e3fd5f20a3f2b0d3bd0c@datamartcomputing.com> Message-ID: Hi Frediano, I downloaded the latest release (freetds-dev.0.99.297) but it fails with: datacopy -t -p32768 -v -S SOURECE/USER/PW/DBdate_time_source -D DESTINATION/USER/PW/DB/date_time_destination -E -T200000 Error in dbnumcols datacopy: table structures do not match. terminating My working version still works and looks like: Starting copy... rows read??????????? : 5 rows written???????? : 5 elapsed time (secs)? : 0.002556 rows per second????? : 1956.181534 I just wan,ted to check that I'd got the right version before I start investigating what's missing. Thanks, Matthew. PS. Here's the SQL I use to test (as well as a visual check): ? if exists (select 1 from sysobjects where name = "date_time_source" and type = "U") ??? drop table date_time_source go if exists (select 1 from sysobjects where name = "date_time_destination" and type = "U") ??? drop table date_time_destination go create table date_time_source ( ?? ?dt_i???????????????????????????? int????????????????????????????? not null? , ?? ?dt_d???????????????????????????? datetime???????????????????????? not null? , ?? ?dt_dt??????????????????????????? date???????????????????????????? not null? , ?? ?dt_t???????????????????????????? time???????????????????????????? not null? , ?? ?dt_i2??????????????????????????? int????????????????????????????????? null? , ??? dt_dt2?????????????????????????? date???????????????????????????????? null? , ??? dt_t2??????????????????????????? time???????????????????????????????? null ) create table date_time_destination ( ?? ?dt_i???????????????????????????? int????????????????????????????? not null? , ?? ?dt_d???????????????????????????? datetime???????????????????????? not null? , ?? ?dt_dt??????????????????????????? date???????????????????????????? not null? , ?? ?dt_t???????????????????????????? time???????????????????????????? not null? , ?? ?dt_i2??????????????????????????? int????????????????????????????????? null? , ??? dt_dt2?????????????????????????? date???????????????????????????????? null? , ??? dt_t2??????????????????????????? time???????????????????????????????? null ) go INSERT INTO date_time_source select 1,'1970-06-13 11:15:23.223','1970-06-13','10:15:23',2,'1950-12-10','05:15:12' INSERT INTO date_time_source select 2,'1980-08-15 12:15:23.009','1970-06-15','12:15:23',3,'1965-02-20',NULL INSERT INTO date_time_source select 3,'1981-10-30 02:05:25.123','1966-01-01','07:11:17',4,NULL,'15:00:12:123' INSERT INTO date_time_source select 3,'1977-11-05 19:17:03.003','1960-02-14','07:11:17',4,NULL,NULL INSERT INTO date_time_source select 1,'2012-01-13 11:15:23.223','2030-03-25','21:35:23:176',2,'1958-10-17','09:05:50:840' go -- Pause here and run datacopy. Don't forget you will need select/into turned on in the target database. declare @source_rows int, ??????? @destination_rows int, ??????? @unique_rows int, ??????? @message varchar(2000) select @source_rows = count(*) from date_time_source select @destination_rows = count(*) from date_time_destination select dt_i, dt_d, dt_dt, dt_t, dt_i2, dt_dt2 , dt_t2 from date_time_source union ? select dt_i, dt_d, dt_dt, dt_t, dt_i2, dt_dt2 , dt_t2 from date_time_destination select @unique_rows = @@rowcount if @unique_rows != @source_rows ??? select @message = "ERROR: "+convert(varchar, at source_rows)+" source rows resulted in "+convert(varchar, at unique_rows)+" unqiue rows." else if @destination_rows != @source_rows ??? select @message = "ERROR: "+convert(varchar, at source_rows)+" source rows resulted in "+convert(varchar, at destination_rows)+" destination rows." if @message is null ??? print "TEST PASSED." else ??? print "TEST FAILED" print @message go ? September 14 2015 2:37 PM, "Frediano Ziglio" wrote:The change for tds_types.h is not necessary, the invalid constant is actually 0. Also tds_types.h is auto generated from misc/types.cvs. The change in include/sybdb.h is also in my patches to support these types (with new bindings) in dblib. So... please grab the last snapshot and try again, should work! Actually there is no automatic tests for freebcp and datacopy (but the base functions they use are tested). Frediano 2015-09-14 13:13 GMT+01:00 : ?Hi Frediano, Yes, a diff is the thing to do :-) I've got access again so I ran it and the results are (I removedreferences to compiled objects and documentation): diff -r ../compare/freetds-dev.0.99.220/include/sybdb.h ./include/sybdb.h diff -r ../compare/freetds-dev.0.99.220/include/freetds/convert.h ./include/freetds/convert.h diff -r ../compare/freetds-dev.0.99.220/include/freetds/proto.h ./include/freetds/proto.h diff -r ../compare/freetds-dev.0.99.220/src/apps/datacopy.c ./src/apps/datacopy.c diff -r ../compare/freetds-dev.0.99.220/src/tds/convert.c ./src/tds/convert.c diff -r ../compare/freetds-dev.0.99.220/src/tds/mem.c ./src/tds/mem.c diff -r ../compare/freetds-dev.0.99.220/src/tds/query.c ./src/tds/query.c diff -r ../compare/freetds-dev.0.99.220/src/tds/tds_types.h ./src/tds/tds_types.h So, I'd missed two files (in bold) which have now been updated in my attached document. It's still working for me :-) Cheers, Matthew. September 14 2015 10:46 AM, "Frediano Ziglio" wrote:Thanks, did patches yesterday. See https://github.com/FreeTDS/freetds/commit/235019b7342cea9bd200e7a7b00bb1bc26e37096 (https://github.com/FreeTDS/freetds/commit/235019b7342cea9bd200e7a7b00bb1bc26e37096) (https://github.com/FreeTDS/freetds/commit/235019b7342cea9bd200e7a7b00bb1bc26e37096 (https://github.com/FreeTDS/freetds/commit/235019b7342cea9bd200e7a7b00bb1bc26e37096)) and https://github.com/FreeTDS/freetds/commit/526c035f66cc297943690fd4096444921a764206 (https://github.com/FreeTDS/freetds/commit/526c035f66cc297943690fd4096444921a764206) (https://github.com/FreeTDS/freetds/commit/526c035f66cc297943690fd4096444921a764206 (https://github.com/FreeTDS/freetds/commit/526c035f66cc297943690fd4096444921a764206)). Is not easier to do a diff? Currently only ODBC is missing to the list. Frediano 2015-09-14 9:19 GMT+01:00 : I've found one file I modified which wasn't in my document... sorry about that. The change is to include/sybdb.h, around line 154: enum { SYBCHAR = 47, /* 0x2F */ #define SYBCHAR SYBCHAR SYBVARCHAR = 39, /* 0x27 */ #define SYBVARCHAR SYBVARCHAR SYBINTN = 38, /* 0x26 */ #define SYBINTN SYBINTN SYBINT1 = 48, /* 0x30 */ #define SYBINT1 SYBINT1 SYBINT2 = 52, /* 0x34 */ #define SYBINT2 SYBINT2 SYBINT4 = 56, /* 0x38 */ #define SYBINT4 SYBINT4 SYBINT8 = 127, /* 0x7F */ #define SYBINT8 SYBINT8 SYBFLT8 = 62, /* 0x3E */ #define SYBFLT8 SYBFLT8 SYBDATETIME = 61, /* 0x3D */ #define SYBDATETIME SYBDATETIME SYBDATE = 49, /* 0x31 */ #define SYBDATE SYBDATE SYBTIME = 51, /* 0x33 */ #define SYBTIME SYBTIME SYBBIT = 50, /* 0x32 */ #define SYBBIT SYBBIT SYBBITN = 104, /* 0x68 */ I'll keep looking in case there's anything else..... Cheers, Matthew. September 13 2015 12:19 PM, "Matthew" wrote:Thanks for the kind words. It seems I must have missedsomething as datacopy is working for me when copying DATE and TIME columns from ASE 15.7 to ASE 15.7. A lot of what I did was trial and error and I tried to remember to leave a comment so I could find what I'd changed in order to write it up at the end. Any idea which file I would have changed to get it working with dblib? If not I'll untar the package somewhere else and run a find and diff to see if I can spot it. Cheers, Matthew. On 13/09/15 11:55, Frediano Ziglio wrote: 2015-09-11 10:04 GMT+01:00 :Dear All, I'm not really a C programmer (or C++ for that matter) but I wanted to be able to use datacopy tocopy tables with DATE and TIME data types. So, I decided to have a crack at adding them to FreeTDS.My testing has been successful, although I'm not sure the way I've coded it is correct so any help/fixes would be appreciated. I've attached a rich text document with the details. The first part proposes a quick and dirty fix,while the second is my best guess at the "correct" way of doing things. Bare in mind that this is currently only for Sybase to Sybase. I'm going to look at doing this forSQL Server too but that's a bit more complicated! Cheers, Matthew. Patch and effort are really appreciated. So appreciated that I already pushed some changes and is actually testing deeply (but I don't think there will be any regression). datacopy still does not work as SYBDATE/SYBTIME are not supported by dblib (you added support for libTDS not upper libraries and datacopy is based on dblib). Currently converting from string will use datetime format in all cases. ODBC has its standard so format strings are well defined for it. I added some improvements too based on previously patches on some other types. Yes, adding a new type in FreeTDS is really a nightmare !!! Frediano _______________________________________________ FreeTDS mailing list FreeTDS at lists.ibiblio.org (mailto:FreeTDS at lists.ibiblio.org) (mailto:FreeTDS at lists.ibiblio.org (mailto:mailto:FreeTDS at lists.ibiblio.org)) (mailto:FreeTDS at lists.ibiblio.org (mailto:mailto:FreeTDS at lists.ibiblio.org) (mailto:mailto:FreeTDS at lists.ibiblio.org (mailto:mailto:mailto:FreeTDS at lists.ibiblio.org))) http://lists.ibiblio.org/mailman/listinfo/freetds (http://lists.ibiblio.org/mailman/listinfo/freetds) (http://lists.ibiblio.org/mailman/listinfo/freetds (http://lists.ibiblio.org/mailman/listinfo/freetds)) (http://lists.ibiblio.org/mailman/listinfo/freetds (http://lists.ibiblio.org/mailman/listinfo/freetds) (http://lists.ibiblio.org/mailman/listinfo/freetds) (http://lists.ibiblio.org/mailman/listinfo/freetds))) _______________________________________________ FreeTDS mailing list FreeTDS at lists.ibiblio.org (mailto:FreeTDS at lists.ibiblio.org) (mailto:FreeTDS at lists.ibiblio.org (mailto:mailto:FreeTDS at lists.ibiblio.org)) http://lists.ibiblio.org/mailman/listinfo/freetds (http://lists.ibiblio.org/mailman/listinfo/freetds) (http://lists.ibiblio.org/mailman/listinfo/freetds (http://lists.ibiblio.org/mailman/listinfo/freetds)) _______________________________________________ FreeTDS mailing list FreeTDS at lists.ibiblio.org (mailto:FreeTDS at lists.ibiblio.org) (mailto:FreeTDS at lists.ibiblio.org (mailto:mailto:FreeTDS at lists.ibiblio.org)) http://lists.ibiblio.org/mailman/listinfo/freetds (http://lists.ibiblio.org/mailman/listinfo/freetds) (http://lists.ibiblio.org/mailman/listinfo/freetds (http://lists.ibiblio.org/mailman/listinfo/freetds)) _______________________________________________ FreeTDS mailing list FreeTDS at lists.ibiblio.org (mailto:FreeTDS at lists.ibiblio.org) http://lists.ibiblio.org/mailman/listinfo/freetds (http://lists.ibiblio.org/mailman/listinfo/freetds) _______________________________________________ FreeTDS mailing list FreeTDS at lists.ibiblio.org (mailto:FreeTDS at lists.ibiblio.org) http://lists.ibiblio.org/mailman/listinfo/freetds (http://lists.ibiblio.org/mailman/listinfo/freetds) From tworman at med.umich.edu Tue Sep 15 13:39:26 2015 From: tworman at med.umich.edu (Worman, Tyler) Date: Tue, 15 Sep 2015 17:39:26 +0000 Subject: [freetds] FreeTDS build on AIX - No shared objects (.so) generated? Message-ID: Hi, Trying to build FreeTDS (stable .95.19) on AIX 7100-03-05-1524. The .so files don't generate. Browsed online and tried a few suggested fixes for similar problems but no luck so far. Generated my own .so files from the .a that builds but it doesn't seem to work. Any advice? Using the following: ./configure --with-unixodbc=/usr/local/ --prefix=/home/tworman/local --with-tdsver=7.0 make make install Appears to complete but no .so files are generated in the directory /home/tworman/local/lib. I only get .a and .la files. I tested tsql that was built. It worked and connected to my MS SQL Server instance fine. I then generated the .so from the .a with gcc -fpic -g -shared -o libtdsodbc.so libtdsodbc.a I verified my config using osql. It's fine until it gets to the actual connection and invoking isql (Unixodbc 32-bit). I tried the exact same .odbc.ini from a Linux box with a build of FreeTDS there and it works fine. The OSQL test: ./osql -S TEST -U accthere -P passwordhere That produces this but no dump. [IM004][unixODBC][Driver Manager]Driver's SQLAllocHandle on SQL_HANDLE_HENV failed [ISQL]ERROR: Could not SQLConnect sed: Cannot find or open file /tmp/osql.dump.51511686. If I do this instead, I still get no dump, and nothing is written to the file I specify. TDSDUMPCONFIG=stderr TDSDUMP=~/local/bin/temp ./osql -S TEST -U usernamhere -P passwordhere Thanks! - Tyler Semi-unrelated try of 64 bit build (even though UnixODBC is compiled with 32bit types). export OBJECT_MODE=64 export CFLAGS=-maix64 export LIBPATH=/usr/local/lib export LD_LIBRARY_PATH=/usr/local/lib export AR_FLAGS="-X64 cru" export ARFLAGS="-X64 cru" ./configure --with-tdsver=7.0 --with-unixodbc=/usr/local --prefix=/home/tworman/local Configure is fine but build of this fails with: Making all in . CC odbc.lo odbc.c: In function '_SQLRowCount': odbc.c:4630: warning: visibility attribute not supported in this configuration; ignored CC connectparams.lo connectparams.c:96: error: static declaration of 'SQLGetPrivateProfileString' follows non-static declaration /usr/local/include/odbcinst.h:210: error: previous declaration of 'SQLGetPrivateProfileString' was here make: The error code from the last command is 1. Stop. make: The error code from the last command is 1. Stop. make: The error code from the last command is 2. Stop. make: The error code from the last command is 1. Stop. make: The error code from the last command is 1. Stop. Not sure if this is really the path I should go down. This seems like I just have multiple libraries defining SQLGetPrivateProfileString but I only see one in my library path. That is the one from unixodbc at /usr/local/include/ ********************************************************** Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues From freddy77 at gmail.com Tue Sep 15 14:46:59 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Tue, 15 Sep 2015 19:46:59 +0100 Subject: [freetds] FreeTDS build on AIX - No shared objects (.so) generated? In-Reply-To: References: Message-ID: 2015-09-15 18:39 GMT+01:00 Worman, Tyler : > Hi, > Trying to build FreeTDS (stable .95.19) on AIX 7100-03-05-1524. The .so files don't generate. Browsed online and tried a few suggested fixes for similar problems but no luck so far. Generated my own .so files from the .a that builds but it doesn't seem to work. Any advice? > > Using the following: > ./configure --with-unixodbc=/usr/local/ --prefix=/home/tworman/local --with-tdsver=7.0 > make > make install > > Appears to complete but no .so files are generated in the directory /home/tworman/local/lib. I only get .a and .la files. > I tested tsql that was built. It worked and connected to my MS SQL Server instance fine. > tsql always works :) It use static linking so one less issue to solve! AIX is quite strange when it comes to shared libraries. The static library on AIX are not such different from static ones. > I then generated the .so from the .a with gcc -fpic -g -shared -o libtdsodbc.so libtdsodbc.a > I verified my config using osql. It's fine until it gets to the actual connection and invoking isql (Unixodbc 32-bit). osql do you mean the utility in src/apps, right? > I tried the exact same .odbc.ini from a Linux box with a build of FreeTDS there and it works fine. > > The OSQL test: > ./osql -S TEST -U accthere -P passwordhere > > That produces this but no dump. > [IM004][unixODBC][Driver Manager]Driver's SQLAllocHandle on SQL_HANDLE_HENV failed > [ISQL]ERROR: Could not SQLConnect > sed: Cannot find or open file /tmp/osql.dump.51511686. > > If I do this instead, I still get no dump, and nothing is written to the file I specify. > TDSDUMPCONFIG=stderr TDSDUMP=~/local/bin/temp ./osql -S TEST -U usernamhere -P passwordhere > could be is not loading the driver so these environment are not used. > Thanks! > > - Tyler > > It would be helpful to see the configure output to understand if something went wrong. > > > > > Semi-unrelated try of 64 bit build (even though UnixODBC is compiled with 32bit types). > export OBJECT_MODE=64 > export CFLAGS=-maix64 > export LIBPATH=/usr/local/lib > export LD_LIBRARY_PATH=/usr/local/lib > export AR_FLAGS="-X64 cru" > export ARFLAGS="-X64 cru" > ./configure --with-tdsver=7.0 --with-unixodbc=/usr/local --prefix=/home/tworman/local > > Configure is fine but build of this fails with: > Making all in . > CC odbc.lo > odbc.c: In function '_SQLRowCount': > odbc.c:4630: warning: visibility attribute not supported in this configuration; ignored > CC connectparams.lo > connectparams.c:96: error: static declaration of 'SQLGetPrivateProfileString' follows non-static declaration > /usr/local/include/odbcinst.h:210: error: previous declaration of 'SQLGetPrivateProfileString' was here Is quite expected, is finding the declaration but not the function. Trying to remove the odbcinst.h should make it compile. Better to have a 64 bit unixODBC ! > make: The error code from the last command is 1. > Stop. > make: The error code from the last command is 1. > Stop. > make: The error code from the last command is 2. > Stop. > make: The error code from the last command is 1. > Stop. > make: The error code from the last command is 1. > Stop. > > Not sure if this is really the path I should go down. This seems like I just have multiple libraries defining SQLGetPrivateProfileString but I only see one in my library path. That is the one from unixodbc at /usr/local/include/ If you have autoconf installed in the system you can try with autoreconf -if command before configure to see if you can get a working libtool. Or I can try to make a distribution from a recent system and send to you to try a new libtool. Frediano From fabrizio.magni at besolution.it Wed Sep 16 04:47:12 2015 From: fabrizio.magni at besolution.it (Fabrizio Magni) Date: Wed, 16 Sep 2015 10:47:12 +0200 Subject: [freetds] sybase login encryption In-Reply-To: <55F69F69.3020203@besolution.it> References: <55F69F69.3020203@besolution.it> Message-ID: <55F92C90.7060805@besolution.it> Hello, I'm trying to connect to a Sybase obtaining this error: Adaptive Server requires encryption of the login password on the network I cannot change the server configuration. Is there any way to encrypt the password? I tried: [testt] host = 10.10.10.10 port = 4901 tds version = 5.0 ASA database = TEST encryption = required But still no luck. Regards Fabrizio From freddy77 at gmail.com Wed Sep 16 13:40:20 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Wed, 16 Sep 2015 18:40:20 +0100 Subject: [freetds] sybase login encryption In-Reply-To: <55F92C90.7060805@besolution.it> References: <55F69F69.3020203@besolution.it> <55F92C90.7060805@besolution.it> Message-ID: 2015-09-16 9:47 GMT+01:00 Fabrizio Magni : > Hello, > I'm trying to connect to a Sybase obtaining this error: > Adaptive Server requires encryption of the login password on the network > I cannot change the server configuration. > Is there any way to encrypt the password? > > I tried: > > [testt] > host = 10.10.10.10 > port = 4901 > tds version = 5.0 > ASA database = TEST > encryption = required > > But still no luck. > > Regards > Fabrizio > Currently not supported. But is in my todo list https://trello.com/b/bk0UZNRJ/freetds-todo-list. Frediano From james.k.lowden at icloud.com Wed Sep 16 18:32:09 2015 From: james.k.lowden at icloud.com (James K. Lowden) Date: Wed, 16 Sep 2015 18:32:09 -0400 Subject: [freetds] FreeTDS build on AIX - No shared objects (.so) generated? In-Reply-To: References: Message-ID: <20150916183209.ed4b4bb7.james.k.lowden@icloud.com> On Tue, 15 Sep 2015 17:39:26 +0000 "Worman, Tyler" wrote: > Trying to build FreeTDS (stable .95.19) on AIX 7100-03-05-1524. > The .so files don't generate. Browsed online and tried a few > suggested fixes for similar problems but no luck so far. Generated my > own .so files from the .a that builds but it doesn't seem to work. > Any advice? If memory serves, .a in AIX *is* a dynamic library. I don't believe AIX follows the .so convention. If you're not sure, what does file(1) tell you? As Frediano said, tsql doesn't use the shared libraries. The simplest test is to run the unit tests for dblib, or run bsqldb. HTH. --jkl From no-reply at appveyor.com Fri Sep 18 06:47:00 2015 From: no-reply at appveyor.com (AppVeyor) Date: Fri, 18 Sep 2015 10:47:00 +0000 Subject: [freetds] Build failed: freetds 178 Message-ID: <20150918104700.16571.65269@appveyor.com> From no-reply at appveyor.com Fri Sep 18 06:57:45 2015 From: no-reply at appveyor.com (AppVeyor) Date: Fri, 18 Sep 2015 10:57:45 +0000 Subject: [freetds] Build failed: freetds 180 Message-ID: <20150918105745.9945.97230@appveyor.com> From tworman at med.umich.edu Thu Sep 17 00:09:50 2015 From: tworman at med.umich.edu (Worman, Tyler) Date: Thu, 17 Sep 2015 04:09:50 +0000 Subject: [freetds] FreeTDS build on AIX - No shared objects (.so) generated? Message-ID: I was curious about the .a too, so I tried to direct UnixODBC to use the .a as the driver file but no luck. Unfortunately I'm not terribly familiar with AIX and our admin has been swamped, so my time with him is limited for questioned about the shared objects. [01000][unixODBC][Driver Manager]Can't open lib '/home/tworman/local/lib/libtdsodbc.a' : file not found [ISQL]ERROR: Could not SQLConnect But the file is there.... bash-4.2$ file /home/tworman/local/lib/libtdsodbc.a /home/tworman/local/lib/libtdsodbc.a: archive (big format) This is from the .so I generated with gcc. bash-4.2$ file libtdsodbc.so libtdsodbc.so: executable (RISC System/6000) or object module not stripped bash-4.2$ bsqldb Could not load program bsqldb: Dependent module ../dblib/.libs/libsybdb.a(libsybdb.so.5) could not be loaded. Could not load module ../dblib/.libs/libsybdb.a(libsybdb.so.5). System error: No such file or directory I don't understand why it's looking where it is for the file. That is in the bin directory under my local install path. No dblib folder exists below that. The libsysdb.a file is located in ../lib/ Tried bsqlodbc but it gives the same issue as osql/isql does. bsqlodbc gives the same: bsqlodbc: error -1: SQLConnect: SQL_ERROR: failed "[unixODBC][Driver Manager]Driver's SQLAllocHandle on SQL_HANDLE_HENV failed" Thank you for the response. I really appreciate the help! Going to try Frediano's advice and see if I can't get a full set of 64 bit builds working. Maybe I'll have slight better luck vs the 32 bit libraries. Results from 32bit DBLib unit tests and the configure are below. - Tyler Dblib unit tests. env CFLAGS="-I/usr/local/include" AR_FLAGS="cru" ARFLAGS="cru" LD_LIBRARY_PATH=/usr/local/lib/ ./configure --with-unixodbc=/usr/local/ --prefix=/home/tworman/local --with-tdsver=7.0 make Then the test results: PASS: t0001 PASS: t0002 PASS: t0003 PASS: t0004 FAIL: t0005 PASS: t0006 PASS: t0007 PASS: t0008 PASS: t0009 PASS: t0011 PASS: t0012 FAIL: t0013 FAIL: t0014 PASS: t0015 PASS: t0016 PASS: t0017 PASS: t0018 PASS: t0019 PASS: t0020 PASS: t0021 FAIL: t0022 FAIL: t0023 FAIL: rpc FAIL: dbmorecmds FAIL: bcp FAIL: thread PASS: text_buffer PASS: done_handling PASS: timeout FAIL: hang PASS: null PASS: null2 PASS: setnull FAIL: numeric PASS: pending ============================================================================ Testsuite summary for FreeTDS 0.95.19 ============================================================================ # TOTAL: 35 # PASS: 24 # SKIP: 0 # XFAIL: 0 # FAIL: 11 # XPASS: 0 # ERROR: 0 ============================================================================ See src/dblib/unittests/test-suite.log ============================================================================ make: The error code from the last command is 1 Stop. make: The error code from the last command is 2. Stop. make: The error code from the last command is 2. Stop. Most of the failures in the test suite were a result of lack of permissions for the account I have to create tables/procedures in certain areas. Output of the configure above: checking for a BSD-compatible install... ./install-sh -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... ./install-sh -c -d checking for gawk... no checking for mawk... no checking for nawk... nawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking whether make supports nested variables... (cached) yes checking for gawk... (cached) nawk checking for grep that handles long lines and -e... /usr/bin/grep checking whether ln -s works... yes checking for ranlib... ranlib checking for a sed that does not truncate output... /usr/bin/sed checking build system type... powerpc-ibm-aix7.1.0.0 checking host system type... powerpc-ibm-aix7.1.0.0 checking for style of include used by make... GNU checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking whether gcc understands -c and -o together... yes checking dependency style of gcc... gcc3 checking how to run the C preprocessor... gcc -E checking for egrep... /usr/bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking minix/config.h usability... no checking minix/config.h presence... no checking for minix/config.h... no checking whether it is safe to define __EXTENSIONS__... yes checking for special C compiler options needed for large files... no checking for _FILE_OFFSET_BITS value needed for large files... unknown checking for _LARGE_FILES value needed for large files... 1 checking for gcc... (cached) gcc checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ISO C89... (cached) none needed checking whether gcc understands -c and -o together... (cached) yes checking dependency style of gcc... (cached) gcc3 checking how to run the C preprocessor... gcc -E checking for inline... inline checking how to print strings... print -r checking for a sed that does not truncate output... (cached) /usr/bin/sed checking for fgrep... /usr/bin/grep -F checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm -B) interface... BSD nm checking the maximum length of command line arguments... 786432 checking whether the shell understands some XSI constructs... yes checking whether the shell understands "+="... no checking how to convert powerpc-ibm-aix7.1.0.0 file names to powerpc-ibm-aix7.1.0.0 format... func_convert_file_noop checking how to convert powerpc-ibm-aix7.1.0.0 file names to toolchain format... func_convert_file_noop checking for /usr/bin/ld option to reload object files... -r checking for objdump... objdump checking how to recognize dependent libraries... pass_all checking for dlltool... dlltool checking how to associate runtime and link libraries... print -r -- checking for ar... ar checking for archiver @FILE support... no checking for strip... strip checking for ranlib... (cached) ranlib checking command to parse /usr/bin/nm -B output from gcc object... ok checking for sysroot... no checking for mt... mt checking if mt is a manifest tool... no checking for dlfcn.h... yes checking for objdir... .libs checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -DPIC checking if gcc PIC flag -DPIC works... yes checking if gcc static flag -static works... no checking if gcc supports -c -o file.o... yes checking if gcc supports -c -o file.o... (cached) yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... aix7.1.0.0 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... no checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for library containing dlopen... none required checking for dlerror... yes checking for shl_load... no checking for shl_load in -ldld... no checking for dld_link in -ldld... no checking for windres... no checking for ld used by GCC... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking for shared library run path origin... done checking for iconv... yes checking how to link with libiconv... /home/tworman/local/lib/libiconv.a checking for iconv declaration... extern size_t iconv (iconv_t cd, char * *inbuf, size_t *inbytesleft, char * *outbuf, size_t *outbytesleft); checking for doxygen... no checking for odbc_config... odbc_config checking for pkg-config... no checking for library containing socket... none required checking for library containing gethostbyname... none required checking for library containing tgetent... -lcurses checking for readline in -lreadline... yes checking for rl_on_new_line... yes checking for rl_reset_line_state... yes checking for the pthreads library -lpthreads... yes checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE checking if more special flags are required for pthreads... -D_THREAD_SAFE checking for library containing pthread_condattr_setclock... none required checking for pthread_condattr_setclock... yes checking for ANSI C header files... (cached) yes checking whether time.h and sys/time.h may both be included... yes checking whether struct tm is in sys/time.h or time.h... time.h checking for struct tm.tm_zone... no checking whether tzname is declared... yes checking for tzname... yes checking for struct tm.__tm_zone... no checking errno.h usability... yes checking errno.h presence... yes checking for errno.h... yes checking libgen.h usability... yes checking libgen.h presence... yes checking for libgen.h... yes checking limits.h usability... yes checking limits.h presence... yes checking for limits.h... yes checking locale.h usability... yes checking locale.h presence... yes checking for locale.h... yes checking poll.h usability... yes checking poll.h presence... yes checking for poll.h... yes checking readpassphrase.h usability... no checking readpassphrase.h presence... no checking for readpassphrase.h... no checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking stddef.h usability... yes checking stddef.h presence... yes checking for stddef.h... yes checking sys/param.h usability... yes checking sys/param.h presence... yes checking for sys/param.h... yes checking sys/select.h usability... yes checking sys/select.h presence... yes checking for sys/select.h... yes checking for sys/stat.h... (cached) yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking for sys/types.h... (cached) yes checking sys/resource.h usability... yes checking sys/resource.h presence... yes checking for sys/resource.h... yes checking sys/wait.h usability... yes checking sys/wait.h presence... yes checking for sys/wait.h... yes checking for unistd.h... (cached) yes checking netdb.h usability... yes checking netdb.h presence... yes checking for netdb.h... yes checking wchar.h usability... yes checking wchar.h presence... yes checking for wchar.h... yes checking for inttypes.h... (cached) yes checking winsock2.h usability... no checking winsock2.h presence... no checking for winsock2.h... no checking localcharset.h usability... yes checking localcharset.h presence... yes checking for localcharset.h... yes checking valgrind/memcheck.h usability... no checking valgrind/memcheck.h presence... no checking for valgrind/memcheck.h... no checking malloc.h usability... yes checking malloc.h presence... yes checking for malloc.h... yes checking dirent.h usability... yes checking dirent.h presence... yes checking for dirent.h... yes checking for windows.h... no checking for sql.h... yes checking for odbcss.h... yes checking arpa/inet.h usability... yes checking arpa/inet.h presence... yes checking for arpa/inet.h... yes checking langinfo.h usability... yes checking langinfo.h presence... yes checking for langinfo.h... yes checking for netdb.h... (cached) yes checking netinet/in.h usability... yes checking netinet/in.h presence... yes checking for netinet/in.h... yes checking netinet/tcp.h usability... yes checking netinet/tcp.h presence... yes checking for netinet/tcp.h... yes checking roken.h usability... no checking roken.h presence... no checking for roken.h... no checking com_err.h usability... no checking com_err.h presence... no checking for com_err.h... no checking paths.h usability... yes checking paths.h presence... yes checking for paths.h... yes checking sys/ioctl.h usability... yes checking sys/ioctl.h presence... yes checking for sys/ioctl.h... yes checking sys/socket.h usability... yes checking sys/socket.h presence... yes checking for sys/socket.h... yes checking whether INADDR_NONE is defined... yes checking size of char... 1 checking size of short... 2 checking size of long... 4 checking size of int... 4 checking size of float... 4 checking size of double... 8 checking size of long double... 16 checking size of long long... 8 checking size of __int64... 0 checking size of void *... 4 checking size of wchar_t... 2 checking is FIONBIO defined... yes checking for socklen_t... yes checking whether getopt has optreset support... no checking whether byte ordering is bigendian... yes checking for an ANSI C-conforming const... yes checking whether we can use -static-libgcc... sed: Cannot find or open file conftest.c. no checking whether we can use -Wl,-static-libgcc... sed: Cannot find or open file conftest.c. no checking whether memset(0) sets pointers to NULL... yes checking for _atoi64... no checking for vsnprintf... yes checking for _vsnprintf... no checking for _vscprintf... no checking for gettimeofday... yes checking for nl_langinfo... yes checking for locale_charset... no checking for setenv... yes checking for putenv... yes checking for getuid... yes checking for getpwuid... yes checking for getpwuid_r... yes checking for fstat... yes checking for alarm... yes checking for fork... yes checking for gethrtime... no checking for localtime_r... yes checking for setitimer... yes checking for _lseeki64... no checking for _telli64... no checking for _fseeki64... no checking for _ftelli64... no checking for setrlimit... yes checking for pthread_cond_timedwait... yes checking for _lock_file... no checking for _unlock_file... no checking for usleep... yes checking for nanosleep... yes checking for readdir_r... yes checking for inet_ntoa_r... yes checking for getipnodebyaddr... yes checking for getipnodebyname... yes checking for getaddrinfo... yes checking for inet_ntop... yes checking for gethostname... yes checking for poll... yes checking for socketpair... yes checking for asprintf... no checking for vasprintf... no checking for strtok_r... yes checking for readpassphrase... no checking for strlcpy... no checking for strlcat... no checking for basename... yes checking for getopt... yes checking for strsep... yes checking for _LARGEFILE_SOURCE value needed for large files... no checking for library containing clock_gettime... none required checking if clock_gettime support CLOCK_MONOTONIC... yes checking whether malloc_options variable is present... no checking compile-time options looking for installed odbc driver manager checking for SQLGetPrivateProfileString in -lodbcinst... yes checking for SQLSETPOSIROW... yes checking for SQLROWSETSIZE... yes checking for SQLROWOFFSET... yes checking size of SQLWCHAR... 2 checking if openssl is wanted... no checking threadsafety... enabled checking for which type of gethostbyname_r... three checking for which type of getservbyname_r... four checking for which type of gethostbyaddr_r... five checking for which type of getpwuid_r... five checking for which type of localtime_r... struct configure: debug enabled checking CFLAGS for gcc -Wdeclaration-after-statement... -Wdeclaration-after-statement done checking that generated files are newer than configure... done configure: creating ./config.status config.status: creating include/freetds/version.h config.status: creating include/tds_sysdep_public.h config.status: creating Makefile config.status: creating include/Makefile config.status: creating include/freetds/Makefile config.status: creating doc/Makefile config.status: creating samples/Makefile config.status: creating src/Makefile config.status: creating src/tds/Makefile config.status: creating src/tds/unittests/Makefile config.status: creating src/dblib/Makefile config.status: creating src/dblib/unittests/Makefile config.status: creating src/ctlib/Makefile config.status: creating src/ctlib/unittests/Makefile config.status: creating src/replacements/Makefile config.status: creating src/replacements/unittests/Makefile config.status: creating src/server/Makefile config.status: creating src/pool/Makefile config.status: creating src/odbc/Makefile config.status: creating src/odbc/unittests/Makefile config.status: creating src/apps/Makefile config.status: creating src/apps/fisql/Makefile config.status: creating freetds.spec config.status: creating win32/Makefile config.status: creating win32/config.h config.status: creating win32/version.rc config.status: creating win32/freetds.nsh config.status: creating vms/Makefile config.status: creating doc/freebcp.1 config.status: creating doc/tsql.1 config.status: creating doc/osql.1 config.status: creating doc/bsqldb.1 config.status: creating doc/bsqlodbc.1 config.status: creating doc/defncopy.1 config.status: creating doc/datacopy.1 config.status: creating doc/fisql.1 config.status: creating doc/freetds.conf.5 config.status: creating include/config.h config.status: executing depfiles commands config.status: executing libtool commands -----Original Message----- From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of James K. Lowden Sent: Wednesday, September 16, 2015 6:32 PM To: freetds at lists.ibiblio.org Subject: Re: [freetds] FreeTDS build on AIX - No shared objects (.so) generated? On Tue, 15 Sep 2015 17:39:26 +0000 "Worman, Tyler" wrote: > Trying to build FreeTDS (stable .95.19) on AIX 7100-03-05-1524. > The .so files don't generate. Browsed online and tried a few suggested > fixes for similar problems but no luck so far. Generated my own .so > files from the .a that builds but it doesn't seem to work. > Any advice? If memory serves, .a in AIX *is* a dynamic library. I don't believe AIX follows the .so convention. If you're not sure, what does file(1) tell you? As Frediano said, tsql doesn't use the shared libraries. The simplest test is to run the unit tests for dblib, or run bsqldb. HTH. --jkl _______________________________________________ FreeTDS mailing list FreeTDS at lists.ibiblio.org http://lists.ibiblio.org/mailman/listinfo/freetds ********************************************************** Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues From tworman at med.umich.edu Thu Sep 17 00:23:59 2015 From: tworman at med.umich.edu (Worman, Tyler) Date: Thu, 17 Sep 2015 04:23:59 +0000 Subject: [freetds] FreeTDS build on AIX - No shared objects (.so) generated? In-Reply-To: References: Message-ID: Got it working....Out of curiosity after seeing the bsqldb error and playing with libtool, I poked around the file structure of the 32-bit build. In /home/tworman/freetds-0.95.19/src/odbc/.libs I found libtdsodbc.so.0 I copied this to /home/tworman/local/libs (where I installed to) as my .so file and now osql and isql work perfect. Thank you so much. Still unsure why that wasn't copied/linked on the make install like it did on linux. This proves to me though that my build of the .so from the .a file didn't work as planned. Next is to try the 64 bit build. - Tyler -----Original Message----- From: Worman, Tyler Sent: Thursday, September 17, 2015 12:10 AM To: 'jklowden at freetds.org'; freetds at lists.ibiblio.org Subject: RE: [freetds] FreeTDS build on AIX - No shared objects (.so) generated? I was curious about the .a too, so I tried to direct UnixODBC to use the .a as the driver file but no luck. Unfortunately I'm not terribly familiar with AIX and our admin has been swamped, so my time with him is limited for questioned about the shared objects. [01000][unixODBC][Driver Manager]Can't open lib '/home/tworman/local/lib/libtdsodbc.a' : file not found [ISQL]ERROR: Could not SQLConnect But the file is there.... bash-4.2$ file /home/tworman/local/lib/libtdsodbc.a /home/tworman/local/lib/libtdsodbc.a: archive (big format) This is from the .so I generated with gcc. bash-4.2$ file libtdsodbc.so libtdsodbc.so: executable (RISC System/6000) or object module not stripped bash-4.2$ bsqldb Could not load program bsqldb: Dependent module ../dblib/.libs/libsybdb.a(libsybdb.so.5) could not be loaded. Could not load module ../dblib/.libs/libsybdb.a(libsybdb.so.5). System error: No such file or directory I don't understand why it's looking where it is for the file. That is in the bin directory under my local install path. No dblib folder exists below that. The libsysdb.a file is located in ../lib/ Tried bsqlodbc but it gives the same issue as osql/isql does. bsqlodbc gives the same: bsqlodbc: error -1: SQLConnect: SQL_ERROR: failed "[unixODBC][Driver Manager]Driver's SQLAllocHandle on SQL_HANDLE_HENV failed" Thank you for the response. I really appreciate the help! Going to try Frediano's advice and see if I can't get a full set of 64 bit builds working. Maybe I'll have slight better luck vs the 32 bit libraries. Results from 32bit DBLib unit tests and the configure are below. - Tyler Dblib unit tests. env CFLAGS="-I/usr/local/include" AR_FLAGS="cru" ARFLAGS="cru" LD_LIBRARY_PATH=/usr/local/lib/ ./configure --with-unixodbc=/usr/local/ --prefix=/home/tworman/local --with-tdsver=7.0 make Then the test results: PASS: t0001 PASS: t0002 PASS: t0003 PASS: t0004 FAIL: t0005 PASS: t0006 PASS: t0007 PASS: t0008 PASS: t0009 PASS: t0011 PASS: t0012 FAIL: t0013 FAIL: t0014 PASS: t0015 PASS: t0016 PASS: t0017 PASS: t0018 PASS: t0019 PASS: t0020 PASS: t0021 FAIL: t0022 FAIL: t0023 FAIL: rpc FAIL: dbmorecmds FAIL: bcp FAIL: thread PASS: text_buffer PASS: done_handling PASS: timeout FAIL: hang PASS: null PASS: null2 PASS: setnull FAIL: numeric PASS: pending ============================================================================ Testsuite summary for FreeTDS 0.95.19 ============================================================================ # TOTAL: 35 # PASS: 24 # SKIP: 0 # XFAIL: 0 # FAIL: 11 # XPASS: 0 # ERROR: 0 ============================================================================ See src/dblib/unittests/test-suite.log ============================================================================ make: The error code from the last command is 1 Stop. make: The error code from the last command is 2. Stop. make: The error code from the last command is 2. Stop. Most of the failures in the test suite were a result of lack of permissions for the account I have to create tables/procedures in certain areas. Output of the configure above: checking for a BSD-compatible install... ./install-sh -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... ./install-sh -c -d checking for gawk... no checking for mawk... no checking for nawk... nawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking whether make supports nested variables... (cached) yes checking for gawk... (cached) nawk checking for grep that handles long lines and -e... /usr/bin/grep checking whether ln -s works... yes checking for ranlib... ranlib checking for a sed that does not truncate output... /usr/bin/sed checking build system type... powerpc-ibm-aix7.1.0.0 checking host system type... powerpc-ibm-aix7.1.0.0 checking for style of include used by make... GNU checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking whether gcc understands -c and -o together... yes checking dependency style of gcc... gcc3 checking how to run the C preprocessor... gcc -E checking for egrep... /usr/bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking minix/config.h usability... no checking minix/config.h presence... no checking for minix/config.h... no checking whether it is safe to define __EXTENSIONS__... yes checking for special C compiler options needed for large files... no checking for _FILE_OFFSET_BITS value needed for large files... unknown checking for _LARGE_FILES value needed for large files... 1 checking for gcc... (cached) gcc checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ISO C89... (cached) none needed checking whether gcc understands -c and -o together... (cached) yes checking dependency style of gcc... (cached) gcc3 checking how to run the C preprocessor... gcc -E checking for inline... inline checking how to print strings... print -r checking for a sed that does not truncate output... (cached) /usr/bin/sed checking for fgrep... /usr/bin/grep -F checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm -B) interface... BSD nm checking the maximum length of command line arguments... 786432 checking whether the shell understands some XSI constructs... yes checking whether the shell understands "+="... no checking how to convert powerpc-ibm-aix7.1.0.0 file names to powerpc-ibm-aix7.1.0.0 format... func_convert_file_noop checking how to convert powerpc-ibm-aix7.1.0.0 file names to toolchain format... func_convert_file_noop checking for /usr/bin/ld option to reload object files... -r checking for objdump... objdump checking how to recognize dependent libraries... pass_all checking for dlltool... dlltool checking how to associate runtime and link libraries... print -r -- checking for ar... ar checking for archiver @FILE support... no checking for strip... strip checking for ranlib... (cached) ranlib checking command to parse /usr/bin/nm -B output from gcc object... ok checking for sysroot... no checking for mt... mt checking if mt is a manifest tool... no checking for dlfcn.h... yes checking for objdir... .libs checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -DPIC checking if gcc PIC flag -DPIC works... yes checking if gcc static flag -static works... no checking if gcc supports -c -o file.o... yes checking if gcc supports -c -o file.o... (cached) yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... aix7.1.0.0 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... no checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for library containing dlopen... none required checking for dlerror... yes checking for shl_load... no checking for shl_load in -ldld... no checking for dld_link in -ldld... no checking for windres... no checking for ld used by GCC... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking for shared library run path origin... done checking for iconv... yes checking how to link with libiconv... /home/tworman/local/lib/libiconv.a checking for iconv declaration... extern size_t iconv (iconv_t cd, char * *inbuf, size_t *inbytesleft, char * *outbuf, size_t *outbytesleft); checking for doxygen... no checking for odbc_config... odbc_config checking for pkg-config... no checking for library containing socket... none required checking for library containing gethostbyname... none required checking for library containing tgetent... -lcurses checking for readline in -lreadline... yes checking for rl_on_new_line... yes checking for rl_reset_line_state... yes checking for the pthreads library -lpthreads... yes checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE checking if more special flags are required for pthreads... -D_THREAD_SAFE checking for library containing pthread_condattr_setclock... none required checking for pthread_condattr_setclock... yes checking for ANSI C header files... (cached) yes checking whether time.h and sys/time.h may both be included... yes checking whether struct tm is in sys/time.h or time.h... time.h checking for struct tm.tm_zone... no checking whether tzname is declared... yes checking for tzname... yes checking for struct tm.__tm_zone... no checking errno.h usability... yes checking errno.h presence... yes checking for errno.h... yes checking libgen.h usability... yes checking libgen.h presence... yes checking for libgen.h... yes checking limits.h usability... yes checking limits.h presence... yes checking for limits.h... yes checking locale.h usability... yes checking locale.h presence... yes checking for locale.h... yes checking poll.h usability... yes checking poll.h presence... yes checking for poll.h... yes checking readpassphrase.h usability... no checking readpassphrase.h presence... no checking for readpassphrase.h... no checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking stddef.h usability... yes checking stddef.h presence... yes checking for stddef.h... yes checking sys/param.h usability... yes checking sys/param.h presence... yes checking for sys/param.h... yes checking sys/select.h usability... yes checking sys/select.h presence... yes checking for sys/select.h... yes checking for sys/stat.h... (cached) yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking for sys/types.h... (cached) yes checking sys/resource.h usability... yes checking sys/resource.h presence... yes checking for sys/resource.h... yes checking sys/wait.h usability... yes checking sys/wait.h presence... yes checking for sys/wait.h... yes checking for unistd.h... (cached) yes checking netdb.h usability... yes checking netdb.h presence... yes checking for netdb.h... yes checking wchar.h usability... yes checking wchar.h presence... yes checking for wchar.h... yes checking for inttypes.h... (cached) yes checking winsock2.h usability... no checking winsock2.h presence... no checking for winsock2.h... no checking localcharset.h usability... yes checking localcharset.h presence... yes checking for localcharset.h... yes checking valgrind/memcheck.h usability... no checking valgrind/memcheck.h presence... no checking for valgrind/memcheck.h... no checking malloc.h usability... yes checking malloc.h presence... yes checking for malloc.h... yes checking dirent.h usability... yes checking dirent.h presence... yes checking for dirent.h... yes checking for windows.h... no checking for sql.h... yes checking for odbcss.h... yes checking arpa/inet.h usability... yes checking arpa/inet.h presence... yes checking for arpa/inet.h... yes checking langinfo.h usability... yes checking langinfo.h presence... yes checking for langinfo.h... yes checking for netdb.h... (cached) yes checking netinet/in.h usability... yes checking netinet/in.h presence... yes checking for netinet/in.h... yes checking netinet/tcp.h usability... yes checking netinet/tcp.h presence... yes checking for netinet/tcp.h... yes checking roken.h usability... no checking roken.h presence... no checking for roken.h... no checking com_err.h usability... no checking com_err.h presence... no checking for com_err.h... no checking paths.h usability... yes checking paths.h presence... yes checking for paths.h... yes checking sys/ioctl.h usability... yes checking sys/ioctl.h presence... yes checking for sys/ioctl.h... yes checking sys/socket.h usability... yes checking sys/socket.h presence... yes checking for sys/socket.h... yes checking whether INADDR_NONE is defined... yes checking size of char... 1 checking size of short... 2 checking size of long... 4 checking size of int... 4 checking size of float... 4 checking size of double... 8 checking size of long double... 16 checking size of long long... 8 checking size of __int64... 0 checking size of void *... 4 checking size of wchar_t... 2 checking is FIONBIO defined... yes checking for socklen_t... yes checking whether getopt has optreset support... no checking whether byte ordering is bigendian... yes checking for an ANSI C-conforming const... yes checking whether we can use -static-libgcc... sed: Cannot find or open file conftest.c. no checking whether we can use -Wl,-static-libgcc... sed: Cannot find or open file conftest.c. no checking whether memset(0) sets pointers to NULL... yes checking for _atoi64... no checking for vsnprintf... yes checking for _vsnprintf... no checking for _vscprintf... no checking for gettimeofday... yes checking for nl_langinfo... yes checking for locale_charset... no checking for setenv... yes checking for putenv... yes checking for getuid... yes checking for getpwuid... yes checking for getpwuid_r... yes checking for fstat... yes checking for alarm... yes checking for fork... yes checking for gethrtime... no checking for localtime_r... yes checking for setitimer... yes checking for _lseeki64... no checking for _telli64... no checking for _fseeki64... no checking for _ftelli64... no checking for setrlimit... yes checking for pthread_cond_timedwait... yes checking for _lock_file... no checking for _unlock_file... no checking for usleep... yes checking for nanosleep... yes checking for readdir_r... yes checking for inet_ntoa_r... yes checking for getipnodebyaddr... yes checking for getipnodebyname... yes checking for getaddrinfo... yes checking for inet_ntop... yes checking for gethostname... yes checking for poll... yes checking for socketpair... yes checking for asprintf... no checking for vasprintf... no checking for strtok_r... yes checking for readpassphrase... no checking for strlcpy... no checking for strlcat... no checking for basename... yes checking for getopt... yes checking for strsep... yes checking for _LARGEFILE_SOURCE value needed for large files... no checking for library containing clock_gettime... none required checking if clock_gettime support CLOCK_MONOTONIC... yes checking whether malloc_options variable is present... no checking compile-time options looking for installed odbc driver manager checking for SQLGetPrivateProfileString in -lodbcinst... yes checking for SQLSETPOSIROW... yes checking for SQLROWSETSIZE... yes checking for SQLROWOFFSET... yes checking size of SQLWCHAR... 2 checking if openssl is wanted... no checking threadsafety... enabled checking for which type of gethostbyname_r... three checking for which type of getservbyname_r... four checking for which type of gethostbyaddr_r... five checking for which type of getpwuid_r... five checking for which type of localtime_r... struct configure: debug enabled checking CFLAGS for gcc -Wdeclaration-after-statement... -Wdeclaration-after-statement done checking that generated files are newer than configure... done configure: creating ./config.status config.status: creating include/freetds/version.h config.status: creating include/tds_sysdep_public.h config.status: creating Makefile config.status: creating include/Makefile config.status: creating include/freetds/Makefile config.status: creating doc/Makefile config.status: creating samples/Makefile config.status: creating src/Makefile config.status: creating src/tds/Makefile config.status: creating src/tds/unittests/Makefile config.status: creating src/dblib/Makefile config.status: creating src/dblib/unittests/Makefile config.status: creating src/ctlib/Makefile config.status: creating src/ctlib/unittests/Makefile config.status: creating src/replacements/Makefile config.status: creating src/replacements/unittests/Makefile config.status: creating src/server/Makefile config.status: creating src/pool/Makefile config.status: creating src/odbc/Makefile config.status: creating src/odbc/unittests/Makefile config.status: creating src/apps/Makefile config.status: creating src/apps/fisql/Makefile config.status: creating freetds.spec config.status: creating win32/Makefile config.status: creating win32/config.h config.status: creating win32/version.rc config.status: creating win32/freetds.nsh config.status: creating vms/Makefile config.status: creating doc/freebcp.1 config.status: creating doc/tsql.1 config.status: creating doc/osql.1 config.status: creating doc/bsqldb.1 config.status: creating doc/bsqlodbc.1 config.status: creating doc/defncopy.1 config.status: creating doc/datacopy.1 config.status: creating doc/fisql.1 config.status: creating doc/freetds.conf.5 config.status: creating include/config.h config.status: executing depfiles commands config.status: executing libtool commands -----Original Message----- From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of James K. Lowden Sent: Wednesday, September 16, 2015 6:32 PM To: freetds at lists.ibiblio.org Subject: Re: [freetds] FreeTDS build on AIX - No shared objects (.so) generated? On Tue, 15 Sep 2015 17:39:26 +0000 "Worman, Tyler" wrote: > Trying to build FreeTDS (stable .95.19) on AIX 7100-03-05-1524. > The .so files don't generate. Browsed online and tried a few suggested > fixes for similar problems but no luck so far. Generated my own .so > files from the .a that builds but it doesn't seem to work. > Any advice? If memory serves, .a in AIX *is* a dynamic library. I don't believe AIX follows the .so convention. If you're not sure, what does file(1) tell you? As Frediano said, tsql doesn't use the shared libraries. The simplest test is to run the unit tests for dblib, or run bsqldb. HTH. --jkl _______________________________________________ FreeTDS mailing list FreeTDS at lists.ibiblio.org http://lists.ibiblio.org/mailman/listinfo/freetds ********************************************************** Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues From no-reply at appveyor.com Fri Sep 18 10:12:18 2015 From: no-reply at appveyor.com (AppVeyor) Date: Fri, 18 Sep 2015 14:12:18 +0000 Subject: [freetds] Build completed: freetds 185 Message-ID: <20150918141217.3654.10976@appveyor.com> From freddy77 at gmail.com Fri Sep 18 14:46:11 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Fri, 18 Sep 2015 19:46:11 +0100 Subject: [freetds] Sybase DATE and TIME data types In-Reply-To: References: <55F54D96.7070208@datamartcomputing.com> <2363cb4fab47e3fd5f20a3f2b0d3bd0c@datamartcomputing.com> Message-ID: Should work now. Was a problem with datacopy not with date/time patches Il 15/Set/2015 14:33, ha scritto: > Hi Frediano, > > I downloaded the latest release (freetds-dev.0.99.297) but it fails with: > > datacopy -t -p32768 -v -S SOURECE/USER/PW/DBdate_time_source -D > DESTINATION/USER/PW/DB/date_time_destination -E -T200000 > Error in dbnumcols > datacopy: table structures do not match. terminating > My working version still works and looks like: > Starting copy... > > rows read : 5 > rows written : 5 > elapsed time (secs) : 0.002556 > rows per second : 1956.181534 > > I just wan,ted to check that I'd got the right version before I start > investigating what's missing. > > Thanks, > > Matthew. > > PS. Here's the SQL I use to test (as well as a visual check): > > if exists (select 1 from sysobjects where name = "date_time_source" and > type = "U") > drop table date_time_source > go > if exists (select 1 from sysobjects where name = "date_time_destination" > and type = "U") > drop table date_time_destination > go > > create table date_time_source ( > dt_i int not > null , > dt_d datetime not > null , > dt_dt date not > null , > dt_t time not > null , > dt_i2 int > null , > dt_dt2 date > null , > dt_t2 time > null > ) > > create table date_time_destination ( > dt_i int not > null , > dt_d datetime not > null , > dt_dt date not > null , > dt_t time not > null , > dt_i2 int > null , > dt_dt2 date > null , > dt_t2 time > null > ) > go > INSERT INTO date_time_source select 1,'1970-06-13 > 11:15:23.223','1970-06-13','10:15:23',2,'1950-12-10','05:15:12' > INSERT INTO date_time_source select 2,'1980-08-15 > 12:15:23.009','1970-06-15','12:15:23',3,'1965-02-20',NULL > INSERT INTO date_time_source select 3,'1981-10-30 > 02:05:25.123','1966-01-01','07:11:17',4,NULL,'15:00:12:123' > INSERT INTO date_time_source select 3,'1977-11-05 > 19:17:03.003','1960-02-14','07:11:17',4,NULL,NULL > INSERT INTO date_time_source select 1,'2012-01-13 > 11:15:23.223','2030-03-25','21:35:23:176',2,'1958-10-17','09:05:50:840' > go > -- Pause here and run datacopy. Don't forget you will need select/into > turned on in the target database. > > declare @source_rows int, > @destination_rows int, > @unique_rows int, > @message varchar(2000) > > select @source_rows = count(*) from date_time_source > select @destination_rows = count(*) from date_time_destination > > select dt_i, dt_d, dt_dt, dt_t, dt_i2, dt_dt2 , dt_t2 from date_time_source > union > select dt_i, dt_d, dt_dt, dt_t, dt_i2, dt_dt2 , dt_t2 from > date_time_destination > > select @unique_rows = @@rowcount > > if @unique_rows != @source_rows > select @message = "ERROR: "+convert(varchar, at source_rows)+" source > rows resulted in "+convert(varchar, at unique_rows)+" unqiue rows." > else if @destination_rows != @source_rows > select @message = "ERROR: "+convert(varchar, at source_rows)+" source > rows resulted in "+convert(varchar, at destination_rows)+" destination rows." > > if @message is null > print "TEST PASSED." > else > print "TEST FAILED" > > print @message > go > > September 14 2015 2:37 PM, "Frediano Ziglio" wrote:The change for > tds_types.h is not necessary, the invalid constant is > actually 0. Also tds_types.h is auto generated from misc/types.cvs. > The change in include/sybdb.h is also in my patches to support these > types (with new bindings) in dblib. > > So... please grab the last snapshot and try again, should work! > > Actually there is no automatic tests for freebcp and datacopy (but the > base functions they use are tested). > > Frediano > > 2015-09-14 13:13 GMT+01:00 : > Hi Frediano, > > Yes, a diff is the thing to do :-) I've got access again so I ran it and > the results are (I > removedreferences to compiled objects and documentation): > > diff -r ../compare/freetds-dev.0.99.220/include/sybdb.h ./include/sybdb.h > diff -r ../compare/freetds-dev.0.99.220/include/freetds/convert.h > ./include/freetds/convert.h > diff -r ../compare/freetds-dev.0.99.220/include/freetds/proto.h > ./include/freetds/proto.h > diff -r ../compare/freetds-dev.0.99.220/src/apps/datacopy.c > ./src/apps/datacopy.c > diff -r ../compare/freetds-dev.0.99.220/src/tds/convert.c > ./src/tds/convert.c > diff -r ../compare/freetds-dev.0.99.220/src/tds/mem.c ./src/tds/mem.c > diff -r ../compare/freetds-dev.0.99.220/src/tds/query.c ./src/tds/query.c > diff -r ../compare/freetds-dev.0.99.220/src/tds/tds_types.h > ./src/tds/tds_types.h > > So, I'd missed two files (in bold) which have now been updated in my > attached document. > > It's still working for me :-) > > Cheers, > > Matthew. > September 14 2015 10:46 AM, "Frediano Ziglio" wrote:Thanks, > did patches yesterday. See > > https://github.com/FreeTDS/freetds/commit/235019b7342cea9bd200e7a7b00bb1bc26e37096 > ( > https://github.com/FreeTDS/freetds/commit/235019b7342cea9bd200e7a7b00bb1bc26e37096 > ) > ( > https://github.com/FreeTDS/freetds/commit/235019b7342cea9bd200e7a7b00bb1bc26e37096 > ( > https://github.com/FreeTDS/freetds/commit/235019b7342cea9bd200e7a7b00bb1bc26e37096 > )) > and > https://github.com/FreeTDS/freetds/commit/526c035f66cc297943690fd4096444921a764206 > ( > https://github.com/FreeTDS/freetds/commit/526c035f66cc297943690fd4096444921a764206 > ) > ( > https://github.com/FreeTDS/freetds/commit/526c035f66cc297943690fd4096444921a764206 > ( > https://github.com/FreeTDS/freetds/commit/526c035f66cc297943690fd4096444921a764206) > ). > > Is not easier to do a diff? > > Currently only ODBC is missing to the list. > > Frediano > > 2015-09-14 9:19 GMT+01:00 : > I've found one file I modified which wasn't in my document... sorry about > that. > > The change is to include/sybdb.h, around line 154: > > enum > { > SYBCHAR = 47, /* 0x2F */ > #define SYBCHAR SYBCHAR > SYBVARCHAR = 39, /* 0x27 */ > #define SYBVARCHAR SYBVARCHAR > SYBINTN = 38, /* 0x26 */ > #define SYBINTN SYBINTN > SYBINT1 = 48, /* 0x30 */ > #define SYBINT1 SYBINT1 > SYBINT2 = 52, /* 0x34 */ > #define SYBINT2 SYBINT2 > SYBINT4 = 56, /* 0x38 */ > #define SYBINT4 SYBINT4 > SYBINT8 = 127, /* 0x7F */ > #define SYBINT8 SYBINT8 > SYBFLT8 = 62, /* 0x3E */ > #define SYBFLT8 SYBFLT8 > SYBDATETIME = 61, /* 0x3D */ > #define SYBDATETIME SYBDATETIME > SYBDATE = 49, /* 0x31 */ > #define SYBDATE SYBDATE > SYBTIME = 51, /* 0x33 */ > #define SYBTIME SYBTIME > SYBBIT = 50, /* 0x32 */ > #define SYBBIT SYBBIT > SYBBITN = 104, /* 0x68 */ > > I'll keep looking in case there's anything else..... > > Cheers, > > Matthew. > September 13 2015 12:19 PM, "Matthew" wrote:Thanks for the kind words. It > seems I must have > missedsomething as > datacopy is working for me when copying DATE and TIME columns from ASE > 15.7 to ASE 15.7. > > A lot of what I did was trial and error and I tried to remember to leave > a comment so I could find what I'd changed in order to write it up at > the end. > > Any idea which file I would have changed to get it working with dblib? > If not I'll untar the package somewhere else and run a find and diff to > see if I can spot it. > > Cheers, > > Matthew. > > On 13/09/15 11:55, Frediano Ziglio wrote: > 2015-09-11 10:04 GMT+01:00 :Dear All, > > I'm not really a C programmer (or C++ for that matter) but I wanted to be > able to use datacopy > tocopy tables with DATE and TIME data types. So, I decided to have a crack > at adding them to > FreeTDS.My testing has been successful, although I'm not sure the way I've > coded it is correct so > any > help/fixes would be appreciated. > > I've attached a rich text document with the details. The first part > proposes a quick and dirty > fix,while the second is my best guess at the "correct" way of doing things. > > Bare in mind that this is currently only for Sybase to Sybase. I'm going > to look at doing this > forSQL Server too but that's a bit more complicated! > > Cheers, > > Matthew. > > Patch and effort are really appreciated. > So appreciated that I already pushed some changes and is actually > testing deeply (but I don't think there will be any regression). > > datacopy still does not work as SYBDATE/SYBTIME are not supported by > dblib (you added support for libTDS not upper libraries and datacopy > is based on dblib). > > Currently converting from string will use datetime format in all > cases. ODBC has its standard so format strings are well defined for > it. > > I added some improvements too based on previously patches on some other > types. > > Yes, adding a new type in FreeTDS is really a nightmare !!! > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org (mailto:FreeTDS at lists.ibiblio.org) (mailto: > FreeTDS at lists.ibiblio.org (mailto:mailto:FreeTDS at lists.ibiblio.org)) > (mailto:FreeTDS at lists.ibiblio.org (mailto:mailto:FreeTDS at lists.ibiblio.org > ) > (mailto:mailto:FreeTDS at lists.ibiblio.org (mailto:mailto:mailto: > FreeTDS at lists.ibiblio.org))) > http://lists.ibiblio.org/mailman/listinfo/freetds ( > http://lists.ibiblio.org/mailman/listinfo/freetds) > (http://lists.ibiblio.org/mailman/listinfo/freetds ( > http://lists.ibiblio.org/mailman/listinfo/freetds)) > (http://lists.ibiblio.org/mailman/listinfo/freetds ( > http://lists.ibiblio.org/mailman/listinfo/freetds) > (http://lists.ibiblio.org/mailman/listinfo/freetds) ( > http://lists.ibiblio.org/mailman/listinfo/freetds))) > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org (mailto:FreeTDS at lists.ibiblio.org) (mailto: > FreeTDS at lists.ibiblio.org (mailto:mailto:FreeTDS at lists.ibiblio.org)) > http://lists.ibiblio.org/mailman/listinfo/freetds ( > http://lists.ibiblio.org/mailman/listinfo/freetds) > (http://lists.ibiblio.org/mailman/listinfo/freetds ( > http://lists.ibiblio.org/mailman/listinfo/freetds)) > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org (mailto:FreeTDS at lists.ibiblio.org) (mailto: > FreeTDS at lists.ibiblio.org (mailto:mailto:FreeTDS at lists.ibiblio.org)) > http://lists.ibiblio.org/mailman/listinfo/freetds ( > http://lists.ibiblio.org/mailman/listinfo/freetds) > (http://lists.ibiblio.org/mailman/listinfo/freetds ( > http://lists.ibiblio.org/mailman/listinfo/freetds)) > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org (mailto:FreeTDS at lists.ibiblio.org) > http://lists.ibiblio.org/mailman/listinfo/freetds ( > http://lists.ibiblio.org/mailman/listinfo/freetds) > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org (mailto:FreeTDS at lists.ibiblio.org) > http://lists.ibiblio.org/mailman/listinfo/freetds ( > http://lists.ibiblio.org/mailman/listinfo/freetds) > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > From james.k.lowden at icloud.com Fri Sep 18 22:47:49 2015 From: james.k.lowden at icloud.com (James K. Lowden) Date: Fri, 18 Sep 2015 22:47:49 -0400 Subject: [freetds] FreeTDS build on AIX - No shared objects (.so) generated? In-Reply-To: References: Message-ID: <20150918224749.5060e11c.james.k.lowden@icloud.com> On Thu, 17 Sep 2015 04:23:59 +0000 "Worman, Tyler" wrote: > I copied this to /home/tworman/local/libs (where I installed to) as > my .so file and now osql and isql work perfect. Thank you so much. Not at all, you did the work. :-) > Still unsure why that wasn't copied/linked on the make install like > it did on linux. Looks to me like an autoconf error on AIX. Perhaps maybe it could be we're using an old version of autoconf, one that expects .a to be a dynamic library. Or something in that vicinity. The linker emitted a .so, but the install script wasn't looking for one. > This proves to me though that my build of the .so from the .a file > didn't work as planned. Yeah, you would have had to have been lucky with that one. Can be done, of course, but not usually on the first try. --jkl From no-reply at appveyor.com Sat Sep 19 11:04:25 2015 From: no-reply at appveyor.com (AppVeyor) Date: Sat, 19 Sep 2015 15:04:25 +0000 Subject: [freetds] Build failed: freetds 193 Message-ID: <20150919150425.11690.24623@appveyor.com> From no-reply at appveyor.com Sat Sep 19 11:18:59 2015 From: no-reply at appveyor.com (AppVeyor) Date: Sat, 19 Sep 2015 15:18:59 +0000 Subject: [freetds] Build failed: freetds 197 Message-ID: <20150919151859.11686.37272@appveyor.com> From no-reply at appveyor.com Sat Sep 19 12:28:25 2015 From: no-reply at appveyor.com (AppVeyor) Date: Sat, 19 Sep 2015 16:28:25 +0000 Subject: [freetds] Build failed: freetds 202 Message-ID: <20150919162825.3660.27340@appveyor.com> From no-reply at appveyor.com Sat Sep 19 13:00:52 2015 From: no-reply at appveyor.com (AppVeyor) Date: Sat, 19 Sep 2015 17:00:52 +0000 Subject: [freetds] Build completed: freetds 203 Message-ID: <20150919170051.3662.19446@appveyor.com> From no-reply at appveyor.com Mon Sep 21 00:48:21 2015 From: no-reply at appveyor.com (AppVeyor) Date: Mon, 21 Sep 2015 04:48:21 +0000 Subject: [freetds] Build failed: freetds 209 Message-ID: <20150921044821.11696.54895@appveyor.com> From no-reply at appveyor.com Mon Sep 21 01:34:18 2015 From: no-reply at appveyor.com (AppVeyor) Date: Mon, 21 Sep 2015 05:34:18 +0000 Subject: [freetds] Build completed: freetds 210 Message-ID: <20150921053418.98364.33473@appveyor.com> From matthew.green at datamartcomputing.com Mon Sep 21 13:43:26 2015 From: matthew.green at datamartcomputing.com (Matthew) Date: Mon, 21 Sep 2015 19:43:26 +0200 Subject: [freetds] Sybase DATE and TIME data types In-Reply-To: References: <55F54D96.7070208@datamartcomputing.com> <2363cb4fab47e3fd5f20a3f2b0d3bd0c@datamartcomputing.com> Message-ID: <560041BE.8080903@datamartcomputing.com> I took last night's build and it worked well and passed my tests!!!! Thanks Frediano. Next step is MS SQL Server but that'll be more complicated as "set fmtonly" is deprecated and doesn't show DATEs and TIMEs. Still, I'll give it a go. Cheers, Matthew. On 18/09/15 20:46, Frediano Ziglio wrote: > Should work now. Was a problem with datacopy not with date/time patches > Il 15/Set/2015 14:33, ha scritto: > >> Hi Frediano, >> >> I downloaded the latest release (freetds-dev.0.99.297) but it fails with: >> >> datacopy -t -p32768 -v -S SOURECE/USER/PW/DBdate_time_source -D >> DESTINATION/USER/PW/DB/date_time_destination -E -T200000 >> Error in dbnumcols >> datacopy: table structures do not match. terminating >> My working version still works and looks like: >> Starting copy... >> >> rows read : 5 >> rows written : 5 >> elapsed time (secs) : 0.002556 >> rows per second : 1956.181534 >> >> I just wan,ted to check that I'd got the right version before I start >> investigating what's missing. >> >> Thanks, >> >> Matthew. >> >> PS. Here's the SQL I use to test (as well as a visual check): >> >> if exists (select 1 from sysobjects where name = "date_time_source" and >> type = "U") >> drop table date_time_source >> go >> if exists (select 1 from sysobjects where name = "date_time_destination" >> and type = "U") >> drop table date_time_destination >> go >> >> create table date_time_source ( >> dt_i int not >> null , >> dt_d datetime not >> null , >> dt_dt date not >> null , >> dt_t time not >> null , >> dt_i2 int >> null , >> dt_dt2 date >> null , >> dt_t2 time >> null >> ) >> >> create table date_time_destination ( >> dt_i int not >> null , >> dt_d datetime not >> null , >> dt_dt date not >> null , >> dt_t time not >> null , >> dt_i2 int >> null , >> dt_dt2 date >> null , >> dt_t2 time >> null >> ) >> go >> INSERT INTO date_time_source select 1,'1970-06-13 >> 11:15:23.223','1970-06-13','10:15:23',2,'1950-12-10','05:15:12' >> INSERT INTO date_time_source select 2,'1980-08-15 >> 12:15:23.009','1970-06-15','12:15:23',3,'1965-02-20',NULL >> INSERT INTO date_time_source select 3,'1981-10-30 >> 02:05:25.123','1966-01-01','07:11:17',4,NULL,'15:00:12:123' >> INSERT INTO date_time_source select 3,'1977-11-05 >> 19:17:03.003','1960-02-14','07:11:17',4,NULL,NULL >> INSERT INTO date_time_source select 1,'2012-01-13 >> 11:15:23.223','2030-03-25','21:35:23:176',2,'1958-10-17','09:05:50:840' >> go >> -- Pause here and run datacopy. Don't forget you will need select/into >> turned on in the target database. >> >> declare @source_rows int, >> @destination_rows int, >> @unique_rows int, >> @message varchar(2000) >> >> select @source_rows = count(*) from date_time_source >> select @destination_rows = count(*) from date_time_destination >> >> select dt_i, dt_d, dt_dt, dt_t, dt_i2, dt_dt2 , dt_t2 from date_time_source >> union >> select dt_i, dt_d, dt_dt, dt_t, dt_i2, dt_dt2 , dt_t2 from >> date_time_destination >> >> select @unique_rows = @@rowcount >> >> if @unique_rows != @source_rows >> select @message = "ERROR: "+convert(varchar, at source_rows)+" source >> rows resulted in "+convert(varchar, at unique_rows)+" unqiue rows." >> else if @destination_rows != @source_rows >> select @message = "ERROR: "+convert(varchar, at source_rows)+" source >> rows resulted in "+convert(varchar, at destination_rows)+" destination rows." >> >> if @message is null >> print "TEST PASSED." >> else >> print "TEST FAILED" >> >> print @message >> go >> >> September 14 2015 2:37 PM, "Frediano Ziglio" wrote:The change for >> tds_types.h is not necessary, the invalid constant is >> actually 0. Also tds_types.h is auto generated from misc/types.cvs. >> The change in include/sybdb.h is also in my patches to support these >> types (with new bindings) in dblib. >> >> So... please grab the last snapshot and try again, should work! >> >> Actually there is no automatic tests for freebcp and datacopy (but the >> base functions they use are tested). >> >> Frediano >> >> 2015-09-14 13:13 GMT+01:00 : >> Hi Frediano, >> >> Yes, a diff is the thing to do :-) I've got access again so I ran it and >> the results are (I >> removedreferences to compiled objects and documentation): >> >> diff -r ../compare/freetds-dev.0.99.220/include/sybdb.h ./include/sybdb.h >> diff -r ../compare/freetds-dev.0.99.220/include/freetds/convert.h >> ./include/freetds/convert.h >> diff -r ../compare/freetds-dev.0.99.220/include/freetds/proto.h >> ./include/freetds/proto.h >> diff -r ../compare/freetds-dev.0.99.220/src/apps/datacopy.c >> ./src/apps/datacopy.c >> diff -r ../compare/freetds-dev.0.99.220/src/tds/convert.c >> ./src/tds/convert.c >> diff -r ../compare/freetds-dev.0.99.220/src/tds/mem.c ./src/tds/mem.c >> diff -r ../compare/freetds-dev.0.99.220/src/tds/query.c ./src/tds/query.c >> diff -r ../compare/freetds-dev.0.99.220/src/tds/tds_types.h >> ./src/tds/tds_types.h >> >> So, I'd missed two files (in bold) which have now been updated in my >> attached document. >> >> It's still working for me :-) >> >> Cheers, >> >> Matthew. >> September 14 2015 10:46 AM, "Frediano Ziglio" wrote:Thanks, >> did patches yesterday. See >> >> https://github.com/FreeTDS/freetds/commit/235019b7342cea9bd200e7a7b00bb1bc26e37096 >> ( >> https://github.com/FreeTDS/freetds/commit/235019b7342cea9bd200e7a7b00bb1bc26e37096 >> ) >> ( >> https://github.com/FreeTDS/freetds/commit/235019b7342cea9bd200e7a7b00bb1bc26e37096 >> ( >> https://github.com/FreeTDS/freetds/commit/235019b7342cea9bd200e7a7b00bb1bc26e37096 >> )) >> and >> https://github.com/FreeTDS/freetds/commit/526c035f66cc297943690fd4096444921a764206 >> ( >> https://github.com/FreeTDS/freetds/commit/526c035f66cc297943690fd4096444921a764206 >> ) >> ( >> https://github.com/FreeTDS/freetds/commit/526c035f66cc297943690fd4096444921a764206 >> ( >> https://github.com/FreeTDS/freetds/commit/526c035f66cc297943690fd4096444921a764206) >> ). >> >> Is not easier to do a diff? >> >> Currently only ODBC is missing to the list. >> >> Frediano >> >> 2015-09-14 9:19 GMT+01:00 : >> I've found one file I modified which wasn't in my document... sorry about >> that. >> >> The change is to include/sybdb.h, around line 154: >> >> enum >> { >> SYBCHAR = 47, /* 0x2F */ >> #define SYBCHAR SYBCHAR >> SYBVARCHAR = 39, /* 0x27 */ >> #define SYBVARCHAR SYBVARCHAR >> SYBINTN = 38, /* 0x26 */ >> #define SYBINTN SYBINTN >> SYBINT1 = 48, /* 0x30 */ >> #define SYBINT1 SYBINT1 >> SYBINT2 = 52, /* 0x34 */ >> #define SYBINT2 SYBINT2 >> SYBINT4 = 56, /* 0x38 */ >> #define SYBINT4 SYBINT4 >> SYBINT8 = 127, /* 0x7F */ >> #define SYBINT8 SYBINT8 >> SYBFLT8 = 62, /* 0x3E */ >> #define SYBFLT8 SYBFLT8 >> SYBDATETIME = 61, /* 0x3D */ >> #define SYBDATETIME SYBDATETIME >> SYBDATE = 49, /* 0x31 */ >> #define SYBDATE SYBDATE >> SYBTIME = 51, /* 0x33 */ >> #define SYBTIME SYBTIME >> SYBBIT = 50, /* 0x32 */ >> #define SYBBIT SYBBIT >> SYBBITN = 104, /* 0x68 */ >> >> I'll keep looking in case there's anything else..... >> >> Cheers, >> >> Matthew. >> September 13 2015 12:19 PM, "Matthew" wrote:Thanks for the kind words. It >> seems I must have >> missedsomething as >> datacopy is working for me when copying DATE and TIME columns from ASE >> 15.7 to ASE 15.7. >> >> A lot of what I did was trial and error and I tried to remember to leave >> a comment so I could find what I'd changed in order to write it up at >> the end. >> >> Any idea which file I would have changed to get it working with dblib? >> If not I'll untar the package somewhere else and run a find and diff to >> see if I can spot it. >> >> Cheers, >> >> Matthew. >> >> On 13/09/15 11:55, Frediano Ziglio wrote: >> 2015-09-11 10:04 GMT+01:00 :Dear All, >> >> I'm not really a C programmer (or C++ for that matter) but I wanted to be >> able to use datacopy >> tocopy tables with DATE and TIME data types. So, I decided to have a crack >> at adding them to >> FreeTDS.My testing has been successful, although I'm not sure the way I've >> coded it is correct so >> any >> help/fixes would be appreciated. >> >> I've attached a rich text document with the details. The first part >> proposes a quick and dirty >> fix,while the second is my best guess at the "correct" way of doing things. >> >> Bare in mind that this is currently only for Sybase to Sybase. I'm going >> to look at doing this >> forSQL Server too but that's a bit more complicated! >> >> Cheers, >> >> Matthew. >> >> Patch and effort are really appreciated. >> So appreciated that I already pushed some changes and is actually >> testing deeply (but I don't think there will be any regression). >> >> datacopy still does not work as SYBDATE/SYBTIME are not supported by >> dblib (you added support for libTDS not upper libraries and datacopy >> is based on dblib). >> >> Currently converting from string will use datetime format in all >> cases. ODBC has its standard so format strings are well defined for >> it. >> >> I added some improvements too based on previously patches on some other >> types. >> >> Yes, adding a new type in FreeTDS is really a nightmare !!! >> >> Frediano >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org (mailto:FreeTDS at lists.ibiblio.org) (mailto: >> FreeTDS at lists.ibiblio.org (mailto:mailto:FreeTDS at lists.ibiblio.org)) >> (mailto:FreeTDS at lists.ibiblio.org (mailto:mailto:FreeTDS at lists.ibiblio.org >> ) >> (mailto:mailto:FreeTDS at lists.ibiblio.org (mailto:mailto:mailto: >> FreeTDS at lists.ibiblio.org))) >> http://lists.ibiblio.org/mailman/listinfo/freetds ( >> http://lists.ibiblio.org/mailman/listinfo/freetds) >> (http://lists.ibiblio.org/mailman/listinfo/freetds ( >> http://lists.ibiblio.org/mailman/listinfo/freetds)) >> (http://lists.ibiblio.org/mailman/listinfo/freetds ( >> http://lists.ibiblio.org/mailman/listinfo/freetds) >> (http://lists.ibiblio.org/mailman/listinfo/freetds) ( >> http://lists.ibiblio.org/mailman/listinfo/freetds))) >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org (mailto:FreeTDS at lists.ibiblio.org) (mailto: >> FreeTDS at lists.ibiblio.org (mailto:mailto:FreeTDS at lists.ibiblio.org)) >> http://lists.ibiblio.org/mailman/listinfo/freetds ( >> http://lists.ibiblio.org/mailman/listinfo/freetds) >> (http://lists.ibiblio.org/mailman/listinfo/freetds ( >> http://lists.ibiblio.org/mailman/listinfo/freetds)) >> >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org (mailto:FreeTDS at lists.ibiblio.org) (mailto: >> FreeTDS at lists.ibiblio.org (mailto:mailto:FreeTDS at lists.ibiblio.org)) >> http://lists.ibiblio.org/mailman/listinfo/freetds ( >> http://lists.ibiblio.org/mailman/listinfo/freetds) >> (http://lists.ibiblio.org/mailman/listinfo/freetds ( >> http://lists.ibiblio.org/mailman/listinfo/freetds)) >> >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org (mailto:FreeTDS at lists.ibiblio.org) >> http://lists.ibiblio.org/mailman/listinfo/freetds ( >> http://lists.ibiblio.org/mailman/listinfo/freetds) >> >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org (mailto:FreeTDS at lists.ibiblio.org) >> http://lists.ibiblio.org/mailman/listinfo/freetds ( >> http://lists.ibiblio.org/mailman/listinfo/freetds) >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> http://lists.ibiblio.org/mailman/listinfo/freetds >> > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From no-reply at appveyor.com Mon Sep 21 14:56:33 2015 From: no-reply at appveyor.com (AppVeyor) Date: Mon, 21 Sep 2015 18:56:33 +0000 Subject: [freetds] Build failed: freetds 212 Message-ID: <20150921185631.98366.54431@appveyor.com> From no-reply at appveyor.com Tue Sep 22 02:52:50 2015 From: no-reply at appveyor.com (AppVeyor) Date: Tue, 22 Sep 2015 06:52:50 +0000 Subject: [freetds] Build completed: freetds 217 Message-ID: <20150922065250.9945.94966@appveyor.com> From tworman at med.umich.edu Tue Sep 22 00:17:44 2015 From: tworman at med.umich.edu (Worman, Tyler) Date: Tue, 22 Sep 2015 04:17:44 +0000 Subject: [freetds] FreeTDS build on AIX - No shared objects (.so) generated? In-Reply-To: References: Message-ID: Following up on how to get the 64 bit version building correctly on AIX. I don't have autoreconf available to me so I couldn't try that test. Built 64-bit UnixODBC first. It's located in /home/tworman/local64/ in this example. export OBJECT_MODE=64 export PATH=$PATH:/usr/ccs/bin env CC=gcc CFLAGS="-maix64 -I/usr/local/include" AR_FLAGS="-X64 cru" ARFLAGS="-X64 cru" ./configure --with-tdsver=8.0 --with-unixodbc=/home/tworman/local64 --prefix=/home/tworman/local64/ make make install The .so's still don't copy over on install. So I copied them from the .lib directory in the install to my lib directory and setup the links manually. In the new /local64/lib dir, I ran these... ln -sf libct.so.4 libct.so ln -sf libsybdb.so.5 libsybdb.so ln -sf libtdsodbc.so.0 libtdsodbc.so That builds the symlinks for the .so files and then it seems to work just fine. Thanks again. - Tyler -----Original Message----- From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of Frediano Ziglio Sent: Tuesday, September 15, 2015 2:47 PM To: FreeTDS Development Group Subject: Re: [freetds] FreeTDS build on AIX - No shared objects (.so) generated? 2015-09-15 18:39 GMT+01:00 Worman, Tyler : > Hi, > Trying to build FreeTDS (stable .95.19) on AIX 7100-03-05-1524. The .so files don't generate. Browsed online and tried a few suggested fixes for similar problems but no luck so far. Generated my own .so files from the .a that builds but it doesn't seem to work. Any advice? > > Using the following: > ./configure --with-unixodbc=/usr/local/ --prefix=/home/tworman/local > --with-tdsver=7.0 make make install > > Appears to complete but no .so files are generated in the directory /home/tworman/local/lib. I only get .a and .la files. > I tested tsql that was built. It worked and connected to my MS SQL Server instance fine. > tsql always works :) It use static linking so one less issue to solve! AIX is quite strange when it comes to shared libraries. The static library on AIX are not such different from static ones. > I then generated the .so from the .a with gcc -fpic -g -shared -o > libtdsodbc.so libtdsodbc.a I verified my config using osql. It's fine until it gets to the actual connection and invoking isql (Unixodbc 32-bit). osql do you mean the utility in src/apps, right? > I tried the exact same .odbc.ini from a Linux box with a build of FreeTDS there and it works fine. > > The OSQL test: > ./osql -S TEST -U accthere -P passwordhere > > That produces this but no dump. > [IM004][unixODBC][Driver Manager]Driver's SQLAllocHandle on > SQL_HANDLE_HENV failed > [ISQL]ERROR: Could not SQLConnect > sed: Cannot find or open file /tmp/osql.dump.51511686. > > If I do this instead, I still get no dump, and nothing is written to the file I specify. > TDSDUMPCONFIG=stderr TDSDUMP=~/local/bin/temp ./osql -S TEST -U > usernamhere -P passwordhere > could be is not loading the driver so these environment are not used. > Thanks! > > - Tyler > > It would be helpful to see the configure output to understand if something went wrong. > > > > > Semi-unrelated try of 64 bit build (even though UnixODBC is compiled with 32bit types). > export OBJECT_MODE=64 > export CFLAGS=-maix64 > export LIBPATH=/usr/local/lib > export LD_LIBRARY_PATH=/usr/local/lib > export AR_FLAGS="-X64 cru" > export ARFLAGS="-X64 cru" > ./configure --with-tdsver=7.0 --with-unixodbc=/usr/local > --prefix=/home/tworman/local > > Configure is fine but build of this fails with: > Making all in . > CC odbc.lo > odbc.c: In function '_SQLRowCount': > odbc.c:4630: warning: visibility attribute not supported in this configuration; ignored > CC connectparams.lo > connectparams.c:96: error: static declaration of > 'SQLGetPrivateProfileString' follows non-static declaration > /usr/local/include/odbcinst.h:210: error: previous declaration of > 'SQLGetPrivateProfileString' was here Is quite expected, is finding the declaration but not the function. Trying to remove the odbcinst.h should make it compile. Better to have a 64 bit unixODBC ! > make: The error code from the last command is 1. > Stop. > make: The error code from the last command is 1. > Stop. > make: The error code from the last command is 2. > Stop. > make: The error code from the last command is 1. > Stop. > make: The error code from the last command is 1. > Stop. > > Not sure if this is really the path I should go down. This seems like > I just have multiple libraries defining SQLGetPrivateProfileString but > I only see one in my library path. That is the one from unixodbc at > /usr/local/include/ If you have autoconf installed in the system you can try with autoreconf -if command before configure to see if you can get a working libtool. Or I can try to make a distribution from a recent system and send to you to try a new libtool. Frediano _______________________________________________ FreeTDS mailing list FreeTDS at lists.ibiblio.org http://lists.ibiblio.org/mailman/listinfo/freetds ********************************************************** Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues From freddy77 at gmail.com Tue Sep 22 06:17:22 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Tue, 22 Sep 2015 11:17:22 +0100 Subject: [freetds] big(date)time types added Message-ID: Yesterday I finished and pushed my branch on supporting these new types for Sybase 15.7+. These types allow to store time or date and time with a microsecond precision. Regards, Frediano From freddy77 at gmail.com Tue Sep 22 06:19:24 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Tue, 22 Sep 2015 11:19:24 +0100 Subject: [freetds] Sybase 16 support ongoing Message-ID: I fix some issues for Sybase 16. This version is able to accept LOBs on prepared statement. There were some issues for LOBs which was not uploaded correctly. Looks like this server version had a lot of good improvements and optimizations. Frediano From sf at 4js.com Tue Sep 22 10:40:26 2015 From: sf at 4js.com (Sebastien FLAESCH) Date: Tue, 22 Sep 2015 16:40:26 +0200 Subject: [freetds] FreeTDS build on AIX - No shared objects (.so) generated? In-Reply-To: References: Message-ID: <5601685A.2030503@4js.com> AIX .a archives can hold 32 and 64 bit shared objects. Try this: comp at zebulon:/tmp/sf$ ls -l total 5064 -rwxr-xr-x 1 comp fjsadm 2585883 Sep 22 16:38 libtdsodbc.a comp at zebulon:/tmp/sf$ ar -x libtdsodbc.a comp at zebulon:/tmp/sf$ ls -l total 10088 -rwxr-xr-x 1 comp fjsadm 2585883 Sep 22 16:38 libtdsodbc.a -rwxrwxr-x 1 comp fjsadm 2567943 Sep 22 16:38 libtdsodbc.so.0 I have another problem when building 0.95 on AIX, will post another thread. Seb On 09/17/2015 06:09 AM, Worman, Tyler wrote: > I was curious about the .a too, so I tried to direct UnixODBC to use the .a as the driver file but no luck. Unfortunately I'm not terribly familiar with AIX and our admin has been swamped, so my time with him is limited for questioned about the shared objects. > > [01000][unixODBC][Driver Manager]Can't open lib '/home/tworman/local/lib/libtdsodbc.a' : file not found > [ISQL]ERROR: Could not SQLConnect > > But the file is there.... > bash-4.2$ file /home/tworman/local/lib/libtdsodbc.a > /home/tworman/local/lib/libtdsodbc.a: archive (big format) > > This is from the .so I generated with gcc. > bash-4.2$ file libtdsodbc.so > libtdsodbc.so: executable (RISC System/6000) or object module not stripped > > > bash-4.2$ bsqldb > Could not load program bsqldb: > Dependent module ../dblib/.libs/libsybdb.a(libsybdb.so.5) could not be loaded. > Could not load module ../dblib/.libs/libsybdb.a(libsybdb.so.5). > System error: No such file or directory > > I don't understand why it's looking where it is for the file. That is in the bin directory under my local install path. No dblib folder exists below that. The libsysdb.a file is located in ../lib/ > > Tried bsqlodbc but it gives the same issue as osql/isql does. > bsqlodbc gives the same: > bsqlodbc: error -1: SQLConnect: SQL_ERROR: failed > "[unixODBC][Driver Manager]Driver's SQLAllocHandle on SQL_HANDLE_HENV failed" > > Thank you for the response. I really appreciate the help! Going to try Frediano's advice and see if I can't get a full set of 64 bit builds working. Maybe I'll have slight better luck vs the 32 bit libraries. Results from 32bit DBLib unit tests and the configure are below. > > - Tyler > > Dblib unit tests. > env CFLAGS="-I/usr/local/include" AR_FLAGS="cru" ARFLAGS="cru" LD_LIBRARY_PATH=/usr/local/lib/ ./configure --with-unixodbc=/usr/local/ --prefix=/home/tworman/local --with-tdsver=7.0 > make > > Then the test results: > PASS: t0001 > PASS: t0002 > PASS: t0003 > PASS: t0004 > FAIL: t0005 > PASS: t0006 > PASS: t0007 > PASS: t0008 > PASS: t0009 > PASS: t0011 > PASS: t0012 > FAIL: t0013 > FAIL: t0014 > PASS: t0015 > PASS: t0016 > PASS: t0017 > PASS: t0018 > PASS: t0019 > PASS: t0020 > PASS: t0021 > FAIL: t0022 > FAIL: t0023 > FAIL: rpc > FAIL: dbmorecmds > FAIL: bcp > FAIL: thread > PASS: text_buffer > PASS: done_handling > PASS: timeout > FAIL: hang > PASS: null > PASS: null2 > PASS: setnull > FAIL: numeric > PASS: pending > ============================================================================ > Testsuite summary for FreeTDS 0.95.19 > ============================================================================ > # TOTAL: 35 > # PASS: 24 > # SKIP: 0 > # XFAIL: 0 > # FAIL: 11 > # XPASS: 0 > # ERROR: 0 > ============================================================================ > See src/dblib/unittests/test-suite.log > ============================================================================ > make: The error code from the last command is 1 > Stop. > make: The error code from the last command is 2. > Stop. > make: The error code from the last command is 2. > Stop. > > Most of the failures in the test suite were a result of lack of permissions for the account I have to create tables/procedures in certain areas. > > Output of the configure above: > checking for a BSD-compatible install... ./install-sh -c > checking whether build environment is sane... yes > checking for a thread-safe mkdir -p... ./install-sh -c -d > checking for gawk... no > checking for mawk... no > checking for nawk... nawk > checking whether make sets $(MAKE)... yes > checking whether make supports nested variables... yes > checking whether make supports nested variables... (cached) yes > checking for gawk... (cached) nawk > checking for grep that handles long lines and -e... /usr/bin/grep > checking whether ln -s works... yes > checking for ranlib... ranlib > checking for a sed that does not truncate output... /usr/bin/sed > checking build system type... powerpc-ibm-aix7.1.0.0 > checking host system type... powerpc-ibm-aix7.1.0.0 > checking for style of include used by make... GNU > checking for gcc... gcc > checking whether the C compiler works... yes > checking for C compiler default output file name... a.out > checking for suffix of executables... > checking whether we are cross compiling... no > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ISO C89... none needed > checking whether gcc understands -c and -o together... yes > checking dependency style of gcc... gcc3 > checking how to run the C preprocessor... gcc -E > checking for egrep... /usr/bin/grep -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking minix/config.h usability... no > checking minix/config.h presence... no > checking for minix/config.h... no > checking whether it is safe to define __EXTENSIONS__... yes > checking for special C compiler options needed for large files... no > checking for _FILE_OFFSET_BITS value needed for large files... unknown > checking for _LARGE_FILES value needed for large files... 1 > checking for gcc... (cached) gcc > checking whether we are using the GNU C compiler... (cached) yes > checking whether gcc accepts -g... (cached) yes > checking for gcc option to accept ISO C89... (cached) none needed > checking whether gcc understands -c and -o together... (cached) yes > checking dependency style of gcc... (cached) gcc3 > checking how to run the C preprocessor... gcc -E > checking for inline... inline > checking how to print strings... print -r > checking for a sed that does not truncate output... (cached) /usr/bin/sed > checking for fgrep... /usr/bin/grep -F > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... no > checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B > checking the name lister (/usr/bin/nm -B) interface... BSD nm > checking the maximum length of command line arguments... 786432 > checking whether the shell understands some XSI constructs... yes > checking whether the shell understands "+="... no > checking how to convert powerpc-ibm-aix7.1.0.0 file names to powerpc-ibm-aix7.1.0.0 format... func_convert_file_noop > checking how to convert powerpc-ibm-aix7.1.0.0 file names to toolchain format... func_convert_file_noop > checking for /usr/bin/ld option to reload object files... -r > checking for objdump... objdump > checking how to recognize dependent libraries... pass_all > checking for dlltool... dlltool > checking how to associate runtime and link libraries... print -r -- > checking for ar... ar > checking for archiver @FILE support... no > checking for strip... strip > checking for ranlib... (cached) ranlib > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for sysroot... no > checking for mt... mt > checking if mt is a manifest tool... no > checking for dlfcn.h... yes > checking for objdir... .libs > checking if gcc supports -fno-rtti -fno-exceptions... no > checking for gcc option to produce PIC... -DPIC > checking if gcc PIC flag -DPIC works... yes > checking if gcc static flag -static works... no > checking if gcc supports -c -o file.o... yes > checking if gcc supports -c -o file.o... (cached) yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... aix7.1.0.0 ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... no > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for library containing dlopen... none required > checking for dlerror... yes > checking for shl_load... no > checking for shl_load in -ldld... no > checking for dld_link in -ldld... no > checking for windres... no > checking for ld used by GCC... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... no > checking for shared library run path origin... done > checking for iconv... yes > checking how to link with libiconv... /home/tworman/local/lib/libiconv.a > checking for iconv declaration... > extern size_t iconv (iconv_t cd, char * *inbuf, size_t *inbytesleft, char * *outbuf, size_t *outbytesleft); > checking for doxygen... no > checking for odbc_config... odbc_config > checking for pkg-config... no > checking for library containing socket... none required > checking for library containing gethostbyname... none required > checking for library containing tgetent... -lcurses > checking for readline in -lreadline... yes > checking for rl_on_new_line... yes > checking for rl_reset_line_state... yes > checking for the pthreads library -lpthreads... yes > checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE > checking if more special flags are required for pthreads... -D_THREAD_SAFE > checking for library containing pthread_condattr_setclock... none required > checking for pthread_condattr_setclock... yes > checking for ANSI C header files... (cached) yes > checking whether time.h and sys/time.h may both be included... yes > checking whether struct tm is in sys/time.h or time.h... time.h > checking for struct tm.tm_zone... no > checking whether tzname is declared... yes > checking for tzname... yes > checking for struct tm.__tm_zone... no > checking errno.h usability... yes > checking errno.h presence... yes > checking for errno.h... yes > checking libgen.h usability... yes > checking libgen.h presence... yes > checking for libgen.h... yes > checking limits.h usability... yes > checking limits.h presence... yes > checking for limits.h... yes > checking locale.h usability... yes > checking locale.h presence... yes > checking for locale.h... yes > checking poll.h usability... yes > checking poll.h presence... yes > checking for poll.h... yes > checking readpassphrase.h usability... no > checking readpassphrase.h presence... no > checking for readpassphrase.h... no > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking stddef.h usability... yes > checking stddef.h presence... yes > checking for stddef.h... yes > checking sys/param.h usability... yes > checking sys/param.h presence... yes > checking for sys/param.h... yes > checking sys/select.h usability... yes > checking sys/select.h presence... yes > checking for sys/select.h... yes > checking for sys/stat.h... (cached) yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking for sys/types.h... (cached) yes > checking sys/resource.h usability... yes > checking sys/resource.h presence... yes > checking for sys/resource.h... yes > checking sys/wait.h usability... yes > checking sys/wait.h presence... yes > checking for sys/wait.h... yes > checking for unistd.h... (cached) yes > checking netdb.h usability... yes > checking netdb.h presence... yes > checking for netdb.h... yes > checking wchar.h usability... yes > checking wchar.h presence... yes > checking for wchar.h... yes > checking for inttypes.h... (cached) yes > checking winsock2.h usability... no > checking winsock2.h presence... no > checking for winsock2.h... no > checking localcharset.h usability... yes > checking localcharset.h presence... yes > checking for localcharset.h... yes > checking valgrind/memcheck.h usability... no > checking valgrind/memcheck.h presence... no > checking for valgrind/memcheck.h... no > checking malloc.h usability... yes > checking malloc.h presence... yes > checking for malloc.h... yes > checking dirent.h usability... yes > checking dirent.h presence... yes > checking for dirent.h... yes > checking for windows.h... no > checking for sql.h... yes > checking for odbcss.h... yes > checking arpa/inet.h usability... yes > checking arpa/inet.h presence... yes > checking for arpa/inet.h... yes > checking langinfo.h usability... yes > checking langinfo.h presence... yes > checking for langinfo.h... yes > checking for netdb.h... (cached) yes > checking netinet/in.h usability... yes > checking netinet/in.h presence... yes > checking for netinet/in.h... yes > checking netinet/tcp.h usability... yes > checking netinet/tcp.h presence... yes > checking for netinet/tcp.h... yes > checking roken.h usability... no > checking roken.h presence... no > checking for roken.h... no > checking com_err.h usability... no > checking com_err.h presence... no > checking for com_err.h... no > checking paths.h usability... yes > checking paths.h presence... yes > checking for paths.h... yes > checking sys/ioctl.h usability... yes > checking sys/ioctl.h presence... yes > checking for sys/ioctl.h... yes > checking sys/socket.h usability... yes > checking sys/socket.h presence... yes > checking for sys/socket.h... yes > checking whether INADDR_NONE is defined... yes > checking size of char... 1 > checking size of short... 2 > checking size of long... 4 > checking size of int... 4 > checking size of float... 4 > checking size of double... 8 > checking size of long double... 16 > checking size of long long... 8 > checking size of __int64... 0 > checking size of void *... 4 > checking size of wchar_t... 2 > checking is FIONBIO defined... yes > checking for socklen_t... yes > checking whether getopt has optreset support... no > checking whether byte ordering is bigendian... yes > checking for an ANSI C-conforming const... yes > checking whether we can use -static-libgcc... sed: Cannot find or open file conftest.c. > no > checking whether we can use -Wl,-static-libgcc... sed: Cannot find or open file conftest.c. > no > checking whether memset(0) sets pointers to NULL... yes > checking for _atoi64... no > checking for vsnprintf... yes > checking for _vsnprintf... no > checking for _vscprintf... no > checking for gettimeofday... yes > checking for nl_langinfo... yes > checking for locale_charset... no > checking for setenv... yes > checking for putenv... yes > checking for getuid... yes > checking for getpwuid... yes > checking for getpwuid_r... yes > checking for fstat... yes > checking for alarm... yes > checking for fork... yes > checking for gethrtime... no > checking for localtime_r... yes > checking for setitimer... yes > checking for _lseeki64... no > checking for _telli64... no > checking for _fseeki64... no > checking for _ftelli64... no > checking for setrlimit... yes > checking for pthread_cond_timedwait... yes > checking for _lock_file... no > checking for _unlock_file... no > checking for usleep... yes > checking for nanosleep... yes > checking for readdir_r... yes > checking for inet_ntoa_r... yes > checking for getipnodebyaddr... yes > checking for getipnodebyname... yes > checking for getaddrinfo... yes > checking for inet_ntop... yes > checking for gethostname... yes > checking for poll... yes > checking for socketpair... yes > checking for asprintf... no > checking for vasprintf... no > checking for strtok_r... yes > checking for readpassphrase... no > checking for strlcpy... no > checking for strlcat... no > checking for basename... yes > checking for getopt... yes > checking for strsep... yes > checking for _LARGEFILE_SOURCE value needed for large files... no > checking for library containing clock_gettime... none required > checking if clock_gettime support CLOCK_MONOTONIC... yes > checking whether malloc_options variable is present... no > checking compile-time options > looking for installed odbc driver manager > checking for SQLGetPrivateProfileString in -lodbcinst... yes > checking for SQLSETPOSIROW... yes > checking for SQLROWSETSIZE... yes > checking for SQLROWOFFSET... yes > checking size of SQLWCHAR... 2 > checking if openssl is wanted... no > checking threadsafety... enabled > checking for which type of gethostbyname_r... three > checking for which type of getservbyname_r... four > checking for which type of gethostbyaddr_r... five > checking for which type of getpwuid_r... five > checking for which type of localtime_r... struct > configure: debug enabled > checking CFLAGS for gcc -Wdeclaration-after-statement... -Wdeclaration-after-statement > done > checking that generated files are newer than configure... done > configure: creating ./config.status > config.status: creating include/freetds/version.h > config.status: creating include/tds_sysdep_public.h > config.status: creating Makefile > config.status: creating include/Makefile > config.status: creating include/freetds/Makefile > config.status: creating doc/Makefile > config.status: creating samples/Makefile > config.status: creating src/Makefile > config.status: creating src/tds/Makefile > config.status: creating src/tds/unittests/Makefile > config.status: creating src/dblib/Makefile > config.status: creating src/dblib/unittests/Makefile > config.status: creating src/ctlib/Makefile > config.status: creating src/ctlib/unittests/Makefile > config.status: creating src/replacements/Makefile > config.status: creating src/replacements/unittests/Makefile > config.status: creating src/server/Makefile > config.status: creating src/pool/Makefile > config.status: creating src/odbc/Makefile > config.status: creating src/odbc/unittests/Makefile > config.status: creating src/apps/Makefile > config.status: creating src/apps/fisql/Makefile > config.status: creating freetds.spec > config.status: creating win32/Makefile > config.status: creating win32/config.h > config.status: creating win32/version.rc > config.status: creating win32/freetds.nsh > config.status: creating vms/Makefile > config.status: creating doc/freebcp.1 > config.status: creating doc/tsql.1 > config.status: creating doc/osql.1 > config.status: creating doc/bsqldb.1 > config.status: creating doc/bsqlodbc.1 > config.status: creating doc/defncopy.1 > config.status: creating doc/datacopy.1 > config.status: creating doc/fisql.1 > config.status: creating doc/freetds.conf.5 > config.status: creating include/config.h > config.status: executing depfiles commands > config.status: executing libtool commands > > -----Original Message----- > From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of James K. Lowden > Sent: Wednesday, September 16, 2015 6:32 PM > To: freetds at lists.ibiblio.org > Subject: Re: [freetds] FreeTDS build on AIX - No shared objects (.so) generated? > > On Tue, 15 Sep 2015 17:39:26 +0000 > "Worman, Tyler" wrote: > >> Trying to build FreeTDS (stable .95.19) on AIX 7100-03-05-1524. >> The .so files don't generate. Browsed online and tried a few suggested >> fixes for similar problems but no luck so far. Generated my own .so >> files from the .a that builds but it doesn't seem to work. >> Any advice? > > If memory serves, .a in AIX *is* a dynamic library. I don't believe AIX follows the .so convention. If you're not sure, what does file(1) tell you? > > As Frediano said, tsql doesn't use the shared libraries. The simplest test is to run the unit tests for dblib, or run bsqldb. > > HTH. > > --jkl > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > ********************************************************** > Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > From sf at 4js.com Tue Sep 22 11:07:41 2015 From: sf at 4js.com (Sebastien FLAESCH) Date: Tue, 22 Sep 2015 17:07:41 +0200 Subject: [freetds] Build issue on AIX (invalid connection) Message-ID: <56016EBD.40903@4js.com> Trying to build 0.95.5 on AIX 6.1 in 64bit mode... $ export OBJECT_MODE=64 $ CC="gcc -maix64" CXX="g++ -maix64" LDFLAGS="-maix64" ./configure --prefix=$FTMDIR --with-odbc-nodm=/dbs/64bits/uxo/2.3.1 Note that we are using unixODBC 2.3.1, and we don't want to use unixODBC as we link directly with libtdsodbc.a/.so ... A simple connection fails and SQLGetDiagRec() returns a strange error message: SQL State: 42000 SQL code : 18456 Message : [FreeTDS][SQL Server]L SQL SERVER error 18456 is an invalid user/login issue, but when I switch to an older version of FreeTDS (0.92), same data source + username + login connects without problem... Any ideas? I suspect some unixODBC defines problem... Any way to check that the unixODBC defines (32b/64b SQLLEN) match? sizeof(SQLLEN) = 8 Seb From sf at 4js.com Tue Sep 22 11:08:52 2015 From: sf at 4js.com (Sebastien FLAESCH) Date: Tue, 22 Sep 2015 17:08:52 +0200 Subject: [freetds] Build issue on AIX (invalid connection) In-Reply-To: <56016EBD.40903@4js.com> References: <56016EBD.40903@4js.com> Message-ID: <56016F04.8080903@4js.com> Also tested with 0.95-rc3 by the way. Seb On 09/22/2015 05:07 PM, Sebastien FLAESCH wrote: > Trying to build 0.95.5 on AIX 6.1 in 64bit mode... > > $ export OBJECT_MODE=64 > > $ CC="gcc -maix64" CXX="g++ -maix64" LDFLAGS="-maix64" ./configure --prefix=$FTMDIR --with-odbc-nodm=/dbs/64bits/uxo/2.3.1 > > Note that we are using unixODBC 2.3.1, and we don't want to use unixODBC > as we link directly with libtdsodbc.a/.so ... > > A simple connection fails and SQLGetDiagRec() returns a strange error message: > > SQL State: 42000 > SQL code : 18456 > Message : [FreeTDS][SQL Server]L > > SQL SERVER error 18456 is an invalid user/login issue, but when I switch to an > older version of FreeTDS (0.92), same data source + username + login connects > without problem... > > Any ideas? > > I suspect some unixODBC defines problem... > > Any way to check that the unixODBC defines (32b/64b SQLLEN) match? > > sizeof(SQLLEN) = 8 > > Seb > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > From sf at 4js.com Tue Sep 22 11:17:00 2015 From: sf at 4js.com (Sebastien FLAESCH) Date: Tue, 22 Sep 2015 17:17:00 +0200 Subject: [freetds] Build issue on AIX (invalid connection) In-Reply-To: <56016F04.8080903@4js.com> References: <56016EBD.40903@4js.com> <56016F04.8080903@4js.com> Message-ID: <560170EC.6090002@4js.com> And here is the TDSDUMP (0.95-rc3)... Seb On 09/22/2015 05:08 PM, Sebastien FLAESCH wrote: > Also tested with 0.95-rc3 by the way. > Seb > > On 09/22/2015 05:07 PM, Sebastien FLAESCH wrote: >> Trying to build 0.95.5 on AIX 6.1 in 64bit mode... >> >> $ export OBJECT_MODE=64 >> >> $ CC="gcc -maix64" CXX="g++ -maix64" LDFLAGS="-maix64" ./configure --prefix=$FTMDIR --with-odbc-nodm=/dbs/64bits/uxo/2.3.1 >> >> Note that we are using unixODBC 2.3.1, and we don't want to use unixODBC >> as we link directly with libtdsodbc.a/.so ... >> >> A simple connection fails and SQLGetDiagRec() returns a strange error message: >> >> SQL State: 42000 >> SQL code : 18456 >> Message : [FreeTDS][SQL Server]L >> >> SQL SERVER error 18456 is an invalid user/login issue, but when I switch to an >> older version of FreeTDS (0.92), same data source + username + login connects >> without problem... >> >> Any ideas? >> >> I suspect some unixODBC defines problem... >> >> Any way to check that the unixODBC defines (32b/64b SQLLEN) match? >> >> sizeof(SQLLEN) = 8 >> >> Seb >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> http://lists.ibiblio.org/mailman/listinfo/freetds >> > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > -------------- next part -------------- A non-text attachment was scrubbed... Name: tdsdump.log Type: text/x-log Size: 3469 bytes Desc: not available URL: From tworman at med.umich.edu Tue Sep 22 12:26:03 2015 From: tworman at med.umich.edu (Worman, Tyler) Date: Tue, 22 Sep 2015 16:26:03 +0000 Subject: [freetds] Build issue on AIX (invalid connection) In-Reply-To: <560170EC.6090002@4js.com> References: <56016EBD.40903@4js.com> <56016F04.8080903@4js.com> <560170EC.6090002@4js.com> Message-ID: I'm suffering through the same issue at present! It seems to be related to libiconv. See your log: local name for UCS-2LE is (null) iconv.c:187:local name for UCS-2BE is UCS-2 On a working 32-bit version of FreeTDS on AIX, that (null) isn't there. Which version of Iconv are you using? If you can build gnu libiconv as 64bit, I'm guessing it might work. I've read that the AIX libiconv is "incomplete" Where I'm at: I can't build a 64 bit libiconv successfully. I get: libtool: compile: /home/tworman/libiconv-1.14/build-aux/compile gcc -I. -I. -I../include -I./../include -I.. -I./.. -maix64 -DLIBDIR=\"/home/tworman/local64/lib\" -DBUILDING_LIBICONV -DBUILDING_DLL -DENABLE_RELOCATABLE=1 -DIN_LIBRARY -DINSTALLDIR=\"/home/tworman/local64/lib\" -DNO_XMALLOC -Dset_relocation_prefix=libiconv_set_relocation_prefix -Drelocate=libiconv_relocate -DHAVE_CONFIG_H -c ./iconv.c ../libtool[11]: /home/tworman/libiconv-1.14/build-aux/compile: not found make: The error code from the last command is 1. I assumed it was a libtool issue. Unable to even configure a 64 bit lib tool as it needs a newer m4 than what I have. Unable to build m4 as it complains about: In file included from quotearg.c:43: ./wctype.h:727: error: conflicting types for 'wctype_t' /opt/freeware/lib/gcc/powerpc-ibm-aix6.1.0.0/4.2.0/include/ctype.h:119: error: previous declaration of 'wctype_t' was here ./wctype.h:776: error: conflicting types for 'wctrans_t' /usr/include/wctype.h:52: error: previous declaration of 'wctrans_t' was here make: The error code from the last command is 1. -----Original Message----- From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of Sebastien FLAESCH Sent: Tuesday, September 22, 2015 11:17 AM To: freetds at lists.ibiblio.org Subject: Re: [freetds] Build issue on AIX (invalid connection) And here is the TDSDUMP (0.95-rc3)... Seb On 09/22/2015 05:08 PM, Sebastien FLAESCH wrote: > Also tested with 0.95-rc3 by the way. > Seb > > On 09/22/2015 05:07 PM, Sebastien FLAESCH wrote: >> Trying to build 0.95.5 on AIX 6.1 in 64bit mode... >> >> $ export OBJECT_MODE=64 >> >> $ CC="gcc -maix64" CXX="g++ -maix64" LDFLAGS="-maix64" ./configure >> --prefix=$FTMDIR --with-odbc-nodm=/dbs/64bits/uxo/2.3.1 >> >> Note that we are using unixODBC 2.3.1, and we don't want to use >> unixODBC as we link directly with libtdsodbc.a/.so ... >> >> A simple connection fails and SQLGetDiagRec() returns a strange error message: >> >> SQL State: 42000 >> SQL code : 18456 >> Message : [FreeTDS][SQL Server]L >> >> SQL SERVER error 18456 is an invalid user/login issue, but when I >> switch to an older version of FreeTDS (0.92), same data source + >> username + login connects without problem... >> >> Any ideas? >> >> I suspect some unixODBC defines problem... >> >> Any way to check that the unixODBC defines (32b/64b SQLLEN) match? >> >> sizeof(SQLLEN) = 8 >> >> Seb >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> http://lists.ibiblio.org/mailman/listinfo/freetds >> > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > ********************************************************** Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues From tworman at med.umich.edu Tue Sep 22 12:54:18 2015 From: tworman at med.umich.edu (Worman, Tyler) Date: Tue, 22 Sep 2015 16:54:18 +0000 Subject: [freetds] FreeTDS build on AIX - No shared objects (.so) generated? In-Reply-To: References: Message-ID: To update this, the build worked but the local libiconv provided with AIX didn't provide everything needed. It was giving an invalid login but the error message was just "L". The TDSDUMP pointed me to libiconv not supporting some of the translations needed for the connection. Here is what tipped me off: log.c:167:Starting log file for FreeTDS 0.95.19 on 2015-09-22 09:54:03 with debug flags 0x4fff. iconv.c:328:tds_iconv_open(110023490, ISO8859-1) iconv.c:187:local name for ISO-8859-1 is ISO-8859-1 iconv.c:187:local name for UTF-8 is UTF-8 iconv.c:187:local name for UCS-2LE is (null) iconv.c:187:local name for UCS-2BE is UNICODEBIG iconv.c:346:setting up conversions for client charset "ISO8859-1" iconv.c:348:preparing iconv for "ISO8859-1" <-> "UCS-2LE" conversion iconv.c:455:Charset 2 not supported by iconv, using "ISO-8859-1" instead iconv.c:395:preparing iconv for "ISO-8859-1" <-> "UCS-2LE" conversion iconv.c:400:tds_iconv_open: done The process became build UnixODBC, gnu Libiconv, FreeTDS. UnixODBC 64-bit: export OBJECT_MODE=64 export PATH=$PATH:/usr/ccs/bin env CC=gcc CFLAGS="-maix64 -I/usr/local/include" AR_FLAGS="-X64 cru" ARFLAGS="-X64 cru" ./configure --prefix=/home/tworman/local64 make make install This installs, but doesn't copy the .so's. They do build though. find /home/tworman/unixODBC-2.3.4 -path '*/.*' | grep "\.so*" > sharedfiles cp $( sharedfiles cp $(: > Hi, > Trying to build FreeTDS (stable .95.19) on AIX 7100-03-05-1524. The .so files don't generate. Browsed online and tried a few suggested fixes for similar problems but no luck so far. Generated my own .so files from the .a that builds but it doesn't seem to work. Any advice? > > Using the following: > ./configure --with-unixodbc=/usr/local/ --prefix=/home/tworman/local > --with-tdsver=7.0 make make install > > Appears to complete but no .so files are generated in the directory /home/tworman/local/lib. I only get .a and .la files. > I tested tsql that was built. It worked and connected to my MS SQL Server instance fine. > tsql always works :) It use static linking so one less issue to solve! AIX is quite strange when it comes to shared libraries. The static library on AIX are not such different from static ones. > I then generated the .so from the .a with gcc -fpic -g -shared -o > libtdsodbc.so libtdsodbc.a I verified my config using osql. It's fine until it gets to the actual connection and invoking isql (Unixodbc 32-bit). osql do you mean the utility in src/apps, right? > I tried the exact same .odbc.ini from a Linux box with a build of FreeTDS there and it works fine. > > The OSQL test: > ./osql -S TEST -U accthere -P passwordhere > > That produces this but no dump. > [IM004][unixODBC][Driver Manager]Driver's SQLAllocHandle on > SQL_HANDLE_HENV failed > [ISQL]ERROR: Could not SQLConnect > sed: Cannot find or open file /tmp/osql.dump.51511686. > > If I do this instead, I still get no dump, and nothing is written to the file I specify. > TDSDUMPCONFIG=stderr TDSDUMP=~/local/bin/temp ./osql -S TEST -U > usernamhere -P passwordhere > could be is not loading the driver so these environment are not used. > Thanks! > > - Tyler > > It would be helpful to see the configure output to understand if something went wrong. > > > > > Semi-unrelated try of 64 bit build (even though UnixODBC is compiled with 32bit types). > export OBJECT_MODE=64 > export CFLAGS=-maix64 > export LIBPATH=/usr/local/lib > export LD_LIBRARY_PATH=/usr/local/lib > export AR_FLAGS="-X64 cru" > export ARFLAGS="-X64 cru" > ./configure --with-tdsver=7.0 --with-unixodbc=/usr/local > --prefix=/home/tworman/local > > Configure is fine but build of this fails with: > Making all in . > CC odbc.lo > odbc.c: In function '_SQLRowCount': > odbc.c:4630: warning: visibility attribute not supported in this configuration; ignored > CC connectparams.lo > connectparams.c:96: error: static declaration of > 'SQLGetPrivateProfileString' follows non-static declaration > /usr/local/include/odbcinst.h:210: error: previous declaration of > 'SQLGetPrivateProfileString' was here Is quite expected, is finding the declaration but not the function. Trying to remove the odbcinst.h should make it compile. Better to have a 64 bit unixODBC ! > make: The error code from the last command is 1. > Stop. > make: The error code from the last command is 1. > Stop. > make: The error code from the last command is 2. > Stop. > make: The error code from the last command is 1. > Stop. > make: The error code from the last command is 1. > Stop. > > Not sure if this is really the path I should go down. This seems like > I just have multiple libraries defining SQLGetPrivateProfileString but > I only see one in my library path. That is the one from unixodbc at > /usr/local/include/ If you have autoconf installed in the system you can try with autoreconf -if command before configure to see if you can get a working libtool. Or I can try to make a distribution from a recent system and send to you to try a new libtool. Frediano _______________________________________________ FreeTDS mailing list FreeTDS at lists.ibiblio.org http://lists.ibiblio.org/mailman/listinfo/freetds ********************************************************** Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues From tworman at med.umich.edu Tue Sep 22 12:56:26 2015 From: tworman at med.umich.edu (Worman, Tyler) Date: Tue, 22 Sep 2015 16:56:26 +0000 Subject: [freetds] Build issue on AIX (invalid connection) In-Reply-To: <560170EC.6090002@4js.com> References: <56016EBD.40903@4js.com> <56016F04.8080903@4js.com> <560170EC.6090002@4js.com> Message-ID: I was able to fix this by building GNU libiconv and then build FreeTDS against that. After that, it runs and connects without the odd "L" error message. The TDS_DUMP also no longer complains about iconv. To get libiconv to build I needed to set the following: export OBJECT_MODE=64 env CC=gcc CFLAGS="-maix64 -I/usr/local/include" AR_FLAGS="-X64 cru" /configure --prefix=/home/tworman/local64/ make make install -----Original Message----- From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of Sebastien FLAESCH Sent: Tuesday, September 22, 2015 11:17 AM To: freetds at lists.ibiblio.org Subject: Re: [freetds] Build issue on AIX (invalid connection) And here is the TDSDUMP (0.95-rc3)... Seb On 09/22/2015 05:08 PM, Sebastien FLAESCH wrote: > Also tested with 0.95-rc3 by the way. > Seb > > On 09/22/2015 05:07 PM, Sebastien FLAESCH wrote: >> Trying to build 0.95.5 on AIX 6.1 in 64bit mode... >> >> $ export OBJECT_MODE=64 >> >> $ CC="gcc -maix64" CXX="g++ -maix64" LDFLAGS="-maix64" ./configure >> --prefix=$FTMDIR --with-odbc-nodm=/dbs/64bits/uxo/2.3.1 >> >> Note that we are using unixODBC 2.3.1, and we don't want to use >> unixODBC as we link directly with libtdsodbc.a/.so ... >> >> A simple connection fails and SQLGetDiagRec() returns a strange error message: >> >> SQL State: 42000 >> SQL code : 18456 >> Message : [FreeTDS][SQL Server]L >> >> SQL SERVER error 18456 is an invalid user/login issue, but when I >> switch to an older version of FreeTDS (0.92), same data source + >> username + login connects without problem... >> >> Any ideas? >> >> I suspect some unixODBC defines problem... >> >> Any way to check that the unixODBC defines (32b/64b SQLLEN) match? >> >> sizeof(SQLLEN) = 8 >> >> Seb >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> http://lists.ibiblio.org/mailman/listinfo/freetds >> > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > ********************************************************** Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues From ikorot01 at gmail.com Tue Sep 22 08:59:08 2015 From: ikorot01 at gmail.com (Igor Korot) Date: Tue, 22 Sep 2015 08:59:08 -0400 Subject: [freetds] FreeTDS build on AIX - No shared objects (.so) generated? In-Reply-To: References: Message-ID: Hi, On Tue, Sep 22, 2015 at 12:17 AM, Worman, Tyler wrote: > Following up on how to get the 64 bit version building correctly on AIX. I don't have autoreconf available to me so I couldn't try that test. > > Built 64-bit UnixODBC first. It's located in /home/tworman/local64/ in this example. > > export OBJECT_MODE=64 > export PATH=$PATH:/usr/ccs/bin > > env CC=gcc CFLAGS="-maix64 -I/usr/local/include" AR_FLAGS="-X64 cru" ARFLAGS="-X64 cru" ./configure --with-tdsver=8.0 --with-unixodbc=/home/tworman/local64 --prefix=/home/tworman/local64/ > > make > make install > > The .so's still don't copy over on install. So I copied them from the .lib directory in the install to my lib directory and setup the links manually. > > In the new /local64/lib dir, I ran these... > ln -sf libct.so.4 libct.so > ln -sf libsybdb.so.5 libsybdb.so > ln -sf libtdsodbc.so.0 libtdsodbc.so > > That builds the symlinks for the .so files and then it seems to work just fine. > > Thanks again.. You should send an email to unixodbc maintainer - Nick Gorham and ask him to fix the build. ;-) Thank you. > > - Tyler > > -----Original Message----- > From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of Frediano Ziglio > Sent: Tuesday, September 15, 2015 2:47 PM > To: FreeTDS Development Group > Subject: Re: [freetds] FreeTDS build on AIX - No shared objects (.so) generated? > > 2015-09-15 18:39 GMT+01:00 Worman, Tyler : >> Hi, >> Trying to build FreeTDS (stable .95.19) on AIX 7100-03-05-1524. The .so files don't generate. Browsed online and tried a few suggested fixes for similar problems but no luck so far. Generated my own .so files from the .a that builds but it doesn't seem to work. Any advice? >> >> Using the following: >> ./configure --with-unixodbc=/usr/local/ --prefix=/home/tworman/local >> --with-tdsver=7.0 make make install >> >> Appears to complete but no .so files are generated in the directory /home/tworman/local/lib. I only get .a and .la files. >> I tested tsql that was built. It worked and connected to my MS SQL Server instance fine. >> > > tsql always works :) > It use static linking so one less issue to solve! > AIX is quite strange when it comes to shared libraries. The static library on AIX are not such different from static ones. > >> I then generated the .so from the .a with gcc -fpic -g -shared -o >> libtdsodbc.so libtdsodbc.a I verified my config using osql. It's fine until it gets to the actual connection and invoking isql (Unixodbc 32-bit). > > osql do you mean the utility in src/apps, right? > >> I tried the exact same .odbc.ini from a Linux box with a build of FreeTDS there and it works fine. >> >> The OSQL test: >> ./osql -S TEST -U accthere -P passwordhere >> >> That produces this but no dump. >> [IM004][unixODBC][Driver Manager]Driver's SQLAllocHandle on >> SQL_HANDLE_HENV failed >> [ISQL]ERROR: Could not SQLConnect >> sed: Cannot find or open file /tmp/osql.dump.51511686. >> >> If I do this instead, I still get no dump, and nothing is written to the file I specify. >> TDSDUMPCONFIG=stderr TDSDUMP=~/local/bin/temp ./osql -S TEST -U >> usernamhere -P passwordhere >> > > could be is not loading the driver so these environment are not used. > >> Thanks! >> >> - Tyler >> >> > > It would be helpful to see the configure output to understand if something went wrong. > >> >> >> >> >> Semi-unrelated try of 64 bit build (even though UnixODBC is compiled with 32bit types). >> export OBJECT_MODE=64 >> export CFLAGS=-maix64 >> export LIBPATH=/usr/local/lib >> export LD_LIBRARY_PATH=/usr/local/lib >> export AR_FLAGS="-X64 cru" >> export ARFLAGS="-X64 cru" >> ./configure --with-tdsver=7.0 --with-unixodbc=/usr/local >> --prefix=/home/tworman/local >> >> Configure is fine but build of this fails with: >> Making all in . >> CC odbc.lo >> odbc.c: In function '_SQLRowCount': >> odbc.c:4630: warning: visibility attribute not supported in this configuration; ignored >> CC connectparams.lo >> connectparams.c:96: error: static declaration of >> 'SQLGetPrivateProfileString' follows non-static declaration >> /usr/local/include/odbcinst.h:210: error: previous declaration of >> 'SQLGetPrivateProfileString' was here > > Is quite expected, is finding the declaration but not the function. > Trying to remove the odbcinst.h should make it compile. > Better to have a 64 bit unixODBC ! > >> make: The error code from the last command is 1. >> Stop. >> make: The error code from the last command is 1. >> Stop. >> make: The error code from the last command is 2. >> Stop. >> make: The error code from the last command is 1. >> Stop. >> make: The error code from the last command is 1. >> Stop. >> >> Not sure if this is really the path I should go down. This seems like >> I just have multiple libraries defining SQLGetPrivateProfileString but >> I only see one in my library path. That is the one from unixodbc at >> /usr/local/include/ > > If you have autoconf installed in the system you can try with > > autoreconf -if > > command before configure to see if you can get a working libtool. > > Or I can try to make a distribution from a recent system and send to you to try a new libtool. > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > ********************************************************** > Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From tworman at med.umich.edu Tue Sep 22 17:41:27 2015 From: tworman at med.umich.edu (Worman, Tyler) Date: Tue, 22 Sep 2015 21:41:27 +0000 Subject: [freetds] FreeTDS build on AIX - No shared objects (.so) generated? In-Reply-To: References: Message-ID: The problem here with the copying is actually on the FreeTDS side. Sorry the first email might not have been clear. Similar things happen with UnixODBC. I'll email the maintainer just in case. Thanks! I'm not so sure it's is either package vs how AIX's libtool handles what configure produces. With both UnixODBC and FreeTDS the .so files are not copied from the .libs folders on AIX7.1. Wanted to document it here in case anyone else runs into a similar problem. - Tyler -----Original Message----- From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of Igor Korot Sent: Tuesday, September 22, 2015 8:59 AM To: FreeTDS Development Group Subject: Re: [freetds] FreeTDS build on AIX - No shared objects (.so) generated? Hi, On Tue, Sep 22, 2015 at 12:17 AM, Worman, Tyler wrote: > Following up on how to get the 64 bit version building correctly on AIX. I don't have autoreconf available to me so I couldn't try that test. > > Built 64-bit UnixODBC first. It's located in /home/tworman/local64/ in this example. > > export OBJECT_MODE=64 > export PATH=$PATH:/usr/ccs/bin > > env CC=gcc CFLAGS="-maix64 -I/usr/local/include" AR_FLAGS="-X64 cru" > ARFLAGS="-X64 cru" ./configure --with-tdsver=8.0 > --with-unixodbc=/home/tworman/local64 --prefix=/home/tworman/local64/ > > make > make install > > The .so's still don't copy over on install. So I copied them from the .lib directory in the install to my lib directory and setup the links manually. > > In the new /local64/lib dir, I ran these... > ln -sf libct.so.4 libct.so > ln -sf libsybdb.so.5 libsybdb.so > ln -sf libtdsodbc.so.0 libtdsodbc.so > > That builds the symlinks for the .so files and then it seems to work just fine. > > Thanks again.. You should send an email to unixodbc maintainer - Nick Gorham and ask him to fix the build. ;-) Thank you. > > - Tyler > > -----Original Message----- > From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of > Frediano Ziglio > Sent: Tuesday, September 15, 2015 2:47 PM > To: FreeTDS Development Group > Subject: Re: [freetds] FreeTDS build on AIX - No shared objects (.so) generated? > > 2015-09-15 18:39 GMT+01:00 Worman, Tyler : >> Hi, >> Trying to build FreeTDS (stable .95.19) on AIX 7100-03-05-1524. The .so files don't generate. Browsed online and tried a few suggested fixes for similar problems but no luck so far. Generated my own .so files from the .a that builds but it doesn't seem to work. Any advice? >> >> Using the following: >> ./configure --with-unixodbc=/usr/local/ --prefix=/home/tworman/local >> --with-tdsver=7.0 make make install >> >> Appears to complete but no .so files are generated in the directory /home/tworman/local/lib. I only get .a and .la files. >> I tested tsql that was built. It worked and connected to my MS SQL Server instance fine. >> > > tsql always works :) > It use static linking so one less issue to solve! > AIX is quite strange when it comes to shared libraries. The static library on AIX are not such different from static ones. > >> I then generated the .so from the .a with gcc -fpic -g -shared -o >> libtdsodbc.so libtdsodbc.a I verified my config using osql. It's fine until it gets to the actual connection and invoking isql (Unixodbc 32-bit). > > osql do you mean the utility in src/apps, right? > >> I tried the exact same .odbc.ini from a Linux box with a build of FreeTDS there and it works fine. >> >> The OSQL test: >> ./osql -S TEST -U accthere -P passwordhere >> >> That produces this but no dump. >> [IM004][unixODBC][Driver Manager]Driver's SQLAllocHandle on >> SQL_HANDLE_HENV failed >> [ISQL]ERROR: Could not SQLConnect >> sed: Cannot find or open file /tmp/osql.dump.51511686. >> >> If I do this instead, I still get no dump, and nothing is written to the file I specify. >> TDSDUMPCONFIG=stderr TDSDUMP=~/local/bin/temp ./osql -S TEST -U >> usernamhere -P passwordhere >> > > could be is not loading the driver so these environment are not used. > >> Thanks! >> >> - Tyler >> >> > > It would be helpful to see the configure output to understand if something went wrong. > >> >> >> >> >> Semi-unrelated try of 64 bit build (even though UnixODBC is compiled with 32bit types). >> export OBJECT_MODE=64 >> export CFLAGS=-maix64 >> export LIBPATH=/usr/local/lib >> export LD_LIBRARY_PATH=/usr/local/lib export AR_FLAGS="-X64 cru" >> export ARFLAGS="-X64 cru" >> ./configure --with-tdsver=7.0 --with-unixodbc=/usr/local >> --prefix=/home/tworman/local >> >> Configure is fine but build of this fails with: >> Making all in . >> CC odbc.lo >> odbc.c: In function '_SQLRowCount': >> odbc.c:4630: warning: visibility attribute not supported in this configuration; ignored >> CC connectparams.lo >> connectparams.c:96: error: static declaration of >> 'SQLGetPrivateProfileString' follows non-static declaration >> /usr/local/include/odbcinst.h:210: error: previous declaration of >> 'SQLGetPrivateProfileString' was here > > Is quite expected, is finding the declaration but not the function. > Trying to remove the odbcinst.h should make it compile. > Better to have a 64 bit unixODBC ! > >> make: The error code from the last command is 1. >> Stop. >> make: The error code from the last command is 1. >> Stop. >> make: The error code from the last command is 2. >> Stop. >> make: The error code from the last command is 1. >> Stop. >> make: The error code from the last command is 1. >> Stop. >> >> Not sure if this is really the path I should go down. This seems like >> I just have multiple libraries defining SQLGetPrivateProfileString >> but I only see one in my library path. That is the one from unixodbc >> at /usr/local/include/ > > If you have autoconf installed in the system you can try with > > autoreconf -if > > command before configure to see if you can get a working libtool. > > Or I can try to make a distribution from a recent system and send to you to try a new libtool. > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > ********************************************************** > Electronic Mail is not secure, may not be read every day, and should > not be used for urgent or sensitive issues > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds _______________________________________________ FreeTDS mailing list FreeTDS at lists.ibiblio.org http://lists.ibiblio.org/mailman/listinfo/freetds ********************************************************** Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues From freddy77 at gmail.com Tue Sep 22 18:22:38 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Tue, 22 Sep 2015 23:22:38 +0100 Subject: [freetds] FreeTDS build on AIX - No shared objects (.so) generated? In-Reply-To: References: Message-ID: Looks like a libtool problem. Could you post (after the make): - the libtool file in the main directory - src/dblib/libsybdb.la I would ask config.log too but I'm not sure could contain private information. Could you also try to define LDFLAGS to "-brtl" (before configure) ? Frediano 2015-09-22 22:41 GMT+01:00 Worman, Tyler : > The problem here with the copying is actually on the FreeTDS side. Sorry the first email might not have been clear. > > Similar things happen with UnixODBC. I'll email the maintainer just in case. Thanks! > > I'm not so sure it's is either package vs how AIX's libtool handles what configure produces. > With both UnixODBC and FreeTDS the .so files are not copied from the .libs folders on AIX7.1. > > Wanted to document it here in case anyone else runs into a similar problem. > > - Tyler > > -----Original Message----- > From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of Igor Korot > Sent: Tuesday, September 22, 2015 8:59 AM > To: FreeTDS Development Group > Subject: Re: [freetds] FreeTDS build on AIX - No shared objects (.so) generated? > > Hi, > > On Tue, Sep 22, 2015 at 12:17 AM, Worman, Tyler wrote: >> Following up on how to get the 64 bit version building correctly on AIX. I don't have autoreconf available to me so I couldn't try that test. >> >> Built 64-bit UnixODBC first. It's located in /home/tworman/local64/ in this example. >> >> export OBJECT_MODE=64 >> export PATH=$PATH:/usr/ccs/bin >> >> env CC=gcc CFLAGS="-maix64 -I/usr/local/include" AR_FLAGS="-X64 cru" >> ARFLAGS="-X64 cru" ./configure --with-tdsver=8.0 >> --with-unixodbc=/home/tworman/local64 --prefix=/home/tworman/local64/ >> >> make >> make install >> >> The .so's still don't copy over on install. So I copied them from the .lib directory in the install to my lib directory and setup the links manually. >> >> In the new /local64/lib dir, I ran these... >> ln -sf libct.so.4 libct.so >> ln -sf libsybdb.so.5 libsybdb.so >> ln -sf libtdsodbc.so.0 libtdsodbc.so >> >> That builds the symlinks for the .so files and then it seems to work just fine. >> >> Thanks again.. > > You should send an email to unixodbc maintainer - Nick Gorham and ask him to fix the build. ;-) > > Thank you. > >> >> - Tyler >> >> -----Original Message----- >> From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of >> Frediano Ziglio >> Sent: Tuesday, September 15, 2015 2:47 PM >> To: FreeTDS Development Group >> Subject: Re: [freetds] FreeTDS build on AIX - No shared objects (.so) generated? >> >> 2015-09-15 18:39 GMT+01:00 Worman, Tyler : >>> Hi, >>> Trying to build FreeTDS (stable .95.19) on AIX 7100-03-05-1524. The .so files don't generate. Browsed online and tried a few suggested fixes for similar problems but no luck so far. Generated my own .so files from the .a that builds but it doesn't seem to work. Any advice? >>> >>> Using the following: >>> ./configure --with-unixodbc=/usr/local/ --prefix=/home/tworman/local >>> --with-tdsver=7.0 make make install >>> >>> Appears to complete but no .so files are generated in the directory /home/tworman/local/lib. I only get .a and .la files. >>> I tested tsql that was built. It worked and connected to my MS SQL Server instance fine. >>> >> >> tsql always works :) >> It use static linking so one less issue to solve! >> AIX is quite strange when it comes to shared libraries. The static library on AIX are not such different from static ones. >> >>> I then generated the .so from the .a with gcc -fpic -g -shared -o >>> libtdsodbc.so libtdsodbc.a I verified my config using osql. It's fine until it gets to the actual connection and invoking isql (Unixodbc 32-bit). >> >> osql do you mean the utility in src/apps, right? >> >>> I tried the exact same .odbc.ini from a Linux box with a build of FreeTDS there and it works fine. >>> >>> The OSQL test: >>> ./osql -S TEST -U accthere -P passwordhere >>> >>> That produces this but no dump. >>> [IM004][unixODBC][Driver Manager]Driver's SQLAllocHandle on >>> SQL_HANDLE_HENV failed >>> [ISQL]ERROR: Could not SQLConnect >>> sed: Cannot find or open file /tmp/osql.dump.51511686. >>> >>> If I do this instead, I still get no dump, and nothing is written to the file I specify. >>> TDSDUMPCONFIG=stderr TDSDUMP=~/local/bin/temp ./osql -S TEST -U >>> usernamhere -P passwordhere >>> >> >> could be is not loading the driver so these environment are not used. >> >>> Thanks! >>> >>> - Tyler >>> >>> >> >> It would be helpful to see the configure output to understand if something went wrong. >> >>> >>> >>> >>> >>> Semi-unrelated try of 64 bit build (even though UnixODBC is compiled with 32bit types). >>> export OBJECT_MODE=64 >>> export CFLAGS=-maix64 >>> export LIBPATH=/usr/local/lib >>> export LD_LIBRARY_PATH=/usr/local/lib export AR_FLAGS="-X64 cru" >>> export ARFLAGS="-X64 cru" >>> ./configure --with-tdsver=7.0 --with-unixodbc=/usr/local >>> --prefix=/home/tworman/local >>> >>> Configure is fine but build of this fails with: >>> Making all in . >>> CC odbc.lo >>> odbc.c: In function '_SQLRowCount': >>> odbc.c:4630: warning: visibility attribute not supported in this configuration; ignored >>> CC connectparams.lo >>> connectparams.c:96: error: static declaration of >>> 'SQLGetPrivateProfileString' follows non-static declaration >>> /usr/local/include/odbcinst.h:210: error: previous declaration of >>> 'SQLGetPrivateProfileString' was here >> >> Is quite expected, is finding the declaration but not the function. >> Trying to remove the odbcinst.h should make it compile. >> Better to have a 64 bit unixODBC ! >> >>> make: The error code from the last command is 1. >>> Stop. >>> make: The error code from the last command is 1. >>> Stop. >>> make: The error code from the last command is 2. >>> Stop. >>> make: The error code from the last command is 1. >>> Stop. >>> make: The error code from the last command is 1. >>> Stop. >>> >>> Not sure if this is really the path I should go down. This seems like >>> I just have multiple libraries defining SQLGetPrivateProfileString >>> but I only see one in my library path. That is the one from unixodbc >>> at /usr/local/include/ >> >> If you have autoconf installed in the system you can try with >> >> autoreconf -if >> >> command before configure to see if you can get a working libtool. >> >> Or I can try to make a distribution from a recent system and send to you to try a new libtool. >> >> Frediano >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> http://lists.ibiblio.org/mailman/listinfo/freetds >> ********************************************************** >> Electronic Mail is not secure, may not be read every day, and should >> not be used for urgent or sensitive issues >> >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> http://lists.ibiblio.org/mailman/listinfo/freetds > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > ********************************************************** > Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From sf at 4js.com Wed Sep 23 05:46:48 2015 From: sf at 4js.com (Sebastien FLAESCH) Date: Wed, 23 Sep 2015 11:46:48 +0200 Subject: [freetds] Build issue on AIX (invalid connection) In-Reply-To: References: <56016EBD.40903@4js.com> <56016F04.8080903@4js.com> <560170EC.6090002@4js.com> Message-ID: <56027508.2010402@4js.com> Cool! Thanks a lot Tyler, will try this and let you know if it solves the problem on our AIX. Seb On 09/22/2015 06:56 PM, Worman, Tyler wrote: > I was able to fix this by building GNU libiconv and then build FreeTDS against that. After that, it runs and connects without the odd "L" error message. The TDS_DUMP also no longer complains about iconv. > > To get libiconv to build I needed to set the following: > > export OBJECT_MODE=64 > env CC=gcc CFLAGS="-maix64 -I/usr/local/include" AR_FLAGS="-X64 cru" /configure --prefix=/home/tworman/local64/ > make > make install > > -----Original Message----- > From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of Sebastien FLAESCH > Sent: Tuesday, September 22, 2015 11:17 AM > To: freetds at lists.ibiblio.org > Subject: Re: [freetds] Build issue on AIX (invalid connection) > > And here is the TDSDUMP (0.95-rc3)... > Seb > > On 09/22/2015 05:08 PM, Sebastien FLAESCH wrote: >> Also tested with 0.95-rc3 by the way. >> Seb >> >> On 09/22/2015 05:07 PM, Sebastien FLAESCH wrote: >>> Trying to build 0.95.5 on AIX 6.1 in 64bit mode... >>> >>> $ export OBJECT_MODE=64 >>> >>> $ CC="gcc -maix64" CXX="g++ -maix64" LDFLAGS="-maix64" ./configure >>> --prefix=$FTMDIR --with-odbc-nodm=/dbs/64bits/uxo/2.3.1 >>> >>> Note that we are using unixODBC 2.3.1, and we don't want to use >>> unixODBC as we link directly with libtdsodbc.a/.so ... >>> >>> A simple connection fails and SQLGetDiagRec() returns a strange error message: >>> >>> SQL State: 42000 >>> SQL code : 18456 >>> Message : [FreeTDS][SQL Server]L >>> >>> SQL SERVER error 18456 is an invalid user/login issue, but when I >>> switch to an older version of FreeTDS (0.92), same data source + >>> username + login connects without problem... >>> >>> Any ideas? >>> >>> I suspect some unixODBC defines problem... >>> >>> Any way to check that the unixODBC defines (32b/64b SQLLEN) match? >>> >>> sizeof(SQLLEN) = 8 >>> >>> Seb >>> _______________________________________________ >>> FreeTDS mailing list >>> FreeTDS at lists.ibiblio.org >>> http://lists.ibiblio.org/mailman/listinfo/freetds >>> >> >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> http://lists.ibiblio.org/mailman/listinfo/freetds >> > > ********************************************************** > Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > From freddy77 at gmail.com Wed Sep 23 12:24:52 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Wed, 23 Sep 2015 17:24:52 +0100 Subject: [freetds] FreeTDS build on AIX - No shared objects (.so) generated? In-Reply-To: References: Message-ID: Looking at libtool changes it looks like newer libtool could help. Yesterday I updated the libtool used to produce snapshort to last stable version (2.4.6, previously was 2.4.2). This new version add an extra --with-aix-soname option to the configure script. Could you try to download the last snapshot, add a "--with-aix-soname=srv4" or a "--with-aix-soname=both" to configure command and try make + make install again? Frediano 2015-09-22 22:41 GMT+01:00 Worman, Tyler : > The problem here with the copying is actually on the FreeTDS side. Sorry the first email might not have been clear. > > Similar things happen with UnixODBC. I'll email the maintainer just in case. Thanks! > > I'm not so sure it's is either package vs how AIX's libtool handles what configure produces. > With both UnixODBC and FreeTDS the .so files are not copied from the .libs folders on AIX7.1. > > Wanted to document it here in case anyone else runs into a similar problem. > > - Tyler > > -----Original Message----- > From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of Igor Korot > Sent: Tuesday, September 22, 2015 8:59 AM > To: FreeTDS Development Group > Subject: Re: [freetds] FreeTDS build on AIX - No shared objects (.so) generated? > > Hi, > > On Tue, Sep 22, 2015 at 12:17 AM, Worman, Tyler wrote: >> Following up on how to get the 64 bit version building correctly on AIX. I don't have autoreconf available to me so I couldn't try that test. >> >> Built 64-bit UnixODBC first. It's located in /home/tworman/local64/ in this example. >> >> export OBJECT_MODE=64 >> export PATH=$PATH:/usr/ccs/bin >> >> env CC=gcc CFLAGS="-maix64 -I/usr/local/include" AR_FLAGS="-X64 cru" >> ARFLAGS="-X64 cru" ./configure --with-tdsver=8.0 >> --with-unixodbc=/home/tworman/local64 --prefix=/home/tworman/local64/ >> >> make >> make install >> >> The .so's still don't copy over on install. So I copied them from the .lib directory in the install to my lib directory and setup the links manually. >> >> In the new /local64/lib dir, I ran these... >> ln -sf libct.so.4 libct.so >> ln -sf libsybdb.so.5 libsybdb.so >> ln -sf libtdsodbc.so.0 libtdsodbc.so >> >> That builds the symlinks for the .so files and then it seems to work just fine. >> >> Thanks again.. > > You should send an email to unixodbc maintainer - Nick Gorham and ask him to fix the build. ;-) > > Thank you. > >> >> - Tyler >> >> -----Original Message----- >> From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of >> Frediano Ziglio >> Sent: Tuesday, September 15, 2015 2:47 PM >> To: FreeTDS Development Group >> Subject: Re: [freetds] FreeTDS build on AIX - No shared objects (.so) generated? >> >> 2015-09-15 18:39 GMT+01:00 Worman, Tyler : >>> Hi, >>> Trying to build FreeTDS (stable .95.19) on AIX 7100-03-05-1524. The .so files don't generate. Browsed online and tried a few suggested fixes for similar problems but no luck so far. Generated my own .so files from the .a that builds but it doesn't seem to work. Any advice? >>> >>> Using the following: >>> ./configure --with-unixodbc=/usr/local/ --prefix=/home/tworman/local >>> --with-tdsver=7.0 make make install >>> >>> Appears to complete but no .so files are generated in the directory /home/tworman/local/lib. I only get .a and .la files. >>> I tested tsql that was built. It worked and connected to my MS SQL Server instance fine. >>> >> >> tsql always works :) >> It use static linking so one less issue to solve! >> AIX is quite strange when it comes to shared libraries. The static library on AIX are not such different from static ones. >> >>> I then generated the .so from the .a with gcc -fpic -g -shared -o >>> libtdsodbc.so libtdsodbc.a I verified my config using osql. It's fine until it gets to the actual connection and invoking isql (Unixodbc 32-bit). >> >> osql do you mean the utility in src/apps, right? >> >>> I tried the exact same .odbc.ini from a Linux box with a build of FreeTDS there and it works fine. >>> >>> The OSQL test: >>> ./osql -S TEST -U accthere -P passwordhere >>> >>> That produces this but no dump. >>> [IM004][unixODBC][Driver Manager]Driver's SQLAllocHandle on >>> SQL_HANDLE_HENV failed >>> [ISQL]ERROR: Could not SQLConnect >>> sed: Cannot find or open file /tmp/osql.dump.51511686. >>> >>> If I do this instead, I still get no dump, and nothing is written to the file I specify. >>> TDSDUMPCONFIG=stderr TDSDUMP=~/local/bin/temp ./osql -S TEST -U >>> usernamhere -P passwordhere >>> >> >> could be is not loading the driver so these environment are not used. >> >>> Thanks! >>> >>> - Tyler >>> >>> >> >> It would be helpful to see the configure output to understand if something went wrong. >> >>> >>> >>> >>> >>> Semi-unrelated try of 64 bit build (even though UnixODBC is compiled with 32bit types). >>> export OBJECT_MODE=64 >>> export CFLAGS=-maix64 >>> export LIBPATH=/usr/local/lib >>> export LD_LIBRARY_PATH=/usr/local/lib export AR_FLAGS="-X64 cru" >>> export ARFLAGS="-X64 cru" >>> ./configure --with-tdsver=7.0 --with-unixodbc=/usr/local >>> --prefix=/home/tworman/local >>> >>> Configure is fine but build of this fails with: >>> Making all in . >>> CC odbc.lo >>> odbc.c: In function '_SQLRowCount': >>> odbc.c:4630: warning: visibility attribute not supported in this configuration; ignored >>> CC connectparams.lo >>> connectparams.c:96: error: static declaration of >>> 'SQLGetPrivateProfileString' follows non-static declaration >>> /usr/local/include/odbcinst.h:210: error: previous declaration of >>> 'SQLGetPrivateProfileString' was here >> >> Is quite expected, is finding the declaration but not the function. >> Trying to remove the odbcinst.h should make it compile. >> Better to have a 64 bit unixODBC ! >> >>> make: The error code from the last command is 1. >>> Stop. >>> make: The error code from the last command is 1. >>> Stop. >>> make: The error code from the last command is 2. >>> Stop. >>> make: The error code from the last command is 1. >>> Stop. >>> make: The error code from the last command is 1. >>> Stop. >>> >>> Not sure if this is really the path I should go down. This seems like >>> I just have multiple libraries defining SQLGetPrivateProfileString >>> but I only see one in my library path. That is the one from unixodbc >>> at /usr/local/include/ >> >> If you have autoconf installed in the system you can try with >> >> autoreconf -if >> >> command before configure to see if you can get a working libtool. >> >> Or I can try to make a distribution from a recent system and send to you to try a new libtool. >> >> Frediano >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> http://lists.ibiblio.org/mailman/listinfo/freetds >> ********************************************************** >> Electronic Mail is not secure, may not be read every day, and should >> not be used for urgent or sensitive issues >> >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> http://lists.ibiblio.org/mailman/listinfo/freetds > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > ********************************************************** > Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From tworman at med.umich.edu Thu Sep 24 09:28:35 2015 From: tworman at med.umich.edu (Worman, Tyler) Date: Thu, 24 Sep 2015 13:28:35 +0000 Subject: [freetds] FreeTDS build on AIX - No shared objects (.so) generated? In-Reply-To: References: Message-ID: I tried the latest snapshot freetds-dev.0.99.375 with my existing base libraries on the system. If I need to update my local libtool command to do these tests we may be out of luck. I've not been able to get libtool to even configure. It needs a newer m4 and I can't get that to build at present. With --with-aix-soname=srv4 env CC=gcc CFLAGS="-maix64 -I/usr/local/include" AR_FLAGS="-X64 cru" ARFLAGS="-X64 cru" ./configure --with-tdsver=8.0 --with-unixodbc=/home/tworman/local64 --with-aix-soname=srv4 --prefix=/home/tworman/localtest/ Configure fails: Unknown argument to --with-aix-soname With --with-aix-soname=both env CC=gcc CFLAGS="-maix64 -I/usr/local/include" AR_FLAGS="-X64 cru" ARFLAGS="-X64 cru" ./configure --with-tdsver=8.0 --with-unixodbc=/home/tworman/local64 --prefix=/home/tworman/localtest/ "--with-aix-soname=both The configure is fine but make fails with: ctutil.c: In function '_ct_handle_server_message': ctutil.c:175: warning: visibility attribute not supported in this configuration; ignored CCLD libct.la strip: .libs/libct.a.d/shr_64.o -- 0654-400 Cannot open file. No such file or directory make: The error code from the last command is 255. Stop. make: The error code from the last command is 1. -----Original Message----- From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of Frediano Ziglio Sent: Wednesday, September 23, 2015 12:25 PM To: FreeTDS Development Group Subject: Re: [freetds] FreeTDS build on AIX - No shared objects (.so) generated? Looking at libtool changes it looks like newer libtool could help. Yesterday I updated the libtool used to produce snapshort to last stable version (2.4.6, previously was 2.4.2). This new version add an extra --with-aix-soname option to the configure script. Could you try to download the last snapshot, add a "--with-aix-soname=srv4" or a "--with-aix-soname=both" to configure command and try make + make install again? Frediano 2015-09-22 22:41 GMT+01:00 Worman, Tyler : > The problem here with the copying is actually on the FreeTDS side. Sorry the first email might not have been clear. > > Similar things happen with UnixODBC. I'll email the maintainer just in case. Thanks! > > I'm not so sure it's is either package vs how AIX's libtool handles what configure produces. > With both UnixODBC and FreeTDS the .so files are not copied from the .libs folders on AIX7.1. > > Wanted to document it here in case anyone else runs into a similar problem. > > - Tyler > > -----Original Message----- > From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of > Igor Korot > Sent: Tuesday, September 22, 2015 8:59 AM > To: FreeTDS Development Group > Subject: Re: [freetds] FreeTDS build on AIX - No shared objects (.so) generated? > > Hi, > > On Tue, Sep 22, 2015 at 12:17 AM, Worman, Tyler wrote: >> Following up on how to get the 64 bit version building correctly on AIX. I don't have autoreconf available to me so I couldn't try that test. >> >> Built 64-bit UnixODBC first. It's located in /home/tworman/local64/ in this example. >> >> export OBJECT_MODE=64 >> export PATH=$PATH:/usr/ccs/bin >> >> env CC=gcc CFLAGS="-maix64 -I/usr/local/include" AR_FLAGS="-X64 cru" >> ARFLAGS="-X64 cru" ./configure --with-tdsver=8.0 >> --with-unixodbc=/home/tworman/local64 --prefix=/home/tworman/local64/ >> >> make >> make install >> >> The .so's still don't copy over on install. So I copied them from the .lib directory in the install to my lib directory and setup the links manually. >> >> In the new /local64/lib dir, I ran these... >> ln -sf libct.so.4 libct.so >> ln -sf libsybdb.so.5 libsybdb.so >> ln -sf libtdsodbc.so.0 libtdsodbc.so >> >> That builds the symlinks for the .so files and then it seems to work just fine. >> >> Thanks again.. > > You should send an email to unixodbc maintainer - Nick Gorham and ask > him to fix the build. ;-) > > Thank you. > >> >> - Tyler >> >> -----Original Message----- >> From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of >> Frediano Ziglio >> Sent: Tuesday, September 15, 2015 2:47 PM >> To: FreeTDS Development Group >> Subject: Re: [freetds] FreeTDS build on AIX - No shared objects (.so) generated? >> >> 2015-09-15 18:39 GMT+01:00 Worman, Tyler : >>> Hi, >>> Trying to build FreeTDS (stable .95.19) on AIX 7100-03-05-1524. The .so files don't generate. Browsed online and tried a few suggested fixes for similar problems but no luck so far. Generated my own .so files from the .a that builds but it doesn't seem to work. Any advice? >>> >>> Using the following: >>> ./configure --with-unixodbc=/usr/local/ --prefix=/home/tworman/local >>> --with-tdsver=7.0 make make install >>> >>> Appears to complete but no .so files are generated in the directory /home/tworman/local/lib. I only get .a and .la files. >>> I tested tsql that was built. It worked and connected to my MS SQL Server instance fine. >>> >> >> tsql always works :) >> It use static linking so one less issue to solve! >> AIX is quite strange when it comes to shared libraries. The static library on AIX are not such different from static ones. >> >>> I then generated the .so from the .a with gcc -fpic -g -shared -o >>> libtdsodbc.so libtdsodbc.a I verified my config using osql. It's fine until it gets to the actual connection and invoking isql (Unixodbc 32-bit). >> >> osql do you mean the utility in src/apps, right? >> >>> I tried the exact same .odbc.ini from a Linux box with a build of FreeTDS there and it works fine. >>> >>> The OSQL test: >>> ./osql -S TEST -U accthere -P passwordhere >>> >>> That produces this but no dump. >>> [IM004][unixODBC][Driver Manager]Driver's SQLAllocHandle on >>> SQL_HANDLE_HENV failed >>> [ISQL]ERROR: Could not SQLConnect >>> sed: Cannot find or open file /tmp/osql.dump.51511686. >>> >>> If I do this instead, I still get no dump, and nothing is written to the file I specify. >>> TDSDUMPCONFIG=stderr TDSDUMP=~/local/bin/temp ./osql -S TEST -U >>> usernamhere -P passwordhere >>> >> >> could be is not loading the driver so these environment are not used. >> >>> Thanks! >>> >>> - Tyler >>> >>> >> >> It would be helpful to see the configure output to understand if something went wrong. >> >>> >>> >>> >>> >>> Semi-unrelated try of 64 bit build (even though UnixODBC is compiled with 32bit types). >>> export OBJECT_MODE=64 >>> export CFLAGS=-maix64 >>> export LIBPATH=/usr/local/lib >>> export LD_LIBRARY_PATH=/usr/local/lib export AR_FLAGS="-X64 cru" >>> export ARFLAGS="-X64 cru" >>> ./configure --with-tdsver=7.0 --with-unixodbc=/usr/local >>> --prefix=/home/tworman/local >>> >>> Configure is fine but build of this fails with: >>> Making all in . >>> CC odbc.lo >>> odbc.c: In function '_SQLRowCount': >>> odbc.c:4630: warning: visibility attribute not supported in this configuration; ignored >>> CC connectparams.lo >>> connectparams.c:96: error: static declaration of >>> 'SQLGetPrivateProfileString' follows non-static declaration >>> /usr/local/include/odbcinst.h:210: error: previous declaration of >>> 'SQLGetPrivateProfileString' was here >> >> Is quite expected, is finding the declaration but not the function. >> Trying to remove the odbcinst.h should make it compile. >> Better to have a 64 bit unixODBC ! >> >>> make: The error code from the last command is 1. >>> Stop. >>> make: The error code from the last command is 1. >>> Stop. >>> make: The error code from the last command is 2. >>> Stop. >>> make: The error code from the last command is 1. >>> Stop. >>> make: The error code from the last command is 1. >>> Stop. >>> >>> Not sure if this is really the path I should go down. This seems >>> like I just have multiple libraries defining >>> SQLGetPrivateProfileString but I only see one in my library path. >>> That is the one from unixodbc at /usr/local/include/ >> >> If you have autoconf installed in the system you can try with >> >> autoreconf -if >> >> command before configure to see if you can get a working libtool. >> >> Or I can try to make a distribution from a recent system and send to you to try a new libtool. >> >> Frediano >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> http://lists.ibiblio.org/mailman/listinfo/freetds >> ********************************************************** >> Electronic Mail is not secure, may not be read every day, and should >> not be used for urgent or sensitive issues >> >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> http://lists.ibiblio.org/mailman/listinfo/freetds > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > ********************************************************** > Electronic Mail is not secure, may not be read every day, and should > not be used for urgent or sensitive issues > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds _______________________________________________ FreeTDS mailing list FreeTDS at lists.ibiblio.org http://lists.ibiblio.org/mailman/listinfo/freetds ********************************************************** Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues From tworman at med.umich.edu Thu Sep 24 09:19:58 2015 From: tworman at med.umich.edu (Worman, Tyler) Date: Thu, 24 Sep 2015 13:19:58 +0000 Subject: [freetds] FreeTDS build on AIX - No shared objects (.so) generated? In-Reply-To: References: Message-ID: Using -brtl as LD_FLAGS to build FreeTDS, I still get no .so files moved on make install. export OBJECT_MODE=64 export PATH=$PATH:/usr/ccs/bin env CC=gcc CFLAGS="-maix64 -I/usr/local/include" LD_FLAGS="-brtl" AR_FLAGS="-X64 cru" ARFLAGS="-X64 cru" ./configure --with-tdsver=8.0 --with-unixodbc=/home/tworman/local64 --prefix=/home/tworman/localtest/ make make install ~~~~~~~~~~~~~~~~~ The attached Libtool and the Libsysdba.la was pulled from my successful 64 bit build without using -brtl. Let me know if it helps to have those files with using the -brtl also. Libsysdba.la: # libsybdb.la - a libtool library file # Generated by libtool (GNU libtool) 2.4.2 # # Please DO NOT delete this file! # It is necessary for linking the library. # The name that we can dlopen(3). dlname='libsybdb.so.5' # Names of this library. library_names='libsybdb.a libsybdb.a' # The name of the static archive. old_library='' # Linker flags that can not go in dependency_libs. inherited_linker_flags='' # Libraries that this one depends upon. dependency_libs=' -L/home/tworman/local64/lib -lpthreads' # Names of additional weak libraries provided by this library weak_library_names='' # Version information for libsybdb. current=5 age=0 revision=0 # Is this an already installed library? installed=no # Should we warn about portability when linking against -modules? shouldnotlink=no # Files to dlopen/dlpreopen dlopen='' dlpreopen='' # Directory that this library needs to be installed in: libdir='/home/tworman/local64/lib' -----Original Message----- From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of Frediano Ziglio Sent: Tuesday, September 22, 2015 6:23 PM To: FreeTDS Development Group Subject: Re: [freetds] FreeTDS build on AIX - No shared objects (.so) generated? Looks like a libtool problem. Could you post (after the make): - the libtool file in the main directory - src/dblib/libsybdb.la I would ask config.log too but I'm not sure could contain private information. Could you also try to define LDFLAGS to "-brtl" (before configure) ? Frediano 2015-09-22 22:41 GMT+01:00 Worman, Tyler : > The problem here with the copying is actually on the FreeTDS side. Sorry the first email might not have been clear. > > Similar things happen with UnixODBC. I'll email the maintainer just in case. Thanks! > > I'm not so sure it's is either package vs how AIX's libtool handles what configure produces. > With both UnixODBC and FreeTDS the .so files are not copied from the .libs folders on AIX7.1. > > Wanted to document it here in case anyone else runs into a similar problem. > > - Tyler > > -----Original Message----- > From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of > Igor Korot > Sent: Tuesday, September 22, 2015 8:59 AM > To: FreeTDS Development Group > Subject: Re: [freetds] FreeTDS build on AIX - No shared objects (.so) generated? > > Hi, > > On Tue, Sep 22, 2015 at 12:17 AM, Worman, Tyler wrote: >> Following up on how to get the 64 bit version building correctly on AIX. I don't have autoreconf available to me so I couldn't try that test. >> >> Built 64-bit UnixODBC first. It's located in /home/tworman/local64/ in this example. >> >> export OBJECT_MODE=64 >> export PATH=$PATH:/usr/ccs/bin >> >> env CC=gcc CFLAGS="-maix64 -I/usr/local/include" AR_FLAGS="-X64 cru" >> ARFLAGS="-X64 cru" ./configure --with-tdsver=8.0 >> --with-unixodbc=/home/tworman/local64 --prefix=/home/tworman/local64/ >> >> make >> make install >> >> The .so's still don't copy over on install. So I copied them from the .lib directory in the install to my lib directory and setup the links manually. >> >> In the new /local64/lib dir, I ran these... >> ln -sf libct.so.4 libct.so >> ln -sf libsybdb.so.5 libsybdb.so >> ln -sf libtdsodbc.so.0 libtdsodbc.so >> >> That builds the symlinks for the .so files and then it seems to work just fine. >> >> Thanks again.. > > You should send an email to unixodbc maintainer - Nick Gorham and ask > him to fix the build. ;-) > > Thank you. > >> >> - Tyler >> >> -----Original Message----- >> From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of >> Frediano Ziglio >> Sent: Tuesday, September 15, 2015 2:47 PM >> To: FreeTDS Development Group >> Subject: Re: [freetds] FreeTDS build on AIX - No shared objects (.so) generated? >> >> 2015-09-15 18:39 GMT+01:00 Worman, Tyler : >>> Hi, >>> Trying to build FreeTDS (stable .95.19) on AIX 7100-03-05-1524. The .so files don't generate. Browsed online and tried a few suggested fixes for similar problems but no luck so far. Generated my own .so files from the .a that builds but it doesn't seem to work. Any advice? >>> >>> Using the following: >>> ./configure --with-unixodbc=/usr/local/ --prefix=/home/tworman/local >>> --with-tdsver=7.0 make make install >>> >>> Appears to complete but no .so files are generated in the directory /home/tworman/local/lib. I only get .a and .la files. >>> I tested tsql that was built. It worked and connected to my MS SQL Server instance fine. >>> >> >> tsql always works :) >> It use static linking so one less issue to solve! >> AIX is quite strange when it comes to shared libraries. The static library on AIX are not such different from static ones. >> >>> I then generated the .so from the .a with gcc -fpic -g -shared -o >>> libtdsodbc.so libtdsodbc.a I verified my config using osql. It's fine until it gets to the actual connection and invoking isql (Unixodbc 32-bit). >> >> osql do you mean the utility in src/apps, right? >> >>> I tried the exact same .odbc.ini from a Linux box with a build of FreeTDS there and it works fine. >>> >>> The OSQL test: >>> ./osql -S TEST -U accthere -P passwordhere >>> >>> That produces this but no dump. >>> [IM004][unixODBC][Driver Manager]Driver's SQLAllocHandle on >>> SQL_HANDLE_HENV failed >>> [ISQL]ERROR: Could not SQLConnect >>> sed: Cannot find or open file /tmp/osql.dump.51511686. >>> >>> If I do this instead, I still get no dump, and nothing is written to the file I specify. >>> TDSDUMPCONFIG=stderr TDSDUMP=~/local/bin/temp ./osql -S TEST -U >>> usernamhere -P passwordhere >>> >> >> could be is not loading the driver so these environment are not used. >> >>> Thanks! >>> >>> - Tyler >>> >>> >> >> It would be helpful to see the configure output to understand if something went wrong. >> >>> >>> >>> >>> >>> Semi-unrelated try of 64 bit build (even though UnixODBC is compiled with 32bit types). >>> export OBJECT_MODE=64 >>> export CFLAGS=-maix64 >>> export LIBPATH=/usr/local/lib >>> export LD_LIBRARY_PATH=/usr/local/lib export AR_FLAGS="-X64 cru" >>> export ARFLAGS="-X64 cru" >>> ./configure --with-tdsver=7.0 --with-unixodbc=/usr/local >>> --prefix=/home/tworman/local >>> >>> Configure is fine but build of this fails with: >>> Making all in . >>> CC odbc.lo >>> odbc.c: In function '_SQLRowCount': >>> odbc.c:4630: warning: visibility attribute not supported in this configuration; ignored >>> CC connectparams.lo >>> connectparams.c:96: error: static declaration of >>> 'SQLGetPrivateProfileString' follows non-static declaration >>> /usr/local/include/odbcinst.h:210: error: previous declaration of >>> 'SQLGetPrivateProfileString' was here >> >> Is quite expected, is finding the declaration but not the function. >> Trying to remove the odbcinst.h should make it compile. >> Better to have a 64 bit unixODBC ! >> >>> make: The error code from the last command is 1. >>> Stop. >>> make: The error code from the last command is 1. >>> Stop. >>> make: The error code from the last command is 2. >>> Stop. >>> make: The error code from the last command is 1. >>> Stop. >>> make: The error code from the last command is 1. >>> Stop. >>> >>> Not sure if this is really the path I should go down. This seems >>> like I just have multiple libraries defining >>> SQLGetPrivateProfileString but I only see one in my library path. >>> That is the one from unixodbc at /usr/local/include/ >> >> If you have autoconf installed in the system you can try with >> >> autoreconf -if >> >> command before configure to see if you can get a working libtool. >> >> Or I can try to make a distribution from a recent system and send to you to try a new libtool. >> >> Frediano >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> http://lists.ibiblio.org/mailman/listinfo/freetds >> ********************************************************** >> Electronic Mail is not secure, may not be read every day, and should >> not be used for urgent or sensitive issues >> >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> http://lists.ibiblio.org/mailman/listinfo/freetds > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > ********************************************************** > Electronic Mail is not secure, may not be read every day, and should > not be used for urgent or sensitive issues > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds _______________________________________________ FreeTDS mailing list FreeTDS at lists.ibiblio.org http://lists.ibiblio.org/mailman/listinfo/freetds ********************************************************** Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: libtool.txt URL: From freddy77 at gmail.com Thu Sep 24 15:34:37 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Thu, 24 Sep 2015 20:34:37 +0100 Subject: [freetds] FreeTDS build on AIX - No shared objects (.so) generated? In-Reply-To: References: Message-ID: 2015-09-24 14:28 GMT+01:00 Worman, Tyler : > I tried the latest snapshot freetds-dev.0.99.375 with my existing base libraries on the system. If I need to update my local libtool command to do these tests we may be out of luck. I've not been able to get libtool to even configure. It needs a newer m4 and I can't get that to build at present. > > > With --with-aix-soname=srv4 > env CC=gcc CFLAGS="-maix64 -I/usr/local/include" AR_FLAGS="-X64 cru" ARFLAGS="-X64 cru" ./configure --with-tdsver=8.0 --with-unixodbc=/home/tworman/local64 --with-aix-soname=srv4 --prefix=/home/tworman/localtest/ > > Configure fails: Unknown argument to --with-aix-soname > Sorry, was svr4, not srv4 > With --with-aix-soname=both > env CC=gcc CFLAGS="-maix64 -I/usr/local/include" AR_FLAGS="-X64 cru" ARFLAGS="-X64 cru" ./configure --with-tdsver=8.0 --with-unixodbc=/home/tworman/local64 --prefix=/home/tworman/localtest/ "--with-aix-soname=both > > The configure is fine but make fails with: > ctutil.c: In function '_ct_handle_server_message': > ctutil.c:175: warning: visibility attribute not supported in this configuration; ignored > CCLD libct.la > strip: .libs/libct.a.d/shr_64.o -- 0654-400 Cannot open file. > No such file or directory > make: The error code from the last command is 255. > This is weird! > > Stop. > make: The error code from the last command is 1. > > I'm trying to undestand the libtool script. Looks like the -brtl should have some behaviour changes. On newer libtool even svr4 should do the work (use .so files instead of .a). I found this comment in libtool # Test if we are trying to use run time linking or normal # AIX style linking. If -brtl is somewhere in LDFLAGS, we # have runtime linking enabled, and use it for executables. # For shared libraries, we enable/disable runtime linking # depending on the kind of the shared library created - # when "with_aix_soname,aix_use_runtimelinking" is: # "aix,no" lib.a(lib.so.V) shared, rtl:no, for executables # "aix,yes" lib.so shared, rtl:yes, for executables # lib.a static archive # "both,no" lib.so.V(shr.o) shared, rtl:yes # lib.a(lib.so.V) shared, rtl:no, for executables # "both,yes" lib.so.V(shr.o) shared, rtl:yes, for executables # lib.a(lib.so.V) shared, rtl:no # "svr4,*" lib.so.V(shr.o) shared, rtl:yes, for executables # lib.a static archive Frediano > > -----Original Message----- > From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of Frediano Ziglio > Sent: Wednesday, September 23, 2015 12:25 PM > To: FreeTDS Development Group > Subject: Re: [freetds] FreeTDS build on AIX - No shared objects (.so) generated? > > Looking at libtool changes it looks like newer libtool could help. > > Yesterday I updated the libtool used to produce snapshort to last stable version (2.4.6, previously was 2.4.2). This new version add an extra --with-aix-soname option to the configure script. > > Could you try to download the last snapshot, add a "--with-aix-soname=srv4" or a "--with-aix-soname=both" to configure command and try make + make install again? > > Frediano > > > 2015-09-22 22:41 GMT+01:00 Worman, Tyler : >> The problem here with the copying is actually on the FreeTDS side. Sorry the first email might not have been clear. >> >> Similar things happen with UnixODBC. I'll email the maintainer just in case. Thanks! >> >> I'm not so sure it's is either package vs how AIX's libtool handles what configure produces. >> With both UnixODBC and FreeTDS the .so files are not copied from the .libs folders on AIX7.1. >> >> Wanted to document it here in case anyone else runs into a similar problem. >> >> - Tyler >> >> -----Original Message----- >> From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of >> Igor Korot >> Sent: Tuesday, September 22, 2015 8:59 AM >> To: FreeTDS Development Group >> Subject: Re: [freetds] FreeTDS build on AIX - No shared objects (.so) generated? >> >> Hi, >> >> On Tue, Sep 22, 2015 at 12:17 AM, Worman, Tyler wrote: >>> Following up on how to get the 64 bit version building correctly on AIX. I don't have autoreconf available to me so I couldn't try that test. >>> >>> Built 64-bit UnixODBC first. It's located in /home/tworman/local64/ in this example. >>> >>> export OBJECT_MODE=64 >>> export PATH=$PATH:/usr/ccs/bin >>> >>> env CC=gcc CFLAGS="-maix64 -I/usr/local/include" AR_FLAGS="-X64 cru" >>> ARFLAGS="-X64 cru" ./configure --with-tdsver=8.0 >>> --with-unixodbc=/home/tworman/local64 --prefix=/home/tworman/local64/ >>> >>> make >>> make install >>> >>> The .so's still don't copy over on install. So I copied them from the .lib directory in the install to my lib directory and setup the links manually. >>> >>> In the new /local64/lib dir, I ran these... >>> ln -sf libct.so.4 libct.so >>> ln -sf libsybdb.so.5 libsybdb.so >>> ln -sf libtdsodbc.so.0 libtdsodbc.so >>> >>> That builds the symlinks for the .so files and then it seems to work just fine. >>> >>> Thanks again.. >> >> You should send an email to unixodbc maintainer - Nick Gorham and ask >> him to fix the build. ;-) >> >> Thank you. >> >>> >>> - Tyler >>> >>> -----Original Message----- >>> From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of >>> Frediano Ziglio >>> Sent: Tuesday, September 15, 2015 2:47 PM >>> To: FreeTDS Development Group >>> Subject: Re: [freetds] FreeTDS build on AIX - No shared objects (.so) generated? >>> >>> 2015-09-15 18:39 GMT+01:00 Worman, Tyler : >>>> Hi, >>>> Trying to build FreeTDS (stable .95.19) on AIX 7100-03-05-1524. The .so files don't generate. Browsed online and tried a few suggested fixes for similar problems but no luck so far. Generated my own .so files from the .a that builds but it doesn't seem to work. Any advice? >>>> >>>> Using the following: >>>> ./configure --with-unixodbc=/usr/local/ --prefix=/home/tworman/local >>>> --with-tdsver=7.0 make make install >>>> >>>> Appears to complete but no .so files are generated in the directory /home/tworman/local/lib. I only get .a and .la files. >>>> I tested tsql that was built. It worked and connected to my MS SQL Server instance fine. >>>> >>> >>> tsql always works :) >>> It use static linking so one less issue to solve! >>> AIX is quite strange when it comes to shared libraries. The static library on AIX are not such different from static ones. >>> >>>> I then generated the .so from the .a with gcc -fpic -g -shared -o >>>> libtdsodbc.so libtdsodbc.a I verified my config using osql. It's fine until it gets to the actual connection and invoking isql (Unixodbc 32-bit). >>> >>> osql do you mean the utility in src/apps, right? >>> >>>> I tried the exact same .odbc.ini from a Linux box with a build of FreeTDS there and it works fine. >>>> >>>> The OSQL test: >>>> ./osql -S TEST -U accthere -P passwordhere >>>> >>>> That produces this but no dump. >>>> [IM004][unixODBC][Driver Manager]Driver's SQLAllocHandle on >>>> SQL_HANDLE_HENV failed >>>> [ISQL]ERROR: Could not SQLConnect >>>> sed: Cannot find or open file /tmp/osql.dump.51511686. >>>> >>>> If I do this instead, I still get no dump, and nothing is written to the file I specify. >>>> TDSDUMPCONFIG=stderr TDSDUMP=~/local/bin/temp ./osql -S TEST -U >>>> usernamhere -P passwordhere >>>> >>> >>> could be is not loading the driver so these environment are not used. >>> >>>> Thanks! >>>> >>>> - Tyler >>>> >>>> >>> >>> It would be helpful to see the configure output to understand if something went wrong. >>> >>>> >>>> >>>> >>>> >>>> Semi-unrelated try of 64 bit build (even though UnixODBC is compiled with 32bit types). >>>> export OBJECT_MODE=64 >>>> export CFLAGS=-maix64 >>>> export LIBPATH=/usr/local/lib >>>> export LD_LIBRARY_PATH=/usr/local/lib export AR_FLAGS="-X64 cru" >>>> export ARFLAGS="-X64 cru" >>>> ./configure --with-tdsver=7.0 --with-unixodbc=/usr/local >>>> --prefix=/home/tworman/local >>>> >>>> Configure is fine but build of this fails with: >>>> Making all in . >>>> CC odbc.lo >>>> odbc.c: In function '_SQLRowCount': >>>> odbc.c:4630: warning: visibility attribute not supported in this configuration; ignored >>>> CC connectparams.lo >>>> connectparams.c:96: error: static declaration of >>>> 'SQLGetPrivateProfileString' follows non-static declaration >>>> /usr/local/include/odbcinst.h:210: error: previous declaration of >>>> 'SQLGetPrivateProfileString' was here >>> >>> Is quite expected, is finding the declaration but not the function. >>> Trying to remove the odbcinst.h should make it compile. >>> Better to have a 64 bit unixODBC ! >>> >>>> make: The error code from the last command is 1. >>>> Stop. >>>> make: The error code from the last command is 1. >>>> Stop. >>>> make: The error code from the last command is 2. >>>> Stop. >>>> make: The error code from the last command is 1. >>>> Stop. >>>> make: The error code from the last command is 1. >>>> Stop. >>>> >>>> Not sure if this is really the path I should go down. This seems >>>> like I just have multiple libraries defining >>>> SQLGetPrivateProfileString but I only see one in my library path. >>>> That is the one from unixodbc at /usr/local/include/ >>> >>> If you have autoconf installed in the system you can try with >>> >>> autoreconf -if >>> >>> command before configure to see if you can get a working libtool. >>> >>> Or I can try to make a distribution from a recent system and send to you to try a new libtool. >>> >>> Frediano >>> _______________________________________________ >>> FreeTDS mailing list >>> FreeTDS at lists.ibiblio.org >>> http://lists.ibiblio.org/mailman/listinfo/freetds >>> ********************************************************** >>> Electronic Mail is not secure, may not be read every day, and should >>> not be used for urgent or sensitive issues >>> >>> _______________________________________________ >>> FreeTDS mailing list >>> FreeTDS at lists.ibiblio.org >>> http://lists.ibiblio.org/mailman/listinfo/freetds >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> http://lists.ibiblio.org/mailman/listinfo/freetds >> ********************************************************** >> Electronic Mail is not secure, may not be read every day, and should >> not be used for urgent or sensitive issues >> >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> http://lists.ibiblio.org/mailman/listinfo/freetds > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > ********************************************************** > Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From sf at 4js.com Tue Sep 29 10:17:43 2015 From: sf at 4js.com (Sebastien FLAESCH) Date: Tue, 29 Sep 2015 16:17:43 +0200 Subject: [freetds] Build issue on AIX (invalid connection) In-Reply-To: <56027508.2010402@4js.com> References: <56016EBD.40903@4js.com> <56016F04.8080903@4js.com> <560170EC.6090002@4js.com> <56027508.2010402@4js.com> Message-ID: <560A9D87.4070602@4js.com> Hi all, a bit late, but I confirm that it fixed the problem. Seb On 09/23/2015 11:46 AM, Sebastien FLAESCH wrote: > Cool! > Thanks a lot Tyler, will try this and let you know if it solves the problem on our AIX. > Seb > > On 09/22/2015 06:56 PM, Worman, Tyler wrote: >> I was able to fix this by building GNU libiconv and then build FreeTDS against that. After that, it runs and connects without the odd "L" error >> message. The TDS_DUMP also no longer complains about iconv. >> >> To get libiconv to build I needed to set the following: >> >> export OBJECT_MODE=64 >> env CC=gcc CFLAGS="-maix64 -I/usr/local/include" AR_FLAGS="-X64 cru" /configure --prefix=/home/tworman/local64/ >> make >> make install >> >> -----Original Message----- >> From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of Sebastien FLAESCH >> Sent: Tuesday, September 22, 2015 11:17 AM >> To: freetds at lists.ibiblio.org >> Subject: Re: [freetds] Build issue on AIX (invalid connection) >> >> And here is the TDSDUMP (0.95-rc3)... >> Seb >> >> On 09/22/2015 05:08 PM, Sebastien FLAESCH wrote: >>> Also tested with 0.95-rc3 by the way. >>> Seb >>> >>> On 09/22/2015 05:07 PM, Sebastien FLAESCH wrote: >>>> Trying to build 0.95.5 on AIX 6.1 in 64bit mode... >>>> >>>> $ export OBJECT_MODE=64 >>>> >>>> $ CC="gcc -maix64" CXX="g++ -maix64" LDFLAGS="-maix64" ./configure >>>> --prefix=$FTMDIR --with-odbc-nodm=/dbs/64bits/uxo/2.3.1 >>>> >>>> Note that we are using unixODBC 2.3.1, and we don't want to use >>>> unixODBC as we link directly with libtdsodbc.a/.so ... >>>> >>>> A simple connection fails and SQLGetDiagRec() returns a strange error message: >>>> >>>> SQL State: 42000 >>>> SQL code : 18456 >>>> Message : [FreeTDS][SQL Server]L >>>> >>>> SQL SERVER error 18456 is an invalid user/login issue, but when I >>>> switch to an older version of FreeTDS (0.92), same data source + >>>> username + login connects without problem... >>>> >>>> Any ideas? >>>> >>>> I suspect some unixODBC defines problem... >>>> >>>> Any way to check that the unixODBC defines (32b/64b SQLLEN) match? >>>> >>>> sizeof(SQLLEN) = 8 >>>> >>>> Seb >>>> _______________________________________________ >>>> FreeTDS mailing list >>>> FreeTDS at lists.ibiblio.org >>>> http://lists.ibiblio.org/mailman/listinfo/freetds >>>> >>> >>> _______________________________________________ >>> FreeTDS mailing list >>> FreeTDS at lists.ibiblio.org >>> http://lists.ibiblio.org/mailman/listinfo/freetds >>> >> >> ********************************************************** >> Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues >> >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> http://lists.ibiblio.org/mailman/listinfo/freetds >> > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds >