From no-reply at appveyor.com Tue Jan 5 13:34:41 2016 From: no-reply at appveyor.com (AppVeyor) Date: Tue, 05 Jan 2016 18:34:41 +0000 Subject: [freetds] Build failed: freetds 368 Message-ID: <20160105183441.21388.15683@appveyor.com> From no-reply at appveyor.com Wed Jan 6 05:33:13 2016 From: no-reply at appveyor.com (AppVeyor) Date: Wed, 06 Jan 2016 10:33:13 +0000 Subject: [freetds] Build failed: freetds 375 Message-ID: <20160106103312.53712.78745@appveyor.com> From no-reply at appveyor.com Wed Jan 6 06:06:10 2016 From: no-reply at appveyor.com (AppVeyor) Date: Wed, 06 Jan 2016 11:06:10 +0000 Subject: [freetds] Build failed: freetds 377 Message-ID: <20160106110610.3367.98132@appveyor.com> From esterniclos at gmail.com Thu Jan 7 04:31:46 2016 From: esterniclos at gmail.com (esterniclos at gmail.com) Date: Thu, 07 Jan 2016 10:31:46 +0100 Subject: [freetds] SQL Cluster always on Message-ID: <1452159106.2592.14.camel@gmail.com> Hello everyone, We would like to adapt freetds to SQL Server Always On Clustering. This kind of cluster is pretty simple: Every database has associated a Listener with a dns name. E.g. dblistener.myorg.com Every listener has 2 or more IPs associated: nslookup dblistener.myorg.com responds something like: 10.57.3.2 and 10.57.4.52 Only one of the IP's serves the database (active-passive) The connection has to be made directly to the listener. and use the IP that is working at that moment. TDS Behaviour at this point. Right now, TDS works as long as the listener is in the first node. In the example dblistener.myorg.com instance working in 10.57.3.2 If the database is moved to another instance, it returns a timeout. Never checks the rest of IPs Possible solution Try to login in several times with as many objects as IP's are in DNS: tds/login.c:tds_set_host(TDSLOGIN * tds_login, const char *hostname) This would penalize a little when the database is in the backup instance, as it has to receive a timeout before making the connection. To speed up things, the last IP where the database was seen could be also stored, and only ask dns if there is a time out. Thank you for your time, and any advice is welcome. Ester Nicl?s Ferreras From james.k.lowden at icloud.com Thu Jan 7 10:18:54 2016 From: james.k.lowden at icloud.com (James K. Lowden) Date: Thu, 07 Jan 2016 10:18:54 -0500 Subject: [freetds] SQL Cluster always on In-Reply-To: <1452159106.2592.14.camel@gmail.com> References: <1452159106.2592.14.camel@gmail.com> Message-ID: <20160107101854.a8d2906ba3fb238a0340850a@icloud.com> On Thu, 07 Jan 2016 10:31:46 +0100 "esterniclos at gmail.com" wrote: > Right now, TDS works as long as the listener is in the first node. > In the example > dblistener.myorg.com instance working in 10.57.3.2 > > If the database is moved to another instance, it returns a > timeout. Never checks the rest of IPs > > Possible solution > > Try to login in several times with as many objects as IP's are > in DNS: > > tds/login.c:tds_set_host(TDSLOGIN * tds_login, > const char *hostname) > > > This would penalize a little when the database is in the > backup instance, as it has to receive a timeout before making the > connection. Yours is a good idea. Don't worry about the delay introduced by timing out on the primary, because the delay will normally be less than 1 second, provided DNS is working. A failed node will not accept a connection on SQL Server's port if SQL Server isn't running. $ time -p tsql -H www.freetds.org -p 8000 locale is "en_US.UTF-8" locale charset is "UTF-8" using default charset "UTF-8" There was a problem connecting to the server real 0.13 user 0.00 sys 0.00 It's very unusual for SQL Server to be running, accepting connections, and timing out on logins. In any case, if the delay is important, the configuration can be changed while the backup is in use. HTH. --jkl From mithrazor at gmail.com Mon Jan 11 09:13:51 2016 From: mithrazor at gmail.com (Bilal Hasan) Date: Mon, 11 Jan 2016 08:13:51 -0600 Subject: [freetds] Can connect with tsql but not with isql Message-ID: <5693b8a1.e141b60a.83f78.fffff804@mx.google.com> From freddy77 at gmail.com Tue Jan 12 06:48:22 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Tue, 12 Jan 2016 11:48:22 +0000 Subject: [freetds] Can connect with tsql but not with isql In-Reply-To: <5693b8a1.e141b60a.83f78.fffff804@mx.google.com> References: <5693b8a1.e141b60a.83f78.fffff804@mx.google.com> Message-ID: > From: Bilal Hasan > To: freetds at lists.ibiblio.org > Cc: > Date: Mon, 11 Jan 2016 08:13:51 -0600 > Subject: Can connect with tsql but not with isql > > I'm having an issue where I can connect to tsql but not through isql and DBD:ODBC which is my end goal. With DBD:ODBC it doesn't complain about not being able to connect. But I don't receive any data. > > I connect to tsql using: > > tsql -S MyDB-U MyUser > > But when I try to connect specifying the password in the command > ie: tsql -S MyDB -U MyUser -P MyPass > That's weird. Are you sure you don't need to quote your password as containing strange characters? > It gives me the following error: > > locale is "en_US.UTF-8" > locale charset is "UTF-8" > using default charset "UTF-8" > Msg 18456 (severity 14, state 1) from ELEONIE-VM4\SCMSERVER Line 1: > "Login failed for user 'MyUser'." > Error 20002 (severity 9): > Adaptive Server connection failed > There was a problem connecting to the server > > Now, when I try to connect using isql, I get a plain old data source not found error: > > [S1000][unixODBC][FreeTDS][SQL Server]Unable to connect to data source > [37000][unixODBC][FreeTDS][SQL Server]Login failed for user 'RNDCIQReader'. > [ISQL]ERROR: Could not SQLConnect > > > > Below is my odbc.ini: > > [MSSQL-MyDB] > Driver = FreeTDS > Servername = MyDB > Port = 1433 Already in freetds.conf > TDS Version = 8 Here should be TDS_Version or better remove as already in freetds.conf > Thread safety: yes weird syntax and I don't think is supported. > Database = MyDB > UID = MyUser > PWD = MyPass > UID/PWD ignored > > Below is my freetds.conf: > > # $Id: freetds.conf,v 1.12 2007/12/25 06:02:36 jklowden Exp $ > # > # This file is installed by FreeTDS if no file by the same > # name is found in the installation directory. > # > # For information about the layout of this file and its settings, > # see the freetds.conf manpage "man freetds.conf". > > # Global settings are overridden by those in a database > # server specific section > [global] > # TDS protocol version > ; tds version = 4.2 > > # Whether to write a TDSDUMP file for diagnostic purposes > # (setting this to /tmp is insecure on a multi-user system) > ; dump file = /tmp/freetds.log > ; debug flags = 0xffff > > # Command and connection timeouts > ; timeout = 10 > ; connect timeout = 10 > # If you get out-of-memory errors, it may mean that your client > # is trying to allocate a huge buffer for a TEXT field. > # Try setting 'text size' to a more reasonable limit > text size = 64512 > > # A typical Sybase server > [egServer50] > host = symachine.domain.com > port = 5000 > tds version = 5.0 > > # A typical Microsoft server > [egServer70] > host = ntmachine.domain.com > port = 1433 > tds version = 7.0 > > [MyDB] > host = ***.**.**.*** > port = 1433 > tds version = 8 > 8 does not make sense. 8.0 is obsolete. See http://www.freetds.org/userguide/choosingtdsprotocol.htm > > And below is my odbcinst.ini file: > > # Example driver definitions > > # Driver from the postgresql-odbc package > # Setup from the unixODBC package > [PostgreSQL] > Description = ODBC for PostgreSQL > Driver = /usr/lib/psqlodbc.so > Setup = /usr/lib/libodbcpsqlS.so > Driver64 = /usr/lib64/psqlodbc.so > Setup64 = /usr/lib64/libodbcpsqlS.so > FileUsage = 1 > > > # Driver from the mysql-connector-odbc package > # Setup from the unixODBC package > [MySQL] > Description = ODBC for MySQL > Driver = /usr/lib/libmyodbc5.so > Setup = /usr/lib/libodbcmyS.so > Driver64 = /usr/lib64/libmyodbc5.so > Setup64 = /usr/lib64/libodbcmyS.so > FileUsage = 1 > > > [FreeTDS] > Description = ODBC for Microsoft SQL > Setup = /usr/lib/libtdsS.so Here you can use /usr/lib/libtdsodbc.so.0 too. > Driver = /usr/lib/libtdsodbc.so.0 > Driver64 = /usr/lib64/libtdsodbc.so.0 > Setup64 = /usr/lib64/libtdsS.so Did you compile 32 and 64 bit versions? > UsageCount = 1 > Threading = 2 > Why? Are you using an old unixODBC version, default is not working or did you have issues with FreeTDS? > > I've been looking for a way to fix this for a couple days now. Please help! Any information would be appreciated > Frediano From joshua.h.lang at gmail.com Fri Jan 15 20:41:34 2016 From: joshua.h.lang at gmail.com (Joshua Lang) Date: Fri, 15 Jan 2016 17:41:34 -0800 Subject: [freetds] Empty VARCHAR parameters converted to NULL Message-ID: In the latest version of FreeTDS-dblib (0.95.79) I'm passing rpc VARCHAR parameters of 0 length, but non-NULL (empty strings). FreeTDS seems to turn these into NULL values before passing them on to SQL Server. From what I've read, it seems as if older databases didn't support passing empty strings, but newer ones do? (i.e. TDS 7.0+ do support empty strings). It seems as this is a known issue, but I was wondering if it is possible to fix it for the newer versions of SQL server? E.g. in dbrpcparam() passing a non-NULL pointer to the 'value' parameter and a 0 to 'datalen' would indicate an empty string is desired if possible. Thoughts? From freddy77 at gmail.com Tue Jan 19 05:52:15 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Tue, 19 Jan 2016 10:52:15 +0000 Subject: [freetds] Empty VARCHAR parameters converted to NULL In-Reply-To: References: Message-ID: 2016-01-16 1:41 GMT+00:00 Joshua Lang : > In the latest version of FreeTDS-dblib (0.95.79) I'm passing rpc VARCHAR > parameters of 0 length, but non-NULL (empty strings). FreeTDS seems to turn > these into NULL values before passing them on to SQL Server. From what I've > read, it seems as if older databases didn't support passing empty strings, > but newer ones do? (i.e. TDS 7.0+ do support empty strings). > > It seems as this is a known issue, but I was wondering if it is possible to > fix it for the newer versions of SQL server? E.g. in dbrpcparam() passing a > non-NULL pointer to the 'value' parameter and a 0 to 'datalen' would > indicate an empty string is desired if possible. > > Thoughts? The main problem is not libTDS (the code library) but dbrpcparam specification. datalen < 0 is invalid for variable fields (like VARCHAR) and 0 is used for NULL value (no matter the data pointer). But looks like your suggestion (not NULL value and 0 datalen) could be a good choice. Not sure however if this could work with all types and server versions (for instance 0 size TEXT). We can do it but I'm not thinking about backporting it to 0.95. Frediano From joshua.h.lang at gmail.com Tue Jan 19 13:25:04 2016 From: joshua.h.lang at gmail.com (Joshua Lang) Date: Tue, 19 Jan 2016 10:25:04 -0800 Subject: [freetds] Empty VARCHAR parameters converted to NULL In-Reply-To: References: Message-ID: I've read that older versions didn't even support passing 0-length data (prior to TDS 7.0 I believe). If this could be supported for later versions of TDS 7.0, that would be great. Thanks. On Tue, Jan 19, 2016 at 2:52 AM, Frediano Ziglio wrote: > 2016-01-16 1:41 GMT+00:00 Joshua Lang : > > In the latest version of FreeTDS-dblib (0.95.79) I'm passing rpc VARCHAR > > parameters of 0 length, but non-NULL (empty strings). FreeTDS seems to > turn > > these into NULL values before passing them on to SQL Server. From what > I've > > read, it seems as if older databases didn't support passing empty > strings, > > but newer ones do? (i.e. TDS 7.0+ do support empty strings). > > > > It seems as this is a known issue, but I was wondering if it is possible > to > > fix it for the newer versions of SQL server? E.g. in dbrpcparam() > passing a > > non-NULL pointer to the 'value' parameter and a 0 to 'datalen' would > > indicate an empty string is desired if possible. > > > > Thoughts? > > > The main problem is not libTDS (the code library) but dbrpcparam > specification. > datalen < 0 is invalid for variable fields (like VARCHAR) and 0 is used > for NULL > value (no matter the data pointer). But looks like your suggestion > (not NULL value > and 0 datalen) could be a good choice. > Not sure however if this could work with all types and server versions > (for instance > 0 size TEXT). > We can do it but I'm not thinking about backporting it to 0.95. > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > From ruslan.sivak at reis.com Mon Jan 25 15:52:15 2016 From: ruslan.sivak at reis.com (Russ Sivak) Date: Mon, 25 Jan 2016 15:52:15 -0500 Subject: [freetds] FreeTDS slow with SQL Server 2014 Message-ID: <56A68AFF.7020708@reis.com> We have been using SQL Server 2008 and things have been good. Recently we have upgraded to SQL Server 2014 and things have become VERY slow. We are using FreeTDS freetds-0.91-2.el6.x86_64, which is the latest from EPEL that for CentOS 6. This communication (including any attachments) is intended solely for the recipient(s) named above and may contain information that is confidential, privileged or legally protected. Any unauthorized use or dissemination of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender by return e-mail message and delete all copies of the original communication. Thank you for your cooperation. From randy at thesyrings.us Mon Jan 25 17:30:28 2016 From: randy at thesyrings.us (Randy Syring) Date: Mon, 25 Jan 2016 17:30:28 -0500 Subject: [freetds] FreeTDS slow with SQL Server 2014 In-Reply-To: <56A68AFF.7020708@reis.com> References: <56A68AFF.7020708@reis.com> Message-ID: <56A6A204.9070608@thesyrings.us> Since 0.95 has been released: http://www.freetds.org/news.html I'm sure it would be helpful to know if you have the same problem with the latest stable version. *Randy Syring* Husband | Father | Redeemed Sinner /"For what does it profit a man to gain the whole world and forfeit his soul?" (Mark 8:36 ESV)/ On 01/25/2016 03:52 PM, Russ Sivak wrote: > We have been using SQL Server 2008 and things have been good. > > Recently we have upgraded to SQL Server 2014 and things have become VERY > slow. We are using FreeTDS freetds-0.91-2.el6.x86_64, which is the > latest from EPEL that for CentOS 6. > > > > > > > > This communication (including any attachments) is intended solely for the > recipient(s) named above and may contain information that is confidential, > privileged or legally protected. Any unauthorized use or dissemination of this > communication is strictly prohibited. If you have received this communication in > error, please immediately notify the sender by return e-mail message and delete > all copies of the original communication. Thank you for your cooperation. > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > From ruslan.sivak at reis.com Mon Jan 25 17:51:27 2016 From: ruslan.sivak at reis.com (Russ Sivak) Date: Mon, 25 Jan 2016 17:51:27 -0500 Subject: [freetds] FreeTDS slow with SQL Server 2014 In-Reply-To: <56A6A204.9070608@thesyrings.us> References: <56A68AFF.7020708@reis.com> <56A6A204.9070608@thesyrings.us> Message-ID: <56A6A6EF.9000704@reis.com> I have installed the latest from source and am experiencing the same slowness. While I can make the slowness go away by messing with the tds version in the config file using version 0.91, I can't seem to do the same in 0.95. At the higher TDS version, however, I am seeing weird behavior in 0.91 in that varchar columns are showing up as length 255, even though they are longer in the database. The operation that we are testing is an insert using executemany with about 30k records. Russ On 1/25/2016 5:30 PM, Randy Syring wrote: > Since 0.95 has been released: > > http://cp.mcafee.com/d/5fHCMUp3zqb3X8VN6XW9KVJeUVNBUs-yedFEIILL8CzCUUSDssUOYevhd79IKyryTg_otihDiEazYGsKrzYGsKrR5fndsvW_fCzBAsMCeWZOWqqaf8EKnvhhuWyaqRQRrIcYG7DR8OJMddECSjt-jLuZXTLuVKVI04X7_Cxjw0egYNjwsrtz_PgEn8lrxrW0E-l9QWh2h0-lu00CTTD1NI5-Aq83iSX7_CxgQKCy0nz_wAe63h1g-FwQg69j9Cy0o0saCy0o-9DUCy1eWb1Jwsrvn8x > > > I'm sure it would be helpful to know if you have the same problem with > the latest stable version. > > *Randy Syring* > Husband | Father | Redeemed Sinner > > /"For what does it profit a man to gain the whole world > and forfeit his soul?" (Mark 8:36 ESV)/ > > On 01/25/2016 03:52 PM, Russ Sivak wrote: >> We have been using SQL Server 2008 and things have been good. >> >> Recently we have upgraded to SQL Server 2014 and things have become VERY >> slow. We are using FreeTDS freetds-0.91-2.el6.x86_64, which is the >> latest from EPEL that for CentOS 6. >> >> >> >> >> >> >> >> This communication (including any attachments) is intended solely for >> the >> recipient(s) named above and may contain information that is >> confidential, >> privileged or legally protected. Any unauthorized use or >> dissemination of this >> communication is strictly prohibited. If you have received this >> communication in >> error, please immediately notify the sender by return e-mail message >> and delete >> all copies of the original communication. Thank you for your >> cooperation. >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> http://cp.mcafee.com/d/2DRPoArhovp7e8TvhdTdFT7ecL3DQhNJd5BBZV4QsT76QXzD6nxPW9EVdBQjsmW7X3GicWl1kvBjBPsvBjBPuEFWVHz_nVYQsIzC4NTnKnjjhhV55OXWabTkhjmKCHtxDBgY-F6lK1FJcSOrLOtXTLuZXTdTdw0PVkDjF4943VlU03wCHIcfBisEeRNSf_d2xJSf_d2xsxlK5LE2zVkDjF4943VlU02rvus76MnWhEwdbrIv-q53iWq81uf-2gUod453WC3h0oBcCq81w1MGq81zUCvyq84XEI6S1NLzCpc4V9ptLc >> >> > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://cp.mcafee.com/d/avndygw720wrhovp7e8TvhdTdFT7ecL3DQhNJd5BBZV4QsT76QXzD6nxPW9EVdBQjsmW7X3GicWl1kvBjBPsvBjBPuEFWVHz_nVYQsIzC4NTnKnjjhhV55OXWabTkhjmKCHtxDBgY-F6lK1FJASOrLOtXTLuZXTdTdw0PVkDjF4943VlU03wCHIcfBisEeRNSf_d2xJSf_d2xsxlK5LE2zVkDjF4943VlU02rvus76MnWhEwdbrIv-q53iWq81uf-2gUod453WC3h0oBcCq81w1MGq81zUCvyq84XEI6S1NKRCGuV7G > This communication (including any attachments) is intended solely for the recipient(s) named above and may contain information that is confidential, privileged or legally protected. Any unauthorized use or dissemination of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender by return e-mail message and delete all copies of the original communication. Thank you for your cooperation. From ken at metaskills.net Mon Jan 25 21:08:45 2016 From: ken at metaskills.net (Ken Collins) Date: Mon, 25 Jan 2016 21:08:45 -0500 Subject: [freetds] FTP Down Message-ID: I noticed the FTP site is down. Been having issues building FreeTDS on my CI boxes for the past few days. Started on Saturday I think. ?- Ken From christos at zoulas.com Tue Jan 26 13:36:07 2016 From: christos at zoulas.com (Christos Zoulas) Date: Tue, 26 Jan 2016 13:36:07 -0500 Subject: [freetds] FTP Down In-Reply-To: from Ken Collins (Jan 25, 9:08pm) Message-ID: <20160126183607.8927017FDAB@rebar.astron.com> On Jan 25, 9:08pm, ken at metaskills.net (Ken Collins) wrote: -- Subject: [freetds] FTP Down It is up now... Does it work for you? christos From freddy77 at gmail.com Thu Jan 28 16:09:11 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Thu, 28 Jan 2016 21:09:11 +0000 Subject: [freetds] FreeTDS slow with SQL Server 2014 In-Reply-To: <56A6A6EF.9000704@reis.com> References: <56A68AFF.7020708@reis.com> <56A6A204.9070608@thesyrings.us> <56A6A6EF.9000704@reis.com> Message-ID: Il 25/Gen/2016 23:40, "Russ Sivak" ha scritto: > > I have installed the latest from source and am experiencing the same > slowness. > > While I can make the slowness go away by messing with the tds version in > the config file using version 0.91, I can't seem to do the same in 0.95. > > At the higher TDS version, however, I am seeing weird behavior in 0.91 > in that varchar columns are showing up as length 255, even though they > are longer in the database. > Usually 255 means you are using a wrong protocol version. Are you seeing slow connection or slow queries? Are you sure you don't have logging turned on? Frediano > The operation that we are testing is an insert using executemany with > about 30k records. > > Russ > > On 1/25/2016 5:30 PM, Randy Syring wrote: > > Since 0.95 has been released: > > > > http://cp.mcafee.com/d/5fHCMUp3zqb3X8VN6XW9KVJeUVNBUs-yedFEIILL8CzCUUSDssUOYevhd79IKyryTg_otihDiEazYGsKrzYGsKrR5fndsvW_fCzBAsMCeWZOWqqaf8EKnvhhuWyaqRQRrIcYG7DR8OJMddECSjt-jLuZXTLuVKVI04X7_Cxjw0egYNjwsrtz_PgEn8lrxrW0E-l9QWh2h0-lu00CTTD1NI5-Aq83iSX7_CxgQKCy0nz_wAe63h1g-FwQg69j9Cy0o0saCy0o-9DUCy1eWb1Jwsrvn8x > > > > > > I'm sure it would be helpful to know if you have the same problem with > > the latest stable version. > > > > *Randy Syring* > > Husband | Father | Redeemed Sinner > > > > /"For what does it profit a man to gain the whole world > > and forfeit his soul?" (Mark 8:36 ESV)/ > > > > On 01/25/2016 03:52 PM, Russ Sivak wrote: > >> We have been using SQL Server 2008 and things have been good. > >> > >> Recently we have upgraded to SQL Server 2014 and things have become VERY > >> slow. We are using FreeTDS freetds-0.91-2.el6.x86_64, which is the > >> latest from EPEL that for CentOS 6. > >> > >> > >> > >> > >> > >> > >> > >> This communication (including any attachments) is intended solely for > >> the > >> recipient(s) named above and may contain information that is > >> confidential, > >> privileged or legally protected. Any unauthorized use or > >> dissemination of this > >> communication is strictly prohibited. If you have received this > >> communication in > >> error, please immediately notify the sender by return e-mail message > >> and delete > >> all copies of the original communication. Thank you for your > >> cooperation. > >> _______________________________________________ > >> FreeTDS mailing list > >> FreeTDS at lists.ibiblio.org > >> http://cp.mcafee.com/d/2DRPoArhovp7e8TvhdTdFT7ecL3DQhNJd5BBZV4QsT76QXzD6nxPW9EVdBQjsmW7X3GicWl1kvBjBPsvBjBPuEFWVHz_nVYQsIzC4NTnKnjjhhV55OXWabTkhjmKCHtxDBgY-F6lK1FJcSOrLOtXTLuZXTdTdw0PVkDjF4943VlU03wCHIcfBisEeRNSf_d2xJSf_d2xsxlK5LE2zVkDjF4943VlU02rvus76MnWhEwdbrIv-q53iWq81uf-2gUod453WC3h0oBcCq81w1MGq81zUCvyq84XEI6S1NLzCpc4V9ptLc > >> > >> > > > > _______________________________________________ > > FreeTDS mailing list > > FreeTDS at lists.ibiblio.org > > http://cp.mcafee.com/d/avndygw720wrhovp7e8TvhdTdFT7ecL3DQhNJd5BBZV4QsT76QXzD6nxPW9EVdBQjsmW7X3GicWl1kvBjBPsvBjBPuEFWVHz_nVYQsIzC4NTnKnjjhhV55OXWabTkhjmKCHtxDBgY-F6lK1FJASOrLOtXTLuZXTdTdw0PVkDjF4943VlU03wCHIcfBisEeRNSf_d2xJSf_d2xsxlK5LE2zVkDjF4943VlU02rvus76MnWhEwdbrIv-q53iWq81uf-2gUod453WC3h0oBcCq81w1MGq81zUCvyq84XEI6S1NKRCGuV7G > > > > > > > This communication (including any attachments) is intended solely for the > recipient(s) named above and may contain information that is confidential, > privileged or legally protected. Any unauthorized use or dissemination of this > communication is strictly prohibited. If you have received this communication in > error, please immediately notify the sender by return e-mail message and delete > all copies of the original communication. Thank you for your cooperation. > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From jezekj at centrum.cz Thu Jan 28 14:51:01 2016 From: jezekj at centrum.cz (jezekj at centrum.cz) Date: Thu, 28 Jan 2016 20:51:01 +0100 Subject: [freetds] =?utf-8?q?Invalid_Cursor_state?= In-Reply-To: <20160128120837.4819A2B2@centrum.cz> References: <20160128120837.4819A2B2@centrum.cz> Message-ID: <20160128205101.59D8FE4A@centrum.cz> Hello, ? first of all I would like to thank you for creating and maintaining FreeTDS. In our application we do have procedure to trace progress of huge procedures execution to easily find out where the error is. This procedure contains raiserror function. When in another procedure I call select after trace procedure is called out I got invalid cursor state. i.e.: ? create procedure sp_trace as ? raiserror('test', 0, 1) go ? create procedure sp_test_me as ? select getdate() ? execute sp_trace ? select getdate() go ? Then we call out from perl: my $dbh=APPDBI->masterConnect(); my $statement='execute sp_test_me'; my $sth=$dbh->prepare($statement); my $sth->execute; while (my $d=$sth->fetch;){ #get 1st result set (first getdate) ? print Dumper $d; } while (my $d=$sth->fetch;){ #get 2nd result set (second getdate) ? print Dumper $d; } ? ? Can you confirm this is a bug which can/will be fixed? We have tried other driver in our setup (easysoft) and it is not case. Please let me know wah other details you need from me to support you in investigation. ? Best Regards, JJ From freddy77 at gmail.com Fri Jan 29 08:51:53 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Fri, 29 Jan 2016 13:51:53 +0000 Subject: [freetds] Invalid Cursor state In-Reply-To: <20160128205101.59D8FE4A@centrum.cz> References: <20160128120837.4819A2B2@centrum.cz> <20160128205101.59D8FE4A@centrum.cz> Message-ID: 2016-01-28 19:51 GMT+00:00 : > Hello, > > first of all I would like to thank you for creating and maintaining FreeTDS. In our application we do have procedure to trace progress of huge procedures execution to easily find out where the error is. This procedure contains raiserror function. When in another procedure I call select after trace procedure is called out I got invalid cursor state. i.e.: > > create procedure sp_trace as > raiserror('test', 0, 1) > go > > create procedure sp_test_me as > select getdate() > execute sp_trace > select getdate() > go > > Then we call out from perl: > my $dbh=APPDBI->masterConnect(); > my $statement='execute sp_test_me'; > my $sth=$dbh->prepare($statement); > my $sth->execute; > while (my $d=$sth->fetch;){ #get 1st result set (first getdate) > print Dumper $d; > } > while (my $d=$sth->fetch;){ #get 2nd result set (second getdate) > print Dumper $d; > } > > > Can you confirm this is a bug which can/will be fixed? > We have tried other driver in our setup (easysoft) and it is not case. > Please let me know wah other details you need from me to support you in investigation. > > Best Regards, > JJ Hi, it's indeed quite strange. Have a look at http://www.freetds.org/userguide/askingforhelp.htm and http://www.freetds.org/userguide/logging.htm. With the dump we can understand a lot like which library is Perl using and how. As your problem is not logging in you could strip the login part if you feel more comfortable for security reasons. Frediano From jezekj at centrum.cz Fri Jan 29 13:31:28 2016 From: jezekj at centrum.cz (jezekj at centrum.cz) Date: Fri, 29 Jan 2016 19:31:28 +0100 Subject: [freetds] =?utf-8?q?Invalid_Cursor_state?= In-Reply-To: References: <20160128120837.4819A2B2@centrum.cz>, <20160128205101.59D8FE4A@centrum.cz> Message-ID: <20160129193128.20A22390@centrum.cz> Hello, ? I have dumped my session with logging(default level) enabled. File is attached. ? JJ ? ______________________________________________________________ > Od: Frediano Ziglio > Komu: FreeTDS Development Group > Datum: 29.01.2016 14:52 > P?edm?t: Re: [freetds] Invalid Cursor state > 2016-01-28 19:51 GMT+00:00 ?: > Hello, > > first of all I would like to thank you for creating and maintaining FreeTDS. In our application we do have procedure to trace progress of huge procedures execution to easily find out where the error is. This procedure contains raiserror function. When in another procedure I call select after trace procedure is called out I got invalid cursor state. i.e.: > > create procedure sp_trace as > ? raiserror('test', 0, 1) > go > > create procedure sp_test_me as > ? select getdate() > ? execute sp_trace > ? select getdate() > go > > Then we call out from perl: > my $dbh=APPDBI->masterConnect(); > my $statement='execute sp_test_me'; > my $sth=$dbh->prepare($statement); > my $sth->execute; > while (my $d=$sth->fetch;){ #get 1st result set (first getdate) > ? print Dumper $d; > } > while (my $d=$sth->fetch;){ #get 2nd result set (second getdate) > ? print Dumper $d; > } > > > Can you confirm this is a bug which can/will be fixed? > We have tried other driver in our setup (easysoft) and it is not case. > Please let me know wah other details you need from me to support you in investigation. > > Best Regards, > JJ Hi, ?it's indeed quite strange. Have a look at http://www.freetds.org/userguide/askingforhelp.htm and http://www.freetds.org/userguide/logging.htm . With the dump we can understand a lot like which library is Perl using and how. As your problem is not logging in you could strip the login part if you feel more comfortable for security reasons. Frediano _______________________________________________ FreeTDS mailing list FreeTDS at lists.ibiblio.org http://lists.ibiblio.org/mailman/listinfo/freetds -------------- next part -------------- A non-text attachment was scrubbed... Name: fetch_TDS.log Type: text/x-log Size: 25451 bytes Desc: fetch_TDS.log URL: From cwthomas at llu.edu Fri Jan 29 15:54:44 2016 From: cwthomas at llu.edu (Thomas, Christopher (LLU)) Date: Fri, 29 Jan 2016 20:54:44 +0000 Subject: [freetds] Weird tsql behaviour Message-ID: Hello, I got a report from one of the developers that PHP couldn't connect to one of our databases. This happens every once in a while and I always try to connect using tsql first to see if it is a PHP problem or a problem much lower in the stack. Once I connected to the database server using tsql, the line numbers started to go up and up, automatically. About one digit per second. I've never seen this before, but I bet whatever is causing this is also making PHP not be able to connect to the database. I can't figure out what is going on. Does anyone have any suggestions? The db server is MS SQL Server 2008 R2 with SP2. The application server is RHEL 7 using the FreeTDS that comes from EPEL, 0.95.19. Christopher Thomas - Associate Director, Administrative Systems LOMA LINDA UNIVERSITY | Information Services 11172 Anderson Street, Loma Linda, California 92350 (909) 558-7866 LLU Information Systems: http://myllu.llu.edu/informationsystems/ Zoom Room: https://llu.zoom.us/j/9095587866 CONFIDENTIALITY NOTICE: This e-mail communication and any attachments may contain confidential and privileged information for the use of the designated recipients named above. If you are not the intended recipient, you are hereby notified that you have received this communication in error and that any review, disclosure, dissemination, distribution or copying of it or its contents is prohibited. If you have received this communication in error, please notify me immediately by replying to this message and destroy all copies of this communication and any attachments. Thank you. From james.k.lowden at icloud.com Sat Jan 30 13:21:28 2016 From: james.k.lowden at icloud.com (James K. Lowden) Date: Sat, 30 Jan 2016 13:21:28 -0500 Subject: [freetds] Weird tsql behaviour In-Reply-To: References: Message-ID: <20160130132128.74ecef119288422af9b481e7@icloud.com> On Fri, 29 Jan 2016 20:54:44 +0000 "Thomas, Christopher (LLU)" wrote: > Once I connected to the database server using tsql, the line numbers > started to go up and up, automatically. About one digit per second. Those "line numbers" are a counter that appears while a connection request is pending. It disappears when the connection succeeds. And, yes, they should be really, really close to 1 second apart! ;-) Under the hood, libtds connects to the server using nonblocking I/O. connect(2) usually returns with EINPROGRESS or similar, and the library uses poll(2) to wait for the connection to complete. You can see evidence of that in a typical TDSDUMP log. The above information should be in the man page, but isn't. Sorry about that, Chief. --jkl From freddy77 at gmail.com Sat Jan 30 13:57:19 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Sat, 30 Jan 2016 18:57:19 +0000 Subject: [freetds] Weird tsql behaviour In-Reply-To: <20160130132128.74ecef119288422af9b481e7@icloud.com> References: <20160130132128.74ecef119288422af9b481e7@icloud.com> Message-ID: 2016-01-30 18:21 GMT+00:00 James K. Lowden : > On Fri, 29 Jan 2016 20:54:44 +0000 > "Thomas, Christopher (LLU)" wrote: > >> Once I connected to the database server using tsql, the line numbers >> started to go up and up, automatically. About one digit per second. > > Those "line numbers" are a counter that appears while a connection > request is pending. It disappears when the connection succeeds. And, > yes, they should be really, really close to 1 second apart! ;-) > > Under the hood, libtds connects to the server using nonblocking I/O. > connect(2) usually returns with EINPROGRESS or similar, and the library > uses poll(2) to wait for the connection to complete. You can see > evidence of that in a typical TDSDUMP log. > > The above information should be in the man page, but isn't. Sorry > about that, Chief. > So looks like your server is down. Or firewall/network problems. Or sql server is not accepting new connections. If the physical server is up but sql server is down you should see a fast reply with connection error. Frediano From bill.d.thompson at baml.com Tue Feb 2 09:20:10 2016 From: bill.d.thompson at baml.com (Thompson, William) Date: Tue, 02 Feb 2016 14:20:10 +0000 Subject: [freetds] Problem with src/tds/write.c Message-ID: <4A990489BF566041A7724DC577BB06041750393B@smtp_mail.bankofamerica.com> Hi All, I'm investigating an issue which is affecting some of my processes which use the db-library bcp API. I'm getting an error back from SQL Server: "The incoming tabular data stream (TDS) protocol stream is incorrect. The stream ended unexpectedly." After debugging it, It turns out we have an edge case involving some of the functions in src/tds/write.c The functions tds_put_int8, tds_put_int and tds_put_smallint do not check that there is sufficient space in the packet buffer for their respective data types. As a consequence, data gets dropped if it happens that one of these data types is being added to the packet buffer when the packet size is reached. Having looked at the functions, I think I'm going to change these lines (which occur in all the functions): if (tds->out_pos >= tds->out_buf_max) tds_write_packet(tds, 0x0); to be: if (tds->out_pos + sizeof(TDS_INT) >= tds->out_buf_max) /* or TDS_INT8 or TDS_SMALLINT */ tds_write_packet(tds, 0x0); If I do this there will be cases where the packet (although not a final packet) is smaller than the maximum size, but I REALLY don't want to go anywhere near those TDS_PUT_UA* macros. :) Incidentally, what is the idea behind this TDS_ADDITIONAL_SPACE macro and all those TDS_PUT macros? Life used to be much simpler (sigh), e.g. Int tds_put_smallint(TDSSOCKET * tds, TDS_SMALLINT si) { #if WORDS_BIGENDIAN if (tds->emul_little_endian) { tds_put_byte(tds, si & 0x000000FF); tds_put_byte(tds, (si & 0x0000FF00) >> 8); return 0; } #endif return tds_put_n(tds, (const unsigned char *) &si, sizeof(TDS_SMALLINT)); } <\old code> Bill ---------------------------------------------------------------------- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message. From andrew.punch at smart-associates.biz Tue Feb 2 23:40:09 2016 From: andrew.punch at smart-associates.biz (Andrew Punch) Date: Wed, 3 Feb 2016 15:40:09 +1100 Subject: [freetds] freebcp adding escaping Message-ID: <56B184A9.1040603@smart-associates.biz> Hi, I had a requirement to have properly formatted CSV output from freebcp. Unfortunately freebcp (and the original bcp) do not escape characters correctly. For example in a comma delimited file commas will not be escaped. Also the way NULLs are indicated can be inconvenient. I hacked together a patch which I have attached. I would like to do a pull after a clean up but I have a few questions: 1. is dblib the best place to make the change? 2. what is the best structure to pass parameters and flags? Namely: 1. Flag for delimiter escaping 2. The actual delimiter (I notice that the column delimiter changes to EOL for the last column) 3. Flag for NULL string replacement (instead of ASCII NUL) 4. NULL string replacement -------------- next part -------------- A non-text attachment was scrubbed... Name: smart.patch Type: text/x-patch Size: 4452 bytes Desc: not available URL: From bill.d.thompson at baml.com Thu Feb 4 04:31:55 2016 From: bill.d.thompson at baml.com (Thompson, William) Date: Thu, 04 Feb 2016 09:31:55 +0000 Subject: [freetds] freebcp adding escaping In-Reply-To: <56B184A9.1040603@smart-associates.biz> References: <56B184A9.1040603@smart-associates.biz> Message-ID: <4A990489BF566041A7724DC577BB06041750429B@smtp_mail.bankofamerica.com> Hi Andrew, It's a perfectly reasonable requirement, but I'm not sure that your implementation produces "properly formatted CSV output" as commonly understood. Although there is no agreed standard for CSV, the Wikipedia page on CSV summarises my understanding of the conventions, namely that a CSV file requires: * lines that end with a newline character or characters (optional for the last line) * An optional header record (although there is no sure way to detect whether it is present, so care is required when importing). * Each record should contain the same number of comma-separated fields. * Any field may be quoted (with double quotes). * Fields containing a line-break, double-quote, and/or commas should be quoted. * A (double) quote character in a field must be represented by two (double) quote characters. Given this, a neat way of fulfilling the requirement would be to implement a single command line flag, which would operate as an alternative to the -c, -n or -f flags. This could then: Default the field separator to comma, (with possible override using the -t flag) Wrap double quotes around at least all the character fields extracted, maybe all fields... Double up any double quotes in any character fields. And that's all you would need. For most applications accepting CSV files (Excel for example) that would deal with the issues you have tried to address with the escaping functionality you've coded. I'm not sure about the Null string/field replacement stuff you've done. An empty or absent field in CSV is usually just represented by two consecutive delimiters, and I think bcp would do that already. Hope this helps, Bill -----Original Message----- From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of Andrew Punch Sent: 03 February 2016 04:40 To: freetds at lists.ibiblio.org Subject: [freetds] freebcp adding escaping Hi, I had a requirement to have properly formatted CSV output from freebcp. Unfortunately freebcp (and the original bcp) do not escape characters correctly. For example in a comma delimited file commas will not be escaped. Also the way NULLs are indicated can be inconvenient. I hacked together a patch which I have attached. I would like to do a pull after a clean up but I have a few questions: 1. is dblib the best place to make the change? 2. what is the best structure to pass parameters and flags? Namely: 1. Flag for delimiter escaping 2. The actual delimiter (I notice that the column delimiter changes to EOL for the last column) 3. Flag for NULL string replacement (instead of ASCII NUL) 4. NULL string replacement ---------------------------------------------------------------------- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message. From no-reply at appveyor.com Thu Feb 4 18:10:34 2016 From: no-reply at appveyor.com (AppVeyor) Date: Thu, 04 Feb 2016 23:10:34 +0000 Subject: [freetds] Build failed: freetds 406 Message-ID: <20160204231033.11241.74168@appveyor.com> From no-reply at appveyor.com Fri Feb 5 05:03:06 2016 From: no-reply at appveyor.com (AppVeyor) Date: Fri, 05 Feb 2016 10:03:06 +0000 Subject: [freetds] Build completed: freetds 407 Message-ID: <20160205100304.68416.27539@appveyor.com> From andrei.muresanu at ing.ro Fri Feb 5 04:27:12 2016 From: andrei.muresanu at ing.ro (Muresanu A.V. (Andrei Valentin)) Date: Fri, 5 Feb 2016 09:27:12 +0000 Subject: [freetds] php mssql_connect() without section name in freetds.conf Message-ID: <39fcb6ec04a84857af78e782af562a6f@SU8000006108.ad.ing.net> Hi, anybody have any idea with the following ? Does not work, gives 'Unknown host machine name'. Even with tds version = 7.0... 7.1, 8, etc..: $link = mssql_connect("10.98.97.96:62220", 'user', 'pass'); Works because there is a section in freetds.conf named 'dasdswh': $link = mssql_connect('dasdswh', 'user', 'pass'); $ php -v PHP 5.5.21 (cli) (built: Jun 10 2015 05:26:44) Copyright (c) 1997-2014 The PHP Group Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies with Zend OPcache v7.0.4-dev, Copyright (c) 1999-2014, by Zend Technologies Trace log: 16:55:35.585240 15567 (log.c:196):Starting log file for FreeTDS 0.91 on 2016-02-04 16:55:35 with debug flags 0xffff. 16:55:35.585295 15567 (iconv.c:330):tds_iconv_open(0x2569f10, UTF-8) 16:55:35.585508 15567 (iconv.c:187):local name for ISO-8859-1 is ISO-8859-1 16:55:35.585528 15567 (iconv.c:187):local name for UTF-8 is UTF-8 16:55:35.585542 15567 (iconv.c:187):local name for UCS-2LE is UCS-2LE 16:55:35.585560 15567 (iconv.c:187):local name for UCS-2BE is UCS-2BE 16:55:35.585578 15567 (iconv.c:349):setting up conversions for client charset "UTF-8" 16:55:35.585590 15567 (iconv.c:351):preparing iconv for "UTF-8" <-> "UCS-2LE" conversion 16:55:35.585610 15567 (iconv.c:391):preparing iconv for "ISO-8859-1" <-> "UCS-2LE" conversion 16:55:35.585635 15567 (iconv.c:394):tds_iconv_open: done 16:55:35.585647 15567 (util.c:331):tdserror(0x245d490, 0x2569f10, 20013, 0) 16:55:35.585666 15567 (dblib.c:7906):dbperror(0x2569530, 20013, 0) 16:55:35.585681 15567 (dblib.c:7958):20013: "Unknown host machine name" 16:55:35.585717 15567 (dblib.c:7979):"Unknown host machine name", client returns 2 (INT_CANCEL) 16:55:35.585734 15567 (util.c:361):tdserror: client library returned TDS_INT_CANCEL(2) 16:55:35.585751 15567 (util.c:384):tdserror: returning TDS_INT_CANCEL(2) 16:55:35.585766 15567 (login.c:417):IP address pointer is empty 16:55:35.585776 15567 (login.c:419):Server 10.98.97.96:62220 not found! 16:55:35.585795 15567 (dblib.c:1424):dbclose(0x2569530) 16:55:35.585815 15567 (dblib.c:258):dblib_del_connection(0x7f78f16cd800, 0x2569f10) 16:55:35.585862 15567 (mem.c:615):tds_free_all_results() 16:55:35.585890 15567 (dblib.c:305):dblib_release_tds_ctx(1) 16:55:35.585909 15567 (dblib.c:5859):dbfreebuf(0x2569530) 16:55:35.592809 15567 (dblib.c:724):dbloginfree(0x2569510) 16:55:35.594342 15567 (dblib.c:1493):dbexit(void) 16:55:35.594378 15567 (dblib.c:305):dblib_release_tds_ctx(1) ---------------------------------------------------------------- ATTENTION: The information in this e-mail is confidential and only meant for the intended recipient. If you are not the intended recipient , don't use or disclose it in anyway. Please let the sender know and delete the message immediately. ------------------------------------------------------------------------------------------------------ From jezekj at centrum.cz Fri Feb 5 11:19:06 2016 From: jezekj at centrum.cz (jezekj at centrum.cz) Date: Fri, 05 Feb 2016 17:19:06 +0100 Subject: [freetds] php mssql_connect() without section name in freetds.conf In-Reply-To: <39fcb6ec04a84857af78e782af562a6f@SU8000006108.ad.ing.net> References: <39fcb6ec04a84857af78e782af562a6f@SU8000006108.ad.ing.net> Message-ID: <832C1320-D6B9-43D7-B36D-6BEBC289D4BA@centrum.cz> Not sure, but in old Sybase times port has been delimited by space. i.e. "10.98.97.96 62220". Maybe I'm totally wrong here, but give it a try. JJ 5. ?nora 2016 10:27:12 CET, "Muresanu A.V. (Andrei Valentin)" napsal: >Hi, > >anybody have any idea with the following ? > >Does not work, gives 'Unknown host machine name'. Even with tds version >= 7.0... 7.1, 8, etc..: > >$link = mssql_connect("10.98.97.96:62220", 'user', 'pass'); > >Works because there is a section in freetds.conf named 'dasdswh': > >$link = mssql_connect('dasdswh', 'user', 'pass'); > >$ php -v >PHP 5.5.21 (cli) (built: Jun 10 2015 05:26:44) >Copyright (c) 1997-2014 The PHP Group >Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies >with Zend OPcache v7.0.4-dev, Copyright (c) 1999-2014, by Zend >Technologies > >Trace log: > >16:55:35.585240 15567 (log.c:196):Starting log file for FreeTDS 0.91 > on 2016-02-04 16:55:35 with debug flags 0xffff. >16:55:35.585295 15567 (iconv.c:330):tds_iconv_open(0x2569f10, UTF-8) >16:55:35.585508 15567 (iconv.c:187):local name for ISO-8859-1 is >ISO-8859-1 >16:55:35.585528 15567 (iconv.c:187):local name for UTF-8 is UTF-8 >16:55:35.585542 15567 (iconv.c:187):local name for UCS-2LE is UCS-2LE >16:55:35.585560 15567 (iconv.c:187):local name for UCS-2BE is UCS-2BE >16:55:35.585578 15567 (iconv.c:349):setting up conversions for client >charset "UTF-8" >16:55:35.585590 15567 (iconv.c:351):preparing iconv for "UTF-8" <-> >"UCS-2LE" conversion >16:55:35.585610 15567 (iconv.c:391):preparing iconv for "ISO-8859-1" ><-> "UCS-2LE" conversion >16:55:35.585635 15567 (iconv.c:394):tds_iconv_open: done >16:55:35.585647 15567 (util.c:331):tdserror(0x245d490, 0x2569f10, >20013, 0) >16:55:35.585666 15567 (dblib.c:7906):dbperror(0x2569530, 20013, 0) >16:55:35.585681 15567 (dblib.c:7958):20013: "Unknown host machine name" >16:55:35.585717 15567 (dblib.c:7979):"Unknown host machine name", >client returns 2 (INT_CANCEL) >16:55:35.585734 15567 (util.c:361):tdserror: client library returned >TDS_INT_CANCEL(2) >16:55:35.585751 15567 (util.c:384):tdserror: returning >TDS_INT_CANCEL(2) >16:55:35.585766 15567 (login.c:417):IP address pointer is empty >16:55:35.585776 15567 (login.c:419):Server 10.98.97.96:62220 not found! >16:55:35.585795 15567 (dblib.c:1424):dbclose(0x2569530) >16:55:35.585815 15567 >(dblib.c:258):dblib_del_connection(0x7f78f16cd800, 0x2569f10) >16:55:35.585862 15567 (mem.c:615):tds_free_all_results() >16:55:35.585890 15567 (dblib.c:305):dblib_release_tds_ctx(1) >16:55:35.585909 15567 (dblib.c:5859):dbfreebuf(0x2569530) >16:55:35.592809 15567 (dblib.c:724):dbloginfree(0x2569510) >16:55:35.594342 15567 (dblib.c:1493):dbexit(void) >16:55:35.594378 15567 (dblib.c:305):dblib_release_tds_ctx(1) > >---------------------------------------------------------------- >ATTENTION: >The information in this e-mail is confidential and only meant for the >intended recipient. If you are not the intended recipient , don't use >or disclose it in anyway. Please let the sender know and delete the >message immediately. >------------------------------------------------------------------------------------------------------ > > >_______________________________________________ >FreeTDS mailing list >FreeTDS at lists.ibiblio.org >http://lists.ibiblio.org/mailman/listinfo/freetds -- Odesl?no z m?ho telefonu s Androidem pomoc? po?ty K-9 Mail. Omluvte pros?m moji stru?nost. From andrei.muresanu at ing.ro Fri Feb 5 11:49:14 2016 From: andrei.muresanu at ing.ro (Muresanu A.V. (Andrei Valentin)) Date: Fri, 5 Feb 2016 16:49:14 +0000 Subject: [freetds] php mssql_connect() without section name in freetds.conf In-Reply-To: <832C1320-D6B9-43D7-B36D-6BEBC289D4BA@centrum.cz> References: <39fcb6ec04a84857af78e782af562a6f@SU8000006108.ad.ing.net> <832C1320-D6B9-43D7-B36D-6BEBC289D4BA@centrum.cz> Message-ID: <90937532a4d44d9cb3f4cee3ce3ed73d@SU8000006108.ad.ing.net> Doesn't work. It's the same as not mentioning the port at all. Tries on port 4000 instead: 20009: "Unable to connect: Adaptive Server is unavailable or does not exist" log.c:196:Starting log file for FreeTDS 0.91 on 2016-02-05 18:46:24 with debug flags 0x4fff. iconv.c:330:tds_iconv_open(0x2b9bfd0, UTF-8) iconv.c:187:local name for ISO-8859-1 is ISO-8859-1 iconv.c:187:local name for UTF-8 is UTF-8 iconv.c:187:local name for UCS-2LE is UCS-2LE iconv.c:187:local name for UCS-2BE is UCS-2BE iconv.c:349:setting up conversions for client charset "UTF-8" iconv.c:351:preparing iconv for "UTF-8" <-> "UCS-2LE" conversion iconv.c:391:preparing iconv for "ISO-8859-1" <-> "UCS-2LE" conversion iconv.c:394:tds_iconv_open: done net.c:205:Connecting to 10.98.97.95 port 4000 (TDS version 7.1) net.c:270:tds_open_socket: connect(2) returned "Operation now in progress" net.c:316:tds_open_socket() failed util.c:331:tdserror(0x2a89fa0, 0x2b9bfd0, 20009, 115) dblib.c:7906:dbperror(0x2b9b5f0, 20009, 115) dblib.c:7958:20009: "Unable to connect: Adaptive Server is unavailable or does not exist" dblib.c:7979:"Unable to connect: Adaptive Server is unavailable or does not exist", client returns 2 (INT_CANCEL) util.c:361:tdserror: client library returned TDS_INT_CANCEL(2) util.c:384:tdserror: returning TDS_INT_CANCEL(2) dblib.c:1424:dbclose(0x2b9b5f0) dblib.c:258:dblib_del_connection(0x7fe324a6b1a0, 0x2b9bfd0) mem.c:615:tds_free_all_results() dblib.c:305:dblib_release_tds_ctx(1) dblib.c:5859:dbfreebuf(0x2b9b5f0) dblib.c:724:dbloginfree(0x2b9b020) dblib.c:1493:dbexit(void) dblib.c:305:dblib_release_tds_ctx(1) -----Original Message----- From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of jezekj at centrum.cz Sent: Friday, February 05, 2016 6:19 PM To: FreeTDS Development Group Subject: Re: [freetds] php mssql_connect() without section name in freetds.conf Not sure, but in old Sybase times port has been delimited by space. i.e. "10.98.97.96 62220". Maybe I'm totally wrong here, but give it a try. JJ 5. ?nora 2016 10:27:12 CET, "Muresanu A.V. (Andrei Valentin)" napsal: >Hi, > >anybody have any idea with the following ? > >Does not work, gives 'Unknown host machine name'. Even with tds version >= 7.0... 7.1, 8, etc..: > >$link = mssql_connect("10.98.97.96:62220", 'user', 'pass'); > >Works because there is a section in freetds.conf named 'dasdswh': > >$link = mssql_connect('dasdswh', 'user', 'pass'); > >$ php -v >PHP 5.5.21 (cli) (built: Jun 10 2015 05:26:44) Copyright (c) 1997-2014 >The PHP Group Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend >Technologies with Zend OPcache v7.0.4-dev, Copyright (c) 1999-2014, by >Zend Technologies > >Trace log: > >16:55:35.585240 15567 (log.c:196):Starting log file for FreeTDS 0.91 > on 2016-02-04 16:55:35 with debug flags 0xffff. >16:55:35.585295 15567 (iconv.c:330):tds_iconv_open(0x2569f10, UTF-8) >16:55:35.585508 15567 (iconv.c:187):local name for ISO-8859-1 is >ISO-8859-1 >16:55:35.585528 15567 (iconv.c:187):local name for UTF-8 is UTF-8 >16:55:35.585542 15567 (iconv.c:187):local name for UCS-2LE is UCS-2LE >16:55:35.585560 15567 (iconv.c:187):local name for UCS-2BE is UCS-2BE >16:55:35.585578 15567 (iconv.c:349):setting up conversions for client >charset "UTF-8" >16:55:35.585590 15567 (iconv.c:351):preparing iconv for "UTF-8" <-> >"UCS-2LE" conversion >16:55:35.585610 15567 (iconv.c:391):preparing iconv for "ISO-8859-1" ><-> "UCS-2LE" conversion >16:55:35.585635 15567 (iconv.c:394):tds_iconv_open: done >16:55:35.585647 15567 (util.c:331):tdserror(0x245d490, 0x2569f10, >20013, 0) >16:55:35.585666 15567 (dblib.c:7906):dbperror(0x2569530, 20013, 0) >16:55:35.585681 15567 (dblib.c:7958):20013: "Unknown host machine name" >16:55:35.585717 15567 (dblib.c:7979):"Unknown host machine name", >client returns 2 (INT_CANCEL) >16:55:35.585734 15567 (util.c:361):tdserror: client library returned >TDS_INT_CANCEL(2) >16:55:35.585751 15567 (util.c:384):tdserror: returning >TDS_INT_CANCEL(2) >16:55:35.585766 15567 (login.c:417):IP address pointer is empty >16:55:35.585776 15567 (login.c:419):Server 10.98.97.96:62220 not found! >16:55:35.585795 15567 (dblib.c:1424):dbclose(0x2569530) >16:55:35.585815 15567 >(dblib.c:258):dblib_del_connection(0x7f78f16cd800, 0x2569f10) >16:55:35.585862 15567 (mem.c:615):tds_free_all_results() >16:55:35.585890 15567 (dblib.c:305):dblib_release_tds_ctx(1) >16:55:35.585909 15567 (dblib.c:5859):dbfreebuf(0x2569530) >16:55:35.592809 15567 (dblib.c:724):dbloginfree(0x2569510) >16:55:35.594342 15567 (dblib.c:1493):dbexit(void) >16:55:35.594378 15567 (dblib.c:305):dblib_release_tds_ctx(1) > >---------------------------------------------------------------- >ATTENTION: >The information in this e-mail is confidential and only meant for the >intended recipient. If you are not the intended recipient , don't use >or disclose it in anyway. Please let the sender know and delete the >message immediately. >----------------------------------------------------------------------- >------------------------------- > > >_______________________________________________ >FreeTDS mailing list >FreeTDS at lists.ibiblio.org >http://lists.ibiblio.org/mailman/listinfo/freetds -- Odesl?no z m?ho telefonu s Androidem pomoc? po?ty K-9 Mail. Omluvte pros?m moji stru?nost. _______________________________________________ FreeTDS mailing list FreeTDS at lists.ibiblio.org http://lists.ibiblio.org/mailman/listinfo/freetds ------------------------------------------------------------------------------------------------------ ATTENTION: The information in this e-mail is confidential and only meant for the intended recipient. If you are not the intended recipient , don't use or disclose it in anyway. Please let the sender know and delete the message immediately. ------------------------------------------------------------------------------------------------------ From john at capps.com Sat Feb 6 04:33:06 2016 From: john at capps.com (John Kendall) Date: Sat, 6 Feb 2016 09:33:06 +0000 Subject: [freetds] compute rows Message-ID: <772DB680-422D-403B-8C8C-DC35998401AD@capps.com> I am having trouble with the output of compute rows. I found the following exchange from 2007 between jkl and Michael Peppler that summarizes what I'm experiencing in 2016: http://lists.ibiblio.org/pipermail/freetds/2007q1/020954.html To summarize, sqsh (and other tools linked to freetds) do not produce usable output for compute rows. Michael Peppler says that sqsh acts correctly when linked to sybase libs. I have an old copy of isql that handles compute statements in a very predictable way, for example: select col1=1, col2=1, col3=1 into tempdb..tab insert tempdb..tab select 2,2,2 insert tempdb..tab select 3,3,3 go select * from tempdb..tab compute sum(col1), avg(col1), min(col1), count(col1), avg(col2), max(col3), min(col3) go col1 col2 col3 ----------- ----------- ----------- 1 1 1 2 2 2 3 3 3 sum =========== 6 avg avg =========== =========== 2 2 min min =========== =========== 1 1 count =========== 3 max =========== 3 (4 rows affected) sqsh, linked to freetds, produces: col1 col2 col3 ----------- ----------- ----------- 1 1 1 2 2 2 3 3 3 =========== 6 =========== 2 =========== 1 =========== =========== =========== 3 2 3 =========== 1 (4 rows affected) Note how sqsh doesn't label the aggregate columns, and it combined count, avg and max into one row, while not combining the two min rows. Pretty useless. I no longer have access to sybase libs, so I cannot test sqsh linked to them. Just for comparison, fisql has a different set of problems: col1 col2 col3 ----------- ----------- ----------- 1 1 1 2 2 2 3 3 3 sum avg min count avg max min ----------- ----------- ----------- ----------- ----------- ----------- ----------- 6 2 1 3 2 3 1 (4 rows affected) Micheal's theory was that an API call in CTlib wasn't quite right, such as ct_describe() or ct_compute_info(). Any ideas anyone? Thanks, John From freddy77 at gmail.com Sat Feb 6 07:15:38 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Sat, 6 Feb 2016 12:15:38 +0000 Subject: [freetds] php mssql_connect() without section name in freetds.conf In-Reply-To: <90937532a4d44d9cb3f4cee3ce3ed73d@SU8000006108.ad.ing.net> References: <39fcb6ec04a84857af78e782af562a6f@SU8000006108.ad.ing.net> <832C1320-D6B9-43D7-B36D-6BEBC289D4BA@centrum.cz> <90937532a4d44d9cb3f4cee3ce3ed73d@SU8000006108.ad.ing.net> Message-ID: That's weird. It's not clear how the first mssql_connect parameter is passed to FreeTDS. Could you try to set TDSDUMPCONFIG and not only TDSDUMP or (even better) After first connect try to do another connect (even if first fails)? On the log we should see dbopen call. Frediano 2016-02-05 16:49 GMT+00:00 Muresanu A.V. (Andrei Valentin) : > Doesn't work. It's the same as not mentioning the port at all. Tries on port 4000 instead: > > 20009: "Unable to connect: Adaptive Server is unavailable or does not exist" > > log.c:196:Starting log file for FreeTDS 0.91 > on 2016-02-05 18:46:24 with debug flags 0x4fff. > iconv.c:330:tds_iconv_open(0x2b9bfd0, UTF-8) > iconv.c:187:local name for ISO-8859-1 is ISO-8859-1 > iconv.c:187:local name for UTF-8 is UTF-8 > iconv.c:187:local name for UCS-2LE is UCS-2LE > iconv.c:187:local name for UCS-2BE is UCS-2BE > iconv.c:349:setting up conversions for client charset "UTF-8" > iconv.c:351:preparing iconv for "UTF-8" <-> "UCS-2LE" conversion > iconv.c:391:preparing iconv for "ISO-8859-1" <-> "UCS-2LE" conversion > iconv.c:394:tds_iconv_open: done > net.c:205:Connecting to 10.98.97.95 port 4000 (TDS version 7.1) > net.c:270:tds_open_socket: connect(2) returned "Operation now in progress" > net.c:316:tds_open_socket() failed > util.c:331:tdserror(0x2a89fa0, 0x2b9bfd0, 20009, 115) > dblib.c:7906:dbperror(0x2b9b5f0, 20009, 115) > dblib.c:7958:20009: "Unable to connect: Adaptive Server is unavailable or does not exist" > dblib.c:7979:"Unable to connect: Adaptive Server is unavailable or does not exist", client returns 2 (INT_CANCEL) > util.c:361:tdserror: client library returned TDS_INT_CANCEL(2) > util.c:384:tdserror: returning TDS_INT_CANCEL(2) > dblib.c:1424:dbclose(0x2b9b5f0) > dblib.c:258:dblib_del_connection(0x7fe324a6b1a0, 0x2b9bfd0) > mem.c:615:tds_free_all_results() > dblib.c:305:dblib_release_tds_ctx(1) > dblib.c:5859:dbfreebuf(0x2b9b5f0) > dblib.c:724:dbloginfree(0x2b9b020) > dblib.c:1493:dbexit(void) > dblib.c:305:dblib_release_tds_ctx(1) > > -----Original Message----- > From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of jezekj at centrum.cz > Sent: Friday, February 05, 2016 6:19 PM > To: FreeTDS Development Group > Subject: Re: [freetds] php mssql_connect() without section name in freetds.conf > > Not sure, but in old Sybase times port has been delimited by space. i.e. "10.98.97.96 62220". Maybe I'm totally wrong here, but give it a try. > > JJ > > 5. ?nora 2016 10:27:12 CET, "Muresanu A.V. (Andrei Valentin)" napsal: >>Hi, >> >>anybody have any idea with the following ? >> >>Does not work, gives 'Unknown host machine name'. Even with tds version >>= 7.0... 7.1, 8, etc..: >> >>$link = mssql_connect("10.98.97.96:62220", 'user', 'pass'); >> >>Works because there is a section in freetds.conf named 'dasdswh': >> >>$link = mssql_connect('dasdswh', 'user', 'pass'); >> >>$ php -v >>PHP 5.5.21 (cli) (built: Jun 10 2015 05:26:44) Copyright (c) 1997-2014 >>The PHP Group Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend >>Technologies with Zend OPcache v7.0.4-dev, Copyright (c) 1999-2014, by >>Zend Technologies >> >>Trace log: >> >>16:55:35.585240 15567 (log.c:196):Starting log file for FreeTDS 0.91 >> on 2016-02-04 16:55:35 with debug flags 0xffff. >>16:55:35.585295 15567 (iconv.c:330):tds_iconv_open(0x2569f10, UTF-8) >>16:55:35.585508 15567 (iconv.c:187):local name for ISO-8859-1 is >>ISO-8859-1 >>16:55:35.585528 15567 (iconv.c:187):local name for UTF-8 is UTF-8 >>16:55:35.585542 15567 (iconv.c:187):local name for UCS-2LE is UCS-2LE >>16:55:35.585560 15567 (iconv.c:187):local name for UCS-2BE is UCS-2BE >>16:55:35.585578 15567 (iconv.c:349):setting up conversions for client >>charset "UTF-8" >>16:55:35.585590 15567 (iconv.c:351):preparing iconv for "UTF-8" <-> >>"UCS-2LE" conversion >>16:55:35.585610 15567 (iconv.c:391):preparing iconv for "ISO-8859-1" >><-> "UCS-2LE" conversion >>16:55:35.585635 15567 (iconv.c:394):tds_iconv_open: done >>16:55:35.585647 15567 (util.c:331):tdserror(0x245d490, 0x2569f10, >>20013, 0) >>16:55:35.585666 15567 (dblib.c:7906):dbperror(0x2569530, 20013, 0) >>16:55:35.585681 15567 (dblib.c:7958):20013: "Unknown host machine name" >>16:55:35.585717 15567 (dblib.c:7979):"Unknown host machine name", >>client returns 2 (INT_CANCEL) >>16:55:35.585734 15567 (util.c:361):tdserror: client library returned >>TDS_INT_CANCEL(2) >>16:55:35.585751 15567 (util.c:384):tdserror: returning >>TDS_INT_CANCEL(2) >>16:55:35.585766 15567 (login.c:417):IP address pointer is empty >>16:55:35.585776 15567 (login.c:419):Server 10.98.97.96:62220 not found! >>16:55:35.585795 15567 (dblib.c:1424):dbclose(0x2569530) >>16:55:35.585815 15567 >>(dblib.c:258):dblib_del_connection(0x7f78f16cd800, 0x2569f10) >>16:55:35.585862 15567 (mem.c:615):tds_free_all_results() >>16:55:35.585890 15567 (dblib.c:305):dblib_release_tds_ctx(1) >>16:55:35.585909 15567 (dblib.c:5859):dbfreebuf(0x2569530) >>16:55:35.592809 15567 (dblib.c:724):dbloginfree(0x2569510) >>16:55:35.594342 15567 (dblib.c:1493):dbexit(void) >>16:55:35.594378 15567 (dblib.c:305):dblib_release_tds_ctx(1) >> From jezekj at centrum.cz Sat Feb 6 08:29:12 2016 From: jezekj at centrum.cz (jezekj at centrum.cz) Date: Sat, 06 Feb 2016 14:29:12 +0100 Subject: [freetds] php mssql_connect() without section name in freetds.conf In-Reply-To: <90937532a4d44d9cb3f4cee3ce3ed73d@SU8000006108.ad.ing.net> References: <39fcb6ec04a84857af78e782af562a6f@SU8000006108.ad.ing.net> <832C1320-D6B9-43D7-B36D-6BEBC289D4BA@centrum.cz> <90937532a4d44d9cb3f4cee3ce3ed73d@SU8000006108.ad.ing.net> Message-ID: <280F50D9-7A79-4E2B-892D-AE7142E19B62@centrum.cz> Sorry I was wrong. Port is not space delimited, but comma delimited. Please try "10.98.97.96,62220". Maybe it will help. JJ 5. ?nora 2016 17:49:14 CET, "Muresanu A.V. (Andrei Valentin)" napsal: >Doesn't work. It's the same as not mentioning the port at all. Tries on >port 4000 instead: > >20009: "Unable to connect: Adaptive Server is unavailable or does not >exist" > >log.c:196:Starting log file for FreeTDS 0.91 > on 2016-02-05 18:46:24 with debug flags 0x4fff. >iconv.c:330:tds_iconv_open(0x2b9bfd0, UTF-8) >iconv.c:187:local name for ISO-8859-1 is ISO-8859-1 >iconv.c:187:local name for UTF-8 is UTF-8 >iconv.c:187:local name for UCS-2LE is UCS-2LE >iconv.c:187:local name for UCS-2BE is UCS-2BE >iconv.c:349:setting up conversions for client charset "UTF-8" >iconv.c:351:preparing iconv for "UTF-8" <-> "UCS-2LE" conversion >iconv.c:391:preparing iconv for "ISO-8859-1" <-> "UCS-2LE" conversion >iconv.c:394:tds_iconv_open: done >net.c:205:Connecting to 10.98.97.95 port 4000 (TDS version 7.1) >net.c:270:tds_open_socket: connect(2) returned "Operation now in >progress" >net.c:316:tds_open_socket() failed >util.c:331:tdserror(0x2a89fa0, 0x2b9bfd0, 20009, 115) >dblib.c:7906:dbperror(0x2b9b5f0, 20009, 115) >dblib.c:7958:20009: "Unable to connect: Adaptive Server is unavailable >or does not exist" >dblib.c:7979:"Unable to connect: Adaptive Server is unavailable or does >not exist", client returns 2 (INT_CANCEL) >util.c:361:tdserror: client library returned TDS_INT_CANCEL(2) >util.c:384:tdserror: returning TDS_INT_CANCEL(2) >dblib.c:1424:dbclose(0x2b9b5f0) >dblib.c:258:dblib_del_connection(0x7fe324a6b1a0, 0x2b9bfd0) >mem.c:615:tds_free_all_results() >dblib.c:305:dblib_release_tds_ctx(1) >dblib.c:5859:dbfreebuf(0x2b9b5f0) >dblib.c:724:dbloginfree(0x2b9b020) >dblib.c:1493:dbexit(void) >dblib.c:305:dblib_release_tds_ctx(1) > >-----Original Message----- >From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of >jezekj at centrum.cz >Sent: Friday, February 05, 2016 6:19 PM >To: FreeTDS Development Group >Subject: Re: [freetds] php mssql_connect() without section name in >freetds.conf > >Not sure, but in old Sybase times port has been delimited by space. >i.e. "10.98.97.96 62220". Maybe I'm totally wrong here, but give it a >try. > >JJ > >5. ?nora 2016 10:27:12 CET, "Muresanu A.V. (Andrei Valentin)" > napsal: >>Hi, >> >>anybody have any idea with the following ? >> >>Does not work, gives 'Unknown host machine name'. Even with tds >version >>= 7.0... 7.1, 8, etc..: >> >>$link = mssql_connect("10.98.97.96:62220", 'user', 'pass'); >> >>Works because there is a section in freetds.conf named 'dasdswh': >> >>$link = mssql_connect('dasdswh', 'user', 'pass'); >> >>$ php -v >>PHP 5.5.21 (cli) (built: Jun 10 2015 05:26:44) Copyright (c) 1997-2014 > >>The PHP Group Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend >>Technologies with Zend OPcache v7.0.4-dev, Copyright (c) 1999-2014, by > >>Zend Technologies >> >>Trace log: >> >>16:55:35.585240 15567 (log.c:196):Starting log file for FreeTDS 0.91 >> on 2016-02-04 16:55:35 with debug flags 0xffff. >>16:55:35.585295 15567 (iconv.c:330):tds_iconv_open(0x2569f10, UTF-8) >>16:55:35.585508 15567 (iconv.c:187):local name for ISO-8859-1 is >>ISO-8859-1 >>16:55:35.585528 15567 (iconv.c:187):local name for UTF-8 is UTF-8 >>16:55:35.585542 15567 (iconv.c:187):local name for UCS-2LE is UCS-2LE >>16:55:35.585560 15567 (iconv.c:187):local name for UCS-2BE is UCS-2BE >>16:55:35.585578 15567 (iconv.c:349):setting up conversions for client >>charset "UTF-8" >>16:55:35.585590 15567 (iconv.c:351):preparing iconv for "UTF-8" <-> >>"UCS-2LE" conversion >>16:55:35.585610 15567 (iconv.c:391):preparing iconv for "ISO-8859-1" >><-> "UCS-2LE" conversion >>16:55:35.585635 15567 (iconv.c:394):tds_iconv_open: done >>16:55:35.585647 15567 (util.c:331):tdserror(0x245d490, 0x2569f10, >>20013, 0) >>16:55:35.585666 15567 (dblib.c:7906):dbperror(0x2569530, 20013, 0) >>16:55:35.585681 15567 (dblib.c:7958):20013: "Unknown host machine >name" >>16:55:35.585717 15567 (dblib.c:7979):"Unknown host machine name", >>client returns 2 (INT_CANCEL) >>16:55:35.585734 15567 (util.c:361):tdserror: client library returned >>TDS_INT_CANCEL(2) >>16:55:35.585751 15567 (util.c:384):tdserror: returning >>TDS_INT_CANCEL(2) >>16:55:35.585766 15567 (login.c:417):IP address pointer is empty >>16:55:35.585776 15567 (login.c:419):Server 10.98.97.96:62220 not >found! >>16:55:35.585795 15567 (dblib.c:1424):dbclose(0x2569530) >>16:55:35.585815 15567 >>(dblib.c:258):dblib_del_connection(0x7f78f16cd800, 0x2569f10) >>16:55:35.585862 15567 (mem.c:615):tds_free_all_results() >>16:55:35.585890 15567 (dblib.c:305):dblib_release_tds_ctx(1) >>16:55:35.585909 15567 (dblib.c:5859):dbfreebuf(0x2569530) >>16:55:35.592809 15567 (dblib.c:724):dbloginfree(0x2569510) >>16:55:35.594342 15567 (dblib.c:1493):dbexit(void) >>16:55:35.594378 15567 (dblib.c:305):dblib_release_tds_ctx(1) >> >>---------------------------------------------------------------- >>ATTENTION: >>The information in this e-mail is confidential and only meant for the >>intended recipient. If you are not the intended recipient , don't use >>or disclose it in anyway. Please let the sender know and delete the >>message immediately. >>----------------------------------------------------------------------- >>------------------------------- >> >> >>_______________________________________________ >>FreeTDS mailing list >>FreeTDS at lists.ibiblio.org >>http://lists.ibiblio.org/mailman/listinfo/freetds > >-- >Odesl?no z m?ho telefonu s Androidem pomoc? po?ty K-9 Mail. Omluvte >pros?m moji stru?nost. >_______________________________________________ >FreeTDS mailing list >FreeTDS at lists.ibiblio.org >http://lists.ibiblio.org/mailman/listinfo/freetds > >------------------------------------------------------------------------------------------------------ >ATTENTION: >The information in this e-mail is confidential and only meant for the >intended recipient. If you are not the intended recipient , don't use >or disclose it in anyway. Please let the sender know and delete the >message immediately. >------------------------------------------------------------------------------------------------------ > >_______________________________________________ >FreeTDS mailing list >FreeTDS at lists.ibiblio.org >http://lists.ibiblio.org/mailman/listinfo/freetds -- Odesl?no z m?ho telefonu s Androidem pomoc? po?ty K-9 Mail. Omluvte pros?m moji stru?nost. From freddy77 at gmail.com Sun Feb 7 07:50:21 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Sun, 7 Feb 2016 12:50:21 +0000 Subject: [freetds] compute rows In-Reply-To: <772DB680-422D-403B-8C8C-DC35998401AD@capps.com> References: <772DB680-422D-403B-8C8C-DC35998401AD@capps.com> Message-ID: 2016-02-06 9:33 GMT+00:00 John Kendall : > I am having trouble with the output of compute rows. I found the following exchange from 2007 between jkl and Michael Peppler that summarizes what I'm experiencing in 2016: > > http://lists.ibiblio.org/pipermail/freetds/2007q1/020954.html > > To summarize, sqsh (and other tools linked to freetds) do not produce usable output for compute rows. Michael Peppler says that sqsh acts correctly when linked to sybase libs. I have an old copy of isql that handles compute statements in a very predictable way, for example: > > select col1=1, col2=1, col3=1 into tempdb..tab > insert tempdb..tab select 2,2,2 > insert tempdb..tab select 3,3,3 > go > select * from tempdb..tab compute sum(col1), avg(col1), min(col1), count(col1), avg(col2), max(col3), min(col3) > go > col1 col2 col3 > ----------- ----------- ----------- > 1 1 1 > 2 2 2 > 3 3 3 > sum > =========== > 6 > avg avg > =========== =========== > 2 2 > min min > =========== =========== > 1 1 > count > =========== > 3 > max > =========== > 3 > > (4 rows affected) > > > sqsh, linked to freetds, produces: > > col1 col2 col3 > ----------- ----------- ----------- > 1 1 1 > 2 2 2 > 3 3 3 > > =========== > 6 > > =========== > 2 > > =========== > 1 > > =========== =========== =========== > 3 2 3 > > =========== > 1 > > (4 rows affected) > > > Note how sqsh doesn't label the aggregate columns, and it combined count, avg and max into one row, while not combining the two min rows. Pretty useless. > > I no longer have access to sybase libs, so I cannot test sqsh linked to them. > Just for comparison, fisql has a different set of problems: > > col1 col2 col3 > ----------- ----------- ----------- > 1 1 1 > 2 2 2 > 3 3 3 > sum avg min count avg max min > ----------- ----------- ----------- ----------- ----------- ----------- ----------- > 6 2 1 3 2 3 1 > > (4 rows affected) > > Micheal's theory was that an API call in CTlib wasn't quite right, such as ct_describe() or ct_compute_info(). > Any ideas anyone? > Thanks, > John > Weird request. MS is trying to remove (if not already) support for COMPUTE. Probably the better way is to looks at the dumps (TDSDUMPs), and see what functions return. Then looks at documentation and callers (fisql, sqsh) and try to understand what's wrong. Frediano From matthew.green at datamartcomputing.com Mon Feb 8 03:53:14 2016 From: matthew.green at datamartcomputing.com (matthew.green at datamartcomputing.com) Date: Mon, 08 Feb 2016 08:53:14 +0000 Subject: [freetds] compute rows In-Reply-To: References: <772DB680-422D-403B-8C8C-DC35998401AD@capps.com> Message-ID: <5cff0c0a6e0b62c2c9f53db48d572c66@datamartcomputing.com> In case it helps: Sybase 15.7 client with sqsh produces "predictable" results, with the correct headings. On the other hand isql itself produced results more like fisql: 1> select * from tempdb..tab compute sum(col1), avg(col1), min(col1), count(col1), avg(col2), max(col3), min(col3) 2> go col1 col2 col3 ----------- ----------- ----------- 1 1 1 2 2 2 3 3 3 Compute Result: ----------- ----------- ----------- ----------- ----------- ----------- ----------- 6 2 1 3 2 3 1 Sybase on Windows (isql GUI) gives: col1 col2 col3 ----------- ----------- ----------- 1 1 1 2 2 2 3 3 3 (3 rows) Sum(col1) Avg(col1) Min(col1) Count(col1) Avg(col2) Max(col3) Min(col3) ----------- ----------- ----------- ----------- ----------- ----------- ----------- 6 2 1 3 2 3 1 but isql from a DOS box gives the same output as Solaris. All a bit of a mess, even when using the vendor version! I tried to track the TDS stream with Ribo and I couldn't see any obvious difference in communication flow in regard to the results returned in each case. I'd therefore guess that the presentation must be a client side decision. Cheers, Matthew. February 7 2016 1:50 PM, "Frediano Ziglio" wrote: > 2016-02-06 9:33 GMT+00:00 John Kendall : > >> I am having trouble with the output of compute rows. I found the following exchange from 2007 >> between jkl and Michael Peppler that summarizes what I'm experiencing in 2016: >> >> http://lists.ibiblio.org/pipermail/freetds/2007q1/020954.html >> >> To summarize, sqsh (and other tools linked to freetds) do not produce usable output for compute >> rows. Michael Peppler says that sqsh acts correctly when linked to sybase libs. I have an old > copy >> of isql that handles compute statements in a very predictable way, for example: >> >> select col1=1, col2=1, col3=1 into tempdb..tab >> insert tempdb..tab select 2,2,2 >> insert tempdb..tab select 3,3,3 >> go >> select * from tempdb..tab compute sum(col1), avg(col1), min(col1), count(col1), avg(col2), >> max(col3), min(col3) >> go >> col1 col2 col3 >> ----------- ----------- ----------- >> 1 1 1 >> 2 2 2 >> 3 3 3 >> sum >> =========== >> 6 >> avg avg >> =========== =========== >> 2 2 >> min min >> =========== =========== >> 1 1 >> count >> =========== >> 3 >> max >> =========== >> 3 >> >> (4 rows affected) >> >> sqsh, linked to freetds, produces: >> >> col1 col2 col3 >> ----------- ----------- ----------- >> 1 1 1 >> 2 2 2 >> 3 3 3 >> >> =========== >> 6 >> >> =========== >> 2 >> >> =========== >> 1 >> >> =========== =========== =========== >> 3 2 3 >> >> =========== >> 1 >> >> (4 rows affected) >> >> Note how sqsh doesn't label the aggregate columns, and it combined count, avg and max into one > row, >> while not combining the two min rows. Pretty useless. >> >> I no longer have access to sybase libs, so I cannot test sqsh linked to them. >> Just for comparison, fisql has a different set of problems: >> >> col1 col2 col3 >> ----------- ----------- ----------- >> 1 1 1 >> 2 2 2 >> 3 3 3 >> sum avg min count avg max min >> ----------- ----------- ----------- ----------- ----------- ----------- ----------- >> 6 2 1 3 2 3 1 >> >> (4 rows affected) >> >> Micheal's theory was that an API call in CTlib wasn't quite right, such as ct_describe() or >> ct_compute_info(). >> Any ideas anyone? >> Thanks, >> John > > Weird request. MS is trying to remove (if not already) support for COMPUTE. > Probably the better way is to looks at the dumps (TDSDUMPs), and see > what functions > return. Then looks at documentation and callers (fisql, sqsh) and try > to understand what's > wrong. > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From andrew.punch at smart-associates.biz Mon Feb 8 05:41:45 2016 From: andrew.punch at smart-associates.biz (Andrew Punch) Date: Mon, 8 Feb 2016 21:41:45 +1100 Subject: [freetds] FreeTDS Digest, Vol 157, Issue 1 In-Reply-To: References: Message-ID: <56B870E9.1000504@smart-associates.biz> Hi, The delimited file I am creating is for use with Netezza's create external table. This format would also be useful for Redshift. Excel format [https://tools.ietf.org/html/rfc4180] would also be acceptable as I could process it in awk or another tool if it is properly escaped. Regarding NULL. How do you suggest to differentiate between an empty field and a NULL? Currently freebcp inserts an ASCII NUL if the field is NULL. A zero length string has nothing between the delimiters. I suppose I could replace the ASCII NUL with the desired NULL character but what if there is an ASCII NUL in the field? -Andrew On 05/02/16 01:16, freetds-request at lists.ibiblio.org wrote: > Hi Andrew, > > It's a perfectly reasonable requirement, but I'm not sure that your implementation produces "properly formatted CSV output" as commonly understood. > Although there is no agreed standard for CSV, the Wikipedia page on CSV summarises my understanding of the conventions, namely that a CSV file requires: > > * lines that end with a newline character or characters (optional for the last line) > * An optional header record (although there is no sure way to detect whether it is present, so care is required when importing). > * Each record should contain the same number of comma-separated fields. > * Any field may be quoted (with double quotes). > * Fields containing a line-break, double-quote, and/or commas should be quoted. > * A (double) quote character in a field must be represented by two (double) quote characters. > > Given this, a neat way of fulfilling the requirement would be to implement a single command line flag, > which would operate as an alternative to the -c, -n or -f flags. > This could then: > > Default the field separator to comma, (with possible override using the -t flag) > Wrap double quotes around at least all the character fields extracted, maybe all fields... > Double up any double quotes in any character fields. > > And that's all you would need. > For most applications accepting CSV files (Excel for example) that would deal with the issues you have tried to address with the escaping functionality you've coded. > > I'm not sure about the Null string/field replacement stuff you've done. > An empty or absent field in CSV is usually just represented by two consecutive delimiters, and I think bcp would do that already. > > Hope this helps, > > Bill > > > > -----Original Message----- > From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of Andrew Punch > Sent: 03 February 2016 04:40 > To:freetds at lists.ibiblio.org > Subject: [freetds] freebcp adding escaping > > Hi, > > I had a requirement to have properly formatted CSV output from freebcp. > Unfortunately freebcp (and the original bcp) do not escape characters correctly. For example in a comma delimited file commas will not be escaped. Also the way NULLs are indicated can be inconvenient. > > I hacked together a patch which I have attached. I would like to do a pull after a clean up but I have a few questions: > > 1. is dblib the best place to make the change? > 2. what is the best structure to pass parameters and flags? Namely: > 1. Flag for delimiter escaping > 2. The actual delimiter (I notice that the column delimiter changes > to EOL for the last column) > 3. Flag for NULL string replacement (instead of ASCII NUL) > 4. NULL string replacement From cramm0 at gmail.com Tue Feb 9 14:03:12 2016 From: cramm0 at gmail.com (Ramiro Morales) Date: Tue, 9 Feb 2016 16:03:12 -0300 Subject: [freetds] OpenSSL misdetection by configure script Message-ID: Hi all, Found this while working with the Branch-0_95 branch code but I've just reproduced it with current master (commit https://github.com/FreeTDS/freetds/commit/5f6d9cdaac045ac7857398274ff18ceb0884139f) if with a fresh checkout I, as per INSTALL.GIT, run:: $ ./autogen $ ./configure --with-openssl=no OpenSSL support remains detected as active:: $ grep -in ssl include/config.h 265:/* Define if you have the OpenSSL. */ 266:#define HAVE_OPENSSL 1 This happens even if I uninstall development files for OpenSSL (libssl-dev .deb package). Autotools versions are (Ubuntu 14.04 LTS x86_64 system):: $ (autoconf --version; automake --version; libtool --version) |grep GNU autoconf (GNU Autoconf) 2.69 License GPLv3+/Autoconf: GNU GPL version 3 or later automake (GNU automake) 1.14.1 License GPLv2+: GNU GPL version 2 or later libtool (GNU libtool) 2.4.2 Anyone else sees the same issue? Regards, -- Ramiro Morales @ramiromorales From jezekj at centrum.cz Tue Feb 9 15:22:08 2016 From: jezekj at centrum.cz (jezekj at centrum.cz) Date: Tue, 09 Feb 2016 21:22:08 +0100 Subject: [freetds] =?utf-8?q?freetds_-_invalid_cursor_state?= Message-ID: <20160209212208.DD38D8BF@centrum.cz> Hi guys, we have to find some solution. ? We have perl script using DBD::ODBC to connect to MSSQL using unixODBC driver and FreeTDS. When we execute stored procedure and this stored procedure is executing another stored procedure with raiserror or print functions we get invalid cursor state error. ? i.e.: CREATE PROCEDURE [dbo].[dummyproc] as RAISERROR('test', 0, 0) return 0 ? CREATE PROCEDURE [dbo].[testproc] as select GETDATE() exec dummyproc select GETDATE() return 0 ? This happens ONLY when we try to fetch results from second getdate() function. i.e.: my $query = 'exec testproc'; my $sth?? = $dbh->prepare($query); $sth->execute || die "Error running query $query"; while ( my $d = $sth->fetchrow_arrayref ) { ??? print Dumper $d; #should return first getdate() } while ( my $d = $sth->fetchrow_arrayref ) { ??? print Dumper $d; #should return second getdate() } ? We?re using: Old perl 5.8.8. DBD::ODBC version 1.45 unixODBC 2.3.1 (also tried newest 2.3.4.) FreeTDS 0.91.dev.20110409RC1 (also tried FreeTDS 0.95.81) ? In case we use Easysoft database driver instead of FreeTDS the error does not appear. When I call out the procedure from tsql error does not appear. ? The log using latest FreeTDS can be found here: http://jezecek.dyndns.org/freetds.log The unixODBC log (not sure it will help) can be found here: http://jezecek.dyndns.org/odbc.log ? I would really really appreciate if you can let me know what to focus on. Thank you for any hints& supprt from you. ? Regards, JJ From freddy77 at gmail.com Tue Feb 9 16:24:22 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Tue, 9 Feb 2016 21:24:22 +0000 Subject: [freetds] OpenSSL misdetection by configure script In-Reply-To: References: Message-ID: 2016-02-09 19:03 GMT+00:00 Ramiro Morales : > Hi all, > > Found this while working with the Branch-0_95 branch code but I've > just reproduced it with current master (commit > https://github.com/FreeTDS/freetds/commit/5f6d9cdaac045ac7857398274ff18ceb0884139f) > > if with a fresh checkout I, as per INSTALL.GIT, run:: > > $ ./autogen > $ ./configure --with-openssl=no > > OpenSSL support remains detected as active:: > > $ grep -in ssl include/config.h > 265:/* Define if you have the OpenSSL. */ > 266:#define HAVE_OPENSSL 1 > > This happens even if I uninstall development files for OpenSSL > (libssl-dev .deb package). > > Autotools versions are (Ubuntu 14.04 LTS x86_64 system):: > > $ (autoconf --version; automake --version; libtool --version) |grep GNU > autoconf (GNU Autoconf) 2.69 > License GPLv3+/Autoconf: GNU GPL version 3 or later > automake (GNU automake) 1.14.1 > License GPLv2+: GNU GPL version 2 or later > > libtool (GNU libtool) 2.4.2 > > Anyone else sees the same issue? > > Regards, > > -- > Ramiro Morales I think everybody. I checked m4/check_openssl.m4 and has this behavior. Basically every value (even "no" which is used when you specify --without-openssl) specified cause the check to trigger. Weird that even uninstalling package OpenSSL was detected. Frediano From freddy77 at gmail.com Tue Feb 9 18:56:48 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Tue, 9 Feb 2016 23:56:48 +0000 Subject: [freetds] OpenSSL misdetection by configure script In-Reply-To: References: Message-ID: 2016-02-09 19:03 GMT+00:00 Ramiro Morales : > Hi all, > > Found this while working with the Branch-0_95 branch code but I've > just reproduced it with current master (commit > https://github.com/FreeTDS/freetds/commit/5f6d9cdaac045ac7857398274ff18ceb0884139f) > > if with a fresh checkout I, as per INSTALL.GIT, run:: > > $ ./autogen > $ ./configure --with-openssl=no > > OpenSSL support remains detected as active:: > > $ grep -in ssl include/config.h > 265:/* Define if you have the OpenSSL. */ > 266:#define HAVE_OPENSSL 1 > > This happens even if I uninstall development files for OpenSSL > (libssl-dev .deb package). > > Autotools versions are (Ubuntu 14.04 LTS x86_64 system):: > > $ (autoconf --version; automake --version; libtool --version) |grep GNU > autoconf (GNU Autoconf) 2.69 > License GPLv3+/Autoconf: GNU GPL version 3 or later > automake (GNU automake) 1.14.1 > License GPLv2+: GNU GPL version 2 or later > > libtool (GNU libtool) 2.4.2 > > Anyone else sees the same issue? > > Regards, > > -- > Ramiro Morales Fixed in master Can you try if works for you? The fact that is enabled even with package removed is weird. Frediano From freddy77 at gmail.com Tue Feb 9 19:05:29 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Wed, 10 Feb 2016 00:05:29 +0000 Subject: [freetds] freetds - invalid cursor state In-Reply-To: <20160209212208.DD38D8BF@centrum.cz> References: <20160209212208.DD38D8BF@centrum.cz> Message-ID: 2016-02-09 20:22 GMT+00:00 : > > Hi guys, we have to find some solution. > > We have perl script using DBD::ODBC to connect to MSSQL using unixODBC > driver and FreeTDS. When we execute stored procedure and this stored > procedure is executing another stored procedure with raiserror or print > functions we get invalid cursor state error. > > i.e.: > CREATE PROCEDURE [dbo].[dummyproc] as > RAISERROR('test', 0, 0) > return 0 > > CREATE PROCEDURE [dbo].[testproc] as > select GETDATE() > exec dummyproc > select GETDATE() > return 0 > > This happens ONLY when we try to fetch results from second getdate() > function. > i.e.: > my $query = 'exec testproc'; > my $sth = $dbh->prepare($query); > $sth->execute || die "Error running query $query"; > while ( my $d = $sth->fetchrow_arrayref ) { > print Dumper $d; #should return first getdate() > } > while ( my $d = $sth->fetchrow_arrayref ) { > print Dumper $d; #should return second getdate() > } > > We?re using: > Old perl 5.8.8. > DBD::ODBC version 1.45 > unixODBC 2.3.1 (also tried newest 2.3.4.) > FreeTDS 0.91.dev.20110409RC1 (also tried FreeTDS 0.95.81) > > In case we use Easysoft database driver instead of FreeTDS the error does > not appear. > When I call out the procedure from tsql error does not appear. > > The log using latest FreeTDS can be found here: > http://jezecek.dyndns.org/freetds.log > The unixODBC log (not sure it will help) can be found here: > http://jezecek.dyndns.org/odbc.log > > I would really really appreciate if you can let me know what to focus on. > Thank you for any hints& supprt from you. > > Regards, > JJ > Does not look so weird. In ODBC 3 resultset can have no records, for instance they can contains an error. You got an error in between two recordsets with rows. It seems that DBD::ODBC calls SQLFreeStmt(SQL_UNBIND) but this should not skip the error. I'll check exactly in this condition what SQLNumResultCols and SQLMoreResults returns with a Windows driver. I remember a similar problem using an old unixODBC version. Frediano From cramm0 at gmail.com Tue Feb 9 21:15:43 2016 From: cramm0 at gmail.com (Ramiro Morales) Date: Tue, 9 Feb 2016 23:15:43 -0300 Subject: [freetds] OpenSSL misdetection by configure script In-Reply-To: References: Message-ID: Frediano, On Tue, Feb 9, 2016 at 6:24 PM, Frediano Ziglio wrote: > 2016-02-09 19:03 GMT+00:00 Ramiro Morales : >> [...] >> $ ./configure --with-openssl=no >> [...] >> OpenSSL support remains detected as active:: >> [...] >> This happens even if I uninstall development files for OpenSSL >> (libssl-dev .deb package). > > I checked m4/check_openssl.m4 and has this behavior. Basically every > value (even "no" which is used when you specify --without-openssl) > specified cause the check to trigger. Aha! That was the key hint. > Weird that even uninstalling package OpenSSL was detected. With the OpenSSL development files still absent but don't specifying --with-openssl=no as I was doing then, once configure is run, I get HAVE_OPENSSL defined in config.h. Thanks! -- Ramiro Morales @ramiromorales From cramm0 at gmail.com Tue Feb 9 21:20:46 2016 From: cramm0 at gmail.com (Ramiro Morales) Date: Tue, 9 Feb 2016 23:20:46 -0300 Subject: [freetds] OpenSSL misdetection by configure script In-Reply-To: References: Message-ID: On Tue, Feb 9, 2016 at 11:15 PM, Ramiro Morales wrote: > Frediano, > > On Tue, Feb 9, 2016 at 6:24 PM, Frediano Ziglio wrote: > With the OpenSSL development files still absent but don't specifying > --with-openssl=no as I was doing then, once configure is run, I get > HAVE_OPENSSL defined in config.h. Sorry, I meant I DON'T get HAVE_OPENSSL defined in config.h. -- Ramiro Morales @ramiromorales From jezekj at centrum.cz Wed Feb 10 02:02:16 2016 From: jezekj at centrum.cz (jezekj at centrum.cz) Date: Wed, 10 Feb 2016 08:02:16 +0100 Subject: [freetds] =?utf-8?q?freetds_-_invalid_cursor_state?= In-Reply-To: References: <20160209212208.DD38D8BF@centrum.cz> Message-ID: <20160210080216.712E9D01@centrum.cz> Hello Frediano, ? thank you for looking into this issue. In the meantime I will rebuild our Perl::DBD to use latest unixODBC (2.3.4) nad let you know results. Please let me know your findings about status of SQLNumResultCols and SQLMoreResults when using Windows driver. ? Thank you, JJ ? ______________________________________________________________ > Od: Frediano Ziglio > Komu: FreeTDS Development Group > Datum: 10.02.2016 01:05 > P?edm?t: Re: [freetds] freetds - invalid cursor state > 2016-02-09 20:22 GMT+00:00 ?: > > Hi guys, we have to find some solution. > > We have perl script using DBD::ODBC to connect to MSSQL using unixODBC > driver and FreeTDS. When we execute stored procedure and this stored > procedure is executing another stored procedure with raiserror or print > functions we get invalid cursor state error. > > i.e.: > CREATE PROCEDURE [dbo].[dummyproc] as > RAISERROR('test', 0, 0) > return 0 > > CREATE PROCEDURE [dbo].[testproc] as > select GETDATE() > exec dummyproc > select GETDATE() > return 0 > > This happens ONLY when we try to fetch results from second getdate() > function. > i.e.: > my $query = 'exec testproc'; > my $sth ? = $dbh->prepare($query); > $sth->execute || die "Error running query $query"; > while ( my $d = $sth->fetchrow_arrayref ) { > ? ? print Dumper $d; #should return first getdate() > } > while ( my $d = $sth->fetchrow_arrayref ) { > ? ? print Dumper $d; #should return second getdate() > } > > We?re using: > Old perl 5.8.8. > DBD::ODBC version 1.45 > unixODBC 2.3.1 (also tried newest 2.3.4.) > FreeTDS 0.91.dev.20110409RC1 (also tried FreeTDS 0.95.81) > > In case we use Easysoft database driver instead of FreeTDS the error does > not appear. > When I call out the procedure from tsql error does not appear. > > The log using latest FreeTDS can be found here: > http://jezecek.dyndns.org/freetds.log > The unixODBC log (not sure it will help) can be found here: > http://jezecek.dyndns.org/odbc.log > > I would really really appreciate if you can let me know what to focus on. > Thank you for any hints& supprt from you. > > Regards, > JJ > Does not look so weird. In ODBC 3 resultset can have no records, for instance they can contains an error. You got an error in between two recordsets with rows. It seems that DBD::ODBC calls SQLFreeStmt(SQL_UNBIND) but this should not skip the error. I'll check exactly in this condition what SQLNumResultCols and SQLMoreResults returns with a Windows driver. I remember a similar problem using an old unixODBC version. Frediano _______________________________________________ FreeTDS mailing list FreeTDS at lists.ibiblio.org http://lists.ibiblio.org/mailman/listinfo/freetds From jezekj at centrum.cz Fri Feb 12 01:26:37 2016 From: jezekj at centrum.cz (jezekj at centrum.cz) Date: Fri, 12 Feb 2016 07:26:37 +0100 Subject: [freetds] =?utf-8?q?freetds_-_invalid_cursor_state?= In-Reply-To: <20160210080216.712E9D01@centrum.cz> References: <20160209212208.DD38D8BF@centrum.cz>, <20160210080216.712E9D01@centrum.cz> Message-ID: <20160212072637.EED451E7@centrum.cz> Hi again, I was investigating further a bit: 1) Have tried to use easysoft driver and tried to compare unixodbc log. Logs are same except the log when easysoft driver is used does continue with fetching of other data. 2) I have played with stored procedures and I have found that you do not need to call second procedure with print, or raiserror, these commands can be in one proc only. i.e.: Create procedure testproc as select getdate() print test select getdate() ? The invalid cursor state is thrown only when you do attempt to fetch data from procedure. ? This is fetching of first getdate of procedure: odbc.c:3615:SQLExecute returns SQL_SUCCESS odbc.c:4626:_SQLRowCount(0xb6130a0, 0xb612588), -1 rows odbc.c:4637:SQLRowCount returns 0, row count -1 odbc.c:4545:SQLNumResultCols(0xb6130a0, 0x7fff718bda50) odbc.c:4545:SQLNumResultCols(0xb6130a0, 0x7fff718bd9f6) odbc_export.h:195:SQLDescribeCol(0xb6130a0, 1, 0xb61d8d0, 128, 0xb61d870, 0xb61d882, 0xb61d878, 0xb61d880, 0xb61d884) odbc.c:2047:_SQLColAttribute(0xb6130a0, 1, 6, (nil), 0, (nil), 0xb61d890) odbc.c:2089:SQLColAttribute: fDescType is 6 odbc.c:2047:_SQLColAttribute(0xb6130a0, 1, 1003, (nil), 0, (nil), 0xb61d888) odbc.c:2089:SQLColAttribute: fDescType is 1003 odbc.c:1803:SQLBindCol(0xb6130a0, 1, 1, 0xb41c870, 24, 0xb61d8a8) odbc.c:4033:SQLFetch(0xb6130a0) odbc.c:3768:_SQLFetch(0xb6130a0, 1, 0) token.c:549:tds_process_tokens(0xb5ce7d0, 0x7fff718bd794, 0x7fff718bd790, 0x6508) util.c:165:Changed query state from PENDING to READING When you try to fetch second getdate log continues with: odbc.c:3697:odbc_process_tokens: processed TDS_DONEINPROC_RESULT odbc.c:895:SQLMoreResults: result_type=4054, row_count=-1, lastrc=1 error_export.h:6:SQLGetDiagRec(3, 0xb6130a0, 1, 0x7fff718bd870, 0x7fff718bd88c, 0x7fff718bd670, 512, 0x7fff718bd888) error.c:565:SQLGetDiagRec: "[FreeTDS][SQL Server]test" error_export.h:6:SQLGetDiagRec(3, 0xb6130a0, 2, 0x7fff718bd870, 0x7fff718bd88c, 0x7fff718bd670, 512, 0x7fff718bd888) odbc.c:4263:SQLFreeStmt(0xb6130a0, 2) odbc.c:4179:_SQLFreeStmt(0xb6130a0, 2, 0) odbc.c:4545:SQLNumResultCols(0xb6130a0, 0x7fff718bd9d6) odbc.c:4033:SQLFetch(0xb6130a0) odbc.c:3768:_SQLFetch(0xb6130a0, 1, 0) error.c:414:odbc_errs_add: "Invalid cursor state" error_export.h:6:SQLGetDiagRec(3, 0xb6130a0, 1, 0x7fff718bd870, 0x7fff718bd88c, 0x7fff718bd670, 512, 0x7fff718bd888) error.c:565:SQLGetDiagRec: "[FreeTDS][SQL Server]Invalid cursor state" error_export.h:6:SQLGetDiagRec(3, 0xb6130a0, 2, 0x7fff718bd870, 0x7fff718bd88c, 0x7fff718bd670, 512, 0x7fff718bd888) odbc.c:4263:SQLFreeStmt(0xb6130a0, 0) odbc.c:4179:_SQLFreeStmt(0xb6130a0, 0, 0) query.c:2189:tds_send_cancel: not in_cancel and not idle I have tried to rewrite the procedure: Create procedure testproc as print test select getdate() select getdate() And the tracefile is different and procedure runs fine: odbc.c:3615:SQLExecute returns SQL_SUCCESS_WITH_INFO error_export.h:6:SQLGetDiagRec(3, 0x2e4b0b0, 1, 0x7fff9ea22de0, 0x7fff9ea22dfc, 0x7fff9ea22be0, 512, 0x7fff9ea22df8) error.c:565:SQLGetDiagRec: "[FreeTDS][SQL Server]test" error_export.h:6:SQLGetDiagRec(3, 0x2e4b0b0, 2, 0x7fff9ea22de0, 0x7fff9ea22dfc, 0x7fff9ea22be0, 512, 0x7fff9ea22df8) odbc.c:4626:_SQLRowCount(0x2e4b0b0, 0x2e4a598), -1 rows odbc.c:4637:SQLRowCount returns 0, row count -1 odbc.c:4545:SQLNumResultCols(0x2e4b0b0, 0x7fff9ea22fa0) odbc.c:4545:SQLNumResultCols(0x2e4b0b0, 0x7fff9ea22f46) odbc_export.h:195:SQLDescribeCol(0x2e4b0b0, 1, 0x2e5a5d0, 128, 0x2e5a570, 0x2e5a582, 0x2e5a578, 0x2e5a580, 0x2e5a584) odbc.c:2047:_SQLColAttribute(0x2e4b0b0, 1, 6, (nil), 0, (nil), 0x2e5a590) odbc.c:2089:SQLColAttribute: fDescType is 6 odbc.c:2047:_SQLColAttribute(0x2e4b0b0, 1, 1003, (nil), 0, (nil), 0x2e5a588) odbc.c:2089:SQLColAttribute: fDescType is 1003 odbc.c:1803:SQLBindCol(0x2e4b0b0, 1, 1, 0x2c54880, 24, 0x2e5a5a8) odbc.c:4033:SQLFetch(0x2e4b0b0) odbc.c:3768:_SQLFetch(0x2e4b0b0, 1, 0) token.c:549:tds_process_tokens(0x2e067e0, 0x7fff9ea22ce4, 0x7fff9ea22ce0, 0x6508) util.c:165:Changed query state from PENDING to READING The main difference is that SQLExecute returns SQL_SUCCESS_WITH_INFO, but in case of failure it returns odbc.c:3615:SQLExecute returns SQL_SUCCESS Will this information be sufficient to get the issue fixed? Or do you want some more information from me to help you with investigation? Thanks & Regards, JJ ? ______________________________________________________________ > Od: > Komu: FreeTDS Development Group > Datum: 10.02.2016 08:57 > P?edm?t: Re: [freetds] freetds - invalid cursor state > Hello Frediano, ? thank you for looking into this issue. In the meantime I will rebuild our Perl::DBD to use latest unixODBC (2.3.4) nad let you know results. Please let me know your findings about status of SQLNumResultCols and SQLMoreResults when using Windows driver. ? Thank you, JJ ? ______________________________________________________________ > Od: Frediano Ziglio > Komu: FreeTDS Development Group > Datum: 10.02.2016 01:05 > P?edm?t: Re: [freetds] freetds - invalid cursor state > 2016-02-09 20:22 GMT+00:00 ?: > > Hi guys, we have to find some solution. > > We have perl script using DBD::ODBC to connect to MSSQL using unixODBC > driver and FreeTDS. When we execute stored procedure and this stored > procedure is executing another stored procedure with raiserror or print > functions we get invalid cursor state error. > > i.e.: > CREATE PROCEDURE [dbo].[dummyproc] as > RAISERROR('test', 0, 0) > return 0 > > CREATE PROCEDURE [dbo].[testproc] as > select GETDATE() > exec dummyproc > select GETDATE() > return 0 > > This happens ONLY when we try to fetch results from second getdate() > function. > i.e.: > my $query = 'exec testproc'; > my $sth ? = $dbh->prepare($query); > $sth->execute || die "Error running query $query"; > while ( my $d = $sth->fetchrow_arrayref ) { > ? ? print Dumper $d; #should return first getdate() > } > while ( my $d = $sth->fetchrow_arrayref ) { > ? ? print Dumper $d; #should return second getdate() > } > > We?re using: > Old perl 5.8.8. > DBD::ODBC version 1.45 > unixODBC 2.3.1 (also tried newest 2.3.4.) > FreeTDS 0.91.dev.20110409RC1 (also tried FreeTDS 0.95.81) > > In case we use Easysoft database driver instead of FreeTDS the error does > not appear. > When I call out the procedure from tsql error does not appear. > > The log using latest FreeTDS can be found here: > http://jezecek.dyndns.org/freetds.log > > The unixODBC log (not sure it will help) can be found here: > http://jezecek.dyndns.org/odbc.log > > > I would really really appreciate if you can let me know what to focus on. > Thank you for any hints& supprt from you. > > Regards, > JJ > Does not look so weird. In ODBC 3 resultset can have no records, for instance they can contains an error. You got an error in between two recordsets with rows. It seems that DBD::ODBC calls SQLFreeStmt(SQL_UNBIND) but this should not skip the error. I'll check exactly in this condition what SQLNumResultCols and SQLMoreResults returns with a Windows driver. I remember a similar problem using an old unixODBC version. Frediano _______________________________________________ FreeTDS mailing list FreeTDS at lists.ibiblio.org http://lists.ibiblio.org/mailman/listinfo/freetds > _______________________________________________ FreeTDS mailing list FreeTDS at lists.ibiblio.org http://lists.ibiblio.org/mailman/listinfo/freetds From marsupilami79 at gmx.de Fri Feb 12 05:42:55 2016 From: marsupilami79 at gmx.de (Marsupilami79) Date: Fri, 12 Feb 2016 11:42:55 +0100 Subject: [freetds] FreeTDS 0.95.84 and cmake Message-ID: <56BDB72F.8020605@gmx.de> Hello all, I am trying to build the current FreeTDS version that is downloadable from www.freetds.org using cmake 3.4 and Visual C++ 2013, as suggested by the user guide. Unfortunately cmake raises some errors, where the first error is that it cannot find the file /misc/cmake_checks.c. The misc directory is not included in the downloadable freeetds-patched.tar.gz. Is this the way it is supposed to be? What is the expected way to compile freetds in that case? With best regards, Jan Baumgarten From freddy77 at gmail.com Fri Feb 12 12:34:51 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Fri, 12 Feb 2016 17:34:51 +0000 Subject: [freetds] FreeTDS 0.95.84 and cmake In-Reply-To: <56BDB72F.8020605@gmx.de> References: <56BDB72F.8020605@gmx.de> Message-ID: 2016-02-12 10:42 GMT+00:00 Marsupilami79 : > Hello all, > > I am trying to build the current FreeTDS version that is downloadable > from www.freetds.org using cmake 3.4 and Visual C++ 2013, as suggested > by the user guide. Unfortunately cmake raises some errors, where the > first error is that it cannot find the file > /misc/cmake_checks.c. The misc directory is not included in > the downloadable freeetds-patched.tar.gz. > > Is this the way it is supposed to be? What is the expected way to > compile freetds in that case? > > With best regards, > > Jan Baumgarten > Fixed. Thanks for the report. Expect a new snapshot tomorrow. Frediano From no-reply at appveyor.com Fri Feb 12 20:17:58 2016 From: no-reply at appveyor.com (AppVeyor) Date: Sat, 13 Feb 2016 01:17:58 +0000 Subject: [freetds] Build failed: freetds 414 Message-ID: <20160213011752.31081.35489@appveyor.com> From freddy77 at gmail.com Sat Feb 13 03:20:09 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Sat, 13 Feb 2016 08:20:09 +0000 Subject: [freetds] freetds - invalid cursor state In-Reply-To: <20160212072637.EED451E7@centrum.cz> References: <20160209212208.DD38D8BF@centrum.cz> <20160210080216.712E9D01@centrum.cz> <20160212072637.EED451E7@centrum.cz> Message-ID: 2016-02-12 6:26 GMT+00:00 : > Hi again, > I was investigating further a bit: > > 1) Have tried to use easysoft driver and tried to compare unixodbc log. Logs > are same except the log when easysoft driver is used does continue with > fetching of other data. > Could you post these logs? Frediano > 2) I have played with stored procedures and I have found that you do not > need to call second procedure with print, or raiserror, these commands can > be in one proc only. i.e.: > > Create procedure testproc as > select getdate() > print test > select getdate() > > The invalid cursor state is thrown only when you do attempt to fetch data > from procedure. > > This is fetching of first getdate of procedure: > odbc.c:3615:SQLExecute returns SQL_SUCCESS > odbc.c:4626:_SQLRowCount(0xb6130a0, 0xb612588), -1 rows > odbc.c:4637:SQLRowCount returns 0, row count -1 > odbc.c:4545:SQLNumResultCols(0xb6130a0, 0x7fff718bda50) > odbc.c:4545:SQLNumResultCols(0xb6130a0, 0x7fff718bd9f6) > odbc_export.h:195:SQLDescribeCol(0xb6130a0, 1, 0xb61d8d0, 128, 0xb61d870, > 0xb61d882, 0xb61d878, 0xb61d880, 0xb61d884) > odbc.c:2047:_SQLColAttribute(0xb6130a0, 1, 6, (nil), 0, (nil), 0xb61d890) > odbc.c:2089:SQLColAttribute: fDescType is 6 > odbc.c:2047:_SQLColAttribute(0xb6130a0, 1, 1003, (nil), 0, (nil), 0xb61d888) > odbc.c:2089:SQLColAttribute: fDescType is 1003 > odbc.c:1803:SQLBindCol(0xb6130a0, 1, 1, 0xb41c870, 24, 0xb61d8a8) > odbc.c:4033:SQLFetch(0xb6130a0) > odbc.c:3768:_SQLFetch(0xb6130a0, 1, 0) > token.c:549:tds_process_tokens(0xb5ce7d0, 0x7fff718bd794, 0x7fff718bd790, > 0x6508) > util.c:165:Changed query state from PENDING to READING > > When you try to fetch second getdate log continues with: > odbc.c:3697:odbc_process_tokens: processed TDS_DONEINPROC_RESULT > odbc.c:895:SQLMoreResults: result_type=4054, row_count=-1, lastrc=1 > error_export.h:6:SQLGetDiagRec(3, 0xb6130a0, 1, 0x7fff718bd870, > 0x7fff718bd88c, 0x7fff718bd670, 512, 0x7fff718bd888) > error.c:565:SQLGetDiagRec: "[FreeTDS][SQL Server]test" > error_export.h:6:SQLGetDiagRec(3, 0xb6130a0, 2, 0x7fff718bd870, > 0x7fff718bd88c, 0x7fff718bd670, 512, 0x7fff718bd888) > odbc.c:4263:SQLFreeStmt(0xb6130a0, 2) > odbc.c:4179:_SQLFreeStmt(0xb6130a0, 2, 0) > odbc.c:4545:SQLNumResultCols(0xb6130a0, 0x7fff718bd9d6) > odbc.c:4033:SQLFetch(0xb6130a0) > odbc.c:3768:_SQLFetch(0xb6130a0, 1, 0) > error.c:414:odbc_errs_add: "Invalid cursor state" > error_export.h:6:SQLGetDiagRec(3, 0xb6130a0, 1, 0x7fff718bd870, > 0x7fff718bd88c, 0x7fff718bd670, 512, 0x7fff718bd888) > error.c:565:SQLGetDiagRec: "[FreeTDS][SQL Server]Invalid cursor state" > error_export.h:6:SQLGetDiagRec(3, 0xb6130a0, 2, 0x7fff718bd870, > 0x7fff718bd88c, 0x7fff718bd670, 512, 0x7fff718bd888) > odbc.c:4263:SQLFreeStmt(0xb6130a0, 0) > odbc.c:4179:_SQLFreeStmt(0xb6130a0, 0, 0) > query.c:2189:tds_send_cancel: not in_cancel and not idle > > I have tried to rewrite the procedure: > > Create procedure testproc as > print test > select getdate() > select getdate() > > And the tracefile is different and procedure runs fine: > odbc.c:3615:SQLExecute returns SQL_SUCCESS_WITH_INFO > error_export.h:6:SQLGetDiagRec(3, 0x2e4b0b0, 1, 0x7fff9ea22de0, > 0x7fff9ea22dfc, 0x7fff9ea22be0, 512, 0x7fff9ea22df8) > error.c:565:SQLGetDiagRec: "[FreeTDS][SQL Server]test" > error_export.h:6:SQLGetDiagRec(3, 0x2e4b0b0, 2, 0x7fff9ea22de0, > 0x7fff9ea22dfc, 0x7fff9ea22be0, 512, 0x7fff9ea22df8) > odbc.c:4626:_SQLRowCount(0x2e4b0b0, 0x2e4a598), -1 rows > odbc.c:4637:SQLRowCount returns 0, row count -1 > odbc.c:4545:SQLNumResultCols(0x2e4b0b0, 0x7fff9ea22fa0) > odbc.c:4545:SQLNumResultCols(0x2e4b0b0, 0x7fff9ea22f46) > odbc_export.h:195:SQLDescribeCol(0x2e4b0b0, 1, 0x2e5a5d0, 128, 0x2e5a570, > 0x2e5a582, 0x2e5a578, 0x2e5a580, 0x2e5a584) > odbc.c:2047:_SQLColAttribute(0x2e4b0b0, 1, 6, (nil), 0, (nil), 0x2e5a590) > odbc.c:2089:SQLColAttribute: fDescType is 6 > odbc.c:2047:_SQLColAttribute(0x2e4b0b0, 1, 1003, (nil), 0, (nil), 0x2e5a588) > odbc.c:2089:SQLColAttribute: fDescType is 1003 > odbc.c:1803:SQLBindCol(0x2e4b0b0, 1, 1, 0x2c54880, 24, 0x2e5a5a8) > odbc.c:4033:SQLFetch(0x2e4b0b0) > odbc.c:3768:_SQLFetch(0x2e4b0b0, 1, 0) > token.c:549:tds_process_tokens(0x2e067e0, 0x7fff9ea22ce4, 0x7fff9ea22ce0, > 0x6508) > util.c:165:Changed query state from PENDING to READING > > The main difference is that SQLExecute returns SQL_SUCCESS_WITH_INFO, but in > case of failure it returns odbc.c:3615:SQLExecute returns SQL_SUCCESS > > Will this information be sufficient to get the issue fixed? Or do you want > some more information from me to help you with investigation? > Thanks & Regards, > JJ > > ______________________________________________________________ >> >> Od: >> Komu: FreeTDS Development Group >> Datum: 10.02.2016 08:57 >> >> P?edm?t: Re: [freetds] freetds - invalid cursor state >> > Hello Frediano, > > thank you for looking into this issue. In the meantime I will rebuild our > Perl::DBD to use latest unixODBC (2.3.4) nad let you know results. Please > let me know your findings about status of SQLNumResultCols and > SQLMoreResults when using Windows driver. > > Thank you, > JJ > > ______________________________________________________________ >> >> Od: Frediano Ziglio >> Komu: FreeTDS Development Group >> Datum: 10.02.2016 01:05 >> P?edm?t: Re: [freetds] freetds - invalid cursor state >> > 2016-02-09 20:22 GMT+00:00 : >> >> >> Hi guys, we have to find some solution. >> >> We have perl script using DBD::ODBC to connect to MSSQL using unixODBC >> driver and FreeTDS. When we execute stored procedure and this stored >> procedure is executing another stored procedure with raiserror or print >> functions we get invalid cursor state error. >> >> i.e.: >> CREATE PROCEDURE [dbo].[dummyproc] as >> RAISERROR('test', 0, 0) >> return 0 >> >> CREATE PROCEDURE [dbo].[testproc] as >> select GETDATE() >> exec dummyproc >> select GETDATE() >> return 0 >> >> This happens ONLY when we try to fetch results from second getdate() >> function. >> i.e.: >> my $query = 'exec testproc'; >> my $sth = $dbh->prepare($query); >> $sth->execute || die "Error running query $query"; >> while ( my $d = $sth->fetchrow_arrayref ) { >> print Dumper $d; #should return first getdate() >> } >> while ( my $d = $sth->fetchrow_arrayref ) { >> print Dumper $d; #should return second getdate() >> } >> >> We?re using: >> Old perl 5.8.8. >> DBD::ODBC version 1.45 >> unixODBC 2.3.1 (also tried newest 2.3.4.) >> FreeTDS 0.91.dev.20110409RC1 (also tried FreeTDS 0.95.81) >> >> In case we use Easysoft database driver instead of FreeTDS the error does >> not appear. >> When I call out the procedure from tsql error does not appear. >> >> The log using latest FreeTDS can be found here: >> http://jezecek.dyndns.org/freetds.log >> >> > > >> The unixODBC log (not sure it will help) can be found here: >> http://jezecek.dyndns.org/odbc.log >> > >> >> I would really really appreciate if you can let me know what to focus on. >> Thank you for any hints& supprt from you. >> >> Regards, >> JJ >> > > Does not look so weird. In ODBC 3 resultset can have no records, for > instance they can contains an error. You got an error in between two > recordsets with rows. It seems that DBD::ODBC calls > SQLFreeStmt(SQL_UNBIND) but this should not skip the error. > I'll check exactly in this condition what SQLNumResultCols and > SQLMoreResults returns with a Windows driver. I remember a similar > problem using an old unixODBC version. > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > > > > > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From no-reply at appveyor.com Sat Feb 13 03:52:32 2016 From: no-reply at appveyor.com (AppVeyor) Date: Sat, 13 Feb 2016 08:52:32 +0000 Subject: [freetds] Build completed: freetds 415 Message-ID: <20160213085229.130803.98120@appveyor.com> From freddy77 at gmail.com Sat Feb 13 03:55:54 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Sat, 13 Feb 2016 08:55:54 +0000 Subject: [freetds] SQL Cluster always on In-Reply-To: <1452159106.2592.14.camel@gmail.com> References: <1452159106.2592.14.camel@gmail.com> Message-ID: 2016-01-07 9:31 GMT+00:00 esterniclos at gmail.com : > Hello everyone, > > We would like to adapt freetds to SQL Server Always On Clustering. > > This kind of cluster is pretty simple: > > > Every database has associated a Listener with a dns name. E.g. > dblistener.myorg.com > > Every listener has 2 or more IPs associated: > nslookup dblistener.myorg.com responds something like: 10.57.3.2 > and 10.57.4.52 > > > Only one of the IP's serves the database (active-passive) > > The connection has to be made directly to the listener. and use > the IP that is working at that moment. > > TDS Behaviour at this point. > > Right now, TDS works as long as the listener is in the first node. > In the example > dblistener.myorg.com instance working in 10.57.3.2 > > If the database is moved to another instance, it returns a timeout. > Never checks the rest of IPs > > Possible solution > > Try to login in several times with as many objects as IP's are > in DNS: > > tds/login.c:tds_set_host(TDSLOGIN * tds_login, > const char *hostname) > > > This would penalize a little when the database is in the > backup instance, as it has to receive a timeout before making the > connection. > > To speed up things, the last IP where the database was seen > could be also stored, and only ask dns if there is a time out. > > Thank you for your time, and any advice is welcome. > > Ester Nicl?s Ferreras Now (master) we try to connect to all IPs, not just the first. Yes, could be cached the last success somewhere but is a start. Frediano From Manasi.Deshpande at Renishaw.com Tue Feb 23 05:30:04 2016 From: Manasi.Deshpande at Renishaw.com (Manasi Deshpande) Date: Tue, 23 Feb 2016 10:30:04 +0000 Subject: [freetds] Issues in FreeTDS installation Message-ID: Hello, After building and installing freetds from source, I don't see libtdsodbc.so files! What could be the reason? Am I doing anything differently? Apparently I am also unable to download anything from FreeTDS downloads page! Need Help! Regards, 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 jezekj at centrum.cz Tue Feb 23 14:50:18 2016 From: jezekj at centrum.cz (jezekj at centrum.cz) Date: Tue, 23 Feb 2016 20:50:18 +0100 Subject: [freetds] =?utf-8?q?Issues_in_FreeTDS_installation?= In-Reply-To: References: Message-ID: <20160223205018.DE70CE48@centrum.cz> Hello, ? Try to run configure with parameter --with-unixodbc=DIR http://www.freetds.org/userguide/config.htm ? JJ ? ______________________________________________________________ > Od: Manasi Deshpande > Komu: FreeTDS Development Group > Datum: 23.02.2016 20:41 > P?edm?t: [freetds] Issues in FreeTDS installation > Hello, After building and installing freetds from source, I don't see libtdsodbc.so files! What could be the reason? Am I doing anything differently? Apparently I am also unable to download anything from FreeTDS downloads page! Need Help! Regards, 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. -------------------------------------------------------------------------------------------------- _______________________________________________ FreeTDS mailing list FreeTDS at lists.ibiblio.org http://lists.ibiblio.org/mailman/listinfo/freetds From geoff.montee at gmail.com Wed Feb 24 19:35:15 2016 From: geoff.montee at gmail.com (Geoff Montee) Date: Wed, 24 Feb 2016 16:35:15 -0800 Subject: [freetds] dbdatlen() returns 8 for NULL timestamp / rowversion value Message-ID: Hi all, According to MS SQL Server's documentation, the timestamp / rowversion data type is equivalent to binary(8) or varbinary(8) depending on whether the column is nullable. "A nonnullable rowversion column is semantically equivalent to a binary(8) column. A nullable rowversion column is semantically equivalent to a varbinary(8) column." https://msdn.microsoft.com/en-us/library/ms182776.aspx I can confirm that FreeTDS's dbcoltype() function returns 45 (SYBBINARY) as the data type for a timestamp column. I've noticed some strange behavior by dbdatlen() though. If I query a NULL binary(8) or varbinary(8) column, then dbdatlen() returns 0, which makes sense for a NULL column. However, if I query a NULL timestamp column, then dbdatlen() returns 8. This causes the NULL checks in my application (tds_fdw) to say that the column is not NULL. Is this intentional, or is this a bug? I noticed this behavior on FreeTDS 0.95.19 on RHEL 7. Thanks! Geoff From jezekj at centrum.cz Thu Feb 25 15:17:15 2016 From: jezekj at centrum.cz (jezekj at centrum.cz) Date: Thu, 25 Feb 2016 21:17:15 +0100 Subject: [freetds] =?utf-8?q?freetds_-_invalid_cursor_state?= In-Reply-To: References: <20160209212208.DD38D8BF@centrum.cz>, , <20160210080216.712E9D01@centrum.cz>, <20160212072637.EED451E7@centrum.cz> Message-ID: <20160225211715.C3104356@centrum.cz> Hello Frediano, ? I was busy with another tasks, but today I had some spare time so I've generated ODBC logs when using freetds and easysoft drivers. Both are attached. I would really apreciate if you can take a look at these logs and try to identify the root cause. I really would like to have this issue fixed. ? Thanks, Jakub ? ______________________________________________________________ > Od: Frediano Ziglio > Komu: FreeTDS Development Group > Datum: 13.02.2016 09:20 > P?edm?t: Re: [freetds] freetds - invalid cursor state > 2016-02-12 6:26 GMT+00:00 ?: > Hi again, > I was investigating further a bit: > > 1) Have tried to use easysoft driver and tried to compare unixodbc log. Logs > are same except the log when easysoft driver is used does continue with > fetching of other data. > Could you post these logs? Frediano > 2) I have played with stored procedures and I have found that you do not > need to call second procedure with print, or raiserror, these commands can > be in one proc only. i.e.: > > Create procedure testproc as > select getdate() > print test > select getdate() > > The invalid cursor state is thrown only when you do attempt to fetch data > from procedure. > > This is fetching of first getdate of procedure: > odbc.c:3615:SQLExecute returns SQL_SUCCESS > odbc.c:4626:_SQLRowCount(0xb6130a0, 0xb612588), -1 rows > odbc.c:4637:SQLRowCount returns 0, row count -1 > odbc.c:4545:SQLNumResultCols(0xb6130a0, 0x7fff718bda50) > odbc.c:4545:SQLNumResultCols(0xb6130a0, 0x7fff718bd9f6) > odbc_export.h:195:SQLDescribeCol(0xb6130a0, 1, 0xb61d8d0, 128, 0xb61d870, > 0xb61d882, 0xb61d878, 0xb61d880, 0xb61d884) > odbc.c:2047:_SQLColAttribute(0xb6130a0, 1, 6, (nil), 0, (nil), 0xb61d890) > odbc.c:2089:SQLColAttribute: fDescType is 6 > odbc.c:2047:_SQLColAttribute(0xb6130a0, 1, 1003, (nil), 0, (nil), 0xb61d888) > odbc.c:2089:SQLColAttribute: fDescType is 1003 > odbc.c:1803:SQLBindCol(0xb6130a0, 1, 1, 0xb41c870, 24, 0xb61d8a8) > odbc.c:4033:SQLFetch(0xb6130a0) > odbc.c:3768:_SQLFetch(0xb6130a0, 1, 0) > token.c:549:tds_process_tokens(0xb5ce7d0, 0x7fff718bd794, 0x7fff718bd790, > 0x6508) > util.c:165:Changed query state from PENDING to READING > > When you try to fetch second getdate log continues with: > odbc.c:3697:odbc_process_tokens: processed TDS_DONEINPROC_RESULT > odbc.c:895:SQLMoreResults: result_type=4054, row_count=-1, lastrc=1 > error_export.h:6:SQLGetDiagRec(3, 0xb6130a0, 1, 0x7fff718bd870, > 0x7fff718bd88c, 0x7fff718bd670, 512, 0x7fff718bd888) > error.c:565:SQLGetDiagRec: "[FreeTDS][SQL Server]test" > error_export.h:6:SQLGetDiagRec(3, 0xb6130a0, 2, 0x7fff718bd870, > 0x7fff718bd88c, 0x7fff718bd670, 512, 0x7fff718bd888) > odbc.c:4263:SQLFreeStmt(0xb6130a0, 2) > odbc.c:4179:_SQLFreeStmt(0xb6130a0, 2, 0) > odbc.c:4545:SQLNumResultCols(0xb6130a0, 0x7fff718bd9d6) > odbc.c:4033:SQLFetch(0xb6130a0) > odbc.c:3768:_SQLFetch(0xb6130a0, 1, 0) > error.c:414:odbc_errs_add: "Invalid cursor state" > error_export.h:6:SQLGetDiagRec(3, 0xb6130a0, 1, 0x7fff718bd870, > 0x7fff718bd88c, 0x7fff718bd670, 512, 0x7fff718bd888) > error.c:565:SQLGetDiagRec: "[FreeTDS][SQL Server]Invalid cursor state" > error_export.h:6:SQLGetDiagRec(3, 0xb6130a0, 2, 0x7fff718bd870, > 0x7fff718bd88c, 0x7fff718bd670, 512, 0x7fff718bd888) > odbc.c:4263:SQLFreeStmt(0xb6130a0, 0) > odbc.c:4179:_SQLFreeStmt(0xb6130a0, 0, 0) > query.c:2189:tds_send_cancel: not in_cancel and not idle > > I have tried to rewrite the procedure: > > Create procedure testproc as > print test > select getdate() > select getdate() > > And the tracefile is different and procedure runs fine: > odbc.c:3615:SQLExecute returns SQL_SUCCESS_WITH_INFO > error_export.h:6:SQLGetDiagRec(3, 0x2e4b0b0, 1, 0x7fff9ea22de0, > 0x7fff9ea22dfc, 0x7fff9ea22be0, 512, 0x7fff9ea22df8) > error.c:565:SQLGetDiagRec: "[FreeTDS][SQL Server]test" > error_export.h:6:SQLGetDiagRec(3, 0x2e4b0b0, 2, 0x7fff9ea22de0, > 0x7fff9ea22dfc, 0x7fff9ea22be0, 512, 0x7fff9ea22df8) > odbc.c:4626:_SQLRowCount(0x2e4b0b0, 0x2e4a598), -1 rows > odbc.c:4637:SQLRowCount returns 0, row count -1 > odbc.c:4545:SQLNumResultCols(0x2e4b0b0, 0x7fff9ea22fa0) > odbc.c:4545:SQLNumResultCols(0x2e4b0b0, 0x7fff9ea22f46) > odbc_export.h:195:SQLDescribeCol(0x2e4b0b0, 1, 0x2e5a5d0, 128, 0x2e5a570, > 0x2e5a582, 0x2e5a578, 0x2e5a580, 0x2e5a584) > odbc.c:2047:_SQLColAttribute(0x2e4b0b0, 1, 6, (nil), 0, (nil), 0x2e5a590) > odbc.c:2089:SQLColAttribute: fDescType is 6 > odbc.c:2047:_SQLColAttribute(0x2e4b0b0, 1, 1003, (nil), 0, (nil), 0x2e5a588) > odbc.c:2089:SQLColAttribute: fDescType is 1003 > odbc.c:1803:SQLBindCol(0x2e4b0b0, 1, 1, 0x2c54880, 24, 0x2e5a5a8) > odbc.c:4033:SQLFetch(0x2e4b0b0) > odbc.c:3768:_SQLFetch(0x2e4b0b0, 1, 0) > token.c:549:tds_process_tokens(0x2e067e0, 0x7fff9ea22ce4, 0x7fff9ea22ce0, > 0x6508) > util.c:165:Changed query state from PENDING to READING > > The main difference is that SQLExecute returns SQL_SUCCESS_WITH_INFO, but in > case of failure it returns odbc.c:3615:SQLExecute returns SQL_SUCCESS > > Will this information be sufficient to get the issue fixed? Or do you want > some more information from me to help you with investigation? > Thanks & Regards, > JJ > > ______________________________________________________________ >> >> Od: >> Komu: FreeTDS Development Group >> Datum: 10.02.2016 08:57 >> >> P?edm?t: Re: [freetds] freetds - invalid cursor state >> > Hello Frediano, > > thank you for looking into this issue. In the meantime I will rebuild our > Perl::DBD to use latest unixODBC (2.3.4) nad let you know results. Please > let me know your findings about status of SQLNumResultCols and > SQLMoreResults when using Windows driver. > > Thank you, > JJ > > ______________________________________________________________ >> >> Od: Frediano Ziglio >> Komu: FreeTDS Development Group >> Datum: 10.02.2016 01:05 >> P?edm?t: Re: [freetds] freetds - invalid cursor state >> > 2016-02-09 20:22 GMT+00:00 ?: >> >> >> Hi guys, we have to find some solution. >> >> We have perl script using DBD::ODBC to connect to MSSQL using unixODBC >> driver and FreeTDS. When we execute stored procedure and this stored >> procedure is executing another stored procedure with raiserror or print >> functions we get invalid cursor state error. >> >> i.e.: >> CREATE PROCEDURE [dbo].[dummyproc] as >> RAISERROR('test', 0, 0) >> return 0 >> >> CREATE PROCEDURE [dbo].[testproc] as >> select GETDATE() >> exec dummyproc >> select GETDATE() >> return 0 >> >> This happens ONLY when we try to fetch results from second getdate() >> function. >> i.e.: >> my $query = 'exec testproc'; >> my $sth ? = $dbh->prepare($query); >> $sth->execute || die "Error running query $query"; >> while ( my $d = $sth->fetchrow_arrayref ) { >> ? ? print Dumper $d; #should return first getdate() >> } >> while ( my $d = $sth->fetchrow_arrayref ) { >> ? ? print Dumper $d; #should return second getdate() >> } >> >> We?re using: >> Old perl 5.8.8. >> DBD::ODBC version 1.45 >> unixODBC 2.3.1 (also tried newest 2.3.4.) >> FreeTDS 0.91.dev.20110409RC1 (also tried FreeTDS 0.95.81) >> >> In case we use Easysoft database driver instead of FreeTDS the error does >> not appear. >> When I call out the procedure from tsql error does not appear. >> >> The log using latest FreeTDS can be found here: >> http://jezecek.dyndns.org/freetds.log >> > >> >> >> >> The unixODBC log (not sure it will help) can be found here: >> http://jezecek.dyndns.org/odbc.log > >> >> >> >> I would really really appreciate if you can let me know what to focus on. >> Thank you for any hints& supprt from you. >> >> Regards, >> JJ >> > > Does not look so weird. In ODBC 3 resultset can have no records, for > instance they can contains an error. You got an error in between two > recordsets with rows. It seems that DBD::ODBC calls > SQLFreeStmt(SQL_UNBIND) but this should not skip the error. > I'll check exactly in this condition what SQLNumResultCols and > SQLMoreResults returns with a Windows driver. I remember a similar > problem using an old unixODBC version. > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > > > > >> > > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > > > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds _______________________________________________ FreeTDS mailing list FreeTDS at lists.ibiblio.org http://lists.ibiblio.org/mailman/listinfo/freetds -------------- next part -------------- A non-text attachment was scrubbed... Name: odbc_freetds.log Type: text/x-log Size: 12539 bytes Desc: odbc_freetds.log URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: odbc_easysoft.log Type: text/x-log Size: 14926 bytes Desc: odbc_easysoft.log URL: From james.k.lowden at icloud.com Fri Feb 26 14:00:03 2016 From: james.k.lowden at icloud.com (James K. Lowden) Date: Fri, 26 Feb 2016 14:00:03 -0500 Subject: [freetds] freetds - invalid cursor state In-Reply-To: <20160225211715.C3104356@centrum.cz> References: <20160209212208.DD38D8BF@centrum.cz> <20160210080216.712E9D01@centrum.cz> <20160212072637.EED451E7@centrum.cz> <20160225211715.C3104356@centrum.cz> Message-ID: <20160226140003.d22a2767f7e1a044b93f4ea6@icloud.com> On Thu, 25 Feb 2016 21:17:15 +0100 wrote: > Both are attached. I would really apreciate if you can take a look at > these logs and try to identify the root cause. Perhaps I'm missing something, but to me it looks like a contradiction. In the FreeTDS log, we see, [ODBC][21590][1456398626.473093][SQLError.c][389] Exit:[SQL_SUCCESS] SQLState = 24000 Native = 0x7fff2ad0ec58 -> 0 Message Text = [[FreeTDS][SQL Server]Invalid cursor state] SQL_SUCCESS is not an error, so "Invalid cursor state" cannot describe the state. Either the operation succeeded, or it failed because of an invalid cursor state. --jkl From freddy77 at gmail.com Fri Feb 26 14:23:09 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Fri, 26 Feb 2016 19:23:09 +0000 Subject: [freetds] freetds - invalid cursor state In-Reply-To: <20160226140003.d22a2767f7e1a044b93f4ea6@icloud.com> References: <20160209212208.DD38D8BF@centrum.cz> <20160210080216.712E9D01@centrum.cz> <20160212072637.EED451E7@centrum.cz> <20160225211715.C3104356@centrum.cz> <20160226140003.d22a2767f7e1a044b93f4ea6@icloud.com> Message-ID: On 26 Feb 2016 19:00, "James K. Lowden" wrote: > > On Thu, 25 Feb 2016 21:17:15 +0100 > wrote: > > > Both are attached. I would really apreciate if you can take a look at > > these logs and try to identify the root cause. > > Perhaps I'm missing something, but to me it looks like a contradiction. > In the FreeTDS log, we see, > > [ODBC][21590][1456398626.473093][SQLError.c][389] > Exit:[SQL_SUCCESS] > SQLState = 24000 > Native = 0x7fff2ad0ec58 -> 0 > Message Text = [[FreeTDS][SQL Server]Invalid > cursor state] > > > SQL_SUCCESS is not an error, so "Invalid cursor state" cannot describe > the state. Either the operation succeeded, or it failed because of an > invalid cursor state. > Well... time for a beer I think. However. Sql error returns the error string for previous function calls. So it succeeded (returned the error) and error was "Invalid cursor state" Frediano From jezekj at centrum.cz Fri Feb 26 14:26:07 2016 From: jezekj at centrum.cz (jezekj at centrum.cz) Date: Fri, 26 Feb 2016 20:26:07 +0100 Subject: [freetds] =?utf-8?q?freetds_-_invalid_cursor_state?= In-Reply-To: <20160226140003.d22a2767f7e1a044b93f4ea6@icloud.com> References: <20160209212208.DD38D8BF@centrum.cz>, , <20160210080216.712E9D01@centrum.cz>, <20160212072637.EED451E7@centrum.cz>, , <20160225211715.C3104356@centrum.cz> <20160226140003.d22a2767f7e1a044b93f4ea6@icloud.com> Message-ID: <20160226202607.30BADF06@centrum.cz> Hello James, ? so let me describe whole story again. ? we have stored procedure: create procedure test_me as select getdate() print test select getdate() ? Then we have piece of perl: my $query = 'exec testproc'; my $sth = $dbh->prepare($query); $sth->execute || die "Error running query $query"; while ( my $d = $sth->fetchrow_arrayref ) { print Dumper $d; #should return first getdate() } while ( my $d = $sth->fetchrow_arrayref ) { print Dumper $d; #should return second getdate()} ? Perl is connecting through DBD::ODBC version 1.45 then we have unixODBC ( 2.3.1 ) as odbc manager, we also tried version 2.3.4 and we have both: FreeTDS 0.91.dev.20110409RC1 (also tried FreeTDS 0.95.81), Easysoft (don't know version) ? ? When we use easysoft driver the result set contains date, then printed text "test" and another result set contains another date. When we use FreeTDS driver result set contains: date printed out 'test' followed by invalid cursor state error. ? When we do not fetch the second result set no error is thrown. ? Sorry, but I have no idea how to understand ODBC logs. ? Jakub ? ______________________________________________________________ > Od: "James K. Lowden" > Komu: > Datum: 26.02.2016 20:00 > P?edm?t: Re: [freetds] freetds - invalid cursor state > On Thu, 25 Feb 2016 21:17:15 +0100 wrote: > Both are attached. I would really apreciate if you can take a look at > these logs and try to identify the root cause. Perhaps I'm missing something, but to me it looks like a contradiction. In the FreeTDS log, we see, [ODBC][21590][1456398626.473093][SQLError.c][389] ? ? ? ? ? ? ? ?Exit:[SQL_SUCCESS] ? ? ? ? ? ? ? ? ? ? ? ?SQLState = 24000 ? ? ? ? ? ? ? ? ? ? ? ?Native = 0x7fff2ad0ec58 -> 0 ? ? ? ? ? ? ? ? ? ? ? ?Message Text = [[FreeTDS][SQL Server]Invalid cursor state] SQL_SUCCESS is not an error, so "Invalid cursor state" cannot describe the state. ?Either the operation succeeded, or it failed because of an invalid cursor state. ? --jkl _______________________________________________ FreeTDS mailing list FreeTDS at lists.ibiblio.org http://lists.ibiblio.org/mailman/listinfo/freetds From jezekj at centrum.cz Fri Feb 26 14:28:34 2016 From: jezekj at centrum.cz (jezekj at centrum.cz) Date: Fri, 26 Feb 2016 20:28:34 +0100 Subject: [freetds] =?utf-8?q?freetds_-_invalid_cursor_state?= In-Reply-To: References: <20160209212208.DD38D8BF@centrum.cz>, , <20160210080216.712E9D01@centrum.cz>, <20160212072637.EED451E7@centrum.cz>, , <20160225211715.C3104356@centrum.cz>, <20160226140003.d22a2767f7e1a044b93f4ea6@icloud.com> Message-ID: <20160226202834.4F65C15E@centrum.cz> But no cursor is open since the begining. I know that some drivers are opening cursors implicitly, but me as a user I cannot do anything with this, or can I? ? When issue is solved and you are in Prague the beer is on me! ? JJ ? ______________________________________________________________ > Od: Frediano Ziglio > Komu: FreeTDS Development Group , "James K. Lowden" > Datum: 26.02.2016 20:23 > P?edm?t: Re: [freetds] freetds - invalid cursor state > On 26 Feb 2016 19:00, "James K. Lowden" wrote: > > On Thu, 25 Feb 2016 21:17:15 +0100 > wrote: > > > Both are attached. I would really apreciate if you can take a look at > > these logs and try to identify the root cause. > > Perhaps I'm missing something, but to me it looks like a contradiction. > In the FreeTDS log, we see, > > [ODBC][21590][1456398626.473093][SQLError.c][389] > ? ? ? ? ? ? ? ? Exit:[SQL_SUCCESS] > ? ? ? ? ? ? ? ? ? ? ? ? SQLState = 24000 > ? ? ? ? ? ? ? ? ? ? ? ? Native = 0x7fff2ad0ec58 -> 0 > ? ? ? ? ? ? ? ? ? ? ? ? Message Text = [[FreeTDS][SQL Server]Invalid > cursor state] > > > SQL_SUCCESS is not an error, so "Invalid cursor state" cannot describe > the state. ?Either the operation succeeded, or it failed because of an > invalid cursor state. > Well... time for a beer I think. However. Sql error returns the error string for previous function calls. So it succeeded (returned the error) and error was "Invalid cursor state" Frediano _______________________________________________ FreeTDS mailing list FreeTDS at lists.ibiblio.org http://lists.ibiblio.org/mailman/listinfo/freetds From freddy77 at gmail.com Sat Feb 27 04:16:33 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Sat, 27 Feb 2016 09:16:33 +0000 Subject: [freetds] freetds - invalid cursor state In-Reply-To: <20160226202834.4F65C15E@centrum.cz> References: <20160209212208.DD38D8BF@centrum.cz> <20160210080216.712E9D01@centrum.cz> <20160212072637.EED451E7@centrum.cz> <20160225211715.C3104356@centrum.cz> <20160226140003.d22a2767f7e1a044b93f4ea6@icloud.com> <20160226202834.4F65C15E@centrum.cz> Message-ID: I found the problem! But you won't like it! Easysoft is wrong! Well... all other ODBC drivers (I tested FreeTDS, NCLI and NCLI10 which are Microsoft SQL Server 2005 and 2008) all behave the same (returning 0 columns from SQLNumResultCols and "Invalid Cursor State" from SQLFetch). The main reason is that in ODBC 3 (ODBC 2 is obsolete since 20 years or so) a record set can just contain the error with no rows. What you are trying to do is getting rows while you have no rows. The fact that easysoft join the error to next record set (which is more a ODBC 2 behaviour) is just different from the standard MSSQL (and FreeTDS) drivers. So the solution has to be searched in higher level (DBD::ODBC or your program). Surely you can get all record sets using DBD::ODBC as is tested really well with MSSQL using Microsoft drivers. Frediano 2016-02-26 19:28 GMT+00:00 : > But no cursor is open since the begining. I know that some drivers are > opening cursors implicitly, but me as a user I cannot do anything with this, > or can I? > > When issue is solved and you are in Prague the beer is on me! > > JJ > > ______________________________________________________________ >> >> Od: Frediano Ziglio >> Komu: FreeTDS Development Group , "James K. >> Lowden" >> Datum: 26.02.2016 20:23 >> P?edm?t: Re: [freetds] freetds - invalid cursor state >> > On 26 Feb 2016 19:00, "James K. Lowden" wrote: >> >> >> On Thu, 25 Feb 2016 21:17:15 +0100 >> wrote: >> >> > Both are attached. I would really apreciate if you can take a look at >> > these logs and try to identify the root cause. >> >> Perhaps I'm missing something, but to me it looks like a contradiction. >> In the FreeTDS log, we see, >> >> [ODBC][21590][1456398626.473093][SQLError.c][389] >> Exit:[SQL_SUCCESS] >> SQLState = 24000 >> Native = 0x7fff2ad0ec58 -> 0 >> Message Text = [[FreeTDS][SQL Server]Invalid >> cursor state] >> >> >> SQL_SUCCESS is not an error, so "Invalid cursor state" cannot describe >> the state. Either the operation succeeded, or it failed because of an >> invalid cursor state. >> > > Well... time for a beer I think. > However. Sql error returns the error string for previous function calls. So > it succeeded (returned the error) and error was "Invalid cursor state" > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > > > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From john at capps.com Sat Feb 27 05:16:37 2016 From: john at capps.com (John Kendall) Date: Sat, 27 Feb 2016 10:16:37 +0000 Subject: [freetds] compute rows Message-ID: Greetings. I've looked into this and have found one problem and I have a patch. It appears freetds ct_compute_info is not returning the same aggregate operator type as the sybase client lib. According to http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.infocenter.dc32840.1550/html/ctref/CIHHCJCJ.htm ct_compute_info should return one of the following symbolic values when passed the CS_COMP_OP type: CS_OP_SUM, CS_OP_AVG, CS_OP_COUNT, CS_OP_MIN or CS_OP_MAX. According to cspublic.h, these symbolic values are: #define CS_OP_SUM 5370 #define CS_OP_AVG 5371 #define CS_OP_COUNT 5372 #define CS_OP_MIN 5373 #define CS_OP_MAX 5374 However, freetds ct_compute_info is consistently returning the following: for SUM: 77 for AVG: 79 for COUNT: 75 for MIN: 81 for MAX: 82 By consistently, i mean I've tested it on Sybase 11.02, ASE 16 and MS SQL 2012 with Linux and SPARC clients. Looking at dumps, it appears that all 3 servers are returning the lower numbers (77, 79, etc) and freetds ct_compute_info returns the value unmodified. Clearly that is not what the sybase client is doing. It must be doing some mapping of the wire numbers to the symbolic values. I've patched my copy of ct.c like so: *** 2625,2636 **** --- 2625,2644 ---- case CS_COMP_OP: if (!resinfo) { int_val = 0; } else { curcol = resinfo->columns[colnum - 1]; int_val = curcol->column_operator; + switch (int_val) + { + case 77: int_val= CS_OP_SUM; break; + case 79: int_val= CS_OP_AVG; break; + case 75: int_val= CS_OP_COUNT; break; + case 81: int_val= CS_OP_MIN; break; + case 82: int_val= CS_OP_MAX; break; + } } memcpy(buffer, &int_val, sizeof(CS_INT)); if (outlen) *outlen = sizeof(CS_INT); break; default: Could this, or somethings like it, be applied to the master? John Date: Mon, 08 Feb 2016 08:53:14 +0000 From: matthew.green at datamartcomputing.com To: "FreeTDS Development Group" Subject: Re: [freetds] compute rows Message-ID: <5cff0c0a6e0b62c2c9f53db48d572c66 at datamartcomputing.com> In case it helps: Sybase 15.7 client with sqsh produces "predictable" results, with the correct headings. On the other hand isql itself produced results more like fisql: 1> select * from tempdb..tab compute sum(col1), avg(col1), min(col1), count(col1), avg(col2), max(col3), min(col3) 2> go col1 col2 col3 ----------- ----------- ----------- 1 1 1 2 2 2 3 3 3 Compute Result: ----------- ----------- ----------- ----------- ----------- ----------- ----------- 6 2 1 3 2 3 1 Sybase on Windows (isql GUI) gives: col1 col2 col3 ----------- ----------- ----------- 1 1 1 2 2 2 3 3 3 (3 rows) Sum(col1) Avg(col1) Min(col1) Count(col1) Avg(col2) Max(col3) Min(col3) ----------- ----------- ----------- ----------- ----------- ----------- ----------- 6 2 1 3 2 3 1 but isql from a DOS box gives the same output as Solaris. All a bit of a mess, even when using the vendor version! I tried to track the TDS stream with Ribo and I couldn't see any obvious difference in communication flow in regard to the results returned in each case. I'd therefore guess that the presentation must be a client side decision. Cheers, Matthew. February 7 2016 1:50 PM, "Frediano Ziglio" wrote: > 2016-02-06 9:33 GMT+00:00 John Kendall : > >> I am having trouble with the output of compute rows. I found the following exchange from 2007 >> between jkl and Michael Peppler that summarizes what I'm experiencing in 2016: >> >> http://lists.ibiblio.org/pipermail/freetds/2007q1/020954.html >> >> To summarize, sqsh (and other tools linked to freetds) do not produce usable output for compute >> rows. Michael Peppler says that sqsh acts correctly when linked to sybase libs. I have an old > copy >> of isql that handles compute statements in a very predictable way, for example: >> >> select col1=1, col2=1, col3=1 into tempdb..tab >> insert tempdb..tab select 2,2,2 >> insert tempdb..tab select 3,3,3 >> go >> select * from tempdb..tab compute sum(col1), avg(col1), min(col1), count(col1), avg(col2), >> max(col3), min(col3) >> go >> col1 col2 col3 >> ----------- ----------- ----------- >> 1 1 1 >> 2 2 2 >> 3 3 3 >> sum >> =========== >> 6 >> avg avg >> =========== =========== >> 2 2 >> min min >> =========== =========== >> 1 1 >> count >> =========== >> 3 >> max >> =========== >> 3 >> >> (4 rows affected) >> >> sqsh, linked to freetds, produces: >> >> col1 col2 col3 >> ----------- ----------- ----------- >> 1 1 1 >> 2 2 2 >> 3 3 3 >> >> =========== >> 6 >> >> =========== >> 2 >> >> =========== >> 1 >> >> =========== =========== =========== >> 3 2 3 >> >> =========== >> 1 >> >> (4 rows affected) >> >> Note how sqsh doesn't label the aggregate columns, and it combined count, avg and max into one > row, >> while not combining the two min rows. Pretty useless. >> >> I no longer have access to sybase libs, so I cannot test sqsh linked to them. >> Just for comparison, fisql has a different set of problems: >> >> col1 col2 col3 >> ----------- ----------- ----------- >> 1 1 1 >> 2 2 2 >> 3 3 3 >> sum avg min count avg max min >> ----------- ----------- ----------- ----------- ----------- ----------- ----------- >> 6 2 1 3 2 3 1 >> >> (4 rows affected) >> >> Micheal's theory was that an API call in CTlib wasn't quite right, such as ct_describe() or >> ct_compute_info(). >> Any ideas anyone? >> Thanks, >> John > > Weird request. MS is trying to remove (if not already) support for COMPUTE. > Probably the better way is to looks at the dumps (TDSDUMPs), and see > what functions > return. Then looks at documentation and callers (fisql, sqsh) and try > to understand what's > wrong. > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From freddy77 at gmail.com Sun Feb 28 15:35:56 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Sun, 28 Feb 2016 20:35:56 +0000 Subject: [freetds] dbdatlen() returns 8 for NULL timestamp / rowversion value In-Reply-To: References: Message-ID: On 25 Feb 2016 23:10, "Geoff Montee" wrote: > > Hi all, > > According to MS SQL Server's documentation, the timestamp / rowversion > data type is equivalent to binary(8) or varbinary(8) depending on > whether the column is nullable. > > "A nonnullable rowversion column is semantically equivalent to a > binary(8) column. A nullable rowversion column is semantically > equivalent to a varbinary(8) column." > > https://msdn.microsoft.com/en-us/library/ms182776.aspx > > I can confirm that FreeTDS's dbcoltype() function returns 45 > (SYBBINARY) as the data type for a timestamp column. I've noticed some > strange behavior by dbdatlen() though. > > If I query a NULL binary(8) or varbinary(8) column, then dbdatlen() > returns 0, which makes sense for a NULL column. However, if I query a > NULL timestamp column, then dbdatlen() returns 8. This causes the NULL > checks in my application (tds_fdw) to say that the column is not NULL. > > Is this intentional, or is this a bug? > > I noticed this behavior on FreeTDS 0.95.19 on RHEL 7. > > Thanks! > > Geoff > I don't known. Can you send a log (tds dump)? If I remember the only difference for timestamps and binaries are the usertype. Possibly binary is always used instead of varbinary. Frediano From igor.anic at gmail.com Tue Mar 1 04:46:30 2016 From: igor.anic at gmail.com (=?UTF-8?Q?Igor_Ani=C4=87?=) Date: Tue, 1 Mar 2016 10:46:30 +0100 Subject: [freetds] Fwd: dbrpcparam and varchar(max) column In-Reply-To: References: Message-ID: I'have stored procedure with output param of datatype varchar(max) and can't find the way to pass string longer than 8000 characters. Setting 5th parameter in dbrpcparam (maxlen) to value greater then 8000 has no effect. In sql server profiler varchar is always declared with max 8000 in size. Setting maxlen to 0 has the same effect. >From profiler: declare @p1 varchar(8000) set @p1=' ... ' exec test_sp_varchar_max @p1=@p1 output select @p1 What is the right way to use stored procedures with varchar(max) datatype. Thanks, Igor. dbrpcparam reference: http://www.freetds.org/reference/a00342.html#ga98b9b5db66975dafae8d422218e4de45 From joshua.h.lang at gmail.com Mon Mar 7 13:45:10 2016 From: joshua.h.lang at gmail.com (Joshua Lang) Date: Mon, 7 Mar 2016 10:45:10 -0800 Subject: [freetds] Fwd: dbrpcparam and varchar(max) column In-Reply-To: References: Message-ID: I ran into this same problem a few months back: http://lists.ibiblio.org/pipermail/freetds/2015q4/029664.html A workaround is to use the TEXT type (SYBTEXT) instead. I haven't extensively tested it, but it seems to work for the basic cases I have tested, such as yours. On Tue, Mar 1, 2016 at 1:46 AM, Igor Ani? wrote: > I'have stored procedure with output param of datatype varchar(max) and > can't find the way to pass string longer than 8000 characters. > > Setting 5th parameter in dbrpcparam (maxlen) to value greater then 8000 has > no effect. In sql server profiler varchar is always declared with max 8000 > in size. Setting maxlen to 0 has the same effect. > From profiler: > > declare @p1 varchar(8000) > set @p1=' ... ' > exec test_sp_varchar_max @p1=@p1 output > select @p1 > > > What is the right way to use stored procedures with varchar(max) datatype. > > Thanks, > Igor. > > dbrpcparam reference: > > http://www.freetds.org/reference/a00342.html#ga98b9b5db66975dafae8d422218e4de45 > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > From freddy77 at gmail.com Tue Mar 15 19:37:37 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Tue, 15 Mar 2016 23:37:37 +0000 Subject: [freetds] Empty VARCHAR parameters converted to NULL In-Reply-To: References: Message-ID: I was looking at this issue. The problem raise when you want a return value but you want to pass a empty or a NULL varchar. How to differentiate in this case? value cannot be NULL for return parameters. Frediano 2016-01-19 18:25 GMT+00:00 Joshua Lang : > I've read that older versions didn't even support passing 0-length data > (prior to TDS 7.0 I believe). If this could be supported for later versions > of TDS 7.0, that would be great. > > Thanks. > > On Tue, Jan 19, 2016 at 2:52 AM, Frediano Ziglio wrote: > >> 2016-01-16 1:41 GMT+00:00 Joshua Lang : >> > In the latest version of FreeTDS-dblib (0.95.79) I'm passing rpc VARCHAR >> > parameters of 0 length, but non-NULL (empty strings). FreeTDS seems to >> turn >> > these into NULL values before passing them on to SQL Server. From what >> I've >> > read, it seems as if older databases didn't support passing empty >> strings, >> > but newer ones do? (i.e. TDS 7.0+ do support empty strings). >> > >> > It seems as this is a known issue, but I was wondering if it is possible >> to >> > fix it for the newer versions of SQL server? E.g. in dbrpcparam() >> passing a >> > non-NULL pointer to the 'value' parameter and a 0 to 'datalen' would >> > indicate an empty string is desired if possible. >> > >> > Thoughts? >> >> >> The main problem is not libTDS (the code library) but dbrpcparam >> specification. >> datalen < 0 is invalid for variable fields (like VARCHAR) and 0 is used >> for NULL >> value (no matter the data pointer). But looks like your suggestion >> (not NULL value >> and 0 datalen) could be a good choice. >> Not sure however if this could work with all types and server versions >> (for instance >> 0 size TEXT). >> We can do it but I'm not thinking about backporting it to 0.95. >> >> Frediano >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> http://lists.ibiblio.org/mailman/listinfo/freetds >> > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From joshua.h.lang at gmail.com Tue Mar 15 20:22:46 2016 From: joshua.h.lang at gmail.com (Joshua Lang) Date: Tue, 15 Mar 2016 17:22:46 -0700 Subject: [freetds] Empty VARCHAR parameters converted to NULL In-Reply-To: References: Message-ID: I assume you're referring to input/output parameters where the input value is NULL, but the output value is non-NULL? The MSDN docs for rpcparam ( https://msdn.microsoft.com/en-us/library/aa937102(v=sql.80).aspx) don't really indicate how this case is handled, but I think the following would work for the input/output parameter: maxlen = datalen = 0 Basically maxlen is used for the length of the output parameter buffer and datalen is the length of the input data. Thoughts? On Tue, Mar 15, 2016 at 4:37 PM, Frediano Ziglio wrote: > I was looking at this issue. The problem raise when you want a return > value but you want to pass a empty or a NULL varchar. How to > differentiate in this case? value cannot be NULL for return > parameters. > > Frediano > > > 2016-01-19 18:25 GMT+00:00 Joshua Lang : > > I've read that older versions didn't even support passing 0-length data > > (prior to TDS 7.0 I believe). If this could be supported for later > versions > > of TDS 7.0, that would be great. > > > > Thanks. > > > > On Tue, Jan 19, 2016 at 2:52 AM, Frediano Ziglio > wrote: > > > >> 2016-01-16 1:41 GMT+00:00 Joshua Lang : > >> > In the latest version of FreeTDS-dblib (0.95.79) I'm passing rpc > VARCHAR > >> > parameters of 0 length, but non-NULL (empty strings). FreeTDS seems to > >> turn > >> > these into NULL values before passing them on to SQL Server. From what > >> I've > >> > read, it seems as if older databases didn't support passing empty > >> strings, > >> > but newer ones do? (i.e. TDS 7.0+ do support empty strings). > >> > > >> > It seems as this is a known issue, but I was wondering if it is > possible > >> to > >> > fix it for the newer versions of SQL server? E.g. in dbrpcparam() > >> passing a > >> > non-NULL pointer to the 'value' parameter and a 0 to 'datalen' would > >> > indicate an empty string is desired if possible. > >> > > >> > Thoughts? > >> > >> > >> The main problem is not libTDS (the code library) but dbrpcparam > >> specification. > >> datalen < 0 is invalid for variable fields (like VARCHAR) and 0 is used > >> for NULL > >> value (no matter the data pointer). But looks like your suggestion > >> (not NULL value > >> and 0 datalen) could be a good choice. > >> Not sure however if this could work with all types and server versions > >> (for instance > >> 0 size TEXT). > >> We can do it but I'm not thinking about backporting it to 0.95. > >> > >> Frediano > >> _______________________________________________ > >> FreeTDS mailing list > >> FreeTDS at lists.ibiblio.org > >> http://lists.ibiblio.org/mailman/listinfo/freetds > >> > > _______________________________________________ > > FreeTDS mailing list > > FreeTDS at lists.ibiblio.org > > http://lists.ibiblio.org/mailman/listinfo/freetds > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > From joshua.h.lang at gmail.com Wed Mar 16 15:23:48 2016 From: joshua.h.lang at gmail.com (Joshua Lang) Date: Wed, 16 Mar 2016 12:23:48 -0700 Subject: [freetds] infinite loop in dbcancel Message-ID: FreeTDS version: 0.95.79 OS: Debian 7.9 (wheezy) Here's the scenario: Application has a long-running (pooled) connection to a database. The database is restarted. The application then consumes as much of one CPU as it can. Unfortunately I have yet to find a simple repro for this issue locally, but here is what I've found debugging the live application: strace shows a constant stream of the following call: poll([{fd=150, events=POLLOUT}, {fd=98, events=POLLIN}], 2, 1000) = 1 ([{fd=150, revents=POLLOUT|POLLERR|POLLHUP}]) The (relevant) stack trace from gdb: (gdb) bt #0 0x00007f1fae4d16b3 in *__GI___poll (fds=, nfds=, timeout=1000) at ../sysdeps/unix/sysv/linux/poll.c:87 #1 0x00007f1fa50ff883 in tds_select () from /opt/zillow/services/mortgage-api-external/zpr/lib/libsybdb.so.5 #2 0x00007f1fa50ffe70 in tds_goodwrite () from /opt/zillow/services/mortgage-api-external/zpr/lib/libsybdb.so.5 #3 0x00007f1fa5100062 in tds_connection_write () from /opt/zillow/services/mortgage-api-external/zpr/lib/libsybdb.so.5 #4 0x00007f1fa51046f7 in tds_put_cancel () from /opt/zillow/services/mortgage-api-external/zpr/lib/libsybdb.so.5 #5 0x00007f1fa50f574b in tds_send_cancel () from /opt/zillow/services/mortgage-api-external/zpr/lib/libsybdb.so.5 #6 0x00007f1fa50c3560 in dbcancel () from /opt/zillow/services/mortgage-api-external/zpr/lib/libsybdb.so.5 I've stepped through this with gdb and here are the results: 1. tds_select is called, returning -1 (verified in gdb) 2. errno returns to 11 (EAGAIN) (verified in gdb, by stepping through the c-lib function call to return it) 3. TDSSOCK_WOULDBLOCK therefore causes the loop to repeat: https://github.com/FreeTDS/freetds/blob/master/src/tds/net.c#L803 and we're back to step 1 and an infinite loop The TDSSOCK_WOULDBLOCK seems strange to me, and the comment after it agrees. I wouldn't expect the socket read to block if the poll call just indicated it was ready for read. From freddy77 at gmail.com Thu Mar 17 15:55:10 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Thu, 17 Mar 2016 19:55:10 +0000 Subject: [freetds] infinite loop in dbcancel In-Reply-To: References: Message-ID: 2016-03-16 19:23 GMT+00:00 Joshua Lang : > FreeTDS version: 0.95.79 > OS: Debian 7.9 (wheezy) > > Here's the scenario: > > Application has a long-running (pooled) connection to a database. > The database is restarted. > The application then consumes as much of one CPU as it can. > > Unfortunately I have yet to find a simple repro for this issue locally, but > here is what I've found debugging the live application: > > strace shows a constant stream of the following call: > > poll([{fd=150, events=POLLOUT}, {fd=98, events=POLLIN}], 2, 1000) = 1 > ([{fd=150, revents=POLLOUT|POLLERR|POLLHUP}]) > > The (relevant) stack trace from gdb: > > (gdb) bt > #0 0x00007f1fae4d16b3 in *__GI___poll (fds=, > nfds=, timeout=1000) > at ../sysdeps/unix/sysv/linux/poll.c:87 > #1 0x00007f1fa50ff883 in tds_select () from > /opt/zillow/services/mortgage-api-external/zpr/lib/libsybdb.so.5 > #2 0x00007f1fa50ffe70 in tds_goodwrite () from > /opt/zillow/services/mortgage-api-external/zpr/lib/libsybdb.so.5 > #3 0x00007f1fa5100062 in tds_connection_write () from > /opt/zillow/services/mortgage-api-external/zpr/lib/libsybdb.so.5 > #4 0x00007f1fa51046f7 in tds_put_cancel () from > /opt/zillow/services/mortgage-api-external/zpr/lib/libsybdb.so.5 > #5 0x00007f1fa50f574b in tds_send_cancel () from > /opt/zillow/services/mortgage-api-external/zpr/lib/libsybdb.so.5 > #6 0x00007f1fa50c3560 in dbcancel () from > /opt/zillow/services/mortgage-api-external/zpr/lib/libsybdb.so.5 > > > I've stepped through this with gdb and here are the results: > 1. tds_select is called, returning -1 (verified in gdb) > 2. errno returns to 11 (EAGAIN) (verified in gdb, by stepping through the > c-lib function call to return it) > 3. TDSSOCK_WOULDBLOCK therefore causes the loop to repeat: > https://github.com/FreeTDS/freetds/blob/master/src/tds/net.c#L803 and we're > back to step 1 and an infinite loop > > The TDSSOCK_WOULDBLOCK seems strange to me, and the comment after it > agrees. I wouldn't expect the socket read to block if the poll call just > indicated it was ready for read. I think the problem is in tds_select. After poll returns 1 we check for error and return correctly -1 as failure however errno is not set so it's still the old value. I would try to set to something like EPIPE before returning -1. Frediano From joshua.h.lang at gmail.com Thu Mar 17 16:52:20 2016 From: joshua.h.lang at gmail.com (Joshua Lang) Date: Thu, 17 Mar 2016 13:52:20 -0700 Subject: [freetds] infinite loop in dbcancel In-Reply-To: References: Message-ID: That seems reasonable. Would you like a pull request? On Thu, Mar 17, 2016 at 12:55 PM, Frediano Ziglio wrote: > 2016-03-16 19:23 GMT+00:00 Joshua Lang : > > FreeTDS version: 0.95.79 > > OS: Debian 7.9 (wheezy) > > > > Here's the scenario: > > > > Application has a long-running (pooled) connection to a database. > > The database is restarted. > > The application then consumes as much of one CPU as it can. > > > > Unfortunately I have yet to find a simple repro for this issue locally, > but > > here is what I've found debugging the live application: > > > > strace shows a constant stream of the following call: > > > > poll([{fd=150, events=POLLOUT}, {fd=98, events=POLLIN}], 2, 1000) = 1 > > ([{fd=150, revents=POLLOUT|POLLERR|POLLHUP}]) > > > > The (relevant) stack trace from gdb: > > > > (gdb) bt > > #0 0x00007f1fae4d16b3 in *__GI___poll (fds=, > > nfds=, timeout=1000) > > at ../sysdeps/unix/sysv/linux/poll.c:87 > > #1 0x00007f1fa50ff883 in tds_select () from > > /opt/zillow/services/mortgage-api-external/zpr/lib/libsybdb.so.5 > > #2 0x00007f1fa50ffe70 in tds_goodwrite () from > > /opt/zillow/services/mortgage-api-external/zpr/lib/libsybdb.so.5 > > #3 0x00007f1fa5100062 in tds_connection_write () from > > /opt/zillow/services/mortgage-api-external/zpr/lib/libsybdb.so.5 > > #4 0x00007f1fa51046f7 in tds_put_cancel () from > > /opt/zillow/services/mortgage-api-external/zpr/lib/libsybdb.so.5 > > #5 0x00007f1fa50f574b in tds_send_cancel () from > > /opt/zillow/services/mortgage-api-external/zpr/lib/libsybdb.so.5 > > #6 0x00007f1fa50c3560 in dbcancel () from > > /opt/zillow/services/mortgage-api-external/zpr/lib/libsybdb.so.5 > > > > > > I've stepped through this with gdb and here are the results: > > 1. tds_select is called, returning -1 (verified in gdb) > > 2. errno returns to 11 (EAGAIN) (verified in gdb, by stepping through the > > c-lib function call to return it) > > 3. TDSSOCK_WOULDBLOCK therefore causes the loop to repeat: > > https://github.com/FreeTDS/freetds/blob/master/src/tds/net.c#L803 and > we're > > back to step 1 and an infinite loop > > > > The TDSSOCK_WOULDBLOCK seems strange to me, and the comment after it > > agrees. I wouldn't expect the socket read to block if the poll call just > > indicated it was ready for read. > > > I think the problem is in tds_select. After poll returns 1 we check > for error and return correctly -1 as failure however errno is not set > so it's still the old value. I would try to set to something like > EPIPE before returning -1. > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > From freddy77 at gmail.com Thu Mar 17 17:24:57 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Thu, 17 Mar 2016 21:24:57 +0000 Subject: [freetds] infinite loop in dbcancel In-Reply-To: References: Message-ID: On 17 Mar 2016 21:21, "Joshua Lang" wrote: > > That seems reasonable. Would you like a pull request? > You can. However I think on Windows you have to call a function to set the error and I don't know which constant would be better. On Windows these kind of error (socket ones) have no relation with c errno Frediano > On Thu, Mar 17, 2016 at 12:55 PM, Frediano Ziglio > wrote: > > > 2016-03-16 19:23 GMT+00:00 Joshua Lang : > > > FreeTDS version: 0.95.79 > > > OS: Debian 7.9 (wheezy) > > > > > > Here's the scenario: > > > > > > Application has a long-running (pooled) connection to a database. > > > The database is restarted. > > > The application then consumes as much of one CPU as it can. > > > > > > Unfortunately I have yet to find a simple repro for this issue locally, > > but > > > here is what I've found debugging the live application: > > > > > > strace shows a constant stream of the following call: > > > > > > poll([{fd=150, events=POLLOUT}, {fd=98, events=POLLIN}], 2, 1000) = 1 > > > ([{fd=150, revents=POLLOUT|POLLERR|POLLHUP}]) > > > > > > The (relevant) stack trace from gdb: > > > > > > (gdb) bt > > > #0 0x00007f1fae4d16b3 in *__GI___poll (fds=, > > > nfds=, timeout=1000) > > > at ../sysdeps/unix/sysv/linux/poll.c:87 > > > #1 0x00007f1fa50ff883 in tds_select () from > > > /opt/zillow/services/mortgage-api-external/zpr/lib/libsybdb.so.5 > > > #2 0x00007f1fa50ffe70 in tds_goodwrite () from > > > /opt/zillow/services/mortgage-api-external/zpr/lib/libsybdb.so.5 > > > #3 0x00007f1fa5100062 in tds_connection_write () from > > > /opt/zillow/services/mortgage-api-external/zpr/lib/libsybdb.so.5 > > > #4 0x00007f1fa51046f7 in tds_put_cancel () from > > > /opt/zillow/services/mortgage-api-external/zpr/lib/libsybdb.so.5 > > > #5 0x00007f1fa50f574b in tds_send_cancel () from > > > /opt/zillow/services/mortgage-api-external/zpr/lib/libsybdb.so.5 > > > #6 0x00007f1fa50c3560 in dbcancel () from > > > /opt/zillow/services/mortgage-api-external/zpr/lib/libsybdb.so.5 > > > > > > > > > I've stepped through this with gdb and here are the results: > > > 1. tds_select is called, returning -1 (verified in gdb) > > > 2. errno returns to 11 (EAGAIN) (verified in gdb, by stepping through the > > > c-lib function call to return it) > > > 3. TDSSOCK_WOULDBLOCK therefore causes the loop to repeat: > > > https://github.com/FreeTDS/freetds/blob/master/src/tds/net.c#L803 and > > we're > > > back to step 1 and an infinite loop > > > > > > The TDSSOCK_WOULDBLOCK seems strange to me, and the comment after it > > > agrees. I wouldn't expect the socket read to block if the poll call just > > > indicated it was ready for read. > > > > > > I think the problem is in tds_select. After poll returns 1 we check > > for error and return correctly -1 as failure however errno is not set > > so it's still the old value. I would try to set to something like > > EPIPE before returning -1. > > > > Frediano > > _______________________________________________ > > FreeTDS mailing list > > FreeTDS at lists.ibiblio.org > > http://lists.ibiblio.org/mailman/listinfo/freetds > > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From joshua.h.lang at gmail.com Thu Mar 17 17:28:56 2016 From: joshua.h.lang at gmail.com (Joshua Lang) Date: Thu, 17 Mar 2016 14:28:56 -0700 Subject: [freetds] infinite loop in dbcancel In-Reply-To: References: Message-ID: Ugh. Well I don't have a Windows host setup currently for testing... Also, it does seem strange that the code loops if the returned error is EWOULDBLOCK or EAGAIN. That should never happen in a read after the select (poll) has successfully returned the file descriptor is ready for reading. On Thu, Mar 17, 2016 at 2:24 PM, Frediano Ziglio wrote: > On 17 Mar 2016 21:21, "Joshua Lang" wrote: > > > > That seems reasonable. Would you like a pull request? > > > > You can. However I think on Windows you have to call a function to set the > error and I don't know which constant would be better. On Windows these > kind of error (socket ones) have no relation with c errno > > Frediano > > > On Thu, Mar 17, 2016 at 12:55 PM, Frediano Ziglio > > wrote: > > > > > 2016-03-16 19:23 GMT+00:00 Joshua Lang : > > > > FreeTDS version: 0.95.79 > > > > OS: Debian 7.9 (wheezy) > > > > > > > > Here's the scenario: > > > > > > > > Application has a long-running (pooled) connection to a database. > > > > The database is restarted. > > > > The application then consumes as much of one CPU as it can. > > > > > > > > Unfortunately I have yet to find a simple repro for this issue > locally, > > > but > > > > here is what I've found debugging the live application: > > > > > > > > strace shows a constant stream of the following call: > > > > > > > > poll([{fd=150, events=POLLOUT}, {fd=98, events=POLLIN}], 2, 1000) = 1 > > > > ([{fd=150, revents=POLLOUT|POLLERR|POLLHUP}]) > > > > > > > > The (relevant) stack trace from gdb: > > > > > > > > (gdb) bt > > > > #0 0x00007f1fae4d16b3 in *__GI___poll (fds=, > > > > nfds=, timeout=1000) > > > > at ../sysdeps/unix/sysv/linux/poll.c:87 > > > > #1 0x00007f1fa50ff883 in tds_select () from > > > > /opt/zillow/services/mortgage-api-external/zpr/lib/libsybdb.so.5 > > > > #2 0x00007f1fa50ffe70 in tds_goodwrite () from > > > > /opt/zillow/services/mortgage-api-external/zpr/lib/libsybdb.so.5 > > > > #3 0x00007f1fa5100062 in tds_connection_write () from > > > > /opt/zillow/services/mortgage-api-external/zpr/lib/libsybdb.so.5 > > > > #4 0x00007f1fa51046f7 in tds_put_cancel () from > > > > /opt/zillow/services/mortgage-api-external/zpr/lib/libsybdb.so.5 > > > > #5 0x00007f1fa50f574b in tds_send_cancel () from > > > > /opt/zillow/services/mortgage-api-external/zpr/lib/libsybdb.so.5 > > > > #6 0x00007f1fa50c3560 in dbcancel () from > > > > /opt/zillow/services/mortgage-api-external/zpr/lib/libsybdb.so.5 > > > > > > > > > > > > I've stepped through this with gdb and here are the results: > > > > 1. tds_select is called, returning -1 (verified in gdb) > > > > 2. errno returns to 11 (EAGAIN) (verified in gdb, by stepping through > the > > > > c-lib function call to return it) > > > > 3. TDSSOCK_WOULDBLOCK therefore causes the loop to repeat: > > > > https://github.com/FreeTDS/freetds/blob/master/src/tds/net.c#L803 > and > > > we're > > > > back to step 1 and an infinite loop > > > > > > > > The TDSSOCK_WOULDBLOCK seems strange to me, and the comment after it > > > > agrees. I wouldn't expect the socket read to block if the poll call > just > > > > indicated it was ready for read. > > > > > > > > > I think the problem is in tds_select. After poll returns 1 we check > > > for error and return correctly -1 as failure however errno is not set > > > so it's still the old value. I would try to set to something like > > > EPIPE before returning -1. > > > > > > Frediano > > > _______________________________________________ > > > FreeTDS mailing list > > > FreeTDS at lists.ibiblio.org > > > http://lists.ibiblio.org/mailman/listinfo/freetds > > > > > _______________________________________________ > > FreeTDS mailing list > > FreeTDS at lists.ibiblio.org > > http://lists.ibiblio.org/mailman/listinfo/freetds > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > From sfhacker at hotmail.com Thu Mar 17 18:41:06 2016 From: sfhacker at hotmail.com (Sergio NNX) Date: Fri, 18 Mar 2016 09:41:06 +1100 Subject: [freetds] infinite loop in dbcancel In-Reply-To: References: , , , Message-ID: > You can. However I think on Windows you have to call a function to set the > error and I don't know which constant would be better. On Windows these > kind of error (socket ones) have no relation with c errno I don't know whether or not it is a good practice, but you could set errno to the value of WSAGetLastError() and then use gai_strerror() or FormatMessage() or whatever you prefer. From freddy77 at gmail.com Fri Mar 18 02:44:18 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Fri, 18 Mar 2016 06:44:18 +0000 Subject: [freetds] infinite loop in dbcancel In-Reply-To: References: Message-ID: There are multiple reasons why read our other functions could return EAGAIN or similar. The issue here it that poll returns 1 so it does not set errno but tds_select returns - 1 as there is an error in the socket. If errno was already EAGAIN loop can happen. On 18 Mar 2016 06:38, "Joshua Lang" wrote: > Ugh. Well I don't have a Windows host setup currently for testing... > Also, it does seem strange that the code loops if the returned error is > EWOULDBLOCK or EAGAIN. That should never happen in a read after the select > (poll) has successfully returned the file descriptor is ready for reading. > > On Thu, Mar 17, 2016 at 2:24 PM, Frediano Ziglio > wrote: > > > On 17 Mar 2016 21:21, "Joshua Lang" wrote: > > > > > > That seems reasonable. Would you like a pull request? > > > > > > > You can. However I think on Windows you have to call a function to set > the > > error and I don't know which constant would be better. On Windows these > > kind of error (socket ones) have no relation with c errno > > > > Frediano > > > > > On Thu, Mar 17, 2016 at 12:55 PM, Frediano Ziglio > > > wrote: > > > > > > > 2016-03-16 19:23 GMT+00:00 Joshua Lang : > > > > > FreeTDS version: 0.95.79 > > > > > OS: Debian 7.9 (wheezy) > > > > > > > > > > Here's the scenario: > > > > > > > > > > Application has a long-running (pooled) connection to a database. > > > > > The database is restarted. > > > > > The application then consumes as much of one CPU as it can. > > > > > > > > > > Unfortunately I have yet to find a simple repro for this issue > > locally, > > > > but > > > > > here is what I've found debugging the live application: > > > > > > > > > > strace shows a constant stream of the following call: > > > > > > > > > > poll([{fd=150, events=POLLOUT}, {fd=98, events=POLLIN}], 2, 1000) > = 1 > > > > > ([{fd=150, revents=POLLOUT|POLLERR|POLLHUP}]) > > > > > > > > > > The (relevant) stack trace from gdb: > > > > > > > > > > (gdb) bt > > > > > #0 0x00007f1fae4d16b3 in *__GI___poll (fds=, > > > > > nfds=, timeout=1000) > > > > > at ../sysdeps/unix/sysv/linux/poll.c:87 > > > > > #1 0x00007f1fa50ff883 in tds_select () from > > > > > /opt/zillow/services/mortgage-api-external/zpr/lib/libsybdb.so.5 > > > > > #2 0x00007f1fa50ffe70 in tds_goodwrite () from > > > > > /opt/zillow/services/mortgage-api-external/zpr/lib/libsybdb.so.5 > > > > > #3 0x00007f1fa5100062 in tds_connection_write () from > > > > > /opt/zillow/services/mortgage-api-external/zpr/lib/libsybdb.so.5 > > > > > #4 0x00007f1fa51046f7 in tds_put_cancel () from > > > > > /opt/zillow/services/mortgage-api-external/zpr/lib/libsybdb.so.5 > > > > > #5 0x00007f1fa50f574b in tds_send_cancel () from > > > > > /opt/zillow/services/mortgage-api-external/zpr/lib/libsybdb.so.5 > > > > > #6 0x00007f1fa50c3560 in dbcancel () from > > > > > /opt/zillow/services/mortgage-api-external/zpr/lib/libsybdb.so.5 > > > > > > > > > > > > > > > I've stepped through this with gdb and here are the results: > > > > > 1. tds_select is called, returning -1 (verified in gdb) > > > > > 2. errno returns to 11 (EAGAIN) (verified in gdb, by stepping > through > > the > > > > > c-lib function call to return it) > > > > > 3. TDSSOCK_WOULDBLOCK therefore causes the loop to repeat: > > > > > https://github.com/FreeTDS/freetds/blob/master/src/tds/net.c#L803 > > and > > > > we're > > > > > back to step 1 and an infinite loop > > > > > > > > > > The TDSSOCK_WOULDBLOCK seems strange to me, and the comment after > it > > > > > agrees. I wouldn't expect the socket read to block if the poll call > > just > > > > > indicated it was ready for read. > > > > > > > > > > > > I think the problem is in tds_select. After poll returns 1 we check > > > > for error and return correctly -1 as failure however errno is not set > > > > so it's still the old value. I would try to set to something like > > > > EPIPE before returning -1. > > > > > > > > Frediano > > > > _______________________________________________ > > > > FreeTDS mailing list > > > > FreeTDS at lists.ibiblio.org > > > > http://lists.ibiblio.org/mailman/listinfo/freetds > > > > > > > _______________________________________________ > > > FreeTDS mailing list > > > FreeTDS at lists.ibiblio.org > > > http://lists.ibiblio.org/mailman/listinfo/freetds > > _______________________________________________ > > FreeTDS mailing list > > FreeTDS at lists.ibiblio.org > > http://lists.ibiblio.org/mailman/listinfo/freetds > > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > From freddy77 at gmail.com Fri Mar 18 02:54:10 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Fri, 18 Mar 2016 06:54:10 +0000 Subject: [freetds] Empty VARCHAR parameters converted to NULL In-Reply-To: References: Message-ID: The problem is distinguish between null and empty. By definition 0 is null and - 1 is not accepted. Another negative value could work and a program could detect of library is FreeTDS or not and use this value (FreeTDS) or 0 (ms or sybase). Libraries do not have same abi so a compile time check would be fine. Other libraries use 1 as length and fill the byte to a specific value (like space for varchar and 0 for binaries) On 17 Mar 2016 03:45, "Joshua Lang" wrote: > I assume you're referring to input/output parameters where the input value > is NULL, but the output value is non-NULL? > > The MSDN docs for rpcparam ( > https://msdn.microsoft.com/en-us/library/aa937102(v=sql.80).aspx) don't > really indicate how this case is handled, but > I think the following would work for the input/output parameter: > > maxlen = > datalen = 0 > > Basically maxlen is used for the length of the output parameter buffer and > datalen is the length of the input data. > > Thoughts? > > > On Tue, Mar 15, 2016 at 4:37 PM, Frediano Ziglio > wrote: > > > I was looking at this issue. The problem raise when you want a return > > value but you want to pass a empty or a NULL varchar. How to > > differentiate in this case? value cannot be NULL for return > > parameters. > > > > Frediano > > > > > > 2016-01-19 18:25 GMT+00:00 Joshua Lang : > > > I've read that older versions didn't even support passing 0-length data > > > (prior to TDS 7.0 I believe). If this could be supported for later > > versions > > > of TDS 7.0, that would be great. > > > > > > Thanks. > > > > > > On Tue, Jan 19, 2016 at 2:52 AM, Frediano Ziglio > > wrote: > > > > > >> 2016-01-16 1:41 GMT+00:00 Joshua Lang : > > >> > In the latest version of FreeTDS-dblib (0.95.79) I'm passing rpc > > VARCHAR > > >> > parameters of 0 length, but non-NULL (empty strings). FreeTDS seems > to > > >> turn > > >> > these into NULL values before passing them on to SQL Server. From > what > > >> I've > > >> > read, it seems as if older databases didn't support passing empty > > >> strings, > > >> > but newer ones do? (i.e. TDS 7.0+ do support empty strings). > > >> > > > >> > It seems as this is a known issue, but I was wondering if it is > > possible > > >> to > > >> > fix it for the newer versions of SQL server? E.g. in dbrpcparam() > > >> passing a > > >> > non-NULL pointer to the 'value' parameter and a 0 to 'datalen' would > > >> > indicate an empty string is desired if possible. > > >> > > > >> > Thoughts? > > >> > > >> > > >> The main problem is not libTDS (the code library) but dbrpcparam > > >> specification. > > >> datalen < 0 is invalid for variable fields (like VARCHAR) and 0 is > used > > >> for NULL > > >> value (no matter the data pointer). But looks like your suggestion > > >> (not NULL value > > >> and 0 datalen) could be a good choice. > > >> Not sure however if this could work with all types and server versions > > >> (for instance > > >> 0 size TEXT). > > >> We can do it but I'm not thinking about backporting it to 0.95. > > >> > > >> Frediano > > >> _______________________________________________ > > >> FreeTDS mailing list > > >> FreeTDS at lists.ibiblio.org > > >> http://lists.ibiblio.org/mailman/listinfo/freetds > > >> > > > _______________________________________________ > > > FreeTDS mailing list > > > FreeTDS at lists.ibiblio.org > > > http://lists.ibiblio.org/mailman/listinfo/freetds > > _______________________________________________ > > FreeTDS mailing list > > FreeTDS at lists.ibiblio.org > > http://lists.ibiblio.org/mailman/listinfo/freetds > > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > From joshua.h.lang at gmail.com Fri Mar 18 19:43:47 2016 From: joshua.h.lang at gmail.com (Joshua Lang) Date: Fri, 18 Mar 2016 16:43:47 -0700 Subject: [freetds] Empty VARCHAR parameters converted to NULL In-Reply-To: References: Message-ID: I went back and re-read the entire thread and I see the problem you are referring to with the desire of the input parameter to be NULL, but still support an output parameter. I don't see a good way for the DB-lib API to support this directly. Even still, the ability to pass NULL pointers for input only parameters would be nice. One could add a new method (e.g. dbrpcparam2), which had distinct inputs for both input and output parameters instead of using the same pointer 'value' for both input data and output buffer. On Thu, Mar 17, 2016 at 11:54 PM, Frediano Ziglio wrote: > The problem is distinguish between null and empty. By definition 0 is null > and - 1 is not accepted. Another negative value could work and a program > could detect of library is FreeTDS or not and use this value (FreeTDS) or 0 > (ms or sybase). Libraries do not have same abi so a compile time check > would be fine. Other libraries use 1 as length and fill the byte to a > specific value (like space for varchar and 0 for binaries) > On 17 Mar 2016 03:45, "Joshua Lang" wrote: > > > I assume you're referring to input/output parameters where the input > value > > is NULL, but the output value is non-NULL? > > > > The MSDN docs for rpcparam ( > > https://msdn.microsoft.com/en-us/library/aa937102(v=sql.80).aspx) don't > > really indicate how this case is handled, but > > I think the following would work for the input/output parameter: > > > > maxlen = > > datalen = 0 > > > > Basically maxlen is used for the length of the output parameter buffer > and > > datalen is the length of the input data. > > > > Thoughts? > > > > > > On Tue, Mar 15, 2016 at 4:37 PM, Frediano Ziglio > > wrote: > > > > > I was looking at this issue. The problem raise when you want a return > > > value but you want to pass a empty or a NULL varchar. How to > > > differentiate in this case? value cannot be NULL for return > > > parameters. > > > > > > Frediano > > > > > > > > > 2016-01-19 18:25 GMT+00:00 Joshua Lang : > > > > I've read that older versions didn't even support passing 0-length > data > > > > (prior to TDS 7.0 I believe). If this could be supported for later > > > versions > > > > of TDS 7.0, that would be great. > > > > > > > > Thanks. > > > > > > > > On Tue, Jan 19, 2016 at 2:52 AM, Frediano Ziglio > > > > wrote: > > > > > > > >> 2016-01-16 1:41 GMT+00:00 Joshua Lang : > > > >> > In the latest version of FreeTDS-dblib (0.95.79) I'm passing rpc > > > VARCHAR > > > >> > parameters of 0 length, but non-NULL (empty strings). FreeTDS > seems > > to > > > >> turn > > > >> > these into NULL values before passing them on to SQL Server. From > > what > > > >> I've > > > >> > read, it seems as if older databases didn't support passing empty > > > >> strings, > > > >> > but newer ones do? (i.e. TDS 7.0+ do support empty strings). > > > >> > > > > >> > It seems as this is a known issue, but I was wondering if it is > > > possible > > > >> to > > > >> > fix it for the newer versions of SQL server? E.g. in dbrpcparam() > > > >> passing a > > > >> > non-NULL pointer to the 'value' parameter and a 0 to 'datalen' > would > > > >> > indicate an empty string is desired if possible. > > > >> > > > > >> > Thoughts? > > > >> > > > >> > > > >> The main problem is not libTDS (the code library) but dbrpcparam > > > >> specification. > > > >> datalen < 0 is invalid for variable fields (like VARCHAR) and 0 is > > used > > > >> for NULL > > > >> value (no matter the data pointer). But looks like your suggestion > > > >> (not NULL value > > > >> and 0 datalen) could be a good choice. > > > >> Not sure however if this could work with all types and server > versions > > > >> (for instance > > > >> 0 size TEXT). > > > >> We can do it but I'm not thinking about backporting it to 0.95. > > > >> > > > >> Frediano > > > >> _______________________________________________ > > > >> FreeTDS mailing list > > > >> FreeTDS at lists.ibiblio.org > > > >> http://lists.ibiblio.org/mailman/listinfo/freetds > > > >> > > > > _______________________________________________ > > > > FreeTDS mailing list > > > > FreeTDS at lists.ibiblio.org > > > > http://lists.ibiblio.org/mailman/listinfo/freetds > > > _______________________________________________ > > > FreeTDS mailing list > > > FreeTDS at lists.ibiblio.org > > > http://lists.ibiblio.org/mailman/listinfo/freetds > > > > > _______________________________________________ > > FreeTDS mailing list > > FreeTDS at lists.ibiblio.org > > http://lists.ibiblio.org/mailman/listinfo/freetds > > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > From freddy77 at gmail.com Sun Mar 20 07:22:46 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Sun, 20 Mar 2016 11:22:46 +0000 Subject: [freetds] infinite loop in dbcancel In-Reply-To: References: Message-ID: Fixed (master and 0.95)! Expect usually snapshots tomorrow. Frediano 2016-03-17 21:28 GMT+00:00 Joshua Lang : > Ugh. Well I don't have a Windows host setup currently for testing... > Also, it does seem strange that the code loops if the returned error is > EWOULDBLOCK or EAGAIN. That should never happen in a read after the select > (poll) has successfully returned the file descriptor is ready for reading. > > On Thu, Mar 17, 2016 at 2:24 PM, Frediano Ziglio wrote: > >> On 17 Mar 2016 21:21, "Joshua Lang" wrote: >> > >> > That seems reasonable. Would you like a pull request? >> > >> >> You can. However I think on Windows you have to call a function to set the >> error and I don't know which constant would be better. On Windows these >> kind of error (socket ones) have no relation with c errno >> >> Frediano >> >> > On Thu, Mar 17, 2016 at 12:55 PM, Frediano Ziglio >> > wrote: >> > >> > > 2016-03-16 19:23 GMT+00:00 Joshua Lang : >> > > > FreeTDS version: 0.95.79 >> > > > OS: Debian 7.9 (wheezy) >> > > > >> > > > Here's the scenario: >> > > > >> > > > Application has a long-running (pooled) connection to a database. >> > > > The database is restarted. >> > > > The application then consumes as much of one CPU as it can. >> > > > >> > > > Unfortunately I have yet to find a simple repro for this issue >> locally, >> > > but >> > > > here is what I've found debugging the live application: >> > > > >> > > > strace shows a constant stream of the following call: >> > > > >> > > > poll([{fd=150, events=POLLOUT}, {fd=98, events=POLLIN}], 2, 1000) = 1 >> > > > ([{fd=150, revents=POLLOUT|POLLERR|POLLHUP}]) >> > > > >> > > > The (relevant) stack trace from gdb: >> > > > >> > > > (gdb) bt >> > > > #0 0x00007f1fae4d16b3 in *__GI___poll (fds=, >> > > > nfds=, timeout=1000) >> > > > at ../sysdeps/unix/sysv/linux/poll.c:87 >> > > > #1 0x00007f1fa50ff883 in tds_select () from >> > > > /opt/zillow/services/mortgage-api-external/zpr/lib/libsybdb.so.5 >> > > > #2 0x00007f1fa50ffe70 in tds_goodwrite () from >> > > > /opt/zillow/services/mortgage-api-external/zpr/lib/libsybdb.so.5 >> > > > #3 0x00007f1fa5100062 in tds_connection_write () from >> > > > /opt/zillow/services/mortgage-api-external/zpr/lib/libsybdb.so.5 >> > > > #4 0x00007f1fa51046f7 in tds_put_cancel () from >> > > > /opt/zillow/services/mortgage-api-external/zpr/lib/libsybdb.so.5 >> > > > #5 0x00007f1fa50f574b in tds_send_cancel () from >> > > > /opt/zillow/services/mortgage-api-external/zpr/lib/libsybdb.so.5 >> > > > #6 0x00007f1fa50c3560 in dbcancel () from >> > > > /opt/zillow/services/mortgage-api-external/zpr/lib/libsybdb.so.5 >> > > > >> > > > >> > > > I've stepped through this with gdb and here are the results: >> > > > 1. tds_select is called, returning -1 (verified in gdb) >> > > > 2. errno returns to 11 (EAGAIN) (verified in gdb, by stepping through >> the >> > > > c-lib function call to return it) >> > > > 3. TDSSOCK_WOULDBLOCK therefore causes the loop to repeat: >> > > > https://github.com/FreeTDS/freetds/blob/master/src/tds/net.c#L803 >> and >> > > we're >> > > > back to step 1 and an infinite loop >> > > > >> > > > The TDSSOCK_WOULDBLOCK seems strange to me, and the comment after it >> > > > agrees. I wouldn't expect the socket read to block if the poll call >> just >> > > > indicated it was ready for read. >> > > >> > > >> > > I think the problem is in tds_select. After poll returns 1 we check >> > > for error and return correctly -1 as failure however errno is not set >> > > so it's still the old value. I would try to set to something like >> > > EPIPE before returning -1. >> > > >> > > Frediano >> > > _______________________________________________ >> > > FreeTDS mailing list >> > > FreeTDS at lists.ibiblio.org >> > > http://lists.ibiblio.org/mailman/listinfo/freetds >> > > >> > _______________________________________________ >> > FreeTDS mailing list >> > FreeTDS at lists.ibiblio.org >> > http://lists.ibiblio.org/mailman/listinfo/freetds >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> http://lists.ibiblio.org/mailman/listinfo/freetds >> > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From joshua.h.lang at gmail.com Sun Mar 20 12:06:43 2016 From: joshua.h.lang at gmail.com (Joshua Lang) Date: Sun, 20 Mar 2016 09:06:43 -0700 Subject: [freetds] infinite loop in dbcancel In-Reply-To: References: Message-ID: <9B68D6DC-20E4-4966-8305-579FCD898A98@gmail.com> Excellent. Thanks for the quick turnaround! > On Mar 20, 2016, at 4:22 AM, Frediano Ziglio wrote: > > Fixed (master and 0.95)! > > Expect usually snapshots tomorrow. > > Frediano > > > 2016-03-17 21:28 GMT+00:00 Joshua Lang : >> Ugh. Well I don't have a Windows host setup currently for testing... >> Also, it does seem strange that the code loops if the returned error is >> EWOULDBLOCK or EAGAIN. That should never happen in a read after the select >> (poll) has successfully returned the file descriptor is ready for reading. >> >>> On Thu, Mar 17, 2016 at 2:24 PM, Frediano Ziglio wrote: >>> >>>> On 17 Mar 2016 21:21, "Joshua Lang" wrote: >>>> >>>> That seems reasonable. Would you like a pull request? >>> >>> You can. However I think on Windows you have to call a function to set the >>> error and I don't know which constant would be better. On Windows these >>> kind of error (socket ones) have no relation with c errno >>> >>> Frediano >>> >>>> On Thu, Mar 17, 2016 at 12:55 PM, Frediano Ziglio >>>> wrote: >>>> >>>>> 2016-03-16 19:23 GMT+00:00 Joshua Lang : >>>>>> FreeTDS version: 0.95.79 >>>>>> OS: Debian 7.9 (wheezy) >>>>>> >>>>>> Here's the scenario: >>>>>> >>>>>> Application has a long-running (pooled) connection to a database. >>>>>> The database is restarted. >>>>>> The application then consumes as much of one CPU as it can. >>>>>> >>>>>> Unfortunately I have yet to find a simple repro for this issue >>> locally, >>>>> but >>>>>> here is what I've found debugging the live application: >>>>>> >>>>>> strace shows a constant stream of the following call: >>>>>> >>>>>> poll([{fd=150, events=POLLOUT}, {fd=98, events=POLLIN}], 2, 1000) = 1 >>>>>> ([{fd=150, revents=POLLOUT|POLLERR|POLLHUP}]) >>>>>> >>>>>> The (relevant) stack trace from gdb: >>>>>> >>>>>> (gdb) bt >>>>>> #0 0x00007f1fae4d16b3 in *__GI___poll (fds=, >>>>>> nfds=, timeout=1000) >>>>>> at ../sysdeps/unix/sysv/linux/poll.c:87 >>>>>> #1 0x00007f1fa50ff883 in tds_select () from >>>>>> /opt/zillow/services/mortgage-api-external/zpr/lib/libsybdb.so.5 >>>>>> #2 0x00007f1fa50ffe70 in tds_goodwrite () from >>>>>> /opt/zillow/services/mortgage-api-external/zpr/lib/libsybdb.so.5 >>>>>> #3 0x00007f1fa5100062 in tds_connection_write () from >>>>>> /opt/zillow/services/mortgage-api-external/zpr/lib/libsybdb.so.5 >>>>>> #4 0x00007f1fa51046f7 in tds_put_cancel () from >>>>>> /opt/zillow/services/mortgage-api-external/zpr/lib/libsybdb.so.5 >>>>>> #5 0x00007f1fa50f574b in tds_send_cancel () from >>>>>> /opt/zillow/services/mortgage-api-external/zpr/lib/libsybdb.so.5 >>>>>> #6 0x00007f1fa50c3560 in dbcancel () from >>>>>> /opt/zillow/services/mortgage-api-external/zpr/lib/libsybdb.so.5 >>>>>> >>>>>> >>>>>> I've stepped through this with gdb and here are the results: >>>>>> 1. tds_select is called, returning -1 (verified in gdb) >>>>>> 2. errno returns to 11 (EAGAIN) (verified in gdb, by stepping through >>> the >>>>>> c-lib function call to return it) >>>>>> 3. TDSSOCK_WOULDBLOCK therefore causes the loop to repeat: >>>>>> https://github.com/FreeTDS/freetds/blob/master/src/tds/net.c#L803 >>> and >>>>> we're >>>>>> back to step 1 and an infinite loop >>>>>> >>>>>> The TDSSOCK_WOULDBLOCK seems strange to me, and the comment after it >>>>>> agrees. I wouldn't expect the socket read to block if the poll call >>> just >>>>>> indicated it was ready for read. >>>>> >>>>> >>>>> I think the problem is in tds_select. After poll returns 1 we check >>>>> for error and return correctly -1 as failure however errno is not set >>>>> so it's still the old value. I would try to set to something like >>>>> EPIPE before returning -1. >>>>> >>>>> Frediano >>>>> _______________________________________________ >>>>> FreeTDS mailing list >>>>> FreeTDS at lists.ibiblio.org >>>>> http://lists.ibiblio.org/mailman/listinfo/freetds >>>> _______________________________________________ >>>> FreeTDS mailing list >>>> FreeTDS at lists.ibiblio.org >>>> http://lists.ibiblio.org/mailman/listinfo/freetds >>> _______________________________________________ >>> FreeTDS mailing list >>> FreeTDS at lists.ibiblio.org >>> http://lists.ibiblio.org/mailman/listinfo/freetds >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> http://lists.ibiblio.org/mailman/listinfo/freetds > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From mjetzer.cdc at gmail.com Thu Mar 24 17:02:49 2016 From: mjetzer.cdc at gmail.com (Mike Jetzer) Date: Thu, 24 Mar 2016 16:02:49 -0500 Subject: [freetds] Data alignment issue on freetds-0.95.8x under HP-UX B.11.31 causes core dump Message-ID: I had this issue when I first put up freetds-0.95.80 a couple of months ago, and the problem persists in 0.95.88. Compiled under HP-UX B.11.31 using the "cc: HP C/aC++ B3910B A.06.20 [May 13 2008]" compiler in 32-bit mode. I initially compiled with "-O", but the problem persists when compiling with "-g". Relevant freetds.conf info; this refers to an SQL Server database: [testconn] host = mkenday port = 1433 client charset = UTF-8 tds version = 7.3 Here's the table I'm using in my feasibility study: create table item ( itm_num nvarchar(40) not null default '', itm_desc nvarchar(33) not null default '', shelf_life integer not null default 0, itm_wid decimal (9,2) not null default 0.0, last_cc_dt_tm datetime2(3) not null default '1980-01-01 00:00:00' ) And the one row of data I'm using: insert into item ( itm_num, shelf_life, itm_wid, last_cc_dt_tm ) values ( 'ITM_NUM 12345', 1, 2.3, '2016-01-02 03:04:05') FreeTDS cores when attempting to do a "select * from item", either using tsql or the isql from unixODBC-2.3.4. If I select only certain fields, it may succeed, but if I "select *" or the wrong combination of fields, it dumps core (the problem appears to be with the datetime2 field). Running the tsql from 0.95.88 in gdb: $ gdb -q tsql (gdb) run -S testconn -U osb3prog1 -P osb3prog1 Starting program: /u1/sqlprog/freetds-0.95.88/src/apps/tsql -S testconn -U osb3prog1 -P osb3prog1 locale is "en_US.utf8 en_US.utf8 en_US.utf8 en_US.utf8 C en_US.utf8" locale charset is "utf8" using default charset "UTF-8" [New process 2721] warning: reading register 584: No such process Detaching after fork from process 2721 1> select * from item 2> go itm_num itm_desc shelf_life itm_wid last_cc_dt_tm Program received signal SIGBUS, Bus error si_code: 1 - BUS_ADRALN - Invalid address alignment. Please refer to the following link that helps in handling unaligned data: http://docs.hp.com/en/7730/newhelp0610/pragmas.htm#pragma-pack-ex3. 0x4096760:1 in tds_msdatetime_get (tds=0x4002b440, col=0x4005d890) at data.c:1110 1110 dt->time = u8; (gdb) p dt $1 = (struct {...} *) 0x40060ffc (gdb) p *dt $2 = {time = 0, date = 0, offset = 0, time_prec = 3, _res = 0, has_time = 0, has_date = 0, has_offset = 0} (gdb) p &dt->time $3 = (unsigned long long *) 0x40060ffc (gdb) where #0 0x4096760:1 in tds_msdatetime_get (tds=0x4002b440, col=0x4005d890) at data.c:1110 #1 0x403c830:0 in tds_process_row (tds=0x4002b440) at token.c:1954 #2 0x403fd00:0 in tds_process_tokens (tds=0x4002b440, result_type=0x7fff7cb0, done_flags=0x0, flag=5384) at token.c:685 #3 0x4026c60:0 in do_query (tds=0x4002b440, buf=0x4005a1d0 "select * from item\n", opt_flags=0) at tsql.c:233 #4 0x402c1d0:0 in main (argc=7, argv=0x7fff8380) at tsql.c:872 The URL to which gdb refers is no longer valid and HP doesn't have a redirect for it, but refers to pragmas for aligning structures. However, dt is a pointer into the column_data field of a variable of type TDSCOLUMN, which is just an "unsigned char *", so from my cursory reading of the pragmas, this wouldn't help. Additionally, there's a possibility that I'll also need FreeTDS under Solaris, AIX, and Linux; as FreeTDS is OpenSource I assume it'll work under Linux but am worried that the same issue might crop up under Solaris and AIX. From freddy77 at gmail.com Fri Mar 25 10:16:25 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Fri, 25 Mar 2016 14:16:25 +0000 Subject: [freetds] Data alignment issue on freetds-0.95.8x under HP-UX B.11.31 causes core dump In-Reply-To: References: Message-ID: 2016-03-24 21:02 GMT+00:00 Mike Jetzer : > I had this issue when I first put up freetds-0.95.80 a couple of months > ago, and the problem persists in 0.95.88. > > Compiled under HP-UX B.11.31 using the "cc: HP C/aC++ B3910B A.06.20 [May > 13 2008]" compiler in 32-bit mode. I initially compiled with "-O", but the > problem persists when compiling with "-g". > > Relevant freetds.conf info; this refers to an SQL Server database: > [testconn] > host = mkenday > port = 1433 > client charset = UTF-8 > tds version = 7.3 > > Here's the table I'm using in my feasibility study: > create table item > ( > itm_num nvarchar(40) not null default '', > itm_desc nvarchar(33) not null default '', > shelf_life integer not null default 0, > itm_wid decimal (9,2) not null default 0.0, > last_cc_dt_tm datetime2(3) not null default '1980-01-01 00:00:00' > ) > > And the one row of data I'm using: > insert into item ( itm_num, shelf_life, itm_wid, last_cc_dt_tm ) > values ( 'ITM_NUM 12345', 1, 2.3, '2016-01-02 03:04:05') > > FreeTDS cores when attempting to do a "select * from item", either using > tsql or the isql from unixODBC-2.3.4. If I select only certain fields, it > may succeed, but if I "select *" or the wrong combination of fields, it > dumps core (the problem appears to be with the datetime2 field). > > Running the tsql from 0.95.88 in gdb: > $ gdb -q tsql > (gdb) run -S testconn -U osb3prog1 -P osb3prog1 > Starting program: /u1/sqlprog/freetds-0.95.88/src/apps/tsql -S > testconn -U osb3prog1 -P osb3prog1 > locale is "en_US.utf8 en_US.utf8 en_US.utf8 en_US.utf8 C en_US.utf8" > locale charset is "utf8" > using default charset "UTF-8" > [New process 2721] > warning: reading register 584: No such process > Detaching after fork from process 2721 > 1> select * from item > 2> go > itm_num itm_desc shelf_life itm_wid last_cc_dt_tm > > Program received signal SIGBUS, Bus error > si_code: 1 - BUS_ADRALN - Invalid address alignment. Please refer > to the following link that helps in handling unaligned data: > http://docs.hp.com/en/7730/newhelp0610/pragmas.htm#pragma-pack-ex3. > 0x4096760:1 in tds_msdatetime_get (tds=0x4002b440, col=0x4005d890) > at data.c:1110 > 1110 dt->time = u8; > (gdb) p dt > $1 = (struct {...} *) 0x40060ffc > (gdb) p *dt > $2 = {time = 0, date = 0, offset = 0, time_prec = 3, _res = 0, > has_time = 0, > has_date = 0, has_offset = 0} > (gdb) p &dt->time > $3 = (unsigned long long *) 0x40060ffc > (gdb) where > #0 0x4096760:1 in tds_msdatetime_get (tds=0x4002b440, > col=0x4005d890) > at data.c:1110 > #1 0x403c830:0 in tds_process_row (tds=0x4002b440) at token.c:1954 > #2 0x403fd00:0 in tds_process_tokens (tds=0x4002b440, > result_type=0x7fff7cb0, > done_flags=0x0, flag=5384) at token.c:685 > #3 0x4026c60:0 in do_query (tds=0x4002b440, > buf=0x4005a1d0 "select * from item\n", opt_flags=0) at > tsql.c:233 > #4 0x402c1d0:0 in main (argc=7, argv=0x7fff8380) at tsql.c:872 > > The URL to which gdb refers is no longer valid and HP doesn't have a > redirect for it, but refers to pragmas for aligning structures. However, > dt is a pointer into the column_data field of a variable of type TDSCOLUMN, > which is just an "unsigned char *", so from my cursory reading of the > pragmas, this wouldn't help. Additionally, there's a possibility that I'll > also need FreeTDS under Solaris, AIX, and Linux; as FreeTDS is OpenSource I > assume it'll work under Linux but am worried that the same issue might crop > up under Solaris and AIX. This came quite surprisingly. Probably 64 bit and Intel machines do not help to detect these issues. Fixed in git (both master and 0.95), expect a new snapshot tomorrow. Frediano From Oswin.Dsa at mindtree.com Mon Mar 28 02:07:57 2016 From: Oswin.Dsa at mindtree.com (Oswin Dsa) Date: Mon, 28 Mar 2016 06:07:57 +0000 Subject: [freetds] Issue with Connecting to MS SQL Message-ID: Hello, I'm trying to connect to Microsoft SQL Server from my Mac application using iODBC and FreeTDS. No matter what I do, I get the error message "Unable to connect to data source" from the FreeTDS driver. I have consulted as many possible manuals, blog posts, and StackOverflow questions. Following is the troubleshooting steps I tried and more details about my code, DB Connection string = Driver=/Applications/xxx.app/Contents/Frameworks/libtdsodbc.so;Server=ip;DATABASE=DB;TDS_Version=8.0;Port=1433;ClientCharset=UTF-8;uid=username;pwd=*****;Trusted_Connection=No; >From application logs, SQLGetDiagRec function returns [01000] [FreeTDS][SQL Server]Adaptive Server connection failed (20002) [08001] [FreeTDS][SQL Server]Unable to connect to data source (0) Few StackOverflow post's suggested this is due to TDS version and changing to 8.0 would help but it's already set. When I ping the server - no packets are lost. Connection is established when I telnet the server on 1433 port. Using the below I am able to establish connection too, tsql -H >IP< -p 1433 -U username -P password Few searches online I found that if SERVER attribute is used in connection string then freetds.config and odbc.ini are ignored. So I guess the config file parameters don't help much. Also to add a point this works for most of the environment expect a few, is there any way to find why those few are not able to connect ? Could anyone please provide me with some pointers or any help so I can proceed further. Regards, Oswin ________________________________ http://www.mindtree.com/email/disclaimer.html From mjetzer.cdc at gmail.com Mon Mar 28 11:17:48 2016 From: mjetzer.cdc at gmail.com (Mike Jetzer) Date: Mon, 28 Mar 2016 10:17:48 -0500 Subject: [freetds] Data alignment issue on freetds-0.95.8x under HP-UX B.11.31 causes core dump In-Reply-To: References: Message-ID: Yes, thank you. I no longer get that core dump in freetds-0.95.89. On Fri, Mar 25, 2016 at 9:16 AM, Frediano Ziglio wrote: > 2016-03-24 21:02 GMT+00:00 Mike Jetzer : > > I had this issue when I first put up freetds-0.95.80 a couple of months > > ago, and the problem persists in 0.95.88. > > > > Compiled under HP-UX B.11.31 using the "cc: HP C/aC++ B3910B A.06.20 [May > > 13 2008]" compiler in 32-bit mode. I initially compiled with "-O", but > the > > problem persists when compiling with "-g". > > > > Relevant freetds.conf info; this refers to an SQL Server database: > > [testconn] > > host = mkenday > > port = 1433 > > client charset = UTF-8 > > tds version = 7.3 > > > > Here's the table I'm using in my feasibility study: > > create table item > > ( > > itm_num nvarchar(40) not null default '', > > itm_desc nvarchar(33) not null default '', > > shelf_life integer not null default 0, > > itm_wid decimal (9,2) not null default 0.0, > > last_cc_dt_tm datetime2(3) not null default '1980-01-01 > 00:00:00' > > ) > > > > And the one row of data I'm using: > > insert into item ( itm_num, shelf_life, itm_wid, last_cc_dt_tm ) > > values ( 'ITM_NUM 12345', 1, 2.3, '2016-01-02 03:04:05') > > > > FreeTDS cores when attempting to do a "select * from item", either using > > tsql or the isql from unixODBC-2.3.4. If I select only certain fields, > it > > may succeed, but if I "select *" or the wrong combination of fields, it > > dumps core (the problem appears to be with the datetime2 field). > > > > Running the tsql from 0.95.88 in gdb: > > $ gdb -q tsql > > (gdb) run -S testconn -U osb3prog1 -P osb3prog1 > > Starting program: /u1/sqlprog/freetds-0.95.88/src/apps/tsql -S > > testconn -U osb3prog1 -P osb3prog1 > > locale is "en_US.utf8 en_US.utf8 en_US.utf8 en_US.utf8 C > en_US.utf8" > > locale charset is "utf8" > > using default charset "UTF-8" > > [New process 2721] > > warning: reading register 584: No such process > > Detaching after fork from process 2721 > > 1> select * from item > > 2> go > > itm_num itm_desc shelf_life itm_wid last_cc_dt_tm > > > > Program received signal SIGBUS, Bus error > > si_code: 1 - BUS_ADRALN - Invalid address alignment. Please > refer > > to the following link that helps in handling unaligned data: > > http://docs.hp.com/en/7730/newhelp0610/pragmas.htm#pragma-pack-ex3. > > 0x4096760:1 in tds_msdatetime_get (tds=0x4002b440, > col=0x4005d890) > > at data.c:1110 > > 1110 dt->time = u8; > > (gdb) p dt > > $1 = (struct {...} *) 0x40060ffc > > (gdb) p *dt > > $2 = {time = 0, date = 0, offset = 0, time_prec = 3, _res = 0, > > has_time = 0, > > has_date = 0, has_offset = 0} > > (gdb) p &dt->time > > $3 = (unsigned long long *) 0x40060ffc > > (gdb) where > > #0 0x4096760:1 in tds_msdatetime_get (tds=0x4002b440, > > col=0x4005d890) > > at data.c:1110 > > #1 0x403c830:0 in tds_process_row (tds=0x4002b440) at > token.c:1954 > > #2 0x403fd00:0 in tds_process_tokens (tds=0x4002b440, > > result_type=0x7fff7cb0, > > done_flags=0x0, flag=5384) at token.c:685 > > #3 0x4026c60:0 in do_query (tds=0x4002b440, > > buf=0x4005a1d0 "select * from item\n", opt_flags=0) at > > tsql.c:233 > > #4 0x402c1d0:0 in main (argc=7, argv=0x7fff8380) at tsql.c:872 > > > > The URL to which gdb refers is no longer valid and HP doesn't have a > > redirect for it, but refers to pragmas for aligning structures. However, > > dt is a pointer into the column_data field of a variable of type > TDSCOLUMN, > > which is just an "unsigned char *", so from my cursory reading of the > > pragmas, this wouldn't help. Additionally, there's a possibility that > I'll > > also need FreeTDS under Solaris, AIX, and Linux; as FreeTDS is > OpenSource I > > assume it'll work under Linux but am worried that the same issue might > crop > > up under Solaris and AIX. > > This came quite surprisingly. Probably 64 bit and Intel machines do > not help to detect these issues. > Fixed in git (both master and 0.95), expect a new snapshot tomorrow. > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > From mjetzer.cdc at gmail.com Mon Mar 28 11:39:42 2016 From: mjetzer.cdc at gmail.com (Mike Jetzer) Date: Mon, 28 Mar 2016 10:39:42 -0500 Subject: [freetds] Compilation issues when compiling under HP-UX B.11.31. Message-ID: Two compilation issues with freetds-0.95.89 (as well as .88 and .80) when compiling under HP-UX B.11.31 with the "HP C/aC++ B3910B A.06.20 [May 13 2008]" compiler in 32-bit mode. Both have simple work-arounds which are fine for my requirements, but I thought I'd report them to be addressed when time permits. src/tds/token.c generates a 'warning #2513-D: a value of type "int" cannot be assigned to an entity of type "char *" because has not been #included: nbcbuf = alloca((info->num_cols + 7) / 8); ^ Simply adding an "#include " to token.c solves the issue. I did not include a patch file because I imagine that this would most properly be resolved via configure/config.h rather than unconditionally adding it to token.c. (In the version of Linux I use, performs an #include of with the default compiler defines, so a prototype is present and gcc produces no similar warning.) The second issue is with src/dblib/dbpivot.c, which generates a large number of 'error #2136: struct "col_t" has no field "XX" errors due to the anonymous union in struct col_t's definition. A Google search implies that anonymous unions were once a gcc extension but were adopted in C11; the HP-UX compiler only accepts up to and including C99. My work-around was to assign a name to the union and then update references to the union members with this union name. I am not including a patch because I just named the union "x" and do not know what a more logical name for the union might be. From freddy77 at gmail.com Tue Mar 29 07:42:18 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Tue, 29 Mar 2016 12:42:18 +0100 Subject: [freetds] Compilation issues when compiling under HP-UX B.11.31. In-Reply-To: References: Message-ID: 2016-03-28 16:39 GMT+01:00 Mike Jetzer : > Two compilation issues with freetds-0.95.89 (as well as .88 and .80) when > compiling under HP-UX B.11.31 with the "HP C/aC++ B3910B A.06.20 [May 13 > 2008]" compiler in 32-bit mode. Both have simple work-arounds which are > fine for my requirements, but I thought I'd report them to be addressed > when time permits. > > src/tds/token.c generates a 'warning #2513-D: a value of type "int" cannot > be assigned to an entity of type "char *" because has not been > #included: > nbcbuf = alloca((info->num_cols + 7) / 8); > ^ > > Simply adding an "#include " to token.c solves the issue. I did > not include a patch file because I imagine that this would most properly be > resolved via configure/config.h rather than unconditionally adding it to > token.c. (In the version of Linux I use, performs an #include > of with the default compiler defines, so a prototype is present > and gcc produces no similar warning.) > Fixed. I added AC_FUNC_ALLOCA in configure and proper headers changes. > > The second issue is with src/dblib/dbpivot.c, which generates a large > number of 'error #2136: struct "col_t" has no field "XX" errors due to the > anonymous union in struct col_t's definition. A Google search implies that > anonymous unions were once a gcc extension but were adopted in C11; the > HP-UX compiler only accepts up to and including C99. > > My work-around was to assign a name to the union and then update references > to the union members with this union name. I am not including a patch > because I just named the union "x" and do not know what a more logical name > for the union might be. Named as "data". Tomorrow snapshot should work without problems Frediano