From DJacopille at MFS.com Mon Oct 5 17:07:02 2015 From: DJacopille at MFS.com (Jacopille, David) Date: Mon, 5 Oct 2015 21:07:02 +0000 Subject: [freetds] Using FreeTDS 0.95 INSERTS fail above 66000 characters...unless 'dump file' is turned on Message-ID: Looking for suggestions or a troubleshooting approach on this 100% reproducible issue where FreeTDS logging seems to be the only variable. Since the issue goes away as soon as I turn on freetds logging I can?t look at the logs to find the problem. ENVIRONMENT SQL Server 2012 OS X 10.9.5 FreeTDS 0.95.20 DBD::Sybase 1.15 TDSVER 7.0 or 7.1 (same symptoms) Perl 5.16.3 FreeTDS text size = 1000000 Testing large string INSERTS to a table with a single, nvarchar(max), column WHAT WORKS A. With freetds logging on (via 'dump file = /tmp/freetds.log?) INSERT values from 0-500,000 characters are successful. Decreasing reliability above 500,000 characters. B. INSERT statements with values of 0 thru 66,000 characters always work, regardless of freetds logging on/off C. SELECT work correctly for all values 0 thru one million characters, regardless of freetds logging on/off DOES NOT WORK If freetds logging is turned off the following fails consistently: A. 67,000 character INSERT stalls at INSERT B. 100,000+ character INSERT doesn?t stall but doesn?t INSERT C. Stored Procedures also experiencing failures in same character ranges FREETDS.CONF # In the failure configuration it looks like this. # The ?DOES NOT WORK? symptoms go away if the last two lines are uncommented. [global] client charset = UTF-8 text size = 1000000 [bossqld4] host = bossqld4.mfs.com port = 1433 tds version = 7.0 #dump file = /tmp/freetds.log #dump file append = no PERL SCRIPT REPRODUCING ISSUE (WITH NO FREETDS LOGGING) use DBI qw(:sql_types); use DBD::Sybase; my ($sql, $dbh, $ref, $largetext); $dbh = DBI->connect( 'DBI:Sybase:server=bossqld4', ?CORP\user', ?password', { PrintError => 0 } ) or die; $dbh->do('use testdatabase'); $largetext = 'x' x 100000; # one hundred thousand characters $dbh->do(qq|INSERT into TESTTABLE (maxtext) values (N\'$largetext\')|); # SELECT not affected by FreeTDS logging on/off # SELECT always successful on all values tested up to one million characters (and probably much larger, but untested). $sql = q|SELECT TOP 1 [maxtext] FROM TESTTABLE|; $ref = $dbh->selectrow_arrayref($sql); print 'Length of value: '. (length $$ref[0]) ."\n"; $dbh->disconnect(); Thank you, Dave Jacopille Boston MFS Email system made the following annotation --------------------------------------------------------------------------------------------------------------------------------------- This email communication and any attachments may contain proprietary, confidential, or privileged information. If you are not the intended recipient, you are hereby notified that you have received this email in error and that any review, disclosure, dissemination, distribution or copying of it or its contents is prohibited. The sender does not waive confidentiality or any privilege by mistransmission. If you have received this email in error, please notify the sender immediately, delete this email, and destroy all copies and any attachments. From dchang at fsautomation.com Mon Oct 5 18:54:07 2015 From: dchang at fsautomation.com (David Chang) Date: Mon, 5 Oct 2015 15:54:07 -0700 Subject: [freetds] Using FreeTDS 0.95 INSERTS fail above 66000 characters...unless 'dump file' is turned on In-Reply-To: References: Message-ID: <5612FF8F.3080800@fsautomation.com> Dave, I see you set the text size in the freetds.conf file to 1000000. I would confirm it using 'select @@textsize'. DC On 10/5/2015 2:07 PM, Jacopille, David wrote: > Looking for suggestions or a troubleshooting approach on this 100% > reproducible issue where FreeTDS logging seems to be the only variable. > > Since the issue goes away as soon as I turn on freetds logging I can?t > look at the logs to find the problem. > > ENVIRONMENT > SQL Server 2012 > OS X 10.9.5 > FreeTDS 0.95.20 > DBD::Sybase 1.15 > TDSVER 7.0 or 7.1 (same symptoms) > Perl 5.16.3 > FreeTDS text size = 1000000 > > Testing large string INSERTS to a table with a single, nvarchar(max), > column > > > WHAT WORKS > A. With freetds logging on (via 'dump file = /tmp/freetds.log?) INSERT > values from 0-500,000 characters are successful. Decreasing reliability > above 500,000 characters. > > B. INSERT statements with values of 0 thru 66,000 characters always work, > regardless of freetds logging on/off > > C. SELECT work correctly for all values 0 thru one million characters, > regardless of freetds logging on/off > > > DOES NOT WORK > If freetds logging is turned off the following fails consistently: > > A. 67,000 character INSERT stalls at INSERT > > B. 100,000+ character INSERT doesn?t stall but doesn?t INSERT > > C. Stored Procedures also experiencing failures in same character ranges > > > FREETDS.CONF > > # In the failure configuration it looks like this. > # The ?DOES NOT WORK? symptoms go away if the last two lines are > uncommented. > > [global] > client charset = UTF-8 > text size = 1000000 > > [bossqld4] > host = bossqld4.mfs.com > port = 1433 > tds version = 7.0 > #dump file = /tmp/freetds.log > #dump file append = no > > > PERL SCRIPT REPRODUCING ISSUE (WITH NO FREETDS LOGGING) > > use DBI qw(:sql_types); > use DBD::Sybase; > my ($sql, $dbh, $ref, $largetext); > > $dbh = DBI->connect( 'DBI:Sybase:server=bossqld4', ?CORP\user', > ?password', { PrintError => 0 } ) or die; > $dbh->do('use testdatabase'); > > $largetext = 'x' x 100000; # one hundred thousand characters > > $dbh->do(qq|INSERT into TESTTABLE (maxtext) values (N\'$largetext\')|); > > # SELECT not affected by FreeTDS logging on/off > # SELECT always successful on all values tested up to one million > characters (and probably much larger, but untested). > > $sql = q|SELECT TOP 1 [maxtext] FROM TESTTABLE|; > $ref = $dbh->selectrow_arrayref($sql); > print 'Length of value: '. (length $$ref[0]) ."\n"; > > $dbh->disconnect(); > > > Thank you, > Dave Jacopille > Boston > > MFS Email system made the following annotation > --------------------------------------------------------------------------------------------------------------------------------------- > This email communication and any attachments may contain proprietary, confidential, or privileged information. If you are not the intended recipient, you are hereby notified that you have received this email in error and that any review, disclosure, dissemination, distribution or copying of it or its contents is prohibited. The sender does not waive confidentiality or any privilege by mistransmission. If you have received this email in error, please notify the sender immediately, delete this email, and destroy all copies and any attachments. > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From dchang at fsautomation.com Mon Oct 5 18:44:30 2015 From: dchang at fsautomation.com (David Chang) Date: Mon, 5 Oct 2015 15:44:30 -0700 Subject: [freetds] Using FreeTDS 0.95 INSERTS fail above 66000 characters...unless 'dump file' is turned on In-Reply-To: References: Message-ID: <5612FD4E.2060702@fsautomation.com> Dave, That number of 66000 sounds awfully close to the old Sybase DB-Lib DBTEXTSIZE value of 65536 (64K). However, I don't know why it works when you turn on logging. In Sybase, text data was written in chunks. I think you can set the TEXTSIZE value all the way up to 2GB. In old versions of SQL Server, there were some limits on the amount of text data that could be written interactively (via osql). Those limits may have been removed. I would look into increasing your TEXTSIZE value. DC On 10/5/2015 2:07 PM, Jacopille, David wrote: > Looking for suggestions or a troubleshooting approach on this 100% > reproducible issue where FreeTDS logging seems to be the only variable. > > Since the issue goes away as soon as I turn on freetds logging I can?t > look at the logs to find the problem. > > ENVIRONMENT > SQL Server 2012 > OS X 10.9.5 > FreeTDS 0.95.20 > DBD::Sybase 1.15 > TDSVER 7.0 or 7.1 (same symptoms) > Perl 5.16.3 > FreeTDS text size = 1000000 > > Testing large string INSERTS to a table with a single, nvarchar(max), > column > > > WHAT WORKS > A. With freetds logging on (via 'dump file = /tmp/freetds.log?) INSERT > values from 0-500,000 characters are successful. Decreasing reliability > above 500,000 characters. > > B. INSERT statements with values of 0 thru 66,000 characters always work, > regardless of freetds logging on/off > > C. SELECT work correctly for all values 0 thru one million characters, > regardless of freetds logging on/off > > > DOES NOT WORK > If freetds logging is turned off the following fails consistently: > > A. 67,000 character INSERT stalls at INSERT > > B. 100,000+ character INSERT doesn?t stall but doesn?t INSERT > > C. Stored Procedures also experiencing failures in same character ranges > > > FREETDS.CONF > > # In the failure configuration it looks like this. > # The ?DOES NOT WORK? symptoms go away if the last two lines are > uncommented. > > [global] > client charset = UTF-8 > text size = 1000000 > > [bossqld4] > host = bossqld4.mfs.com > port = 1433 > tds version = 7.0 > #dump file = /tmp/freetds.log > #dump file append = no > > > PERL SCRIPT REPRODUCING ISSUE (WITH NO FREETDS LOGGING) > > use DBI qw(:sql_types); > use DBD::Sybase; > my ($sql, $dbh, $ref, $largetext); > > $dbh = DBI->connect( 'DBI:Sybase:server=bossqld4', ?CORP\user', > ?password', { PrintError => 0 } ) or die; > $dbh->do('use testdatabase'); > > $largetext = 'x' x 100000; # one hundred thousand characters > > $dbh->do(qq|INSERT into TESTTABLE (maxtext) values (N\'$largetext\')|); > > # SELECT not affected by FreeTDS logging on/off > # SELECT always successful on all values tested up to one million > characters (and probably much larger, but untested). > > $sql = q|SELECT TOP 1 [maxtext] FROM TESTTABLE|; > $ref = $dbh->selectrow_arrayref($sql); > print 'Length of value: '. (length $$ref[0]) ."\n"; > > $dbh->disconnect(); > > > Thank you, > Dave Jacopille > Boston > > MFS Email system made the following annotation > --------------------------------------------------------------------------------------------------------------------------------------- > This email communication and any attachments may contain proprietary, confidential, or privileged information. If you are not the intended recipient, you are hereby notified that you have received this email in error and that any review, disclosure, dissemination, distribution or copying of it or its contents is prohibited. The sender does not waive confidentiality or any privilege by mistransmission. If you have received this email in error, please notify the sender immediately, delete this email, and destroy all copies and any attachments. > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From DJacopille at MFS.com Mon Oct 5 20:36:15 2015 From: DJacopille at MFS.com (Jacopille, David) Date: Tue, 6 Oct 2015 00:36:15 +0000 Subject: [freetds] Using FreeTDS 0.95 INSERTS fail above 66000 characters...unless 'dump file' is turned on In-Reply-To: <5612FF8F.3080800@fsautomation.com> References: <5612FF8F.3080800@fsautomation.com> Message-ID: DC - Thanks for the quick reply. Text size is positively set to one million characters. 1. The data SELECT of 500,000 characters always works. 2. SELECT @@textsize does confirm the 1,000,000 setting (but the above also proves functionality) 3. 'Text size' setting only applies to SELECT statements, not INSERT where we are having the issue. This is demonstrably true for MS SQL Server, which we are using. Don't know about other databases. SQL Server 2012 nvarchar(max) does hold 2 GB theoretical. This specific table and nvarchar(max) column has proven to handle far more than the 1 MB values I'm testing with. At least through other software. I suspect that there is a bug in either FreeTDS 0.95 or DBD::Sybase 1.15 that is limiting the text. However I find FreeTDS more suspicious because turning on logging (which changes something in FreeTDS) fixes the problem. Unfortunately the thing that would be useful to find the problem is what fixes the problem. Dave -----Original Message----- From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of David Chang Sent: Monday, October 05, 2015 6:54 PM To: FreeTDS Development Group Subject: Re: [freetds] Using FreeTDS 0.95 INSERTS fail above 66000 characters...unless 'dump file' is turned on Dave, I see you set the text size in the freetds.conf file to 1000000. I would confirm it using 'select @@textsize'. DC On 10/5/2015 2:07 PM, Jacopille, David wrote: > Looking for suggestions or a troubleshooting approach on this 100% > reproducible issue where FreeTDS logging seems to be the only variable. > > Since the issue goes away as soon as I turn on freetds logging I can?t > look at the logs to find the problem. > > ENVIRONMENT > SQL Server 2012 > OS X 10.9.5 > FreeTDS 0.95.20 > DBD::Sybase 1.15 > TDSVER 7.0 or 7.1 (same symptoms) > Perl 5.16.3 > FreeTDS text size = 1000000 > > Testing large string INSERTS to a table with a single, nvarchar(max), > column > > > WHAT WORKS > A. With freetds logging on (via 'dump file = /tmp/freetds.log?) INSERT > values from 0-500,000 characters are successful. Decreasing > reliability above 500,000 characters. > > B. INSERT statements with values of 0 thru 66,000 characters always > work, regardless of freetds logging on/off > > C. SELECT work correctly for all values 0 thru one million characters, > regardless of freetds logging on/off > > > DOES NOT WORK > If freetds logging is turned off the following fails consistently: > > A. 67,000 character INSERT stalls at INSERT > > B. 100,000+ character INSERT doesn?t stall but doesn?t INSERT > > C. Stored Procedures also experiencing failures in same character > ranges > > > FREETDS.CONF > > # In the failure configuration it looks like this. > # The ?DOES NOT WORK? symptoms go away if the last two lines are > uncommented. > > [global] > client charset = UTF-8 > text size = 1000000 > > [bossqld4] > host = bossqld4.mfs.com > port = 1433 > tds version = 7.0 > #dump file = /tmp/freetds.log > #dump file append = no > > > PERL SCRIPT REPRODUCING ISSUE (WITH NO FREETDS LOGGING) > > use DBI qw(:sql_types); > use DBD::Sybase; > my ($sql, $dbh, $ref, $largetext); > > $dbh = DBI->connect( 'DBI:Sybase:server=bossqld4', ?CORP\user', > ?password', { PrintError => 0 } ) or die; $dbh->do('use > testdatabase'); > > $largetext = 'x' x 100000; # one hundred thousand characters > > $dbh->do(qq|INSERT into TESTTABLE (maxtext) values > (N\'$largetext\')|); > > # SELECT not affected by FreeTDS logging on/off # SELECT always > successful on all values tested up to one million characters (and > probably much larger, but untested). > > $sql = q|SELECT TOP 1 [maxtext] FROM TESTTABLE|; $ref = > $dbh->selectrow_arrayref($sql); print 'Length of value: '. (length > $$ref[0]) ."\n"; > > $dbh->disconnect(); > > > Thank you, > Dave Jacopille > Boston > > MFS Email system made the following annotation > ---------------------------------------------------------------------- > ----------------------------------------------------------------- > This email communication and any attachments may contain proprietary, confidential, or privileged information. If you are not the intended recipient, you are hereby notified that you have received this email in error and that any review, disclosure, dissemination, distribution or copying of it or its contents is prohibited. The sender does not waive confidentiality or any privilege by mistransmission. If you have received this email in error, please notify the sender immediately, delete this email, and destroy all copies and any attachments. > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds _______________________________________________ FreeTDS mailing list FreeTDS at lists.ibiblio.org http://lists.ibiblio.org/mailman/listinfo/freetds MFS Email system made the following annotation --------------------------------------------------------------------------------------------------------------------------------------- This email communication and any attachments may contain proprietary, confidential, or privileged information. If you are not the intended recipient, you are hereby notified that you have received this email in error and that any review, disclosure, dissemination, distribution or copying of it or its contents is prohibited. The sender does not waive confidentiality or any privilege by mistransmission. If you have received this email in error, please notify the sender immediately, delete this email, and destroy all copies and any attachments. From no-reply at appveyor.com Tue Oct 6 03:34:28 2015 From: no-reply at appveyor.com (AppVeyor) Date: Tue, 06 Oct 2015 07:34:28 +0000 Subject: [freetds] Build failed: freetds 241 Message-ID: <20151006073428.2677.39082@appveyor.com> From no-reply at appveyor.com Tue Oct 6 08:04:49 2015 From: no-reply at appveyor.com (AppVeyor) Date: Tue, 06 Oct 2015 12:04:49 +0000 Subject: [freetds] Build completed: freetds 242 Message-ID: <20151006120449.449.14662@appveyor.com> From freddy77 at gmail.com Wed Oct 7 11:37:18 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Wed, 7 Oct 2015 16:37:18 +0100 Subject: [freetds] Using FreeTDS 0.95 INSERTS fail above 66000 characters...unless 'dump file' is turned on In-Reply-To: References: <5612FF8F.3080800@fsautomation.com> Message-ID: I won't be surprised if there are also some limit in sql server. You are sending the data inside a language query string. It's quite surprising changing log settings solve the issue, perhaps there is a bug inside Ctlib (DBD::Sybase should use ctlib). You can try using a packet sniffer to get traffic with the server. Can you post (or send to me if you prefer) the logs anyway? Probably you'd better compress them. From the log we can understand which calls DBD::Sybase does so I can try reproduce with C directly. Frediano 2015-10-06 1:36 GMT+01:00 Jacopille, David : > DC - Thanks for the quick reply. Text size is positively set to one million characters. > > 1. The data SELECT of 500,000 characters always works. > 2. SELECT @@textsize does confirm the 1,000,000 setting (but the above also proves functionality) > 3. 'Text size' setting only applies to SELECT statements, not INSERT where we are having the issue. This is demonstrably true for MS SQL Server, which we are using. Don't know about other databases. > > SQL Server 2012 nvarchar(max) does hold 2 GB theoretical. This specific table and nvarchar(max) column has proven to handle far more than the 1 MB values I'm testing with. At least through other software. > > I suspect that there is a bug in either FreeTDS 0.95 or DBD::Sybase 1.15 that is limiting the text. However I find FreeTDS more suspicious because turning on logging (which changes something in FreeTDS) fixes the problem. > > Unfortunately the thing that would be useful to find the problem is what fixes the problem. > > Dave > > -----Original Message----- > From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of David Chang > Sent: Monday, October 05, 2015 6:54 PM > To: FreeTDS Development Group > Subject: Re: [freetds] Using FreeTDS 0.95 INSERTS fail above 66000 characters...unless 'dump file' is turned on > > Dave, > > I see you set the text size in the freetds.conf file to 1000000. I would confirm it using 'select @@textsize'. > > DC > > On 10/5/2015 2:07 PM, Jacopille, David wrote: >> Looking for suggestions or a troubleshooting approach on this 100% >> reproducible issue where FreeTDS logging seems to be the only variable. >> >> Since the issue goes away as soon as I turn on freetds logging I can?t >> look at the logs to find the problem. >> >> ENVIRONMENT >> SQL Server 2012 >> OS X 10.9.5 >> FreeTDS 0.95.20 >> DBD::Sybase 1.15 >> TDSVER 7.0 or 7.1 (same symptoms) >> Perl 5.16.3 >> FreeTDS text size = 1000000 >> >> Testing large string INSERTS to a table with a single, nvarchar(max), >> column >> >> >> WHAT WORKS >> A. With freetds logging on (via 'dump file = /tmp/freetds.log?) INSERT >> values from 0-500,000 characters are successful. Decreasing >> reliability above 500,000 characters. >> >> B. INSERT statements with values of 0 thru 66,000 characters always >> work, regardless of freetds logging on/off >> >> C. SELECT work correctly for all values 0 thru one million characters, >> regardless of freetds logging on/off >> >> >> DOES NOT WORK >> If freetds logging is turned off the following fails consistently: >> >> A. 67,000 character INSERT stalls at INSERT >> >> B. 100,000+ character INSERT doesn?t stall but doesn?t INSERT >> >> C. Stored Procedures also experiencing failures in same character >> ranges >> >> >> FREETDS.CONF >> >> # In the failure configuration it looks like this. >> # The ?DOES NOT WORK? symptoms go away if the last two lines are >> uncommented. >> >> [global] >> client charset = UTF-8 >> text size = 1000000 >> >> [bossqld4] >> host = bossqld4.mfs.com >> port = 1433 >> tds version = 7.0 >> #dump file = /tmp/freetds.log >> #dump file append = no >> >> >> PERL SCRIPT REPRODUCING ISSUE (WITH NO FREETDS LOGGING) >> >> use DBI qw(:sql_types); >> use DBD::Sybase; >> my ($sql, $dbh, $ref, $largetext); >> >> $dbh = DBI->connect( 'DBI:Sybase:server=bossqld4', ?CORP\user', >> ?password', { PrintError => 0 } ) or die; $dbh->do('use >> testdatabase'); >> >> $largetext = 'x' x 100000; # one hundred thousand characters >> >> $dbh->do(qq|INSERT into TESTTABLE (maxtext) values >> (N\'$largetext\')|); >> >> # SELECT not affected by FreeTDS logging on/off # SELECT always >> successful on all values tested up to one million characters (and >> probably much larger, but untested). >> >> $sql = q|SELECT TOP 1 [maxtext] FROM TESTTABLE|; $ref = >> $dbh->selectrow_arrayref($sql); print 'Length of value: '. (length >> $$ref[0]) ."\n"; >> >> $dbh->disconnect(); >> >> >> Thank you, >> Dave Jacopille >> Boston >> >> MFS Email system made the following annotation >> ---------------------------------------------------------------------- >> ----------------------------------------------------------------- >> This email communication and any attachments may contain proprietary, confidential, or privileged information. If you are not the intended recipient, you are hereby notified that you have received this email in error and that any review, disclosure, dissemination, distribution or copying of it or its contents is prohibited. The sender does not waive confidentiality or any privilege by mistransmission. If you have received this email in error, please notify the sender immediately, delete this email, and destroy all copies and any attachments. >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> http://lists.ibiblio.org/mailman/listinfo/freetds > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > MFS Email system made the following annotation > --------------------------------------------------------------------------------------------------------------------------------------- > This email communication and any attachments may contain proprietary, confidential, or privileged information. If you are not the intended recipient, you are hereby notified that you have received this email in error and that any review, disclosure, dissemination, distribution or copying of it or its contents is prohibited. The sender does not waive confidentiality or any privilege by mistransmission. If you have received this email in error, please notify the sender immediately, delete this email, and destroy all copies and any attachments. > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From DJacopille at MFS.com Wed Oct 7 13:13:08 2015 From: DJacopille at MFS.com (Jacopille, David) Date: Wed, 7 Oct 2015 17:13:08 +0000 Subject: [freetds] Using FreeTDS 0.95 INSERTS fail above 66000 characters...unless 'dump file' is turned on In-Reply-To: References: <5612FF8F.3080800@fsautomation.com> Message-ID: Frediano, Below is the freetds.log that contains results from these three lines from the test script. The INSERT was successful since logging/debugging was turned on. It would not have been if logging was turned off. DBI->connect USE INSERT (string of 100000 ?x? characters) The logs recorded a lot of repetitive lines on INSERT of 100000 ?x? characters. To save space I removed the repetitive lines with nothing but x characters, like this example: .... 00 78 00 78 00 78 00 78-00 78 00 78 00 78 00 78 |.x.x.x.x .x.x.x.x| I also removed some of the repetitive packet retries for the long insert. Everything else, including that beginning of the INSERT should be there. Thank you for looking into this. Dave log.c:167:Starting log file for FreeTDS 0.95.20 on 2015-10-07 13:06:36 with debug flags 0x4fff. iconv.c:328:tds_iconv_open(0x7fa6f687a390, 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 168.66.122.143 port 1433 (TDS version 7.0) 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 login.c:788:using NTLM authentication for 'CORP\jacopille_d' account login.c:852:quietly sending TDS 7+ login packet token.c:326:tds_process_login_tokens() packet.c:639:Received packet 0000 04 01 00 e3 00 00 00 00-ed d8 00 4e 54 4c 4d 53 |........ ...NTLMS| 0010 53 50 00 02 00 00 00 08-00 08 00 38 00 00 00 05 |SP...... ...8....| 0020 82 89 02 f5 e6 ef 6b 26-25 0a 98 00 00 00 00 00 |......k& %.......| 0030 00 00 00 98 00 98 00 40-00 00 00 06 01 b1 1d 00 |.......@ ........| 0040 00 00 0f 43 00 4f 00 52-00 50 00 02 00 08 00 43 |...C.O.R .P.....C| 0050 00 4f 00 52 00 50 00 01-00 10 00 42 00 4f 00 53 |.O.R.P.. ...B.O.S| 0060 00 53 00 51 00 4c 00 44-00 34 00 04 00 18 00 63 |.S.Q.L.D .4.....c| 0070 00 6f 00 72 00 70 00 2e-00 6d 00 66 00 73 00 2e |.o.r.p.. .m.f.s..| 0080 00 63 00 6f 00 6d 00 03-00 2a 00 62 00 6f 00 73 |.c.o.m.. .*.b.o.s| 0090 00 73 00 71 00 6c 00 64-00 34 00 2e 00 63 00 6f |.s.q.l.d .4...c.o| 00a0 00 72 00 70 00 2e 00 6d-00 66 00 73 00 2e 00 63 |.r.p...m .f.s...c| 00b0 00 6f 00 6d 00 05 00 1a-00 77 00 69 00 6e 00 72 |.o.m.... .w.i.n.r| 00c0 00 6f 00 6f 00 74 00 2e-00 6c 00 6f 00 63 00 61 |.o.o.t.. .l.o.c.a| 00d0 00 6c 00 07 00 08 00 4e-2f 6c 86 22 01 d1 01 00 |.l.....N /l."....| 00e0 00 00 00 - |...| token.c:335:looking for login token, got ed(AUTH) token.c:115:tds_process_default_tokens() marker is ed(AUTH) token.c:463:TDS_AUTH_TOKEN PDU size 216 challenge.c:648:TDS_AUTH_TOKEN nonce 0000 f5 e6 ef 6b 26 25 0a 98- |...k&%..| challenge.c:702:Draining 0 bytes packet.c:740:Sending packet 0000 11 01 00 b6 00 00 00 00-4e 54 4c 4d 53 53 50 00 |........ NTLMSSP.| 0010 03 00 00 00 18 00 18 00-7e 00 00 00 18 00 18 00 |........ ~.......| 0020 96 00 00 00 08 00 08 00-40 00 00 00 16 00 16 00 |........ @.......| 0030 48 00 00 00 20 00 20 00-5e 00 00 00 00 00 00 00 |H... . . ^.......| 0040 ae 00 00 00 01 82 00 00-43 00 4f 00 52 00 50 00 |........ C.O.R.P.| 0050 6a 00 61 00 63 00 6f 00-70 00 69 00 6c 00 6c 00 |j.a.c.o. p.i.l.l.| 0060 65 00 5f 00 64 00 30 00-30 00 36 00 2d 00 65 00 |e._.d.0. 0.6.-.e.| 0070 37 00 32 00 37 00 2e 00-6d 00 66 00 73 00 2e 00 |7.2.7... m.f.s...| 0080 63 00 6f 00 6d 00 ad ef-62 84 d4 08 0d 87 00 00 |c.o.m... b.......| 0090 00 00 00 00 00 00 00 00-00 00 00 00 00 00 df c8 |........ ........| 00a0 2e 96 a9 95 b8 b6 2e f2-7e 0b 80 23 14 d2 e6 c8 |........ ~..#....| 00b0 90 e7 6a 64 47 2b - |..jdG+| packet.c:639:Received packet 0000 04 01 01 94 00 6c 01 00-e3 15 00 01 03 4f 00 74 |.....l.. .....O.t| 0010 00 6f 00 06 6d 00 61 00-73 00 74 00 65 00 72 00 |.o..m.a. s.t.e.r.| 0020 ab 60 00 45 16 00 00 02-00 22 00 43 00 68 00 61 |.`.E.... .".C.h.a| 0030 00 6e 00 67 00 65 00 64-00 20 00 64 00 61 00 74 |.n.g.e.d . .d.a.t| 0040 00 61 00 62 00 61 00 73-00 65 00 20 00 63 00 6f |.a.b.a.s .e. .c.o| 0050 00 6e 00 74 00 65 00 78-00 74 00 20 00 74 00 6f |.n.t.e.x .t. .t.o| 0060 00 20 00 27 00 4f 00 74-00 6f 00 27 00 2e 00 08 |. .'.O.t .o.'....| 0070 42 00 4f 00 53 00 53 00-51 00 4c 00 44 00 34 00 |B.O.S.S. Q.L.D.4.| 0080 00 01 00 e3 17 00 02 0a-75 00 73 00 5f 00 65 00 |........ u.s._.e.| 0090 6e 00 67 00 6c 00 69 00-73 00 68 00 00 ab 6a 00 |n.g.l.i. s.h...j.| 00a0 47 16 00 00 01 00 27 00-43 00 68 00 61 00 6e 00 |G.....'. C.h.a.n.| 00b0 67 00 65 00 64 00 20 00-6c 00 61 00 6e 00 67 00 |g.e.d. . l.a.n.g.| 00c0 75 00 61 00 67 00 65 00-20 00 73 00 65 00 74 00 |u.a.g.e. .s.e.t.| 00d0 74 00 69 00 6e 00 67 00-20 00 74 00 6f 00 20 00 |t.i.n.g. .t.o. .| 00e0 75 00 73 00 5f 00 65 00-6e 00 67 00 6c 00 69 00 |u.s._.e. n.g.l.i.| 00f0 73 00 68 00 2e 00 08 42-00 4f 00 53 00 53 00 51 |s.h....B .O.S.S.Q| 0100 00 4c 00 44 00 34 00 00-01 00 e3 0f 00 03 05 69 |.L.D.4.. .......i| 0110 00 73 00 6f 00 5f 00 31-00 01 00 00 e3 0b 00 05 |.s.o._.1 ........| 0120 04 31 00 30 00 33 00 33-00 00 e3 0f 00 06 06 31 |.1.0.3.3 .......1| 0130 00 39 00 36 00 36 00 30-00 39 00 00 ad 36 00 01 |.9.6.6.0 .9...6..| 0140 07 00 00 00 16 4d 00 69-00 63 00 72 00 6f 00 73 |.....M.i .c.r.o.s| 0150 00 6f 00 66 00 74 00 20-00 53 00 51 00 4c 00 20 |.o.f.t. .S.Q.L. | 0160 00 53 00 65 00 72 00 76-00 65 00 72 00 00 00 00 |.S.e.r.v .e.r....| 0170 00 0b 00 0d 6d e3 13 00-04 04 34 00 30 00 39 00 |....m... ..4.0.9.| 0180 36 00 04 34 00 30 00 39-00 36 00 fd 00 00 00 00 |6..4.0.9 .6......| 0190 00 00 00 00 - |....| token.c:335:looking for login token, got e3(ENVCHANGE) token.c:115:tds_process_default_tokens() marker is e3(ENVCHANGE) token.c:335:looking for login token, got ab(INFO) token.c:115:tds_process_default_tokens() marker is ab(INFO) token.c:2344:tds_process_msg() reading message 5701 from server token.c:2416:tds_process_msg() calling client msg handler ctutil.c:142:_ct_handle_server_message(0x7fa6f6874620, 0x7fa6f687a390, 0x7fff5a6c6680) ct.c:350:ct_con_props(0x7fa6f687a2d0, 33, 9108, 0x7fff5a6c5888, 8, 0x0) ct.c:352:ct_con_props() action = CS_GET property = 9108 ct.c:512:fetching userdata 0x7fa6f6876d90 token.c:2429:tds_process_msg() returning TDS_SUCCESS token.c:335:looking for login token, got e3(ENVCHANGE) token.c:115:tds_process_default_tokens() marker is e3(ENVCHANGE) token.c:335:looking for login token, got ab(INFO) token.c:115:tds_process_default_tokens() marker is ab(INFO) token.c:2344:tds_process_msg() reading message 5703 from server token.c:2416:tds_process_msg() calling client msg handler ctutil.c:142:_ct_handle_server_message(0x7fa6f6874620, 0x7fa6f687a390, 0x7fff5a6c6680) ct.c:350:ct_con_props(0x7fa6f687a2d0, 33, 9108, 0x7fff5a6c5888, 8, 0x0) ct.c:352:ct_con_props() action = CS_GET property = 9108 ct.c:512:fetching userdata 0x7fa6f6876d90 token.c:2429:tds_process_msg() returning TDS_SUCCESS token.c:335:looking for login token, got e3(ENVCHANGE) token.c:115:tds_process_default_tokens() marker is e3(ENVCHANGE) token.c:2251:server indicated charset change to "iso_1" iconv.c:796:setting server single-byte charset to "CP1252" token.c:335:looking for login token, got e3(ENVCHANGE) token.c:115:tds_process_default_tokens() marker is e3(ENVCHANGE) token.c:335:looking for login token, got e3(ENVCHANGE) token.c:115:tds_process_default_tokens() marker is e3(ENVCHANGE) token.c:335:looking for login token, got ad(LOGINACK) token.c:373:server reports TDS version 7.0.0.0 token.c:375:Product name for 0x7000000 is 7.0 token.c:407:Product version 8B000D6D token.c:335:looking for login token, got e3(ENVCHANGE) token.c:115:tds_process_default_tokens() marker is e3(ENVCHANGE) token.c:2235:changing block size from 4096 to 4096 token.c:335:looking for login token, got fd(DONE) token.c:115:tds_process_default_tokens() marker is fd(DONE) token.c:2080:tds_process_end: more_results = 0 was_cancelled = 0 error = 0 done_count_valid = 0 token.c:2097: rows_affected = 0 token.c:2100:tds_process_end() state set to TDS_IDLE token.c:439:tds_process_login_tokens() returning TDS_SUCCESS mem.c:648:tds_free_all_results() util.c:165:Changed query state from IDLE to WRITING util.c:165:Changed query state from WRITING to PENDING packet.c:740:Sending packet 0000 01 01 00 32 00 00 00 00-73 00 65 00 74 00 20 00 |...2.... s.e.t. .| 0010 74 00 65 00 78 00 74 00-73 00 69 00 7a 00 65 00 |t.e.x.t. s.i.z.e.| 0020 20 00 32 00 30 00 30 00-30 00 30 00 30 00 30 00 | .2.0.0. 0.0.0.0.| 0030 20 00 - | .| token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c6784, 0x7fff5a6c6780, 0x100) util.c:165:Changed query state from PENDING to READING packet.c:639:Received packet 0000 04 01 00 11 00 6c 01 00-fd 00 00 be 00 00 00 00 |.....l.. ........| 0010 00 - |.| token.c:564:processing result tokens. marker is fd(DONE) token.c:2080:tds_process_end: more_results = 0 was_cancelled = 0 error = 0 done_count_valid = 0 token.c:2097: rows_affected = 0 token.c:2100: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 token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c6784, 0x7fff5a6c6780, 0x100) token.c:552:tds_process_tokens() state is COMPLETED ct.c:656:leaving ct_connect() returning 1 ct.c:3383:ct_options(0x7fa6f687a2d0, 34, 5025, 0x7fff5a6c6c44, -99999, 0x0) ct.c:3415:ct_options: CS_SET, option = 5025 ct.c:3613: tds_submit_optioncmd will be action(CS_SET) option(25) arg(0) arglen(1) query.c:3411:tds_submit_optioncmd() mem.c:648:tds_free_all_results() util.c:165:Changed query state from IDLE to WRITING util.c:165:Changed query state from WRITING to PENDING packet.c:740:Sending packet 0000 01 01 00 42 00 00 01 00-53 00 45 00 54 00 20 00 |...B.... S.E.T. .| 0010 49 00 4d 00 50 00 4c 00-49 00 43 00 49 00 54 00 |I.M.P.L. I.C.I.T.| 0020 5f 00 54 00 52 00 41 00-4e 00 53 00 41 00 43 00 |_.T.R.A. N.S.A.C.| 0030 54 00 49 00 4f 00 4e 00-53 00 20 00 4f 00 46 00 |T.I.O.N. S. .O.F.| 0040 46 00 - |F.| token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c6a74, 0x7fff5a6c6a70, 0x100) util.c:165:Changed query state from PENDING to READING packet.c:639:Received packet 0000 04 01 00 11 00 6c 01 00-fd 00 00 ba 00 00 00 00 |.....l.. ........| 0010 00 - |.| token.c:564:processing result tokens. marker is fd(DONE) token.c:2080:tds_process_end: more_results = 0 was_cancelled = 0 error = 0 done_count_valid = 0 token.c:2097: rows_affected = 0 token.c:2100: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 token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c6a74, 0x7fff5a6c6a70, 0x100) token.c:552:tds_process_tokens() state is COMPLETED ct.c:673:ct_cmd_alloc(0x7fa6f687a2d0, 0x7fff5a6c6ff8) ct.c:235:ct_describe_cmd_state(0) ct.c:235:ct_describe_cmd_state(0) ct.c:223:setting command state to IDLE (from IDLE) ct.c:690:ct_cmd_alloc() : allocating command list to head ct.c:711:ct_command(0x7fa6f5400040, 148, 0x7fff5a6c71c0, -9, -99999) ct.c:850:_ct_initialise_cmd(0x7fa6f5400040) ct.c:235:ct_describe_cmd_state(0) ct.c:235:ct_describe_cmd_state(0) ct.c:223:setting command state to IDLE (from IDLE) ct.c:4033:rpc_clear(0x0) ct.c:235:ct_describe_cmd_state(0) ct.c:235:ct_describe_cmd_state(0) ct.c:223:setting command state to IDLE (from IDLE) ct.c:235:ct_describe_cmd_state(2) ct.c:235:ct_describe_cmd_state(0) ct.c:223:setting command state to READY (from IDLE) ct.c:869:ct_send(0x7fa6f5400040) ct.c:871:ct_send() command_type = 148 mem.c:648:tds_free_all_results() util.c:165:Changed query state from IDLE to WRITING util.c:165:Changed query state from WRITING to PENDING packet.c:740:Sending packet 0000 01 01 00 28 00 00 01 00-73 00 65 00 6c 00 65 00 |...(.... s.e.l.e.| 0010 63 00 74 00 20 00 40 00-40 00 76 00 65 00 72 00 |c.t. . at . @.v.e.r.| 0020 73 00 69 00 6f 00 6e 00- |s.i.o.n.| ct.c:235:ct_describe_cmd_state(3) ct.c:235:ct_describe_cmd_state(2) ct.c:223:setting command state to SENT (from READY) ct.c:994:ct_send() succeeded ct.c:1132:ct_results(0x7fa6f5400040, 0x7fff5a6c6ff4) token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c6f84, 0x7fff5a6c6f80, 0x6914) util.c:165:Changed query state from PENDING to READING packet.c:639:Received packet 0000 04 01 01 bd 00 6c 01 00-81 01 00 00 00 21 00 e7 |.....l.. .....!..| 0010 58 02 00 d1 9e 01 4d 00-69 00 63 00 72 00 6f 00 |X.....M. i.c.r.o.| 0020 73 00 6f 00 66 00 74 00-20 00 53 00 51 00 4c 00 |s.o.f.t. .S.Q.L.| 0030 20 00 53 00 65 00 72 00-76 00 65 00 72 00 20 00 | .S.e.r. v.e.r. .| 0040 32 00 30 00 31 00 32 00-20 00 28 00 53 00 50 00 |2.0.1.2. .(.S.P.| 0050 31 00 29 00 20 00 2d 00-20 00 31 00 31 00 2e 00 |1.). .-. .1.1...| 0060 30 00 2e 00 33 00 34 00-33 00 37 00 2e 00 30 00 |0...3.4. 3.7...0.| 0070 20 00 28 00 58 00 36 00-34 00 29 00 20 00 0a 00 | .(.X.6. 4.). ...| 0080 09 00 4d 00 61 00 79 00-20 00 32 00 39 00 20 00 |..M.a.y. .2.9. .| 0090 32 00 30 00 31 00 34 00-20 00 31 00 36 00 3a 00 |2.0.1.4. .1.6.:.| 00a0 30 00 33 00 3a 00 34 00-30 00 20 00 0a 00 09 00 |0.3.:.4. 0. .....| 00b0 43 00 6f 00 70 00 79 00-72 00 69 00 67 00 68 00 |C.o.p.y. r.i.g.h.| 00c0 74 00 20 00 28 00 63 00-29 00 20 00 4d 00 69 00 |t. .(.c. ). .M.i.| 00d0 63 00 72 00 6f 00 73 00-6f 00 66 00 74 00 20 00 |c.r.o.s. o.f.t. .| 00e0 43 00 6f 00 72 00 70 00-6f 00 72 00 61 00 74 00 |C.o.r.p. o.r.a.t.| 00f0 69 00 6f 00 6e 00 0a 00-09 00 44 00 65 00 76 00 |i.o.n... ..D.e.v.| 0100 65 00 6c 00 6f 00 70 00-65 00 72 00 20 00 45 00 |e.l.o.p. e.r. .E.| 0110 64 00 69 00 74 00 69 00-6f 00 6e 00 20 00 28 00 |d.i.t.i. o.n. .(.| 0120 36 00 34 00 2d 00 62 00-69 00 74 00 29 00 20 00 |6.4.-.b. i.t.). .| 0130 6f 00 6e 00 20 00 57 00-69 00 6e 00 64 00 6f 00 |o.n. .W. i.n.d.o.| 0140 77 00 73 00 20 00 4e 00-54 00 20 00 36 00 2e 00 |w.s. .N. T. .6...| 0150 31 00 20 00 3c 00 58 00-36 00 34 00 3e 00 20 00 |1. .<.X. 6.4.>. .| 0160 28 00 42 00 75 00 69 00-6c 00 64 00 20 00 37 00 |(.B.u.i. l.d. .7.| 0170 36 00 30 00 31 00 3a 00-20 00 53 00 65 00 72 00 |6.0.1.:. .S.e.r.| 0180 76 00 69 00 63 00 65 00-20 00 50 00 61 00 63 00 |v.i.c.e. .P.a.c.| 0190 6b 00 20 00 31 00 29 00-20 00 28 00 48 00 79 00 |k. .1.). .(.H.y.| 01a0 70 00 65 00 72 00 76 00-69 00 73 00 6f 00 72 00 |p.e.r.v. i.s.o.r.| 01b0 29 00 0a 00 fd 10 00 c1-00 01 00 00 00 |)....... .....| token.c:564:processing result tokens. marker is 81(TDS7_RESULT) token.c:1573:processing TDS7 result metadata. mem.c:648:tds_free_all_results() token.c:1598:set current_results (1 column) to tds->res_info token.c:1605:setting up 1 columns token.c:3164:adjust_character_column_size: Server charset: UCS-2LE Server column_size: 600 Client charset: UTF-8 Client column_size: 1200 token.c:1542:tds7_get_data_info: colname = type = 39 (varchar) server's type = 231 (x UCS-2 varchar) column_varint_size = 2 column_size = 1200 (600 on server) token.c:1614: name size/wsize type/wtype utype token.c:1615: -------------------- --------------- --------------- ------- token.c:1620: 1200/600 39/231 0 util.c:165:Changed query state from READING to PENDING ct.c:1189:ct_results() process_result_tokens returned 0 (type 4049) token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c6f84, 0x7fff5a6c6f80, 0x6914) util.c:165:Changed query state from PENDING to READING token.c:564:processing result tokens. marker is d1(ROW) token.c:680:tds_process_tokens::SET_RETURN stopping on current token util.c:165:Changed query state from READING to PENDING ct.c:1189:ct_results() process_result_tokens returned 0 (type 4040) ct.c:2283:ct_describe(0x7fa6f5400040, 1, 0x7fff5a6c7000) ct.c:1896:_ct_get_client_type(type 39, user 0, size 1200) ct.c:2304:ct_describe() datafmt->datatype = 0 server type 39 ct.c:1457:ct_bind(0x7fa6f5400040, 1, 0x7fff5a6c7000, 0x7fff5a6c70c0, 0x7fff5a6c6ff0, 0x7fff5a6c6fee) ct.c:1459:ct_bind() datafmt count = 1 column_number = 1 ct.c:1518:ct_fetch(0x7fa6f5400040, -99999, -99999, -99999, 0x7fff5a6c6fe8) token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c6f7c, 0x0, 0x1608) util.c:165:Changed query state from PENDING to READING token.c:564:processing result tokens. marker is d1(ROW) token.c:1951:tds_process_row(): reading column 0 data.c:534:tds_get_data: type 39, varint size 2 data.c:587:tds_get_data(): wire column size is 414 util.c:165:Changed query state from READING to PENDING ct.c:1583:inside ct_fetch() process_row_tokens returned 0 ct.c:1723:_ct_bind_data(0x7fa6f576fd50, 0x7fa6f687adc0, 0x7fa6f687adc0, 0) ct.c:1730:_ct_bind_data(): column 0 is type 39 and has length 207 ct.c:1896:_ct_get_client_type(type 39, user 0, size 1200) cs.c:473:cs_convert(0x7fa6f576fd50, 0x7fff5a6c6e50, 0x7fa6f3a11c00, 0x7fff5a6c6da0, 0x7fff5a6c70c0, 0x7fff5a6c6ff0) ct.c:2007:_ct_get_server_type(0) ct.c:2007:_ct_get_server_type(0) cs.c:521:converting type 47 (207 bytes) to type = 47 (255 bytes) cs.c:535:cs_convert() srctype == desttype cs.c:571:cs_convert() desttype = character cs.c:53:cs_prretcode(1) cs.c:660:cs_convert() returning CS_SUCCEED ct.c:1518:ct_fetch(0x7fa6f5400040, -99999, -99999, -99999, 0x7fff5a6c6fe8) ct.c:1132:ct_results(0x7fa6f5400040, 0x7fff5a6c6ff4) token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c6f84, 0x7fff5a6c6f80, 0x6914) util.c:165:Changed query state from PENDING to READING token.c:564:processing result tokens. marker is fd(DONE) token.c:2080:tds_process_end: more_results = 0 was_cancelled = 0 error = 0 done_count_valid = 1 token.c:2097: rows_affected = 1 token.c:2100: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:1189:ct_results() process_result_tokens returned 0 (type 4052) ct.c:1295:ct_results() results state = 2 ct.c:1296:ct_results() command type = 148 ct.c:1297:ct_results() dynamic cmd = 0 ct.c:1132:ct_results(0x7fa6f5400040, 0x7fff5a6c6ff4) token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c6f84, 0x7fff5a6c6f80, 0x6914) token.c:552:tds_process_tokens() state is COMPLETED ct.c:1189:ct_results() process_result_tokens returned 1 (type 4052) ct.c:235:ct_describe_cmd_state(2) ct.c:235:ct_describe_cmd_state(3) ct.c:223:setting command state to READY (from SENT) ct.c:1796:ct_cmd_drop(0x7fa6f5400040) ct.c:1827:ct_cmd_drop() : command entry found in list ct.c:1832:ct_cmd_drop() : relinking list ct.c:1839:ct_cmd_drop() : relinked list ct.c:673:ct_cmd_alloc(0x7fa6f687a2d0, 0x7fff5a6c6de0) ct.c:235:ct_describe_cmd_state(0) ct.c:235:ct_describe_cmd_state(0) ct.c:223:setting command state to IDLE (from IDLE) ct.c:690:ct_cmd_alloc() : allocating command list to head ct.c:711:ct_command(0x7fa6f5359360, 148, 0x7fa6f2c01f00, -9, -99999) ct.c:850:_ct_initialise_cmd(0x7fa6f5359360) ct.c:235:ct_describe_cmd_state(0) ct.c:235:ct_describe_cmd_state(0) ct.c:223:setting command state to IDLE (from IDLE) ct.c:4033:rpc_clear(0x0) ct.c:235:ct_describe_cmd_state(0) ct.c:235:ct_describe_cmd_state(0) ct.c:223:setting command state to IDLE (from IDLE) ct.c:235:ct_describe_cmd_state(2) ct.c:235:ct_describe_cmd_state(0) ct.c:223:setting command state to READY (from IDLE) ct.c:869:ct_send(0x7fa6f5359360) ct.c:871:ct_send() command_type = 148 mem.c:648:tds_free_all_results() util.c:165:Changed query state from IDLE to WRITING util.c:165:Changed query state from WRITING to PENDING packet.c:740:Sending packet 0000 01 01 00 18 00 00 01 00-75 00 73 00 65 00 20 00 |........ u.s.e. .| 0010 6f 00 74 00 6f 00 33 00- |o.t.o.3.| ct.c:235:ct_describe_cmd_state(3) ct.c:235:ct_describe_cmd_state(2) ct.c:223:setting command state to SENT (from READY) ct.c:994:ct_send() succeeded ct.c:1132:ct_results(0x7fa6f5359360, 0x7fff5a6c66d0) token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c65f4, 0x7fff5a6c65f0, 0x6914) util.c:165:Changed query state from PENDING to READING packet.c:639:Received packet 0000 04 01 00 8a 00 6c 01 00-e3 11 00 01 04 4f 00 54 |.....l.. .....O.T| 0010 00 4f 00 33 00 03 4f 00-54 00 4f 00 ab 62 00 45 |.O.3..O. T.O..b.E| 0020 16 00 00 01 00 23 00 43-00 68 00 61 00 6e 00 67 |.....#.C .h.a.n.g| 0030 00 65 00 64 00 20 00 64-00 61 00 74 00 61 00 62 |.e.d. .d .a.t.a.b| 0040 00 61 00 73 00 65 00 20-00 63 00 6f 00 6e 00 74 |.a.s.e. .c.o.n.t| 0050 00 65 00 78 00 74 00 20-00 74 00 6f 00 20 00 27 |.e.x.t. .t.o. .'| 0060 00 4f 00 54 00 4f 00 33-00 27 00 2e 00 08 42 00 |.O.T.O.3 .'....B.| 0070 4f 00 53 00 53 00 51 00-4c 00 44 00 34 00 00 01 |O.S.S.Q. L.D.4...| 0080 00 fd 00 00 e2 00 00 00-00 00 |........ ..| token.c:564:processing result tokens. marker is e3(ENVCHANGE) token.c:115:tds_process_default_tokens() marker is e3(ENVCHANGE) token.c:564:processing result tokens. marker is ab(INFO) token.c:115:tds_process_default_tokens() marker is ab(INFO) token.c:2344:tds_process_msg() reading message 5701 from server token.c:2416:tds_process_msg() calling client msg handler ctutil.c:142:_ct_handle_server_message(0x7fa6f6874620, 0x7fa6f687a390, 0x7fff5a6c6420) ct.c:350:ct_con_props(0x7fa6f687a2d0, 33, 9108, 0x7fff5a6c5628, 8, 0x0) ct.c:352:ct_con_props() action = CS_GET property = 9108 ct.c:512:fetching userdata 0x7fa6f6876d90 token.c:2429:tds_process_msg() returning TDS_SUCCESS token.c:564:processing result tokens. marker is fd(DONE) token.c:2080:tds_process_end: more_results = 0 was_cancelled = 0 error = 0 done_count_valid = 0 token.c:2097: rows_affected = 0 token.c:2100: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:1189:ct_results() process_result_tokens returned 0 (type 4052) ct.c:1295:ct_results() results state = 0 ct.c:1296:ct_results() command type = 148 ct.c:1297:ct_results() dynamic cmd = 0 ct.c:2347:ct_res_info(0x7fa6f5359360, 800, 0x7fa6f2c67598, -99999, 0x0) ct.c:2372:ct_res_info(): Number of rows is -1 ct.c:1132:ct_results(0x7fa6f5359360, 0x7fff5a6c66d0) ct.c:2347:ct_res_info(0x7fa6f5359360, 800, 0x7fa6f2c67598, -99999, 0x0) ct.c:2372:ct_res_info(): Number of rows is -1 ct.c:1132:ct_results(0x7fa6f5359360, 0x7fff5a6c66d0) token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c65f4, 0x7fff5a6c65f0, 0x6914) token.c:552:tds_process_tokens() state is COMPLETED ct.c:1189:ct_results() process_result_tokens returned 1 (type 4052) ct.c:235:ct_describe_cmd_state(2) ct.c:235:ct_describe_cmd_state(3) ct.c:223:setting command state to READY (from SENT) ct.c:1796:ct_cmd_drop(0x7fa6f5359360) ct.c:1827:ct_cmd_drop() : command entry found in list ct.c:1832:ct_cmd_drop() : relinking list ct.c:1839:ct_cmd_drop() : relinked list ct.c:673:ct_cmd_alloc(0x7fa6f687a2d0, 0x7fff5a6c6de0) ct.c:235:ct_describe_cmd_state(0) ct.c:235:ct_describe_cmd_state(0) ct.c:223:setting command state to IDLE (from IDLE) ct.c:690:ct_cmd_alloc() : allocating command list to head ct.c:711:ct_command(0x7fa6f5145ea0, 148, 0x1056b8000, -9, -99999) ct.c:850:_ct_initialise_cmd(0x7fa6f5145ea0) ct.c:235:ct_describe_cmd_state(0) ct.c:235:ct_describe_cmd_state(0) ct.c:223:setting command state to IDLE (from IDLE) ct.c:4033:rpc_clear(0x0) ct.c:235:ct_describe_cmd_state(0) ct.c:235:ct_describe_cmd_state(0) ct.c:223:setting command state to IDLE (from IDLE) ct.c:235:ct_describe_cmd_state(2) ct.c:235:ct_describe_cmd_state(0) ct.c:223:setting command state to READY (from IDLE) ct.c:869:ct_send(0x7fa6f5145ea0) ct.c:871:ct_send() command_type = 148 mem.c:648:tds_free_all_results() util.c:165:Changed query state from IDLE to WRITING packet.c:740:Sending packet 0000 01 00 10 00 00 00 01 00-49 00 4e 00 53 00 45 00 |........ I.N.S.E.| 0010 52 00 54 00 20 00 69 00-6e 00 74 00 6f 00 20 00 |R.T. .i. n.t.o. .| 0020 54 00 45 00 53 00 54 00-54 00 41 00 42 00 4c 00 |T.E.S.T. T.A.B.L.| 0030 45 00 20 00 28 00 6d 00-61 00 78 00 74 00 65 00 |E. .(.m. a.x.t.e.| 0040 78 00 74 00 29 00 20 00-76 00 61 00 6c 00 75 00 |x.t.). . v.a.l.u.| 0050 65 00 73 00 20 00 28 00-4e 00 27 00 78 00 78 00 |e.s. .(. N.'.x.x.| stream.c:125:Error: tds_convert_stream: tds_iconv returned errno 7, conv_errno 7 packet.c:740:Sending packet 0000 01 00 10 00 00 00 01 00-78 00 78 00 78 00 78 00 |........ x.x.x.x.| packet.c:740:Sending packet 0000 01 00 10 00 00 00 01 00-78 00 78 00 78 00 78 00 |........ x.x.x.x.| stream.c:125:Error: tds_convert_stream: tds_iconv returned errno 7, conv_errno 7 packet.c:740:Sending packet 0000 01 00 10 00 00 00 01 00-78 00 78 00 78 00 78 00 |........ x.x.x.x.| stream.c:125:Error: tds_convert_stream: tds_iconv returned errno 7, conv_errno 7 util.c:165:Changed query state from WRITING to PENDING packet.c:740:Sending packet 0000 01 01 0f 20 00 00 01 00-78 00 78 00 78 00 78 00 |... .... x.x.x.x.| 0f10 78 00 78 00 78 00 78 00-78 00 78 00 27 00 29 00 |x.x.x.x. x.x.'.).| ct.c:235:ct_describe_cmd_state(3) ct.c:235:ct_describe_cmd_state(2) ct.c:223:setting command state to SENT (from READY) ct.c:994:ct_send() succeeded ct.c:1132:ct_results(0x7fa6f5145ea0, 0x7fff5a6c66d0) token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c65f4, 0x7fff5a6c65f0, 0x6914) util.c:165:Changed query state from PENDING to READING packet.c:639:Received packet 0000 04 01 00 11 00 6c 01 00-fd 10 00 c3 00 01 00 00 |.....l.. ........| 0010 00 - |.| token.c:564:processing result tokens. marker is fd(DONE) token.c:2080:tds_process_end: more_results = 0 was_cancelled = 0 error = 0 done_count_valid = 1 token.c:2097: rows_affected = 1 token.c:2100: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:1189:ct_results() process_result_tokens returned 0 (type 4052) ct.c:1295:ct_results() results state = 0 ct.c:1296:ct_results() command type = 148 ct.c:1297:ct_results() dynamic cmd = 0 ct.c:2347:ct_res_info(0x7fa6f5145ea0, 800, 0x7fa6f687a908, -99999, 0x0) ct.c:2372:ct_res_info(): Number of rows is 1 ct.c:1132:ct_results(0x7fa6f5145ea0, 0x7fff5a6c66d0) ct.c:2347:ct_res_info(0x7fa6f5145ea0, 800, 0x7fa6f687a908, -99999, 0x0) ct.c:2372:ct_res_info(): Number of rows is 1 ct.c:1132:ct_results(0x7fa6f5145ea0, 0x7fff5a6c66d0) token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c65f4, 0x7fff5a6c65f0, 0x6914) token.c:552:tds_process_tokens() state is COMPLETED ct.c:1189:ct_results() process_result_tokens returned 1 (type 4052) ct.c:235:ct_describe_cmd_state(2) ct.c:235:ct_describe_cmd_state(3) ct.c:223:setting command state to READY (from SENT) ct.c:1796:ct_cmd_drop(0x7fa6f5145ea0) ct.c:1827:ct_cmd_drop() : command entry found in list ct.c:1832:ct_cmd_drop() : relinking list ct.c:1839:ct_cmd_drop() : relinked list On 10/7/15, 11:37 AM, "Frediano Ziglio" wrote: >I won't be surprised if there are also some limit in sql server. > >You are sending the data inside a language query string. It's quite >surprising changing log settings solve the issue, perhaps there is a >bug inside Ctlib (DBD::Sybase should use ctlib). You can try using a >packet sniffer to get traffic with the server. Can you post (or send >to me if you prefer) the logs anyway? >Probably you'd better compress them. From the log we can understand >which calls DBD::Sybase does so I can try reproduce with C directly. > >Frediano > > >2015-10-06 1:36 GMT+01:00 Jacopille, David : >> DC - Thanks for the quick reply. Text size is positively set to one >>million characters. >> >> 1. The data SELECT of 500,000 characters always works. >> 2. SELECT @@textsize does confirm the 1,000,000 setting (but the above >>also proves functionality) >> 3. 'Text size' setting only applies to SELECT statements, not INSERT >>where we are having the issue. This is demonstrably true for MS SQL >>Server, which we are using. Don't know about other databases. >> >> SQL Server 2012 nvarchar(max) does hold 2 GB theoretical. This >>specific table and nvarchar(max) column has proven to handle far more >>than the 1 MB values I'm testing with. At least through other software. >> >> I suspect that there is a bug in either FreeTDS 0.95 or DBD::Sybase >>1.15 that is limiting the text. However I find FreeTDS more suspicious >>because turning on logging (which changes something in FreeTDS) fixes >>the problem. >> >> Unfortunately the thing that would be useful to find the problem is >>what fixes the problem. >> >> Dave >> >> -----Original Message----- >> From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of >>David Chang >> Sent: Monday, October 05, 2015 6:54 PM >> To: FreeTDS Development Group >> Subject: Re: [freetds] Using FreeTDS 0.95 INSERTS fail above 66000 >>characters...unless 'dump file' is turned on >> >> Dave, >> >> I see you set the text size in the freetds.conf file to 1000000. I >>would confirm it using 'select @@textsize'. >> >> DC >> >> On 10/5/2015 2:07 PM, Jacopille, David wrote: >>> Looking for suggestions or a troubleshooting approach on this 100% >>> reproducible issue where FreeTDS logging seems to be the only variable. >>> >>> Since the issue goes away as soon as I turn on freetds logging I can?t >>> look at the logs to find the problem. >>> >>> ENVIRONMENT >>> SQL Server 2012 >>> OS X 10.9.5 >>> FreeTDS 0.95.20 >>> DBD::Sybase 1.15 >>> TDSVER 7.0 or 7.1 (same symptoms) >>> Perl 5.16.3 >>> FreeTDS text size = 1000000 >>> >>> Testing large string INSERTS to a table with a single, nvarchar(max), >>> column >>> >>> >>> WHAT WORKS >>> A. With freetds logging on (via 'dump file = /tmp/freetds.log?) INSERT >>> values from 0-500,000 characters are successful. Decreasing >>> reliability above 500,000 characters. >>> >>> B. INSERT statements with values of 0 thru 66,000 characters always >>> work, regardless of freetds logging on/off >>> >>> C. SELECT work correctly for all values 0 thru one million characters, >>> regardless of freetds logging on/off >>> >>> >>> DOES NOT WORK >>> If freetds logging is turned off the following fails consistently: >>> >>> A. 67,000 character INSERT stalls at INSERT >>> >>> B. 100,000+ character INSERT doesn?t stall but doesn?t >>>INSERT >>> >>> C. Stored Procedures also experiencing failures in same character >>> ranges >>> >>> >>> FREETDS.CONF >>> >>> # In the failure configuration it looks like this. >>> # The ?DOES NOT WORK? symptoms go away if the last two lines are >>> uncommented. >>> >>> [global] >>> client charset = UTF-8 >>> text size = 1000000 >>> >>> [bossqld4] >>> host = bossqld4.mfs.com >>> port = 1433 >>> tds version = 7.0 >>> #dump file = /tmp/freetds.log >>> #dump file append = no >>> >>> >>> PERL SCRIPT REPRODUCING ISSUE (WITH NO FREETDS LOGGING) >>> >>> use DBI qw(:sql_types); >>> use DBD::Sybase; >>> my ($sql, $dbh, $ref, $largetext); >>> >>> $dbh = DBI->connect( 'DBI:Sybase:server=bossqld4', ?CORP\user', >>> ?password', { PrintError => 0 } ) or die; $dbh->do('use >>> testdatabase'); >>> >>> $largetext = 'x' x 100000; # one hundred thousand characters >>> >>> $dbh->do(qq|INSERT into TESTTABLE (maxtext) values >>> (N\'$largetext\')|); >>> >>> # SELECT not affected by FreeTDS logging on/off # SELECT always >>> successful on all values tested up to one million characters (and >>> probably much larger, but untested). >>> >>> $sql = q|SELECT TOP 1 [maxtext] FROM TESTTABLE|; $ref = >>> $dbh->selectrow_arrayref($sql); print 'Length of value: '. (length >>> $$ref[0]) ."\n"; >>> >>> $dbh->disconnect(); >>> >>> >>> Thank you, >>> Dave Jacopille >>> Boston >>> >>> MFS Email system made the following annotation >>> ---------------------------------------------------------------------- >>> ----------------------------------------------------------------- >>> This email communication and any attachments may contain proprietary, >>>confidential, or privileged information. If you are not the intended >>>recipient, you are hereby notified that you have received this email in >>>error and that any review, disclosure, dissemination, distribution or >>>copying of it or its contents is prohibited. The sender does not waive >>>confidentiality or any privilege by mistransmission. If you have >>>received this email in error, please notify the sender immediately, >>>delete this email, and destroy all copies and any attachments. >>> _______________________________________________ >>> FreeTDS mailing list >>> FreeTDS at lists.ibiblio.org >>> http://lists.ibiblio.org/mailman/listinfo/freetds >> >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> http://lists.ibiblio.org/mailman/listinfo/freetds >> MFS Email system made the following annotation >> >>------------------------------------------------------------------------- >>-------------------------------------------------------------- >> This email communication and any attachments may contain proprietary, >>confidential, or privileged information. If you are not the intended >>recipient, you are hereby notified that you have received this email in >>error and that any review, disclosure, dissemination, distribution or >>copying of it or its contents is prohibited. The sender does not waive >>confidentiality or any privilege by mistransmission. If you have >>received this email in error, please notify the sender immediately, >>delete this email, and destroy all copies and any attachments. >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> http://lists.ibiblio.org/mailman/listinfo/freetds >_______________________________________________ >FreeTDS mailing list >FreeTDS at lists.ibiblio.org >http://lists.ibiblio.org/mailman/listinfo/freetds MFS Email system made the following annotation --------------------------------------------------------------------------------------------------------------------------------------- This email communication and any attachments may contain proprietary, confidential, or privileged information. If you are not the intended recipient, you are hereby notified that you have received this email in error and that any review, disclosure, dissemination, distribution or copying of it or its contents is prohibited. The sender does not waive confidentiality or any privilege by mistransmission. If you have received this email in error, please notify the sender immediately, delete this email, and destroy all copies and any attachments. From hfreire at abajar.com Thu Oct 8 06:36:40 2015 From: hfreire at abajar.com (Hugo Freire) Date: Thu, 08 Oct 2015 12:36:40 +0200 Subject: [freetds] Freetds and Unicode Message-ID: <56164738.3050501@abajar.com> Hi, I'm using Freetds from 4 years ago and works perfectly. Now we are trying to allow to store Unicode characters in sql server. We have detected that we can store without problems any character from first plane of Basic Multilingual Plane https://en.wikipedia.org/wiki/Plane_(Unicode)#Basic_Multilingual_Plane, but not able to store any character from other planes. In the Freetds documentation I can read "At some future time, FreeTDS aims to support Unicode and other multi-byte character sets." After making some tests, we was able to store all Unicode characters using "client charset ISO-8859-1". Unfortunately we have an heterogeneous platform with windows and linux systems connecting to the same data, so the data stored by Freetds using ISO-8859-1 can't be read by .net application for example. Our conclusion was that FreeTDS is unable to store all Unicode characters in SQL Server in UCS-2. Is it correct? Are there any patch that allow to store all UCS-2 characters? Is posible create a patch to allow this? Can someone guide me to start to create this patch? Best regards, Hugo From ikorot01 at gmail.com Thu Oct 8 08:29:00 2015 From: ikorot01 at gmail.com (Igor Korot) Date: Thu, 8 Oct 2015 08:29:00 -0400 Subject: [freetds] Freetds and Unicode In-Reply-To: <56164738.3050501@abajar.com> References: <56164738.3050501@abajar.com> Message-ID: Hi, On Thu, Oct 8, 2015 at 6:36 AM, Hugo Freire wrote: > Hi, > > I'm using Freetds from 4 years ago and works perfectly. Now we are trying to > allow to store Unicode characters in sql server. Can you try the latest release? At least for testing purposes. 4 years ago binary is outdated. Thank you. > We have detected that we can store without problems any character from first > plane of Basic Multilingual Plane > https://en.wikipedia.org/wiki/Plane_(Unicode)#Basic_Multilingual_Plane, but > not able to store any character from other planes. > In the Freetds documentation I can read "At some future time, FreeTDS aims > to support Unicode and other multi-byte character sets." > After making some tests, we was able to store all Unicode characters using > "client charset ISO-8859-1". > Unfortunately we have an heterogeneous platform with windows and linux > systems connecting to the same data, so the data stored by Freetds using > ISO-8859-1 can't be read by .net application for example. > > Our conclusion was that FreeTDS is unable to store all Unicode characters in > SQL Server in UCS-2. > > Is it correct? > Are there any patch that allow to store all UCS-2 characters? > Is posible create a patch to allow this? > Can someone guide me to start to create this patch? > > Best regards, > Hugo > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From hfreire at abajar.com Thu Oct 8 10:11:24 2015 From: hfreire at abajar.com (Hugo Freire) Date: Thu, 08 Oct 2015 16:11:24 +0200 Subject: [freetds] Freetds and Unicode In-Reply-To: References: <56164738.3050501@abajar.com> Message-ID: <5616798C.6040309@abajar.com> I'm testing it with last stable version freetds-0.95.20. Thanks, Hugo El 10/8/2015 a las 2:29 PM, Igor Korot escribi?: > Hi, > > On Thu, Oct 8, 2015 at 6:36 AM, Hugo Freire wrote: >> Hi, >> >> I'm using Freetds from 4 years ago and works perfectly. Now we are trying to >> allow to store Unicode characters in sql server. > Can you try the latest release? At least for testing purposes. > 4 years ago binary is outdated. > > Thank you. > >> We have detected that we can store without problems any character from first >> plane of Basic Multilingual Plane >> https://en.wikipedia.org/wiki/Plane_(Unicode)#Basic_Multilingual_Plane, but >> not able to store any character from other planes. >> In the Freetds documentation I can read "At some future time, FreeTDS aims >> to support Unicode and other multi-byte character sets." >> After making some tests, we was able to store all Unicode characters using >> "client charset ISO-8859-1". >> Unfortunately we have an heterogeneous platform with windows and linux >> systems connecting to the same data, so the data stored by Freetds using >> ISO-8859-1 can't be read by .net application for example. >> >> Our conclusion was that FreeTDS is unable to store all Unicode characters in >> SQL Server in UCS-2. >> >> Is it correct? >> Are there any patch that allow to store all UCS-2 characters? >> Is posible create a patch to allow this? >> Can someone guide me to start to create this patch? >> >> Best regards, >> Hugo >> _______________________________________________ >> 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 DJacopille at MFS.com Fri Oct 9 16:29:41 2015 From: DJacopille at MFS.com (Jacopille, David) Date: Fri, 9 Oct 2015 20:29:41 +0000 Subject: [freetds] Using FreeTDS 0.95 INSERTS fail above 66000 characters...unless 'dump file' is turned on In-Reply-To: References: <5612FF8F.3080800@fsautomation.com> Message-ID: FreeTDS group: This issue, which is 100% reproducible in 0.95.20, does not occur at all in 0.91. Insert and select values of 500,000 using FreeTDS 0.91 set to TDSVER=7.1 worked correctly 20 times in a row. I verified the insert as a new record after each run the script. Could this just be a bug in the 0.95.20 build? Thanks, Dave On 10/7/15, 1:13 PM, "Jacopille, David" wrote: >Frediano, > >Below is the freetds.log that contains results from these three lines >from the test script. The INSERT was successful since >logging/debugging was turned on. It would not have been if logging was >turned off. > >DBI->connect >USE >INSERT (string of 100000 ?x? characters) > >The logs recorded a lot of repetitive lines on INSERT of 100000 >?x? characters. > >To save space I removed the repetitive lines with nothing but x >characters, like this example: > >.... 00 78 00 78 00 78 00 78-00 78 00 78 00 78 00 78 |.x.x.x.x .x.x.x.x| > >I also removed some of the repetitive packet retries for the long insert. > >Everything else, including that beginning of the INSERT should be there. > >Thank you for looking into this. > >Dave > >log.c:167:Starting log file for FreeTDS 0.95.20 > on 2015-10-07 13:06:36 with debug flags 0x4fff. >iconv.c:328:tds_iconv_open(0x7fa6f687a390, 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 168.66.122.143 port 1433 (TDS version 7.0) >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 >login.c:788:using NTLM authentication for 'CORP\jacopille_d' account >login.c:852:quietly sending TDS 7+ login packet >token.c:326:tds_process_login_tokens() >packet.c:639:Received packet >0000 04 01 00 e3 00 00 00 00-ed d8 00 4e 54 4c 4d 53 |........ ...NTLMS| >0010 53 50 00 02 00 00 00 08-00 08 00 38 00 00 00 05 |SP...... ...8....| >0020 82 89 02 f5 e6 ef 6b 26-25 0a 98 00 00 00 00 00 |......k& %.......| >0030 00 00 00 98 00 98 00 40-00 00 00 06 01 b1 1d 00 |.......@ ........| >0040 00 00 0f 43 00 4f 00 52-00 50 00 02 00 08 00 43 |...C.O.R .P.....C| >0050 00 4f 00 52 00 50 00 01-00 10 00 42 00 4f 00 53 |.O.R.P.. ...B.O.S| >0060 00 53 00 51 00 4c 00 44-00 34 00 04 00 18 00 63 |.S.Q.L.D .4.....c| >0070 00 6f 00 72 00 70 00 2e-00 6d 00 66 00 73 00 2e |.o.r.p.. .m.f.s..| >0080 00 63 00 6f 00 6d 00 03-00 2a 00 62 00 6f 00 73 |.c.o.m.. .*.b.o.s| >0090 00 73 00 71 00 6c 00 64-00 34 00 2e 00 63 00 6f |.s.q.l.d .4...c.o| >00a0 00 72 00 70 00 2e 00 6d-00 66 00 73 00 2e 00 63 |.r.p...m .f.s...c| >00b0 00 6f 00 6d 00 05 00 1a-00 77 00 69 00 6e 00 72 |.o.m.... .w.i.n.r| >00c0 00 6f 00 6f 00 74 00 2e-00 6c 00 6f 00 63 00 61 |.o.o.t.. .l.o.c.a| >00d0 00 6c 00 07 00 08 00 4e-2f 6c 86 22 01 d1 01 00 |.l.....N /l."....| >00e0 00 00 00 - |...| > >token.c:335:looking for login token, got ed(AUTH) >token.c:115:tds_process_default_tokens() marker is ed(AUTH) >token.c:463:TDS_AUTH_TOKEN PDU size 216 >challenge.c:648:TDS_AUTH_TOKEN nonce >0000 f5 e6 ef 6b 26 25 0a 98- |...k&%..| > >challenge.c:702:Draining 0 bytes >packet.c:740:Sending packet >0000 11 01 00 b6 00 00 00 00-4e 54 4c 4d 53 53 50 00 |........ NTLMSSP.| >0010 03 00 00 00 18 00 18 00-7e 00 00 00 18 00 18 00 |........ ~.......| >0020 96 00 00 00 08 00 08 00-40 00 00 00 16 00 16 00 |........ @.......| >0030 48 00 00 00 20 00 20 00-5e 00 00 00 00 00 00 00 |H... . . ^.......| >0040 ae 00 00 00 01 82 00 00-43 00 4f 00 52 00 50 00 |........ C.O.R.P.| >0050 6a 00 61 00 63 00 6f 00-70 00 69 00 6c 00 6c 00 |j.a.c.o. p.i.l.l.| >0060 65 00 5f 00 64 00 30 00-30 00 36 00 2d 00 65 00 |e._.d.0. 0.6.-.e.| >0070 37 00 32 00 37 00 2e 00-6d 00 66 00 73 00 2e 00 |7.2.7... m.f.s...| >0080 63 00 6f 00 6d 00 ad ef-62 84 d4 08 0d 87 00 00 |c.o.m... b.......| >0090 00 00 00 00 00 00 00 00-00 00 00 00 00 00 df c8 |........ ........| >00a0 2e 96 a9 95 b8 b6 2e f2-7e 0b 80 23 14 d2 e6 c8 |........ ~..#....| >00b0 90 e7 6a 64 47 2b - |..jdG+| > >packet.c:639:Received packet >0000 04 01 01 94 00 6c 01 00-e3 15 00 01 03 4f 00 74 |.....l.. .....O.t| >0010 00 6f 00 06 6d 00 61 00-73 00 74 00 65 00 72 00 |.o..m.a. s.t.e.r.| >0020 ab 60 00 45 16 00 00 02-00 22 00 43 00 68 00 61 |.`.E.... .".C.h.a| >0030 00 6e 00 67 00 65 00 64-00 20 00 64 00 61 00 74 |.n.g.e.d . .d.a.t| >0040 00 61 00 62 00 61 00 73-00 65 00 20 00 63 00 6f |.a.b.a.s .e. .c.o| >0050 00 6e 00 74 00 65 00 78-00 74 00 20 00 74 00 6f |.n.t.e.x .t. .t.o| >0060 00 20 00 27 00 4f 00 74-00 6f 00 27 00 2e 00 08 |. .'.O.t .o.'....| >0070 42 00 4f 00 53 00 53 00-51 00 4c 00 44 00 34 00 |B.O.S.S. Q.L.D.4.| >0080 00 01 00 e3 17 00 02 0a-75 00 73 00 5f 00 65 00 |........ u.s._.e.| >0090 6e 00 67 00 6c 00 69 00-73 00 68 00 00 ab 6a 00 |n.g.l.i. s.h...j.| >00a0 47 16 00 00 01 00 27 00-43 00 68 00 61 00 6e 00 |G.....'. C.h.a.n.| >00b0 67 00 65 00 64 00 20 00-6c 00 61 00 6e 00 67 00 |g.e.d. . l.a.n.g.| >00c0 75 00 61 00 67 00 65 00-20 00 73 00 65 00 74 00 |u.a.g.e. .s.e.t.| >00d0 74 00 69 00 6e 00 67 00-20 00 74 00 6f 00 20 00 |t.i.n.g. .t.o. .| >00e0 75 00 73 00 5f 00 65 00-6e 00 67 00 6c 00 69 00 |u.s._.e. n.g.l.i.| >00f0 73 00 68 00 2e 00 08 42-00 4f 00 53 00 53 00 51 |s.h....B .O.S.S.Q| >0100 00 4c 00 44 00 34 00 00-01 00 e3 0f 00 03 05 69 |.L.D.4.. .......i| >0110 00 73 00 6f 00 5f 00 31-00 01 00 00 e3 0b 00 05 |.s.o._.1 ........| >0120 04 31 00 30 00 33 00 33-00 00 e3 0f 00 06 06 31 |.1.0.3.3 .......1| >0130 00 39 00 36 00 36 00 30-00 39 00 00 ad 36 00 01 |.9.6.6.0 .9...6..| >0140 07 00 00 00 16 4d 00 69-00 63 00 72 00 6f 00 73 |.....M.i .c.r.o.s| >0150 00 6f 00 66 00 74 00 20-00 53 00 51 00 4c 00 20 |.o.f.t. .S.Q.L. | >0160 00 53 00 65 00 72 00 76-00 65 00 72 00 00 00 00 |.S.e.r.v .e.r....| >0170 00 0b 00 0d 6d e3 13 00-04 04 34 00 30 00 39 00 |....m... ..4.0.9.| >0180 36 00 04 34 00 30 00 39-00 36 00 fd 00 00 00 00 |6..4.0.9 .6......| >0190 00 00 00 00 - |....| > >token.c:335:looking for login token, got e3(ENVCHANGE) >token.c:115:tds_process_default_tokens() marker is e3(ENVCHANGE) >token.c:335:looking for login token, got ab(INFO) >token.c:115:tds_process_default_tokens() marker is ab(INFO) >token.c:2344:tds_process_msg() reading message 5701 from server >token.c:2416:tds_process_msg() calling client msg handler >ctutil.c:142:_ct_handle_server_message(0x7fa6f6874620, 0x7fa6f687a390, >0x7fff5a6c6680) >ct.c:350:ct_con_props(0x7fa6f687a2d0, 33, 9108, 0x7fff5a6c5888, 8, 0x0) >ct.c:352:ct_con_props() action = CS_GET property = 9108 >ct.c:512:fetching userdata 0x7fa6f6876d90 >token.c:2429:tds_process_msg() returning TDS_SUCCESS >token.c:335:looking for login token, got e3(ENVCHANGE) >token.c:115:tds_process_default_tokens() marker is e3(ENVCHANGE) >token.c:335:looking for login token, got ab(INFO) >token.c:115:tds_process_default_tokens() marker is ab(INFO) >token.c:2344:tds_process_msg() reading message 5703 from server >token.c:2416:tds_process_msg() calling client msg handler >ctutil.c:142:_ct_handle_server_message(0x7fa6f6874620, 0x7fa6f687a390, >0x7fff5a6c6680) >ct.c:350:ct_con_props(0x7fa6f687a2d0, 33, 9108, 0x7fff5a6c5888, 8, 0x0) >ct.c:352:ct_con_props() action = CS_GET property = 9108 >ct.c:512:fetching userdata 0x7fa6f6876d90 >token.c:2429:tds_process_msg() returning TDS_SUCCESS >token.c:335:looking for login token, got e3(ENVCHANGE) >token.c:115:tds_process_default_tokens() marker is e3(ENVCHANGE) >token.c:2251:server indicated charset change to "iso_1" >iconv.c:796:setting server single-byte charset to "CP1252" >token.c:335:looking for login token, got e3(ENVCHANGE) >token.c:115:tds_process_default_tokens() marker is e3(ENVCHANGE) >token.c:335:looking for login token, got e3(ENVCHANGE) >token.c:115:tds_process_default_tokens() marker is e3(ENVCHANGE) >token.c:335:looking for login token, got ad(LOGINACK) >token.c:373:server reports TDS version 7.0.0.0 >token.c:375:Product name for 0x7000000 is 7.0 >token.c:407:Product version 8B000D6D >token.c:335:looking for login token, got e3(ENVCHANGE) >token.c:115:tds_process_default_tokens() marker is e3(ENVCHANGE) >token.c:2235:changing block size from 4096 to 4096 >token.c:335:looking for login token, got fd(DONE) >token.c:115:tds_process_default_tokens() marker is fd(DONE) >token.c:2080:tds_process_end: more_results = 0 > was_cancelled = 0 > error = 0 > done_count_valid = 0 >token.c:2097: rows_affected = 0 >token.c:2100:tds_process_end() state set to TDS_IDLE >token.c:439:tds_process_login_tokens() returning TDS_SUCCESS >mem.c:648:tds_free_all_results() >util.c:165:Changed query state from IDLE to WRITING >util.c:165:Changed query state from WRITING to PENDING >packet.c:740:Sending packet >0000 01 01 00 32 00 00 00 00-73 00 65 00 74 00 20 00 |...2.... s.e.t. .| >0010 74 00 65 00 78 00 74 00-73 00 69 00 7a 00 65 00 |t.e.x.t. s.i.z.e.| >0020 20 00 32 00 30 00 30 00-30 00 30 00 30 00 30 00 | .2.0.0. 0.0.0.0.| >0030 20 00 - | .| > >token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c6784, >0x7fff5a6c6780, 0x100) >util.c:165:Changed query state from PENDING to READING >packet.c:639:Received packet >0000 04 01 00 11 00 6c 01 00-fd 00 00 be 00 00 00 00 |.....l.. ........| >0010 00 - |.| > >token.c:564:processing result tokens. marker is fd(DONE) >token.c:2080:tds_process_end: more_results = 0 > was_cancelled = 0 > error = 0 > done_count_valid = 0 >token.c:2097: rows_affected = 0 >token.c:2100: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 >token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c6784, >0x7fff5a6c6780, 0x100) >token.c:552:tds_process_tokens() state is COMPLETED >ct.c:656:leaving ct_connect() returning 1 >ct.c:3383:ct_options(0x7fa6f687a2d0, 34, 5025, 0x7fff5a6c6c44, -99999, >0x0) >ct.c:3415:ct_options: CS_SET, option = 5025 >ct.c:3613: tds_submit_optioncmd will be action(CS_SET) option(25) >arg(0) >arglen(1) >query.c:3411:tds_submit_optioncmd() >mem.c:648:tds_free_all_results() >util.c:165:Changed query state from IDLE to WRITING >util.c:165:Changed query state from WRITING to PENDING >packet.c:740:Sending packet >0000 01 01 00 42 00 00 01 00-53 00 45 00 54 00 20 00 |...B.... S.E.T. .| >0010 49 00 4d 00 50 00 4c 00-49 00 43 00 49 00 54 00 |I.M.P.L. I.C.I.T.| >0020 5f 00 54 00 52 00 41 00-4e 00 53 00 41 00 43 00 |_.T.R.A. N.S.A.C.| >0030 54 00 49 00 4f 00 4e 00-53 00 20 00 4f 00 46 00 |T.I.O.N. S. .O.F.| >0040 46 00 - |F.| > >token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c6a74, >0x7fff5a6c6a70, 0x100) >util.c:165:Changed query state from PENDING to READING >packet.c:639:Received packet >0000 04 01 00 11 00 6c 01 00-fd 00 00 ba 00 00 00 00 |.....l.. ........| >0010 00 - |.| > >token.c:564:processing result tokens. marker is fd(DONE) >token.c:2080:tds_process_end: more_results = 0 > was_cancelled = 0 > error = 0 > done_count_valid = 0 >token.c:2097: rows_affected = 0 >token.c:2100: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 >token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c6a74, >0x7fff5a6c6a70, 0x100) >token.c:552:tds_process_tokens() state is COMPLETED >ct.c:673:ct_cmd_alloc(0x7fa6f687a2d0, 0x7fff5a6c6ff8) >ct.c:235:ct_describe_cmd_state(0) >ct.c:235:ct_describe_cmd_state(0) >ct.c:223:setting command state to IDLE (from IDLE) >ct.c:690:ct_cmd_alloc() : allocating command list to head >ct.c:711:ct_command(0x7fa6f5400040, 148, 0x7fff5a6c71c0, -9, -99999) >ct.c:850:_ct_initialise_cmd(0x7fa6f5400040) >ct.c:235:ct_describe_cmd_state(0) >ct.c:235:ct_describe_cmd_state(0) >ct.c:223:setting command state to IDLE (from IDLE) >ct.c:4033:rpc_clear(0x0) >ct.c:235:ct_describe_cmd_state(0) >ct.c:235:ct_describe_cmd_state(0) >ct.c:223:setting command state to IDLE (from IDLE) >ct.c:235:ct_describe_cmd_state(2) >ct.c:235:ct_describe_cmd_state(0) >ct.c:223:setting command state to READY (from IDLE) >ct.c:869:ct_send(0x7fa6f5400040) >ct.c:871:ct_send() command_type = 148 >mem.c:648:tds_free_all_results() >util.c:165:Changed query state from IDLE to WRITING >util.c:165:Changed query state from WRITING to PENDING >packet.c:740:Sending packet >0000 01 01 00 28 00 00 01 00-73 00 65 00 6c 00 65 00 |...(.... s.e.l.e.| >0010 63 00 74 00 20 00 40 00-40 00 76 00 65 00 72 00 |c.t. . at . @.v.e.r.| >0020 73 00 69 00 6f 00 6e 00- |s.i.o.n.| > >ct.c:235:ct_describe_cmd_state(3) >ct.c:235:ct_describe_cmd_state(2) >ct.c:223:setting command state to SENT (from READY) >ct.c:994:ct_send() succeeded >ct.c:1132:ct_results(0x7fa6f5400040, 0x7fff5a6c6ff4) >token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c6f84, >0x7fff5a6c6f80, 0x6914) >util.c:165:Changed query state from PENDING to READING >packet.c:639:Received packet >0000 04 01 01 bd 00 6c 01 00-81 01 00 00 00 21 00 e7 |.....l.. .....!..| >0010 58 02 00 d1 9e 01 4d 00-69 00 63 00 72 00 6f 00 |X.....M. i.c.r.o.| >0020 73 00 6f 00 66 00 74 00-20 00 53 00 51 00 4c 00 |s.o.f.t. .S.Q.L.| >0030 20 00 53 00 65 00 72 00-76 00 65 00 72 00 20 00 | .S.e.r. v.e.r. .| >0040 32 00 30 00 31 00 32 00-20 00 28 00 53 00 50 00 |2.0.1.2. .(.S.P.| >0050 31 00 29 00 20 00 2d 00-20 00 31 00 31 00 2e 00 |1.). .-. .1.1...| >0060 30 00 2e 00 33 00 34 00-33 00 37 00 2e 00 30 00 |0...3.4. 3.7...0.| >0070 20 00 28 00 58 00 36 00-34 00 29 00 20 00 0a 00 | .(.X.6. 4.). ...| >0080 09 00 4d 00 61 00 79 00-20 00 32 00 39 00 20 00 |..M.a.y. .2.9. .| >0090 32 00 30 00 31 00 34 00-20 00 31 00 36 00 3a 00 |2.0.1.4. .1.6.:.| >00a0 30 00 33 00 3a 00 34 00-30 00 20 00 0a 00 09 00 |0.3.:.4. 0. .....| >00b0 43 00 6f 00 70 00 79 00-72 00 69 00 67 00 68 00 |C.o.p.y. r.i.g.h.| >00c0 74 00 20 00 28 00 63 00-29 00 20 00 4d 00 69 00 |t. .(.c. ). .M.i.| >00d0 63 00 72 00 6f 00 73 00-6f 00 66 00 74 00 20 00 |c.r.o.s. o.f.t. .| >00e0 43 00 6f 00 72 00 70 00-6f 00 72 00 61 00 74 00 |C.o.r.p. o.r.a.t.| >00f0 69 00 6f 00 6e 00 0a 00-09 00 44 00 65 00 76 00 |i.o.n... ..D.e.v.| >0100 65 00 6c 00 6f 00 70 00-65 00 72 00 20 00 45 00 |e.l.o.p. e.r. .E.| >0110 64 00 69 00 74 00 69 00-6f 00 6e 00 20 00 28 00 |d.i.t.i. o.n. .(.| >0120 36 00 34 00 2d 00 62 00-69 00 74 00 29 00 20 00 |6.4.-.b. i.t.). .| >0130 6f 00 6e 00 20 00 57 00-69 00 6e 00 64 00 6f 00 |o.n. .W. i.n.d.o.| >0140 77 00 73 00 20 00 4e 00-54 00 20 00 36 00 2e 00 |w.s. .N. T. .6...| >0150 31 00 20 00 3c 00 58 00-36 00 34 00 3e 00 20 00 |1. .<.X. 6.4.>. .| >0160 28 00 42 00 75 00 69 00-6c 00 64 00 20 00 37 00 |(.B.u.i. l.d. .7.| >0170 36 00 30 00 31 00 3a 00-20 00 53 00 65 00 72 00 |6.0.1.:. .S.e.r.| >0180 76 00 69 00 63 00 65 00-20 00 50 00 61 00 63 00 |v.i.c.e. .P.a.c.| >0190 6b 00 20 00 31 00 29 00-20 00 28 00 48 00 79 00 |k. .1.). .(.H.y.| >01a0 70 00 65 00 72 00 76 00-69 00 73 00 6f 00 72 00 |p.e.r.v. i.s.o.r.| >01b0 29 00 0a 00 fd 10 00 c1-00 01 00 00 00 |)....... .....| > >token.c:564:processing result tokens. marker is 81(TDS7_RESULT) >token.c:1573:processing TDS7 result metadata. >mem.c:648:tds_free_all_results() >token.c:1598:set current_results (1 column) to tds->res_info >token.c:1605:setting up 1 columns >token.c:3164:adjust_character_column_size: > Server charset: UCS-2LE > Server column_size: 600 > Client charset: UTF-8 > Client column_size: 1200 >token.c:1542:tds7_get_data_info: > colname = > type = 39 (varchar) > server's type = 231 (x UCS-2 varchar) > column_varint_size = 2 > column_size = 1200 (600 on server) >token.c:1614: name size/wsize type/wtype utype >token.c:1615: -------------------- --------------- --------------- ------- >token.c:1620: 1200/600 39/231 0 >util.c:165:Changed query state from READING to PENDING >ct.c:1189:ct_results() process_result_tokens returned 0 (type 4049) >token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c6f84, >0x7fff5a6c6f80, 0x6914) >util.c:165:Changed query state from PENDING to READING >token.c:564:processing result tokens. marker is d1(ROW) >token.c:680:tds_process_tokens::SET_RETURN stopping on current token >util.c:165:Changed query state from READING to PENDING >ct.c:1189:ct_results() process_result_tokens returned 0 (type 4040) >ct.c:2283:ct_describe(0x7fa6f5400040, 1, 0x7fff5a6c7000) >ct.c:1896:_ct_get_client_type(type 39, user 0, size 1200) >ct.c:2304:ct_describe() datafmt->datatype = 0 server type 39 >ct.c:1457:ct_bind(0x7fa6f5400040, 1, 0x7fff5a6c7000, 0x7fff5a6c70c0, >0x7fff5a6c6ff0, 0x7fff5a6c6fee) >ct.c:1459:ct_bind() datafmt count = 1 column_number = 1 >ct.c:1518:ct_fetch(0x7fa6f5400040, -99999, -99999, -99999, 0x7fff5a6c6fe8) >token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c6f7c, 0x0, >0x1608) >util.c:165:Changed query state from PENDING to READING >token.c:564:processing result tokens. marker is d1(ROW) >token.c:1951:tds_process_row(): reading column 0 >data.c:534:tds_get_data: type 39, varint size 2 >data.c:587:tds_get_data(): wire column size is 414 >util.c:165:Changed query state from READING to PENDING >ct.c:1583:inside ct_fetch() process_row_tokens returned 0 >ct.c:1723:_ct_bind_data(0x7fa6f576fd50, 0x7fa6f687adc0, 0x7fa6f687adc0, 0) >ct.c:1730:_ct_bind_data(): column 0 is type 39 and has length 207 >ct.c:1896:_ct_get_client_type(type 39, user 0, size 1200) >cs.c:473:cs_convert(0x7fa6f576fd50, 0x7fff5a6c6e50, 0x7fa6f3a11c00, >0x7fff5a6c6da0, 0x7fff5a6c70c0, 0x7fff5a6c6ff0) >ct.c:2007:_ct_get_server_type(0) >ct.c:2007:_ct_get_server_type(0) >cs.c:521:converting type 47 (207 bytes) to type = 47 (255 bytes) >cs.c:535:cs_convert() srctype == desttype >cs.c:571:cs_convert() desttype = character >cs.c:53:cs_prretcode(1) >cs.c:660:cs_convert() returning CS_SUCCEED >ct.c:1518:ct_fetch(0x7fa6f5400040, -99999, -99999, -99999, 0x7fff5a6c6fe8) >ct.c:1132:ct_results(0x7fa6f5400040, 0x7fff5a6c6ff4) >token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c6f84, >0x7fff5a6c6f80, 0x6914) >util.c:165:Changed query state from PENDING to READING >token.c:564:processing result tokens. marker is fd(DONE) >token.c:2080:tds_process_end: more_results = 0 > was_cancelled = 0 > error = 0 > done_count_valid = 1 >token.c:2097: rows_affected = 1 >token.c:2100: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:1189:ct_results() process_result_tokens returned 0 (type 4052) >ct.c:1295:ct_results() results state = 2 >ct.c:1296:ct_results() command type = 148 >ct.c:1297:ct_results() dynamic cmd = 0 >ct.c:1132:ct_results(0x7fa6f5400040, 0x7fff5a6c6ff4) >token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c6f84, >0x7fff5a6c6f80, 0x6914) >token.c:552:tds_process_tokens() state is COMPLETED >ct.c:1189:ct_results() process_result_tokens returned 1 (type 4052) >ct.c:235:ct_describe_cmd_state(2) >ct.c:235:ct_describe_cmd_state(3) >ct.c:223:setting command state to READY (from SENT) >ct.c:1796:ct_cmd_drop(0x7fa6f5400040) >ct.c:1827:ct_cmd_drop() : command entry found in list >ct.c:1832:ct_cmd_drop() : relinking list >ct.c:1839:ct_cmd_drop() : relinked list >ct.c:673:ct_cmd_alloc(0x7fa6f687a2d0, 0x7fff5a6c6de0) >ct.c:235:ct_describe_cmd_state(0) >ct.c:235:ct_describe_cmd_state(0) >ct.c:223:setting command state to IDLE (from IDLE) >ct.c:690:ct_cmd_alloc() : allocating command list to head >ct.c:711:ct_command(0x7fa6f5359360, 148, 0x7fa6f2c01f00, -9, -99999) >ct.c:850:_ct_initialise_cmd(0x7fa6f5359360) >ct.c:235:ct_describe_cmd_state(0) >ct.c:235:ct_describe_cmd_state(0) >ct.c:223:setting command state to IDLE (from IDLE) >ct.c:4033:rpc_clear(0x0) >ct.c:235:ct_describe_cmd_state(0) >ct.c:235:ct_describe_cmd_state(0) >ct.c:223:setting command state to IDLE (from IDLE) >ct.c:235:ct_describe_cmd_state(2) >ct.c:235:ct_describe_cmd_state(0) >ct.c:223:setting command state to READY (from IDLE) >ct.c:869:ct_send(0x7fa6f5359360) >ct.c:871:ct_send() command_type = 148 >mem.c:648:tds_free_all_results() >util.c:165:Changed query state from IDLE to WRITING >util.c:165:Changed query state from WRITING to PENDING >packet.c:740:Sending packet >0000 01 01 00 18 00 00 01 00-75 00 73 00 65 00 20 00 |........ u.s.e. .| >0010 6f 00 74 00 6f 00 33 00- |o.t.o.3.| > >ct.c:235:ct_describe_cmd_state(3) >ct.c:235:ct_describe_cmd_state(2) >ct.c:223:setting command state to SENT (from READY) >ct.c:994:ct_send() succeeded >ct.c:1132:ct_results(0x7fa6f5359360, 0x7fff5a6c66d0) >token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c65f4, >0x7fff5a6c65f0, 0x6914) >util.c:165:Changed query state from PENDING to READING >packet.c:639:Received packet >0000 04 01 00 8a 00 6c 01 00-e3 11 00 01 04 4f 00 54 |.....l.. .....O.T| >0010 00 4f 00 33 00 03 4f 00-54 00 4f 00 ab 62 00 45 |.O.3..O. T.O..b.E| >0020 16 00 00 01 00 23 00 43-00 68 00 61 00 6e 00 67 |.....#.C .h.a.n.g| >0030 00 65 00 64 00 20 00 64-00 61 00 74 00 61 00 62 |.e.d. .d .a.t.a.b| >0040 00 61 00 73 00 65 00 20-00 63 00 6f 00 6e 00 74 |.a.s.e. .c.o.n.t| >0050 00 65 00 78 00 74 00 20-00 74 00 6f 00 20 00 27 |.e.x.t. .t.o. .'| >0060 00 4f 00 54 00 4f 00 33-00 27 00 2e 00 08 42 00 |.O.T.O.3 .'....B.| >0070 4f 00 53 00 53 00 51 00-4c 00 44 00 34 00 00 01 |O.S.S.Q. L.D.4...| >0080 00 fd 00 00 e2 00 00 00-00 00 |........ ..| > >token.c:564:processing result tokens. marker is e3(ENVCHANGE) >token.c:115:tds_process_default_tokens() marker is e3(ENVCHANGE) >token.c:564:processing result tokens. marker is ab(INFO) >token.c:115:tds_process_default_tokens() marker is ab(INFO) >token.c:2344:tds_process_msg() reading message 5701 from server >token.c:2416:tds_process_msg() calling client msg handler >ctutil.c:142:_ct_handle_server_message(0x7fa6f6874620, 0x7fa6f687a390, >0x7fff5a6c6420) >ct.c:350:ct_con_props(0x7fa6f687a2d0, 33, 9108, 0x7fff5a6c5628, 8, 0x0) >ct.c:352:ct_con_props() action = CS_GET property = 9108 >ct.c:512:fetching userdata 0x7fa6f6876d90 >token.c:2429:tds_process_msg() returning TDS_SUCCESS >token.c:564:processing result tokens. marker is fd(DONE) >token.c:2080:tds_process_end: more_results = 0 > was_cancelled = 0 > error = 0 > done_count_valid = 0 >token.c:2097: rows_affected = 0 >token.c:2100: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:1189:ct_results() process_result_tokens returned 0 (type 4052) >ct.c:1295:ct_results() results state = 0 >ct.c:1296:ct_results() command type = 148 >ct.c:1297:ct_results() dynamic cmd = 0 >ct.c:2347:ct_res_info(0x7fa6f5359360, 800, 0x7fa6f2c67598, -99999, 0x0) >ct.c:2372:ct_res_info(): Number of rows is -1 >ct.c:1132:ct_results(0x7fa6f5359360, 0x7fff5a6c66d0) >ct.c:2347:ct_res_info(0x7fa6f5359360, 800, 0x7fa6f2c67598, -99999, 0x0) >ct.c:2372:ct_res_info(): Number of rows is -1 >ct.c:1132:ct_results(0x7fa6f5359360, 0x7fff5a6c66d0) >token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c65f4, >0x7fff5a6c65f0, 0x6914) >token.c:552:tds_process_tokens() state is COMPLETED >ct.c:1189:ct_results() process_result_tokens returned 1 (type 4052) >ct.c:235:ct_describe_cmd_state(2) >ct.c:235:ct_describe_cmd_state(3) >ct.c:223:setting command state to READY (from SENT) >ct.c:1796:ct_cmd_drop(0x7fa6f5359360) >ct.c:1827:ct_cmd_drop() : command entry found in list >ct.c:1832:ct_cmd_drop() : relinking list >ct.c:1839:ct_cmd_drop() : relinked list >ct.c:673:ct_cmd_alloc(0x7fa6f687a2d0, 0x7fff5a6c6de0) >ct.c:235:ct_describe_cmd_state(0) >ct.c:235:ct_describe_cmd_state(0) >ct.c:223:setting command state to IDLE (from IDLE) >ct.c:690:ct_cmd_alloc() : allocating command list to head >ct.c:711:ct_command(0x7fa6f5145ea0, 148, 0x1056b8000, -9, -99999) >ct.c:850:_ct_initialise_cmd(0x7fa6f5145ea0) >ct.c:235:ct_describe_cmd_state(0) >ct.c:235:ct_describe_cmd_state(0) >ct.c:223:setting command state to IDLE (from IDLE) >ct.c:4033:rpc_clear(0x0) >ct.c:235:ct_describe_cmd_state(0) >ct.c:235:ct_describe_cmd_state(0) >ct.c:223:setting command state to IDLE (from IDLE) >ct.c:235:ct_describe_cmd_state(2) >ct.c:235:ct_describe_cmd_state(0) >ct.c:223:setting command state to READY (from IDLE) >ct.c:869:ct_send(0x7fa6f5145ea0) >ct.c:871:ct_send() command_type = 148 >mem.c:648:tds_free_all_results() >util.c:165:Changed query state from IDLE to WRITING >packet.c:740:Sending packet >0000 01 00 10 00 00 00 01 00-49 00 4e 00 53 00 45 00 |........ I.N.S.E.| >0010 52 00 54 00 20 00 69 00-6e 00 74 00 6f 00 20 00 |R.T. .i. n.t.o. .| >0020 54 00 45 00 53 00 54 00-54 00 41 00 42 00 4c 00 |T.E.S.T. T.A.B.L.| >0030 45 00 20 00 28 00 6d 00-61 00 78 00 74 00 65 00 |E. .(.m. a.x.t.e.| >0040 78 00 74 00 29 00 20 00-76 00 61 00 6c 00 75 00 |x.t.). . v.a.l.u.| >0050 65 00 73 00 20 00 28 00-4e 00 27 00 78 00 78 00 |e.s. .(. N.'.x.x.| > >stream.c:125:Error: tds_convert_stream: tds_iconv returned errno 7, >conv_errno 7 >packet.c:740:Sending packet >0000 01 00 10 00 00 00 01 00-78 00 78 00 78 00 78 00 |........ x.x.x.x.| > >packet.c:740:Sending packet >0000 01 00 10 00 00 00 01 00-78 00 78 00 78 00 78 00 |........ x.x.x.x.| > >stream.c:125:Error: tds_convert_stream: tds_iconv returned errno 7, >conv_errno 7 >packet.c:740:Sending packet >0000 01 00 10 00 00 00 01 00-78 00 78 00 78 00 78 00 |........ x.x.x.x.| > >stream.c:125:Error: tds_convert_stream: tds_iconv returned errno 7, >conv_errno 7 >util.c:165:Changed query state from WRITING to PENDING >packet.c:740:Sending packet >0000 01 01 0f 20 00 00 01 00-78 00 78 00 78 00 78 00 |... .... x.x.x.x.| >0f10 78 00 78 00 78 00 78 00-78 00 78 00 27 00 29 00 |x.x.x.x. x.x.'.).| > >ct.c:235:ct_describe_cmd_state(3) >ct.c:235:ct_describe_cmd_state(2) >ct.c:223:setting command state to SENT (from READY) >ct.c:994:ct_send() succeeded >ct.c:1132:ct_results(0x7fa6f5145ea0, 0x7fff5a6c66d0) >token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c65f4, >0x7fff5a6c65f0, 0x6914) >util.c:165:Changed query state from PENDING to READING >packet.c:639:Received packet >0000 04 01 00 11 00 6c 01 00-fd 10 00 c3 00 01 00 00 |.....l.. ........| >0010 00 - |.| > >token.c:564:processing result tokens. marker is fd(DONE) >token.c:2080:tds_process_end: more_results = 0 > was_cancelled = 0 > error = 0 > done_count_valid = 1 >token.c:2097: rows_affected = 1 >token.c:2100: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:1189:ct_results() process_result_tokens returned 0 (type 4052) >ct.c:1295:ct_results() results state = 0 >ct.c:1296:ct_results() command type = 148 >ct.c:1297:ct_results() dynamic cmd = 0 >ct.c:2347:ct_res_info(0x7fa6f5145ea0, 800, 0x7fa6f687a908, -99999, 0x0) >ct.c:2372:ct_res_info(): Number of rows is 1 >ct.c:1132:ct_results(0x7fa6f5145ea0, 0x7fff5a6c66d0) >ct.c:2347:ct_res_info(0x7fa6f5145ea0, 800, 0x7fa6f687a908, -99999, 0x0) >ct.c:2372:ct_res_info(): Number of rows is 1 >ct.c:1132:ct_results(0x7fa6f5145ea0, 0x7fff5a6c66d0) >token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c65f4, >0x7fff5a6c65f0, 0x6914) >token.c:552:tds_process_tokens() state is COMPLETED >ct.c:1189:ct_results() process_result_tokens returned 1 (type 4052) >ct.c:235:ct_describe_cmd_state(2) >ct.c:235:ct_describe_cmd_state(3) >ct.c:223:setting command state to READY (from SENT) >ct.c:1796:ct_cmd_drop(0x7fa6f5145ea0) >ct.c:1827:ct_cmd_drop() : command entry found in list >ct.c:1832:ct_cmd_drop() : relinking list >ct.c:1839:ct_cmd_drop() : relinked list > > > > > > >On 10/7/15, 11:37 AM, "Frediano Ziglio" wrote: > >>I won't be surprised if there are also some limit in sql server. >> >>You are sending the data inside a language query string. It's quite >>surprising changing log settings solve the issue, perhaps there is a >>bug inside Ctlib (DBD::Sybase should use ctlib). You can try using a >>packet sniffer to get traffic with the server. Can you post (or send >>to me if you prefer) the logs anyway? >>Probably you'd better compress them. From the log we can understand >>which calls DBD::Sybase does so I can try reproduce with C directly. >> >>Frediano >> >> >>2015-10-06 1:36 GMT+01:00 Jacopille, David : >>> DC - Thanks for the quick reply. Text size is positively set to one >>>million characters. >>> >>> 1. The data SELECT of 500,000 characters always works. >>> 2. SELECT @@textsize does confirm the 1,000,000 setting (but the above >>>also proves functionality) >>> 3. 'Text size' setting only applies to SELECT statements, not INSERT >>>where we are having the issue. This is demonstrably true for MS SQL >>>Server, which we are using. Don't know about other databases. >>> >>> SQL Server 2012 nvarchar(max) does hold 2 GB theoretical. This >>>specific table and nvarchar(max) column has proven to handle far more >>>than the 1 MB values I'm testing with. At least through other >>>software. >>> >>> I suspect that there is a bug in either FreeTDS 0.95 or DBD::Sybase >>>1.15 that is limiting the text. However I find FreeTDS more suspicious >>>because turning on logging (which changes something in FreeTDS) fixes >>>the problem. >>> >>> Unfortunately the thing that would be useful to find the problem is >>>what fixes the problem. >>> >>> Dave >>> >>> -----Original Message----- >>> From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of >>>David Chang >>> Sent: Monday, October 05, 2015 6:54 PM >>> To: FreeTDS Development Group >>> Subject: Re: [freetds] Using FreeTDS 0.95 INSERTS fail above 66000 >>>characters...unless 'dump file' is turned on >>> >>> Dave, >>> >>> I see you set the text size in the freetds.conf file to 1000000. I >>>would confirm it using 'select @@textsize'. >>> >>> DC >>> >>> On 10/5/2015 2:07 PM, Jacopille, David wrote: >>>> Looking for suggestions or a troubleshooting approach on this 100% >>>> reproducible issue where FreeTDS logging seems to be the only >>>>variable. >>>> >>>> Since the issue goes away as soon as I turn on freetds logging I can?t >>>> look at the logs to find the problem. >>>> >>>> ENVIRONMENT >>>> SQL Server 2012 >>>> OS X 10.9.5 >>>> FreeTDS 0.95.20 >>>> DBD::Sybase 1.15 >>>> TDSVER 7.0 or 7.1 (same symptoms) >>>> Perl 5.16.3 >>>> FreeTDS text size = 1000000 >>>> >>>> Testing large string INSERTS to a table with a single, nvarchar(max), >>>> column >>>> >>>> >>>> WHAT WORKS >>>> A. With freetds logging on (via 'dump file = /tmp/freetds.log?) INSERT >>>> values from 0-500,000 characters are successful. Decreasing >>>> reliability above 500,000 characters. >>>> >>>> B. INSERT statements with values of 0 thru 66,000 characters always >>>> work, regardless of freetds logging on/off >>>> >>>> C. SELECT work correctly for all values 0 thru one million characters, >>>> regardless of freetds logging on/off >>>> >>>> >>>> DOES NOT WORK >>>> If freetds logging is turned off the following fails consistently: >>>> >>>> A. 67,000 character INSERT stalls at INSERT >>>> >>>> B. 100,000+ character INSERT doesn?t stall but doesn?t >>>>INSERT >>>> >>>> C. Stored Procedures also experiencing failures in same character >>>> ranges >>>> >>>> >>>> FREETDS.CONF >>>> >>>> # In the failure configuration it looks like this. >>>> # The ?DOES NOT WORK? symptoms go away if the last two lines are >>>> uncommented. >>>> >>>> [global] >>>> client charset = UTF-8 >>>> text size = 1000000 >>>> >>>> [bossqld4] >>>> host = bossqld4.mfs.com >>>> port = 1433 >>>> tds version = 7.0 >>>> #dump file = /tmp/freetds.log >>>> #dump file append = no >>>> >>>> >>>> PERL SCRIPT REPRODUCING ISSUE (WITH NO FREETDS LOGGING) >>>> >>>> use DBI qw(:sql_types); >>>> use DBD::Sybase; >>>> my ($sql, $dbh, $ref, $largetext); >>>> >>>> $dbh = DBI->connect( 'DBI:Sybase:server=bossqld4', ?CORP\user', >>>> ?password', { PrintError => 0 } ) or die; $dbh->do('use >>>> testdatabase'); >>>> >>>> $largetext = 'x' x 100000; # one hundred thousand characters >>>> >>>> $dbh->do(qq|INSERT into TESTTABLE (maxtext) values >>>> (N\'$largetext\')|); >>>> >>>> # SELECT not affected by FreeTDS logging on/off # SELECT always >>>> successful on all values tested up to one million characters (and >>>> probably much larger, but untested). >>>> >>>> $sql = q|SELECT TOP 1 [maxtext] FROM TESTTABLE|; $ref = >>>> $dbh->selectrow_arrayref($sql); print 'Length of value: '. (length >>>> $$ref[0]) ."\n"; >>>> >>>> $dbh->disconnect(); >>>> >>>> >>>> Thank you, >>>> Dave Jacopille >>>> Boston >>>> >>>> MFS Email system made the following annotation >>>> ---------------------------------------------------------------------- >>>> ----------------------------------------------------------------- >>>> This email communication and any attachments may contain proprietary, >>>>confidential, or privileged information. If you are not the intended >>>>recipient, you are hereby notified that you have received this email in >>>>error and that any review, disclosure, dissemination, distribution or >>>>copying of it or its contents is prohibited. The sender does not waive >>>>confidentiality or any privilege by mistransmission. If you have >>>>received this email in error, please notify the sender immediately, >>>>delete this email, and destroy all copies and any attachments. >>>> _______________________________________________ >>>> FreeTDS mailing list >>>> FreeTDS at lists.ibiblio.org >>>> http://lists.ibiblio.org/mailman/listinfo/freetds >>> >>> _______________________________________________ >>> FreeTDS mailing list >>> FreeTDS at lists.ibiblio.org >>> http://lists.ibiblio.org/mailman/listinfo/freetds >>> MFS Email system made the following annotation >>> >>>------------------------------------------------------------------------ >>>- >>>-------------------------------------------------------------- >>> This email communication and any attachments may contain proprietary, >>>confidential, or privileged information. If you are not the intended >>>recipient, you are hereby notified that you have received this email in >>>error and that any review, disclosure, dissemination, distribution or >>>copying of it or its contents is prohibited. The sender does not waive >>>confidentiality or any privilege by mistransmission. If you have >>>received this email in error, please notify the sender immediately, >>>delete this email, and destroy all copies and any attachments. >>> _______________________________________________ >>> FreeTDS mailing list >>> FreeTDS at lists.ibiblio.org >>> http://lists.ibiblio.org/mailman/listinfo/freetds >>_______________________________________________ >>FreeTDS mailing list >>FreeTDS at lists.ibiblio.org >>http://lists.ibiblio.org/mailman/listinfo/freetds > >MFS Email system made the following annotation >-------------------------------------------------------------------------- >------------------------------------------------------------- >This email communication and any attachments may contain proprietary, >confidential, or privileged information. If you are not the intended >recipient, you are hereby notified that you have received this email in >error and that any review, disclosure, dissemination, distribution or >copying of it or its contents is prohibited. The sender does not waive >confidentiality or any privilege by mistransmission. If you have received >this email in error, please notify the sender immediately, delete this >email, and destroy all copies and any attachments. >_______________________________________________ >FreeTDS mailing list >FreeTDS at lists.ibiblio.org >http://lists.ibiblio.org/mailman/listinfo/freetds MFS Email system made the following annotation --------------------------------------------------------------------------------------------------------------------------------------- This email communication and any attachments may contain proprietary, confidential, or privileged information. If you are not the intended recipient, you are hereby notified that you have received this email in error and that any review, disclosure, dissemination, distribution or copying of it or its contents is prohibited. The sender does not waive confidentiality or any privilege by mistransmission. If you have received this email in error, please notify the sender immediately, delete this email, and destroy all copies and any attachments. From freddy77 at gmail.com Sat Oct 10 03:46:46 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Sat, 10 Oct 2015 08:46:46 +0100 Subject: [freetds] Using FreeTDS 0.95 INSERTS fail above 66000 characters...unless 'dump file' is turned on In-Reply-To: References: <5612FF8F.3080800@fsautomation.com> Message-ID: Hi, I'm not actually able to reproduce it. I try to play with different configure options: - gnutls/openssl - enable-extra-checks - enable-mars - disable-libiconv With DBD::Sybase 1.15 compiled from source. I was able to insert up to 10 mb (I didn't try more) without issues. I tried with a script very similar to yours (just add table creation and changed account). Which configure options are you using? I'm actually using Linux so the issue could be something related to the OS. Frediano 2015-10-09 21:29 GMT+01:00 Jacopille, David : > FreeTDS group: > > This issue, which is 100% reproducible in 0.95.20, does not occur at all > in 0.91. > > Insert and select values of 500,000 using FreeTDS 0.91 set to TDSVER=7.1 > worked correctly 20 times in a row. > > I verified the insert as a new record after each run the script. > > Could this just be a bug in the 0.95.20 build? > > Thanks, > Dave > > On 10/7/15, 1:13 PM, "Jacopille, David" wrote: > >>Frediano, >> >>Below is the freetds.log that contains results from these three lines >>from the test script. The INSERT was successful since >>logging/debugging was turned on. It would not have been if logging was >>turned off. >> >>DBI->connect >>USE >>INSERT (string of 100000 ?x? characters) >> >>The logs recorded a lot of repetitive lines on INSERT of 100000 >>?x? characters. >> >>To save space I removed the repetitive lines with nothing but x >>characters, like this example: >> >>.... 00 78 00 78 00 78 00 78-00 78 00 78 00 78 00 78 |.x.x.x.x .x.x.x.x| >> >>I also removed some of the repetitive packet retries for the long insert. >> >>Everything else, including that beginning of the INSERT should be there. >> >>Thank you for looking into this. >> >>Dave >> >>log.c:167:Starting log file for FreeTDS 0.95.20 >> on 2015-10-07 13:06:36 with debug flags 0x4fff. >>iconv.c:328:tds_iconv_open(0x7fa6f687a390, 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 168.66.122.143 port 1433 (TDS version 7.0) >>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 >>login.c:788:using NTLM authentication for 'CORP\jacopille_d' account >>login.c:852:quietly sending TDS 7+ login packet >>token.c:326:tds_process_login_tokens() >>packet.c:639:Received packet >>0000 04 01 00 e3 00 00 00 00-ed d8 00 4e 54 4c 4d 53 |........ ...NTLMS| >>0010 53 50 00 02 00 00 00 08-00 08 00 38 00 00 00 05 |SP...... ...8....| >>0020 82 89 02 f5 e6 ef 6b 26-25 0a 98 00 00 00 00 00 |......k& %.......| >>0030 00 00 00 98 00 98 00 40-00 00 00 06 01 b1 1d 00 |.......@ ........| >>0040 00 00 0f 43 00 4f 00 52-00 50 00 02 00 08 00 43 |...C.O.R .P.....C| >>0050 00 4f 00 52 00 50 00 01-00 10 00 42 00 4f 00 53 |.O.R.P.. ...B.O.S| >>0060 00 53 00 51 00 4c 00 44-00 34 00 04 00 18 00 63 |.S.Q.L.D .4.....c| >>0070 00 6f 00 72 00 70 00 2e-00 6d 00 66 00 73 00 2e |.o.r.p.. .m.f.s..| >>0080 00 63 00 6f 00 6d 00 03-00 2a 00 62 00 6f 00 73 |.c.o.m.. .*.b.o.s| >>0090 00 73 00 71 00 6c 00 64-00 34 00 2e 00 63 00 6f |.s.q.l.d .4...c.o| >>00a0 00 72 00 70 00 2e 00 6d-00 66 00 73 00 2e 00 63 |.r.p...m .f.s...c| >>00b0 00 6f 00 6d 00 05 00 1a-00 77 00 69 00 6e 00 72 |.o.m.... .w.i.n.r| >>00c0 00 6f 00 6f 00 74 00 2e-00 6c 00 6f 00 63 00 61 |.o.o.t.. .l.o.c.a| >>00d0 00 6c 00 07 00 08 00 4e-2f 6c 86 22 01 d1 01 00 |.l.....N /l."....| >>00e0 00 00 00 - |...| >> >>token.c:335:looking for login token, got ed(AUTH) >>token.c:115:tds_process_default_tokens() marker is ed(AUTH) >>token.c:463:TDS_AUTH_TOKEN PDU size 216 >>challenge.c:648:TDS_AUTH_TOKEN nonce >>0000 f5 e6 ef 6b 26 25 0a 98- |...k&%..| >> >>challenge.c:702:Draining 0 bytes >>packet.c:740:Sending packet >>0000 11 01 00 b6 00 00 00 00-4e 54 4c 4d 53 53 50 00 |........ NTLMSSP.| >>0010 03 00 00 00 18 00 18 00-7e 00 00 00 18 00 18 00 |........ ~.......| >>0020 96 00 00 00 08 00 08 00-40 00 00 00 16 00 16 00 |........ @.......| >>0030 48 00 00 00 20 00 20 00-5e 00 00 00 00 00 00 00 |H... . . ^.......| >>0040 ae 00 00 00 01 82 00 00-43 00 4f 00 52 00 50 00 |........ C.O.R.P.| >>0050 6a 00 61 00 63 00 6f 00-70 00 69 00 6c 00 6c 00 |j.a.c.o. p.i.l.l.| >>0060 65 00 5f 00 64 00 30 00-30 00 36 00 2d 00 65 00 |e._.d.0. 0.6.-.e.| >>0070 37 00 32 00 37 00 2e 00-6d 00 66 00 73 00 2e 00 |7.2.7... m.f.s...| >>0080 63 00 6f 00 6d 00 ad ef-62 84 d4 08 0d 87 00 00 |c.o.m... b.......| >>0090 00 00 00 00 00 00 00 00-00 00 00 00 00 00 df c8 |........ ........| >>00a0 2e 96 a9 95 b8 b6 2e f2-7e 0b 80 23 14 d2 e6 c8 |........ ~..#....| >>00b0 90 e7 6a 64 47 2b - |..jdG+| >> >>packet.c:639:Received packet >>0000 04 01 01 94 00 6c 01 00-e3 15 00 01 03 4f 00 74 |.....l.. .....O.t| >>0010 00 6f 00 06 6d 00 61 00-73 00 74 00 65 00 72 00 |.o..m.a. s.t.e.r.| >>0020 ab 60 00 45 16 00 00 02-00 22 00 43 00 68 00 61 |.`.E.... .".C.h.a| >>0030 00 6e 00 67 00 65 00 64-00 20 00 64 00 61 00 74 |.n.g.e.d . .d.a.t| >>0040 00 61 00 62 00 61 00 73-00 65 00 20 00 63 00 6f |.a.b.a.s .e. .c.o| >>0050 00 6e 00 74 00 65 00 78-00 74 00 20 00 74 00 6f |.n.t.e.x .t. .t.o| >>0060 00 20 00 27 00 4f 00 74-00 6f 00 27 00 2e 00 08 |. .'.O.t .o.'....| >>0070 42 00 4f 00 53 00 53 00-51 00 4c 00 44 00 34 00 |B.O.S.S. Q.L.D.4.| >>0080 00 01 00 e3 17 00 02 0a-75 00 73 00 5f 00 65 00 |........ u.s._.e.| >>0090 6e 00 67 00 6c 00 69 00-73 00 68 00 00 ab 6a 00 |n.g.l.i. s.h...j.| >>00a0 47 16 00 00 01 00 27 00-43 00 68 00 61 00 6e 00 |G.....'. C.h.a.n.| >>00b0 67 00 65 00 64 00 20 00-6c 00 61 00 6e 00 67 00 |g.e.d. . l.a.n.g.| >>00c0 75 00 61 00 67 00 65 00-20 00 73 00 65 00 74 00 |u.a.g.e. .s.e.t.| >>00d0 74 00 69 00 6e 00 67 00-20 00 74 00 6f 00 20 00 |t.i.n.g. .t.o. .| >>00e0 75 00 73 00 5f 00 65 00-6e 00 67 00 6c 00 69 00 |u.s._.e. n.g.l.i.| >>00f0 73 00 68 00 2e 00 08 42-00 4f 00 53 00 53 00 51 |s.h....B .O.S.S.Q| >>0100 00 4c 00 44 00 34 00 00-01 00 e3 0f 00 03 05 69 |.L.D.4.. .......i| >>0110 00 73 00 6f 00 5f 00 31-00 01 00 00 e3 0b 00 05 |.s.o._.1 ........| >>0120 04 31 00 30 00 33 00 33-00 00 e3 0f 00 06 06 31 |.1.0.3.3 .......1| >>0130 00 39 00 36 00 36 00 30-00 39 00 00 ad 36 00 01 |.9.6.6.0 .9...6..| >>0140 07 00 00 00 16 4d 00 69-00 63 00 72 00 6f 00 73 |.....M.i .c.r.o.s| >>0150 00 6f 00 66 00 74 00 20-00 53 00 51 00 4c 00 20 |.o.f.t. .S.Q.L. | >>0160 00 53 00 65 00 72 00 76-00 65 00 72 00 00 00 00 |.S.e.r.v .e.r....| >>0170 00 0b 00 0d 6d e3 13 00-04 04 34 00 30 00 39 00 |....m... ..4.0.9.| >>0180 36 00 04 34 00 30 00 39-00 36 00 fd 00 00 00 00 |6..4.0.9 .6......| >>0190 00 00 00 00 - |....| >> >>token.c:335:looking for login token, got e3(ENVCHANGE) >>token.c:115:tds_process_default_tokens() marker is e3(ENVCHANGE) >>token.c:335:looking for login token, got ab(INFO) >>token.c:115:tds_process_default_tokens() marker is ab(INFO) >>token.c:2344:tds_process_msg() reading message 5701 from server >>token.c:2416:tds_process_msg() calling client msg handler >>ctutil.c:142:_ct_handle_server_message(0x7fa6f6874620, 0x7fa6f687a390, >>0x7fff5a6c6680) >>ct.c:350:ct_con_props(0x7fa6f687a2d0, 33, 9108, 0x7fff5a6c5888, 8, 0x0) >>ct.c:352:ct_con_props() action = CS_GET property = 9108 >>ct.c:512:fetching userdata 0x7fa6f6876d90 >>token.c:2429:tds_process_msg() returning TDS_SUCCESS >>token.c:335:looking for login token, got e3(ENVCHANGE) >>token.c:115:tds_process_default_tokens() marker is e3(ENVCHANGE) >>token.c:335:looking for login token, got ab(INFO) >>token.c:115:tds_process_default_tokens() marker is ab(INFO) >>token.c:2344:tds_process_msg() reading message 5703 from server >>token.c:2416:tds_process_msg() calling client msg handler >>ctutil.c:142:_ct_handle_server_message(0x7fa6f6874620, 0x7fa6f687a390, >>0x7fff5a6c6680) >>ct.c:350:ct_con_props(0x7fa6f687a2d0, 33, 9108, 0x7fff5a6c5888, 8, 0x0) >>ct.c:352:ct_con_props() action = CS_GET property = 9108 >>ct.c:512:fetching userdata 0x7fa6f6876d90 >>token.c:2429:tds_process_msg() returning TDS_SUCCESS >>token.c:335:looking for login token, got e3(ENVCHANGE) >>token.c:115:tds_process_default_tokens() marker is e3(ENVCHANGE) >>token.c:2251:server indicated charset change to "iso_1" >>iconv.c:796:setting server single-byte charset to "CP1252" >>token.c:335:looking for login token, got e3(ENVCHANGE) >>token.c:115:tds_process_default_tokens() marker is e3(ENVCHANGE) >>token.c:335:looking for login token, got e3(ENVCHANGE) >>token.c:115:tds_process_default_tokens() marker is e3(ENVCHANGE) >>token.c:335:looking for login token, got ad(LOGINACK) >>token.c:373:server reports TDS version 7.0.0.0 >>token.c:375:Product name for 0x7000000 is 7.0 >>token.c:407:Product version 8B000D6D >>token.c:335:looking for login token, got e3(ENVCHANGE) >>token.c:115:tds_process_default_tokens() marker is e3(ENVCHANGE) >>token.c:2235:changing block size from 4096 to 4096 >>token.c:335:looking for login token, got fd(DONE) >>token.c:115:tds_process_default_tokens() marker is fd(DONE) >>token.c:2080:tds_process_end: more_results = 0 >> was_cancelled = 0 >> error = 0 >> done_count_valid = 0 >>token.c:2097: rows_affected = 0 >>token.c:2100:tds_process_end() state set to TDS_IDLE >>token.c:439:tds_process_login_tokens() returning TDS_SUCCESS >>mem.c:648:tds_free_all_results() >>util.c:165:Changed query state from IDLE to WRITING >>util.c:165:Changed query state from WRITING to PENDING >>packet.c:740:Sending packet >>0000 01 01 00 32 00 00 00 00-73 00 65 00 74 00 20 00 |...2.... s.e.t. .| >>0010 74 00 65 00 78 00 74 00-73 00 69 00 7a 00 65 00 |t.e.x.t. s.i.z.e.| >>0020 20 00 32 00 30 00 30 00-30 00 30 00 30 00 30 00 | .2.0.0. 0.0.0.0.| >>0030 20 00 - | .| >> >>token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c6784, >>0x7fff5a6c6780, 0x100) >>util.c:165:Changed query state from PENDING to READING >>packet.c:639:Received packet >>0000 04 01 00 11 00 6c 01 00-fd 00 00 be 00 00 00 00 |.....l.. ........| >>0010 00 - |.| >> >>token.c:564:processing result tokens. marker is fd(DONE) >>token.c:2080:tds_process_end: more_results = 0 >> was_cancelled = 0 >> error = 0 >> done_count_valid = 0 >>token.c:2097: rows_affected = 0 >>token.c:2100: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 >>token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c6784, >>0x7fff5a6c6780, 0x100) >>token.c:552:tds_process_tokens() state is COMPLETED >>ct.c:656:leaving ct_connect() returning 1 >>ct.c:3383:ct_options(0x7fa6f687a2d0, 34, 5025, 0x7fff5a6c6c44, -99999, >>0x0) >>ct.c:3415:ct_options: CS_SET, option = 5025 >>ct.c:3613: tds_submit_optioncmd will be action(CS_SET) option(25) >>arg(0) >>arglen(1) >>query.c:3411:tds_submit_optioncmd() >>mem.c:648:tds_free_all_results() >>util.c:165:Changed query state from IDLE to WRITING >>util.c:165:Changed query state from WRITING to PENDING >>packet.c:740:Sending packet >>0000 01 01 00 42 00 00 01 00-53 00 45 00 54 00 20 00 |...B.... S.E.T. .| >>0010 49 00 4d 00 50 00 4c 00-49 00 43 00 49 00 54 00 |I.M.P.L. I.C.I.T.| >>0020 5f 00 54 00 52 00 41 00-4e 00 53 00 41 00 43 00 |_.T.R.A. N.S.A.C.| >>0030 54 00 49 00 4f 00 4e 00-53 00 20 00 4f 00 46 00 |T.I.O.N. S. .O.F.| >>0040 46 00 - |F.| >> >>token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c6a74, >>0x7fff5a6c6a70, 0x100) >>util.c:165:Changed query state from PENDING to READING >>packet.c:639:Received packet >>0000 04 01 00 11 00 6c 01 00-fd 00 00 ba 00 00 00 00 |.....l.. ........| >>0010 00 - |.| >> >>token.c:564:processing result tokens. marker is fd(DONE) >>token.c:2080:tds_process_end: more_results = 0 >> was_cancelled = 0 >> error = 0 >> done_count_valid = 0 >>token.c:2097: rows_affected = 0 >>token.c:2100: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 >>token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c6a74, >>0x7fff5a6c6a70, 0x100) >>token.c:552:tds_process_tokens() state is COMPLETED >>ct.c:673:ct_cmd_alloc(0x7fa6f687a2d0, 0x7fff5a6c6ff8) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:223:setting command state to IDLE (from IDLE) >>ct.c:690:ct_cmd_alloc() : allocating command list to head >>ct.c:711:ct_command(0x7fa6f5400040, 148, 0x7fff5a6c71c0, -9, -99999) >>ct.c:850:_ct_initialise_cmd(0x7fa6f5400040) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:223:setting command state to IDLE (from IDLE) >>ct.c:4033:rpc_clear(0x0) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:223:setting command state to IDLE (from IDLE) >>ct.c:235:ct_describe_cmd_state(2) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:223:setting command state to READY (from IDLE) >>ct.c:869:ct_send(0x7fa6f5400040) >>ct.c:871:ct_send() command_type = 148 >>mem.c:648:tds_free_all_results() >>util.c:165:Changed query state from IDLE to WRITING >>util.c:165:Changed query state from WRITING to PENDING >>packet.c:740:Sending packet >>0000 01 01 00 28 00 00 01 00-73 00 65 00 6c 00 65 00 |...(.... s.e.l.e.| >>0010 63 00 74 00 20 00 40 00-40 00 76 00 65 00 72 00 |c.t. . at . @.v.e.r.| >>0020 73 00 69 00 6f 00 6e 00- |s.i.o.n.| >> >>ct.c:235:ct_describe_cmd_state(3) >>ct.c:235:ct_describe_cmd_state(2) >>ct.c:223:setting command state to SENT (from READY) >>ct.c:994:ct_send() succeeded >>ct.c:1132:ct_results(0x7fa6f5400040, 0x7fff5a6c6ff4) >>token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c6f84, >>0x7fff5a6c6f80, 0x6914) >>util.c:165:Changed query state from PENDING to READING >>packet.c:639:Received packet >>0000 04 01 01 bd 00 6c 01 00-81 01 00 00 00 21 00 e7 |.....l.. .....!..| >>0010 58 02 00 d1 9e 01 4d 00-69 00 63 00 72 00 6f 00 |X.....M. i.c.r.o.| >>0020 73 00 6f 00 66 00 74 00-20 00 53 00 51 00 4c 00 |s.o.f.t. .S.Q.L.| >>0030 20 00 53 00 65 00 72 00-76 00 65 00 72 00 20 00 | .S.e.r. v.e.r. .| >>0040 32 00 30 00 31 00 32 00-20 00 28 00 53 00 50 00 |2.0.1.2. .(.S.P.| >>0050 31 00 29 00 20 00 2d 00-20 00 31 00 31 00 2e 00 |1.). .-. .1.1...| >>0060 30 00 2e 00 33 00 34 00-33 00 37 00 2e 00 30 00 |0...3.4. 3.7...0.| >>0070 20 00 28 00 58 00 36 00-34 00 29 00 20 00 0a 00 | .(.X.6. 4.). ...| >>0080 09 00 4d 00 61 00 79 00-20 00 32 00 39 00 20 00 |..M.a.y. .2.9. .| >>0090 32 00 30 00 31 00 34 00-20 00 31 00 36 00 3a 00 |2.0.1.4. .1.6.:.| >>00a0 30 00 33 00 3a 00 34 00-30 00 20 00 0a 00 09 00 |0.3.:.4. 0. .....| >>00b0 43 00 6f 00 70 00 79 00-72 00 69 00 67 00 68 00 |C.o.p.y. r.i.g.h.| >>00c0 74 00 20 00 28 00 63 00-29 00 20 00 4d 00 69 00 |t. .(.c. ). .M.i.| >>00d0 63 00 72 00 6f 00 73 00-6f 00 66 00 74 00 20 00 |c.r.o.s. o.f.t. .| >>00e0 43 00 6f 00 72 00 70 00-6f 00 72 00 61 00 74 00 |C.o.r.p. o.r.a.t.| >>00f0 69 00 6f 00 6e 00 0a 00-09 00 44 00 65 00 76 00 |i.o.n... ..D.e.v.| >>0100 65 00 6c 00 6f 00 70 00-65 00 72 00 20 00 45 00 |e.l.o.p. e.r. .E.| >>0110 64 00 69 00 74 00 69 00-6f 00 6e 00 20 00 28 00 |d.i.t.i. o.n. .(.| >>0120 36 00 34 00 2d 00 62 00-69 00 74 00 29 00 20 00 |6.4.-.b. i.t.). .| >>0130 6f 00 6e 00 20 00 57 00-69 00 6e 00 64 00 6f 00 |o.n. .W. i.n.d.o.| >>0140 77 00 73 00 20 00 4e 00-54 00 20 00 36 00 2e 00 |w.s. .N. T. .6...| >>0150 31 00 20 00 3c 00 58 00-36 00 34 00 3e 00 20 00 |1. .<.X. 6.4.>. .| >>0160 28 00 42 00 75 00 69 00-6c 00 64 00 20 00 37 00 |(.B.u.i. l.d. .7.| >>0170 36 00 30 00 31 00 3a 00-20 00 53 00 65 00 72 00 |6.0.1.:. .S.e.r.| >>0180 76 00 69 00 63 00 65 00-20 00 50 00 61 00 63 00 |v.i.c.e. .P.a.c.| >>0190 6b 00 20 00 31 00 29 00-20 00 28 00 48 00 79 00 |k. .1.). .(.H.y.| >>01a0 70 00 65 00 72 00 76 00-69 00 73 00 6f 00 72 00 |p.e.r.v. i.s.o.r.| >>01b0 29 00 0a 00 fd 10 00 c1-00 01 00 00 00 |)....... .....| >> >>token.c:564:processing result tokens. marker is 81(TDS7_RESULT) >>token.c:1573:processing TDS7 result metadata. >>mem.c:648:tds_free_all_results() >>token.c:1598:set current_results (1 column) to tds->res_info >>token.c:1605:setting up 1 columns >>token.c:3164:adjust_character_column_size: >> Server charset: UCS-2LE >> Server column_size: 600 >> Client charset: UTF-8 >> Client column_size: 1200 >>token.c:1542:tds7_get_data_info: >> colname = >> type = 39 (varchar) >> server's type = 231 (x UCS-2 varchar) >> column_varint_size = 2 >> column_size = 1200 (600 on server) >>token.c:1614: name size/wsize type/wtype utype >>token.c:1615: -------------------- --------------- --------------- ------- >>token.c:1620: 1200/600 39/231 0 >>util.c:165:Changed query state from READING to PENDING >>ct.c:1189:ct_results() process_result_tokens returned 0 (type 4049) >>token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c6f84, >>0x7fff5a6c6f80, 0x6914) >>util.c:165:Changed query state from PENDING to READING >>token.c:564:processing result tokens. marker is d1(ROW) >>token.c:680:tds_process_tokens::SET_RETURN stopping on current token >>util.c:165:Changed query state from READING to PENDING >>ct.c:1189:ct_results() process_result_tokens returned 0 (type 4040) >>ct.c:2283:ct_describe(0x7fa6f5400040, 1, 0x7fff5a6c7000) >>ct.c:1896:_ct_get_client_type(type 39, user 0, size 1200) >>ct.c:2304:ct_describe() datafmt->datatype = 0 server type 39 >>ct.c:1457:ct_bind(0x7fa6f5400040, 1, 0x7fff5a6c7000, 0x7fff5a6c70c0, >>0x7fff5a6c6ff0, 0x7fff5a6c6fee) >>ct.c:1459:ct_bind() datafmt count = 1 column_number = 1 >>ct.c:1518:ct_fetch(0x7fa6f5400040, -99999, -99999, -99999, 0x7fff5a6c6fe8) >>token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c6f7c, 0x0, >>0x1608) >>util.c:165:Changed query state from PENDING to READING >>token.c:564:processing result tokens. marker is d1(ROW) >>token.c:1951:tds_process_row(): reading column 0 >>data.c:534:tds_get_data: type 39, varint size 2 >>data.c:587:tds_get_data(): wire column size is 414 >>util.c:165:Changed query state from READING to PENDING >>ct.c:1583:inside ct_fetch() process_row_tokens returned 0 >>ct.c:1723:_ct_bind_data(0x7fa6f576fd50, 0x7fa6f687adc0, 0x7fa6f687adc0, 0) >>ct.c:1730:_ct_bind_data(): column 0 is type 39 and has length 207 >>ct.c:1896:_ct_get_client_type(type 39, user 0, size 1200) >>cs.c:473:cs_convert(0x7fa6f576fd50, 0x7fff5a6c6e50, 0x7fa6f3a11c00, >>0x7fff5a6c6da0, 0x7fff5a6c70c0, 0x7fff5a6c6ff0) >>ct.c:2007:_ct_get_server_type(0) >>ct.c:2007:_ct_get_server_type(0) >>cs.c:521:converting type 47 (207 bytes) to type = 47 (255 bytes) >>cs.c:535:cs_convert() srctype == desttype >>cs.c:571:cs_convert() desttype = character >>cs.c:53:cs_prretcode(1) >>cs.c:660:cs_convert() returning CS_SUCCEED >>ct.c:1518:ct_fetch(0x7fa6f5400040, -99999, -99999, -99999, 0x7fff5a6c6fe8) >>ct.c:1132:ct_results(0x7fa6f5400040, 0x7fff5a6c6ff4) >>token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c6f84, >>0x7fff5a6c6f80, 0x6914) >>util.c:165:Changed query state from PENDING to READING >>token.c:564:processing result tokens. marker is fd(DONE) >>token.c:2080:tds_process_end: more_results = 0 >> was_cancelled = 0 >> error = 0 >> done_count_valid = 1 >>token.c:2097: rows_affected = 1 >>token.c:2100: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:1189:ct_results() process_result_tokens returned 0 (type 4052) >>ct.c:1295:ct_results() results state = 2 >>ct.c:1296:ct_results() command type = 148 >>ct.c:1297:ct_results() dynamic cmd = 0 >>ct.c:1132:ct_results(0x7fa6f5400040, 0x7fff5a6c6ff4) >>token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c6f84, >>0x7fff5a6c6f80, 0x6914) >>token.c:552:tds_process_tokens() state is COMPLETED >>ct.c:1189:ct_results() process_result_tokens returned 1 (type 4052) >>ct.c:235:ct_describe_cmd_state(2) >>ct.c:235:ct_describe_cmd_state(3) >>ct.c:223:setting command state to READY (from SENT) >>ct.c:1796:ct_cmd_drop(0x7fa6f5400040) >>ct.c:1827:ct_cmd_drop() : command entry found in list >>ct.c:1832:ct_cmd_drop() : relinking list >>ct.c:1839:ct_cmd_drop() : relinked list >>ct.c:673:ct_cmd_alloc(0x7fa6f687a2d0, 0x7fff5a6c6de0) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:223:setting command state to IDLE (from IDLE) >>ct.c:690:ct_cmd_alloc() : allocating command list to head >>ct.c:711:ct_command(0x7fa6f5359360, 148, 0x7fa6f2c01f00, -9, -99999) >>ct.c:850:_ct_initialise_cmd(0x7fa6f5359360) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:223:setting command state to IDLE (from IDLE) >>ct.c:4033:rpc_clear(0x0) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:223:setting command state to IDLE (from IDLE) >>ct.c:235:ct_describe_cmd_state(2) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:223:setting command state to READY (from IDLE) >>ct.c:869:ct_send(0x7fa6f5359360) >>ct.c:871:ct_send() command_type = 148 >>mem.c:648:tds_free_all_results() >>util.c:165:Changed query state from IDLE to WRITING >>util.c:165:Changed query state from WRITING to PENDING >>packet.c:740:Sending packet >>0000 01 01 00 18 00 00 01 00-75 00 73 00 65 00 20 00 |........ u.s.e. .| >>0010 6f 00 74 00 6f 00 33 00- |o.t.o.3.| >> >>ct.c:235:ct_describe_cmd_state(3) >>ct.c:235:ct_describe_cmd_state(2) >>ct.c:223:setting command state to SENT (from READY) >>ct.c:994:ct_send() succeeded >>ct.c:1132:ct_results(0x7fa6f5359360, 0x7fff5a6c66d0) >>token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c65f4, >>0x7fff5a6c65f0, 0x6914) >>util.c:165:Changed query state from PENDING to READING >>packet.c:639:Received packet >>0000 04 01 00 8a 00 6c 01 00-e3 11 00 01 04 4f 00 54 |.....l.. .....O.T| >>0010 00 4f 00 33 00 03 4f 00-54 00 4f 00 ab 62 00 45 |.O.3..O. T.O..b.E| >>0020 16 00 00 01 00 23 00 43-00 68 00 61 00 6e 00 67 |.....#.C .h.a.n.g| >>0030 00 65 00 64 00 20 00 64-00 61 00 74 00 61 00 62 |.e.d. .d .a.t.a.b| >>0040 00 61 00 73 00 65 00 20-00 63 00 6f 00 6e 00 74 |.a.s.e. .c.o.n.t| >>0050 00 65 00 78 00 74 00 20-00 74 00 6f 00 20 00 27 |.e.x.t. .t.o. .'| >>0060 00 4f 00 54 00 4f 00 33-00 27 00 2e 00 08 42 00 |.O.T.O.3 .'....B.| >>0070 4f 00 53 00 53 00 51 00-4c 00 44 00 34 00 00 01 |O.S.S.Q. L.D.4...| >>0080 00 fd 00 00 e2 00 00 00-00 00 |........ ..| >> >>token.c:564:processing result tokens. marker is e3(ENVCHANGE) >>token.c:115:tds_process_default_tokens() marker is e3(ENVCHANGE) >>token.c:564:processing result tokens. marker is ab(INFO) >>token.c:115:tds_process_default_tokens() marker is ab(INFO) >>token.c:2344:tds_process_msg() reading message 5701 from server >>token.c:2416:tds_process_msg() calling client msg handler >>ctutil.c:142:_ct_handle_server_message(0x7fa6f6874620, 0x7fa6f687a390, >>0x7fff5a6c6420) >>ct.c:350:ct_con_props(0x7fa6f687a2d0, 33, 9108, 0x7fff5a6c5628, 8, 0x0) >>ct.c:352:ct_con_props() action = CS_GET property = 9108 >>ct.c:512:fetching userdata 0x7fa6f6876d90 >>token.c:2429:tds_process_msg() returning TDS_SUCCESS >>token.c:564:processing result tokens. marker is fd(DONE) >>token.c:2080:tds_process_end: more_results = 0 >> was_cancelled = 0 >> error = 0 >> done_count_valid = 0 >>token.c:2097: rows_affected = 0 >>token.c:2100: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:1189:ct_results() process_result_tokens returned 0 (type 4052) >>ct.c:1295:ct_results() results state = 0 >>ct.c:1296:ct_results() command type = 148 >>ct.c:1297:ct_results() dynamic cmd = 0 >>ct.c:2347:ct_res_info(0x7fa6f5359360, 800, 0x7fa6f2c67598, -99999, 0x0) >>ct.c:2372:ct_res_info(): Number of rows is -1 >>ct.c:1132:ct_results(0x7fa6f5359360, 0x7fff5a6c66d0) >>ct.c:2347:ct_res_info(0x7fa6f5359360, 800, 0x7fa6f2c67598, -99999, 0x0) >>ct.c:2372:ct_res_info(): Number of rows is -1 >>ct.c:1132:ct_results(0x7fa6f5359360, 0x7fff5a6c66d0) >>token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c65f4, >>0x7fff5a6c65f0, 0x6914) >>token.c:552:tds_process_tokens() state is COMPLETED >>ct.c:1189:ct_results() process_result_tokens returned 1 (type 4052) >>ct.c:235:ct_describe_cmd_state(2) >>ct.c:235:ct_describe_cmd_state(3) >>ct.c:223:setting command state to READY (from SENT) >>ct.c:1796:ct_cmd_drop(0x7fa6f5359360) >>ct.c:1827:ct_cmd_drop() : command entry found in list >>ct.c:1832:ct_cmd_drop() : relinking list >>ct.c:1839:ct_cmd_drop() : relinked list >>ct.c:673:ct_cmd_alloc(0x7fa6f687a2d0, 0x7fff5a6c6de0) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:223:setting command state to IDLE (from IDLE) >>ct.c:690:ct_cmd_alloc() : allocating command list to head >>ct.c:711:ct_command(0x7fa6f5145ea0, 148, 0x1056b8000, -9, -99999) >>ct.c:850:_ct_initialise_cmd(0x7fa6f5145ea0) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:223:setting command state to IDLE (from IDLE) >>ct.c:4033:rpc_clear(0x0) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:223:setting command state to IDLE (from IDLE) >>ct.c:235:ct_describe_cmd_state(2) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:223:setting command state to READY (from IDLE) >>ct.c:869:ct_send(0x7fa6f5145ea0) >>ct.c:871:ct_send() command_type = 148 >>mem.c:648:tds_free_all_results() >>util.c:165:Changed query state from IDLE to WRITING >>packet.c:740:Sending packet >>0000 01 00 10 00 00 00 01 00-49 00 4e 00 53 00 45 00 |........ I.N.S.E.| >>0010 52 00 54 00 20 00 69 00-6e 00 74 00 6f 00 20 00 |R.T. .i. n.t.o. .| >>0020 54 00 45 00 53 00 54 00-54 00 41 00 42 00 4c 00 |T.E.S.T. T.A.B.L.| >>0030 45 00 20 00 28 00 6d 00-61 00 78 00 74 00 65 00 |E. .(.m. a.x.t.e.| >>0040 78 00 74 00 29 00 20 00-76 00 61 00 6c 00 75 00 |x.t.). . v.a.l.u.| >>0050 65 00 73 00 20 00 28 00-4e 00 27 00 78 00 78 00 |e.s. .(. N.'.x.x.| >> >>stream.c:125:Error: tds_convert_stream: tds_iconv returned errno 7, >>conv_errno 7 >>packet.c:740:Sending packet >>0000 01 00 10 00 00 00 01 00-78 00 78 00 78 00 78 00 |........ x.x.x.x.| >> >>packet.c:740:Sending packet >>0000 01 00 10 00 00 00 01 00-78 00 78 00 78 00 78 00 |........ x.x.x.x.| >> >>stream.c:125:Error: tds_convert_stream: tds_iconv returned errno 7, >>conv_errno 7 >>packet.c:740:Sending packet >>0000 01 00 10 00 00 00 01 00-78 00 78 00 78 00 78 00 |........ x.x.x.x.| >> >>stream.c:125:Error: tds_convert_stream: tds_iconv returned errno 7, >>conv_errno 7 >>util.c:165:Changed query state from WRITING to PENDING >>packet.c:740:Sending packet >>0000 01 01 0f 20 00 00 01 00-78 00 78 00 78 00 78 00 |... .... x.x.x.x.| >>0f10 78 00 78 00 78 00 78 00-78 00 78 00 27 00 29 00 |x.x.x.x. x.x.'.).| >> >>ct.c:235:ct_describe_cmd_state(3) >>ct.c:235:ct_describe_cmd_state(2) >>ct.c:223:setting command state to SENT (from READY) >>ct.c:994:ct_send() succeeded >>ct.c:1132:ct_results(0x7fa6f5145ea0, 0x7fff5a6c66d0) >>token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c65f4, >>0x7fff5a6c65f0, 0x6914) >>util.c:165:Changed query state from PENDING to READING >>packet.c:639:Received packet >>0000 04 01 00 11 00 6c 01 00-fd 10 00 c3 00 01 00 00 |.....l.. ........| >>0010 00 - |.| >> >>token.c:564:processing result tokens. marker is fd(DONE) >>token.c:2080:tds_process_end: more_results = 0 >> was_cancelled = 0 >> error = 0 >> done_count_valid = 1 >>token.c:2097: rows_affected = 1 >>token.c:2100: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:1189:ct_results() process_result_tokens returned 0 (type 4052) >>ct.c:1295:ct_results() results state = 0 >>ct.c:1296:ct_results() command type = 148 >>ct.c:1297:ct_results() dynamic cmd = 0 >>ct.c:2347:ct_res_info(0x7fa6f5145ea0, 800, 0x7fa6f687a908, -99999, 0x0) >>ct.c:2372:ct_res_info(): Number of rows is 1 >>ct.c:1132:ct_results(0x7fa6f5145ea0, 0x7fff5a6c66d0) >>ct.c:2347:ct_res_info(0x7fa6f5145ea0, 800, 0x7fa6f687a908, -99999, 0x0) >>ct.c:2372:ct_res_info(): Number of rows is 1 >>ct.c:1132:ct_results(0x7fa6f5145ea0, 0x7fff5a6c66d0) >>token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c65f4, >>0x7fff5a6c65f0, 0x6914) >>token.c:552:tds_process_tokens() state is COMPLETED >>ct.c:1189:ct_results() process_result_tokens returned 1 (type 4052) >>ct.c:235:ct_describe_cmd_state(2) >>ct.c:235:ct_describe_cmd_state(3) >>ct.c:223:setting command state to READY (from SENT) >>ct.c:1796:ct_cmd_drop(0x7fa6f5145ea0) >>ct.c:1827:ct_cmd_drop() : command entry found in list >>ct.c:1832:ct_cmd_drop() : relinking list >>ct.c:1839:ct_cmd_drop() : relinked list >> >> >> >> >> >> >>On 10/7/15, 11:37 AM, "Frediano Ziglio" wrote: >> >>>I won't be surprised if there are also some limit in sql server. >>> >>>You are sending the data inside a language query string. It's quite >>>surprising changing log settings solve the issue, perhaps there is a >>>bug inside Ctlib (DBD::Sybase should use ctlib). You can try using a >>>packet sniffer to get traffic with the server. Can you post (or send >>>to me if you prefer) the logs anyway? >>>Probably you'd better compress them. From the log we can understand >>>which calls DBD::Sybase does so I can try reproduce with C directly. >>> >>>Frediano >>> >>> >>>2015-10-06 1:36 GMT+01:00 Jacopille, David : >>>> DC - Thanks for the quick reply. Text size is positively set to one >>>>million characters. >>>> >>>> 1. The data SELECT of 500,000 characters always works. >>>> 2. SELECT @@textsize does confirm the 1,000,000 setting (but the above >>>>also proves functionality) >>>> 3. 'Text size' setting only applies to SELECT statements, not INSERT >>>>where we are having the issue. This is demonstrably true for MS SQL >>>>Server, which we are using. Don't know about other databases. >>>> >>>> SQL Server 2012 nvarchar(max) does hold 2 GB theoretical. This >>>>specific table and nvarchar(max) column has proven to handle far more >>>>than the 1 MB values I'm testing with. At least through other >>>>software. >>>> >>>> I suspect that there is a bug in either FreeTDS 0.95 or DBD::Sybase >>>>1.15 that is limiting the text. However I find FreeTDS more suspicious >>>>because turning on logging (which changes something in FreeTDS) fixes >>>>the problem. >>>> >>>> Unfortunately the thing that would be useful to find the problem is >>>>what fixes the problem. >>>> >>>> Dave >>>> >>>> -----Original Message----- >>>> From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of >>>>David Chang >>>> Sent: Monday, October 05, 2015 6:54 PM >>>> To: FreeTDS Development Group >>>> Subject: Re: [freetds] Using FreeTDS 0.95 INSERTS fail above 66000 >>>>characters...unless 'dump file' is turned on >>>> >>>> Dave, >>>> >>>> I see you set the text size in the freetds.conf file to 1000000. I >>>>would confirm it using 'select @@textsize'. >>>> >>>> DC >>>> >>>> On 10/5/2015 2:07 PM, Jacopille, David wrote: >>>>> Looking for suggestions or a troubleshooting approach on this 100% >>>>> reproducible issue where FreeTDS logging seems to be the only >>>>>variable. >>>>> >>>>> Since the issue goes away as soon as I turn on freetds logging I can?t >>>>> look at the logs to find the problem. >>>>> >>>>> ENVIRONMENT >>>>> SQL Server 2012 >>>>> OS X 10.9.5 >>>>> FreeTDS 0.95.20 >>>>> DBD::Sybase 1.15 >>>>> TDSVER 7.0 or 7.1 (same symptoms) >>>>> Perl 5.16.3 >>>>> FreeTDS text size = 1000000 >>>>> >>>>> Testing large string INSERTS to a table with a single, nvarchar(max), >>>>> column >>>>> >>>>> >>>>> WHAT WORKS >>>>> A. With freetds logging on (via 'dump file = /tmp/freetds.log?) INSERT >>>>> values from 0-500,000 characters are successful. Decreasing >>>>> reliability above 500,000 characters. >>>>> >>>>> B. INSERT statements with values of 0 thru 66,000 characters always >>>>> work, regardless of freetds logging on/off >>>>> >>>>> C. SELECT work correctly for all values 0 thru one million characters, >>>>> regardless of freetds logging on/off >>>>> >>>>> >>>>> DOES NOT WORK >>>>> If freetds logging is turned off the following fails consistently: >>>>> >>>>> A. 67,000 character INSERT stalls at INSERT >>>>> >>>>> B. 100,000+ character INSERT doesn?t stall but doesn?t >>>>>INSERT >>>>> >>>>> C. Stored Procedures also experiencing failures in same character >>>>> ranges >>>>> >>>>> >>>>> FREETDS.CONF >>>>> >>>>> # In the failure configuration it looks like this. >>>>> # The ?DOES NOT WORK? symptoms go away if the last two lines are >>>>> uncommented. >>>>> >>>>> [global] >>>>> client charset = UTF-8 >>>>> text size = 1000000 >>>>> >>>>> [bossqld4] >>>>> host = bossqld4.mfs.com >>>>> port = 1433 >>>>> tds version = 7.0 >>>>> #dump file = /tmp/freetds.log >>>>> #dump file append = no >>>>> >>>>> >>>>> PERL SCRIPT REPRODUCING ISSUE (WITH NO FREETDS LOGGING) >>>>> >>>>> use DBI qw(:sql_types); >>>>> use DBD::Sybase; >>>>> my ($sql, $dbh, $ref, $largetext); >>>>> >>>>> $dbh = DBI->connect( 'DBI:Sybase:server=bossqld4', ?CORP\user', >>>>> ?password', { PrintError => 0 } ) or die; $dbh->do('use >>>>> testdatabase'); >>>>> >>>>> $largetext = 'x' x 100000; # one hundred thousand characters >>>>> >>>>> $dbh->do(qq|INSERT into TESTTABLE (maxtext) values >>>>> (N\'$largetext\')|); >>>>> >>>>> # SELECT not affected by FreeTDS logging on/off # SELECT always >>>>> successful on all values tested up to one million characters (and >>>>> probably much larger, but untested). >>>>> >>>>> $sql = q|SELECT TOP 1 [maxtext] FROM TESTTABLE|; $ref = >>>>> $dbh->selectrow_arrayref($sql); print 'Length of value: '. (length >>>>> $$ref[0]) ."\n"; >>>>> >>>>> $dbh->disconnect(); >>>>> >>>>> >>>>> Thank you, >>>>> Dave Jacopille >>>>> Boston >>>>> >>>>> MFS Email system made the following annotation >>>>> ---------------------------------------------------------------------- >>>>> ----------------------------------------------------------------- >>>>> This email communication and any attachments may contain proprietary, >>>>>confidential, or privileged information. If you are not the intended >>>>>recipient, you are hereby notified that you have received this email in >>>>>error and that any review, disclosure, dissemination, distribution or >>>>>copying of it or its contents is prohibited. The sender does not waive >>>>>confidentiality or any privilege by mistransmission. If you have >>>>>received this email in error, please notify the sender immediately, >>>>>delete this email, and destroy all copies and any attachments. >>>>> _______________________________________________ >>>>> FreeTDS mailing list >>>>> FreeTDS at lists.ibiblio.org >>>>> http://lists.ibiblio.org/mailman/listinfo/freetds >>>> >>>> _______________________________________________ >>>> FreeTDS mailing list >>>> FreeTDS at lists.ibiblio.org >>>> http://lists.ibiblio.org/mailman/listinfo/freetds >>>> MFS Email system made the following annotation >>>> >>>>------------------------------------------------------------------------ >>>>- >>>>-------------------------------------------------------------- >>>> This email communication and any attachments may contain proprietary, >>>>confidential, or privileged information. If you are not the intended >>>>recipient, you are hereby notified that you have received this email in >>>>error and that any review, disclosure, dissemination, distribution or >>>>copying of it or its contents is prohibited. The sender does not waive >>>>confidentiality or any privilege by mistransmission. If you have >>>>received this email in error, please notify the sender immediately, >>>>delete this email, and destroy all copies and any attachments. >>>> _______________________________________________ >>>> FreeTDS mailing list >>>> FreeTDS at lists.ibiblio.org >>>> http://lists.ibiblio.org/mailman/listinfo/freetds >>>_______________________________________________ >>>FreeTDS mailing list >>>FreeTDS at lists.ibiblio.org >>>http://lists.ibiblio.org/mailman/listinfo/freetds >> >>MFS Email system made the following annotation >>-------------------------------------------------------------------------- >>------------------------------------------------------------- >>This email communication and any attachments may contain proprietary, >>confidential, or privileged information. If you are not the intended >>recipient, you are hereby notified that you have received this email in >>error and that any review, disclosure, dissemination, distribution or >>copying of it or its contents is prohibited. The sender does not waive >>confidentiality or any privilege by mistransmission. If you have received >>this email in error, please notify the sender immediately, delete this >>email, and destroy all copies and any attachments. >>_______________________________________________ >>FreeTDS mailing list >>FreeTDS at lists.ibiblio.org >>http://lists.ibiblio.org/mailman/listinfo/freetds > > MFS Email system made the following annotation > --------------------------------------------------------------------------------------------------------------------------------------- > This email communication and any attachments may contain proprietary, confidential, or privileged information. If you are not the intended recipient, you are hereby notified that you have received this email in error and that any review, disclosure, dissemination, distribution or copying of it or its contents is prohibited. The sender does not waive confidentiality or any privilege by mistransmission. If you have received this email in error, please notify the sender immediately, delete this email, and destroy all copies and any attachments. > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From freddy77 at gmail.com Sat Oct 10 11:58:07 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Sat, 10 Oct 2015 16:58:07 +0100 Subject: [freetds] Using FreeTDS 0.95 INSERTS fail above 66000 characters...unless 'dump file' is turned on In-Reply-To: References: <5612FF8F.3080800@fsautomation.com> Message-ID: Fixed in Git. You can get a new minor version at the website. Was more complicated than expected. Looks like Linux is quite different from Mac OS X but anyway was documented in the man page. On some condition some partial write can occurs which make client loose sync with the server. Frediano 2015-10-09 21:29 GMT+01:00 Jacopille, David : > FreeTDS group: > > This issue, which is 100% reproducible in 0.95.20, does not occur at all > in 0.91. > > Insert and select values of 500,000 using FreeTDS 0.91 set to TDSVER=7.1 > worked correctly 20 times in a row. > > I verified the insert as a new record after each run the script. > > Could this just be a bug in the 0.95.20 build? > > Thanks, > Dave > > On 10/7/15, 1:13 PM, "Jacopille, David" wrote: > >>Frediano, >> >>Below is the freetds.log that contains results from these three lines >>from the test script. The INSERT was successful since >>logging/debugging was turned on. It would not have been if logging was >>turned off. >> >>DBI->connect >>USE >>INSERT (string of 100000 ?x? characters) >> >>The logs recorded a lot of repetitive lines on INSERT of 100000 >>?x? characters. >> >>To save space I removed the repetitive lines with nothing but x >>characters, like this example: >> >>.... 00 78 00 78 00 78 00 78-00 78 00 78 00 78 00 78 |.x.x.x.x .x.x.x.x| >> >>I also removed some of the repetitive packet retries for the long insert. >> >>Everything else, including that beginning of the INSERT should be there. >> >>Thank you for looking into this. >> >>Dave >> >>log.c:167:Starting log file for FreeTDS 0.95.20 >> on 2015-10-07 13:06:36 with debug flags 0x4fff. >>iconv.c:328:tds_iconv_open(0x7fa6f687a390, 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 168.66.122.143 port 1433 (TDS version 7.0) >>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 >>login.c:788:using NTLM authentication for 'CORP\jacopille_d' account >>login.c:852:quietly sending TDS 7+ login packet >>token.c:326:tds_process_login_tokens() >>packet.c:639:Received packet >>0000 04 01 00 e3 00 00 00 00-ed d8 00 4e 54 4c 4d 53 |........ ...NTLMS| >>0010 53 50 00 02 00 00 00 08-00 08 00 38 00 00 00 05 |SP...... ...8....| >>0020 82 89 02 f5 e6 ef 6b 26-25 0a 98 00 00 00 00 00 |......k& %.......| >>0030 00 00 00 98 00 98 00 40-00 00 00 06 01 b1 1d 00 |.......@ ........| >>0040 00 00 0f 43 00 4f 00 52-00 50 00 02 00 08 00 43 |...C.O.R .P.....C| >>0050 00 4f 00 52 00 50 00 01-00 10 00 42 00 4f 00 53 |.O.R.P.. ...B.O.S| >>0060 00 53 00 51 00 4c 00 44-00 34 00 04 00 18 00 63 |.S.Q.L.D .4.....c| >>0070 00 6f 00 72 00 70 00 2e-00 6d 00 66 00 73 00 2e |.o.r.p.. .m.f.s..| >>0080 00 63 00 6f 00 6d 00 03-00 2a 00 62 00 6f 00 73 |.c.o.m.. .*.b.o.s| >>0090 00 73 00 71 00 6c 00 64-00 34 00 2e 00 63 00 6f |.s.q.l.d .4...c.o| >>00a0 00 72 00 70 00 2e 00 6d-00 66 00 73 00 2e 00 63 |.r.p...m .f.s...c| >>00b0 00 6f 00 6d 00 05 00 1a-00 77 00 69 00 6e 00 72 |.o.m.... .w.i.n.r| >>00c0 00 6f 00 6f 00 74 00 2e-00 6c 00 6f 00 63 00 61 |.o.o.t.. .l.o.c.a| >>00d0 00 6c 00 07 00 08 00 4e-2f 6c 86 22 01 d1 01 00 |.l.....N /l."....| >>00e0 00 00 00 - |...| >> >>token.c:335:looking for login token, got ed(AUTH) >>token.c:115:tds_process_default_tokens() marker is ed(AUTH) >>token.c:463:TDS_AUTH_TOKEN PDU size 216 >>challenge.c:648:TDS_AUTH_TOKEN nonce >>0000 f5 e6 ef 6b 26 25 0a 98- |...k&%..| >> >>challenge.c:702:Draining 0 bytes >>packet.c:740:Sending packet >>0000 11 01 00 b6 00 00 00 00-4e 54 4c 4d 53 53 50 00 |........ NTLMSSP.| >>0010 03 00 00 00 18 00 18 00-7e 00 00 00 18 00 18 00 |........ ~.......| >>0020 96 00 00 00 08 00 08 00-40 00 00 00 16 00 16 00 |........ @.......| >>0030 48 00 00 00 20 00 20 00-5e 00 00 00 00 00 00 00 |H... . . ^.......| >>0040 ae 00 00 00 01 82 00 00-43 00 4f 00 52 00 50 00 |........ C.O.R.P.| >>0050 6a 00 61 00 63 00 6f 00-70 00 69 00 6c 00 6c 00 |j.a.c.o. p.i.l.l.| >>0060 65 00 5f 00 64 00 30 00-30 00 36 00 2d 00 65 00 |e._.d.0. 0.6.-.e.| >>0070 37 00 32 00 37 00 2e 00-6d 00 66 00 73 00 2e 00 |7.2.7... m.f.s...| >>0080 63 00 6f 00 6d 00 ad ef-62 84 d4 08 0d 87 00 00 |c.o.m... b.......| >>0090 00 00 00 00 00 00 00 00-00 00 00 00 00 00 df c8 |........ ........| >>00a0 2e 96 a9 95 b8 b6 2e f2-7e 0b 80 23 14 d2 e6 c8 |........ ~..#....| >>00b0 90 e7 6a 64 47 2b - |..jdG+| >> >>packet.c:639:Received packet >>0000 04 01 01 94 00 6c 01 00-e3 15 00 01 03 4f 00 74 |.....l.. .....O.t| >>0010 00 6f 00 06 6d 00 61 00-73 00 74 00 65 00 72 00 |.o..m.a. s.t.e.r.| >>0020 ab 60 00 45 16 00 00 02-00 22 00 43 00 68 00 61 |.`.E.... .".C.h.a| >>0030 00 6e 00 67 00 65 00 64-00 20 00 64 00 61 00 74 |.n.g.e.d . .d.a.t| >>0040 00 61 00 62 00 61 00 73-00 65 00 20 00 63 00 6f |.a.b.a.s .e. .c.o| >>0050 00 6e 00 74 00 65 00 78-00 74 00 20 00 74 00 6f |.n.t.e.x .t. .t.o| >>0060 00 20 00 27 00 4f 00 74-00 6f 00 27 00 2e 00 08 |. .'.O.t .o.'....| >>0070 42 00 4f 00 53 00 53 00-51 00 4c 00 44 00 34 00 |B.O.S.S. Q.L.D.4.| >>0080 00 01 00 e3 17 00 02 0a-75 00 73 00 5f 00 65 00 |........ u.s._.e.| >>0090 6e 00 67 00 6c 00 69 00-73 00 68 00 00 ab 6a 00 |n.g.l.i. s.h...j.| >>00a0 47 16 00 00 01 00 27 00-43 00 68 00 61 00 6e 00 |G.....'. C.h.a.n.| >>00b0 67 00 65 00 64 00 20 00-6c 00 61 00 6e 00 67 00 |g.e.d. . l.a.n.g.| >>00c0 75 00 61 00 67 00 65 00-20 00 73 00 65 00 74 00 |u.a.g.e. .s.e.t.| >>00d0 74 00 69 00 6e 00 67 00-20 00 74 00 6f 00 20 00 |t.i.n.g. .t.o. .| >>00e0 75 00 73 00 5f 00 65 00-6e 00 67 00 6c 00 69 00 |u.s._.e. n.g.l.i.| >>00f0 73 00 68 00 2e 00 08 42-00 4f 00 53 00 53 00 51 |s.h....B .O.S.S.Q| >>0100 00 4c 00 44 00 34 00 00-01 00 e3 0f 00 03 05 69 |.L.D.4.. .......i| >>0110 00 73 00 6f 00 5f 00 31-00 01 00 00 e3 0b 00 05 |.s.o._.1 ........| >>0120 04 31 00 30 00 33 00 33-00 00 e3 0f 00 06 06 31 |.1.0.3.3 .......1| >>0130 00 39 00 36 00 36 00 30-00 39 00 00 ad 36 00 01 |.9.6.6.0 .9...6..| >>0140 07 00 00 00 16 4d 00 69-00 63 00 72 00 6f 00 73 |.....M.i .c.r.o.s| >>0150 00 6f 00 66 00 74 00 20-00 53 00 51 00 4c 00 20 |.o.f.t. .S.Q.L. | >>0160 00 53 00 65 00 72 00 76-00 65 00 72 00 00 00 00 |.S.e.r.v .e.r....| >>0170 00 0b 00 0d 6d e3 13 00-04 04 34 00 30 00 39 00 |....m... ..4.0.9.| >>0180 36 00 04 34 00 30 00 39-00 36 00 fd 00 00 00 00 |6..4.0.9 .6......| >>0190 00 00 00 00 - |....| >> >>token.c:335:looking for login token, got e3(ENVCHANGE) >>token.c:115:tds_process_default_tokens() marker is e3(ENVCHANGE) >>token.c:335:looking for login token, got ab(INFO) >>token.c:115:tds_process_default_tokens() marker is ab(INFO) >>token.c:2344:tds_process_msg() reading message 5701 from server >>token.c:2416:tds_process_msg() calling client msg handler >>ctutil.c:142:_ct_handle_server_message(0x7fa6f6874620, 0x7fa6f687a390, >>0x7fff5a6c6680) >>ct.c:350:ct_con_props(0x7fa6f687a2d0, 33, 9108, 0x7fff5a6c5888, 8, 0x0) >>ct.c:352:ct_con_props() action = CS_GET property = 9108 >>ct.c:512:fetching userdata 0x7fa6f6876d90 >>token.c:2429:tds_process_msg() returning TDS_SUCCESS >>token.c:335:looking for login token, got e3(ENVCHANGE) >>token.c:115:tds_process_default_tokens() marker is e3(ENVCHANGE) >>token.c:335:looking for login token, got ab(INFO) >>token.c:115:tds_process_default_tokens() marker is ab(INFO) >>token.c:2344:tds_process_msg() reading message 5703 from server >>token.c:2416:tds_process_msg() calling client msg handler >>ctutil.c:142:_ct_handle_server_message(0x7fa6f6874620, 0x7fa6f687a390, >>0x7fff5a6c6680) >>ct.c:350:ct_con_props(0x7fa6f687a2d0, 33, 9108, 0x7fff5a6c5888, 8, 0x0) >>ct.c:352:ct_con_props() action = CS_GET property = 9108 >>ct.c:512:fetching userdata 0x7fa6f6876d90 >>token.c:2429:tds_process_msg() returning TDS_SUCCESS >>token.c:335:looking for login token, got e3(ENVCHANGE) >>token.c:115:tds_process_default_tokens() marker is e3(ENVCHANGE) >>token.c:2251:server indicated charset change to "iso_1" >>iconv.c:796:setting server single-byte charset to "CP1252" >>token.c:335:looking for login token, got e3(ENVCHANGE) >>token.c:115:tds_process_default_tokens() marker is e3(ENVCHANGE) >>token.c:335:looking for login token, got e3(ENVCHANGE) >>token.c:115:tds_process_default_tokens() marker is e3(ENVCHANGE) >>token.c:335:looking for login token, got ad(LOGINACK) >>token.c:373:server reports TDS version 7.0.0.0 >>token.c:375:Product name for 0x7000000 is 7.0 >>token.c:407:Product version 8B000D6D >>token.c:335:looking for login token, got e3(ENVCHANGE) >>token.c:115:tds_process_default_tokens() marker is e3(ENVCHANGE) >>token.c:2235:changing block size from 4096 to 4096 >>token.c:335:looking for login token, got fd(DONE) >>token.c:115:tds_process_default_tokens() marker is fd(DONE) >>token.c:2080:tds_process_end: more_results = 0 >> was_cancelled = 0 >> error = 0 >> done_count_valid = 0 >>token.c:2097: rows_affected = 0 >>token.c:2100:tds_process_end() state set to TDS_IDLE >>token.c:439:tds_process_login_tokens() returning TDS_SUCCESS >>mem.c:648:tds_free_all_results() >>util.c:165:Changed query state from IDLE to WRITING >>util.c:165:Changed query state from WRITING to PENDING >>packet.c:740:Sending packet >>0000 01 01 00 32 00 00 00 00-73 00 65 00 74 00 20 00 |...2.... s.e.t. .| >>0010 74 00 65 00 78 00 74 00-73 00 69 00 7a 00 65 00 |t.e.x.t. s.i.z.e.| >>0020 20 00 32 00 30 00 30 00-30 00 30 00 30 00 30 00 | .2.0.0. 0.0.0.0.| >>0030 20 00 - | .| >> >>token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c6784, >>0x7fff5a6c6780, 0x100) >>util.c:165:Changed query state from PENDING to READING >>packet.c:639:Received packet >>0000 04 01 00 11 00 6c 01 00-fd 00 00 be 00 00 00 00 |.....l.. ........| >>0010 00 - |.| >> >>token.c:564:processing result tokens. marker is fd(DONE) >>token.c:2080:tds_process_end: more_results = 0 >> was_cancelled = 0 >> error = 0 >> done_count_valid = 0 >>token.c:2097: rows_affected = 0 >>token.c:2100: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 >>token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c6784, >>0x7fff5a6c6780, 0x100) >>token.c:552:tds_process_tokens() state is COMPLETED >>ct.c:656:leaving ct_connect() returning 1 >>ct.c:3383:ct_options(0x7fa6f687a2d0, 34, 5025, 0x7fff5a6c6c44, -99999, >>0x0) >>ct.c:3415:ct_options: CS_SET, option = 5025 >>ct.c:3613: tds_submit_optioncmd will be action(CS_SET) option(25) >>arg(0) >>arglen(1) >>query.c:3411:tds_submit_optioncmd() >>mem.c:648:tds_free_all_results() >>util.c:165:Changed query state from IDLE to WRITING >>util.c:165:Changed query state from WRITING to PENDING >>packet.c:740:Sending packet >>0000 01 01 00 42 00 00 01 00-53 00 45 00 54 00 20 00 |...B.... S.E.T. .| >>0010 49 00 4d 00 50 00 4c 00-49 00 43 00 49 00 54 00 |I.M.P.L. I.C.I.T.| >>0020 5f 00 54 00 52 00 41 00-4e 00 53 00 41 00 43 00 |_.T.R.A. N.S.A.C.| >>0030 54 00 49 00 4f 00 4e 00-53 00 20 00 4f 00 46 00 |T.I.O.N. S. .O.F.| >>0040 46 00 - |F.| >> >>token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c6a74, >>0x7fff5a6c6a70, 0x100) >>util.c:165:Changed query state from PENDING to READING >>packet.c:639:Received packet >>0000 04 01 00 11 00 6c 01 00-fd 00 00 ba 00 00 00 00 |.....l.. ........| >>0010 00 - |.| >> >>token.c:564:processing result tokens. marker is fd(DONE) >>token.c:2080:tds_process_end: more_results = 0 >> was_cancelled = 0 >> error = 0 >> done_count_valid = 0 >>token.c:2097: rows_affected = 0 >>token.c:2100: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 >>token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c6a74, >>0x7fff5a6c6a70, 0x100) >>token.c:552:tds_process_tokens() state is COMPLETED >>ct.c:673:ct_cmd_alloc(0x7fa6f687a2d0, 0x7fff5a6c6ff8) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:223:setting command state to IDLE (from IDLE) >>ct.c:690:ct_cmd_alloc() : allocating command list to head >>ct.c:711:ct_command(0x7fa6f5400040, 148, 0x7fff5a6c71c0, -9, -99999) >>ct.c:850:_ct_initialise_cmd(0x7fa6f5400040) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:223:setting command state to IDLE (from IDLE) >>ct.c:4033:rpc_clear(0x0) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:223:setting command state to IDLE (from IDLE) >>ct.c:235:ct_describe_cmd_state(2) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:223:setting command state to READY (from IDLE) >>ct.c:869:ct_send(0x7fa6f5400040) >>ct.c:871:ct_send() command_type = 148 >>mem.c:648:tds_free_all_results() >>util.c:165:Changed query state from IDLE to WRITING >>util.c:165:Changed query state from WRITING to PENDING >>packet.c:740:Sending packet >>0000 01 01 00 28 00 00 01 00-73 00 65 00 6c 00 65 00 |...(.... s.e.l.e.| >>0010 63 00 74 00 20 00 40 00-40 00 76 00 65 00 72 00 |c.t. . at . @.v.e.r.| >>0020 73 00 69 00 6f 00 6e 00- |s.i.o.n.| >> >>ct.c:235:ct_describe_cmd_state(3) >>ct.c:235:ct_describe_cmd_state(2) >>ct.c:223:setting command state to SENT (from READY) >>ct.c:994:ct_send() succeeded >>ct.c:1132:ct_results(0x7fa6f5400040, 0x7fff5a6c6ff4) >>token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c6f84, >>0x7fff5a6c6f80, 0x6914) >>util.c:165:Changed query state from PENDING to READING >>packet.c:639:Received packet >>0000 04 01 01 bd 00 6c 01 00-81 01 00 00 00 21 00 e7 |.....l.. .....!..| >>0010 58 02 00 d1 9e 01 4d 00-69 00 63 00 72 00 6f 00 |X.....M. i.c.r.o.| >>0020 73 00 6f 00 66 00 74 00-20 00 53 00 51 00 4c 00 |s.o.f.t. .S.Q.L.| >>0030 20 00 53 00 65 00 72 00-76 00 65 00 72 00 20 00 | .S.e.r. v.e.r. .| >>0040 32 00 30 00 31 00 32 00-20 00 28 00 53 00 50 00 |2.0.1.2. .(.S.P.| >>0050 31 00 29 00 20 00 2d 00-20 00 31 00 31 00 2e 00 |1.). .-. .1.1...| >>0060 30 00 2e 00 33 00 34 00-33 00 37 00 2e 00 30 00 |0...3.4. 3.7...0.| >>0070 20 00 28 00 58 00 36 00-34 00 29 00 20 00 0a 00 | .(.X.6. 4.). ...| >>0080 09 00 4d 00 61 00 79 00-20 00 32 00 39 00 20 00 |..M.a.y. .2.9. .| >>0090 32 00 30 00 31 00 34 00-20 00 31 00 36 00 3a 00 |2.0.1.4. .1.6.:.| >>00a0 30 00 33 00 3a 00 34 00-30 00 20 00 0a 00 09 00 |0.3.:.4. 0. .....| >>00b0 43 00 6f 00 70 00 79 00-72 00 69 00 67 00 68 00 |C.o.p.y. r.i.g.h.| >>00c0 74 00 20 00 28 00 63 00-29 00 20 00 4d 00 69 00 |t. .(.c. ). .M.i.| >>00d0 63 00 72 00 6f 00 73 00-6f 00 66 00 74 00 20 00 |c.r.o.s. o.f.t. .| >>00e0 43 00 6f 00 72 00 70 00-6f 00 72 00 61 00 74 00 |C.o.r.p. o.r.a.t.| >>00f0 69 00 6f 00 6e 00 0a 00-09 00 44 00 65 00 76 00 |i.o.n... ..D.e.v.| >>0100 65 00 6c 00 6f 00 70 00-65 00 72 00 20 00 45 00 |e.l.o.p. e.r. .E.| >>0110 64 00 69 00 74 00 69 00-6f 00 6e 00 20 00 28 00 |d.i.t.i. o.n. .(.| >>0120 36 00 34 00 2d 00 62 00-69 00 74 00 29 00 20 00 |6.4.-.b. i.t.). .| >>0130 6f 00 6e 00 20 00 57 00-69 00 6e 00 64 00 6f 00 |o.n. .W. i.n.d.o.| >>0140 77 00 73 00 20 00 4e 00-54 00 20 00 36 00 2e 00 |w.s. .N. T. .6...| >>0150 31 00 20 00 3c 00 58 00-36 00 34 00 3e 00 20 00 |1. .<.X. 6.4.>. .| >>0160 28 00 42 00 75 00 69 00-6c 00 64 00 20 00 37 00 |(.B.u.i. l.d. .7.| >>0170 36 00 30 00 31 00 3a 00-20 00 53 00 65 00 72 00 |6.0.1.:. .S.e.r.| >>0180 76 00 69 00 63 00 65 00-20 00 50 00 61 00 63 00 |v.i.c.e. .P.a.c.| >>0190 6b 00 20 00 31 00 29 00-20 00 28 00 48 00 79 00 |k. .1.). .(.H.y.| >>01a0 70 00 65 00 72 00 76 00-69 00 73 00 6f 00 72 00 |p.e.r.v. i.s.o.r.| >>01b0 29 00 0a 00 fd 10 00 c1-00 01 00 00 00 |)....... .....| >> >>token.c:564:processing result tokens. marker is 81(TDS7_RESULT) >>token.c:1573:processing TDS7 result metadata. >>mem.c:648:tds_free_all_results() >>token.c:1598:set current_results (1 column) to tds->res_info >>token.c:1605:setting up 1 columns >>token.c:3164:adjust_character_column_size: >> Server charset: UCS-2LE >> Server column_size: 600 >> Client charset: UTF-8 >> Client column_size: 1200 >>token.c:1542:tds7_get_data_info: >> colname = >> type = 39 (varchar) >> server's type = 231 (x UCS-2 varchar) >> column_varint_size = 2 >> column_size = 1200 (600 on server) >>token.c:1614: name size/wsize type/wtype utype >>token.c:1615: -------------------- --------------- --------------- ------- >>token.c:1620: 1200/600 39/231 0 >>util.c:165:Changed query state from READING to PENDING >>ct.c:1189:ct_results() process_result_tokens returned 0 (type 4049) >>token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c6f84, >>0x7fff5a6c6f80, 0x6914) >>util.c:165:Changed query state from PENDING to READING >>token.c:564:processing result tokens. marker is d1(ROW) >>token.c:680:tds_process_tokens::SET_RETURN stopping on current token >>util.c:165:Changed query state from READING to PENDING >>ct.c:1189:ct_results() process_result_tokens returned 0 (type 4040) >>ct.c:2283:ct_describe(0x7fa6f5400040, 1, 0x7fff5a6c7000) >>ct.c:1896:_ct_get_client_type(type 39, user 0, size 1200) >>ct.c:2304:ct_describe() datafmt->datatype = 0 server type 39 >>ct.c:1457:ct_bind(0x7fa6f5400040, 1, 0x7fff5a6c7000, 0x7fff5a6c70c0, >>0x7fff5a6c6ff0, 0x7fff5a6c6fee) >>ct.c:1459:ct_bind() datafmt count = 1 column_number = 1 >>ct.c:1518:ct_fetch(0x7fa6f5400040, -99999, -99999, -99999, 0x7fff5a6c6fe8) >>token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c6f7c, 0x0, >>0x1608) >>util.c:165:Changed query state from PENDING to READING >>token.c:564:processing result tokens. marker is d1(ROW) >>token.c:1951:tds_process_row(): reading column 0 >>data.c:534:tds_get_data: type 39, varint size 2 >>data.c:587:tds_get_data(): wire column size is 414 >>util.c:165:Changed query state from READING to PENDING >>ct.c:1583:inside ct_fetch() process_row_tokens returned 0 >>ct.c:1723:_ct_bind_data(0x7fa6f576fd50, 0x7fa6f687adc0, 0x7fa6f687adc0, 0) >>ct.c:1730:_ct_bind_data(): column 0 is type 39 and has length 207 >>ct.c:1896:_ct_get_client_type(type 39, user 0, size 1200) >>cs.c:473:cs_convert(0x7fa6f576fd50, 0x7fff5a6c6e50, 0x7fa6f3a11c00, >>0x7fff5a6c6da0, 0x7fff5a6c70c0, 0x7fff5a6c6ff0) >>ct.c:2007:_ct_get_server_type(0) >>ct.c:2007:_ct_get_server_type(0) >>cs.c:521:converting type 47 (207 bytes) to type = 47 (255 bytes) >>cs.c:535:cs_convert() srctype == desttype >>cs.c:571:cs_convert() desttype = character >>cs.c:53:cs_prretcode(1) >>cs.c:660:cs_convert() returning CS_SUCCEED >>ct.c:1518:ct_fetch(0x7fa6f5400040, -99999, -99999, -99999, 0x7fff5a6c6fe8) >>ct.c:1132:ct_results(0x7fa6f5400040, 0x7fff5a6c6ff4) >>token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c6f84, >>0x7fff5a6c6f80, 0x6914) >>util.c:165:Changed query state from PENDING to READING >>token.c:564:processing result tokens. marker is fd(DONE) >>token.c:2080:tds_process_end: more_results = 0 >> was_cancelled = 0 >> error = 0 >> done_count_valid = 1 >>token.c:2097: rows_affected = 1 >>token.c:2100: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:1189:ct_results() process_result_tokens returned 0 (type 4052) >>ct.c:1295:ct_results() results state = 2 >>ct.c:1296:ct_results() command type = 148 >>ct.c:1297:ct_results() dynamic cmd = 0 >>ct.c:1132:ct_results(0x7fa6f5400040, 0x7fff5a6c6ff4) >>token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c6f84, >>0x7fff5a6c6f80, 0x6914) >>token.c:552:tds_process_tokens() state is COMPLETED >>ct.c:1189:ct_results() process_result_tokens returned 1 (type 4052) >>ct.c:235:ct_describe_cmd_state(2) >>ct.c:235:ct_describe_cmd_state(3) >>ct.c:223:setting command state to READY (from SENT) >>ct.c:1796:ct_cmd_drop(0x7fa6f5400040) >>ct.c:1827:ct_cmd_drop() : command entry found in list >>ct.c:1832:ct_cmd_drop() : relinking list >>ct.c:1839:ct_cmd_drop() : relinked list >>ct.c:673:ct_cmd_alloc(0x7fa6f687a2d0, 0x7fff5a6c6de0) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:223:setting command state to IDLE (from IDLE) >>ct.c:690:ct_cmd_alloc() : allocating command list to head >>ct.c:711:ct_command(0x7fa6f5359360, 148, 0x7fa6f2c01f00, -9, -99999) >>ct.c:850:_ct_initialise_cmd(0x7fa6f5359360) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:223:setting command state to IDLE (from IDLE) >>ct.c:4033:rpc_clear(0x0) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:223:setting command state to IDLE (from IDLE) >>ct.c:235:ct_describe_cmd_state(2) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:223:setting command state to READY (from IDLE) >>ct.c:869:ct_send(0x7fa6f5359360) >>ct.c:871:ct_send() command_type = 148 >>mem.c:648:tds_free_all_results() >>util.c:165:Changed query state from IDLE to WRITING >>util.c:165:Changed query state from WRITING to PENDING >>packet.c:740:Sending packet >>0000 01 01 00 18 00 00 01 00-75 00 73 00 65 00 20 00 |........ u.s.e. .| >>0010 6f 00 74 00 6f 00 33 00- |o.t.o.3.| >> >>ct.c:235:ct_describe_cmd_state(3) >>ct.c:235:ct_describe_cmd_state(2) >>ct.c:223:setting command state to SENT (from READY) >>ct.c:994:ct_send() succeeded >>ct.c:1132:ct_results(0x7fa6f5359360, 0x7fff5a6c66d0) >>token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c65f4, >>0x7fff5a6c65f0, 0x6914) >>util.c:165:Changed query state from PENDING to READING >>packet.c:639:Received packet >>0000 04 01 00 8a 00 6c 01 00-e3 11 00 01 04 4f 00 54 |.....l.. .....O.T| >>0010 00 4f 00 33 00 03 4f 00-54 00 4f 00 ab 62 00 45 |.O.3..O. T.O..b.E| >>0020 16 00 00 01 00 23 00 43-00 68 00 61 00 6e 00 67 |.....#.C .h.a.n.g| >>0030 00 65 00 64 00 20 00 64-00 61 00 74 00 61 00 62 |.e.d. .d .a.t.a.b| >>0040 00 61 00 73 00 65 00 20-00 63 00 6f 00 6e 00 74 |.a.s.e. .c.o.n.t| >>0050 00 65 00 78 00 74 00 20-00 74 00 6f 00 20 00 27 |.e.x.t. .t.o. .'| >>0060 00 4f 00 54 00 4f 00 33-00 27 00 2e 00 08 42 00 |.O.T.O.3 .'....B.| >>0070 4f 00 53 00 53 00 51 00-4c 00 44 00 34 00 00 01 |O.S.S.Q. L.D.4...| >>0080 00 fd 00 00 e2 00 00 00-00 00 |........ ..| >> >>token.c:564:processing result tokens. marker is e3(ENVCHANGE) >>token.c:115:tds_process_default_tokens() marker is e3(ENVCHANGE) >>token.c:564:processing result tokens. marker is ab(INFO) >>token.c:115:tds_process_default_tokens() marker is ab(INFO) >>token.c:2344:tds_process_msg() reading message 5701 from server >>token.c:2416:tds_process_msg() calling client msg handler >>ctutil.c:142:_ct_handle_server_message(0x7fa6f6874620, 0x7fa6f687a390, >>0x7fff5a6c6420) >>ct.c:350:ct_con_props(0x7fa6f687a2d0, 33, 9108, 0x7fff5a6c5628, 8, 0x0) >>ct.c:352:ct_con_props() action = CS_GET property = 9108 >>ct.c:512:fetching userdata 0x7fa6f6876d90 >>token.c:2429:tds_process_msg() returning TDS_SUCCESS >>token.c:564:processing result tokens. marker is fd(DONE) >>token.c:2080:tds_process_end: more_results = 0 >> was_cancelled = 0 >> error = 0 >> done_count_valid = 0 >>token.c:2097: rows_affected = 0 >>token.c:2100: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:1189:ct_results() process_result_tokens returned 0 (type 4052) >>ct.c:1295:ct_results() results state = 0 >>ct.c:1296:ct_results() command type = 148 >>ct.c:1297:ct_results() dynamic cmd = 0 >>ct.c:2347:ct_res_info(0x7fa6f5359360, 800, 0x7fa6f2c67598, -99999, 0x0) >>ct.c:2372:ct_res_info(): Number of rows is -1 >>ct.c:1132:ct_results(0x7fa6f5359360, 0x7fff5a6c66d0) >>ct.c:2347:ct_res_info(0x7fa6f5359360, 800, 0x7fa6f2c67598, -99999, 0x0) >>ct.c:2372:ct_res_info(): Number of rows is -1 >>ct.c:1132:ct_results(0x7fa6f5359360, 0x7fff5a6c66d0) >>token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c65f4, >>0x7fff5a6c65f0, 0x6914) >>token.c:552:tds_process_tokens() state is COMPLETED >>ct.c:1189:ct_results() process_result_tokens returned 1 (type 4052) >>ct.c:235:ct_describe_cmd_state(2) >>ct.c:235:ct_describe_cmd_state(3) >>ct.c:223:setting command state to READY (from SENT) >>ct.c:1796:ct_cmd_drop(0x7fa6f5359360) >>ct.c:1827:ct_cmd_drop() : command entry found in list >>ct.c:1832:ct_cmd_drop() : relinking list >>ct.c:1839:ct_cmd_drop() : relinked list >>ct.c:673:ct_cmd_alloc(0x7fa6f687a2d0, 0x7fff5a6c6de0) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:223:setting command state to IDLE (from IDLE) >>ct.c:690:ct_cmd_alloc() : allocating command list to head >>ct.c:711:ct_command(0x7fa6f5145ea0, 148, 0x1056b8000, -9, -99999) >>ct.c:850:_ct_initialise_cmd(0x7fa6f5145ea0) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:223:setting command state to IDLE (from IDLE) >>ct.c:4033:rpc_clear(0x0) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:223:setting command state to IDLE (from IDLE) >>ct.c:235:ct_describe_cmd_state(2) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:223:setting command state to READY (from IDLE) >>ct.c:869:ct_send(0x7fa6f5145ea0) >>ct.c:871:ct_send() command_type = 148 >>mem.c:648:tds_free_all_results() >>util.c:165:Changed query state from IDLE to WRITING >>packet.c:740:Sending packet >>0000 01 00 10 00 00 00 01 00-49 00 4e 00 53 00 45 00 |........ I.N.S.E.| >>0010 52 00 54 00 20 00 69 00-6e 00 74 00 6f 00 20 00 |R.T. .i. n.t.o. .| >>0020 54 00 45 00 53 00 54 00-54 00 41 00 42 00 4c 00 |T.E.S.T. T.A.B.L.| >>0030 45 00 20 00 28 00 6d 00-61 00 78 00 74 00 65 00 |E. .(.m. a.x.t.e.| >>0040 78 00 74 00 29 00 20 00-76 00 61 00 6c 00 75 00 |x.t.). . v.a.l.u.| >>0050 65 00 73 00 20 00 28 00-4e 00 27 00 78 00 78 00 |e.s. .(. N.'.x.x.| >> >>stream.c:125:Error: tds_convert_stream: tds_iconv returned errno 7, >>conv_errno 7 >>packet.c:740:Sending packet >>0000 01 00 10 00 00 00 01 00-78 00 78 00 78 00 78 00 |........ x.x.x.x.| >> >>packet.c:740:Sending packet >>0000 01 00 10 00 00 00 01 00-78 00 78 00 78 00 78 00 |........ x.x.x.x.| >> >>stream.c:125:Error: tds_convert_stream: tds_iconv returned errno 7, >>conv_errno 7 >>packet.c:740:Sending packet >>0000 01 00 10 00 00 00 01 00-78 00 78 00 78 00 78 00 |........ x.x.x.x.| >> >>stream.c:125:Error: tds_convert_stream: tds_iconv returned errno 7, >>conv_errno 7 >>util.c:165:Changed query state from WRITING to PENDING >>packet.c:740:Sending packet >>0000 01 01 0f 20 00 00 01 00-78 00 78 00 78 00 78 00 |... .... x.x.x.x.| >>0f10 78 00 78 00 78 00 78 00-78 00 78 00 27 00 29 00 |x.x.x.x. x.x.'.).| >> >>ct.c:235:ct_describe_cmd_state(3) >>ct.c:235:ct_describe_cmd_state(2) >>ct.c:223:setting command state to SENT (from READY) >>ct.c:994:ct_send() succeeded >>ct.c:1132:ct_results(0x7fa6f5145ea0, 0x7fff5a6c66d0) >>token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c65f4, >>0x7fff5a6c65f0, 0x6914) >>util.c:165:Changed query state from PENDING to READING >>packet.c:639:Received packet >>0000 04 01 00 11 00 6c 01 00-fd 10 00 c3 00 01 00 00 |.....l.. ........| >>0010 00 - |.| >> >>token.c:564:processing result tokens. marker is fd(DONE) >>token.c:2080:tds_process_end: more_results = 0 >> was_cancelled = 0 >> error = 0 >> done_count_valid = 1 >>token.c:2097: rows_affected = 1 >>token.c:2100: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:1189:ct_results() process_result_tokens returned 0 (type 4052) >>ct.c:1295:ct_results() results state = 0 >>ct.c:1296:ct_results() command type = 148 >>ct.c:1297:ct_results() dynamic cmd = 0 >>ct.c:2347:ct_res_info(0x7fa6f5145ea0, 800, 0x7fa6f687a908, -99999, 0x0) >>ct.c:2372:ct_res_info(): Number of rows is 1 >>ct.c:1132:ct_results(0x7fa6f5145ea0, 0x7fff5a6c66d0) >>ct.c:2347:ct_res_info(0x7fa6f5145ea0, 800, 0x7fa6f687a908, -99999, 0x0) >>ct.c:2372:ct_res_info(): Number of rows is 1 >>ct.c:1132:ct_results(0x7fa6f5145ea0, 0x7fff5a6c66d0) >>token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c65f4, >>0x7fff5a6c65f0, 0x6914) >>token.c:552:tds_process_tokens() state is COMPLETED >>ct.c:1189:ct_results() process_result_tokens returned 1 (type 4052) >>ct.c:235:ct_describe_cmd_state(2) >>ct.c:235:ct_describe_cmd_state(3) >>ct.c:223:setting command state to READY (from SENT) >>ct.c:1796:ct_cmd_drop(0x7fa6f5145ea0) >>ct.c:1827:ct_cmd_drop() : command entry found in list >>ct.c:1832:ct_cmd_drop() : relinking list >>ct.c:1839:ct_cmd_drop() : relinked list >> >> >> >> >> >> >>On 10/7/15, 11:37 AM, "Frediano Ziglio" wrote: >> >>>I won't be surprised if there are also some limit in sql server. >>> >>>You are sending the data inside a language query string. It's quite >>>surprising changing log settings solve the issue, perhaps there is a >>>bug inside Ctlib (DBD::Sybase should use ctlib). You can try using a >>>packet sniffer to get traffic with the server. Can you post (or send >>>to me if you prefer) the logs anyway? >>>Probably you'd better compress them. From the log we can understand >>>which calls DBD::Sybase does so I can try reproduce with C directly. >>> >>>Frediano >>> >>> >>>2015-10-06 1:36 GMT+01:00 Jacopille, David : >>>> DC - Thanks for the quick reply. Text size is positively set to one >>>>million characters. >>>> >>>> 1. The data SELECT of 500,000 characters always works. >>>> 2. SELECT @@textsize does confirm the 1,000,000 setting (but the above >>>>also proves functionality) >>>> 3. 'Text size' setting only applies to SELECT statements, not INSERT >>>>where we are having the issue. This is demonstrably true for MS SQL >>>>Server, which we are using. Don't know about other databases. >>>> >>>> SQL Server 2012 nvarchar(max) does hold 2 GB theoretical. This >>>>specific table and nvarchar(max) column has proven to handle far more >>>>than the 1 MB values I'm testing with. At least through other >>>>software. >>>> >>>> I suspect that there is a bug in either FreeTDS 0.95 or DBD::Sybase >>>>1.15 that is limiting the text. However I find FreeTDS more suspicious >>>>because turning on logging (which changes something in FreeTDS) fixes >>>>the problem. >>>> >>>> Unfortunately the thing that would be useful to find the problem is >>>>what fixes the problem. >>>> >>>> Dave >>>> >>>> -----Original Message----- >>>> From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of >>>>David Chang >>>> Sent: Monday, October 05, 2015 6:54 PM >>>> To: FreeTDS Development Group >>>> Subject: Re: [freetds] Using FreeTDS 0.95 INSERTS fail above 66000 >>>>characters...unless 'dump file' is turned on >>>> >>>> Dave, >>>> >>>> I see you set the text size in the freetds.conf file to 1000000. I >>>>would confirm it using 'select @@textsize'. >>>> >>>> DC >>>> >>>> On 10/5/2015 2:07 PM, Jacopille, David wrote: >>>>> Looking for suggestions or a troubleshooting approach on this 100% >>>>> reproducible issue where FreeTDS logging seems to be the only >>>>>variable. >>>>> >>>>> Since the issue goes away as soon as I turn on freetds logging I can?t >>>>> look at the logs to find the problem. >>>>> >>>>> ENVIRONMENT >>>>> SQL Server 2012 >>>>> OS X 10.9.5 >>>>> FreeTDS 0.95.20 >>>>> DBD::Sybase 1.15 >>>>> TDSVER 7.0 or 7.1 (same symptoms) >>>>> Perl 5.16.3 >>>>> FreeTDS text size = 1000000 >>>>> >>>>> Testing large string INSERTS to a table with a single, nvarchar(max), >>>>> column >>>>> >>>>> >>>>> WHAT WORKS >>>>> A. With freetds logging on (via 'dump file = /tmp/freetds.log?) INSERT >>>>> values from 0-500,000 characters are successful. Decreasing >>>>> reliability above 500,000 characters. >>>>> >>>>> B. INSERT statements with values of 0 thru 66,000 characters always >>>>> work, regardless of freetds logging on/off >>>>> >>>>> C. SELECT work correctly for all values 0 thru one million characters, >>>>> regardless of freetds logging on/off >>>>> >>>>> >>>>> DOES NOT WORK >>>>> If freetds logging is turned off the following fails consistently: >>>>> >>>>> A. 67,000 character INSERT stalls at INSERT >>>>> >>>>> B. 100,000+ character INSERT doesn?t stall but doesn?t >>>>>INSERT >>>>> >>>>> C. Stored Procedures also experiencing failures in same character >>>>> ranges >>>>> >>>>> >>>>> FREETDS.CONF >>>>> >>>>> # In the failure configuration it looks like this. >>>>> # The ?DOES NOT WORK? symptoms go away if the last two lines are >>>>> uncommented. >>>>> >>>>> [global] >>>>> client charset = UTF-8 >>>>> text size = 1000000 >>>>> >>>>> [bossqld4] >>>>> host = bossqld4.mfs.com >>>>> port = 1433 >>>>> tds version = 7.0 >>>>> #dump file = /tmp/freetds.log >>>>> #dump file append = no >>>>> >>>>> >>>>> PERL SCRIPT REPRODUCING ISSUE (WITH NO FREETDS LOGGING) >>>>> >>>>> use DBI qw(:sql_types); >>>>> use DBD::Sybase; >>>>> my ($sql, $dbh, $ref, $largetext); >>>>> >>>>> $dbh = DBI->connect( 'DBI:Sybase:server=bossqld4', ?CORP\user', >>>>> ?password', { PrintError => 0 } ) or die; $dbh->do('use >>>>> testdatabase'); >>>>> >>>>> $largetext = 'x' x 100000; # one hundred thousand characters >>>>> >>>>> $dbh->do(qq|INSERT into TESTTABLE (maxtext) values >>>>> (N\'$largetext\')|); >>>>> >>>>> # SELECT not affected by FreeTDS logging on/off # SELECT always >>>>> successful on all values tested up to one million characters (and >>>>> probably much larger, but untested). >>>>> >>>>> $sql = q|SELECT TOP 1 [maxtext] FROM TESTTABLE|; $ref = >>>>> $dbh->selectrow_arrayref($sql); print 'Length of value: '. (length >>>>> $$ref[0]) ."\n"; >>>>> >>>>> $dbh->disconnect(); >>>>> >>>>> >>>>> Thank you, >>>>> Dave Jacopille >>>>> Boston >>>>> >>>>> MFS Email system made the following annotation >>>>> ---------------------------------------------------------------------- >>>>> ----------------------------------------------------------------- >>>>> This email communication and any attachments may contain proprietary, >>>>>confidential, or privileged information. If you are not the intended >>>>>recipient, you are hereby notified that you have received this email in >>>>>error and that any review, disclosure, dissemination, distribution or >>>>>copying of it or its contents is prohibited. The sender does not waive >>>>>confidentiality or any privilege by mistransmission. If you have >>>>>received this email in error, please notify the sender immediately, >>>>>delete this email, and destroy all copies and any attachments. >>>>> _______________________________________________ >>>>> FreeTDS mailing list >>>>> FreeTDS at lists.ibiblio.org >>>>> http://lists.ibiblio.org/mailman/listinfo/freetds >>>> >>>> _______________________________________________ >>>> FreeTDS mailing list >>>> FreeTDS at lists.ibiblio.org >>>> http://lists.ibiblio.org/mailman/listinfo/freetds >>>> MFS Email system made the following annotation >>>> >>>>------------------------------------------------------------------------ >>>>- >>>>-------------------------------------------------------------- >>>> This email communication and any attachments may contain proprietary, >>>>confidential, or privileged information. If you are not the intended >>>>recipient, you are hereby notified that you have received this email in >>>>error and that any review, disclosure, dissemination, distribution or >>>>copying of it or its contents is prohibited. The sender does not waive >>>>confidentiality or any privilege by mistransmission. If you have >>>>received this email in error, please notify the sender immediately, >>>>delete this email, and destroy all copies and any attachments. >>>> _______________________________________________ >>>> FreeTDS mailing list >>>> FreeTDS at lists.ibiblio.org >>>> http://lists.ibiblio.org/mailman/listinfo/freetds >>>_______________________________________________ >>>FreeTDS mailing list >>>FreeTDS at lists.ibiblio.org >>>http://lists.ibiblio.org/mailman/listinfo/freetds >> >>MFS Email system made the following annotation >>-------------------------------------------------------------------------- >>------------------------------------------------------------- >>This email communication and any attachments may contain proprietary, >>confidential, or privileged information. If you are not the intended >>recipient, you are hereby notified that you have received this email in >>error and that any review, disclosure, dissemination, distribution or >>copying of it or its contents is prohibited. The sender does not waive >>confidentiality or any privilege by mistransmission. If you have received >>this email in error, please notify the sender immediately, delete this >>email, and destroy all copies and any attachments. >>_______________________________________________ >>FreeTDS mailing list >>FreeTDS at lists.ibiblio.org >>http://lists.ibiblio.org/mailman/listinfo/freetds > > MFS Email system made the following annotation > --------------------------------------------------------------------------------------------------------------------------------------- > This email communication and any attachments may contain proprietary, confidential, or privileged information. If you are not the intended recipient, you are hereby notified that you have received this email in error and that any review, disclosure, dissemination, distribution or copying of it or its contents is prohibited. The sender does not waive confidentiality or any privilege by mistransmission. If you have received this email in error, please notify the sender immediately, delete this email, and destroy all copies and any attachments. > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From belinda.garrett at gmail.com Mon Oct 12 08:15:44 2015 From: belinda.garrett at gmail.com (Belinda Garrett) Date: Mon, 12 Oct 2015 22:45:44 +1030 Subject: [freetds] FreeTDS support of Availability Groups Message-ID: Hello, Reading a previous post ( http://lists.ibiblio.org/pipermail/freetds/2015q1/029244.html) and assuming this is still the case (FreeTDS does not currently support availability groups (AlwaysOn)), are there any plans to add support for this in the near future? Thanks in advance, Belinda From DJacopille at MFS.com Mon Oct 12 12:23:07 2015 From: DJacopille at MFS.com (Jacopille, David) Date: Mon, 12 Oct 2015 16:23:07 +0000 Subject: [freetds] Using FreeTDS 0.95 INSERTS fail above 66000 characters...unless 'dump file' is turned on In-Reply-To: References: <5612FF8F.3080800@fsautomation.com> , Message-ID: I can confirm that greeted 0.95.21 resolves the issue with inserts above 66000 characters failing without dump on OS X. A big thank you to Frediano! Dave Jacopille Boston ________________________________ From: FreeTDS on behalf of Frediano Ziglio Sent: Saturday, October 10, 2015 11:58:07 AM To: FreeTDS Development Group Subject: Re: [freetds] Using FreeTDS 0.95 INSERTS fail above 66000 characters...unless 'dump file' is turned on Fixed in Git. You can get a new minor version at the website. Was more complicated than expected. Looks like Linux is quite different from Mac OS X but anyway was documented in the man page. On some condition some partial write can occurs which make client loose sync with the server. Frediano 2015-10-09 21:29 GMT+01:00 Jacopille, David : > FreeTDS group: > > This issue, which is 100% reproducible in 0.95.20, does not occur at all > in 0.91. > > Insert and select values of 500,000 using FreeTDS 0.91 set to TDSVER=7.1 > worked correctly 20 times in a row. > > I verified the insert as a new record after each run the script. > > Could this just be a bug in the 0.95.20 build? > > Thanks, > Dave > > On 10/7/15, 1:13 PM, "Jacopille, David" wrote: > >>Frediano, >> >>Below is the freetds.log that contains results from these three lines >>from the test script. The INSERT was successful since >>logging/debugging was turned on. It would not have been if logging was >>turned off. >> >>DBI->connect >>USE >>INSERT (string of 100000 ?x? characters) >> >>The logs recorded a lot of repetitive lines on INSERT of 100000 >>?x? characters. >> >>To save space I removed the repetitive lines with nothing but x >>characters, like this example: >> >>.... 00 78 00 78 00 78 00 78-00 78 00 78 00 78 00 78 |.x.x.x.x .x.x.x.x| >> >>I also removed some of the repetitive packet retries for the long insert. >> >>Everything else, including that beginning of the INSERT should be there. >> >>Thank you for looking into this. >> >>Dave >> >>log.c:167:Starting log file for FreeTDS 0.95.20 >> on 2015-10-07 13:06:36 with debug flags 0x4fff. >>iconv.c:328:tds_iconv_open(0x7fa6f687a390, 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 168.66.122.143 port 1433 (TDS version 7.0) >>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 >>login.c:788:using NTLM authentication for 'CORP\jacopille_d' account >>login.c:852:quietly sending TDS 7+ login packet >>token.c:326:tds_process_login_tokens() >>packet.c:639:Received packet >>0000 04 01 00 e3 00 00 00 00-ed d8 00 4e 54 4c 4d 53 |........ ...NTLMS| >>0010 53 50 00 02 00 00 00 08-00 08 00 38 00 00 00 05 |SP...... ...8....| >>0020 82 89 02 f5 e6 ef 6b 26-25 0a 98 00 00 00 00 00 |......k& %.......| >>0030 00 00 00 98 00 98 00 40-00 00 00 06 01 b1 1d 00 |.......@ ........| >>0040 00 00 0f 43 00 4f 00 52-00 50 00 02 00 08 00 43 |...C.O.R .P.....C| >>0050 00 4f 00 52 00 50 00 01-00 10 00 42 00 4f 00 53 |.O.R.P.. ...B.O.S| >>0060 00 53 00 51 00 4c 00 44-00 34 00 04 00 18 00 63 |.S.Q.L.D .4.....c| >>0070 00 6f 00 72 00 70 00 2e-00 6d 00 66 00 73 00 2e |.o.r.p.. .m.f.s..| >>0080 00 63 00 6f 00 6d 00 03-00 2a 00 62 00 6f 00 73 |.c.o.m.. .*.b.o.s| >>0090 00 73 00 71 00 6c 00 64-00 34 00 2e 00 63 00 6f |.s.q.l.d .4...c.o| >>00a0 00 72 00 70 00 2e 00 6d-00 66 00 73 00 2e 00 63 |.r.p...m .f.s...c| >>00b0 00 6f 00 6d 00 05 00 1a-00 77 00 69 00 6e 00 72 |.o.m.... .w.i.n.r| >>00c0 00 6f 00 6f 00 74 00 2e-00 6c 00 6f 00 63 00 61 |.o.o.t.. .l.o.c.a| >>00d0 00 6c 00 07 00 08 00 4e-2f 6c 86 22 01 d1 01 00 |.l.....N /l."....| >>00e0 00 00 00 - |...| >> >>token.c:335:looking for login token, got ed(AUTH) >>token.c:115:tds_process_default_tokens() marker is ed(AUTH) >>token.c:463:TDS_AUTH_TOKEN PDU size 216 >>challenge.c:648:TDS_AUTH_TOKEN nonce >>0000 f5 e6 ef 6b 26 25 0a 98- |...k&%..| >> >>challenge.c:702:Draining 0 bytes >>packet.c:740:Sending packet >>0000 11 01 00 b6 00 00 00 00-4e 54 4c 4d 53 53 50 00 |........ NTLMSSP.| >>0010 03 00 00 00 18 00 18 00-7e 00 00 00 18 00 18 00 |........ ~.......| >>0020 96 00 00 00 08 00 08 00-40 00 00 00 16 00 16 00 |........ @.......| >>0030 48 00 00 00 20 00 20 00-5e 00 00 00 00 00 00 00 |H... . . ^.......| >>0040 ae 00 00 00 01 82 00 00-43 00 4f 00 52 00 50 00 |........ C.O.R.P.| >>0050 6a 00 61 00 63 00 6f 00-70 00 69 00 6c 00 6c 00 |j.a.c.o. p.i.l.l.| >>0060 65 00 5f 00 64 00 30 00-30 00 36 00 2d 00 65 00 |e._.d.0. 0.6.-.e.| >>0070 37 00 32 00 37 00 2e 00-6d 00 66 00 73 00 2e 00 |7.2.7... m.f.s...| >>0080 63 00 6f 00 6d 00 ad ef-62 84 d4 08 0d 87 00 00 |c.o.m... b.......| >>0090 00 00 00 00 00 00 00 00-00 00 00 00 00 00 df c8 |........ ........| >>00a0 2e 96 a9 95 b8 b6 2e f2-7e 0b 80 23 14 d2 e6 c8 |........ ~..#....| >>00b0 90 e7 6a 64 47 2b - |..jdG+| >> >>packet.c:639:Received packet >>0000 04 01 01 94 00 6c 01 00-e3 15 00 01 03 4f 00 74 |.....l.. .....O.t| >>0010 00 6f 00 06 6d 00 61 00-73 00 74 00 65 00 72 00 |.o..m.a. s.t.e.r.| >>0020 ab 60 00 45 16 00 00 02-00 22 00 43 00 68 00 61 |.`.E.... .".C.h.a| >>0030 00 6e 00 67 00 65 00 64-00 20 00 64 00 61 00 74 |.n.g.e.d . .d.a.t| >>0040 00 61 00 62 00 61 00 73-00 65 00 20 00 63 00 6f |.a.b.a.s .e. .c.o| >>0050 00 6e 00 74 00 65 00 78-00 74 00 20 00 74 00 6f |.n.t.e.x .t. .t.o| >>0060 00 20 00 27 00 4f 00 74-00 6f 00 27 00 2e 00 08 |. .'.O.t .o.'....| >>0070 42 00 4f 00 53 00 53 00-51 00 4c 00 44 00 34 00 |B.O.S.S. Q.L.D.4.| >>0080 00 01 00 e3 17 00 02 0a-75 00 73 00 5f 00 65 00 |........ u.s._.e.| >>0090 6e 00 67 00 6c 00 69 00-73 00 68 00 00 ab 6a 00 |n.g.l.i. s.h...j.| >>00a0 47 16 00 00 01 00 27 00-43 00 68 00 61 00 6e 00 |G.....'. C.h.a.n.| >>00b0 67 00 65 00 64 00 20 00-6c 00 61 00 6e 00 67 00 |g.e.d. . l.a.n.g.| >>00c0 75 00 61 00 67 00 65 00-20 00 73 00 65 00 74 00 |u.a.g.e. .s.e.t.| >>00d0 74 00 69 00 6e 00 67 00-20 00 74 00 6f 00 20 00 |t.i.n.g. .t.o. .| >>00e0 75 00 73 00 5f 00 65 00-6e 00 67 00 6c 00 69 00 |u.s._.e. n.g.l.i.| >>00f0 73 00 68 00 2e 00 08 42-00 4f 00 53 00 53 00 51 |s.h....B .O.S.S.Q| >>0100 00 4c 00 44 00 34 00 00-01 00 e3 0f 00 03 05 69 |.L.D.4.. .......i| >>0110 00 73 00 6f 00 5f 00 31-00 01 00 00 e3 0b 00 05 |.s.o._.1 ........| >>0120 04 31 00 30 00 33 00 33-00 00 e3 0f 00 06 06 31 |.1.0.3.3 .......1| >>0130 00 39 00 36 00 36 00 30-00 39 00 00 ad 36 00 01 |.9.6.6.0 .9...6..| >>0140 07 00 00 00 16 4d 00 69-00 63 00 72 00 6f 00 73 |.....M.i .c.r.o.s| >>0150 00 6f 00 66 00 74 00 20-00 53 00 51 00 4c 00 20 |.o.f.t. .S.Q.L. | >>0160 00 53 00 65 00 72 00 76-00 65 00 72 00 00 00 00 |.S.e.r.v .e.r....| >>0170 00 0b 00 0d 6d e3 13 00-04 04 34 00 30 00 39 00 |....m... ..4.0.9.| >>0180 36 00 04 34 00 30 00 39-00 36 00 fd 00 00 00 00 |6..4.0.9 .6......| >>0190 00 00 00 00 - |....| >> >>token.c:335:looking for login token, got e3(ENVCHANGE) >>token.c:115:tds_process_default_tokens() marker is e3(ENVCHANGE) >>token.c:335:looking for login token, got ab(INFO) >>token.c:115:tds_process_default_tokens() marker is ab(INFO) >>token.c:2344:tds_process_msg() reading message 5701 from server >>token.c:2416:tds_process_msg() calling client msg handler >>ctutil.c:142:_ct_handle_server_message(0x7fa6f6874620, 0x7fa6f687a390, >>0x7fff5a6c6680) >>ct.c:350:ct_con_props(0x7fa6f687a2d0, 33, 9108, 0x7fff5a6c5888, 8, 0x0) >>ct.c:352:ct_con_props() action = CS_GET property = 9108 >>ct.c:512:fetching userdata 0x7fa6f6876d90 >>token.c:2429:tds_process_msg() returning TDS_SUCCESS >>token.c:335:looking for login token, got e3(ENVCHANGE) >>token.c:115:tds_process_default_tokens() marker is e3(ENVCHANGE) >>token.c:335:looking for login token, got ab(INFO) >>token.c:115:tds_process_default_tokens() marker is ab(INFO) >>token.c:2344:tds_process_msg() reading message 5703 from server >>token.c:2416:tds_process_msg() calling client msg handler >>ctutil.c:142:_ct_handle_server_message(0x7fa6f6874620, 0x7fa6f687a390, >>0x7fff5a6c6680) >>ct.c:350:ct_con_props(0x7fa6f687a2d0, 33, 9108, 0x7fff5a6c5888, 8, 0x0) >>ct.c:352:ct_con_props() action = CS_GET property = 9108 >>ct.c:512:fetching userdata 0x7fa6f6876d90 >>token.c:2429:tds_process_msg() returning TDS_SUCCESS >>token.c:335:looking for login token, got e3(ENVCHANGE) >>token.c:115:tds_process_default_tokens() marker is e3(ENVCHANGE) >>token.c:2251:server indicated charset change to "iso_1" >>iconv.c:796:setting server single-byte charset to "CP1252" >>token.c:335:looking for login token, got e3(ENVCHANGE) >>token.c:115:tds_process_default_tokens() marker is e3(ENVCHANGE) >>token.c:335:looking for login token, got e3(ENVCHANGE) >>token.c:115:tds_process_default_tokens() marker is e3(ENVCHANGE) >>token.c:335:looking for login token, got ad(LOGINACK) >>token.c:373:server reports TDS version 7.0.0.0 >>token.c:375:Product name for 0x7000000 is 7.0 >>token.c:407:Product version 8B000D6D >>token.c:335:looking for login token, got e3(ENVCHANGE) >>token.c:115:tds_process_default_tokens() marker is e3(ENVCHANGE) >>token.c:2235:changing block size from 4096 to 4096 >>token.c:335:looking for login token, got fd(DONE) >>token.c:115:tds_process_default_tokens() marker is fd(DONE) >>token.c:2080:tds_process_end: more_results = 0 >> was_cancelled = 0 >> error = 0 >> done_count_valid = 0 >>token.c:2097: rows_affected = 0 >>token.c:2100:tds_process_end() state set to TDS_IDLE >>token.c:439:tds_process_login_tokens() returning TDS_SUCCESS >>mem.c:648:tds_free_all_results() >>util.c:165:Changed query state from IDLE to WRITING >>util.c:165:Changed query state from WRITING to PENDING >>packet.c:740:Sending packet >>0000 01 01 00 32 00 00 00 00-73 00 65 00 74 00 20 00 |...2.... s.e.t. .| >>0010 74 00 65 00 78 00 74 00-73 00 69 00 7a 00 65 00 |t.e.x.t. s.i.z.e.| >>0020 20 00 32 00 30 00 30 00-30 00 30 00 30 00 30 00 | .2.0.0. 0.0.0.0.| >>0030 20 00 - | .| >> >>token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c6784, >>0x7fff5a6c6780, 0x100) >>util.c:165:Changed query state from PENDING to READING >>packet.c:639:Received packet >>0000 04 01 00 11 00 6c 01 00-fd 00 00 be 00 00 00 00 |.....l.. ........| >>0010 00 - |.| >> >>token.c:564:processing result tokens. marker is fd(DONE) >>token.c:2080:tds_process_end: more_results = 0 >> was_cancelled = 0 >> error = 0 >> done_count_valid = 0 >>token.c:2097: rows_affected = 0 >>token.c:2100: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 >>token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c6784, >>0x7fff5a6c6780, 0x100) >>token.c:552:tds_process_tokens() state is COMPLETED >>ct.c:656:leaving ct_connect() returning 1 >>ct.c:3383:ct_options(0x7fa6f687a2d0, 34, 5025, 0x7fff5a6c6c44, -99999, >>0x0) >>ct.c:3415:ct_options: CS_SET, option = 5025 >>ct.c:3613: tds_submit_optioncmd will be action(CS_SET) option(25) >>arg(0) >>arglen(1) >>query.c:3411:tds_submit_optioncmd() >>mem.c:648:tds_free_all_results() >>util.c:165:Changed query state from IDLE to WRITING >>util.c:165:Changed query state from WRITING to PENDING >>packet.c:740:Sending packet >>0000 01 01 00 42 00 00 01 00-53 00 45 00 54 00 20 00 |...B.... S.E.T. .| >>0010 49 00 4d 00 50 00 4c 00-49 00 43 00 49 00 54 00 |I.M.P.L. I.C.I.T.| >>0020 5f 00 54 00 52 00 41 00-4e 00 53 00 41 00 43 00 |_.T.R.A. N.S.A.C.| >>0030 54 00 49 00 4f 00 4e 00-53 00 20 00 4f 00 46 00 |T.I.O.N. S. .O.F.| >>0040 46 00 - |F.| >> >>token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c6a74, >>0x7fff5a6c6a70, 0x100) >>util.c:165:Changed query state from PENDING to READING >>packet.c:639:Received packet >>0000 04 01 00 11 00 6c 01 00-fd 00 00 ba 00 00 00 00 |.....l.. ........| >>0010 00 - |.| >> >>token.c:564:processing result tokens. marker is fd(DONE) >>token.c:2080:tds_process_end: more_results = 0 >> was_cancelled = 0 >> error = 0 >> done_count_valid = 0 >>token.c:2097: rows_affected = 0 >>token.c:2100: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 >>token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c6a74, >>0x7fff5a6c6a70, 0x100) >>token.c:552:tds_process_tokens() state is COMPLETED >>ct.c:673:ct_cmd_alloc(0x7fa6f687a2d0, 0x7fff5a6c6ff8) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:223:setting command state to IDLE (from IDLE) >>ct.c:690:ct_cmd_alloc() : allocating command list to head >>ct.c:711:ct_command(0x7fa6f5400040, 148, 0x7fff5a6c71c0, -9, -99999) >>ct.c:850:_ct_initialise_cmd(0x7fa6f5400040) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:223:setting command state to IDLE (from IDLE) >>ct.c:4033:rpc_clear(0x0) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:223:setting command state to IDLE (from IDLE) >>ct.c:235:ct_describe_cmd_state(2) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:223:setting command state to READY (from IDLE) >>ct.c:869:ct_send(0x7fa6f5400040) >>ct.c:871:ct_send() command_type = 148 >>mem.c:648:tds_free_all_results() >>util.c:165:Changed query state from IDLE to WRITING >>util.c:165:Changed query state from WRITING to PENDING >>packet.c:740:Sending packet >>0000 01 01 00 28 00 00 01 00-73 00 65 00 6c 00 65 00 |...(.... s.e.l.e.| >>0010 63 00 74 00 20 00 40 00-40 00 76 00 65 00 72 00 |c.t. . at . @.v.e.r.| >>0020 73 00 69 00 6f 00 6e 00- |s.i.o.n.| >> >>ct.c:235:ct_describe_cmd_state(3) >>ct.c:235:ct_describe_cmd_state(2) >>ct.c:223:setting command state to SENT (from READY) >>ct.c:994:ct_send() succeeded >>ct.c:1132:ct_results(0x7fa6f5400040, 0x7fff5a6c6ff4) >>token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c6f84, >>0x7fff5a6c6f80, 0x6914) >>util.c:165:Changed query state from PENDING to READING >>packet.c:639:Received packet >>0000 04 01 01 bd 00 6c 01 00-81 01 00 00 00 21 00 e7 |.....l.. .....!..| >>0010 58 02 00 d1 9e 01 4d 00-69 00 63 00 72 00 6f 00 |X.....M. i.c.r.o.| >>0020 73 00 6f 00 66 00 74 00-20 00 53 00 51 00 4c 00 |s.o.f.t. .S.Q.L.| >>0030 20 00 53 00 65 00 72 00-76 00 65 00 72 00 20 00 | .S.e.r. v.e.r. .| >>0040 32 00 30 00 31 00 32 00-20 00 28 00 53 00 50 00 |2.0.1.2. .(.S.P.| >>0050 31 00 29 00 20 00 2d 00-20 00 31 00 31 00 2e 00 |1.). .-. .1.1...| >>0060 30 00 2e 00 33 00 34 00-33 00 37 00 2e 00 30 00 |0...3.4. 3.7...0.| >>0070 20 00 28 00 58 00 36 00-34 00 29 00 20 00 0a 00 | .(.X.6. 4.). ...| >>0080 09 00 4d 00 61 00 79 00-20 00 32 00 39 00 20 00 |..M.a.y. .2.9. .| >>0090 32 00 30 00 31 00 34 00-20 00 31 00 36 00 3a 00 |2.0.1.4. .1.6.:.| >>00a0 30 00 33 00 3a 00 34 00-30 00 20 00 0a 00 09 00 |0.3.:.4. 0. .....| >>00b0 43 00 6f 00 70 00 79 00-72 00 69 00 67 00 68 00 |C.o.p.y. r.i.g.h.| >>00c0 74 00 20 00 28 00 63 00-29 00 20 00 4d 00 69 00 |t. .(.c. ). .M.i.| >>00d0 63 00 72 00 6f 00 73 00-6f 00 66 00 74 00 20 00 |c.r.o.s. o.f.t. .| >>00e0 43 00 6f 00 72 00 70 00-6f 00 72 00 61 00 74 00 |C.o.r.p. o.r.a.t.| >>00f0 69 00 6f 00 6e 00 0a 00-09 00 44 00 65 00 76 00 |i.o.n... ..D.e.v.| >>0100 65 00 6c 00 6f 00 70 00-65 00 72 00 20 00 45 00 |e.l.o.p. e.r. .E.| >>0110 64 00 69 00 74 00 69 00-6f 00 6e 00 20 00 28 00 |d.i.t.i. o.n. .(.| >>0120 36 00 34 00 2d 00 62 00-69 00 74 00 29 00 20 00 |6.4.-.b. i.t.). .| >>0130 6f 00 6e 00 20 00 57 00-69 00 6e 00 64 00 6f 00 |o.n. .W. i.n.d.o.| >>0140 77 00 73 00 20 00 4e 00-54 00 20 00 36 00 2e 00 |w.s. .N. T. .6...| >>0150 31 00 20 00 3c 00 58 00-36 00 34 00 3e 00 20 00 |1. .<.X. 6.4.>. .| >>0160 28 00 42 00 75 00 69 00-6c 00 64 00 20 00 37 00 |(.B.u.i. l.d. .7.| >>0170 36 00 30 00 31 00 3a 00-20 00 53 00 65 00 72 00 |6.0.1.:. .S.e.r.| >>0180 76 00 69 00 63 00 65 00-20 00 50 00 61 00 63 00 |v.i.c.e. .P.a.c.| >>0190 6b 00 20 00 31 00 29 00-20 00 28 00 48 00 79 00 |k. .1.). .(.H.y.| >>01a0 70 00 65 00 72 00 76 00-69 00 73 00 6f 00 72 00 |p.e.r.v. i.s.o.r.| >>01b0 29 00 0a 00 fd 10 00 c1-00 01 00 00 00 |)....... .....| >> >>token.c:564:processing result tokens. marker is 81(TDS7_RESULT) >>token.c:1573:processing TDS7 result metadata. >>mem.c:648:tds_free_all_results() >>token.c:1598:set current_results (1 column) to tds->res_info >>token.c:1605:setting up 1 columns >>token.c:3164:adjust_character_column_size: >> Server charset: UCS-2LE >> Server column_size: 600 >> Client charset: UTF-8 >> Client column_size: 1200 >>token.c:1542:tds7_get_data_info: >> colname = >> type = 39 (varchar) >> server's type = 231 (x UCS-2 varchar) >> column_varint_size = 2 >> column_size = 1200 (600 on server) >>token.c:1614: name size/wsize type/wtype utype >>token.c:1615: -------------------- --------------- --------------- ------- >>token.c:1620: 1200/600 39/231 0 >>util.c:165:Changed query state from READING to PENDING >>ct.c:1189:ct_results() process_result_tokens returned 0 (type 4049) >>token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c6f84, >>0x7fff5a6c6f80, 0x6914) >>util.c:165:Changed query state from PENDING to READING >>token.c:564:processing result tokens. marker is d1(ROW) >>token.c:680:tds_process_tokens::SET_RETURN stopping on current token >>util.c:165:Changed query state from READING to PENDING >>ct.c:1189:ct_results() process_result_tokens returned 0 (type 4040) >>ct.c:2283:ct_describe(0x7fa6f5400040, 1, 0x7fff5a6c7000) >>ct.c:1896:_ct_get_client_type(type 39, user 0, size 1200) >>ct.c:2304:ct_describe() datafmt->datatype = 0 server type 39 >>ct.c:1457:ct_bind(0x7fa6f5400040, 1, 0x7fff5a6c7000, 0x7fff5a6c70c0, >>0x7fff5a6c6ff0, 0x7fff5a6c6fee) >>ct.c:1459:ct_bind() datafmt count = 1 column_number = 1 >>ct.c:1518:ct_fetch(0x7fa6f5400040, -99999, -99999, -99999, 0x7fff5a6c6fe8) >>token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c6f7c, 0x0, >>0x1608) >>util.c:165:Changed query state from PENDING to READING >>token.c:564:processing result tokens. marker is d1(ROW) >>token.c:1951:tds_process_row(): reading column 0 >>data.c:534:tds_get_data: type 39, varint size 2 >>data.c:587:tds_get_data(): wire column size is 414 >>util.c:165:Changed query state from READING to PENDING >>ct.c:1583:inside ct_fetch() process_row_tokens returned 0 >>ct.c:1723:_ct_bind_data(0x7fa6f576fd50, 0x7fa6f687adc0, 0x7fa6f687adc0, 0) >>ct.c:1730:_ct_bind_data(): column 0 is type 39 and has length 207 >>ct.c:1896:_ct_get_client_type(type 39, user 0, size 1200) >>cs.c:473:cs_convert(0x7fa6f576fd50, 0x7fff5a6c6e50, 0x7fa6f3a11c00, >>0x7fff5a6c6da0, 0x7fff5a6c70c0, 0x7fff5a6c6ff0) >>ct.c:2007:_ct_get_server_type(0) >>ct.c:2007:_ct_get_server_type(0) >>cs.c:521:converting type 47 (207 bytes) to type = 47 (255 bytes) >>cs.c:535:cs_convert() srctype == desttype >>cs.c:571:cs_convert() desttype = character >>cs.c:53:cs_prretcode(1) >>cs.c:660:cs_convert() returning CS_SUCCEED >>ct.c:1518:ct_fetch(0x7fa6f5400040, -99999, -99999, -99999, 0x7fff5a6c6fe8) >>ct.c:1132:ct_results(0x7fa6f5400040, 0x7fff5a6c6ff4) >>token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c6f84, >>0x7fff5a6c6f80, 0x6914) >>util.c:165:Changed query state from PENDING to READING >>token.c:564:processing result tokens. marker is fd(DONE) >>token.c:2080:tds_process_end: more_results = 0 >> was_cancelled = 0 >> error = 0 >> done_count_valid = 1 >>token.c:2097: rows_affected = 1 >>token.c:2100: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:1189:ct_results() process_result_tokens returned 0 (type 4052) >>ct.c:1295:ct_results() results state = 2 >>ct.c:1296:ct_results() command type = 148 >>ct.c:1297:ct_results() dynamic cmd = 0 >>ct.c:1132:ct_results(0x7fa6f5400040, 0x7fff5a6c6ff4) >>token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c6f84, >>0x7fff5a6c6f80, 0x6914) >>token.c:552:tds_process_tokens() state is COMPLETED >>ct.c:1189:ct_results() process_result_tokens returned 1 (type 4052) >>ct.c:235:ct_describe_cmd_state(2) >>ct.c:235:ct_describe_cmd_state(3) >>ct.c:223:setting command state to READY (from SENT) >>ct.c:1796:ct_cmd_drop(0x7fa6f5400040) >>ct.c:1827:ct_cmd_drop() : command entry found in list >>ct.c:1832:ct_cmd_drop() : relinking list >>ct.c:1839:ct_cmd_drop() : relinked list >>ct.c:673:ct_cmd_alloc(0x7fa6f687a2d0, 0x7fff5a6c6de0) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:223:setting command state to IDLE (from IDLE) >>ct.c:690:ct_cmd_alloc() : allocating command list to head >>ct.c:711:ct_command(0x7fa6f5359360, 148, 0x7fa6f2c01f00, -9, -99999) >>ct.c:850:_ct_initialise_cmd(0x7fa6f5359360) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:223:setting command state to IDLE (from IDLE) >>ct.c:4033:rpc_clear(0x0) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:223:setting command state to IDLE (from IDLE) >>ct.c:235:ct_describe_cmd_state(2) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:223:setting command state to READY (from IDLE) >>ct.c:869:ct_send(0x7fa6f5359360) >>ct.c:871:ct_send() command_type = 148 >>mem.c:648:tds_free_all_results() >>util.c:165:Changed query state from IDLE to WRITING >>util.c:165:Changed query state from WRITING to PENDING >>packet.c:740:Sending packet >>0000 01 01 00 18 00 00 01 00-75 00 73 00 65 00 20 00 |........ u.s.e. .| >>0010 6f 00 74 00 6f 00 33 00- |o.t.o.3.| >> >>ct.c:235:ct_describe_cmd_state(3) >>ct.c:235:ct_describe_cmd_state(2) >>ct.c:223:setting command state to SENT (from READY) >>ct.c:994:ct_send() succeeded >>ct.c:1132:ct_results(0x7fa6f5359360, 0x7fff5a6c66d0) >>token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c65f4, >>0x7fff5a6c65f0, 0x6914) >>util.c:165:Changed query state from PENDING to READING >>packet.c:639:Received packet >>0000 04 01 00 8a 00 6c 01 00-e3 11 00 01 04 4f 00 54 |.....l.. .....O.T| >>0010 00 4f 00 33 00 03 4f 00-54 00 4f 00 ab 62 00 45 |.O.3..O. T.O..b.E| >>0020 16 00 00 01 00 23 00 43-00 68 00 61 00 6e 00 67 |.....#.C .h.a.n.g| >>0030 00 65 00 64 00 20 00 64-00 61 00 74 00 61 00 62 |.e.d. .d .a.t.a.b| >>0040 00 61 00 73 00 65 00 20-00 63 00 6f 00 6e 00 74 |.a.s.e. .c.o.n.t| >>0050 00 65 00 78 00 74 00 20-00 74 00 6f 00 20 00 27 |.e.x.t. .t.o. .'| >>0060 00 4f 00 54 00 4f 00 33-00 27 00 2e 00 08 42 00 |.O.T.O.3 .'....B.| >>0070 4f 00 53 00 53 00 51 00-4c 00 44 00 34 00 00 01 |O.S.S.Q. L.D.4...| >>0080 00 fd 00 00 e2 00 00 00-00 00 |........ ..| >> >>token.c:564:processing result tokens. marker is e3(ENVCHANGE) >>token.c:115:tds_process_default_tokens() marker is e3(ENVCHANGE) >>token.c:564:processing result tokens. marker is ab(INFO) >>token.c:115:tds_process_default_tokens() marker is ab(INFO) >>token.c:2344:tds_process_msg() reading message 5701 from server >>token.c:2416:tds_process_msg() calling client msg handler >>ctutil.c:142:_ct_handle_server_message(0x7fa6f6874620, 0x7fa6f687a390, >>0x7fff5a6c6420) >>ct.c:350:ct_con_props(0x7fa6f687a2d0, 33, 9108, 0x7fff5a6c5628, 8, 0x0) >>ct.c:352:ct_con_props() action = CS_GET property = 9108 >>ct.c:512:fetching userdata 0x7fa6f6876d90 >>token.c:2429:tds_process_msg() returning TDS_SUCCESS >>token.c:564:processing result tokens. marker is fd(DONE) >>token.c:2080:tds_process_end: more_results = 0 >> was_cancelled = 0 >> error = 0 >> done_count_valid = 0 >>token.c:2097: rows_affected = 0 >>token.c:2100: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:1189:ct_results() process_result_tokens returned 0 (type 4052) >>ct.c:1295:ct_results() results state = 0 >>ct.c:1296:ct_results() command type = 148 >>ct.c:1297:ct_results() dynamic cmd = 0 >>ct.c:2347:ct_res_info(0x7fa6f5359360, 800, 0x7fa6f2c67598, -99999, 0x0) >>ct.c:2372:ct_res_info(): Number of rows is -1 >>ct.c:1132:ct_results(0x7fa6f5359360, 0x7fff5a6c66d0) >>ct.c:2347:ct_res_info(0x7fa6f5359360, 800, 0x7fa6f2c67598, -99999, 0x0) >>ct.c:2372:ct_res_info(): Number of rows is -1 >>ct.c:1132:ct_results(0x7fa6f5359360, 0x7fff5a6c66d0) >>token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c65f4, >>0x7fff5a6c65f0, 0x6914) >>token.c:552:tds_process_tokens() state is COMPLETED >>ct.c:1189:ct_results() process_result_tokens returned 1 (type 4052) >>ct.c:235:ct_describe_cmd_state(2) >>ct.c:235:ct_describe_cmd_state(3) >>ct.c:223:setting command state to READY (from SENT) >>ct.c:1796:ct_cmd_drop(0x7fa6f5359360) >>ct.c:1827:ct_cmd_drop() : command entry found in list >>ct.c:1832:ct_cmd_drop() : relinking list >>ct.c:1839:ct_cmd_drop() : relinked list >>ct.c:673:ct_cmd_alloc(0x7fa6f687a2d0, 0x7fff5a6c6de0) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:223:setting command state to IDLE (from IDLE) >>ct.c:690:ct_cmd_alloc() : allocating command list to head >>ct.c:711:ct_command(0x7fa6f5145ea0, 148, 0x1056b8000, -9, -99999) >>ct.c:850:_ct_initialise_cmd(0x7fa6f5145ea0) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:223:setting command state to IDLE (from IDLE) >>ct.c:4033:rpc_clear(0x0) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:223:setting command state to IDLE (from IDLE) >>ct.c:235:ct_describe_cmd_state(2) >>ct.c:235:ct_describe_cmd_state(0) >>ct.c:223:setting command state to READY (from IDLE) >>ct.c:869:ct_send(0x7fa6f5145ea0) >>ct.c:871:ct_send() command_type = 148 >>mem.c:648:tds_free_all_results() >>util.c:165:Changed query state from IDLE to WRITING >>packet.c:740:Sending packet >>0000 01 00 10 00 00 00 01 00-49 00 4e 00 53 00 45 00 |........ I.N.S.E.| >>0010 52 00 54 00 20 00 69 00-6e 00 74 00 6f 00 20 00 |R.T. .i. n.t.o. .| >>0020 54 00 45 00 53 00 54 00-54 00 41 00 42 00 4c 00 |T.E.S.T. T.A.B.L.| >>0030 45 00 20 00 28 00 6d 00-61 00 78 00 74 00 65 00 |E. .(.m. a.x.t.e.| >>0040 78 00 74 00 29 00 20 00-76 00 61 00 6c 00 75 00 |x.t.). . v.a.l.u.| >>0050 65 00 73 00 20 00 28 00-4e 00 27 00 78 00 78 00 |e.s. .(. N.'.x.x.| >> >>stream.c:125:Error: tds_convert_stream: tds_iconv returned errno 7, >>conv_errno 7 >>packet.c:740:Sending packet >>0000 01 00 10 00 00 00 01 00-78 00 78 00 78 00 78 00 |........ x.x.x.x.| >> >>packet.c:740:Sending packet >>0000 01 00 10 00 00 00 01 00-78 00 78 00 78 00 78 00 |........ x.x.x.x.| >> >>stream.c:125:Error: tds_convert_stream: tds_iconv returned errno 7, >>conv_errno 7 >>packet.c:740:Sending packet >>0000 01 00 10 00 00 00 01 00-78 00 78 00 78 00 78 00 |........ x.x.x.x.| >> >>stream.c:125:Error: tds_convert_stream: tds_iconv returned errno 7, >>conv_errno 7 >>util.c:165:Changed query state from WRITING to PENDING >>packet.c:740:Sending packet >>0000 01 01 0f 20 00 00 01 00-78 00 78 00 78 00 78 00 |... .... x.x.x.x.| >>0f10 78 00 78 00 78 00 78 00-78 00 78 00 27 00 29 00 |x.x.x.x. x.x.'.).| >> >>ct.c:235:ct_describe_cmd_state(3) >>ct.c:235:ct_describe_cmd_state(2) >>ct.c:223:setting command state to SENT (from READY) >>ct.c:994:ct_send() succeeded >>ct.c:1132:ct_results(0x7fa6f5145ea0, 0x7fff5a6c66d0) >>token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c65f4, >>0x7fff5a6c65f0, 0x6914) >>util.c:165:Changed query state from PENDING to READING >>packet.c:639:Received packet >>0000 04 01 00 11 00 6c 01 00-fd 10 00 c3 00 01 00 00 |.....l.. ........| >>0010 00 - |.| >> >>token.c:564:processing result tokens. marker is fd(DONE) >>token.c:2080:tds_process_end: more_results = 0 >> was_cancelled = 0 >> error = 0 >> done_count_valid = 1 >>token.c:2097: rows_affected = 1 >>token.c:2100: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:1189:ct_results() process_result_tokens returned 0 (type 4052) >>ct.c:1295:ct_results() results state = 0 >>ct.c:1296:ct_results() command type = 148 >>ct.c:1297:ct_results() dynamic cmd = 0 >>ct.c:2347:ct_res_info(0x7fa6f5145ea0, 800, 0x7fa6f687a908, -99999, 0x0) >>ct.c:2372:ct_res_info(): Number of rows is 1 >>ct.c:1132:ct_results(0x7fa6f5145ea0, 0x7fff5a6c66d0) >>ct.c:2347:ct_res_info(0x7fa6f5145ea0, 800, 0x7fa6f687a908, -99999, 0x0) >>ct.c:2372:ct_res_info(): Number of rows is 1 >>ct.c:1132:ct_results(0x7fa6f5145ea0, 0x7fff5a6c66d0) >>token.c:549:tds_process_tokens(0x7fa6f687a390, 0x7fff5a6c65f4, >>0x7fff5a6c65f0, 0x6914) >>token.c:552:tds_process_tokens() state is COMPLETED >>ct.c:1189:ct_results() process_result_tokens returned 1 (type 4052) >>ct.c:235:ct_describe_cmd_state(2) >>ct.c:235:ct_describe_cmd_state(3) >>ct.c:223:setting command state to READY (from SENT) >>ct.c:1796:ct_cmd_drop(0x7fa6f5145ea0) >>ct.c:1827:ct_cmd_drop() : command entry found in list >>ct.c:1832:ct_cmd_drop() : relinking list >>ct.c:1839:ct_cmd_drop() : relinked list >> >> >> >> >> >> >>On 10/7/15, 11:37 AM, "Frediano Ziglio" wrote: >> >>>I won't be surprised if there are also some limit in sql server. >>> >>>You are sending the data inside a language query string. It's quite >>>surprising changing log settings solve the issue, perhaps there is a >>>bug inside Ctlib (DBD::Sybase should use ctlib). You can try using a >>>packet sniffer to get traffic with the server. Can you post (or send >>>to me if you prefer) the logs anyway? >>>Probably you'd better compress them. From the log we can understand >>>which calls DBD::Sybase does so I can try reproduce with C directly. >>> >>>Frediano >>> >>> >>>2015-10-06 1:36 GMT+01:00 Jacopille, David : >>>> DC - Thanks for the quick reply. Text size is positively set to one >>>>million characters. >>>> >>>> 1. The data SELECT of 500,000 characters always works. >>>> 2. SELECT @@textsize does confirm the 1,000,000 setting (but the above >>>>also proves functionality) >>>> 3. 'Text size' setting only applies to SELECT statements, not INSERT >>>>where we are having the issue. This is demonstrably true for MS SQL >>>>Server, which we are using. Don't know about other databases. >>>> >>>> SQL Server 2012 nvarchar(max) does hold 2 GB theoretical. This >>>>specific table and nvarchar(max) column has proven to handle far more >>>>than the 1 MB values I'm testing with. At least through other >>>>software. >>>> >>>> I suspect that there is a bug in either FreeTDS 0.95 or DBD::Sybase >>>>1.15 that is limiting the text. However I find FreeTDS more suspicious >>>>because turning on logging (which changes something in FreeTDS) fixes >>>>the problem. >>>> >>>> Unfortunately the thing that would be useful to find the problem is >>>>what fixes the problem. >>>> >>>> Dave >>>> >>>> -----Original Message----- >>>> From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of >>>>David Chang >>>> Sent: Monday, October 05, 2015 6:54 PM >>>> To: FreeTDS Development Group >>>> Subject: Re: [freetds] Using FreeTDS 0.95 INSERTS fail above 66000 >>>>characters...unless 'dump file' is turned on >>>> >>>> Dave, >>>> >>>> I see you set the text size in the freetds.conf file to 1000000. I >>>>would confirm it using 'select @@textsize'. >>>> >>>> DC >>>> >>>> On 10/5/2015 2:07 PM, Jacopille, David wrote: >>>>> Looking for suggestions or a troubleshooting approach on this 100% >>>>> reproducible issue where FreeTDS logging seems to be the only >>>>>variable. >>>>> >>>>> Since the issue goes away as soon as I turn on freetds logging I can?t >>>>> look at the logs to find the problem. >>>>> >>>>> ENVIRONMENT >>>>> SQL Server 2012 >>>>> OS X 10.9.5 >>>>> FreeTDS 0.95.20 >>>>> DBD::Sybase 1.15 >>>>> TDSVER 7.0 or 7.1 (same symptoms) >>>>> Perl 5.16.3 >>>>> FreeTDS text size = 1000000 >>>>> >>>>> Testing large string INSERTS to a table with a single, nvarchar(max), >>>>> column >>>>> >>>>> >>>>> WHAT WORKS >>>>> A. With freetds logging on (via 'dump file = /tmp/freetds.log?) INSERT >>>>> values from 0-500,000 characters are successful. Decreasing >>>>> reliability above 500,000 characters. >>>>> >>>>> B. INSERT statements with values of 0 thru 66,000 characters always >>>>> work, regardless of freetds logging on/off >>>>> >>>>> C. SELECT work correctly for all values 0 thru one million characters, >>>>> regardless of freetds logging on/off >>>>> >>>>> >>>>> DOES NOT WORK >>>>> If freetds logging is turned off the following fails consistently: >>>>> >>>>> A. 67,000 character INSERT stalls at INSERT >>>>> >>>>> B. 100,000+ character INSERT doesn?t stall but doesn?t >>>>>INSERT >>>>> >>>>> C. Stored Procedures also experiencing failures in same character >>>>> ranges >>>>> >>>>> >>>>> FREETDS.CONF >>>>> >>>>> # In the failure configuration it looks like this. >>>>> # The ?DOES NOT WORK? symptoms go away if the last two lines are >>>>> uncommented. >>>>> >>>>> [global] >>>>> client charset = UTF-8 >>>>> text size = 1000000 >>>>> >>>>> [bossqld4] >>>>> host = bossqld4.mfs.com >>>>> port = 1433 >>>>> tds version = 7.0 >>>>> #dump file = /tmp/freetds.log >>>>> #dump file append = no >>>>> >>>>> >>>>> PERL SCRIPT REPRODUCING ISSUE (WITH NO FREETDS LOGGING) >>>>> >>>>> use DBI qw(:sql_types); >>>>> use DBD::Sybase; >>>>> my ($sql, $dbh, $ref, $largetext); >>>>> >>>>> $dbh = DBI->connect( 'DBI:Sybase:server=bossqld4', ?CORP\user', >>>>> ?password', { PrintError => 0 } ) or die; $dbh->do('use >>>>> testdatabase'); >>>>> >>>>> $largetext = 'x' x 100000; # one hundred thousand characters >>>>> >>>>> $dbh->do(qq|INSERT into TESTTABLE (maxtext) values >>>>> (N\'$largetext\')|); >>>>> >>>>> # SELECT not affected by FreeTDS logging on/off # SELECT always >>>>> successful on all values tested up to one million characters (and >>>>> probably much larger, but untested). >>>>> >>>>> $sql = q|SELECT TOP 1 [maxtext] FROM TESTTABLE|; $ref = >>>>> $dbh->selectrow_arrayref($sql); print 'Length of value: '. (length >>>>> $$ref[0]) ."\n"; >>>>> >>>>> $dbh->disconnect(); >>>>> >>>>> >>>>> Thank you, >>>>> Dave Jacopille >>>>> Boston >>>>> >>>>> MFS Email system made the following annotation >>>>> ---------------------------------------------------------------------- >>>>> ----------------------------------------------------------------- >>>>> This email communication and any attachments may contain proprietary, >>>>>confidential, or privileged information. If you are not the intended >>>>>recipient, you are hereby notified that you have received this email in >>>>>error and that any review, disclosure, dissemination, distribution or >>>>>copying of it or its contents is prohibited. The sender does not waive >>>>>confidentiality or any privilege by mistransmission. If you have >>>>>received this email in error, please notify the sender immediately, >>>>>delete this email, and destroy all copies and any attachments. >>>>> _______________________________________________ >>>>> FreeTDS mailing list >>>>> FreeTDS at lists.ibiblio.org >>>>> http://lists.ibiblio.org/mailman/listinfo/freetds >>>> >>>> _______________________________________________ >>>> FreeTDS mailing list >>>> FreeTDS at lists.ibiblio.org >>>> http://lists.ibiblio.org/mailman/listinfo/freetds >>>> MFS Email system made the following annotation >>>> >>>>------------------------------------------------------------------------ >>>>- >>>>-------------------------------------------------------------- >>>> This email communication and any attachments may contain proprietary, >>>>confidential, or privileged information. If you are not the intended >>>>recipient, you are hereby notified that you have received this email in >>>>error and that any review, disclosure, dissemination, distribution or >>>>copying of it or its contents is prohibited. The sender does not waive >>>>confidentiality or any privilege by mistransmission. If you have >>>>received this email in error, please notify the sender immediately, >>>>delete this email, and destroy all copies and any attachments. >>>> _______________________________________________ >>>> FreeTDS mailing list >>>> FreeTDS at lists.ibiblio.org >>>> http://lists.ibiblio.org/mailman/listinfo/freetds >>>_______________________________________________ >>>FreeTDS mailing list >>>FreeTDS at lists.ibiblio.org >>>http://lists.ibiblio.org/mailman/listinfo/freetds >> >>MFS Email system made the following annotation >>-------------------------------------------------------------------------- >>------------------------------------------------------------- >>This email communication and any attachments may contain proprietary, >>confidential, or privileged information. If you are not the intended >>recipient, you are hereby notified that you have received this email in >>error and that any review, disclosure, dissemination, distribution or >>copying of it or its contents is prohibited. The sender does not waive >>confidentiality or any privilege by mistransmission. If you have received >>this email in error, please notify the sender immediately, delete this >>email, and destroy all copies and any attachments. >>_______________________________________________ >>FreeTDS mailing list >>FreeTDS at lists.ibiblio.org >>http://lists.ibiblio.org/mailman/listinfo/freetds > > MFS Email system made the following annotation > --------------------------------------------------------------------------------------------------------------------------------------- > This email communication and any attachments may contain proprietary, confidential, or privileged information. If you are not the intended recipient, you are hereby notified that you have received this email in error and that any review, disclosure, dissemination, distribution or copying of it or its contents is prohibited. The sender does not waive confidentiality or any privilege by mistransmission. If you have received this email in error, please notify the sender immediately, delete this email, and destroy all copies and any attachments. > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds _______________________________________________ FreeTDS mailing list FreeTDS at lists.ibiblio.org http://lists.ibiblio.org/mailman/listinfo/freetds MFS Email system made the following annotation --------------------------------------------------------------------------------------------------------------------------------------- This email communication and any attachments may contain proprietary, confidential, or privileged information. If you are not the intended recipient, you are hereby notified that you have received this email in error and that any review, disclosure, dissemination, distribution or copying of it or its contents is prohibited. The sender does not waive confidentiality or any privilege by mistransmission. If you have received this email in error, please notify the sender immediately, delete this email, and destroy all copies and any attachments. From no-reply at appveyor.com Wed Oct 14 18:14:29 2015 From: no-reply at appveyor.com (AppVeyor) Date: Wed, 14 Oct 2015 22:14:29 +0000 Subject: [freetds] Build failed: freetds 270 Message-ID: <20151014221429.128830.79024@appveyor.com> From no-reply at appveyor.com Wed Oct 14 18:33:09 2015 From: no-reply at appveyor.com (AppVeyor) Date: Wed, 14 Oct 2015 22:33:09 +0000 Subject: [freetds] Build completed: freetds 271 Message-ID: <20151014223308.477.73530@appveyor.com> From david at qore.org Fri Oct 16 07:23:45 2015 From: david at qore.org (David Nichols) Date: Fri, 16 Oct 2015 13:23:45 +0200 Subject: [freetds] affected rows after insert Message-ID: > 2015-06-09 14:48 GMT+01:00 Ondrej Holecek >: > > Hi, > > > > I made a test with the same code but sybase lib and it works like > > expected. It seems there is a bug in FreeTDS. Could you please check > > my patch? > > > > thx, > > > > Ondrej > > > > Actually works and ctlib tests seems to pass. > > However DONEINPROC is returned in a lot of cases, for instance if > database execute some trigger on the table so your patch can catch > some strange results too. > > Which database version are you using? > > Frediano Hi, Ondra has not been working on this for quite some time, but I?d like to pick up this issue again please. We are using MS SQL Server 2008 - using tds version = 7.2 - with the patch we are able to get the affected rows reliably - without it, we are not. Using the same patched library build with a Sybase (SAP) ASE 16.0 DB, it also gives correct results (with tds version = 5.0) I would be happy to continue helping with this issue if there?s a chance it could be included in freetds (or some other equally effective fix). thanks, David > > On Tue, Jun 2, 2015 at 10:49 AM, Ondrej Holecek > > > wrote: > >> Hi, > >> > >> I have a problem obtaining number of affected rows while inserting. > >> The problem occurs when I pass the values by ct_param() call. > >> So, this command order works well: > >> > >> ct_cmd_alloc() > >> ct_command(CS_LANG_CMD, "INSERT INTO test (number) VALUES(5)") > >> ct_send() > >> ct_result() // the result type is CS_CMD_DONE so I can call... > >> ct_res_info(CS_ROW_COUNT) // as expected 1 row affected > >> > >> > >> but when I call it like this, It skips CS_CMD_DONE, so I can't read > >> the affected rows number. > >> > >> ct_cmd_alloc() > >> ct_command(CS_LANG_CMD, "INSERT INTO test (number) VALUES(@par1)") > >> ct_param("@par1", 1) > >> ct_send() > >> ct_result() // the result type is CS_END_RESULT > >> // can't do anything here :-( > >> > >> > >> The row is inserted in both cases correctly just in the second case I > >> can't read the number of affected rows. > >> > >> I did some ctlib debugging and I created the patch which would fix > >> this behavior. However, I just changed the code blindly (based on the > >> debugging) not knowing what is the real purpose of the case. > >> > >> > >> in ct_result() function I changed the case _CS_RES_INIT: > >> > >> case _CS_RES_INIT: /* commalindlnd had no result set */ > >> if (tds->rows_affected > 0) { > >> *result_type = CS_CMD_DONE; > >> cmd->results_state = _CS_RES_INIT; > >> return CS_SUCCEED; > >> } > >> break; > >> > >> now it seems with the patch it works correctly. But I have no idea if > >> it is really the correct way. > >> > >> Any ideas? > >> > >> Thanks, > >> > >> Ondrej From freddy77 at gmail.com Sun Oct 18 04:06:45 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Sun, 18 Oct 2015 09:06:45 +0100 Subject: [freetds] affected rows after insert In-Reply-To: References: Message-ID: 2015-10-16 12:23 GMT+01:00 David Nichols : >> 2015-06-09 14:48 GMT+01:00 Ondrej Holecek >: >> > Hi, >> > >> > I made a test with the same code but sybase lib and it works like >> > expected. It seems there is a bug in FreeTDS. Could you please check >> > my patch? >> > >> > thx, >> > >> > Ondrej >> > >> >> Actually works and ctlib tests seems to pass. >> >> However DONEINPROC is returned in a lot of cases, for instance if >> database execute some trigger on the table so your patch can catch >> some strange results too. >> >> Which database version are you using? >> >> Frediano > Hi, > > Ondra has not been working on this for quite some time, but I?d like to pick up this issue again please. > > We are using MS SQL Server 2008 - using tds version = 7.2 - with the patch we are able to get the affected rows reliably - without it, we are not. > > Using the same patched library build with a Sybase (SAP) ASE 16.0 DB, it also gives correct results (with tds version = 5.0) > > I would be happy to continue helping with this issue if there?s a chance it could be included in freetds (or some other equally effective fix). > > thanks, > David > A fix was written for this case. Do you still have some code that fails? Did you update FreeTDS? Frediano >> > On Tue, Jun 2, 2015 at 10:49 AM, Ondrej Holecek >> > > wrote: >> >> Hi, >> >> >> >> I have a problem obtaining number of affected rows while inserting. >> >> The problem occurs when I pass the values by ct_param() call. >> >> So, this command order works well: >> >> >> >> ct_cmd_alloc() >> >> ct_command(CS_LANG_CMD, "INSERT INTO test (number) VALUES(5)") >> >> ct_send() >> >> ct_result() // the result type is CS_CMD_DONE so I can call... >> >> ct_res_info(CS_ROW_COUNT) // as expected 1 row affected >> >> >> >> >> >> but when I call it like this, It skips CS_CMD_DONE, so I can't read >> >> the affected rows number. >> >> >> >> ct_cmd_alloc() >> >> ct_command(CS_LANG_CMD, "INSERT INTO test (number) VALUES(@par1)") >> >> ct_param("@par1", 1) >> >> ct_send() >> >> ct_result() // the result type is CS_END_RESULT >> >> // can't do anything here :-( >> >> >> >> >> >> The row is inserted in both cases correctly just in the second case I >> >> can't read the number of affected rows. >> >> >> >> I did some ctlib debugging and I created the patch which would fix >> >> this behavior. However, I just changed the code blindly (based on the >> >> debugging) not knowing what is the real purpose of the case. >> >> >> >> >> >> in ct_result() function I changed the case _CS_RES_INIT: >> >> >> >> case _CS_RES_INIT: /* commalindlnd had no result set */ >> >> if (tds->rows_affected > 0) { >> >> *result_type = CS_CMD_DONE; >> >> cmd->results_state = _CS_RES_INIT; >> >> return CS_SUCCEED; >> >> } >> >> break; >> >> >> >> now it seems with the patch it works correctly. But I have no idea if >> >> it is really the correct way. >> >> >> >> Any ideas? >> >> >> >> Thanks, >> >> >> >> Ondrej > > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From no-reply at appveyor.com Sun Oct 18 14:00:17 2015 From: no-reply at appveyor.com (AppVeyor) Date: Sun, 18 Oct 2015 18:00:17 +0000 Subject: [freetds] Build failed: freetds 280 Message-ID: <20151018180017.3289.95880@appveyor.com> From no-reply at appveyor.com Sun Oct 18 14:34:19 2015 From: no-reply at appveyor.com (AppVeyor) Date: Sun, 18 Oct 2015 18:34:19 +0000 Subject: [freetds] Build completed: freetds 281 Message-ID: <20151018183419.3299.93774@appveyor.com> From david at qore.org Mon Oct 19 06:16:52 2015 From: david at qore.org (David Nichols) Date: Mon, 19 Oct 2015 12:16:52 +0200 Subject: [freetds] affected rows after insert In-Reply-To: References: Message-ID: > On Oct 18, 2015, at 10:06 AM, Frediano Ziglio wrote: > > 2015-10-16 12:23 GMT+01:00 David Nichols : >>> 2015-06-09 14:48 GMT+01:00 Ondrej Holecek >: >>>> Hi, >>>> >>>> I made a test with the same code but sybase lib and it works like >>>> expected. It seems there is a bug in FreeTDS. Could you please check >>>> my patch? >>>> >>>> thx, >>>> >>>> Ondrej >>>> >>> >>> Actually works and ctlib tests seems to pass. >>> >>> However DONEINPROC is returned in a lot of cases, for instance if >>> database execute some trigger on the table so your patch can catch >>> some strange results too. >>> >>> Which database version are you using? >>> >>> Frediano >> Hi, >> >> Ondra has not been working on this for quite some time, but I?d like to pick up this issue again please. >> >> We are using MS SQL Server 2008 - using tds version = 7.2 - with the patch we are able to get the affected rows reliably - without it, we are not. >> >> Using the same patched library build with a Sybase (SAP) ASE 16.0 DB, it also gives correct results (with tds version = 5.0) >> >> I would be happy to continue helping with this issue if there?s a chance it could be included in freetds (or some other equally effective fix). >> >> thanks, >> David >> > > A fix was written for this case. Do you still have some code that > fails? Did you update FreeTDS? > > Frediano yes, I tried it with freetds from freetds-0.95.12 and git master - both failed my tests and with the patch as provded by Ondra the tests then passed. Sorry I did not mention this in the original email. BTW I had to comment out the reference to AM_ICONV in configure.ac to get freetds to build from git master on Linux thx David >>>> On Tue, Jun 2, 2015 at 10:49 AM, Ondrej Holecek >>>> > wrote: >>>>> Hi, >>>>> >>>>> I have a problem obtaining number of affected rows while inserting. >>>>> The problem occurs when I pass the values by ct_param() call. >>>>> So, this command order works well: >>>>> >>>>> ct_cmd_alloc() >>>>> ct_command(CS_LANG_CMD, "INSERT INTO test (number) VALUES(5)") >>>>> ct_send() >>>>> ct_result() // the result type is CS_CMD_DONE so I can call... >>>>> ct_res_info(CS_ROW_COUNT) // as expected 1 row affected >>>>> >>>>> >>>>> but when I call it like this, It skips CS_CMD_DONE, so I can't read >>>>> the affected rows number. >>>>> >>>>> ct_cmd_alloc() >>>>> ct_command(CS_LANG_CMD, "INSERT INTO test (number) VALUES(@par1)") >>>>> ct_param("@par1", 1) >>>>> ct_send() >>>>> ct_result() // the result type is CS_END_RESULT >>>>> // can't do anything here :-( >>>>> >>>>> >>>>> The row is inserted in both cases correctly just in the second case I >>>>> can't read the number of affected rows. >>>>> >>>>> I did some ctlib debugging and I created the patch which would fix >>>>> this behavior. However, I just changed the code blindly (based on the >>>>> debugging) not knowing what is the real purpose of the case. >>>>> >>>>> >>>>> in ct_result() function I changed the case _CS_RES_INIT: >>>>> >>>>> case _CS_RES_INIT: /* commalindlnd had no result set */ >>>>> if (tds->rows_affected > 0) { >>>>> *result_type = CS_CMD_DONE; >>>>> cmd->results_state = _CS_RES_INIT; >>>>> return CS_SUCCEED; >>>>> } >>>>> break; >>>>> >>>>> now it seems with the patch it works correctly. But I have no idea if >>>>> it is really the correct way. >>>>> >>>>> Any ideas? >>>>> >>>>> Thanks, >>>>> >>>>> Ondrej >> >> >> _______________________________________________ >> 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 Mon Oct 19 07:53:53 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Mon, 19 Oct 2015 12:53:53 +0100 Subject: [freetds] affected rows after insert In-Reply-To: References: Message-ID: 2015-10-19 11:16 GMT+01:00 David Nichols : > >> On Oct 18, 2015, at 10:06 AM, Frediano Ziglio wrote: >> >> 2015-10-16 12:23 GMT+01:00 David Nichols : >>>> 2015-06-09 14:48 GMT+01:00 Ondrej Holecek >: >>>>> Hi, >>>>> >>>>> I made a test with the same code but sybase lib and it works like >>>>> expected. It seems there is a bug in FreeTDS. Could you please check >>>>> my patch? >>>>> >>>>> thx, >>>>> >>>>> Ondrej >>>>> >>>> >>>> Actually works and ctlib tests seems to pass. >>>> >>>> However DONEINPROC is returned in a lot of cases, for instance if >>>> database execute some trigger on the table so your patch can catch >>>> some strange results too. >>>> >>>> Which database version are you using? >>>> >>>> Frediano >>> Hi, >>> >>> Ondra has not been working on this for quite some time, but I?d like to pick up this issue again please. >>> >>> We are using MS SQL Server 2008 - using tds version = 7.2 - with the patch we are able to get the affected rows reliably - without it, we are not. >>> >>> Using the same patched library build with a Sybase (SAP) ASE 16.0 DB, it also gives correct results (with tds version = 5.0) >>> >>> I would be happy to continue helping with this issue if there?s a chance it could be included in freetds (or some other equally effective fix). >>> >>> thanks, >>> David >>> >> >> A fix was written for this case. Do you still have some code that >> fails? Did you update FreeTDS? >> >> Frediano > > yes, I tried it with freetds from freetds-0.95.12 and git master - both failed my tests and with the patch as provded by Ondra the tests then passed. Sorry I did not mention this in the original email. > Please try a more recent version (like 0.95.21). Also you should sent some extract of your tests. Can you post an updated patch? > BTW I had to comment out the reference to AM_ICONV in configure.ac to get freetds to build from git master on Linux > Quite odd. Could be you miss some package on your system. Which error did you get? Could be you have an old autoconf package. Frediano > thx > David > > >>>>> On Tue, Jun 2, 2015 at 10:49 AM, Ondrej Holecek >>>>> > wrote: >>>>>> Hi, >>>>>> >>>>>> I have a problem obtaining number of affected rows while inserting. >>>>>> The problem occurs when I pass the values by ct_param() call. >>>>>> So, this command order works well: >>>>>> >>>>>> ct_cmd_alloc() >>>>>> ct_command(CS_LANG_CMD, "INSERT INTO test (number) VALUES(5)") >>>>>> ct_send() >>>>>> ct_result() // the result type is CS_CMD_DONE so I can call... >>>>>> ct_res_info(CS_ROW_COUNT) // as expected 1 row affected >>>>>> >>>>>> >>>>>> but when I call it like this, It skips CS_CMD_DONE, so I can't read >>>>>> the affected rows number. >>>>>> >>>>>> ct_cmd_alloc() >>>>>> ct_command(CS_LANG_CMD, "INSERT INTO test (number) VALUES(@par1)") >>>>>> ct_param("@par1", 1) >>>>>> ct_send() >>>>>> ct_result() // the result type is CS_END_RESULT >>>>>> // can't do anything here :-( >>>>>> >>>>>> >>>>>> The row is inserted in both cases correctly just in the second case I >>>>>> can't read the number of affected rows. >>>>>> >>>>>> I did some ctlib debugging and I created the patch which would fix >>>>>> this behavior. However, I just changed the code blindly (based on the >>>>>> debugging) not knowing what is the real purpose of the case. >>>>>> >>>>>> >>>>>> in ct_result() function I changed the case _CS_RES_INIT: >>>>>> >>>>>> case _CS_RES_INIT: /* commalindlnd had no result set */ >>>>>> if (tds->rows_affected > 0) { >>>>>> *result_type = CS_CMD_DONE; >>>>>> cmd->results_state = _CS_RES_INIT; >>>>>> return CS_SUCCEED; >>>>>> } >>>>>> break; >>>>>> >>>>>> now it seems with the patch it works correctly. But I have no idea if >>>>>> it is really the correct way. >>>>>> >>>>>> Any ideas? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Ondrej >>> >>> >>> _______________________________________________ >>> 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 david at qore.org Mon Oct 19 08:35:33 2015 From: david at qore.org (David Nichols) Date: Mon, 19 Oct 2015 14:35:33 +0200 Subject: [freetds] affected rows after insert In-Reply-To: References: Message-ID: <4AA5C8FC-111B-4F3B-9751-A9A19E226C6B@qore.org> > On Oct 19, 2015, at 1:53 PM, Frediano Ziglio wrote: > > 2015-10-19 11:16 GMT+01:00 David Nichols : >> >>> On Oct 18, 2015, at 10:06 AM, Frediano Ziglio wrote: >>> >>> 2015-10-16 12:23 GMT+01:00 David Nichols : >>>>> 2015-06-09 14:48 GMT+01:00 Ondrej Holecek >: >>>>>> Hi, >>>>>> >>>>>> I made a test with the same code but sybase lib and it works like >>>>>> expected. It seems there is a bug in FreeTDS. Could you please check >>>>>> my patch? >>>>>> >>>>>> thx, >>>>>> >>>>>> Ondrej >>>>>> >>>>> >>>>> Actually works and ctlib tests seems to pass. >>>>> >>>>> However DONEINPROC is returned in a lot of cases, for instance if >>>>> database execute some trigger on the table so your patch can catch >>>>> some strange results too. >>>>> >>>>> Which database version are you using? >>>>> >>>>> Frediano >>>> Hi, >>>> >>>> Ondra has not been working on this for quite some time, but I?d like to pick up this issue again please. >>>> >>>> We are using MS SQL Server 2008 - using tds version = 7.2 - with the patch we are able to get the affected rows reliably - without it, we are not. >>>> >>>> Using the same patched library build with a Sybase (SAP) ASE 16.0 DB, it also gives correct results (with tds version = 5.0) >>>> >>>> I would be happy to continue helping with this issue if there?s a chance it could be included in freetds (or some other equally effective fix). >>>> >>>> thanks, >>>> David >>>> >>> >>> A fix was written for this case. Do you still have some code that >>> fails? Did you update FreeTDS? >>> >>> Frediano >> >> yes, I tried it with freetds from freetds-0.95.12 and git master - both failed my tests and with the patch as provded by Ondra the tests then passed. Sorry I did not mention this in the original email. >> > > Please try a more recent version (like 0.95.21). Also you should sent > some extract of your tests. Can you post an updated patch? > sorry it was a typo on my side - it was 0.95.21 that I tried. Anyway since it failed in git master then I would assume that would be more relevant than the last stable release. Attached please find a patch to git master sources that makes my tests work. Please note that we are using ctlib from freetds to build a DBI driver for the Qore programming language to talk to SQL Server and Sybase DBs; the same source builds with both the sybae libs and ctlib from freetds. Currently my tests are written in the Qore programming language, so there are quite a few layers between the Qore code that?s executed and freetds?s ctlib. When this simple test works (ie only with a patch ctlib); the output looks like this: dnichols at manatee:~/src/qore/git/module-sybase/src$ simple-rows-affected-test.q "Microsoft SQL Server 2008 (RTM) - 10.0.1600.22 (X64) Jul 9 2008 14:17:44 Copyright (c) 1988-2008 Microsoft Corporation Developer Edition (64-bit) on Windows NT 6.1 (Build 7601: Service Pack 1)" insert: 1 n delete: 0 sel: {id: [1]} delete: 1 insert: 1 delete: 1 When it doesn?t work (ie with an unpatched ctlib), the output looks like this: dnichols at manatee:~/src/qore/git/module-sybase/src$ simple-rows-affected-test.q "Microsoft SQL Server 2008 (RTM) - 10.0.1600.22 (X64) Jul 9 2008 14:17:44 Copyright (c) 1988-2008 Microsoft Corporation Developer Edition (64-bit) on Windows NT 6.1 (Build 7601: Service Pack 1)" insert: 0 n delete: 0 sel: {id: [1]} delete: 0 insert: -1 delete: -1 The Qore source to this simple test is attached for your reference. >> BTW I had to comment out the reference to AM_ICONV in configure.ac to get freetds to build from git master on Linux >> > Quite odd. Could be you miss some package on your system. Which error > did you get? Could be you have an old autoconf package. I compiled it on fedora 22 with autocont 2.69. However I just did a search and found that AM_ICONV is installed with the gettext-devel package, which I?ve now installed, and now freetds from git master can be built without any hacks to configure.ac on Fedora. thx David -------------- next part -------------- A non-text attachment was scrubbed... Name: rows-affected-patch.diff Type: application/octet-stream Size: 526 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: simple-rows-affected-test.q Type: application/octet-stream Size: 737 bytes Desc: not available URL: -------------- next part -------------- > Frediano > >> thx >> David >> >> >>>>>> On Tue, Jun 2, 2015 at 10:49 AM, Ondrej Holecek >>>>>> > wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I have a problem obtaining number of affected rows while inserting. >>>>>>> The problem occurs when I pass the values by ct_param() call. >>>>>>> So, this command order works well: >>>>>>> >>>>>>> ct_cmd_alloc() >>>>>>> ct_command(CS_LANG_CMD, "INSERT INTO test (number) VALUES(5)") >>>>>>> ct_send() >>>>>>> ct_result() // the result type is CS_CMD_DONE so I can call... >>>>>>> ct_res_info(CS_ROW_COUNT) // as expected 1 row affected >>>>>>> >>>>>>> >>>>>>> but when I call it like this, It skips CS_CMD_DONE, so I can't read >>>>>>> the affected rows number. >>>>>>> >>>>>>> ct_cmd_alloc() >>>>>>> ct_command(CS_LANG_CMD, "INSERT INTO test (number) VALUES(@par1)") >>>>>>> ct_param("@par1", 1) >>>>>>> ct_send() >>>>>>> ct_result() // the result type is CS_END_RESULT >>>>>>> // can't do anything here :-( >>>>>>> >>>>>>> >>>>>>> The row is inserted in both cases correctly just in the second case I >>>>>>> can't read the number of affected rows. >>>>>>> >>>>>>> I did some ctlib debugging and I created the patch which would fix >>>>>>> this behavior. However, I just changed the code blindly (based on the >>>>>>> debugging) not knowing what is the real purpose of the case. >>>>>>> >>>>>>> >>>>>>> in ct_result() function I changed the case _CS_RES_INIT: >>>>>>> >>>>>>> case _CS_RES_INIT: /* commalindlnd had no result set */ >>>>>>> if (tds->rows_affected > 0) { >>>>>>> *result_type = CS_CMD_DONE; >>>>>>> cmd->results_state = _CS_RES_INIT; >>>>>>> return CS_SUCCEED; >>>>>>> } >>>>>>> break; >>>>>>> >>>>>>> now it seems with the patch it works correctly. But I have no idea if >>>>>>> it is really the correct way. >>>>>>> >>>>>>> Any ideas? >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Ondrej >>>> >>>> >>>> _______________________________________________ >>>> 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 Mon Oct 19 16:20:27 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Mon, 19 Oct 2015 21:20:27 +0100 Subject: [freetds] affected rows after insert In-Reply-To: <4AA5C8FC-111B-4F3B-9751-A9A19E226C6B@qore.org> References: <4AA5C8FC-111B-4F3B-9751-A9A19E226C6B@qore.org> Message-ID: 2015-10-19 13:35 GMT+01:00 David Nichols : > >> On Oct 19, 2015, at 1:53 PM, Frediano Ziglio wrote: >> >> 2015-10-19 11:16 GMT+01:00 David Nichols : >>> >>>> On Oct 18, 2015, at 10:06 AM, Frediano Ziglio wrote: >>>> >>>> 2015-10-16 12:23 GMT+01:00 David Nichols : >>>>>> 2015-06-09 14:48 GMT+01:00 Ondrej Holecek >: >>>>>>> Hi, >>>>>>> >>>>>>> I made a test with the same code but sybase lib and it works like >>>>>>> expected. It seems there is a bug in FreeTDS. Could you please check >>>>>>> my patch? >>>>>>> >>>>>>> thx, >>>>>>> >>>>>>> Ondrej >>>>>>> >>>>>> >>>>>> Actually works and ctlib tests seems to pass. >>>>>> >>>>>> However DONEINPROC is returned in a lot of cases, for instance if >>>>>> database execute some trigger on the table so your patch can catch >>>>>> some strange results too. >>>>>> >>>>>> Which database version are you using? >>>>>> >>>>>> Frediano >>>>> Hi, >>>>> >>>>> Ondra has not been working on this for quite some time, but I?d like to pick up this issue again please. >>>>> >>>>> We are using MS SQL Server 2008 - using tds version = 7.2 - with the patch we are able to get the affected rows reliably - without it, we are not. >>>>> >>>>> Using the same patched library build with a Sybase (SAP) ASE 16.0 DB, it also gives correct results (with tds version = 5.0) >>>>> >>>>> I would be happy to continue helping with this issue if there?s a chance it could be included in freetds (or some other equally effective fix). >>>>> >>>>> thanks, >>>>> David >>>>> >>>> >>>> A fix was written for this case. Do you still have some code that >>>> fails? Did you update FreeTDS? >>>> >>>> Frediano >>> >>> yes, I tried it with freetds from freetds-0.95.12 and git master - both failed my tests and with the patch as provded by Ondra the tests then passed. Sorry I did not mention this in the original email. >>> >> >> Please try a more recent version (like 0.95.21). Also you should sent >> some extract of your tests. Can you post an updated patch? >> > sorry it was a typo on my side - it was 0.95.21 that I tried. Anyway since it failed in git master then I would assume that would be more relevant than the last stable release. > > Attached please find a patch to git master sources that makes my tests work. Please note that we are using ctlib from freetds to build a DBI driver for the Qore programming language to talk to SQL Server and Sybase DBs; the same source builds with both the sybae libs and ctlib from freetds. Currently my tests are written in the Qore programming language, so there are quite a few layers between the Qore code that?s executed and freetds?s ctlib. > > When this simple test works (ie only with a patch ctlib); the output looks like this: > > dnichols at manatee:~/src/qore/git/module-sybase/src$ simple-rows-affected-test.q > "Microsoft SQL Server 2008 (RTM) - 10.0.1600.22 (X64) > Jul 9 2008 14:17:44 > Copyright (c) 1988-2008 Microsoft Corporation > Developer Edition (64-bit) on Windows NT 6.1 (Build 7601: Service Pack 1)" > insert: 1 > n delete: 0 > sel: {id: [1]} > delete: 1 > insert: 1 > delete: 1 > > When it doesn?t work (ie with an unpatched ctlib), the output looks like this: > dnichols at manatee:~/src/qore/git/module-sybase/src$ simple-rows-affected-test.q > "Microsoft SQL Server 2008 (RTM) - 10.0.1600.22 (X64) > Jul 9 2008 14:17:44 > Copyright (c) 1988-2008 Microsoft Corporation > Developer Edition (64-bit) on Windows NT 6.1 (Build 7601: Service Pack 1)" > insert: 0 > n delete: 0 > sel: {id: [1]} > delete: 0 > insert: -1 > delete: -1 > > The Qore source to this simple test is attached for your reference. > I applied the patch and improved a test to catch this issue. I changed the patch slightly to check for TDS_NO_COUNT instead of <0 and returning CS_CMD_SUCCEEDED as ct_res_info documentation Frediano >>> BTW I had to comment out the reference to AM_ICONV in configure.ac to get freetds to build from git master on Linux >>> >> Quite odd. Could be you miss some package on your system. Which error >> did you get? Could be you have an old autoconf package. > > I compiled it on fedora 22 with autocont 2.69. However I just did a search and found that AM_ICONV is installed with the gettext-devel package, which I?ve now installed, and now freetds from git master can be built without any hacks to configure.ac on Fedora. > > thx > David > > > > >> Frediano >> >>> thx >>> David >>> >>> >>>>>>> On Tue, Jun 2, 2015 at 10:49 AM, Ondrej Holecek >>>>>>> > wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I have a problem obtaining number of affected rows while inserting. >>>>>>>> The problem occurs when I pass the values by ct_param() call. >>>>>>>> So, this command order works well: >>>>>>>> >>>>>>>> ct_cmd_alloc() >>>>>>>> ct_command(CS_LANG_CMD, "INSERT INTO test (number) VALUES(5)") >>>>>>>> ct_send() >>>>>>>> ct_result() // the result type is CS_CMD_DONE so I can call... >>>>>>>> ct_res_info(CS_ROW_COUNT) // as expected 1 row affected >>>>>>>> >>>>>>>> >>>>>>>> but when I call it like this, It skips CS_CMD_DONE, so I can't read >>>>>>>> the affected rows number. >>>>>>>> >>>>>>>> ct_cmd_alloc() >>>>>>>> ct_command(CS_LANG_CMD, "INSERT INTO test (number) VALUES(@par1)") >>>>>>>> ct_param("@par1", 1) >>>>>>>> ct_send() >>>>>>>> ct_result() // the result type is CS_END_RESULT >>>>>>>> // can't do anything here :-( >>>>>>>> >>>>>>>> >>>>>>>> The row is inserted in both cases correctly just in the second case I >>>>>>>> can't read the number of affected rows. >>>>>>>> >>>>>>>> I did some ctlib debugging and I created the patch which would fix >>>>>>>> this behavior. However, I just changed the code blindly (based on the >>>>>>>> debugging) not knowing what is the real purpose of the case. >>>>>>>> >>>>>>>> >>>>>>>> in ct_result() function I changed the case _CS_RES_INIT: >>>>>>>> >>>>>>>> case _CS_RES_INIT: /* commalindlnd had no result set */ >>>>>>>> if (tds->rows_affected > 0) { >>>>>>>> *result_type = CS_CMD_DONE; >>>>>>>> cmd->results_state = _CS_RES_INIT; >>>>>>>> return CS_SUCCEED; >>>>>>>> } >>>>>>>> break; >>>>>>>> >>>>>>>> now it seems with the patch it works correctly. But I have no idea if >>>>>>>> it is really the correct way. >>>>>>>> >>>>>>>> Any ideas? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Ondrej >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 > > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > From david at qore.org Tue Oct 20 01:45:20 2015 From: david at qore.org (David Nichols) Date: Tue, 20 Oct 2015 07:45:20 +0200 Subject: [freetds] affected rows after insert In-Reply-To: References: <4AA5C8FC-111B-4F3B-9751-A9A19E226C6B@qore.org> Message-ID: On Oct 19, 2015, at 10:20 PM, Frediano Ziglio wrote: > > 2015-10-19 13:35 GMT+01:00 David Nichols : >> >>> On Oct 19, 2015, at 1:53 PM, Frediano Ziglio wrote: >>> >>> 2015-10-19 11:16 GMT+01:00 David Nichols : >>>> >>>>> On Oct 18, 2015, at 10:06 AM, Frediano Ziglio wrote: >>>>> >>>>> 2015-10-16 12:23 GMT+01:00 David Nichols : >>>>>>> 2015-06-09 14:48 GMT+01:00 Ondrej Holecek >: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I made a test with the same code but sybase lib and it works like >>>>>>>> expected. It seems there is a bug in FreeTDS. Could you please check >>>>>>>> my patch? >>>>>>>> >>>>>>>> thx, >>>>>>>> >>>>>>>> Ondrej >>>>>>>> >>>>>>> >>>>>>> Actually works and ctlib tests seems to pass. >>>>>>> >>>>>>> However DONEINPROC is returned in a lot of cases, for instance if >>>>>>> database execute some trigger on the table so your patch can catch >>>>>>> some strange results too. >>>>>>> >>>>>>> Which database version are you using? >>>>>>> >>>>>>> Frediano >>>>>> Hi, >>>>>> >>>>>> Ondra has not been working on this for quite some time, but I?d like to pick up this issue again please. >>>>>> >>>>>> We are using MS SQL Server 2008 - using tds version = 7.2 - with the patch we are able to get the affected rows reliably - without it, we are not. >>>>>> >>>>>> Using the same patched library build with a Sybase (SAP) ASE 16.0 DB, it also gives correct results (with tds version = 5.0) >>>>>> >>>>>> I would be happy to continue helping with this issue if there?s a chance it could be included in freetds (or some other equally effective fix). >>>>>> >>>>>> thanks, >>>>>> David >>>>>> >>>>> >>>>> A fix was written for this case. Do you still have some code that >>>>> fails? Did you update FreeTDS? >>>>> >>>>> Frediano >>>> >>>> yes, I tried it with freetds from freetds-0.95.12 and git master - both failed my tests and with the patch as provded by Ondra the tests then passed. Sorry I did not mention this in the original email. >>>> >>> >>> Please try a more recent version (like 0.95.21). Also you should sent >>> some extract of your tests. Can you post an updated patch? >>> >> sorry it was a typo on my side - it was 0.95.21 that I tried. Anyway since it failed in git master then I would assume that would be more relevant than the last stable release. >> >> Attached please find a patch to git master sources that makes my tests work. Please note that we are using ctlib from freetds to build a DBI driver for the Qore programming language to talk to SQL Server and Sybase DBs; the same source builds with both the sybae libs and ctlib from freetds. Currently my tests are written in the Qore programming language, so there are quite a few layers between the Qore code that?s executed and freetds?s ctlib. >> >> When this simple test works (ie only with a patch ctlib); the output looks like this: >> >> dnichols at manatee:~/src/qore/git/module-sybase/src$ simple-rows-affected-test.q >> "Microsoft SQL Server 2008 (RTM) - 10.0.1600.22 (X64) >> Jul 9 2008 14:17:44 >> Copyright (c) 1988-2008 Microsoft Corporation >> Developer Edition (64-bit) on Windows NT 6.1 (Build 7601: Service Pack 1)" >> insert: 1 >> n delete: 0 >> sel: {id: [1]} >> delete: 1 >> insert: 1 >> delete: 1 >> >> When it doesn?t work (ie with an unpatched ctlib), the output looks like this: >> dnichols at manatee:~/src/qore/git/module-sybase/src$ simple-rows-affected-test.q >> "Microsoft SQL Server 2008 (RTM) - 10.0.1600.22 (X64) >> Jul 9 2008 14:17:44 >> Copyright (c) 1988-2008 Microsoft Corporation >> Developer Edition (64-bit) on Windows NT 6.1 (Build 7601: Service Pack 1)" >> insert: 0 >> n delete: 0 >> sel: {id: [1]} >> delete: 0 >> insert: -1 >> delete: -1 >> >> The Qore source to this simple test is attached for your reference. >> > > I applied the patch and improved a test to catch this issue. I changed > the patch slightly to check for TDS_NO_COUNT instead of <0 and > returning CS_CMD_SUCCEEDED as ct_res_info documentation My test fails with your patch; if I change it back to: case _CS_RES_INIT: /* command had no result set */ if (tds->rows_affected != TDS_NO_COUNT) { *result_type = CS_CMD_DONE; cmd->results_state = _CS_RES_INIT; return CS_SUCCEED; } break; then it succeeds - please note that his is a hack from my side, I?m not saying that the original approach is correct, just that my test fails unless I set CS_CMD_DONE thx David > Frediano > >>>> BTW I had to comment out the reference to AM_ICONV in configure.ac to get freetds to build from git master on Linux >>>> >>> Quite odd. Could be you miss some package on your system. Which error >>> did you get? Could be you have an old autoconf package. >> >> I compiled it on fedora 22 with autocont 2.69. However I just did a search and found that AM_ICONV is installed with the gettext-devel package, which I?ve now installed, and now freetds from git master can be built without any hacks to configure.ac on Fedora. >> >> thx >> David >> >> >> >> >>> Frediano >>> >>>> thx >>>> David >>>> >>>> >>>>>>>> On Tue, Jun 2, 2015 at 10:49 AM, Ondrej Holecek >>>>>>>> > wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I have a problem obtaining number of affected rows while inserting. >>>>>>>>> The problem occurs when I pass the values by ct_param() call. >>>>>>>>> So, this command order works well: >>>>>>>>> >>>>>>>>> ct_cmd_alloc() >>>>>>>>> ct_command(CS_LANG_CMD, "INSERT INTO test (number) VALUES(5)") >>>>>>>>> ct_send() >>>>>>>>> ct_result() // the result type is CS_CMD_DONE so I can call... >>>>>>>>> ct_res_info(CS_ROW_COUNT) // as expected 1 row affected >>>>>>>>> >>>>>>>>> >>>>>>>>> but when I call it like this, It skips CS_CMD_DONE, so I can't read >>>>>>>>> the affected rows number. >>>>>>>>> >>>>>>>>> ct_cmd_alloc() >>>>>>>>> ct_command(CS_LANG_CMD, "INSERT INTO test (number) VALUES(@par1)") >>>>>>>>> ct_param("@par1", 1) >>>>>>>>> ct_send() >>>>>>>>> ct_result() // the result type is CS_END_RESULT >>>>>>>>> // can't do anything here :-( >>>>>>>>> >>>>>>>>> >>>>>>>>> The row is inserted in both cases correctly just in the second case I >>>>>>>>> can't read the number of affected rows. >>>>>>>>> >>>>>>>>> I did some ctlib debugging and I created the patch which would fix >>>>>>>>> this behavior. However, I just changed the code blindly (based on the >>>>>>>>> debugging) not knowing what is the real purpose of the case. >>>>>>>>> >>>>>>>>> >>>>>>>>> in ct_result() function I changed the case _CS_RES_INIT: >>>>>>>>> >>>>>>>>> case _CS_RES_INIT: /* commalindlnd had no result set */ >>>>>>>>> if (tds->rows_affected > 0) { >>>>>>>>> *result_type = CS_CMD_DONE; >>>>>>>>> cmd->results_state = _CS_RES_INIT; >>>>>>>>> return CS_SUCCEED; >>>>>>>>> } >>>>>>>>> break; >>>>>>>>> >>>>>>>>> now it seems with the patch it works correctly. But I have no idea if >>>>>>>>> it is really the correct way. >>>>>>>>> >>>>>>>>> Any ideas? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Ondrej >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >> >> >> _______________________________________________ >> 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 Oct 20 03:12:04 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Tue, 20 Oct 2015 08:12:04 +0100 Subject: [freetds] affected rows after insert In-Reply-To: References: <4AA5C8FC-111B-4F3B-9751-A9A19E226C6B@qore.org> Message-ID: Il 20/Ott/2015 09:09, "David Nichols" ha scritto: > > On Oct 19, 2015, at 10:20 PM, Frediano Ziglio wrote: > > > > 2015-10-19 13:35 GMT+01:00 David Nichols : > >> > >>> On Oct 19, 2015, at 1:53 PM, Frediano Ziglio wrote: > >>> > >>> 2015-10-19 11:16 GMT+01:00 David Nichols : > >>>> > >>>>> On Oct 18, 2015, at 10:06 AM, Frediano Ziglio wrote: > >>>>> > >>>>> 2015-10-16 12:23 GMT+01:00 David Nichols : > >>>>>>> 2015-06-09 14:48 GMT+01:00 Ondrej Holecek >: > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> I made a test with the same code but sybase lib and it works like > >>>>>>>> expected. It seems there is a bug in FreeTDS. Could you please check > >>>>>>>> my patch? > >>>>>>>> > >>>>>>>> thx, > >>>>>>>> > >>>>>>>> Ondrej > >>>>>>>> > >>>>>>> > >>>>>>> Actually works and ctlib tests seems to pass. > >>>>>>> > >>>>>>> However DONEINPROC is returned in a lot of cases, for instance if > >>>>>>> database execute some trigger on the table so your patch can catch > >>>>>>> some strange results too. > >>>>>>> > >>>>>>> Which database version are you using? > >>>>>>> > >>>>>>> Frediano > >>>>>> Hi, > >>>>>> > >>>>>> Ondra has not been working on this for quite some time, but I?d like to pick up this issue again please. > >>>>>> > >>>>>> We are using MS SQL Server 2008 - using tds version = 7.2 - with the patch we are able to get the affected rows reliably - without it, we are not. > >>>>>> > >>>>>> Using the same patched library build with a Sybase (SAP) ASE 16.0 DB, it also gives correct results (with tds version = 5.0) > >>>>>> > >>>>>> I would be happy to continue helping with this issue if there?s a chance it could be included in freetds (or some other equally effective fix). > >>>>>> > >>>>>> thanks, > >>>>>> David > >>>>>> > >>>>> > >>>>> A fix was written for this case. Do you still have some code that > >>>>> fails? Did you update FreeTDS? > >>>>> > >>>>> Frediano > >>>> > >>>> yes, I tried it with freetds from freetds-0.95.12 and git master - both failed my tests and with the patch as provded by Ondra the tests then passed. Sorry I did not mention this in the original email. > >>>> > >>> > >>> Please try a more recent version (like 0.95.21). Also you should sent > >>> some extract of your tests. Can you post an updated patch? > >>> > >> sorry it was a typo on my side - it was 0.95.21 that I tried. Anyway since it failed in git master then I would assume that would be more relevant than the last stable release. > >> > >> Attached please find a patch to git master sources that makes my tests work. Please note that we are using ctlib from freetds to build a DBI driver for the Qore programming language to talk to SQL Server and Sybase DBs; the same source builds with both the sybae libs and ctlib from freetds. Currently my tests are written in the Qore programming language, so there are quite a few layers between the Qore code that?s executed and freetds?s ctlib. > >> > >> When this simple test works (ie only with a patch ctlib); the output looks like this: > >> > >> dnichols at manatee:~/src/qore/git/module-sybase/src$ simple-rows-affected-test.q > >> "Microsoft SQL Server 2008 (RTM) - 10.0.1600.22 (X64) > >> Jul 9 2008 14:17:44 > >> Copyright (c) 1988-2008 Microsoft Corporation > >> Developer Edition (64-bit) on Windows NT 6.1 (Build 7601: Service Pack 1)" > >> insert: 1 > >> n delete: 0 > >> sel: {id: [1]} > >> delete: 1 > >> insert: 1 > >> delete: 1 > >> > >> When it doesn?t work (ie with an unpatched ctlib), the output looks like this: > >> dnichols at manatee:~/src/qore/git/module-sybase/src$ simple-rows-affected-test.q > >> "Microsoft SQL Server 2008 (RTM) - 10.0.1600.22 (X64) > >> Jul 9 2008 14:17:44 > >> Copyright (c) 1988-2008 Microsoft Corporation > >> Developer Edition (64-bit) on Windows NT 6.1 (Build 7601: Service Pack 1)" > >> insert: 0 > >> n delete: 0 > >> sel: {id: [1]} > >> delete: 0 > >> insert: -1 > >> delete: -1 > >> > >> The Qore source to this simple test is attached for your reference. > >> > > > > I applied the patch and improved a test to catch this issue. I changed > > the patch slightly to check for TDS_NO_COUNT instead of <0 and > > returning CS_CMD_SUCCEEDED as ct_res_info documentation > > My test fails with your patch; if I change it back to: > case _CS_RES_INIT: /* command had no result set */ > if (tds->rows_affected != TDS_NO_COUNT) { > *result_type = CS_CMD_DONE; > cmd->results_state = _CS_RES_INIT; > return CS_SUCCEED; > } > break; > > then it succeeds - please note that his is a hack from my side, I?m not saying that the original approach is correct, just that my test fails unless I set CS_CMD_DONE > > thx > David > Cs_cmd_succeeded is a valid value and is expected to have rows number attached so upper layer should handle it Frediano > > > Frediano > > > >>>> BTW I had to comment out the reference to AM_ICONV in configure.ac to get freetds to build from git master on Linux > >>>> > >>> Quite odd. Could be you miss some package on your system. Which error > >>> did you get? Could be you have an old autoconf package. > >> > >> I compiled it on fedora 22 with autocont 2.69. However I just did a search and found that AM_ICONV is installed with the gettext-devel package, which I?ve now installed, and now freetds from git master can be built without any hacks to configure.ac on Fedora. > >> > >> thx > >> David > >> > >> > >> > >> > >>> Frediano > >>> > >>>> thx > >>>> David > >>>> > >>>> > >>>>>>>> On Tue, Jun 2, 2015 at 10:49 AM, Ondrej Holecek > >>>>>>>> > wrote: > >>>>>>>>> Hi, > >>>>>>>>> > >>>>>>>>> I have a problem obtaining number of affected rows while inserting. > >>>>>>>>> The problem occurs when I pass the values by ct_param() call. > >>>>>>>>> So, this command order works well: > >>>>>>>>> > >>>>>>>>> ct_cmd_alloc() > >>>>>>>>> ct_command(CS_LANG_CMD, "INSERT INTO test (number) VALUES(5)") > >>>>>>>>> ct_send() > >>>>>>>>> ct_result() // the result type is CS_CMD_DONE so I can call... > >>>>>>>>> ct_res_info(CS_ROW_COUNT) // as expected 1 row affected > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> but when I call it like this, It skips CS_CMD_DONE, so I can't read > >>>>>>>>> the affected rows number. > >>>>>>>>> > >>>>>>>>> ct_cmd_alloc() > >>>>>>>>> ct_command(CS_LANG_CMD, "INSERT INTO test (number) VALUES(@par1)") > >>>>>>>>> ct_param("@par1", 1) > >>>>>>>>> ct_send() > >>>>>>>>> ct_result() // the result type is CS_END_RESULT > >>>>>>>>> // can't do anything here :-( > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> The row is inserted in both cases correctly just in the second case I > >>>>>>>>> can't read the number of affected rows. > >>>>>>>>> > >>>>>>>>> I did some ctlib debugging and I created the patch which would fix > >>>>>>>>> this behavior. However, I just changed the code blindly (based on the > >>>>>>>>> debugging) not knowing what is the real purpose of the case. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> in ct_result() function I changed the case _CS_RES_INIT: > >>>>>>>>> > >>>>>>>>> case _CS_RES_INIT: /* commalindlnd had no result set */ > >>>>>>>>> if (tds->rows_affected > 0) { > >>>>>>>>> *result_type = CS_CMD_DONE; > >>>>>>>>> cmd->results_state = _CS_RES_INIT; > >>>>>>>>> return CS_SUCCEED; > >>>>>>>>> } > >>>>>>>>> break; > >>>>>>>>> > >>>>>>>>> now it seems with the patch it works correctly. But I have no idea if > >>>>>>>>> it is really the correct way. > >>>>>>>>> > >>>>>>>>> Any ideas? > >>>>>>>>> > >>>>>>>>> Thanks, > >>>>>>>>> > >>>>>>>>> Ondrej > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> 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 > >> > >> > >> _______________________________________________ > >> 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 david at qore.org Tue Oct 20 05:17:50 2015 From: david at qore.org (David Nichols) Date: Tue, 20 Oct 2015 11:17:50 +0200 Subject: [freetds] affected rows after insert In-Reply-To: References: <4AA5C8FC-111B-4F3B-9751-A9A19E226C6B@qore.org> Message-ID: > On Oct 20, 2015, at 9:12 AM, Frediano Ziglio wrote: > > Il 20/Ott/2015 09:09, "David Nichols" ha scritto: >> >> On Oct 19, 2015, at 10:20 PM, Frediano Ziglio wrote: >>> >>> 2015-10-19 13:35 GMT+01:00 David Nichols : >>>> >>>>> On Oct 19, 2015, at 1:53 PM, Frediano Ziglio > wrote: >>>>> >>>>> 2015-10-19 11:16 GMT+01:00 David Nichols : >>>>>> >>>>>>> On Oct 18, 2015, at 10:06 AM, Frediano Ziglio > wrote: >>>>>>> >>>>>>> 2015-10-16 12:23 GMT+01:00 David Nichols : >>>>>>>>> 2015-06-09 14:48 GMT+01:00 Ondrej Holecek qoretechnologies.com >: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I made a test with the same code but sybase lib and it works like >>>>>>>>>> expected. It seems there is a bug in FreeTDS. Could you please > check >>>>>>>>>> my patch? >>>>>>>>>> >>>>>>>>>> thx, >>>>>>>>>> >>>>>>>>>> Ondrej >>>>>>>>>> >>>>>>>>> >>>>>>>>> Actually works and ctlib tests seems to pass. >>>>>>>>> >>>>>>>>> However DONEINPROC is returned in a lot of cases, for instance if >>>>>>>>> database execute some trigger on the table so your patch can catch >>>>>>>>> some strange results too. >>>>>>>>> >>>>>>>>> Which database version are you using? >>>>>>>>> >>>>>>>>> Frediano >>>>>>>> Hi, >>>>>>>> >>>>>>>> Ondra has not been working on this for quite some time, but I?d > like to pick up this issue again please. >>>>>>>> >>>>>>>> We are using MS SQL Server 2008 - using tds version = 7.2 - with > the patch we are able to get the affected rows reliably - without it, we > are not. >>>>>>>> >>>>>>>> Using the same patched library build with a Sybase (SAP) ASE 16.0 > DB, it also gives correct results (with tds version = 5.0) >>>>>>>> >>>>>>>> I would be happy to continue helping with this issue if there?s a > chance it could be included in freetds (or some other equally effective > fix). >>>>>>>> >>>>>>>> thanks, >>>>>>>> David >>>>>>>> >>>>>>> >>>>>>> A fix was written for this case. Do you still have some code that >>>>>>> fails? Did you update FreeTDS? >>>>>>> >>>>>>> Frediano >>>>>> >>>>>> yes, I tried it with freetds from freetds-0.95.12 and git master - > both failed my tests and with the patch as provded by Ondra the tests then > passed. Sorry I did not mention this in the original email. >>>>>> >>>>> >>>>> Please try a more recent version (like 0.95.21). Also you should sent >>>>> some extract of your tests. Can you post an updated patch? >>>>> >>>> sorry it was a typo on my side - it was 0.95.21 that I tried. Anyway > since it failed in git master then I would assume that would be more > relevant than the last stable release. >>>> >>>> Attached please find a patch to git master sources that makes my tests > work. Please note that we are using ctlib from freetds to build a DBI > driver for the Qore programming language to talk to SQL Server and Sybase > DBs; the same source builds with both the sybae libs and ctlib from > freetds. Currently my tests are written in the Qore programming language, > so there are quite a few layers between the Qore code that?s executed and > freetds?s ctlib. >>>> >>>> When this simple test works (ie only with a patch ctlib); the output > looks like this: >>>> >>>> dnichols at manatee:~/src/qore/git/module-sybase/src$ > simple-rows-affected-test.q >>>> "Microsoft SQL Server 2008 (RTM) - 10.0.1600.22 (X64) >>>> Jul 9 2008 14:17:44 >>>> Copyright (c) 1988-2008 Microsoft Corporation >>>> Developer Edition (64-bit) on Windows NT 6.1 (Build 7601: > Service Pack 1)" >>>> insert: 1 >>>> n delete: 0 >>>> sel: {id: [1]} >>>> delete: 1 >>>> insert: 1 >>>> delete: 1 >>>> >>>> When it doesn?t work (ie with an unpatched ctlib), the output looks > like this: >>>> dnichols at manatee:~/src/qore/git/module-sybase/src$ > simple-rows-affected-test.q >>>> "Microsoft SQL Server 2008 (RTM) - 10.0.1600.22 (X64) >>>> Jul 9 2008 14:17:44 >>>> Copyright (c) 1988-2008 Microsoft Corporation >>>> Developer Edition (64-bit) on Windows NT 6.1 (Build 7601: > Service Pack 1)" >>>> insert: 0 >>>> n delete: 0 >>>> sel: {id: [1]} >>>> delete: 0 >>>> insert: -1 >>>> delete: -1 >>>> >>>> The Qore source to this simple test is attached for your reference. >>>> >>> >>> I applied the patch and improved a test to catch this issue. I changed >>> the patch slightly to check for TDS_NO_COUNT instead of <0 and >>> returning CS_CMD_SUCCEEDED as ct_res_info documentation >> >> My test fails with your patch; if I change it back to: >> case _CS_RES_INIT: /* command had no > result set */ >> if (tds->rows_affected != > TDS_NO_COUNT) { >> *result_type = > CS_CMD_DONE; >> cmd->results_state = > _CS_RES_INIT; >> return CS_SUCCEED; >> } >> break; >> >> then it succeeds - please note that his is a hack from my side, I?m not > saying that the original approach is correct, just that my test fails > unless I set CS_CMD_DONE >> >> thx >> David >> > > Cs_cmd_succeeded is a valid value and is expected to have rows number > attached so upper layer should handle it OK, I see what you mean, however please note that with ctlib from Sybase/SAP ASE 16, I get the rows updated correctly with the same driver code as I use with freetds, and now it seems that I?ll need to update the driver to have a separate code path when it?s built with freetds - which seems to defeat the purpose of freetds?s ctlib. Is it not possible to fix this issue and provide 100% backwards-compatibility with Sybase?s ctlib? thx David > Frediano >> >>> Frediano >>> >>>>>> BTW I had to comment out the reference to AM_ICONV in configure.ac > to get freetds to build from git master on Linux >>>>>> >>>>> Quite odd. Could be you miss some package on your system. Which error >>>>> did you get? Could be you have an old autoconf package. >>>> >>>> I compiled it on fedora 22 with autocont 2.69. However I just did a > search and found that AM_ICONV is installed with the gettext-devel package, > which I?ve now installed, and now freetds from git master can be built > without any hacks to configure.ac on Fedora. >>>> >>>> thx >>>> David >>>> >>>> >>>> >>>> >>>>> Frediano >>>>> >>>>>> thx >>>>>> David >>>>>> >>>>>> >>>>>>>>>> On Tue, Jun 2, 2015 at 10:49 AM, Ondrej Holecek >>>>>>>>>> http://lists.ibiblio.org/mailman/listinfo/freetds>> wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> I have a problem obtaining number of affected rows while > inserting. >>>>>>>>>>> The problem occurs when I pass the values by ct_param() call. >>>>>>>>>>> So, this command order works well: >>>>>>>>>>> >>>>>>>>>>> ct_cmd_alloc() >>>>>>>>>>> ct_command(CS_LANG_CMD, "INSERT INTO test (number) VALUES(5)") >>>>>>>>>>> ct_send() >>>>>>>>>>> ct_result() // the result type is CS_CMD_DONE so I can call... >>>>>>>>>>> ct_res_info(CS_ROW_COUNT) // as expected 1 row affected >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> but when I call it like this, It skips CS_CMD_DONE, so I can't > read >>>>>>>>>>> the affected rows number. >>>>>>>>>>> >>>>>>>>>>> ct_cmd_alloc() >>>>>>>>>>> ct_command(CS_LANG_CMD, "INSERT INTO test (number) > VALUES(@par1)") >>>>>>>>>>> ct_param("@par1", 1) >>>>>>>>>>> ct_send() >>>>>>>>>>> ct_result() // the result type is CS_END_RESULT >>>>>>>>>>> // can't do anything here :-( >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The row is inserted in both cases correctly just in the second > case I >>>>>>>>>>> can't read the number of affected rows. >>>>>>>>>>> >>>>>>>>>>> I did some ctlib debugging and I created the patch which would > fix >>>>>>>>>>> this behavior. However, I just changed the code blindly (based > on the >>>>>>>>>>> debugging) not knowing what is the real purpose of the case. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> in ct_result() function I changed the case _CS_RES_INIT: >>>>>>>>>>> >>>>>>>>>>> case _CS_RES_INIT: /* commalindlnd had no result > set */ >>>>>>>>>>> if (tds->rows_affected > 0) { >>>>>>>>>>> *result_type = CS_CMD_DONE; >>>>>>>>>>> cmd->results_state = _CS_RES_INIT; >>>>>>>>>>> return CS_SUCCEED; >>>>>>>>>>> } >>>>>>>>>>> break; >>>>>>>>>>> >>>>>>>>>>> now it seems with the patch it works correctly. But I have no > idea if >>>>>>>>>>> it is really the correct way. >>>>>>>>>>> >>>>>>>>>>> Any ideas? >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Ondrej >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>> >>>> >>>> _______________________________________________ >>>> 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 hfreire at abajar.com Tue Oct 20 13:25:04 2015 From: hfreire at abajar.com (Hugo Freire) Date: Tue, 20 Oct 2015 19:25:04 +0200 Subject: [freetds] Freetds and Unicode In-Reply-To: <5616798C.6040309@abajar.com> References: <56164738.3050501@abajar.com> <5616798C.6040309@abajar.com> Message-ID: <562678F0.2020407@abajar.com> After investigating a little we have detected that data stored in nvarchar field in sql server 2008 is in UTF-16LE, but FreeTDS uses UCS-2LE to get the data, then freetds raises an exception because UCS-2LE only supports 2 bytes chars, and data stored has 4 bytes. echo -ne '?'| iconv -t utf-16le| hexdump -C works, but echo -ne '?'| iconv -t UCS-2LE hexdump -C raises "iconv: illegal input sequence at position 0" because this char is not in UCS-2LE. Are there any way to force to use UTF-16LE for the server charset? El 10/8/2015 a las 4:11 PM, Hugo Freire escribi?: > I'm testing it with last stable version freetds-0.95.20. > > Thanks, > Hugo > > El 10/8/2015 a las 2:29 PM, Igor Korot escribi?: >> Hi, >> >> On Thu, Oct 8, 2015 at 6:36 AM, Hugo Freire wrote: >>> Hi, >>> >>> I'm using Freetds from 4 years ago and works perfectly. Now we are >>> trying to >>> allow to store Unicode characters in sql server. >> Can you try the latest release? At least for testing purposes. >> 4 years ago binary is outdated. >> >> Thank you. >> >>> We have detected that we can store without problems any character >>> from first >>> plane of Basic Multilingual Plane >>> https://en.wikipedia.org/wiki/Plane_(Unicode)#Basic_Multilingual_Plane, >>> but >>> not able to store any character from other planes. >>> In the Freetds documentation I can read "At some future time, >>> FreeTDS aims >>> to support Unicode and other multi-byte character sets." >>> After making some tests, we was able to store all Unicode characters >>> using >>> "client charset ISO-8859-1". >>> Unfortunately we have an heterogeneous platform with windows and linux >>> systems connecting to the same data, so the data stored by Freetds >>> using >>> ISO-8859-1 can't be read by .net application for example. >>> >>> Our conclusion was that FreeTDS is unable to store all Unicode >>> characters in >>> SQL Server in UCS-2. >>> >>> Is it correct? >>> Are there any patch that allow to store all UCS-2 characters? >>> Is posible create a patch to allow this? >>> Can someone guide me to start to create this patch? >>> >>> Best regards, >>> Hugo >>> _______________________________________________ >>> 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 Wed Oct 21 03:53:24 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Wed, 21 Oct 2015 08:53:24 +0100 Subject: [freetds] Freetds and Unicode In-Reply-To: <562678F0.2020407@abajar.com> References: <56164738.3050501@abajar.com> <5616798C.6040309@abajar.com> <562678F0.2020407@abajar.com> Message-ID: 2015-10-20 18:25 GMT+01:00 Hugo Freire : > After investigating a little we have detected that data stored in nvarchar > field in sql server 2008 is in UTF-16LE, but FreeTDS uses UCS-2LE to get the > data, then freetds raises an exception because UCS-2LE only supports 2 bytes > chars, and data stored has 4 bytes. > > echo -ne '?'| iconv -t utf-16le| hexdump -C > > works, but > > echo -ne '?'| iconv -t UCS-2LE hexdump -C > > raises "iconv: illegal input sequence at position 0" because this char is > not in UCS-2LE. > > Are there any way to force to use UTF-16LE for the server charset? > > See "use utf-16" at http://www.freetds.org/userguide/freetdsconf.htm. Frediano > > > El 10/8/2015 a las 4:11 PM, Hugo Freire escribi?: >> >> I'm testing it with last stable version freetds-0.95.20. >> >> Thanks, >> Hugo >> >> El 10/8/2015 a las 2:29 PM, Igor Korot escribi?: >>> >>> Hi, >>> >>> On Thu, Oct 8, 2015 at 6:36 AM, Hugo Freire wrote: >>>> >>>> Hi, >>>> >>>> I'm using Freetds from 4 years ago and works perfectly. Now we are >>>> trying to >>>> allow to store Unicode characters in sql server. >>> >>> Can you try the latest release? At least for testing purposes. >>> 4 years ago binary is outdated. >>> >>> Thank you. >>> >>>> We have detected that we can store without problems any character from >>>> first >>>> plane of Basic Multilingual Plane >>>> https://en.wikipedia.org/wiki/Plane_(Unicode)#Basic_Multilingual_Plane, >>>> but >>>> not able to store any character from other planes. >>>> In the Freetds documentation I can read "At some future time, FreeTDS >>>> aims >>>> to support Unicode and other multi-byte character sets." >>>> After making some tests, we was able to store all Unicode characters >>>> using >>>> "client charset ISO-8859-1". >>>> Unfortunately we have an heterogeneous platform with windows and linux >>>> systems connecting to the same data, so the data stored by Freetds using >>>> ISO-8859-1 can't be read by .net application for example. >>>> >>>> Our conclusion was that FreeTDS is unable to store all Unicode >>>> characters in >>>> SQL Server in UCS-2. >>>> >>>> Is it correct? >>>> Are there any patch that allow to store all UCS-2 characters? >>>> Is posible create a patch to allow this? >>>> Can someone guide me to start to create this patch? >>>> >>>> Best regards, >>>> Hugo >>>> _______________________________________________ >>>> 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 hfreire at abajar.com Wed Oct 21 10:25:03 2015 From: hfreire at abajar.com (Hugo Freire) Date: Wed, 21 Oct 2015 16:25:03 +0200 Subject: [freetds] Freetds and Unicode In-Reply-To: References: <56164738.3050501@abajar.com> <5616798C.6040309@abajar.com> <562678F0.2020407@abajar.com> Message-ID: <5627A03F.6040302@abajar.com> Thanks Frediano!!!, this solve the problem. I think this information should be at this pages http://www.freetds.org/userguide/unicodefreetds.htm and http://www.freetds.org/userguide/localization.htm Hugo El 10/21/2015 a las 9:53 AM, Frediano Ziglio escribi?: > 2015-10-20 18:25 GMT+01:00 Hugo Freire : >> After investigating a little we have detected that data stored in nvarchar >> field in sql server 2008 is in UTF-16LE, but FreeTDS uses UCS-2LE to get the >> data, then freetds raises an exception because UCS-2LE only supports 2 bytes >> chars, and data stored has 4 bytes. >> >> echo -ne '?'| iconv -t utf-16le| hexdump -C >> >> works, but >> >> echo -ne '?'| iconv -t UCS-2LE hexdump -C >> >> raises "iconv: illegal input sequence at position 0" because this char is >> not in UCS-2LE. >> >> Are there any way to force to use UTF-16LE for the server charset? >> >> > See "use utf-16" at http://www.freetds.org/userguide/freetdsconf.htm. > > Frediano >> >> El 10/8/2015 a las 4:11 PM, Hugo Freire escribi?: >>> I'm testing it with last stable version freetds-0.95.20. >>> >>> Thanks, >>> Hugo >>> >>> El 10/8/2015 a las 2:29 PM, Igor Korot escribi?: >>>> Hi, >>>> >>>> On Thu, Oct 8, 2015 at 6:36 AM, Hugo Freire wrote: >>>>> Hi, >>>>> >>>>> I'm using Freetds from 4 years ago and works perfectly. Now we are >>>>> trying to >>>>> allow to store Unicode characters in sql server. >>>> Can you try the latest release? At least for testing purposes. >>>> 4 years ago binary is outdated. >>>> >>>> Thank you. >>>> >>>>> We have detected that we can store without problems any character from >>>>> first >>>>> plane of Basic Multilingual Plane >>>>> https://en.wikipedia.org/wiki/Plane_(Unicode)#Basic_Multilingual_Plane, >>>>> but >>>>> not able to store any character from other planes. >>>>> In the Freetds documentation I can read "At some future time, FreeTDS >>>>> aims >>>>> to support Unicode and other multi-byte character sets." >>>>> After making some tests, we was able to store all Unicode characters >>>>> using >>>>> "client charset ISO-8859-1". >>>>> Unfortunately we have an heterogeneous platform with windows and linux >>>>> systems connecting to the same data, so the data stored by Freetds using >>>>> ISO-8859-1 can't be read by .net application for example. >>>>> >>>>> Our conclusion was that FreeTDS is unable to store all Unicode >>>>> characters in >>>>> SQL Server in UCS-2. >>>>> >>>>> Is it correct? >>>>> Are there any patch that allow to store all UCS-2 characters? >>>>> Is posible create a patch to allow this? >>>>> Can someone guide me to start to create this patch? >>>>> >>>>> Best regards, >>>>> Hugo >>>>> _______________________________________________ >>>>> 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 Manasi.Deshpande at Renishaw.com Tue Oct 27 00:19:02 2015 From: Manasi.Deshpande at Renishaw.com (Manasi Deshpande) Date: Tue, 27 Oct 2015 04:19:02 +0000 Subject: [freetds] Help is appreciated! Message-ID: Hello, We are using FreeTDS driver to connect from Ubuntu to SQL Server on Windows. Of course we have unixodbc setup. SQLDescribeCol API returns wrong datatypes for BigInt as SQL_NUMERIC and SQL_TIMESTAMP_STRUCT as SQL_WVARCHAR. Are these issues already identified? Have they been fixed? If so please help me with FreeTDS versions to get! Thanks & Regards, Manasi Deshpande Renishaw Metrology Systems Ltd. Hinjewadi Phase -2 Pune -411057 * +91 2066746524 * Manasi.Deshpande at renishaw.com www.renishaw.com -------------------------------------------------------------------------------------------------- This email and any attachments are confidential and are for the use of the addressee only. If you are not the addressee, you must not use or disclose the contents to any other person. Please immediately notify the sender and delete the email. Statements and opinions expressed here may not represent those of the company. Email correspondence is monitored by the company. This information may be subject to export control regulation. You are obliged to comply with such regulations. Renishaw plc (company number 1106260) and Wotton Travel Limited (company number 01973158) are companies registered in England and Wales with a registered office at New Mills, Wotton-under-Edge, Gloucestershire, GL12 8JR, United Kingdom, Telephone +44 1453 524524. -------------------------------------------------------------------------------------------------- From freddy77 at gmail.com Tue Oct 27 16:01:26 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Tue, 27 Oct 2015 21:01:26 +0100 Subject: [freetds] Help is appreciated! In-Reply-To: References: Message-ID: 2015-10-27 5:19 GMT+01:00 Manasi Deshpande : > Hello, > > We are using FreeTDS driver to connect from Ubuntu to SQL Server on Windows. Of course we have unixodbc setup. > SQLDescribeCol API returns wrong datatypes for BigInt as SQL_NUMERIC and SQL_TIMESTAMP_STRUCT as SQL_WVARCHAR. Are these issues already identified? Have they been fixed? If so please help me with FreeTDS versions to get! > > Thanks & Regards, > > Manasi Deshpande > Renishaw Metrology Systems Ltd. > Hinjewadi Phase -2 > Pune -411057 > You are using the wrong protocol version. See http://www.freetds.org/userguide/choosingtdsprotocol.htm Frediano From james.k.lowden at icloud.com Wed Oct 28 12:22:25 2015 From: james.k.lowden at icloud.com (James K. Lowden) Date: Wed, 28 Oct 2015 12:22:25 -0400 Subject: [freetds] Help is appreciated! In-Reply-To: References: Message-ID: <20151028122225.386cc726.james.k.lowden@icloud.com> On Tue, 27 Oct 2015 21:01:26 +0100 Frediano Ziglio wrote: > > SQLDescribeCol API returns wrong datatypes for BigInt as > > SQL_NUMERIC and SQL_TIMESTAMP_STRUCT as SQL_WVARCHAR. Are these > > issues already identified? Have they been fixed? If so please help > > me with FreeTDS versions to get! > > You are using the wrong protocol version. See > http://www.freetds.org/userguide/choosingtdsprotocol.htm I offer the following as a new section for that page: [snip] Backward Compatibility Server Behavior Backward compatibility allows old clients to connect to new servers: The server supports the latest version (by definition) of the protocol, and accepts connections for all prior versions (even going back 10 years and more). One of the primary reasons to change the protocol is to support new datatypes on the server. New datatypes require new binary representations in the protocol. When an old client references a new datatype -- or when a new client uses an old version of the TDS protocol -- the server must do *something*. One option (not taken) would be to return an error to the effect that the client needs to be upgraded. Microsoft to its credit has consistently chosen the harder and better route: backward compatibility. The server represents the data in a form the client can recognize, regardless of its server-side definition. However, as is often the case, compatibility entails a loss of information. Representing a new type as an old one requires a compromise, losing some information along the way. For example, while TDS has long supported the DATETIME datatype, SQL Server 2008 (TDS 7.3) introduced the DATE and TIME datatypes. To transmit these types to the client, the protocol had to be expanded to include new identifiers for them and to define how their values would appear on the wire. Because DATE can include dates not representable by DATETIME, for old TDS versions the server converts DATE to VARCHAR. Usually, but not always, the server converts unsupported datatypes to VARCHAR strings. (All data can be represented as strings.) But not always: when TDS version 7.0 was introduced, old clients saw the new NUMERIC type converted to FLOAT. In every case the data are returned to the client using datatypes recognized by the protocol version the client is using. [Question: what happens when a new client connects to an old server? That should be answered here, but I would need to test it. I think the answer is, "nothing, it just works". I think the protocol is always modified by adding information, such that version N includes only new (not changed) information relative to version N-1. If correct, the server can accept connections from clients for protocol version >= N, because its use of N will be entirely valid as N+1, too. It just won't happen to support the new datatypes defined in N+1.] Programmer Advice For the programmer, backward compatibility means clients can be upgraded "as needed", not just because the server was upgraded. Anyone who's been through a server upgrade knows just how valuable that it. But it also means that as the server's new datatypes begin to be used, old clients will see those new types in converted form, as old types. If you want to make full use of the server's datatypes, use its highest supported TDS version. If the datatype returned to the client is not the one you expect given the defintion on the server, check the protocol version. Setting the TDSDUMP environment variable will generate a log with the protocol version near the top. The log also contains the TDS dataype for each column, as supplied by the server. It does *not* contain the server's conversion choice, if any, because that action is taken on the server and does not appear in the protocol. [pins] Humbly submitted, --jkl From ken at metaskills.net Mon Nov 2 20:25:55 2015 From: ken at metaskills.net (Ken Collins) Date: Mon, 2 Nov 2015 20:25:55 -0500 Subject: [freetds] v0.95.65 Session Busy Errors After Error Message-ID: This is a cross post from an issue filed on GitHub. Not sure which is preferred. https://github.com/FreeTDS/freetds/issues/30 This is in regards to the TinyTDS (Ruby C Extension) gem. Our dblib C code works fine for 0.91 but while testing v0.95 we get unusable connections after running an invalid SQL batch like?SELECT * FROM [foobar]. Error returned when trying to issue the next batch of SQL would be: The request failed to run because the batch is aborted, this can be caused by abort signal sent from client, or another request is running in the same session, which makes the session busy. Below is some dump output from v0.95.65. Any recommendations that stand out? dblib.c:1338:dbcmd(0x7fce5ab9bff0, SELECT * FROM [foobar]) dblib.c:1344:dbcmd() bufsz = 18 dblib.c:5845:dbfreebuf(0x7fce5ab9bff0) dblib.c:6817:dbsqlsend(0x7fce5ab9bff0) mem.c:648:tds_free_all_results() util.c:165:Changed query state from IDLE to WRITING util.c:165:Changed query state from WRITING to PENDING packet.c:740:Sending packet 0000 01 01 00 4a 00 00 01 00-16 00 00 00 12 00 00 00 |...J.... ........| 0010 02 00 00 00 00 00 00 00-00 00 01 00 00 00 53 00 |........ ......S.| 0020 45 00 4c 00 45 00 43 00-54 00 20 00 2a 00 20 00 |E.L.E.C. T. .*. .| 0030 46 00 52 00 4f 00 4d 00-20 00 5b 00 66 00 6f 00 |F.R.O.M. .[.f.o.| 0040 6f 00 62 00 61 00 72 00-5d 00 |o.b.a.r. ].| dblib.c:5743:dbgetuserdata(0x7fce5ab9bff0) dblib.c:5743:dbgetuserdata(0x7fce5ab9bff0) dblib.c:5743:dbgetuserdata(0x7fce5ab9bff0) dblib.c:5743:dbgetuserdata(0x7fce5ab9bff0) dblib.c:4625:dbsqlok(0x7fce5ab9bff0) dblib.c:4654:dbsqlok() not done, calling tds_process_tokens() token.c:549:tds_process_tokens(0x7fce5ab4ca90, 0x7fff5f584794, 0x7fff5f584790, 0x6914) util.c:165:Changed query state from PENDING to READING packet.c:639:Received packet 0000 04 01 00 6c 00 33 01 00-aa 54 00 d0 00 00 00 01 |...l.3.. ?T.?....| 0010 10 1d 00 49 00 6e 00 76-00 61 00 6c 00 69 00 64 |...I.n.v .a.l.i.d| 0020 00 20 00 6f 00 62 00 6a-00 65 00 63 00 74 00 20 |. .o.b.j .e.c.t. | 0030 00 6e 00 61 00 6d 00 65-00 20 00 27 00 66 00 6f |.n.a.m.e . .'.f.o| 0040 00 6f 00 62 00 61 00 72-00 27 00 2e 00 06 53 00 |.o.b.a.r .'....S.| 0050 53 00 32 00 30 00 31 00-34 00 00 01 00 00 00 fd |S.2.0.1. 4......?| 0060 02 00 fd 00 00 00 00 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:2344:tds_process_msg() reading message 208 from server token.c:2416:tds_process_msg() calling client msg handler dbutil.c:76:_dblib_handle_info_message(0x7fce5ab845d0, 0x7fce5ab4ca90, 0x7fff5f584620) dbutil.c:77:msgno 208: "Invalid object name 'foobar'." dblib.c:5743:dbgetuserdata(0x7fce5ab9bff0) dblib.c:4865:dbdead(0x7fce5ab9bff0) [alive] dblib.c:3203:dbcancel(0x7fce5ab9bff0) dblib.c:5743:dbgetuserdata(0x7fce5ab9bff0) token.c:2429:tds_process_msg() returning TDS_SUCCESS token.c:564:processing result tokens. marker is fd(DONE) token.c:2080:tds_process_end: more_results = 0 was_cancelled = 0 error = 1 done_count_valid = 0 token.c:2097: rows_affected = 0 token.c:2100:tds_process_end() state set to TDS_IDLE util.c:165:Changed query state from READING to IDLE util.c:83:logic error: cannot change query state from IDLE to PENDING util.c:165:Changed query state from IDLE to IDLE dblib.c:4687:dbsqlok() end status is FAIL dblib.c:5743:dbgetuserdata(0x7fce5ab9bff0) dblib.c:5743:dbgetuserdata(0x7fce5ab9bff0) dblib.c:4865:dbdead(0x7fce5ab9bff0) [alive] dblib.c:4625:dbsqlok(0x7fce5ab9bff0) dblib.c:4654:dbsqlok() not done, calling tds_process_tokens() token.c:549:tds_process_tokens(0x7fce5ab4ca90, 0x7fff5f5847b4, 0x7fff5f5847b0, 0x6914) token.c:552:tds_process_tokens() state is COMPLETED dblib.c:3203:dbcancel(0x7fce5ab9bff0) query.c:2186:tds_send_cancel: not in_cancel and idle From david at qore.org Tue Nov 3 06:56:50 2015 From: david at qore.org (David Nichols) Date: Tue, 3 Nov 2015 12:56:50 +0100 Subject: [freetds] affected rows after insert In-Reply-To: References: <4AA5C8FC-111B-4F3B-9751-A9A19E226C6B@qore.org> Message-ID: On Oct 20, 2015, at 11:17 AM, David Nichols wrote: > >> >> On Oct 20, 2015, at 9:12 AM, Frediano Ziglio wrote: >> >> Il 20/Ott/2015 09:09, "David Nichols" ha scritto: >>> >>> On Oct 19, 2015, at 10:20 PM, Frediano Ziglio wrote: >>>> >>>> 2015-10-19 13:35 GMT+01:00 David Nichols : >>>>> >>>>>> On Oct 19, 2015, at 1:53 PM, Frediano Ziglio >> wrote: >>>>>> >>>>>> 2015-10-19 11:16 GMT+01:00 David Nichols : >>>>>>> >>>>>>>> On Oct 18, 2015, at 10:06 AM, Frediano Ziglio >> wrote: >>>>>>>> >>>>>>>> 2015-10-16 12:23 GMT+01:00 David Nichols : >>>>>>>>>> 2015-06-09 14:48 GMT+01:00 Ondrej Holecek > qoretechnologies.com >: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> I made a test with the same code but sybase lib and it works like >>>>>>>>>>> expected. It seems there is a bug in FreeTDS. Could you please >> check >>>>>>>>>>> my patch? >>>>>>>>>>> >>>>>>>>>>> thx, >>>>>>>>>>> >>>>>>>>>>> Ondrej >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Actually works and ctlib tests seems to pass. >>>>>>>>>> >>>>>>>>>> However DONEINPROC is returned in a lot of cases, for instance if >>>>>>>>>> database execute some trigger on the table so your patch can catch >>>>>>>>>> some strange results too. >>>>>>>>>> >>>>>>>>>> Which database version are you using? >>>>>>>>>> >>>>>>>>>> Frediano >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Ondra has not been working on this for quite some time, but I?d >> like to pick up this issue again please. >>>>>>>>> >>>>>>>>> We are using MS SQL Server 2008 - using tds version = 7.2 - with >> the patch we are able to get the affected rows reliably - without it, we >> are not. >>>>>>>>> >>>>>>>>> Using the same patched library build with a Sybase (SAP) ASE 16.0 >> DB, it also gives correct results (with tds version = 5.0) >>>>>>>>> >>>>>>>>> I would be happy to continue helping with this issue if there?s a >> chance it could be included in freetds (or some other equally effective >> fix). >>>>>>>>> >>>>>>>>> thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>> >>>>>>>> A fix was written for this case. Do you still have some code that >>>>>>>> fails? Did you update FreeTDS? >>>>>>>> >>>>>>>> Frediano >>>>>>> >>>>>>> yes, I tried it with freetds from freetds-0.95.12 and git master - >> both failed my tests and with the patch as provded by Ondra the tests then >> passed. Sorry I did not mention this in the original email. >>>>>>> >>>>>> >>>>>> Please try a more recent version (like 0.95.21). Also you should sent >>>>>> some extract of your tests. Can you post an updated patch? >>>>>> >>>>> sorry it was a typo on my side - it was 0.95.21 that I tried. Anyway >> since it failed in git master then I would assume that would be more >> relevant than the last stable release. >>>>> >>>>> Attached please find a patch to git master sources that makes my tests >> work. Please note that we are using ctlib from freetds to build a DBI >> driver for the Qore programming language to talk to SQL Server and Sybase >> DBs; the same source builds with both the sybae libs and ctlib from >> freetds. Currently my tests are written in the Qore programming language, >> so there are quite a few layers between the Qore code that?s executed and >> freetds?s ctlib. >>>>> >>>>> When this simple test works (ie only with a patch ctlib); the output >> looks like this: >>>>> >>>>> dnichols at manatee:~/src/qore/git/module-sybase/src$ >> simple-rows-affected-test.q >>>>> "Microsoft SQL Server 2008 (RTM) - 10.0.1600.22 (X64) >>>>> Jul 9 2008 14:17:44 >>>>> Copyright (c) 1988-2008 Microsoft Corporation >>>>> Developer Edition (64-bit) on Windows NT 6.1 (Build 7601: >> Service Pack 1)" >>>>> insert: 1 >>>>> n delete: 0 >>>>> sel: {id: [1]} >>>>> delete: 1 >>>>> insert: 1 >>>>> delete: 1 >>>>> >>>>> When it doesn?t work (ie with an unpatched ctlib), the output looks >> like this: >>>>> dnichols at manatee:~/src/qore/git/module-sybase/src$ >> simple-rows-affected-test.q >>>>> "Microsoft SQL Server 2008 (RTM) - 10.0.1600.22 (X64) >>>>> Jul 9 2008 14:17:44 >>>>> Copyright (c) 1988-2008 Microsoft Corporation >>>>> Developer Edition (64-bit) on Windows NT 6.1 (Build 7601: >> Service Pack 1)" >>>>> insert: 0 >>>>> n delete: 0 >>>>> sel: {id: [1]} >>>>> delete: 0 >>>>> insert: -1 >>>>> delete: -1 >>>>> >>>>> The Qore source to this simple test is attached for your reference. >>>>> >>>> >>>> I applied the patch and improved a test to catch this issue. I changed >>>> the patch slightly to check for TDS_NO_COUNT instead of <0 and >>>> returning CS_CMD_SUCCEEDED as ct_res_info documentation >>> >>> My test fails with your patch; if I change it back to: >>> case _CS_RES_INIT: /* command had no >> result set */ >>> if (tds->rows_affected != >> TDS_NO_COUNT) { >>> *result_type = >> CS_CMD_DONE; >>> cmd->results_state = >> _CS_RES_INIT; >>> return CS_SUCCEED; >>> } >>> break; >>> >>> then it succeeds - please note that his is a hack from my side, I?m not >> saying that the original approach is correct, just that my test fails >> unless I set CS_CMD_DONE >>> >>> thx >>> David >>> >> >> Cs_cmd_succeeded is a valid value and is expected to have rows number >> attached so upper layer should handle it > > OK, I see what you mean, however please note that with ctlib from Sybase/SAP ASE 16, I get the rows updated correctly with the same driver code as I use with freetds, and now it seems that I?ll need to update the driver to have a separate code path when it?s built with freetds - which seems to defeat the purpose of freetds?s ctlib. Is it not possible to fix this issue and provide 100% backwards-compatibility with Sybase?s ctlib? > @Frediano: sorry to bother you with this issue, but since it?s important for me, can you please let me know about the above - should I plan on having 2 code paths in my DB driver - one for Sybase and one for FreeTDS, or should there ideally be a way that compatibility between Sybase?s ctlib and FreeTDS?s ctlib can be provided regarding this issue? thx David > thx > David > >> Frediano >>> >>>> Frediano >>>> >>>>>>> BTW I had to comment out the reference to AM_ICONV in configure.ac >> to get freetds to build from git master on Linux >>>>>>> >>>>>> Quite odd. Could be you miss some package on your system. Which error >>>>>> did you get? Could be you have an old autoconf package. >>>>> >>>>> I compiled it on fedora 22 with autocont 2.69. However I just did a >> search and found that AM_ICONV is installed with the gettext-devel package, >> which I?ve now installed, and now freetds from git master can be built >> without any hacks to configure.ac on Fedora. >>>>> >>>>> thx >>>>> David >>>>> >>>>> >>>>> >>>>> >>>>>> Frediano >>>>>> >>>>>>> thx >>>>>>> David >>>>>>> >>>>>>> >>>>>>>>>>> On Tue, Jun 2, 2015 at 10:49 AM, Ondrej Holecek >>>>>>>>>>> > http://lists.ibiblio.org/mailman/listinfo/freetds>> wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> I have a problem obtaining number of affected rows while >> inserting. >>>>>>>>>>>> The problem occurs when I pass the values by ct_param() call. >>>>>>>>>>>> So, this command order works well: >>>>>>>>>>>> >>>>>>>>>>>> ct_cmd_alloc() >>>>>>>>>>>> ct_command(CS_LANG_CMD, "INSERT INTO test (number) VALUES(5)") >>>>>>>>>>>> ct_send() >>>>>>>>>>>> ct_result() // the result type is CS_CMD_DONE so I can call... >>>>>>>>>>>> ct_res_info(CS_ROW_COUNT) // as expected 1 row affected >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> but when I call it like this, It skips CS_CMD_DONE, so I can't >> read >>>>>>>>>>>> the affected rows number. >>>>>>>>>>>> >>>>>>>>>>>> ct_cmd_alloc() >>>>>>>>>>>> ct_command(CS_LANG_CMD, "INSERT INTO test (number) >> VALUES(@par1)") >>>>>>>>>>>> ct_param("@par1", 1) >>>>>>>>>>>> ct_send() >>>>>>>>>>>> ct_result() // the result type is CS_END_RESULT >>>>>>>>>>>> // can't do anything here :-( >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> The row is inserted in both cases correctly just in the second >> case I >>>>>>>>>>>> can't read the number of affected rows. >>>>>>>>>>>> >>>>>>>>>>>> I did some ctlib debugging and I created the patch which would >> fix >>>>>>>>>>>> this behavior. However, I just changed the code blindly (based >> on the >>>>>>>>>>>> debugging) not knowing what is the real purpose of the case. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> in ct_result() function I changed the case _CS_RES_INIT: >>>>>>>>>>>> >>>>>>>>>>>> case _CS_RES_INIT: /* commalindlnd had no result >> set */ >>>>>>>>>>>> if (tds->rows_affected > 0) { >>>>>>>>>>>> *result_type = CS_CMD_DONE; >>>>>>>>>>>> cmd->results_state = _CS_RES_INIT; >>>>>>>>>>>> return CS_SUCCEED; >>>>>>>>>>>> } >>>>>>>>>>>> break; >>>>>>>>>>>> >>>>>>>>>>>> now it seems with the patch it works correctly. But I have no >> idea if >>>>>>>>>>>> it is really the correct way. >>>>>>>>>>>> >>>>>>>>>>>> Any ideas? >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> Ondrej >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 Wed Nov 4 14:48:52 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Wed, 4 Nov 2015 19:48:52 +0000 Subject: [freetds] v0.95.65 Session Busy Errors After Error In-Reply-To: References: Message-ID: 2015-11-03 1:25 GMT+00:00 Ken Collins : > This is a cross post from an issue filed on GitHub. Not sure which is preferred. > > https://github.com/FreeTDS/freetds/issues/30 > > This is in regards to the TinyTDS (Ruby C Extension) gem. Our dblib C code works fine for 0.91 but while testing v0.95 we get unusable connections after running an invalid SQL batch like SELECT * FROM [foobar]. Error returned when trying to issue the next batch of SQL would be: > > The request failed to run because the batch is aborted, this can be caused by abort signal sent from client, or another request is running in the same session, which makes the session busy. > Below is some dump output from v0.95.65. Any recommendations that stand out? > > dblib.c:1338:dbcmd(0x7fce5ab9bff0, SELECT * FROM [foobar]) > dblib.c:1344:dbcmd() bufsz = 18 > dblib.c:5845:dbfreebuf(0x7fce5ab9bff0) > dblib.c:6817:dbsqlsend(0x7fce5ab9bff0) > mem.c:648:tds_free_all_results() > util.c:165:Changed query state from IDLE to WRITING > util.c:165:Changed query state from WRITING to PENDING > packet.c:740:Sending packet > 0000 01 01 00 4a 00 00 01 00-16 00 00 00 12 00 00 00 |...J.... ........| > 0010 02 00 00 00 00 00 00 00-00 00 01 00 00 00 53 00 |........ ......S.| > 0020 45 00 4c 00 45 00 43 00-54 00 20 00 2a 00 20 00 |E.L.E.C. T. .*. .| > 0030 46 00 52 00 4f 00 4d 00-20 00 5b 00 66 00 6f 00 |F.R.O.M. .[.f.o.| > 0040 6f 00 62 00 61 00 72 00-5d 00 |o.b.a.r. ].| > > dblib.c:5743:dbgetuserdata(0x7fce5ab9bff0) > dblib.c:5743:dbgetuserdata(0x7fce5ab9bff0) > dblib.c:5743:dbgetuserdata(0x7fce5ab9bff0) > dblib.c:5743:dbgetuserdata(0x7fce5ab9bff0) > dblib.c:4625:dbsqlok(0x7fce5ab9bff0) > dblib.c:4654:dbsqlok() not done, calling tds_process_tokens() > token.c:549:tds_process_tokens(0x7fce5ab4ca90, 0x7fff5f584794, 0x7fff5f584790, 0x6914) > util.c:165:Changed query state from PENDING to READING > packet.c:639:Received packet > 0000 04 01 00 6c 00 33 01 00-aa 54 00 d0 00 00 00 01 |...l.3.. ?T.?....| > 0010 10 1d 00 49 00 6e 00 76-00 61 00 6c 00 69 00 64 |...I.n.v .a.l.i.d| > 0020 00 20 00 6f 00 62 00 6a-00 65 00 63 00 74 00 20 |. .o.b.j .e.c.t. | > 0030 00 6e 00 61 00 6d 00 65-00 20 00 27 00 66 00 6f |.n.a.m.e . .'.f.o| > 0040 00 6f 00 62 00 61 00 72-00 27 00 2e 00 06 53 00 |.o.b.a.r .'....S.| > 0050 53 00 32 00 30 00 31 00-34 00 00 01 00 00 00 fd |S.2.0.1. 4......?| > 0060 02 00 fd 00 00 00 00 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:2344:tds_process_msg() reading message 208 from server > token.c:2416:tds_process_msg() calling client msg handler > dbutil.c:76:_dblib_handle_info_message(0x7fce5ab845d0, 0x7fce5ab4ca90, 0x7fff5f584620) > dbutil.c:77:msgno 208: "Invalid object name 'foobar'." > dblib.c:5743:dbgetuserdata(0x7fce5ab9bff0) > dblib.c:4865:dbdead(0x7fce5ab9bff0) [alive] > dblib.c:3203:dbcancel(0x7fce5ab9bff0) > dblib.c:5743:dbgetuserdata(0x7fce5ab9bff0) > token.c:2429:tds_process_msg() returning TDS_SUCCESS > token.c:564:processing result tokens. marker is fd(DONE) > token.c:2080:tds_process_end: more_results = 0 > was_cancelled = 0 > error = 1 > done_count_valid = 0 > token.c:2097: rows_affected = 0 > token.c:2100:tds_process_end() state set to TDS_IDLE > util.c:165:Changed query state from READING to IDLE > util.c:83:logic error: cannot change query state from IDLE to PENDING > util.c:165:Changed query state from IDLE to IDLE > dblib.c:4687:dbsqlok() end status is FAIL > dblib.c:5743:dbgetuserdata(0x7fce5ab9bff0) > dblib.c:5743:dbgetuserdata(0x7fce5ab9bff0) > dblib.c:4865:dbdead(0x7fce5ab9bff0) [alive] > dblib.c:4625:dbsqlok(0x7fce5ab9bff0) > dblib.c:4654:dbsqlok() not done, calling tds_process_tokens() > token.c:549:tds_process_tokens(0x7fce5ab4ca90, 0x7fff5f5847b4, 0x7fff5f5847b0, 0x6914) > token.c:552:tds_process_tokens() state is COMPLETED > dblib.c:3203:dbcancel(0x7fce5ab9bff0) > query.c:2186:tds_send_cancel: not in_cancel and idle I don't see nothing special in the log. A wrong query is sent. An error is generated from the server. A cancel is sent. I cannot see what happen after the cancel. Does the client process the cancel? Do you have a log from 0.91 ? Frediano From freddy77 at gmail.com Sat Nov 7 06:47:59 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Sat, 7 Nov 2015 11:47:59 +0000 Subject: [freetds] v0.95.65 Session Busy Errors After Error In-Reply-To: References: Message-ID: 2015-11-04 21:01 GMT+00:00 Ken Collins : > 2015-11-03 1:25 GMT+00:00 Ken Collins : >> This is a cross post from an issue filed on GitHub. Not sure which is >> preferred. >> >> https://github.com/FreeTDS/freetds/issues/30 > > I don't see nothing special in the log. A wrong query is sent. An > error is generated from the server. A cancel is sent. I cannot see > what happen after the cancel. Does the client process the cancel? Do > you have a log from 0.91 ? > > Thanks for the read thru and reply. I really did try to provide a 0.91 dump > file but for some reason it never generated more than two lines in the file. > > From the 0.95 perspective, here are two gist links of dump output > immediately after the error dump previously mentioned. Both execute a simple > `SELECT 1 AS [one]` to test the client state. > > DEBUG-0.95.65-nextquery1.log - > https://gist.github.com/metaskills/a07f213e14281b42695d > > DEBUG-0.95.65-nextquery2.log - > https://gist.github.com/metaskills/35aa3f9e0119f137c2b4 > > I feel there may be an answer in these two. Gonna scan over them now and > think about it. Help appreciated! > Really interesting. Looks like the cancel is not sent directly but queued and later sent after the query. This make the query fail. Looks like the cancellation is not processed correctly for some reason. I'll have a look at what happen in the program. Frediano From freddy77 at gmail.com Sat Nov 7 08:25:36 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Sat, 7 Nov 2015 13:25:36 +0000 Subject: [freetds] v0.95.65 Session Busy Errors After Error In-Reply-To: References: Message-ID: 2015-11-07 11:47 GMT+00:00 Frediano Ziglio : > 2015-11-04 21:01 GMT+00:00 Ken Collins : >> 2015-11-03 1:25 GMT+00:00 Ken Collins : >>> This is a cross post from an issue filed on GitHub. Not sure which is >>> preferred. >>> >>> https://github.com/FreeTDS/freetds/issues/30 >> >> I don't see nothing special in the log. A wrong query is sent. An >> error is generated from the server. A cancel is sent. I cannot see >> what happen after the cancel. Does the client process the cancel? Do >> you have a log from 0.91 ? >> >> Thanks for the read thru and reply. I really did try to provide a 0.91 dump >> file but for some reason it never generated more than two lines in the file. >> >> From the 0.95 perspective, here are two gist links of dump output >> immediately after the error dump previously mentioned. Both execute a simple >> `SELECT 1 AS [one]` to test the client state. >> >> DEBUG-0.95.65-nextquery1.log - >> https://gist.github.com/metaskills/a07f213e14281b42695d >> >> DEBUG-0.95.65-nextquery2.log - >> https://gist.github.com/metaskills/35aa3f9e0119f137c2b4 >> >> I feel there may be an answer in these two. Gonna scan over them now and >> think about it. Help appreciated! >> > > > Really interesting. Looks like the cancel is not sent directly but > queued and later sent after the query. This make the query fail. Looks > like the cancellation is not processed correctly for some reason. > I'll have a look at what happen in the program. > Got it! Is not the cancel after the query but the cancel from the message handler. In this case a cancel is set but not reset causing it to be registered for the next query. Not hard to fix, time to write a new test (or extend another) Frediano From freddy77 at gmail.com Sat Nov 7 13:01:22 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Sat, 7 Nov 2015 18:01:22 +0000 Subject: [freetds] affected rows after insert In-Reply-To: References: <4AA5C8FC-111B-4F3B-9751-A9A19E226C6B@qore.org> Message-ID: 2015-11-03 11:56 GMT+00:00 David Nichols : > On Oct 20, 2015, at 11:17 AM, David Nichols wrote: >> >>> >>> On Oct 20, 2015, at 9:12 AM, Frediano Ziglio wrote: >>> >>> Il 20/Ott/2015 09:09, "David Nichols" ha scritto: >>>> >>>> On Oct 19, 2015, at 10:20 PM, Frediano Ziglio wrote: >>>>> >>>>> 2015-10-19 13:35 GMT+01:00 David Nichols : >>>>>> >>>>>>> On Oct 19, 2015, at 1:53 PM, Frediano Ziglio >>> wrote: >>>>>>> >>>>>>> 2015-10-19 11:16 GMT+01:00 David Nichols : >>>>>>>> >>>>>>>>> On Oct 18, 2015, at 10:06 AM, Frediano Ziglio >>> wrote: >>>>>>>>> >>>>>>>>> 2015-10-16 12:23 GMT+01:00 David Nichols : >>>>>>>>>>> 2015-06-09 14:48 GMT+01:00 Ondrej Holecek >> qoretechnologies.com >: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> I made a test with the same code but sybase lib and it works like >>>>>>>>>>>> expected. It seems there is a bug in FreeTDS. Could you please >>> check >>>>>>>>>>>> my patch? >>>>>>>>>>>> >>>>>>>>>>>> thx, >>>>>>>>>>>> >>>>>>>>>>>> Ondrej >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Actually works and ctlib tests seems to pass. >>>>>>>>>>> >>>>>>>>>>> However DONEINPROC is returned in a lot of cases, for instance if >>>>>>>>>>> database execute some trigger on the table so your patch can catch >>>>>>>>>>> some strange results too. >>>>>>>>>>> >>>>>>>>>>> Which database version are you using? >>>>>>>>>>> >>>>>>>>>>> Frediano >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Ondra has not been working on this for quite some time, but I?d >>> like to pick up this issue again please. >>>>>>>>>> >>>>>>>>>> We are using MS SQL Server 2008 - using tds version = 7.2 - with >>> the patch we are able to get the affected rows reliably - without it, we >>> are not. >>>>>>>>>> >>>>>>>>>> Using the same patched library build with a Sybase (SAP) ASE 16.0 >>> DB, it also gives correct results (with tds version = 5.0) >>>>>>>>>> >>>>>>>>>> I would be happy to continue helping with this issue if there?s a >>> chance it could be included in freetds (or some other equally effective >>> fix). >>>>>>>>>> >>>>>>>>>> thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>> >>>>>>>>> A fix was written for this case. Do you still have some code that >>>>>>>>> fails? Did you update FreeTDS? >>>>>>>>> >>>>>>>>> Frediano >>>>>>>> >>>>>>>> yes, I tried it with freetds from freetds-0.95.12 and git master - >>> both failed my tests and with the patch as provded by Ondra the tests then >>> passed. Sorry I did not mention this in the original email. >>>>>>>> >>>>>>> >>>>>>> Please try a more recent version (like 0.95.21). Also you should sent >>>>>>> some extract of your tests. Can you post an updated patch? >>>>>>> >>>>>> sorry it was a typo on my side - it was 0.95.21 that I tried. Anyway >>> since it failed in git master then I would assume that would be more >>> relevant than the last stable release. >>>>>> >>>>>> Attached please find a patch to git master sources that makes my tests >>> work. Please note that we are using ctlib from freetds to build a DBI >>> driver for the Qore programming language to talk to SQL Server and Sybase >>> DBs; the same source builds with both the sybae libs and ctlib from >>> freetds. Currently my tests are written in the Qore programming language, >>> so there are quite a few layers between the Qore code that?s executed and >>> freetds?s ctlib. >>>>>> >>>>>> When this simple test works (ie only with a patch ctlib); the output >>> looks like this: >>>>>> >>>>>> dnichols at manatee:~/src/qore/git/module-sybase/src$ >>> simple-rows-affected-test.q >>>>>> "Microsoft SQL Server 2008 (RTM) - 10.0.1600.22 (X64) >>>>>> Jul 9 2008 14:17:44 >>>>>> Copyright (c) 1988-2008 Microsoft Corporation >>>>>> Developer Edition (64-bit) on Windows NT 6.1 (Build 7601: >>> Service Pack 1)" >>>>>> insert: 1 >>>>>> n delete: 0 >>>>>> sel: {id: [1]} >>>>>> delete: 1 >>>>>> insert: 1 >>>>>> delete: 1 >>>>>> >>>>>> When it doesn?t work (ie with an unpatched ctlib), the output looks >>> like this: >>>>>> dnichols at manatee:~/src/qore/git/module-sybase/src$ >>> simple-rows-affected-test.q >>>>>> "Microsoft SQL Server 2008 (RTM) - 10.0.1600.22 (X64) >>>>>> Jul 9 2008 14:17:44 >>>>>> Copyright (c) 1988-2008 Microsoft Corporation >>>>>> Developer Edition (64-bit) on Windows NT 6.1 (Build 7601: >>> Service Pack 1)" >>>>>> insert: 0 >>>>>> n delete: 0 >>>>>> sel: {id: [1]} >>>>>> delete: 0 >>>>>> insert: -1 >>>>>> delete: -1 >>>>>> >>>>>> The Qore source to this simple test is attached for your reference. >>>>>> >>>>> >>>>> I applied the patch and improved a test to catch this issue. I changed >>>>> the patch slightly to check for TDS_NO_COUNT instead of <0 and >>>>> returning CS_CMD_SUCCEEDED as ct_res_info documentation >>>> >>>> My test fails with your patch; if I change it back to: >>>> case _CS_RES_INIT: /* command had no >>> result set */ >>>> if (tds->rows_affected != >>> TDS_NO_COUNT) { >>>> *result_type = >>> CS_CMD_DONE; >>>> cmd->results_state = >>> _CS_RES_INIT; >>>> return CS_SUCCEED; >>>> } >>>> break; >>>> >>>> then it succeeds - please note that his is a hack from my side, I?m not >>> saying that the original approach is correct, just that my test fails >>> unless I set CS_CMD_DONE >>>> >>>> thx >>>> David >>>> >>> >>> Cs_cmd_succeeded is a valid value and is expected to have rows number >>> attached so upper layer should handle it >> >> OK, I see what you mean, however please note that with ctlib from Sybase/SAP ASE 16, I get the rows updated correctly with the same driver code as I use with freetds, and now it seems that I?ll need to update the driver to have a separate code path when it?s built with freetds - which seems to defeat the purpose of freetds?s ctlib. Is it not possible to fix this issue and provide 100% backwards-compatibility with Sybase?s ctlib? >> > > @Frediano: sorry to bother you with this issue, but since it?s important for me, can you please let me know about the above - should I plan on having 2 code paths in my DB driver - one for Sybase and one for FreeTDS, or should there ideally be a way that compatibility between Sybase?s ctlib and FreeTDS?s ctlib can be provided regarding this issue? > > thx > David > Yes, it's possible. But as said is not that easy. They way query is sent is actually different. Also it could break some compatibility. I think this however should be addressed for next release (which I hope will be before next year). I added a note in my TODO list (https://trello.com/b/bk0UZNRJ/freetds-todo-list) Frediano From ken at metaskills.net Mon Nov 9 20:49:08 2015 From: ken at metaskills.net (Ken Collins) Date: Mon, 9 Nov 2015 20:49:08 -0500 Subject: [freetds] v0.95.67 Corrupt Packets After - Error converting characters into server's character set. Message-ID: One more final error when testing the Ruby C-extensions to FreeTDS.? We have a test that tests usage of the client after inserting invalid characters. INSERT INTO [datatypes] ([nvarchar_50]) VALUES ('Test ?') After handling the message, the followup `SELECT 1 AS [one]` test query returns: Incorrect syntax near '3' When examine the TDSDUMP file, it seems there is some garbage in the packets. Thoughts? dblib.c:1338:dbcmd(0x7fca058a4f60, INSERT INTO [datatypes] ([nvarchar_50]) VALUES ('Test ???')) dblib.c:1344:dbcmd() bufsz = 56 dblib.c:5845:dbfreebuf(0x7fca058a4f60) dblib.c:6817:dbsqlsend(0x7fca058a4f60) mem.c:648:tds_free_all_results() util.c:165:Changed query state from IDLE to WRITING util.c:322:tdserror(0x7fca046f4a80, 0x7fca044b0240, 2402, 0) dblib.c:7897:dbperror(0x7fca058a4f60, 2402, 0) dblib.c:7965:dbperror: Calling dblib_err_handler with msgno = 2402; msg->msgtext = "Error converting characters into server's character set. Some character(s) could not be converted" dblib.c:5743:dbgetuserdata(0x7fca058a4f60) dblib.c:5845:dbfreebuf(0x7fca058a4f60) dblib.c:5743:dbgetuserdata(0x7fca058a4f60) dblib.c:1338:dbcmd(0x7fca058a4f60, SELECT 1 AS [one]) dblib.c:1344:dbcmd() bufsz = 0 dblib.c:6817:dbsqlsend(0x7fca058a4f60) util.c:165:Changed query state from WRITING to PENDING packet.c:740:Sending packet 0000 01 01 00 56 00 00 01 00-16 00 00 00 12 00 00 00 |...V.... ........| 0010 02 00 01 00 00 00 33 00-00 00 01 00 00 00 16 00 |......3. ........| 0020 00 00 12 00 00 00 02 00-01 00 00 00 33 00 00 00 |........ ....3...| 0030 01 00 00 00 53 00 45 00-4c 00 45 00 43 00 54 00 |....S.E. L.E.C.T.| 0040 20 00 31 00 20 00 41 00-53 00 20 00 5b 00 6f 00 | .1. .A. S. .[.o.| 0050 6e 00 65 00 5d 00 ? ? ?- ? ? ? ? ? ? ? ? ? ? ? ?|n.e.].| dblib.c:5743:dbgetuserdata(0x7fca058a4f60) dblib.c:5743:dbgetuserdata(0x7fca058a4f60) dblib.c:5743:dbgetuserdata(0x7fca058a4f60) dblib.c:5743:dbgetuserdata(0x7fca058a4f60) dblib.c:4625:dbsqlok(0x7fca058a4f60) dblib.c:4654:dbsqlok() not done, calling tds_process_tokens() token.c:549:tds_process_tokens(0x7fca044b0240, 0x7fff5b414fd4, 0x7fff5b414fd0, 0x6914) util.c:165:Changed query state from PENDING to READING packet.c:639:Received packet 0000 04 01 00 66 00 33 01 00-aa 4e 00 66 00 00 00 01 |...f.3.. ?N.f....| 0010 0f 1a 00 49 00 6e 00 63-00 6f 00 72 00 72 00 65 |...I.n.c .o.r.r.e| 0020 00 63 00 74 00 20 00 73-00 79 00 6e 00 74 00 61 |.c.t. .s .y.n.t.a| 0030 00 78 00 20 00 6e 00 65-00 61 00 72 00 20 00 27 |.x. .n.e .a.r. .'| 0040 00 33 00 27 00 2e 00 06-53 00 53 00 32 00 30 00 |.3.'.... S.S.2.0.| 0050 31 00 34 00 00 01 00 00-00 fd 02 00 fd 00 00 00 |1.4..... .?..?...| 0060 00 00 00 00 00 00 ? ? ?- ? ? ? ? ? ? ? ? ? ? ? ?|......| From ken at metaskills.net Mon Nov 9 20:53:13 2015 From: ken at metaskills.net (Ken Collins) Date: Mon, 9 Nov 2015 20:53:13 -0500 Subject: [freetds] v0.95.67 Corrupt Packets After - Error converting characters into server's character set. In-Reply-To: References: Message-ID: Also, I just noticed this only happens when TDSVER='7.3'. It does not appear under TDSVER='7.1'. ?- Ken On November 9, 2015 at 8:49:10 PM, Ken Collins (ken at metaskills.net) wrote: One more final error when testing the Ruby C-extensions to FreeTDS.? We have a test that tests usage of the client after inserting invalid characters. INSERT INTO [datatypes] ([nvarchar_50]) VALUES ('Test ?') After handling the message, the followup `SELECT 1 AS [one]` test query returns: Incorrect syntax near '3' When examine the TDSDUMP file, it seems there is some garbage in the packets. Thoughts? dblib.c:1338:dbcmd(0x7fca058a4f60, INSERT INTO [datatypes] ([nvarchar_50]) VALUES ('Test ???')) dblib.c:1344:dbcmd() bufsz = 56 dblib.c:5845:dbfreebuf(0x7fca058a4f60) dblib.c:6817:dbsqlsend(0x7fca058a4f60) mem.c:648:tds_free_all_results() util.c:165:Changed query state from IDLE to WRITING util.c:322:tdserror(0x7fca046f4a80, 0x7fca044b0240, 2402, 0) dblib.c:7897:dbperror(0x7fca058a4f60, 2402, 0) dblib.c:7965:dbperror: Calling dblib_err_handler with msgno = 2402; msg->msgtext = "Error converting characters into server's character set. Some character(s) could not be converted" dblib.c:5743:dbgetuserdata(0x7fca058a4f60) dblib.c:5845:dbfreebuf(0x7fca058a4f60) dblib.c:5743:dbgetuserdata(0x7fca058a4f60) dblib.c:1338:dbcmd(0x7fca058a4f60, SELECT 1 AS [one]) dblib.c:1344:dbcmd() bufsz = 0 dblib.c:6817:dbsqlsend(0x7fca058a4f60) util.c:165:Changed query state from WRITING to PENDING packet.c:740:Sending packet 0000 01 01 00 56 00 00 01 00-16 00 00 00 12 00 00 00 |...V.... ........| 0010 02 00 01 00 00 00 33 00-00 00 01 00 00 00 16 00 |......3. ........| 0020 00 00 12 00 00 00 02 00-01 00 00 00 33 00 00 00 |........ ....3...| 0030 01 00 00 00 53 00 45 00-4c 00 45 00 43 00 54 00 |....S.E. L.E.C.T.| 0040 20 00 31 00 20 00 41 00-53 00 20 00 5b 00 6f 00 | .1. .A. S. .[.o.| 0050 6e 00 65 00 5d 00 ? ? ?- ? ? ? ? ? ? ? ? ? ? ? ?|n.e.].| dblib.c:5743:dbgetuserdata(0x7fca058a4f60) dblib.c:5743:dbgetuserdata(0x7fca058a4f60) dblib.c:5743:dbgetuserdata(0x7fca058a4f60) dblib.c:5743:dbgetuserdata(0x7fca058a4f60) dblib.c:4625:dbsqlok(0x7fca058a4f60) dblib.c:4654:dbsqlok() not done, calling tds_process_tokens() token.c:549:tds_process_tokens(0x7fca044b0240, 0x7fff5b414fd4, 0x7fff5b414fd0, 0x6914) util.c:165:Changed query state from PENDING to READING packet.c:639:Received packet 0000 04 01 00 66 00 33 01 00-aa 4e 00 66 00 00 00 01 |...f.3.. ?N.f....| 0010 0f 1a 00 49 00 6e 00 63-00 6f 00 72 00 72 00 65 |...I.n.c .o.r.r.e| 0020 00 63 00 74 00 20 00 73-00 79 00 6e 00 74 00 61 |.c.t. .s .y.n.t.a| 0030 00 78 00 20 00 6e 00 65-00 61 00 72 00 20 00 27 |.x. .n.e .a.r. .'| 0040 00 33 00 27 00 2e 00 06-53 00 53 00 32 00 30 00 |.3.'.... S.S.2.0.| 0050 31 00 34 00 00 01 00 00-00 fd 02 00 fd 00 00 00 |1.4..... .?..?...| 0060 00 00 00 00 00 00 ? ? ?- ? ? ? ? ? ? ? ? ? ? ? ?|......| From no-reply at appveyor.com Wed Nov 11 13:38:22 2015 From: no-reply at appveyor.com (AppVeyor) Date: Wed, 11 Nov 2015 18:38:22 +0000 Subject: [freetds] Build failed: freetds 292 Message-ID: <20151111183821.58419.83135@appveyor.com> From freddy77 at gmail.com Wed Nov 11 14:54:18 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Wed, 11 Nov 2015 19:54:18 +0000 Subject: [freetds] affected rows after insert In-Reply-To: References: <4AA5C8FC-111B-4F3B-9751-A9A19E226C6B@qore.org> Message-ID: 2015-11-03 11:56 GMT+00:00 David Nichols : > On Oct 20, 2015, at 11:17 AM, David Nichols wrote: >> >>> >>> On Oct 20, 2015, at 9:12 AM, Frediano Ziglio wrote: >>> >>> Il 20/Ott/2015 09:09, "David Nichols" ha scritto: >>>> >>>> On Oct 19, 2015, at 10:20 PM, Frediano Ziglio wrote: >>>>> >>>>> 2015-10-19 13:35 GMT+01:00 David Nichols : >>>>>> >>>>>>> On Oct 19, 2015, at 1:53 PM, Frediano Ziglio >>> wrote: >>>>>>> >>>>>>> 2015-10-19 11:16 GMT+01:00 David Nichols : >>>>>>>> >>>>>>>>> On Oct 18, 2015, at 10:06 AM, Frediano Ziglio >>> wrote: >>>>>>>>> >>>>>>>>> 2015-10-16 12:23 GMT+01:00 David Nichols : >>>>>>>>>>> 2015-06-09 14:48 GMT+01:00 Ondrej Holecek >> qoretechnologies.com >: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> I made a test with the same code but sybase lib and it works like >>>>>>>>>>>> expected. It seems there is a bug in FreeTDS. Could you please >>> check >>>>>>>>>>>> my patch? >>>>>>>>>>>> >>>>>>>>>>>> thx, >>>>>>>>>>>> >>>>>>>>>>>> Ondrej >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Actually works and ctlib tests seems to pass. >>>>>>>>>>> >>>>>>>>>>> However DONEINPROC is returned in a lot of cases, for instance if >>>>>>>>>>> database execute some trigger on the table so your patch can catch >>>>>>>>>>> some strange results too. >>>>>>>>>>> >>>>>>>>>>> Which database version are you using? >>>>>>>>>>> >>>>>>>>>>> Frediano >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Ondra has not been working on this for quite some time, but I?d >>> like to pick up this issue again please. >>>>>>>>>> >>>>>>>>>> We are using MS SQL Server 2008 - using tds version = 7.2 - with >>> the patch we are able to get the affected rows reliably - without it, we >>> are not. >>>>>>>>>> >>>>>>>>>> Using the same patched library build with a Sybase (SAP) ASE 16.0 >>> DB, it also gives correct results (with tds version = 5.0) >>>>>>>>>> >>>>>>>>>> I would be happy to continue helping with this issue if there?s a >>> chance it could be included in freetds (or some other equally effective >>> fix). >>>>>>>>>> >>>>>>>>>> thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>> >>>>>>>>> A fix was written for this case. Do you still have some code that >>>>>>>>> fails? Did you update FreeTDS? >>>>>>>>> >>>>>>>>> Frediano >>>>>>>> >>>>>>>> yes, I tried it with freetds from freetds-0.95.12 and git master - >>> both failed my tests and with the patch as provded by Ondra the tests then >>> passed. Sorry I did not mention this in the original email. >>>>>>>> >>>>>>> >>>>>>> Please try a more recent version (like 0.95.21). Also you should sent >>>>>>> some extract of your tests. Can you post an updated patch? >>>>>>> >>>>>> sorry it was a typo on my side - it was 0.95.21 that I tried. Anyway >>> since it failed in git master then I would assume that would be more >>> relevant than the last stable release. >>>>>> >>>>>> Attached please find a patch to git master sources that makes my tests >>> work. Please note that we are using ctlib from freetds to build a DBI >>> driver for the Qore programming language to talk to SQL Server and Sybase >>> DBs; the same source builds with both the sybae libs and ctlib from >>> freetds. Currently my tests are written in the Qore programming language, >>> so there are quite a few layers between the Qore code that?s executed and >>> freetds?s ctlib. >>>>>> >>>>>> When this simple test works (ie only with a patch ctlib); the output >>> looks like this: >>>>>> >>>>>> dnichols at manatee:~/src/qore/git/module-sybase/src$ >>> simple-rows-affected-test.q >>>>>> "Microsoft SQL Server 2008 (RTM) - 10.0.1600.22 (X64) >>>>>> Jul 9 2008 14:17:44 >>>>>> Copyright (c) 1988-2008 Microsoft Corporation >>>>>> Developer Edition (64-bit) on Windows NT 6.1 (Build 7601: >>> Service Pack 1)" >>>>>> insert: 1 >>>>>> n delete: 0 >>>>>> sel: {id: [1]} >>>>>> delete: 1 >>>>>> insert: 1 >>>>>> delete: 1 >>>>>> >>>>>> When it doesn?t work (ie with an unpatched ctlib), the output looks >>> like this: >>>>>> dnichols at manatee:~/src/qore/git/module-sybase/src$ >>> simple-rows-affected-test.q >>>>>> "Microsoft SQL Server 2008 (RTM) - 10.0.1600.22 (X64) >>>>>> Jul 9 2008 14:17:44 >>>>>> Copyright (c) 1988-2008 Microsoft Corporation >>>>>> Developer Edition (64-bit) on Windows NT 6.1 (Build 7601: >>> Service Pack 1)" >>>>>> insert: 0 >>>>>> n delete: 0 >>>>>> sel: {id: [1]} >>>>>> delete: 0 >>>>>> insert: -1 >>>>>> delete: -1 >>>>>> >>>>>> The Qore source to this simple test is attached for your reference. >>>>>> >>>>> >>>>> I applied the patch and improved a test to catch this issue. I changed >>>>> the patch slightly to check for TDS_NO_COUNT instead of <0 and >>>>> returning CS_CMD_SUCCEEDED as ct_res_info documentation >>>> >>>> My test fails with your patch; if I change it back to: >>>> case _CS_RES_INIT: /* command had no >>> result set */ >>>> if (tds->rows_affected != >>> TDS_NO_COUNT) { >>>> *result_type = >>> CS_CMD_DONE; >>>> cmd->results_state = >>> _CS_RES_INIT; >>>> return CS_SUCCEED; >>>> } >>>> break; >>>> >>>> then it succeeds - please note that his is a hack from my side, I?m not >>> saying that the original approach is correct, just that my test fails >>> unless I set CS_CMD_DONE >>>> >>>> thx >>>> David >>>> >>> >>> Cs_cmd_succeeded is a valid value and is expected to have rows number >>> attached so upper layer should handle it >> >> OK, I see what you mean, however please note that with ctlib from Sybase/SAP ASE 16, I get the rows updated correctly with the same driver code as I use with freetds, and now it seems that I?ll need to update the driver to have a separate code path when it?s built with freetds - which seems to defeat the purpose of freetds?s ctlib. Is it not possible to fix this issue and provide 100% backwards-compatibility with Sybase?s ctlib? >> > > @Frediano: sorry to bother you with this issue, but since it?s important for me, can you please let me know about the above - should I plan on having 2 code paths in my DB driver - one for Sybase and one for FreeTDS, or should there ideally be a way that compatibility between Sybase?s ctlib and FreeTDS?s ctlib can be provided regarding this issue? > > thx > David > Hi David, I checked again code and server replies and there is no incompatibility for the change. I'll add a patch for this ASAP. Frediano From david at qore.org Wed Nov 11 15:00:17 2015 From: david at qore.org (David Nichols) Date: Wed, 11 Nov 2015 21:00:17 +0100 Subject: [freetds] affected rows after insert In-Reply-To: References: <4AA5C8FC-111B-4F3B-9751-A9A19E226C6B@qore.org> Message-ID: <51DE90DE-3D8B-4EC8-833D-64144122CDA5@qore.org> > On Nov 11, 2015, at 8:54 PM, Frediano Ziglio wrote: > > 2015-11-03 11:56 GMT+00:00 David Nichols : >> On Oct 20, 2015, at 11:17 AM, David Nichols wrote: >>> >>>> >>>> On Oct 20, 2015, at 9:12 AM, Frediano Ziglio wrote: >>>> >>>> Il 20/Ott/2015 09:09, "David Nichols" ha scritto: >>>>> >>>>> On Oct 19, 2015, at 10:20 PM, Frediano Ziglio wrote: >>>>>> >>>>>> 2015-10-19 13:35 GMT+01:00 David Nichols : >>>>>>> >>>>>>>> On Oct 19, 2015, at 1:53 PM, Frediano Ziglio >>>> wrote: >>>>>>>> >>>>>>>> 2015-10-19 11:16 GMT+01:00 David Nichols : >>>>>>>>> >>>>>>>>>> On Oct 18, 2015, at 10:06 AM, Frediano Ziglio >>>> wrote: >>>>>>>>>> >>>>>>>>>> 2015-10-16 12:23 GMT+01:00 David Nichols : >>>>>>>>>>>> 2015-06-09 14:48 GMT+01:00 Ondrej Holecek >>> qoretechnologies.com >: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> I made a test with the same code but sybase lib and it works like >>>>>>>>>>>>> expected. It seems there is a bug in FreeTDS. Could you please >>>> check >>>>>>>>>>>>> my patch? >>>>>>>>>>>>> >>>>>>>>>>>>> thx, >>>>>>>>>>>>> >>>>>>>>>>>>> Ondrej >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Actually works and ctlib tests seems to pass. >>>>>>>>>>>> >>>>>>>>>>>> However DONEINPROC is returned in a lot of cases, for instance if >>>>>>>>>>>> database execute some trigger on the table so your patch can catch >>>>>>>>>>>> some strange results too. >>>>>>>>>>>> >>>>>>>>>>>> Which database version are you using? >>>>>>>>>>>> >>>>>>>>>>>> Frediano >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> Ondra has not been working on this for quite some time, but I?d >>>> like to pick up this issue again please. >>>>>>>>>>> >>>>>>>>>>> We are using MS SQL Server 2008 - using tds version = 7.2 - with >>>> the patch we are able to get the affected rows reliably - without it, we >>>> are not. >>>>>>>>>>> >>>>>>>>>>> Using the same patched library build with a Sybase (SAP) ASE 16.0 >>>> DB, it also gives correct results (with tds version = 5.0) >>>>>>>>>>> >>>>>>>>>>> I would be happy to continue helping with this issue if there?s a >>>> chance it could be included in freetds (or some other equally effective >>>> fix). >>>>>>>>>>> >>>>>>>>>>> thanks, >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> A fix was written for this case. Do you still have some code that >>>>>>>>>> fails? Did you update FreeTDS? >>>>>>>>>> >>>>>>>>>> Frediano >>>>>>>>> >>>>>>>>> yes, I tried it with freetds from freetds-0.95.12 and git master - >>>> both failed my tests and with the patch as provded by Ondra the tests then >>>> passed. Sorry I did not mention this in the original email. >>>>>>>>> >>>>>>>> >>>>>>>> Please try a more recent version (like 0.95.21). Also you should sent >>>>>>>> some extract of your tests. Can you post an updated patch? >>>>>>>> >>>>>>> sorry it was a typo on my side - it was 0.95.21 that I tried. Anyway >>>> since it failed in git master then I would assume that would be more >>>> relevant than the last stable release. >>>>>>> >>>>>>> Attached please find a patch to git master sources that makes my tests >>>> work. Please note that we are using ctlib from freetds to build a DBI >>>> driver for the Qore programming language to talk to SQL Server and Sybase >>>> DBs; the same source builds with both the sybae libs and ctlib from >>>> freetds. Currently my tests are written in the Qore programming language, >>>> so there are quite a few layers between the Qore code that?s executed and >>>> freetds?s ctlib. >>>>>>> >>>>>>> When this simple test works (ie only with a patch ctlib); the output >>>> looks like this: >>>>>>> >>>>>>> dnichols at manatee:~/src/qore/git/module-sybase/src$ >>>> simple-rows-affected-test.q >>>>>>> "Microsoft SQL Server 2008 (RTM) - 10.0.1600.22 (X64) >>>>>>> Jul 9 2008 14:17:44 >>>>>>> Copyright (c) 1988-2008 Microsoft Corporation >>>>>>> Developer Edition (64-bit) on Windows NT 6.1 (Build 7601: >>>> Service Pack 1)" >>>>>>> insert: 1 >>>>>>> n delete: 0 >>>>>>> sel: {id: [1]} >>>>>>> delete: 1 >>>>>>> insert: 1 >>>>>>> delete: 1 >>>>>>> >>>>>>> When it doesn?t work (ie with an unpatched ctlib), the output looks >>>> like this: >>>>>>> dnichols at manatee:~/src/qore/git/module-sybase/src$ >>>> simple-rows-affected-test.q >>>>>>> "Microsoft SQL Server 2008 (RTM) - 10.0.1600.22 (X64) >>>>>>> Jul 9 2008 14:17:44 >>>>>>> Copyright (c) 1988-2008 Microsoft Corporation >>>>>>> Developer Edition (64-bit) on Windows NT 6.1 (Build 7601: >>>> Service Pack 1)" >>>>>>> insert: 0 >>>>>>> n delete: 0 >>>>>>> sel: {id: [1]} >>>>>>> delete: 0 >>>>>>> insert: -1 >>>>>>> delete: -1 >>>>>>> >>>>>>> The Qore source to this simple test is attached for your reference. >>>>>>> >>>>>> >>>>>> I applied the patch and improved a test to catch this issue. I changed >>>>>> the patch slightly to check for TDS_NO_COUNT instead of <0 and >>>>>> returning CS_CMD_SUCCEEDED as ct_res_info documentation >>>>> >>>>> My test fails with your patch; if I change it back to: >>>>> case _CS_RES_INIT: /* command had no >>>> result set */ >>>>> if (tds->rows_affected != >>>> TDS_NO_COUNT) { >>>>> *result_type = >>>> CS_CMD_DONE; >>>>> cmd->results_state = >>>> _CS_RES_INIT; >>>>> return CS_SUCCEED; >>>>> } >>>>> break; >>>>> >>>>> then it succeeds - please note that his is a hack from my side, I?m not >>>> saying that the original approach is correct, just that my test fails >>>> unless I set CS_CMD_DONE >>>>> >>>>> thx >>>>> David >>>>> >>>> >>>> Cs_cmd_succeeded is a valid value and is expected to have rows number >>>> attached so upper layer should handle it >>> >>> OK, I see what you mean, however please note that with ctlib from Sybase/SAP ASE 16, I get the rows updated correctly with the same driver code as I use with freetds, and now it seems that I?ll need to update the driver to have a separate code path when it?s built with freetds - which seems to defeat the purpose of freetds?s ctlib. Is it not possible to fix this issue and provide 100% backwards-compatibility with Sybase?s ctlib? >>> >> >> @Frediano: sorry to bother you with this issue, but since it?s important for me, can you please let me know about the above - should I plan on having 2 code paths in my DB driver - one for Sybase and one for FreeTDS, or should there ideally be a way that compatibility between Sybase?s ctlib and FreeTDS?s ctlib can be provided regarding this issue? >> >> thx >> David >> > > Hi David, > I checked again code and server replies and there is no > incompatibility for the change. > > I'll add a patch for this ASAP. > thanks a lot; that?s really great news! ciao David > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From no-reply at appveyor.com Wed Nov 11 15:15:35 2015 From: no-reply at appveyor.com (AppVeyor) Date: Wed, 11 Nov 2015 20:15:35 +0000 Subject: [freetds] Build completed: freetds 293 Message-ID: <20151111201533.21724.50225@appveyor.com> From ken at metaskills.net Sun Nov 15 12:58:17 2015 From: ken at metaskills.net (Ken Collins) Date: Sun, 15 Nov 2015 12:58:17 -0500 Subject: [freetds] Compiling Against FreeTDS 0.95 w/7.3 TDSVER Features Possible? Message-ID: I am in the process of upgrading the Ruby C extensions to FreeTDS from 0.91 to 0.95. The primary goal is to also support using TDSVER 7.3 and the newly supported 2008 data types.? Is this possible to use these new types in 0.95 when many of the types are not defined in sybdb.h? For example here is a diff of that file when comparing 0.95 to master.?https://gist.github.com/metaskills/4c9900c3d1078e5c4763 ?- Thanks in advance, ? ? Ken From ken at metaskills.net Sun Nov 15 15:14:29 2015 From: ken at metaskills.net (Ken Collins) Date: Sun, 15 Nov 2015 15:14:29 -0500 Subject: [freetds] Compiling Against FreeTDS 0.95 w/7.3 TDSVER Features Possible? In-Reply-To: References: Message-ID: I am in the process of upgrading the Ruby C extensions to FreeTDS from 0.91 to 0.95. The primary goal is to also support using TDSVER 7.3 and the newly supported 2008 data types.? Is this possible to use these new types in 0.95 when many of the types are not defined in sybdb.h? For example here is a diff of that file when comparing 0.95 to master.?https://gist.github.com/metaskills/4c9900c3d1078e5c4763 For example, I can see that dbcoltype() is returning integers that match these below. I can even see the binary data, but I am unsure how what API functions I need to use this data. So far?dbdatecrack() is not working. Any recommendations? SYBMSDATE = 40 SYBMSTIME = 41 SYBMSDATETIME2 = 42 SYBMSDATETIMEOFFSET = 43 From freddy77 at gmail.com Mon Nov 16 11:58:02 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Mon, 16 Nov 2015 16:58:02 +0000 Subject: [freetds] Compiling Against FreeTDS 0.95 w/7.3 TDSVER Features Possible? In-Reply-To: References: Message-ID: 2015-11-15 20:14 GMT+00:00 Ken Collins : > I am in the process of upgrading the Ruby C extensions to FreeTDS from 0.91 to 0.95. > > The primary goal is to also support using TDSVER 7.3 and the newly supported 2008 data types. > > Is this possible to use these new types in 0.95 when many of the types are not defined in sybdb.h? For example here is a diff of that file when comparing 0.95 to master. https://gist.github.com/metaskills/4c9900c3d1078e5c4763 > > > For example, I can see that dbcoltype() is returning integers that match these below. I can even see the binary data, but I am unsure how what API functions I need to use this data. So far dbdatecrack() is not working. Any recommendations? > > SYBMSDATE = 40 > > SYBMSTIME = 41 > > SYBMSDATETIME2 = 42 > > SYBMSDATETIMEOFFSET = 43 > Yes, actually the patch could be backported (beside the 7.4 stuff). The binary structure is well defined (and an ABI actually) however is defined in tds.h (TDS_DATETIMEALL). The date field is the same as dtdays in DATETIME however time is completely different (100-nanosecondth from start of day). dbdatecrack only supports DATETIME. I suppose a new dbanydatecrack (or whatever) extension could be defined (possibly extending time precision). Or in the meantime you could pass date field into a DATETIME, use dbdatecrack and split time manually (at least the precision). Frediano From freddy77 at gmail.com Sat Nov 21 11:12:48 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Sat, 21 Nov 2015 16:12:48 +0000 Subject: [freetds] Compiling Against FreeTDS 0.95 w/7.3 TDSVER Features Possible? In-Reply-To: References: Message-ID: 2015-11-15 20:14 GMT+00:00 Ken Collins : > I am in the process of upgrading the Ruby C extensions to FreeTDS from 0.91 to 0.95. > > The primary goal is to also support using TDSVER 7.3 and the newly supported 2008 data types. > > Is this possible to use these new types in 0.95 when many of the types are not defined in sybdb.h? For example here is a diff of that file when comparing 0.95 to master. https://gist.github.com/metaskills/4c9900c3d1078e5c4763 > > > For example, I can see that dbcoltype() is returning integers that match these below. I can even see the binary data, but I am unsure how what API functions I need to use this data. So far dbdatecrack() is not working. Any recommendations? > > SYBMSDATE = 40 > > SYBMSTIME = 41 > > SYBMSDATETIME2 = 42 > > SYBMSDATETIMEOFFSET = 43 > > How does it sound this patch (as a start) https://github.com/FreeTDS/freetds/commit/a35fe7e4f98034f255c9ca77eab8b9891dfac661 Frediano From no-reply at appveyor.com Sat Nov 21 11:19:59 2015 From: no-reply at appveyor.com (AppVeyor) Date: Sat, 21 Nov 2015 16:19:59 +0000 Subject: [freetds] Build failed: freetds 301 Message-ID: <20151121161958.20254.16866@appveyor.com> From freddy77 at gmail.com Sun Nov 22 09:27:37 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Sun, 22 Nov 2015 14:27:37 +0000 Subject: [freetds] Compiling Against FreeTDS 0.95 w/7.3 TDSVER Features Possible? In-Reply-To: References: Message-ID: 2015-11-22 0:42 GMT+00:00 Ken Collins : > On November 21, 2015 at 11:13:00 AM, Frediano Ziglio (freddy77 at gmail.com) > wrote: > > 2015-11-15 20:14 GMT+00:00 Ken Collins : >> I am in the process of upgrading the Ruby C extensions to FreeTDS from >> 0.91 to 0.95. >> >> The primary goal is to also support using TDSVER 7.3 and the newly >> supported 2008 data types. >> >> Is this possible to use these new types in 0.95 when many of the types are >> not defined in sybdb.h? For example here is a diff of that file when >> comparing 0.95 to master. >> https://gist.github.com/metaskills/4c9900c3d1078e5c4763 >> >> >> For example, I can see that dbcoltype() is returning integers that match >> these below. I can even see the binary data, but I am unsure how what API >> functions I need to use this data. So far dbdatecrack() is not working. Any >> recommendations? >> >> SYBMSDATE = 40 >> >> SYBMSTIME = 41 >> >> SYBMSDATETIME2 = 42 >> >> SYBMSDATETIMEOFFSET = 43 >> >> > > How does it sound this patch (as a start) > > https://github.com/FreeTDS/freetds/commit/a35fe7e4f98034f255c9ca77eab8b9891dfac661 > > Frediano > > Looks great! I'm interested in knowing how DBDATETIMEALL might be used. > Would this be the structure returned for the new date crack? > dbdata. Is already returned in this way, just there was no definition for the structure. > I've created this issue > (https://github.com/rails-sqlserver/tiny_tds/issues/244) on our project to > tracks this. Thanks and I'll watch master for updates. > I pushed some changes to master to integrate dbanydatecrack. This function use new DBDATEREC2 type which change milliseconds to nanoseconds in the DBDATEREC structure and accepts an additional type parameter (which can be returned by dbcoltype) for the type. So you can use dbdata+dbcoltype+dbanydatecrack to parse any date/time type (even future BIGTIME or whatever). The idea is to backport these changes in 0.95 too. Could you try if works for you? I extended a test and is actually working. Frediano From lacak at zoznam.sk Mon Nov 23 02:18:56 2015 From: lacak at zoznam.sk (LacaK) Date: Mon, 23 Nov 2015 08:18:56 +0100 Subject: [freetds] Compiling Against FreeTDS 0.95 w/7.3 TDSVER Features Possible? In-Reply-To: References: Message-ID: <5652BDE0.4050207@zoznam.sk> > > I pushed some changes to master to integrate dbanydatecrack. This > function use new DBDATEREC2 type which change milliseconds to > nanoseconds in the DBDATEREC structure and accepts an additional type > parameter (which can be returned by dbcoltype) for the type. > So you can use dbdata+dbcoltype+dbanydatecrack to parse any date/time > type (even future BIGTIME or whatever). The idea is to backport these > changes in 0.95 too. > > Could you try if works for you? I extended a test and is actually working. Only formal note: for me better sounds "dbdatecrack2()" as "dbanydatecrack()" (or "tdsdbdatecrack()" as there is already "tdsdbopen()" versus "dbopen()" ? or "dbdatetimecrack()" ?) -Laco. From freddy77 at gmail.com Mon Nov 23 02:51:50 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Mon, 23 Nov 2015 07:51:50 +0000 Subject: [freetds] Compiling Against FreeTDS 0.95 w/7.3 TDSVER Features Possible? In-Reply-To: <5652BDE0.4050207@zoznam.sk> References: <5652BDE0.4050207@zoznam.sk> Message-ID: Il 23/Nov/2015 07:19, "LacaK" ha scritto: > > >> >> I pushed some changes to master to integrate dbanydatecrack. This >> function use new DBDATEREC2 type which change milliseconds to >> nanoseconds in the DBDATEREC structure and accepts an additional type >> parameter (which can be returned by dbcoltype) for the type. >> So you can use dbdata+dbcoltype+dbanydatecrack to parse any date/time >> type (even future BIGTIME or whatever). The idea is to backport these >> changes in 0.95 too. >> >> Could you try if works for you? I extended a test and is actually working. > > > Only formal note: > for me better sounds "dbdatecrack2()" as "dbanydatecrack()" > (or "tdsdbdatecrack()" as there is already "tdsdbopen()" versus "dbopen()" ? > or "dbdatetimecrack()" ?) > It's quite a personal choice. The rationale behind tdsdbopen was different. Was supposed to be an ABI not called directly but to be possible to have dbopen as ABI (so to keep old one) and a new dbopen API which call a new ABI (tdsdbopen was choosed). The rationale against dbanydatecrack is that: - is a new API and ABI; - I want to keep dblib db prefix; - dbdatecrack handle only DB DATE TIME so calling new one dbdatetimecrack is confusing; - can be thought as an extension to dbdatecrack, yes, so the name dbdatecrack2 may sound reasonable also thinking about DBDATEREC2... on the other way it state more precisely that handle all date type instead of just one. So... All that reasonings exclude either tdsdbdatecrack and dbdatetimecrack. About the choice between dbdatecrack2 and dbanydatecrack I think we are one against one. I prefer dbanydatecrack. Frediano From matthew.green at datamartcomputing.com Mon Nov 23 03:06:24 2015 From: matthew.green at datamartcomputing.com (matthew.green at datamartcomputing.com) Date: Mon, 23 Nov 2015 08:06:24 +0000 Subject: [freetds] Compiling Against FreeTDS 0.95 w/7.3 TDSVER Features Possible? In-Reply-To: References: <5652BDE0.4050207@zoznam.sk> Message-ID: <3351d5da418f84c01cedacc843f35844@datamartcomputing.com> If this were a democracy I'd be voting for dbanydatecrack as it feels a better fit to me. Not that I think it matters a huge amount either way :-) Cheers, Matthew. November 23 2015 8:52 AM, "Frediano Ziglio" wrote: > Il 23/Nov/2015 07:19, "LacaK" ha scritto: > >>> I pushed some changes to master to integrate dbanydatecrack. This >>> function use new DBDATEREC2 type which change milliseconds to >>> nanoseconds in the DBDATEREC structure and accepts an additional type >>> parameter (which can be returned by dbcoltype) for the type. >>> So you can use dbdata+dbcoltype+dbanydatecrack to parse any date/time >>> type (even future BIGTIME or whatever). The idea is to backport these >>> changes in 0.95 too. >>> >>> Could you try if works for you? I extended a test and is actually > > working. >> Only formal note: >> for me better sounds "dbdatecrack2()" as "dbanydatecrack()" >> (or "tdsdbdatecrack()" as there is already "tdsdbopen()" versus > > "dbopen()" ? >> or "dbdatetimecrack()" ?) > > It's quite a personal choice. The rationale behind tdsdbopen was different. > Was supposed to be an ABI not called directly but to be possible to have > dbopen as ABI (so to keep old one) and a new dbopen API which call a new > ABI (tdsdbopen was choosed). > > The rationale against dbanydatecrack is that: > - is a new API and ABI; > - I want to keep dblib db prefix; > - dbdatecrack handle only DB DATE TIME so calling new one dbdatetimecrack > is confusing; > - can be thought as an extension to dbdatecrack, yes, so the name > dbdatecrack2 may sound reasonable also thinking about DBDATEREC2... on the > other way it state more precisely that handle all date type instead of just > one. > > So... All that reasonings exclude either tdsdbdatecrack and > dbdatetimecrack. About the choice between dbdatecrack2 and dbanydatecrack I > think we are one against one. I prefer dbanydatecrack. > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From lacak at zoznam.sk Mon Nov 23 04:03:31 2015 From: lacak at zoznam.sk (LacaK) Date: Mon, 23 Nov 2015 10:03:31 +0100 Subject: [freetds] Compiling Against FreeTDS 0.95 w/7.3 TDSVER Features Possible? In-Reply-To: References: <5652BDE0.4050207@zoznam.sk> Message-ID: <5652D663.4080001@zoznam.sk> >> >>> >>> So... All that reasonings exclude either tdsdbdatecrack and >>> dbdatetimecrack. ok >>> About the choice between dbdatecrack2 and dbanydatecrack I >>> think we are one against one. I prefer dbanydatecrack. ok this was only me feeling. (also Microsoft and Oracle have datatypes "DATETIME2" , "VARCHAR2" So suffix "2" is used to introduce "extended" data types) L. >>> >>> Frediano >>> _______________________________________________ >>> FreeTDS mailing list >>> FreeTDS at lists.ibiblio.org >>> http://lists.ibiblio.org/mailman/listinfo/freetds >>> From freddy77 at gmail.com Mon Nov 23 21:06:09 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Tue, 24 Nov 2015 02:06:09 +0000 Subject: [freetds] Compiling Against FreeTDS 0.95 w/7.3 TDSVER Features Possible? In-Reply-To: <5652D663.4080001@zoznam.sk> References: <5652BDE0.4050207@zoznam.sk> <5652D663.4080001@zoznam.sk> Message-ID: Il 23/Nov/2015 09:03, "LacaK" ha scritto: > > >>> >>>> >>>> So... All that reasonings exclude either tdsdbdatecrack and >>>> dbdatetimecrack. > > ok > > >>>> About the choice between dbdatecrack2 and dbanydatecrack I >>>> think we are one against one. I prefer dbanydatecrack. > > ok > this was only me feeling. > > (also Microsoft and Oracle have datatypes "DATETIME2" , "VARCHAR2" > So suffix "2" is used to introduce "extended" data types) > I just think is a short and lazy way :) What about DBDATEREC2 ? Frediano From lacak at zoznam.sk Tue Nov 24 09:45:45 2015 From: lacak at zoznam.sk (LacaK) Date: Tue, 24 Nov 2015 15:45:45 +0100 Subject: [freetds] Compiling Against FreeTDS 0.95 w/7.3 TDSVER Features Possible? In-Reply-To: References: <5652BDE0.4050207@zoznam.sk> <5652D663.4080001@zoznam.sk> Message-ID: <56547819.4010006@zoznam.sk> > I just think is a short and lazy way :) > What about DBDATEREC2 ? No problem for me. I like it ;-) (DATETIME2, DBDATEREC2, output2, ..., "dbdatecrack2()") -Laco. From Manasi.Deshpande at Renishaw.com Fri Nov 27 05:21:45 2015 From: Manasi.Deshpande at Renishaw.com (Manasi Deshpande) Date: Fri, 27 Nov 2015 10:21:45 +0000 Subject: [freetds] Syntax Error Message-ID: Hello, Environment: Ubuntu 14.04 UnixOdbc-2.3.4 Built and installed from freetds-0.95.69 and TDS version is 7.3 Issue: In this we are trying to query DB with IDs to return a collection of items. RETCODE RetCode; SQLSMALLINT sNumResults; int idCount = 0; _INT64 *arrIds =ArrayOfIds.GetArray(); U_stringstream idStr; idStr << _U("("); for (int i = 0; i < idCount; i++) { idStr << arrIds[i]; if (i < idCount - 1) idStr << _U(","); } idStr << _U(")"); U_STRING idString = idStr.str(); SQLUSMALLINT ParamStatusArray[2]; SQLULEN ParamsProcessed; SQLHANDLE hStmt = dbCon.getStmtHandle(); SQLHANDLE hConn = dbCon.getConnHandle(); // Specify the number of elements in each parameter array. TRYODBC(hStmt, SQL_HANDLE_STMT, SQLSetStmtAttr(hStmt, SQL_ATTR_PARAMSET_SIZE, (SQLPOINTER)idCount, 0)); // Specify an array in which to return the status of each set of // parameters. TRYODBC(hStmt, SQL_HANDLE_STMT, SQLSetStmtAttr(hStmt, SQL_ATTR_PARAM_STATUS_PTR, ParamStatusArray, idCount)); // Specify an SQLUINTEGER value in which to return the number of sets of // parameters processed. TRYODBC(hStmt, SQL_HANDLE_STMT, SQLSetStmtAttr(hStmt, SQL_ATTR_PARAMS_PROCESSED_PTR, &ParamsProcessed, 0)); //Bind Parameters //TRYODBC(hStmt, SQL_HANDLE_STMT, SQLBindParameter(hStmt, 1, SQL_PARAM_INPUT, SQL_C_SLONG, SQL_INTEGER, 0, 0, arrIds, 0, NULL)); U_STRING query = _U("SELECT query WHERE ITEM.Id in ") + idString + _U(" ORDER BY ITEM.Id ASC"); RetCode = SQLExecDirect(hStmt, (SQLTCHAR*)query.c_str(), SQL_NTS); The Execute statement returns the following error information. [FreeTDS][SQL Server]Incorrect syntax near Any help/inputs appreciated! Thanks, Manasi -------------------------------------------------------------------------------------------------- This email and any attachments are confidential and are for the use of the addressee only. If you are not the addressee, you must not use or disclose the contents to any other person. Please immediately notify the sender and delete the email. Statements and opinions expressed here may not represent those of the company. Email correspondence is monitored by the company. This information may be subject to export control regulation. You are obliged to comply with such regulations. Renishaw plc (company number 1106260) and Wotton Travel Limited (company number 01973158) are companies registered in England and Wales with a registered office at New Mills, Wotton-under-Edge, Gloucestershire, GL12 8JR, United Kingdom, Telephone +44 1453 524524. -------------------------------------------------------------------------------------------------- From freddy77 at gmail.com Fri Nov 27 09:48:50 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Fri, 27 Nov 2015 14:48:50 +0000 Subject: [freetds] Syntax Error In-Reply-To: References: Message-ID: 2015-11-27 10:21 GMT+00:00 Manasi Deshpande : > Hello, > > Environment: > Ubuntu 14.04 > UnixOdbc-2.3.4 > Built and installed from freetds-0.95.69 and TDS version is 7.3 > > Issue: > In this we are trying to query DB with IDs to return a collection of items. > > RETCODE RetCode; > SQLSMALLINT sNumResults; > > int idCount = 0; > _INT64 *arrIds =ArrayOfIds.GetArray(); > U_stringstream idStr; > > idStr << _U("("); > > for (int i = 0; i < idCount; i++) > { > idStr << arrIds[i]; > if (i < idCount - 1) > idStr << _U(","); > } > > idStr << _U(")"); > U_STRING idString = idStr.str(); > > SQLUSMALLINT ParamStatusArray[2]; > SQLULEN ParamsProcessed; > > SQLHANDLE hStmt = dbCon.getStmtHandle(); > SQLHANDLE hConn = dbCon.getConnHandle(); > > > // Specify the number of elements in each parameter array. > TRYODBC(hStmt, SQL_HANDLE_STMT, SQLSetStmtAttr(hStmt, SQL_ATTR_PARAMSET_SIZE, (SQLPOINTER)idCount, 0)); > > // Specify an array in which to return the status of each set of > // parameters. > TRYODBC(hStmt, SQL_HANDLE_STMT, SQLSetStmtAttr(hStmt, SQL_ATTR_PARAM_STATUS_PTR, ParamStatusArray, idCount)); > > // Specify an SQLUINTEGER value in which to return the number of sets of > // parameters processed. > TRYODBC(hStmt, SQL_HANDLE_STMT, SQLSetStmtAttr(hStmt, SQL_ATTR_PARAMS_PROCESSED_PTR, &ParamsProcessed, 0)); > > //Bind Parameters > //TRYODBC(hStmt, SQL_HANDLE_STMT, SQLBindParameter(hStmt, 1, SQL_PARAM_INPUT, SQL_C_SLONG, SQL_INTEGER, 0, 0, arrIds, 0, NULL)); > > U_STRING query = _U("SELECT query WHERE ITEM.Id in ") + idString + _U(" ORDER BY ITEM.Id ASC"); > I would first try with an easy query like "SELECT 1" > RetCode = SQLExecDirect(hStmt, (SQLTCHAR*)query.c_str(), SQL_NTS); > In which encoding the U_STRING store the string. No, Unicode is not enough (if you don't specify the version). >From the code above query.c_str() should return a NUL-terminated string encoded in UTF-16 or UCS-2 format (endian machine dependent). Should not be SQLExecDirectW or did you enabled UNICODE define in Makefile/project file(s) ? > The Execute statement returns the following error information. > [FreeTDS][SQL Server]Incorrect syntax near > > Any help/inputs appreciated! > > Thanks, > Manasi Frediano From Manasi.Deshpande at Renishaw.com Sun Nov 29 23:55:37 2015 From: Manasi.Deshpande at Renishaw.com (Manasi Deshpande) Date: Mon, 30 Nov 2015 04:55:37 +0000 Subject: [freetds] Syntax Error In-Reply-To: References: Message-ID: Hello, We are using UTF-8 encoding and it is char that we are using! We aren't using wide APIs on Linux! In the FreeTDS config file we are specifying the client charset as UTF-8. Strange thing I observed was after commenting the following code the SQLExecDirect executes with SUCCESS. // Specify the number of elements in each parameter array. TRYODBC(hStmt, SQL_HANDLE_STMT, SQLSetStmtAttr(hStmt, SQL_ATTR_PARAMSET_SIZE, (SQLPOINTER)idCount, 0)); // Specify an array in which to return the status of each set of // parameters. TRYODBC(hStmt, SQL_HANDLE_STMT, SQLSetStmtAttr(hStmt, SQL_ATTR_PARAM_STATUS_PTR, ParamStatusArray, idCount)); // Specify an SQLUINTEGER value in which to return the number of sets of // parameters processed. TRYODBC(hStmt, SQL_HANDLE_STMT, SQLSetStmtAttr(hStmt, SQL_ATTR_PARAMS_PROCESSED_PTR, &ParamsProcessed, 0)); Also another point to notice is that, I have recently updated from freetds-0.91 and TDS version 7.1. The code worked seamlessly then! Regards, Manasi -----Original Message----- From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of Frediano Ziglio Sent: 27 November 2015 20:19 To: FreeTDS Development Group Subject: Re: [freetds] Syntax Error 2015-11-27 10:21 GMT+00:00 Manasi Deshpande : > Hello, > > Environment: > Ubuntu 14.04 > UnixOdbc-2.3.4 > Built and installed from freetds-0.95.69 and TDS version is 7.3 > > Issue: > In this we are trying to query DB with IDs to return a collection of items. > > RETCODE RetCode; > SQLSMALLINT sNumResults; > > int idCount = 0; > _INT64 *arrIds =ArrayOfIds.GetArray(); > U_stringstream idStr; > > idStr << _U("("); > > for (int i = 0; i < idCount; i++) > { > idStr << arrIds[i]; > if (i < idCount - 1) > idStr << _U(","); > } > > idStr << _U(")"); > U_STRING idString = idStr.str(); > > SQLUSMALLINT ParamStatusArray[2]; > SQLULEN ParamsProcessed; > > SQLHANDLE hStmt = dbCon.getStmtHandle(); > SQLHANDLE hConn = dbCon.getConnHandle(); > > > // Specify the number of elements in each parameter array. > TRYODBC(hStmt, SQL_HANDLE_STMT, SQLSetStmtAttr(hStmt, > SQL_ATTR_PARAMSET_SIZE, (SQLPOINTER)idCount, 0)); > > // Specify an array in which to return the status of each set of > // parameters. > TRYODBC(hStmt, SQL_HANDLE_STMT, SQLSetStmtAttr(hStmt, > SQL_ATTR_PARAM_STATUS_PTR, ParamStatusArray, idCount)); > > // Specify an SQLUINTEGER value in which to return the number of sets of > // parameters processed. > TRYODBC(hStmt, SQL_HANDLE_STMT, SQLSetStmtAttr(hStmt, > SQL_ATTR_PARAMS_PROCESSED_PTR, &ParamsProcessed, 0)); > > //Bind Parameters > //TRYODBC(hStmt, SQL_HANDLE_STMT, SQLBindParameter(hStmt, > 1, SQL_PARAM_INPUT, SQL_C_SLONG, SQL_INTEGER, 0, 0, arrIds, 0, NULL)); > > U_STRING query = _U("SELECT query WHERE ITEM.Id in ") + > idString + _U(" ORDER BY ITEM.Id ASC"); > I would first try with an easy query like "SELECT 1" > RetCode = SQLExecDirect(hStmt, (SQLTCHAR*)query.c_str(), > SQL_NTS); > In which encoding the U_STRING store the string. No, Unicode is not enough (if you don't specify the version). >From the code above query.c_str() should return a NUL-terminated string encoded in UTF-16 or UCS-2 format (endian machine dependent). Should not be SQLExecDirectW or did you enabled UNICODE define in Makefile/project file(s) ? > The Execute statement returns the following error information. > [FreeTDS][SQL Server]Incorrect syntax near > > Any help/inputs appreciated! > > Thanks, > Manasi Frediano _______________________________________________ FreeTDS mailing list FreeTDS at lists.ibiblio.org http://lists.ibiblio.org/mailman/listinfo/freetds -------------------------------------------------------------------------------------------------- This email and any attachments are confidential and are for the use of the addressee only. If you are not the addressee, you must not use or disclose the contents to any other person. Please immediately notify the sender and delete the email. Statements and opinions expressed here may not represent those of the company. Email correspondence is monitored by the company. This information may be subject to export control regulation. You are obliged to comply with such regulations. Renishaw plc (company number 1106260) and Wotton Travel Limited (company number 01973158) are companies registered in England and Wales with a registered office at New Mills, Wotton-under-Edge, Gloucestershire, GL12 8JR, United Kingdom, Telephone +44 1453 524524. -------------------------------------------------------------------------------------------------- From ikorot01 at gmail.com Tue Dec 1 08:16:38 2015 From: ikorot01 at gmail.com (Igor Korot) Date: Tue, 1 Dec 2015 08:16:38 -0500 Subject: [freetds] Syntax Error In-Reply-To: References: Message-ID: Hi, Couple of questions: On Sun, Nov 29, 2015 at 11:55 PM, Manasi Deshpande wrote: > Hello, > > We are using UTF-8 encoding and it is char that we are using! We aren't using wide APIs on Linux! > > In the FreeTDS config file we are specifying the client charset as UTF-8. > > Strange thing I observed was after commenting the following code the SQLExecDirect executes with SUCCESS. 1. What did you observe? > > // Specify the number of elements in each parameter array. > TRYODBC(hStmt, SQL_HANDLE_STMT, SQLSetStmtAttr(hStmt, SQL_ATTR_PARAMSET_SIZE, (SQLPOINTER)idCount, 0)); 2. What is TRYODBC()? > > // Specify an array in which to return the status of each set of > // parameters. > TRYODBC(hStmt, SQL_HANDLE_STMT, SQLSetStmtAttr(hStmt, SQL_ATTR_PARAM_STATUS_PTR, ParamStatusArray, idCount)); > > // Specify an SQLUINTEGER value in which to return the number of sets of > // parameters processed. > TRYODBC(hStmt, SQL_HANDLE_STMT, SQLSetStmtAttr(hStmt, SQL_ATTR_PARAMS_PROCESSED_PTR, &ParamsProcessed, 0)); > > > Also another point to notice is that, I have recently updated from freetds-0.91 and TDS version 7.1. The code worked seamlessly then! 3. What is your current freeTDS version and TDS protocol? 4. Did you turn on logging on the ODBC side and inspected the it? What did you see in both versions? Thank you. > > Regards, > Manasi > > -----Original Message----- > From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of Frediano Ziglio > Sent: 27 November 2015 20:19 > To: FreeTDS Development Group > Subject: Re: [freetds] Syntax Error > > 2015-11-27 10:21 GMT+00:00 Manasi Deshpande : >> Hello, >> >> Environment: >> Ubuntu 14.04 >> UnixOdbc-2.3.4 >> Built and installed from freetds-0.95.69 and TDS version is 7.3 >> >> Issue: >> In this we are trying to query DB with IDs to return a collection of items. >> >> RETCODE RetCode; >> SQLSMALLINT sNumResults; >> >> int idCount = 0; >> _INT64 *arrIds =ArrayOfIds.GetArray(); >> U_stringstream idStr; >> >> idStr << _U("("); >> >> for (int i = 0; i < idCount; i++) >> { >> idStr << arrIds[i]; >> if (i < idCount - 1) >> idStr << _U(","); >> } >> >> idStr << _U(")"); >> U_STRING idString = idStr.str(); >> >> SQLUSMALLINT ParamStatusArray[2]; >> SQLULEN ParamsProcessed; >> >> SQLHANDLE hStmt = dbCon.getStmtHandle(); >> SQLHANDLE hConn = dbCon.getConnHandle(); >> >> >> // Specify the number of elements in each parameter array. >> TRYODBC(hStmt, SQL_HANDLE_STMT, SQLSetStmtAttr(hStmt, >> SQL_ATTR_PARAMSET_SIZE, (SQLPOINTER)idCount, 0)); >> >> // Specify an array in which to return the status of each set of >> // parameters. >> TRYODBC(hStmt, SQL_HANDLE_STMT, SQLSetStmtAttr(hStmt, >> SQL_ATTR_PARAM_STATUS_PTR, ParamStatusArray, idCount)); >> >> // Specify an SQLUINTEGER value in which to return the number of sets of >> // parameters processed. >> TRYODBC(hStmt, SQL_HANDLE_STMT, SQLSetStmtAttr(hStmt, >> SQL_ATTR_PARAMS_PROCESSED_PTR, &ParamsProcessed, 0)); >> >> //Bind Parameters >> //TRYODBC(hStmt, SQL_HANDLE_STMT, SQLBindParameter(hStmt, >> 1, SQL_PARAM_INPUT, SQL_C_SLONG, SQL_INTEGER, 0, 0, arrIds, 0, NULL)); >> >> U_STRING query = _U("SELECT query WHERE ITEM.Id in ") + >> idString + _U(" ORDER BY ITEM.Id ASC"); >> > > I would first try with an easy query like "SELECT 1" > >> RetCode = SQLExecDirect(hStmt, (SQLTCHAR*)query.c_str(), >> SQL_NTS); >> > > In which encoding the U_STRING store the string. No, Unicode is not enough (if you don't specify the version). > > From the code above query.c_str() should return a NUL-terminated string encoded in UTF-16 or UCS-2 format (endian machine dependent). > > Should not be SQLExecDirectW or did you enabled UNICODE define in Makefile/project file(s) ? > >> The Execute statement returns the following error information. >> [FreeTDS][SQL Server]Incorrect syntax near >> >> Any help/inputs appreciated! >> >> Thanks, >> Manasi > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > -------------------------------------------------------------------------------------------------- > This email and any attachments are confidential and are for the use of the > addressee only. If you are not the addressee, you must not use or disclose the > contents to any other person. Please immediately notify the sender and > delete the email. Statements and opinions expressed here may not > represent those of the company. Email correspondence is monitored by > the company. This information may be subject to export control > regulation. You are obliged to comply with such regulations. > > Renishaw plc (company number 1106260) and Wotton Travel Limited (company > number 01973158) are companies registered in England and Wales with a registered office > at New Mills, Wotton-under-Edge, Gloucestershire, GL12 8JR, > United Kingdom, Telephone +44 1453 524524. > -------------------------------------------------------------------------------------------------- > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From ikorot01 at gmail.com Tue Dec 1 08:17:23 2015 From: ikorot01 at gmail.com (Igor Korot) Date: Tue, 1 Dec 2015 08:17:23 -0500 Subject: [freetds] Syntax Error In-Reply-To: References: Message-ID: Sorry one more thing: What is you DB version? On Tue, Dec 1, 2015 at 8:16 AM, Igor Korot wrote: > Hi, > Couple of questions: > > On Sun, Nov 29, 2015 at 11:55 PM, Manasi Deshpande > wrote: >> Hello, >> >> We are using UTF-8 encoding and it is char that we are using! We aren't using wide APIs on Linux! >> >> In the FreeTDS config file we are specifying the client charset as UTF-8. >> >> Strange thing I observed was after commenting the following code the SQLExecDirect executes with SUCCESS. > > 1. What did you observe? > >> >> // Specify the number of elements in each parameter array. >> TRYODBC(hStmt, SQL_HANDLE_STMT, SQLSetStmtAttr(hStmt, SQL_ATTR_PARAMSET_SIZE, (SQLPOINTER)idCount, 0)); > > 2. What is TRYODBC()? > >> >> // Specify an array in which to return the status of each set of >> // parameters. >> TRYODBC(hStmt, SQL_HANDLE_STMT, SQLSetStmtAttr(hStmt, SQL_ATTR_PARAM_STATUS_PTR, ParamStatusArray, idCount)); >> >> // Specify an SQLUINTEGER value in which to return the number of sets of >> // parameters processed. >> TRYODBC(hStmt, SQL_HANDLE_STMT, SQLSetStmtAttr(hStmt, SQL_ATTR_PARAMS_PROCESSED_PTR, &ParamsProcessed, 0)); >> >> >> Also another point to notice is that, I have recently updated from freetds-0.91 and TDS version 7.1. The code worked seamlessly then! > > 3. What is your current freeTDS version and TDS protocol? > > 4. Did you turn on logging on the ODBC side and inspected the it? What > did you see in both versions? > > Thank you. > >> >> Regards, >> Manasi >> >> -----Original Message----- >> From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of Frediano Ziglio >> Sent: 27 November 2015 20:19 >> To: FreeTDS Development Group >> Subject: Re: [freetds] Syntax Error >> >> 2015-11-27 10:21 GMT+00:00 Manasi Deshpande : >>> Hello, >>> >>> Environment: >>> Ubuntu 14.04 >>> UnixOdbc-2.3.4 >>> Built and installed from freetds-0.95.69 and TDS version is 7.3 >>> >>> Issue: >>> In this we are trying to query DB with IDs to return a collection of items. >>> >>> RETCODE RetCode; >>> SQLSMALLINT sNumResults; >>> >>> int idCount = 0; >>> _INT64 *arrIds =ArrayOfIds.GetArray(); >>> U_stringstream idStr; >>> >>> idStr << _U("("); >>> >>> for (int i = 0; i < idCount; i++) >>> { >>> idStr << arrIds[i]; >>> if (i < idCount - 1) >>> idStr << _U(","); >>> } >>> >>> idStr << _U(")"); >>> U_STRING idString = idStr.str(); >>> >>> SQLUSMALLINT ParamStatusArray[2]; >>> SQLULEN ParamsProcessed; >>> >>> SQLHANDLE hStmt = dbCon.getStmtHandle(); >>> SQLHANDLE hConn = dbCon.getConnHandle(); >>> >>> >>> // Specify the number of elements in each parameter array. >>> TRYODBC(hStmt, SQL_HANDLE_STMT, SQLSetStmtAttr(hStmt, >>> SQL_ATTR_PARAMSET_SIZE, (SQLPOINTER)idCount, 0)); >>> >>> // Specify an array in which to return the status of each set of >>> // parameters. >>> TRYODBC(hStmt, SQL_HANDLE_STMT, SQLSetStmtAttr(hStmt, >>> SQL_ATTR_PARAM_STATUS_PTR, ParamStatusArray, idCount)); >>> >>> // Specify an SQLUINTEGER value in which to return the number of sets of >>> // parameters processed. >>> TRYODBC(hStmt, SQL_HANDLE_STMT, SQLSetStmtAttr(hStmt, >>> SQL_ATTR_PARAMS_PROCESSED_PTR, &ParamsProcessed, 0)); >>> >>> //Bind Parameters >>> //TRYODBC(hStmt, SQL_HANDLE_STMT, SQLBindParameter(hStmt, >>> 1, SQL_PARAM_INPUT, SQL_C_SLONG, SQL_INTEGER, 0, 0, arrIds, 0, NULL)); >>> >>> U_STRING query = _U("SELECT query WHERE ITEM.Id in ") + >>> idString + _U(" ORDER BY ITEM.Id ASC"); >>> >> >> I would first try with an easy query like "SELECT 1" >> >>> RetCode = SQLExecDirect(hStmt, (SQLTCHAR*)query.c_str(), >>> SQL_NTS); >>> >> >> In which encoding the U_STRING store the string. No, Unicode is not enough (if you don't specify the version). >> >> From the code above query.c_str() should return a NUL-terminated string encoded in UTF-16 or UCS-2 format (endian machine dependent). >> >> Should not be SQLExecDirectW or did you enabled UNICODE define in Makefile/project file(s) ? >> >>> The Execute statement returns the following error information. >>> [FreeTDS][SQL Server]Incorrect syntax near >>> >>> Any help/inputs appreciated! >>> >>> Thanks, >>> Manasi >> >> Frediano >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> http://lists.ibiblio.org/mailman/listinfo/freetds >> -------------------------------------------------------------------------------------------------- >> This email and any attachments are confidential and are for the use of the >> addressee only. If you are not the addressee, you must not use or disclose the >> contents to any other person. Please immediately notify the sender and >> delete the email. Statements and opinions expressed here may not >> represent those of the company. Email correspondence is monitored by >> the company. This information may be subject to export control >> regulation. You are obliged to comply with such regulations. >> >> Renishaw plc (company number 1106260) and Wotton Travel Limited (company >> number 01973158) are companies registered in England and Wales with a registered office >> at New Mills, Wotton-under-Edge, Gloucestershire, GL12 8JR, >> United Kingdom, Telephone +44 1453 524524. >> -------------------------------------------------------------------------------------------------- >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> http://lists.ibiblio.org/mailman/listinfo/freetds From Manasi.Deshpande at Renishaw.com Wed Dec 2 05:41:48 2015 From: Manasi.Deshpande at Renishaw.com (Manasi Deshpande) Date: Wed, 2 Dec 2015 10:41:48 +0000 Subject: [freetds] Syntax Error In-Reply-To: References: Message-ID: 1. When the SQLSetStmtAttr code was commented, SQLExecDirect executes with SUCCESS. Else it returns "Error [FreeTDS][SQL Server]Incorrect syntax near" 2. TRYODBC is just a #define #define TRYODBC(h, ht, x) { RETCODE rc = x;\ if (rc != SQL_SUCCESS) \ { \ HandleDiagnosticRecord (h, ht, rc); \ } \ if (rc == SQL_ERROR) \ { \ fprintf(stderr, "Error in " #x "\n"); \ } \ } 3. Version: freetds v0.95.69 and TDS protocol version 7.3 4. Logging is not enabled as of now! 5. DB version is SQL Server 2008 R2 Regards, Manasi -----Original Message----- From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of Igor Korot Sent: 01 December 2015 18:47 To: FreeTDS Development Group Subject: Re: [freetds] Syntax Error Sorry one more thing: What is you DB version? On Tue, Dec 1, 2015 at 8:16 AM, Igor Korot wrote: > Hi, > Couple of questions: > > On Sun, Nov 29, 2015 at 11:55 PM, Manasi Deshpande > wrote: >> Hello, >> >> We are using UTF-8 encoding and it is char that we are using! We aren't using wide APIs on Linux! >> >> In the FreeTDS config file we are specifying the client charset as UTF-8. >> >> Strange thing I observed was after commenting the following code the SQLExecDirect executes with SUCCESS. > > 1. What did you observe? > >> >> // Specify the number of elements in each parameter array. >> TRYODBC(hStmt, SQL_HANDLE_STMT, SQLSetStmtAttr(hStmt, >> SQL_ATTR_PARAMSET_SIZE, (SQLPOINTER)idCount, 0)); > > 2. What is TRYODBC()? > >> >> // Specify an array in which to return the status of each set of >> // parameters. >> TRYODBC(hStmt, SQL_HANDLE_STMT, SQLSetStmtAttr(hStmt, >> SQL_ATTR_PARAM_STATUS_PTR, ParamStatusArray, idCount)); >> >> // Specify an SQLUINTEGER value in which to return the number of sets of >> // parameters processed. >> TRYODBC(hStmt, SQL_HANDLE_STMT, SQLSetStmtAttr(hStmt, >> SQL_ATTR_PARAMS_PROCESSED_PTR, &ParamsProcessed, 0)); >> >> >> Also another point to notice is that, I have recently updated from freetds-0.91 and TDS version 7.1. The code worked seamlessly then! > > 3. What is your current freeTDS version and TDS protocol? > > 4. Did you turn on logging on the ODBC side and inspected the it? What > did you see in both versions? > > Thank you. > >> >> Regards, >> Manasi >> >> -----Original Message----- >> From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of >> Frediano Ziglio >> Sent: 27 November 2015 20:19 >> To: FreeTDS Development Group >> Subject: Re: [freetds] Syntax Error >> >> 2015-11-27 10:21 GMT+00:00 Manasi Deshpande : >>> Hello, >>> >>> Environment: >>> Ubuntu 14.04 >>> UnixOdbc-2.3.4 >>> Built and installed from freetds-0.95.69 and TDS version is 7.3 >>> >>> Issue: >>> In this we are trying to query DB with IDs to return a collection of items. >>> >>> RETCODE RetCode; >>> SQLSMALLINT sNumResults; >>> >>> int idCount = 0; >>> _INT64 *arrIds =ArrayOfIds.GetArray(); >>> U_stringstream idStr; >>> >>> idStr << _U("("); >>> >>> for (int i = 0; i < idCount; i++) >>> { >>> idStr << arrIds[i]; >>> if (i < idCount - 1) >>> idStr << _U(","); >>> } >>> >>> idStr << _U(")"); >>> U_STRING idString = idStr.str(); >>> >>> SQLUSMALLINT ParamStatusArray[2]; >>> SQLULEN ParamsProcessed; >>> >>> SQLHANDLE hStmt = dbCon.getStmtHandle(); >>> SQLHANDLE hConn = dbCon.getConnHandle(); >>> >>> >>> // Specify the number of elements in each parameter array. >>> TRYODBC(hStmt, SQL_HANDLE_STMT, SQLSetStmtAttr(hStmt, >>> SQL_ATTR_PARAMSET_SIZE, (SQLPOINTER)idCount, 0)); >>> >>> // Specify an array in which to return the status of each set of >>> // parameters. >>> TRYODBC(hStmt, SQL_HANDLE_STMT, SQLSetStmtAttr(hStmt, >>> SQL_ATTR_PARAM_STATUS_PTR, ParamStatusArray, idCount)); >>> >>> // Specify an SQLUINTEGER value in which to return the number of sets of >>> // parameters processed. >>> TRYODBC(hStmt, SQL_HANDLE_STMT, SQLSetStmtAttr(hStmt, >>> SQL_ATTR_PARAMS_PROCESSED_PTR, &ParamsProcessed, 0)); >>> >>> //Bind Parameters >>> //TRYODBC(hStmt, SQL_HANDLE_STMT, >>> SQLBindParameter(hStmt, 1, SQL_PARAM_INPUT, SQL_C_SLONG, >>> SQL_INTEGER, 0, 0, arrIds, 0, NULL)); >>> >>> U_STRING query = _U("SELECT query WHERE ITEM.Id in ") + >>> idString + _U(" ORDER BY ITEM.Id ASC"); >>> >> >> I would first try with an easy query like "SELECT 1" >> >>> RetCode = SQLExecDirect(hStmt, (SQLTCHAR*)query.c_str(), >>> SQL_NTS); >>> >> >> In which encoding the U_STRING store the string. No, Unicode is not enough (if you don't specify the version). >> >> From the code above query.c_str() should return a NUL-terminated string encoded in UTF-16 or UCS-2 format (endian machine dependent). >> >> Should not be SQLExecDirectW or did you enabled UNICODE define in Makefile/project file(s) ? >> >>> The Execute statement returns the following error information. >>> [FreeTDS][SQL Server]Incorrect syntax near >>> >>> Any help/inputs appreciated! >>> >>> Thanks, >>> Manasi >> >> Frediano >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> http://lists.ibiblio.org/mailman/listinfo/freetds >> --------------------------------------------------------------------- >> ----------------------------- This email and any attachments are >> confidential and are for the use of the addressee only. If you are >> not the addressee, you must not use or disclose the contents to any >> other person. Please immediately notify the sender and delete the >> email. Statements and opinions expressed here may not represent those >> of the company. Email correspondence is monitored by the company. >> This information may be subject to export control regulation. You are >> obliged to comply with such regulations. >> >> Renishaw plc (company number 1106260) and Wotton Travel Limited >> (company number 01973158) are companies registered in England and >> Wales with a registered office at New Mills, Wotton-under-Edge, >> Gloucestershire, GL12 8JR, United Kingdom, Telephone +44 1453 524524. >> --------------------------------------------------------------------- >> ----------------------------- >> _______________________________________________ >> 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 -------------------------------------------------------------------------------------------------- This email and any attachments are confidential and are for the use of the addressee only. If you are not the addressee, you must not use or disclose the contents to any other person. Please immediately notify the sender and delete the email. Statements and opinions expressed here may not represent those of the company. Email correspondence is monitored by the company. This information may be subject to export control regulation. You are obliged to comply with such regulations. Renishaw plc (company number 1106260) and Wotton Travel Limited (company number 01973158) are companies registered in England and Wales with a registered office at New Mills, Wotton-under-Edge, Gloucestershire, GL12 8JR, United Kingdom, Telephone +44 1453 524524. -------------------------------------------------------------------------------------------------- From janis.elmeris at intelligentsystems.lv Sat Dec 5 06:17:11 2015 From: janis.elmeris at intelligentsystems.lv (Janis Elmeris) Date: Sat, 5 Dec 2015 13:17:11 +0200 Subject: [freetds] Installing SQSH Message-ID: <5662C7B7.6030402@intelligentsystems.lv> Hello! I'm trying to install SQSH (http://www.freetds.org/userguide/software.htm#SQSH). I'm getting this error: gcc -g -O2 -DSQSH_RC='"/usr/local/etc/sqshrc:${HOME}/.sqshrc"' -DUSE_READLINE -I/usr/local/include -DSYB_LP64 -c -o cmd_connect.o cmd_connect.c cmd_connect.c: In function 'cmd_connect': cmd_connect.c:864:23: error: 'CS_TDS_80' undeclared (first use in this function) Can you give me any pointers, please? "src/Makefile" already has the line as described: "SYBASE_LIBS = -lct -ldl -lm" Regards, Janis From sfhacker at hotmail.com Sun Dec 6 04:47:01 2015 From: sfhacker at hotmail.com (Sergio NNX) Date: Sun, 6 Dec 2015 20:47:01 +1100 Subject: [freetds] Installing SQSH In-Reply-To: <5662C7B7.6030402@intelligentsystems.lv> References: <5662C7B7.6030402@intelligentsystems.lv> Message-ID: > I'm getting this error: > > gcc -g -O2 -DSQSH_RC='"/usr/local/etc/sqshrc:${HOME}/.sqshrc"' > -DUSE_READLINE -I/usr/local/include -DSYB_LP64 -c -o cmd_connect.o > cmd_connect.c cmd_connect.c: In function 'cmd_connect': > cmd_connect.c:864:23: error: 'CS_TDS_80' undeclared (first use in this > function) > > Can you give me any pointers, please? "src/Makefile" already has the > line as described: "SYBASE_LIBS = -lct -ldl -lm" Ciao Janis. You don't specify which version(s) you are using or building against. We are using FreeTDS 0.95.73 and we see no issues at all. Administrator at melbourne /src/sqsh-2.5/src $ sqsh.exe -v sqsh-2.5.16.1 From janis.elmeris at intelligentsystems.lv Mon Dec 7 03:50:03 2015 From: janis.elmeris at intelligentsystems.lv (Janis Elmeris) Date: Mon, 7 Dec 2015 10:50:03 +0200 Subject: [freetds] Installing SQSH In-Reply-To: References: <5662C7B7.6030402@intelligentsystems.lv> Message-ID: <5665483B.6020907@intelligentsystems.lv> Thanks for the reply! I found two tsql binaries installed: # /usr/bin/tsql -C Compile-time settings (established with the "configure" script) Version: freetds v0.91 freetds.conf directory: /etc MS db-lib source compatibility: yes Sybase binary compatibility: no Thread safety: yes iconv library: yes TDS version: 7.0 iODBC: no unixodbc: no SSPI "trusted" logins: no Kerberos: no # /usr/local/bin/tsql -C Compile-time settings (established with the "configure" script) Version: freetds v0.100.dev.20151204 freetds.conf directory: /usr/local/etc MS db-lib source compatibility: no Sybase binary compatibility: no Thread safety: yes iconv library: yes TDS version: auto iODBC: no unixodbc: yes SSPI "trusted" logins: no Kerberos: no OpenSSL: no GnuTLS: no MARS: no Janis On 2015.12.06. 11:47, Sergio NNX wrote: > > I'm getting this error: > > > > gcc -g -O2 -DSQSH_RC='"/usr/local/etc/sqshrc:${HOME}/.sqshrc"' > > -DUSE_READLINE -I/usr/local/include -DSYB_LP64 -c -o cmd_connect.o > > cmd_connect.c cmd_connect.c: In function 'cmd_connect': > > cmd_connect.c:864:23: error: 'CS_TDS_80' undeclared (first use in this > > function) > > > > Can you give me any pointers, please? "src/Makefile" already has the > > line as described: "SYBASE_LIBS = -lct -ldl -lm" > > Ciao Janis. > > You don't specify which version(s) you are using or building against. > > We are using FreeTDS 0.95.73 and we see no issues at all. > > Administrator at melbourne /src/sqsh-2.5/src > $ sqsh.exe -v > sqsh-2.5.16.1 > From paul.t.lueders.ctr at mail.mil Wed Dec 9 15:52:22 2015 From: paul.t.lueders.ctr at mail.mil (Lueders, Paul T CTR (US)) Date: Wed, 9 Dec 2015 20:52:22 +0000 Subject: [freetds] MSSQL encrypted connection Message-ID: I am attempting to access a mssql 2012 database from a RHEL 6 server. The database is configured to use encrypted connections. When I test the connection using either tsql of osql I get and error. What is the proper method of configuring the driver to allow an encrypted connection? Thanks From ikorot01 at gmail.com Wed Dec 9 16:11:07 2015 From: ikorot01 at gmail.com (Igor Korot) Date: Wed, 9 Dec 2015 16:11:07 -0500 Subject: [freetds] MSSQL encrypted connection In-Reply-To: References: Message-ID: Hi, Paul, On Wed, Dec 9, 2015 at 3:52 PM, Lueders, Paul T CTR (US) wrote: > I am attempting to access a mssql 2012 database from a RHEL 6 server. The database is configured to use encrypted connections. When I test the connection using either tsql of osql I get and error. > What is the proper method of configuring the driver to allow an encrypted connection? What error did you get? How did you configured freeTDS? And what version do you use? Thank you. > > Thanks > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From freddy77 at gmail.com Wed Dec 9 16:11:56 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Wed, 9 Dec 2015 21:11:56 +0000 Subject: [freetds] MSSQL encrypted connection In-Reply-To: References: Message-ID: 2015-12-09 20:52 GMT+00:00 Lueders, Paul T CTR (US) : > I am attempting to access a mssql 2012 database from a RHEL 6 server. The database is configured to use encrypted connections. When I test the connection using either tsql of osql I get and error. > What is the proper method of configuring the driver to allow an encrypted connection? > > Thanks Hi, looks at http://www.freetds.org/userguide/freetdsconf.htm and http://www.freetds.org/userguide/odbcconnattr.htm (if you are using ODBC) and search for "encryption". Use "tsql -C" command to understand if either GnuTLS or OpenSSL (required for encryptions connection) are enabled. Frediano From ikorot01 at gmail.com Wed Dec 9 16:12:05 2015 From: ikorot01 at gmail.com (Igor Korot) Date: Wed, 9 Dec 2015 16:12:05 -0500 Subject: [freetds] MSSQL encrypted connection In-Reply-To: References: Message-ID: Paul, On Wed, Dec 9, 2015 at 3:52 PM, Lueders, Paul T CTR (US) wrote: > I am attempting to access a mssql 2012 database from a RHEL 6 server. The database is configured to use encrypted connections. When I test the connection using either tsql of osql I get and error. > What is the proper method of configuring the driver to allow an encrypted connection? Also, are you using ODBC or ct-lib/db-lib layer? Thank you. > > Thanks > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From paul.t.lueders.ctr at mail.mil Wed Dec 9 19:29:48 2015 From: paul.t.lueders.ctr at mail.mil (Lueders, Paul T CTR (US)) Date: Thu, 10 Dec 2015 00:29:48 +0000 Subject: [freetds] [Non-DoD Source] Re: MSSQL encrypted connection In-Reply-To: References: Message-ID: There is the problem neither are enabled. I will recompile freetds. -----Original Message----- From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of Frediano Ziglio Sent: Wednesday, December 09, 2015 4:12 PM To: FreeTDS Development Group Subject: [Non-DoD Source] Re: [freetds] MSSQL encrypted connection All active links contained in this email were disabled. Please verify the identity of the sender, and confirm the authenticity of all links contained within the message prior to copying and pasting the address to a Web browser. ---- 2015-12-09 20:52 GMT+00:00 Lueders, Paul T CTR (US) : > I am attempting to access a mssql 2012 database from a RHEL 6 server. The database is configured to use encrypted connections. When I test the connection using either tsql of osql I get and error. > What is the proper method of configuring the driver to allow an encrypted connection? > > Thanks Hi, looks at Caution-http://www.freetds.org/userguide/freetdsconf.htm and Caution-http://www.freetds.org/userguide/odbcconnattr.htm (if you are using ODBC) and search for "encryption". Use "tsql -C" command to understand if either GnuTLS or OpenSSL (required for encryptions connection) are enabled. Frediano _______________________________________________ FreeTDS mailing list FreeTDS at lists.ibiblio.org Caution-http://lists.ibiblio.org/mailman/listinfo/freetds From joshua.h.lang at gmail.com Thu Dec 10 14:02:49 2015 From: joshua.h.lang at gmail.com (Joshua Lang) Date: Thu, 10 Dec 2015 11:02:49 -0800 Subject: [freetds] VARCHAR values > 8000 bytes truncated (db-lib) Message-ID: When trying to pass stored procedure VARCHAR(MAX) parameters (using SYBVARCHAR for the parameter type), the value is truncated at 8000. This is due to the `tds_fix_column_size` method limiting the value to 8000 because the `column_varint_size` of the column == 2. Based on the comment in `tds_fix_column_size` (src/tds/query.c), it seems as if this is unexpected: /* note that varchar(max)/varbinary(max) have a varint of 8 */ The comment above indicates that this should be supported. Am I missing something or using the db-lib API incorrectly? My code is working fine otherwise. freetds: 0.95.73 OS: Ubuntu 14.04 DB: MS SQL Server 2008 SP3 TDS: 7.3 Thanks -j From freddy77 at gmail.com Wed Dec 16 06:24:54 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Wed, 16 Dec 2015 11:24:54 +0000 Subject: [freetds] Problems with wireshark Message-ID: Hi Johnny, I fixed the problem with tds_env_change you reported. Now wireshark should not complains Regards, Frediano From joshua.h.lang at gmail.com Fri Dec 18 15:06:49 2015 From: joshua.h.lang at gmail.com (Joshua Lang) Date: Fri, 18 Dec 2015 12:06:49 -0800 Subject: [freetds] Bug in dblib CHECK_CONN macro? Message-ID: It seems that once the TDS socket on a dblib connection becomes invalid, the error handling no long er references the connection, even though it seems as though it should? Perhaps I'm missing something? This is causing subsequent uses of the DBPROCESS pointer to fail (as they should), but the resulting error is not correctly associated with the DBPROCESS. See below for a patch. Note that dbproc is passed instead of NULL to dbperror. diff --git a/include/dblib.h b/include/dblib.h index e03ccaa..019c99d 100644 --- a/include/dblib.h +++ b/include/dblib.h @@ -199,7 +199,7 @@ extern EHANDLEFUNC _dblib_err_handler; #define DBPERROR_RETURN(x, msg) if (x) { dbperror(dbproc, (msg), 0); return FAIL; } #define DBPERROR_RETURN3(x, msg, a, b, c) if (x) { dbperror(dbproc, (msg), 0, a, b, c); return FAIL; } #define CHECK_CONN(ret) do { CHECK_PARAMETER(dbproc, SYBENULL, (ret)); \ - if (IS_TDSDEAD(dbproc->tds_socket)) { dbperror(NULL, SYBEDDNE, 0); return (ret); } } while(0) + if (IS_TDSDEAD(dbproc->tds_socket)) { dbperror(dbproc, SYBEDDNE, 0); return (ret); } } while(0) #ifdef __cplusplus From freddy77 at gmail.com Sat Dec 19 05:01:16 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Sat, 19 Dec 2015 10:01:16 +0000 Subject: [freetds] Bug in dblib CHECK_CONN macro? In-Reply-To: References: Message-ID: 2015-12-18 20:06 GMT+00:00 Joshua Lang : > It seems that once the TDS socket on a dblib connection becomes invalid, > the error handling no long er references the connection, even though it > seems as though it should? Perhaps I'm missing something? This is causing > subsequent uses of the DBPROCESS pointer to fail (as they should), but the > resulting error is not correctly associated with the DBPROCESS. > > See below for a patch. Note that dbproc is passed instead of NULL to > dbperror. > > diff --git a/include/dblib.h b/include/dblib.h > index e03ccaa..019c99d 100644 > --- a/include/dblib.h > +++ b/include/dblib.h > @@ -199,7 +199,7 @@ extern EHANDLEFUNC _dblib_err_handler; > #define DBPERROR_RETURN(x, msg) if (x) { dbperror(dbproc, (msg), > 0); return FAIL; } > #define DBPERROR_RETURN3(x, msg, a, b, c) if (x) { dbperror(dbproc, > (msg), 0, a, b, c); return FAIL; } > #define CHECK_CONN(ret) do { CHECK_PARAMETER(dbproc, SYBENULL, (ret)); \ > - if (IS_TDSDEAD(dbproc->tds_socket)) { dbperror(NULL, SYBEDDNE, 0); > return (ret); } } while(0) > + if (IS_TDSDEAD(dbproc->tds_socket)) { dbperror(dbproc, SYBEDDNE, > 0); return (ret); } } while(0) > > > #ifdef __cplusplus Well spot! https://github.com/FreeTDS/freetds/commit/420141cc10a8f0110e1c6773d3487c4b085af9a2 (also in 0.95) Frediano From ken at metaskills.net Sun Dec 20 16:30:39 2015 From: ken at metaskills.net (Ken Collins) Date: Sun, 20 Dec 2015 16:30:39 -0500 Subject: [freetds] 0.95.latest defncopy Message-ID: I keep getting the following error when using defncopy. Assertion failed: (ret >= 0), function print_ddl, file defncopy.c, line 511. This error happens despite what table/object I point it at. Could someone give me a sanity check that 0.95.latest defncopy ?works for them? ?- Thanks in advance, ? ? Ken Collins From freddy77 at gmail.com Wed Dec 23 05:06:10 2015 From: freddy77 at gmail.com (Frediano Ziglio) Date: Wed, 23 Dec 2015 10:06:10 +0000 Subject: [freetds] VARCHAR values > 8000 bytes truncated (db-lib) In-Reply-To: References: Message-ID: Il 11/Dic/2015 13:12, "Joshua Lang" ha scritto: > > When trying to pass stored procedure VARCHAR(MAX) parameters (using > SYBVARCHAR for the parameter type), the value is truncated at 8000. This is > due to the `tds_fix_column_size` method limiting the value to 8000 because > the `column_varint_size` of the column == 2. > > Based on the comment in `tds_fix_column_size` (src/tds/query.c), it seems > as if this is unexpected: > > /* note that varchar(max)/varbinary(max) have a varint of 8 */ > > The comment above indicates that this should be supported. Am I missing > something or using the db-lib API incorrectly? My code is working fine > otherwise. > > > > > freetds: 0.95.73 > OS: Ubuntu 14.04 > DB: MS SQL Server 2008 SP3 > TDS: 7.3 > > Thanks > Hi, Varchar(max) is more similar to text than to normal varchar so type is not promoted. I don't remember if text is promoted to varchar(max) under dblib. Frediano