From Oswin.Dsa at mindtree.com Tue Apr 5 03:16:31 2016 From: Oswin.Dsa at mindtree.com (Oswin Dsa) Date: Tue, 5 Apr 2016 07:16:31 +0000 Subject: [freetds] Issue with Connecting to MS SQL Message-ID: Hello, I tried to make changes in DB connection string so that values are picked from FreeTDS.conf file as follows, DB Connection string = Driver=/Applications/xxx.app/Contents/Frameworks/libtdsodbc.so;Servername=ABC;DATABASE=DB;uid=username;pwd=*****;Trusted_Connection=No; FreeTDS.conf (/usr/local/etc) content : [ABC] Host = xxx.xx.xx.xx Port = 1433 tds version = 7.3 dump file =/tmp/freetds.log debug flag = 0xffff client charset = UTF-8 I changed the value of tds version(from 8.0 to 7.3.) after going through FreeTDS user guide . Now the error has changed to , [01000] [FreeTDS][SQL Server]Unknown host machine name. (20013) [08001] [FreeTDS][SQL Server]Unable to connect to data source (0) The freetds.log is also not being generated. So I have no clue what's going wrong and where. Could someone point me in the right direction ? Regards, Oswin ________________________________ http://www.mindtree.com/email/disclaimer.html From john at capps.com Wed Apr 13 20:01:38 2016 From: john at capps.com (John Kendall) Date: Thu, 14 Apr 2016 00:01:38 +0000 Subject: [freetds] defncopy for old servers Message-ID: <6F0EF849-BD55-4C34-8E61-7E3E09C87608@capps.com> The defncopy app has one bit of SQL in it that uses an ANSI join. This makes it fail on pre-ASE 12.0. To get it to work with my old servers i need to patch it each time I download the latest FreeTDS. Since the SQL89 inner joins are still considered fine, I was wondering if this patch could be applied. Then it will work for all servers out-of-the-box. *** defncopy.c-orig Mon Feb 29 12:00:00 2016 --- defncopy.c Wed Apr 13 16:14:57 2016 *************** *** 211,220 **** static const char query[] = " select cast(c.text as text)" #endif /* MicrosoftsDbLib */ ", number " ! " from syscomments as c" ! " join sysobjects as o" ! " on o.id = c.id" ! " where o.name = '%s'" " and o.uid = user_id('%s')" " and o.type not in ('U', 'S')" /* no user or system tables */ " order by c.number, c.colid" --- 211,220 ---- static const char query[] = " select cast(c.text as text)" #endif /* MicrosoftsDbLib */ ", number " ! " from syscomments c," ! " sysobjects o" ! " where o.id = c.id" ! " and o.name = '%s'" " and o.uid = user_id('%s')" " and o.type not in ('U', 'S')" /* no user or system tables */ " order by c.number, c.colid" Thanks for considering this. John From christos at zoulas.com Wed Apr 13 21:17:33 2016 From: christos at zoulas.com (Christos Zoulas) Date: Wed, 13 Apr 2016 21:17:33 -0400 Subject: [freetds] defncopy for old servers In-Reply-To: <6F0EF849-BD55-4C34-8E61-7E3E09C87608@capps.com> from John Kendall (Apr 14, 12:01am) Message-ID: <20160414011734.00B2817FDAB@rebar.astron.com> On Apr 14, 12:01am, john at capps.com (John Kendall) wrote: -- Subject: [freetds] defncopy for old servers | | The defncopy app has one bit of SQL in it that uses an ANSI join. This makes it fail on pre-ASE 12.0. To get it to work with my old servers i need to patch it each time I download the latest FreeTDS. | | Since the SQL89 inner joins are still considered fine, I was wondering if this patch could be applied. Then it will work for all servers out-of-the-box. | Why did you remove the 'as' keyword? christos | | *** defncopy.c-orig Mon Feb 29 12:00:00 2016 | --- defncopy.c Wed Apr 13 16:14:57 2016 | *************** | *** 211,220 **** | static const char query[] = " select cast(c.text as text)" | #endif /* MicrosoftsDbLib */ | ", number " | ! " from syscomments as c" | ! " join sysobjects as o" | ! " on o.id = c.id" | ! " where o.name = '%s'" | " and o.uid = user_id('%s')" | " and o.type not in ('U', 'S')" /* no user or system tables */ | " order by c.number, c.colid" | --- 211,220 ---- | static const char query[] = " select cast(c.text as text)" | #endif /* MicrosoftsDbLib */ | ", number " | ! " from syscomments c," | ! " sysobjects o" | ! " where o.id = c.id" | ! " and o.name = '%s'" | " and o.uid = user_id('%s')" | " and o.type not in ('U', 'S')" /* no user or system tables */ | " order by c.number, c.colid" | | | | | | Thanks for considering this. | | John | | | _______________________________________________ | FreeTDS mailing list | FreeTDS at lists.ibiblio.org | http://lists.ibiblio.org/mailman/listinfo/freetds -- End of excerpt from John Kendall From jezekj at centrum.cz Thu Apr 14 03:18:34 2016 From: jezekj at centrum.cz (jezekj at centrum.cz) Date: Thu, 14 Apr 2016 09:18:34 +0200 Subject: [freetds] =?utf-8?q?Output_bufferring?= Message-ID: <20160414091834.DAF68D33@centrum.cz> Hello, ? we have following issue. In our application we're tring to match securities with our internal ID based on couple of international IDs. Securities are comming from different data providers during the night. We do have a procedure which is trying to match data from these feeds. This procedure is writen to iterate over period of time. At every iteration it prints out statistics about how many securities were matched, and how many securities has not matched, because data from external providers are missing. Everything works fine with MSSQL Studio and even with isql from freetds. However when we call out the procedure from our perl environment. Output is bufferred and this buffer is flushed when procedure finishes. We have tried tracing on several levels and we have found that in FreeTDS trace log messages are written at every itteration. However in UnixODBC trace messages are shown when procedure finishes. ? Question is very easy. Who is the trouble maker? Is freeTDS bufferring messages on it's output (but after tracing log is written), or are these messages buffered in the UnixODBC? ? If you wish to reproduce, just let me know and I will prepare sproc for you. ? Thanks for your time & support. Jakub From no-reply at appveyor.com Thu Apr 14 17:27:12 2016 From: no-reply at appveyor.com (AppVeyor) Date: Thu, 14 Apr 2016 21:27:12 +0000 Subject: [freetds] Build failed: freetds 446 Message-ID: <20160414212711.565.56562.721FA4C0@appveyor.com> From john at capps.com Thu Apr 14 19:23:57 2016 From: john at capps.com (John Kendall) Date: Thu, 14 Apr 2016 23:23:57 +0000 Subject: [freetds] defncopy for old servers In-Reply-To: <6F0EF849-BD55-4C34-8E61-7E3E09C87608@capps.com> References: <6F0EF849-BD55-4C34-8E61-7E3E09C87608@capps.com> Message-ID: <378A5587-9B21-4E8C-8A18-7B8E282456C0@capps.com> > >> The defncopy app has one bit of SQL in it that uses an ANSI join. This makes it fail on pre-ASE 12.0. To get it to work with my old servers i need to patch it each time I download the latest FreeTDS. >> >> Since the SQL89 inner joins are still considered fine, I was wondering if this patch could be applied. Then it will work for all servers out-of-the-box. >> >> > > Why did you remove the 'as' keyword? > > christos The 'as' keyword doesn't work with my older servers; and leaving out the 'as' keyword works with current servers. John > >> *** defncopy.c-orig Mon Feb 29 12:00:00 2016 >> --- defncopy.c Wed Apr 13 16:14:57 2016 >> *************** >> *** 211,220 **** >> static const char query[] = " select cast(c.text as text)" >> #endif /* MicrosoftsDbLib */ >> ", number " >> ! " from syscomments as c" >> ! " join sysobjects as o" >> ! " on o.id = c.id" >> ! " where o.name = '%s'" >> " and o.uid = user_id('%s')" >> " and o.type not in ('U', 'S')" /* no user or system tables */ >> " order by c.number, c.colid" >> --- 211,220 ---- >> static const char query[] = " select cast(c.text as text)" >> #endif /* MicrosoftsDbLib */ >> ", number " >> ! " from syscomments c," >> ! " sysobjects o" >> ! " where o.id = c.id" >> ! " and o.name = '%s'" >> " and o.uid = user_id('%s')" >> " and o.type not in ('U', 'S')" /* no user or system tables */ >> " order by c.number, c.colid" >> >> >> >> >> >> Thanks for considering this. >> >> John From matthew.green at datamartcomputing.com Fri Apr 15 02:32:28 2016 From: matthew.green at datamartcomputing.com (matthew.green at datamartcomputing.com) Date: Fri, 15 Apr 2016 06:32:28 +0000 Subject: [freetds] defncopy for old servers In-Reply-To: <378A5587-9B21-4E8C-8A18-7B8E282456C0@capps.com> References: <378A5587-9B21-4E8C-8A18-7B8E282456C0@capps.com> <6F0EF849-BD55-4C34-8E61-7E3E09C87608@capps.com> Message-ID: <7e586ccdb73b711c96a91f7fff3a37de@datamartcomputing.com> I can't see why we shouldn't make this change. This syntax works with ASE 16 and SQL Server 20114 and I'm not aware of any plans to remove support for it in the future..... if nothing else there are too many programs out there which use this syntax. Cheers, Matthew. April 15 2016 1:24 AM, "John Kendall" wrote: >>> The defncopy app has one bit of SQL in it that uses an ANSI join. This makes it fail on pre-ASE >>> 12.0. To get it to work with my old servers i need to patch it each time I download the latest >>> FreeTDS. >>> >>> Since the SQL89 inner joins are still considered fine, I was wondering if this patch could be >>> applied. Then it will work for all servers out-of-the-box. >> >> Why did you remove the 'as' keyword? >> >> christos > > The 'as' keyword doesn't work with my older servers; and leaving out the 'as' keyword works with > current servers. > > John > >>> *** defncopy.c-orig Mon Feb 29 12:00:00 2016 >>> --- defncopy.c Wed Apr 13 16:14:57 2016 >>> *************** >>> *** 211,220 **** >>> static const char query[] = " select cast(c.text as text)" >>> #endif /* MicrosoftsDbLib */ >>> ", number " >>> ! " from syscomments as c" >>> ! " join sysobjects as o" >>> ! " on o.id = c.id" >>> ! " where o.name = '%s'" >>> " and o.uid = user_id('%s')" >>> " and o.type not in ('U', 'S')" /* no user or system tables */ >>> " order by c.number, c.colid" >>> --- 211,220 ---- >>> static const char query[] = " select cast(c.text as text)" >>> #endif /* MicrosoftsDbLib */ >>> ", number " >>> ! " from syscomments c," >>> ! " sysobjects o" >>> ! " where o.id = c.id" >>> ! " and o.name = '%s'" >>> " and o.uid = user_id('%s')" >>> " and o.type not in ('U', 'S')" /* no user or system tables */ >>> " order by c.number, c.colid" >>> >>> Thanks for considering this. >>> >>> John > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From no-reply at appveyor.com Fri Apr 15 09:32:47 2016 From: no-reply at appveyor.com (AppVeyor) Date: Fri, 15 Apr 2016 13:32:47 +0000 Subject: [freetds] Build completed: freetds 447 Message-ID: <20160415133247.12755.83401.16AD0957@appveyor.com> From velichko.yuriy at gmail.com Fri Apr 15 09:29:03 2016 From: velichko.yuriy at gmail.com (Velichko Yuriy) Date: Fri, 15 Apr 2016 16:29:03 +0300 Subject: [freetds] Need help with build on Windows Message-ID: ?Hello! I've downloaded ?the latest version of FreeTDS, configured and builded it with CMake and Visual Studio 2013. I need to use only db-lib as a static library. So I copied it to the project and linked with it. But on building the project I have got link errors like this: : unresolved external symbol _tdsdump_open referenced in function _tdsdbopen C:\.......\db-lib.lib(dblib.obj) ?I can't find out how to fix this issue. Help me please! ) Thanks!? From freddy77 at gmail.com Fri Apr 15 10:53:54 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Fri, 15 Apr 2016 15:53:54 +0100 Subject: [freetds] defncopy for old servers In-Reply-To: <7e586ccdb73b711c96a91f7fff3a37de@datamartcomputing.com> References: <6F0EF849-BD55-4C34-8E61-7E3E09C87608@capps.com> <378A5587-9B21-4E8C-8A18-7B8E282456C0@capps.com> <7e586ccdb73b711c96a91f7fff3a37de@datamartcomputing.com> Message-ID: That's why I applied it :-) Frediano 2016-04-15 7:32 GMT+01:00 : > I can't see why we shouldn't make this change. This syntax works with ASE 16 and SQL Server 20114 and I'm not aware of any plans to remove support for it in the future..... if nothing else there are too many programs out there which use this syntax. > > Cheers, > > Matthew. > > April 15 2016 1:24 AM, "John Kendall" wrote: >>>> The defncopy app has one bit of SQL in it that uses an ANSI join. This makes it fail on pre-ASE >>>> 12.0. To get it to work with my old servers i need to patch it each time I download the latest >>>> FreeTDS. >>>> >>>> Since the SQL89 inner joins are still considered fine, I was wondering if this patch could be >>>> applied. Then it will work for all servers out-of-the-box. >>> >>> Why did you remove the 'as' keyword? >>> >>> christos >> >> The 'as' keyword doesn't work with my older servers; and leaving out the 'as' keyword works with >> current servers. >> >> John >> >>>> *** defncopy.c-orig Mon Feb 29 12:00:00 2016 >>>> --- defncopy.c Wed Apr 13 16:14:57 2016 >>>> *************** >>>> *** 211,220 **** >>>> static const char query[] = " select cast(c.text as text)" >>>> #endif /* MicrosoftsDbLib */ >>>> ", number " >>>> ! " from syscomments as c" >>>> ! " join sysobjects as o" >>>> ! " on o.id = c.id" >>>> ! " where o.name = '%s'" >>>> " and o.uid = user_id('%s')" >>>> " and o.type not in ('U', 'S')" /* no user or system tables */ >>>> " order by c.number, c.colid" >>>> --- 211,220 ---- >>>> static const char query[] = " select cast(c.text as text)" >>>> #endif /* MicrosoftsDbLib */ >>>> ", number " >>>> ! " from syscomments c," >>>> ! " sysobjects o" >>>> ! " where o.id = c.id" >>>> ! " and o.name = '%s'" >>>> " and o.uid = user_id('%s')" >>>> " and o.type not in ('U', 'S')" /* no user or system tables */ >>>> " order by c.number, c.colid" >>>> >>>> Thanks for considering this. >>>> >>>> John >> >> _______________________________________________ >> 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 Apr 15 10:54:54 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Fri, 15 Apr 2016 15:54:54 +0100 Subject: [freetds] Need help with build on Windows In-Reply-To: References: Message-ID: 2016-04-15 14:29 GMT+01:00 Velichko Yuriy : > Hello! > > I've downloaded the latest version of FreeTDS, configured and builded it > with CMake and Visual Studio 2013. > > I need to use only db-lib as a static library. > So I copied it to the project and linked with it. > > But on building the project I have got link errors like this: > > : unresolved external symbol _tdsdump_open referenced in function _tdsdbopen > C:\.......\db-lib.lib(dblib.obj) > > I can't find out how to fix this issue. > Help me please! ) > > Thanks! DB-Library depends on libTDS so for statis linking you have to add both libraries. Also possibly the replacements one. Frediano From freddy77 at gmail.com Fri Apr 15 11:02:54 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Fri, 15 Apr 2016 16:02:54 +0100 Subject: [freetds] Output bufferring In-Reply-To: <20160414091834.DAF68D33@centrum.cz> References: <20160414091834.DAF68D33@centrum.cz> Message-ID: 2016-04-14 8:18 GMT+01:00 : > Hello, > > we have following issue. In our application we're tring to match securities with our internal ID based on couple of international IDs. Securities are comming from different data providers during the night. We do have a procedure which is trying to match data from these feeds. This procedure is writen to iterate over period of time. At every iteration it prints out statistics about how many securities were matched, and how many securities has not matched, because data from external providers are missing. Everything works fine with MSSQL Studio and even with isql from freetds. However when we call out the procedure from our perl environment. Output is bufferred and this buffer is flushed when procedure finishes. We have tried tracing on several levels and we have found that in FreeTDS trace log messages are written at every itteration. However in UnixODBC trace messages are shown when procedure finishes. > > Question is very easy. Who is the trouble maker? Is freeTDS bufferring messages on it's output (but after tracing log is written), or are these messages buffered in the UnixODBC? > > If you wish to reproduce, just let me know and I will prepare sproc for you. > > Thanks for your time & support. > Jakub I think what you are looking for is SET NOCOUNT option. A bit of explanation. SQL Server during command (SELECTs, UPDATEs and so on) send back number of row processed. Even during store procedure! So even a simple command like "SELECT @var = 123" by default send back the number of rows (in this case 1). Disabling the option reduce the data sent back. For the SELECT case above you can also use SET instead. I would also suggest to use less queries and more join but not knowing the code I could not suggest anything in particular. Hope I guessed your problem. Frediano From freddy77 at gmail.com Fri Apr 15 11:04:56 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Fri, 15 Apr 2016 16:04:56 +0100 Subject: [freetds] Issue with Connecting to MS SQL In-Reply-To: References: Message-ID: 2016-04-05 8:16 GMT+01:00 Oswin Dsa : > Hello, > > I tried to make changes in DB connection string so that values are picked from FreeTDS.conf file as follows, > > DB Connection string = Driver=/Applications/xxx.app/Contents/Frameworks/libtdsodbc.so;Servername=ABC;DATABASE=DB;uid=username;pwd=*****;Trusted_Connection=No; > > FreeTDS.conf (/usr/local/etc) content : > > [ABC] > Host = xxx.xx.xx.xx > Port = 1433 > tds version = 7.3 > dump file =/tmp/freetds.log > debug flag = 0xffff > client charset = UTF-8 > > I changed the value of tds version(from 8.0 to 7.3.) after going through FreeTDS user guide . > > Now the error has changed to , > [01000] [FreeTDS][SQL Server]Unknown host machine name. (20013) > [08001] [FreeTDS][SQL Server]Unable to connect to data source (0) > > The freetds.log is also not being generated. So I have no clue what's going wrong and where. > > Could someone point me in the right direction ? > > Regards, > Oswin > Try to use TDSDUMPCONFIG environment. Could be that is not picking up your freetds.conf file for some reason. Are you sure that server port is 1433 and open? Frediano From freddy77 at gmail.com Fri Apr 15 11:08:00 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Fri, 15 Apr 2016 16:08:00 +0100 Subject: [freetds] freebcp adding escaping In-Reply-To: <56B184A9.1040603@smart-associates.biz> References: <56B184A9.1040603@smart-associates.biz> Message-ID: 2016-02-03 4:40 GMT+00:00 Andrew Punch : > 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 > Sorry for late reply. Honestly looks quite weird to change freebcp. freebcp use a format which is quite similar to normal bcp utility. I would honestly change tsql instead. Frediano From james.k.lowden at icloud.com Fri Apr 15 11:31:32 2016 From: james.k.lowden at icloud.com (James K. Lowden) Date: Fri, 15 Apr 2016 11:31:32 -0400 Subject: [freetds] Output bufferring In-Reply-To: <20160414091834.DAF68D33@centrum.cz> References: <20160414091834.DAF68D33@centrum.cz> Message-ID: <20160415113132.cc3bc762dda0d5d271fca179@icloud.com> On Thu, 14 Apr 2016 09:18:34 +0200 wrote: > We have tried tracing on several levels and we have found that in > FreeTDS trace log messages are written at every itteration. However > in UnixODBC trace messages are shown when procedure finishes. > > [...] Is freeTDS bufferring messages on it's output (but after > tracing log is written), or are these messages buffered in the > UnixODBC? If you look at the FreeTDS logging function, you'll see it opens and closes the logfile each time a message is written. That ensures each message is flushed to the disk, but it's very expensive in terms of performance. You don't want to use TDSDUMP in production. >From your description, it sounds like you're using log message to monitor your application's data status. If so, I would counsel you that that's a mistake. Better at the application level to capture the statistics you need and flush them under application control (or, you know, insert them in a table). Then you don't have to worry about the vagaries of ODBC log buffering. HTH. --jkl From cramm0 at gmail.com Fri Apr 15 11:52:54 2016 From: cramm0 at gmail.com (Ramiro Morales) Date: Fri, 15 Apr 2016 12:52:54 -0300 Subject: [freetds] Need help with build on Windows In-Reply-To: References: Message-ID: On Fri, Apr 15, 2016 at 10:29 AM, Velichko Yuriy wrote: > ?Hello! > > I've downloaded ?the latest version of FreeTDS, configured and builded it > with CMake and Visual Studio 2013. > > I need to use only db-lib as a static library. > So I copied it to the project and linked with it. > > But on building the project I have got link errors like this: > > : unresolved external symbol _tdsdump_open referenced in function > _tdsdbopen > C:\.......\db-lib.lib(dblib.obj) > > ?I can't find out how to fix this issue. > Help me please! ) > > Thanks!? > You can download FreeTDS binaries for Windows from AppVeyor (the hosted CI platform used). There is a .zip file available as artifact of every sucessful build. The list of builds: https://ci.appveyor.com/project/FreeTDS/freetds/history You can find there builds of code in the master banch and (from time to time) builds from the post-0.95 release fixes-only Branch-0_95 branch. A recent sucessful build: https://ci.appveyor.com/project/FreeTDS/freetds/build/448 Every build matrix element generates its artifact. e.g. for x86_64 builds with Visual Studio 2015: https://ci.appveyor.com/project/FreeTDS/freetds/build/448/job/5a8osy4ey1bqir03 and the resulting zip file: https://ci.appveyor.com/project/FreeTDS/freetds/build/448/job/5a8osy4ey1bqir03/artifacts I also maintain similar builds of the Branch-0_95 branch at https://github.com/ramiro/freetds/releases If you don't want or can't use binaries built by third parties then the appveyor.yml file and associated files (find them on the source tree) can be of help as a source of information and experience to avoid common pitfalls/pain points when building FreeTDS on Windows. HTH -- Ramiro Morales @ramiromorales From velichko.yuriy at gmail.com Fri Apr 15 11:27:08 2016 From: velichko.yuriy at gmail.com (Velichko Yuriy) Date: Fri, 15 Apr 2016 18:27:08 +0300 Subject: [freetds] Need help with build on Windows In-Reply-To: References: Message-ID: Adding tds.lib helps to avoid many of errors from linker. But appeared others like _tds_win_mutex_lock _tds_sys_iconv _vasprintf _strtok_r I think I can handle with errors by finding missed dependancies. You mentioned that there is possibility to replacement to one. Prompt how to do it? Thanks! On 15 April 2016 at 17:54, Frediano Ziglio wrote: > 2016-04-15 14:29 GMT+01:00 Velichko Yuriy : > > Hello! > > > > I've downloaded the latest version of FreeTDS, configured and builded it > > with CMake and Visual Studio 2013. > > > > I need to use only db-lib as a static library. > > So I copied it to the project and linked with it. > > > > But on building the project I have got link errors like this: > > > > : unresolved external symbol _tdsdump_open referenced in function > _tdsdbopen > > C:\.......\db-lib.lib(dblib.obj) > > > > I can't find out how to fix this issue. > > Help me please! ) > > > > Thanks! > > DB-Library depends on libTDS so for statis linking you have to add > both libraries. Also possibly the replacements one. > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > -- ?? ?????????, ??????? ????. From velichko.yuriy at gmail.com Fri Apr 15 12:44:07 2016 From: velichko.yuriy at gmail.com (Velichko Yuriy) Date: Fri, 15 Apr 2016 19:44:07 +0300 Subject: [freetds] Need help with build on Windows In-Reply-To: References: Message-ID: Thanks Alot!!! Btw, I think you can include this answer into FreeTDS docs, because it can be helpful to users. On 15 April 2016 at 18:52, Ramiro Morales wrote: > On Fri, Apr 15, 2016 at 10:29 AM, Velichko Yuriy > > wrote: > > > ?Hello! > > > > I've downloaded ?the latest version of FreeTDS, configured and builded it > > with CMake and Visual Studio 2013. > > > > I need to use only db-lib as a static library. > > So I copied it to the project and linked with it. > > > > But on building the project I have got link errors like this: > > > > : unresolved external symbol _tdsdump_open referenced in function > > _tdsdbopen > > C:\.......\db-lib.lib(dblib.obj) > > > > ?I can't find out how to fix this issue. > > Help me please! ) > > > > Thanks!? > > > > > You can download FreeTDS binaries for Windows from AppVeyor (the hosted CI > platform used). > > There is a .zip file available as artifact of every sucessful build. > > The list of builds: > https://ci.appveyor.com/project/FreeTDS/freetds/history > > You can find there builds of code in the master banch and (from time to > time) builds from the post-0.95 release fixes-only Branch-0_95 branch. > > A recent sucessful build: > https://ci.appveyor.com/project/FreeTDS/freetds/build/448 > > Every build matrix element generates its artifact. e.g. for x86_64 builds > with Visual Studio 2015: > > https://ci.appveyor.com/project/FreeTDS/freetds/build/448/job/5a8osy4ey1bqir03 > and the resulting zip file: > > https://ci.appveyor.com/project/FreeTDS/freetds/build/448/job/5a8osy4ey1bqir03/artifacts > > I also maintain similar builds of the Branch-0_95 branch at > https://github.com/ramiro/freetds/releases > > If you don't want or can't use binaries built by third parties then the > appveyor.yml file and associated files (find them on the source tree) can > be of help as a source of information and experience to avoid common > pitfalls/pain points when building FreeTDS on Windows. > > HTH > > > -- > Ramiro Morales > @ramiromorales > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > -- ?? ?????????, ??????? ????. From velichko.yuriy at gmail.com Sun Apr 17 06:57:57 2016 From: velichko.yuriy at gmail.com (Velichko Yuriy) Date: Sun, 17 Apr 2016 13:57:57 +0300 Subject: [freetds] Conversion emoji symbols to UTF-8 Message-ID: I use UTF-8 charset according to docs: http://www.freetds.org/userguide/unicodefreetds.htm My .conf includes next rows: tds version = 7.0 client charset = UTF-8 All worked as expected until the emoji symbol appeared in the data string. In result I got ??? symbols. If to try example from answer in this post (all string is emoji) the returned data from method dbdata() will be an empty string with non zero lenght (about 60 for example). Here I have read http://www.freetds.org/userguide/localization.htm that not all symbols can be converted properly. Looks like this is my case. But maybe some one faced with this problem and solved it with FreeTDS? Because using emoji is not rare case in our time. Maybe need to use another encoding, or something else? Thanks! From freddy77 at gmail.com Sun Apr 17 08:05:30 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Sun, 17 Apr 2016 13:05:30 +0100 Subject: [freetds] Conversion emoji symbols to UTF-8 In-Reply-To: References: Message-ID: On 17 Apr 2016 12:59, "Velichko Yuriy" wrote: > > I use UTF-8 charset according to docs: > > http://www.freetds.org/userguide/unicodefreetds.htm > > My .conf includes next rows: > > tds version = 7.0 > client charset = UTF-8 > > All worked as expected until the emoji symbol appeared in the data string. > > In result I got ??? symbols. > Data in the database are stored correctly? > If to try example from answer in this post (all string is emoji) the > returned data from method dbdata() will be an empty string with non zero > lenght (about 60 for example). > > Here I have read > http://www.freetds.org/userguide/localization.htm > that not all symbols can be converted properly. Looks like this is my case. > > But maybe some one faced with this problem and solved it with FreeTDS? > Because using emoji is not rare case in our time. > > Maybe need to use another encoding, or something else? > > Thanks! > Are you using iconv correctly? Don't expect to work without it. Which library are you using? Does the output work correctly with utf8? Frediano From velichko.yuriy at gmail.com Sun Apr 17 08:19:29 2016 From: velichko.yuriy at gmail.com (Velichko Yuriy) Date: Sun, 17 Apr 2016 15:19:29 +0300 Subject: [freetds] Conversion emoji symbols to UTF-8 In-Reply-To: References: Message-ID: 1 Data stored correctly because, for example SMSS shows emoji as expected 2 I use static db-lib 3 Other unicode text is shown correctly On 17 April 2016 at 15:05, Frediano Ziglio wrote: > On 17 Apr 2016 12:59, "Velichko Yuriy" wrote: > > > > I use UTF-8 charset according to docs: > > > > http://www.freetds.org/userguide/unicodefreetds.htm > > > > My .conf includes next rows: > > > > tds version = 7.0 > > client charset = UTF-8 > > > > All worked as expected until the emoji symbol appeared in the data > string. > > > > In result I got ??? symbols. > > > > Data in the database are stored correctly? > > > If to try example from answer in this post (all string is emoji) the > > returned data from method dbdata() will be an empty string with non zero > > lenght (about 60 for example). > > > > Here I have read > > http://www.freetds.org/userguide/localization.htm > > that not all symbols can be converted properly. Looks like this is my > case. > > > > But maybe some one faced with this problem and solved it with FreeTDS? > > Because using emoji is not rare case in our time. > > > > Maybe need to use another encoding, or something else? > > > > Thanks! > > > > Are you using iconv correctly? Don't expect to work without it. > Which library are you using? > Does the output work correctly with utf8? > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > -- ?? ?????????, ??????? ????. From freddy77 at gmail.com Sun Apr 17 13:24:41 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Sun, 17 Apr 2016 18:24:41 +0100 Subject: [freetds] Conversion emoji symbols to UTF-8 In-Reply-To: References: Message-ID: Can you post a small dump? You could try a simple query like SELECT N'hello some emoticons' Frediano 2016-04-17 13:19 GMT+01:00 Velichko Yuriy : > 1 Data stored correctly because, for example SMSS shows emoji as expected > 2 I use static db-lib > 3 Other unicode text is shown correctly > > On 17 April 2016 at 15:05, Frediano Ziglio wrote: > >> On 17 Apr 2016 12:59, "Velichko Yuriy" wrote: >> > >> > I use UTF-8 charset according to docs: >> > >> > http://www.freetds.org/userguide/unicodefreetds.htm >> > >> > My .conf includes next rows: >> > >> > tds version = 7.0 >> > client charset = UTF-8 >> > >> > All worked as expected until the emoji symbol appeared in the data >> string. >> > >> > In result I got ??? symbols. >> > >> >> Data in the database are stored correctly? >> >> > If to try example from answer in this post (all string is emoji) the >> > returned data from method dbdata() will be an empty string with non zero >> > lenght (about 60 for example). >> > >> > Here I have read >> > http://www.freetds.org/userguide/localization.htm >> > that not all symbols can be converted properly. Looks like this is my >> case. >> > >> > But maybe some one faced with this problem and solved it with FreeTDS? >> > Because using emoji is not rare case in our time. >> > >> > Maybe need to use another encoding, or something else? >> > >> > Thanks! >> > >> >> Are you using iconv correctly? Don't expect to work without it. >> Which library are you using? >> Does the output work correctly with utf8? >> >> Frediano >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> http://lists.ibiblio.org/mailman/listinfo/freetds >> > > > > -- > ? ?????????, ??????? ????. > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From freddy77 at gmail.com Sun Apr 17 14:37:41 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Sun, 17 Apr 2016 19:37:41 +0100 Subject: [freetds] FreeTDS 1.0 Release Candidate 1 is out! Message-ID: Hi, it's finally time for a 1.0 release! There are not much exiting changes in this release. You can read changes at https://raw.githubusercontent.com/FreeTDS/freetds/Branch-1_00/NEWS. The biggest changes are - pool is now back in a production state. It's limited to MS SQL; - ODBC BCP support; - encrypted Sybase login; - new types for Sybase. Pay attention that "8.0" protocol version is no more supported. Update to a proper version. This was marked as deprecated some versions ago. Another configuration change is that now the default protocol version is "auto", meaning that FreeTDS will try to find the best one. This could slow down connection but will make new users more happier. You can find links for the download at the website (from news page or index one). Please send any feedback, comments, updated to User Guide or whatever documentation. At https://raw.githubusercontent.com/FreeTDS/freetds/Branch-1_00/Thanks-1.0 you can find a list of people contributing to this release. If you feel you should be in that list, you have some corrections or you don't want to be in the list please send a request through the mailing list or to me. Regards, Frediano From no-reply at appveyor.com Sun Apr 17 14:37:43 2016 From: no-reply at appveyor.com (AppVeyor) Date: Sun, 17 Apr 2016 18:37:43 +0000 Subject: [freetds] Build failed: freetds 459 Message-ID: <20160417183743.8340.47024.2D65CC7E@appveyor.com> From velichko.yuriy at gmail.com Sun Apr 17 15:12:12 2016 From: velichko.yuriy at gmail.com (Velichko Yuriy) Date: Sun, 17 Apr 2016 22:12:12 +0300 Subject: [freetds] Conversion emoji symbols to UTF-8 In-Reply-To: References: Message-ID: Here some examples of query result: SELECT N'?' dbdatlen() == 4 "\x00\xFF\x91\x8D" SELECT N'???? ? test' dbdatlen() == 18 "\xD1\x82\xD0\xB5\xD1\x81\xD1\x82 \x00\xFF\x91\x8D test" To store data and show it in UI I use Qt: QString::fromUtf8(); On 17 April 2016 at 20:24, Frediano Ziglio wrote: > Can you post a small dump? > > You could try a simple query like > > SELECT N'hello some emoticons' > > Frediano > > 2016-04-17 13:19 GMT+01:00 Velichko Yuriy : > > 1 Data stored correctly because, for example SMSS shows emoji as expected > > 2 I use static db-lib > > 3 Other unicode text is shown correctly > > > > On 17 April 2016 at 15:05, Frediano Ziglio wrote: > > > >> On 17 Apr 2016 12:59, "Velichko Yuriy" > wrote: > >> > > >> > I use UTF-8 charset according to docs: > >> > > >> > http://www.freetds.org/userguide/unicodefreetds.htm > >> > > >> > My .conf includes next rows: > >> > > >> > tds version = 7.0 > >> > client charset = UTF-8 > >> > > >> > All worked as expected until the emoji symbol appeared in the data > >> string. > >> > > >> > In result I got ??? symbols. > >> > > >> > >> Data in the database are stored correctly? > >> > >> > If to try example from answer in this post (all string is emoji) the > >> > returned data from method dbdata() will be an empty string with non > zero > >> > lenght (about 60 for example). > >> > > >> > Here I have read > >> > http://www.freetds.org/userguide/localization.htm > >> > that not all symbols can be converted properly. Looks like this is my > >> case. > >> > > >> > But maybe some one faced with this problem and solved it with FreeTDS? > >> > Because using emoji is not rare case in our time. > >> > > >> > Maybe need to use another encoding, or something else? > >> > > >> > Thanks! > >> > > >> > >> Are you using iconv correctly? Don't expect to work without it. > >> Which library are you using? > >> Does the output work correctly with utf8? > >> > >> Frediano > >> _______________________________________________ > >> FreeTDS mailing list > >> FreeTDS at lists.ibiblio.org > >> http://lists.ibiblio.org/mailman/listinfo/freetds > >> > > > > > > > > -- > > ? ?????????, ??????? ????. > > _______________________________________________ > > FreeTDS mailing list > > FreeTDS at lists.ibiblio.org > > http://lists.ibiblio.org/mailman/listinfo/freetds > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > -- ?? ?????????, ??????? ????. From freddy77 at gmail.com Sun Apr 17 17:19:13 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Sun, 17 Apr 2016 22:19:13 +0100 Subject: [freetds] Conversion emoji symbols to UTF-8 In-Reply-To: References: Message-ID: Looks like an encoding bug. Time ago I fixed a similar issue. Could be you don't have this fix. Frediano On 17 Apr 2016 20:20, "Velichko Yuriy" wrote: > Here some examples of query result: > > SELECT N'?' > dbdatlen() == 4 > "\x00\xFF\x91\x8D" > > SELECT N'???? ? test' > dbdatlen() == 18 > "\xD1\x82\xD0\xB5\xD1\x81\xD1\x82 \x00\xFF\x91\x8D test" > > To store data and show it in UI I use Qt: > QString::fromUtf8(); > > > On 17 April 2016 at 20:24, Frediano Ziglio wrote: > > > Can you post a small dump? > > > > You could try a simple query like > > > > SELECT N'hello some emoticons' > > > > Frediano > > > > 2016-04-17 13:19 GMT+01:00 Velichko Yuriy : > > > 1 Data stored correctly because, for example SMSS shows emoji as > expected > > > 2 I use static db-lib > > > 3 Other unicode text is shown correctly > > > > > > On 17 April 2016 at 15:05, Frediano Ziglio wrote: > > > > > >> On 17 Apr 2016 12:59, "Velichko Yuriy" > > wrote: > > >> > > > >> > I use UTF-8 charset according to docs: > > >> > > > >> > http://www.freetds.org/userguide/unicodefreetds.htm > > >> > > > >> > My .conf includes next rows: > > >> > > > >> > tds version = 7.0 > > >> > client charset = UTF-8 > > >> > > > >> > All worked as expected until the emoji symbol appeared in the data > > >> string. > > >> > > > >> > In result I got ??? symbols. > > >> > > > >> > > >> Data in the database are stored correctly? > > >> > > >> > If to try example from answer in this post (all string is emoji) > the > > >> > returned data from method dbdata() will be an empty string with non > > zero > > >> > lenght (about 60 for example). > > >> > > > >> > Here I have read > > >> > http://www.freetds.org/userguide/localization.htm > > >> > that not all symbols can be converted properly. Looks like this is > my > > >> case. > > >> > > > >> > But maybe some one faced with this problem and solved it with > FreeTDS? > > >> > Because using emoji is not rare case in our time. > > >> > > > >> > Maybe need to use another encoding, or something else? > > >> > > > >> > Thanks! > > >> > > > >> > > >> Are you using iconv correctly? Don't expect to work without it. > > >> Which library are you using? > > >> Does the output work correctly with utf8? > > >> > > >> 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 james.k.lowden at icloud.com Sun Apr 17 18:27:04 2016 From: james.k.lowden at icloud.com (James K. Lowden) Date: Sun, 17 Apr 2016 18:27:04 -0400 Subject: [freetds] freebcp adding escaping In-Reply-To: <56B184A9.1040603@smart-associates.biz> References: <56B184A9.1040603@smart-associates.biz> Message-ID: <20160417182704.6f2b90ca9868615403166e0d@icloud.com> On Wed, 3 Feb 2016 15:40:09 +1100 Andrew Punch wrote: > 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 disagree with Frediano; I think freebcp is the right place to add csv support. But if I were in his shoes, I'd be reluctant to take your patch without quite a bit more work and testing. It's not true that freebcp handles escape characters incorrectly. freebcp *defines* its text-file formats, and that definition doesn't include an escape mechanism. The column and row delimiters are strings (not single characters). Any character sequence that does not appear in the data will serve. ASCII includes US and RS codes (31 and 30) which were intended for the purpose. (It would be a nice addition to support them as named escapes for the -r and -t options of freebcp.) The reason I'd be reluctant to apply your patch is that CSV is a complex format. It's defined, sort of, by an RFC, but there are many de facto variations on that theme, including using tabs instead of commas as delimiters (in a Comma-Separated Variable format!) To parse CSV correctly, you need to parse it as a context-free language. Regular expressions aren't good enough, and an ad hoc work-for-me hack will likely be frustrating to users and developers both. If you want to do the job correctly, then, you need to write or import a parser for CSV grammar. As it happens, I've written one that could perhaps be adapted and that I would be willing to contribute to the FreeTDS project (http://www.schemamania.org/sql/sqlite/udf/). It's certainly not the only one. It doesn't handle every variation, but it did pass tests I found that were provided by another csv-parser as examples. Let me know if you're interested. To answer your other questions: > 1. is dblib the best place to make the change? If so, it would be in the bcp functions. > 2. what is the best structure to pass parameters and flags? Namely: > 1. Flag for delimiter escaping Please elaborate. > 2. The actual delimiter (I notice that the column delimiter > changes to EOL for the last column) If you want to last column to include the column *separator*, define your row separator to include it. For example, -t \\t -r\\t\\n would do the job. > 3. Flag for NULL string replacement (instead of ASCII NUL) > 4. NULL string replacement This is a separate issue, and could go two ways: either convert an external string to NULL in the database, or convert missing external data to a particular string in the database. The only real challenge is to define the freebcp option syntax; internally, it's just a few calls to bcp_colfmt. HTH. --jkl From james.k.lowden at icloud.com Sun Apr 17 19:34:46 2016 From: james.k.lowden at icloud.com (James K. Lowden) Date: Sun, 17 Apr 2016 19:34:46 -0400 Subject: [freetds] FreeTDS 1.0 Release Candidate 1 is out! In-Reply-To: References: Message-ID: <20160417193446.fe892fcb303c5835ffa38ea7@icloud.com> On Sun, 17 Apr 2016 19:37:41 +0100 Frediano Ziglio wrote: > - ODBC BCP support; Hurrah! > default protocol version is "auto", a welcome change. > it's finally time for a 1.0 release! Hearty congratulations! It's been a long, strange trip. --jkl From velichko.yuriy at gmail.com Mon Apr 18 03:05:40 2016 From: velichko.yuriy at gmail.com (Velichko Yuriy) Date: Mon, 18 Apr 2016 10:05:40 +0300 Subject: [freetds] Conversion emoji symbols to UTF-8 In-Reply-To: References: Message-ID: Ok, I will update freetds and tell you result. On 18 April 2016 at 00:19, Frediano Ziglio wrote: > Looks like an encoding bug. Time ago I fixed a similar issue. > Could be you don't have this fix. > > Frediano > On 17 Apr 2016 20:20, "Velichko Yuriy" wrote: > > > Here some examples of query result: > > > > SELECT N'?' > > dbdatlen() == 4 > > "\x00\xFF\x91\x8D" > > > > SELECT N'???? ? test' > > dbdatlen() == 18 > > "\xD1\x82\xD0\xB5\xD1\x81\xD1\x82 \x00\xFF\x91\x8D test" > > > > To store data and show it in UI I use Qt: > > QString::fromUtf8(); > > > > > > On 17 April 2016 at 20:24, Frediano Ziglio wrote: > > > > > Can you post a small dump? > > > > > > You could try a simple query like > > > > > > SELECT N'hello some emoticons' > > > > > > Frediano > > > > > > 2016-04-17 13:19 GMT+01:00 Velichko Yuriy : > > > > 1 Data stored correctly because, for example SMSS shows emoji as > > expected > > > > 2 I use static db-lib > > > > 3 Other unicode text is shown correctly > > > > > > > > On 17 April 2016 at 15:05, Frediano Ziglio > wrote: > > > > > > > >> On 17 Apr 2016 12:59, "Velichko Yuriy" > > > wrote: > > > >> > > > > >> > I use UTF-8 charset according to docs: > > > >> > > > > >> > http://www.freetds.org/userguide/unicodefreetds.htm > > > >> > > > > >> > My .conf includes next rows: > > > >> > > > > >> > tds version = 7.0 > > > >> > client charset = UTF-8 > > > >> > > > > >> > All worked as expected until the emoji symbol appeared in the data > > > >> string. > > > >> > > > > >> > In result I got ??? symbols. > > > >> > > > > >> > > > >> Data in the database are stored correctly? > > > >> > > > >> > If to try example from answer in this post (all string is emoji) > > the > > > >> > returned data from method dbdata() will be an empty string with > non > > > zero > > > >> > lenght (about 60 for example). > > > >> > > > > >> > Here I have read > > > >> > http://www.freetds.org/userguide/localization.htm > > > >> > that not all symbols can be converted properly. Looks like this is > > my > > > >> case. > > > >> > > > > >> > But maybe some one faced with this problem and solved it with > > FreeTDS? > > > >> > Because using emoji is not rare case in our time. > > > >> > > > > >> > Maybe need to use another encoding, or something else? > > > >> > > > > >> > Thanks! > > > >> > > > > >> > > > >> Are you using iconv correctly? Don't expect to work without it. > > > >> Which library are you using? > > > >> Does the output work correctly with utf8? > > > >> > > > >> 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 velichko.yuriy at gmail.com Mon Apr 18 06:04:58 2016 From: velichko.yuriy at gmail.com (Velichko Yuriy) Date: Mon, 18 Apr 2016 13:04:58 +0300 Subject: [freetds] Need help with build on Windows In-Reply-To: References: Message-ID: ?I have tried to use db-lib.lib from ?AppVeyor archive and got same link issues. So I went back to CMake + Visual Studio + Manual build And figure out that need to use replacements.lib too. So if I link my application to db-lib.lib tds.lib replacements.lib the build performs without errors and all works fine. So there are few more question: 1 why replacements.lib is absent in AppVeyor archive 2 I have inherited project that uses SINGLE file db-lib.lib and all works. But it size much bigger (2.5 Mb for x86). How it can be? may be old version has such build output? 3 It is correct approach to use 3 libs, or there is a way to get a single file? Regards. On 15 April 2016 at 19:44, Velichko Yuriy wrote: > Thanks Alot!!! > > Btw, I think you can include this answer into FreeTDS docs, because it can > be helpful to users. > > > > On 15 April 2016 at 18:52, Ramiro Morales wrote: > >> On Fri, Apr 15, 2016 at 10:29 AM, Velichko Yuriy < >> velichko.yuriy at gmail.com> >> wrote: >> >> > ?Hello! >> > >> > I've downloaded ?the latest version of FreeTDS, configured and builded >> it >> > with CMake and Visual Studio 2013. >> > >> > I need to use only db-lib as a static library. >> > So I copied it to the project and linked with it. >> > >> > But on building the project I have got link errors like this: >> > >> > : unresolved external symbol _tdsdump_open referenced in function >> > _tdsdbopen >> > C:\.......\db-lib.lib(dblib.obj) >> > >> > ?I can't find out how to fix this issue. >> > Help me please! ) >> > >> > Thanks!? >> > >> >> >> You can download FreeTDS binaries for Windows from AppVeyor (the hosted >> CI >> platform used). >> >> There is a .zip file available as artifact of every sucessful build. >> >> The list of builds: >> https://ci.appveyor.com/project/FreeTDS/freetds/history >> >> You can find there builds of code in the master banch and (from time to >> time) builds from the post-0.95 release fixes-only Branch-0_95 branch. >> >> A recent sucessful build: >> https://ci.appveyor.com/project/FreeTDS/freetds/build/448 >> >> Every build matrix element generates its artifact. e.g. for x86_64 builds >> with Visual Studio 2015: >> >> https://ci.appveyor.com/project/FreeTDS/freetds/build/448/job/5a8osy4ey1bqir03 >> and the resulting zip file: >> >> https://ci.appveyor.com/project/FreeTDS/freetds/build/448/job/5a8osy4ey1bqir03/artifacts >> >> I also maintain similar builds of the Branch-0_95 branch at >> https://github.com/ramiro/freetds/releases >> >> If you don't want or can't use binaries built by third parties then the >> appveyor.yml file and associated files (find them on the source tree) can >> be of help as a source of information and experience to avoid common >> pitfalls/pain points when building FreeTDS on Windows. >> >> HTH >> >> >> -- >> Ramiro Morales >> @ramiromorales >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> http://lists.ibiblio.org/mailman/listinfo/freetds >> > > > > -- > ?? ?????????, ??????? ????. > -- ?? ?????????, ??????? ????. From velichko.yuriy at gmail.com Mon Apr 18 06:09:01 2016 From: velichko.yuriy at gmail.com (Velichko Yuriy) Date: Mon, 18 Apr 2016 13:09:01 +0300 Subject: [freetds] Conversion emoji symbols to UTF-8 In-Reply-To: References: Message-ID: With version 0.95.91 all works fine. looks like this issue was fixed earlier. Btw, when approximate date of release 1.0? Regards. On 18 April 2016 at 10:05, Velichko Yuriy wrote: > Ok, I will update freetds and tell you result. > > On 18 April 2016 at 00:19, Frediano Ziglio wrote: > >> Looks like an encoding bug. Time ago I fixed a similar issue. >> Could be you don't have this fix. >> >> Frediano >> On 17 Apr 2016 20:20, "Velichko Yuriy" wrote: >> >> > Here some examples of query result: >> > >> > SELECT N'?' >> > dbdatlen() == 4 >> > "\x00\xFF\x91\x8D" >> > >> > SELECT N'???? ? test' >> > dbdatlen() == 18 >> > "\xD1\x82\xD0\xB5\xD1\x81\xD1\x82 \x00\xFF\x91\x8D test" >> > >> > To store data and show it in UI I use Qt: >> > QString::fromUtf8(); >> > >> > >> > On 17 April 2016 at 20:24, Frediano Ziglio wrote: >> > >> > > Can you post a small dump? >> > > >> > > You could try a simple query like >> > > >> > > SELECT N'hello some emoticons' >> > > >> > > Frediano >> > > >> > > 2016-04-17 13:19 GMT+01:00 Velichko Yuriy : >> > > > 1 Data stored correctly because, for example SMSS shows emoji as >> > expected >> > > > 2 I use static db-lib >> > > > 3 Other unicode text is shown correctly >> > > > >> > > > On 17 April 2016 at 15:05, Frediano Ziglio >> wrote: >> > > > >> > > >> On 17 Apr 2016 12:59, "Velichko Yuriy" >> > > wrote: >> > > >> > >> > > >> > I use UTF-8 charset according to docs: >> > > >> > >> > > >> > http://www.freetds.org/userguide/unicodefreetds.htm >> > > >> > >> > > >> > My .conf includes next rows: >> > > >> > >> > > >> > tds version = 7.0 >> > > >> > client charset = UTF-8 >> > > >> > >> > > >> > All worked as expected until the emoji symbol appeared in the >> data >> > > >> string. >> > > >> > >> > > >> > In result I got ??? symbols. >> > > >> > >> > > >> >> > > >> Data in the database are stored correctly? >> > > >> >> > > >> > If to try example from answer in this post (all string is emoji) >> > the >> > > >> > returned data from method dbdata() will be an empty string with >> non >> > > zero >> > > >> > lenght (about 60 for example). >> > > >> > >> > > >> > Here I have read >> > > >> > http://www.freetds.org/userguide/localization.htm >> > > >> > that not all symbols can be converted properly. Looks like this >> is >> > my >> > > >> case. >> > > >> > >> > > >> > But maybe some one faced with this problem and solved it with >> > FreeTDS? >> > > >> > Because using emoji is not rare case in our time. >> > > >> > >> > > >> > Maybe need to use another encoding, or something else? >> > > >> > >> > > >> > Thanks! >> > > >> > >> > > >> >> > > >> Are you using iconv correctly? Don't expect to work without it. >> > > >> Which library are you using? >> > > >> Does the output work correctly with utf8? >> > > >> >> > > >> 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 Mon Apr 18 06:16:36 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Mon, 18 Apr 2016 11:16:36 +0100 Subject: [freetds] Conversion emoji symbols to UTF-8 In-Reply-To: References: Message-ID: 2016-04-18 11:09 GMT+01:00 Velichko Yuriy : > With version 0.95.91 all works fine. looks like this issue was fixed > earlier. > > Btw, when approximate date of release 1.0? > As usual... when ready :-) I don't expect much RCs for 1.0. Usually for safety I wait at least some weeks from last RC-released fix. Frediano > Regards. > > On 18 April 2016 at 10:05, Velichko Yuriy wrote: > >> Ok, I will update freetds and tell you result. >> >> On 18 April 2016 at 00:19, Frediano Ziglio wrote: >> >>> Looks like an encoding bug. Time ago I fixed a similar issue. >>> Could be you don't have this fix. >>> >>> Frediano >>> On 17 Apr 2016 20:20, "Velichko Yuriy" wrote: >>> >>> > Here some examples of query result: >>> > >>> > SELECT N'?' >>> > dbdatlen() == 4 >>> > "\x00\xFF\x91\x8D" >>> > >>> > SELECT N'???? ? test' >>> > dbdatlen() == 18 >>> > "\xD1\x82\xD0\xB5\xD1\x81\xD1\x82 \x00\xFF\x91\x8D test" >>> > >>> > To store data and show it in UI I use Qt: >>> > QString::fromUtf8(); >>> > >>> > >>> > On 17 April 2016 at 20:24, Frediano Ziglio wrote: >>> > >>> > > Can you post a small dump? >>> > > >>> > > You could try a simple query like >>> > > >>> > > SELECT N'hello some emoticons' >>> > > >>> > > Frediano >>> > > >>> > > 2016-04-17 13:19 GMT+01:00 Velichko Yuriy : >>> > > > 1 Data stored correctly because, for example SMSS shows emoji as >>> > expected >>> > > > 2 I use static db-lib >>> > > > 3 Other unicode text is shown correctly >>> > > > >>> > > > On 17 April 2016 at 15:05, Frediano Ziglio >>> wrote: >>> > > > >>> > > >> On 17 Apr 2016 12:59, "Velichko Yuriy" >>> > > wrote: >>> > > >> > >>> > > >> > I use UTF-8 charset according to docs: >>> > > >> > >>> > > >> > http://www.freetds.org/userguide/unicodefreetds.htm >>> > > >> > >>> > > >> > My .conf includes next rows: >>> > > >> > >>> > > >> > tds version = 7.0 >>> > > >> > client charset = UTF-8 >>> > > >> > >>> > > >> > All worked as expected until the emoji symbol appeared in the >>> data >>> > > >> string. >>> > > >> > >>> > > >> > In result I got ??? symbols. >>> > > >> > >>> > > >> >>> > > >> Data in the database are stored correctly? >>> > > >> >>> > > >> > If to try example from answer in this post (all string is emoji) >>> > the >>> > > >> > returned data from method dbdata() will be an empty string with >>> non >>> > > zero >>> > > >> > lenght (about 60 for example). >>> > > >> > >>> > > >> > Here I have read >>> > > >> > http://www.freetds.org/userguide/localization.htm >>> > > >> > that not all symbols can be converted properly. Looks like this >>> is >>> > my >>> > > >> case. >>> > > >> > >>> > > >> > But maybe some one faced with this problem and solved it with >>> > FreeTDS? >>> > > >> > Because using emoji is not rare case in our time. >>> > > >> > >>> > > >> > Maybe need to use another encoding, or something else? >>> > > >> > >>> > > >> > Thanks! >>> > > >> > >>> > > >> >>> > > >> Are you using iconv correctly? Don't expect to work without it. >>> > > >> Which library are you using? >>> > > >> Does the output work correctly with utf8? >>> > > >> >>> > > >> 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 >>> >> >> >> >> -- >> ? ?????????, ??????? ????. >> > > > > -- > ? ?????????, ??????? ????. > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From velichko.yuriy at gmail.com Mon Apr 18 06:25:22 2016 From: velichko.yuriy at gmail.com (Velichko Yuriy) Date: Mon, 18 Apr 2016 13:25:22 +0300 Subject: [freetds] Conversion emoji symbols to UTF-8 In-Reply-To: References: Message-ID: Ok, thanks again! On 18 April 2016 at 13:16, Frediano Ziglio wrote: > 2016-04-18 11:09 GMT+01:00 Velichko Yuriy : > > With version 0.95.91 all works fine. looks like this issue was fixed > > earlier. > > > > Btw, when approximate date of release 1.0? > > > > As usual... when ready :-) > > I don't expect much RCs for 1.0. Usually for safety I wait at least > some weeks from last RC-released fix. > > Frediano > > > Regards. > > > > On 18 April 2016 at 10:05, Velichko Yuriy > wrote: > > > >> Ok, I will update freetds and tell you result. > >> > >> On 18 April 2016 at 00:19, Frediano Ziglio wrote: > >> > >>> Looks like an encoding bug. Time ago I fixed a similar issue. > >>> Could be you don't have this fix. > >>> > >>> Frediano > >>> On 17 Apr 2016 20:20, "Velichko Yuriy" > wrote: > >>> > >>> > Here some examples of query result: > >>> > > >>> > SELECT N'?' > >>> > dbdatlen() == 4 > >>> > "\x00\xFF\x91\x8D" > >>> > > >>> > SELECT N'???? ? test' > >>> > dbdatlen() == 18 > >>> > "\xD1\x82\xD0\xB5\xD1\x81\xD1\x82 \x00\xFF\x91\x8D test" > >>> > > >>> > To store data and show it in UI I use Qt: > >>> > QString::fromUtf8(); > >>> > > >>> > > >>> > On 17 April 2016 at 20:24, Frediano Ziglio > wrote: > >>> > > >>> > > Can you post a small dump? > >>> > > > >>> > > You could try a simple query like > >>> > > > >>> > > SELECT N'hello some emoticons' > >>> > > > >>> > > Frediano > >>> > > > >>> > > 2016-04-17 13:19 GMT+01:00 Velichko Yuriy < > velichko.yuriy at gmail.com>: > >>> > > > 1 Data stored correctly because, for example SMSS shows emoji as > >>> > expected > >>> > > > 2 I use static db-lib > >>> > > > 3 Other unicode text is shown correctly > >>> > > > > >>> > > > On 17 April 2016 at 15:05, Frediano Ziglio > >>> wrote: > >>> > > > > >>> > > >> On 17 Apr 2016 12:59, "Velichko Yuriy" < > velichko.yuriy at gmail.com> > >>> > > wrote: > >>> > > >> > > >>> > > >> > I use UTF-8 charset according to docs: > >>> > > >> > > >>> > > >> > http://www.freetds.org/userguide/unicodefreetds.htm > >>> > > >> > > >>> > > >> > My .conf includes next rows: > >>> > > >> > > >>> > > >> > tds version = 7.0 > >>> > > >> > client charset = UTF-8 > >>> > > >> > > >>> > > >> > All worked as expected until the emoji symbol appeared in the > >>> data > >>> > > >> string. > >>> > > >> > > >>> > > >> > In result I got ??? symbols. > >>> > > >> > > >>> > > >> > >>> > > >> Data in the database are stored correctly? > >>> > > >> > >>> > > >> > If to try example from answer in this post (all string is > emoji) > >>> > the > >>> > > >> > returned data from method dbdata() will be an empty string > with > >>> non > >>> > > zero > >>> > > >> > lenght (about 60 for example). > >>> > > >> > > >>> > > >> > Here I have read > >>> > > >> > http://www.freetds.org/userguide/localization.htm > >>> > > >> > that not all symbols can be converted properly. Looks like > this > >>> is > >>> > my > >>> > > >> case. > >>> > > >> > > >>> > > >> > But maybe some one faced with this problem and solved it with > >>> > FreeTDS? > >>> > > >> > Because using emoji is not rare case in our time. > >>> > > >> > > >>> > > >> > Maybe need to use another encoding, or something else? > >>> > > >> > > >>> > > >> > Thanks! > >>> > > >> > > >>> > > >> > >>> > > >> Are you using iconv correctly? Don't expect to work without it. > >>> > > >> Which library are you using? > >>> > > >> Does the output work correctly with utf8? > >>> > > >> > >>> > > >> 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 > >>> > >> > >> > >> > >> -- > >> ? ?????????, ??????? ????. > >> > > > > > > > > -- > > ? ?????????, ??????? ????. > > _______________________________________________ > > FreeTDS mailing list > > FreeTDS at lists.ibiblio.org > > http://lists.ibiblio.org/mailman/listinfo/freetds > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > -- ?? ?????????, ??????? ????. From freddy77 at gmail.com Mon Apr 18 06:34:11 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Mon, 18 Apr 2016 11:34:11 +0100 Subject: [freetds] Need help with build on Windows In-Reply-To: References: Message-ID: 2016-04-18 11:04 GMT+01:00 Velichko Yuriy : > I have tried to use db-lib.lib from AppVeyor archive and got same link > issues. > > So I went back to CMake + Visual Studio + Manual build > > And figure out that need to use replacements.lib too. > Yes, replacements was a library :-) > So if I link my application to > > db-lib.lib > tds.lib > replacements.lib > > the build performs without errors and all works fine. > > So there are few more question: > > 1 why replacements.lib is absent in AppVeyor archive Fixing this. Should be distributed. > 2 I have inherited project that uses SINGLE file db-lib.lib and all works. > But it size much bigger (2.5 Mb for x86). How it can be? may be old version > has such build output? libraries are like simple archive (ie zip files), you can put everything together. For some reason the library you used had everything inside (that's also a reason it was much bigger... or contained more debug information). > 3 It is correct approach to use 3 libs, or there is a way to get a single > file? > It's correct. And I prefer instead of having huge static library but self-contained. Frediano > Regards. > > On 15 April 2016 at 19:44, Velichko Yuriy wrote: > >> Thanks Alot!!! >> >> Btw, I think you can include this answer into FreeTDS docs, because it can >> be helpful to users. >> >> >> >> On 15 April 2016 at 18:52, Ramiro Morales wrote: >> >>> On Fri, Apr 15, 2016 at 10:29 AM, Velichko Yuriy < >>> velichko.yuriy at gmail.com> >>> wrote: >>> >>> > Hello! >>> > >>> > I've downloaded the latest version of FreeTDS, configured and builded >>> it >>> > with CMake and Visual Studio 2013. >>> > >>> > I need to use only db-lib as a static library. >>> > So I copied it to the project and linked with it. >>> > >>> > But on building the project I have got link errors like this: >>> > >>> > : unresolved external symbol _tdsdump_open referenced in function >>> > _tdsdbopen >>> > C:\.......\db-lib.lib(dblib.obj) >>> > >>> > I can't find out how to fix this issue. >>> > Help me please! ) >>> > >>> > Thanks! >>> > >>> >>> >>> You can download FreeTDS binaries for Windows from AppVeyor (the hosted >>> CI >>> platform used). >>> >>> There is a .zip file available as artifact of every sucessful build. >>> >>> The list of builds: >>> https://ci.appveyor.com/project/FreeTDS/freetds/history >>> >>> You can find there builds of code in the master banch and (from time to >>> time) builds from the post-0.95 release fixes-only Branch-0_95 branch. >>> >>> A recent sucessful build: >>> https://ci.appveyor.com/project/FreeTDS/freetds/build/448 >>> >>> Every build matrix element generates its artifact. e.g. for x86_64 builds >>> with Visual Studio 2015: >>> >>> https://ci.appveyor.com/project/FreeTDS/freetds/build/448/job/5a8osy4ey1bqir03 >>> and the resulting zip file: >>> >>> https://ci.appveyor.com/project/FreeTDS/freetds/build/448/job/5a8osy4ey1bqir03/artifacts >>> >>> I also maintain similar builds of the Branch-0_95 branch at >>> https://github.com/ramiro/freetds/releases >>> >>> If you don't want or can't use binaries built by third parties then the >>> appveyor.yml file and associated files (find them on the source tree) can >>> be of help as a source of information and experience to avoid common >>> pitfalls/pain points when building FreeTDS on Windows. >>> >>> HTH >>> >>> >>> -- >>> Ramiro Morales >>> @ramiromorales >>> _______________________________________________ >>> 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 velichko.yuriy at gmail.com Mon Apr 18 06:41:36 2016 From: velichko.yuriy at gmail.com (Velichko Yuriy) Date: Mon, 18 Apr 2016 13:41:36 +0300 Subject: [freetds] Need help with build on Windows In-Reply-To: References: Message-ID: Ok, thanks for help! On 18 April 2016 at 13:34, Frediano Ziglio wrote: > 2016-04-18 11:04 GMT+01:00 Velichko Yuriy : > > I have tried to use db-lib.lib from AppVeyor archive and got same link > > issues. > > > > So I went back to CMake + Visual Studio + Manual build > > > > And figure out that need to use replacements.lib too. > > > > Yes, replacements was a library :-) > > > So if I link my application to > > > > db-lib.lib > > tds.lib > > replacements.lib > > > > the build performs without errors and all works fine. > > > > So there are few more question: > > > > 1 why replacements.lib is absent in AppVeyor archive > > Fixing this. Should be distributed. > > > 2 I have inherited project that uses SINGLE file db-lib.lib and all > works. > > But it size much bigger (2.5 Mb for x86). How it can be? may be old > version > > has such build output? > > libraries are like simple archive (ie zip files), you can put > everything together. > For some reason the library you used had everything inside (that's also > a reason it was much bigger... or contained more debug information). > > > 3 It is correct approach to use 3 libs, or there is a way to get a single > > file? > > > > It's correct. And I prefer instead of having huge static library but > self-contained. > > Frediano > > > Regards. > > > > On 15 April 2016 at 19:44, Velichko Yuriy > wrote: > > > >> Thanks Alot!!! > >> > >> Btw, I think you can include this answer into FreeTDS docs, because it > can > >> be helpful to users. > >> > >> > >> > >> On 15 April 2016 at 18:52, Ramiro Morales wrote: > >> > >>> On Fri, Apr 15, 2016 at 10:29 AM, Velichko Yuriy < > >>> velichko.yuriy at gmail.com> > >>> wrote: > >>> > >>> > Hello! > >>> > > >>> > I've downloaded the latest version of FreeTDS, configured and builded > >>> it > >>> > with CMake and Visual Studio 2013. > >>> > > >>> > I need to use only db-lib as a static library. > >>> > So I copied it to the project and linked with it. > >>> > > >>> > But on building the project I have got link errors like this: > >>> > > >>> > : unresolved external symbol _tdsdump_open referenced in function > >>> > _tdsdbopen > >>> > C:\.......\db-lib.lib(dblib.obj) > >>> > > >>> > I can't find out how to fix this issue. > >>> > Help me please! ) > >>> > > >>> > Thanks! > >>> > > >>> > >>> > >>> You can download FreeTDS binaries for Windows from AppVeyor (the > hosted > >>> CI > >>> platform used). > >>> > >>> There is a .zip file available as artifact of every sucessful build. > >>> > >>> The list of builds: > >>> https://ci.appveyor.com/project/FreeTDS/freetds/history > >>> > >>> You can find there builds of code in the master banch and (from time to > >>> time) builds from the post-0.95 release fixes-only Branch-0_95 branch. > >>> > >>> A recent sucessful build: > >>> https://ci.appveyor.com/project/FreeTDS/freetds/build/448 > >>> > >>> Every build matrix element generates its artifact. e.g. for x86_64 > builds > >>> with Visual Studio 2015: > >>> > >>> > https://ci.appveyor.com/project/FreeTDS/freetds/build/448/job/5a8osy4ey1bqir03 > >>> and the resulting zip file: > >>> > >>> > https://ci.appveyor.com/project/FreeTDS/freetds/build/448/job/5a8osy4ey1bqir03/artifacts > >>> > >>> I also maintain similar builds of the Branch-0_95 branch at > >>> https://github.com/ramiro/freetds/releases > >>> > >>> If you don't want or can't use binaries built by third parties then the > >>> appveyor.yml file and associated files (find them on the source tree) > can > >>> be of help as a source of information and experience to avoid common > >>> pitfalls/pain points when building FreeTDS on Windows. > >>> > >>> HTH > >>> > >>> > >>> -- > >>> Ramiro Morales > >>> @ramiromorales > >>> _______________________________________________ > >>> 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 velichko.yuriy at gmail.com Mon Apr 18 11:42:18 2016 From: velichko.yuriy at gmail.com (Velichko Yuriy) Date: Mon, 18 Apr 2016 18:42:18 +0300 Subject: [freetds] Need help with build on Windows In-Reply-To: References: Message-ID: One moe issue. Now for build on mac. I build FreeTds for MacOS with: ./configure make make install Than take lib to my project and get link error Undefined symbols for architecture x86_64: "___strlcpy_chk", referenced from: _tdsdbopen in libsybdb_64.a(dblib.o) _db_env_chg in libsybdb_64.a(dblib.o) _dbcolinfo in libsybdb_64.a(dblib.o) _dbtablecolinfo in libsybdb_64.a(dblib.o) _tds_alloc_dynamic in libsybdb_64.a(mem.o) _tds7_get_instance_port in libsybdb_64.a(net.o) _tds_get_locale in libsybdb_64.a(locale.o) ... ?Any ideas? Because I can't find ?this method in sources. On 18 April 2016 at 13:41, Velichko Yuriy wrote: > Ok, thanks for help! > > On 18 April 2016 at 13:34, Frediano Ziglio wrote: > >> 2016-04-18 11:04 GMT+01:00 Velichko Yuriy : >> > I have tried to use db-lib.lib from AppVeyor archive and got same link >> > issues. >> > >> > So I went back to CMake + Visual Studio + Manual build >> > >> > And figure out that need to use replacements.lib too. >> > >> >> Yes, replacements was a library :-) >> >> > So if I link my application to >> > >> > db-lib.lib >> > tds.lib >> > replacements.lib >> > >> > the build performs without errors and all works fine. >> > >> > So there are few more question: >> > >> > 1 why replacements.lib is absent in AppVeyor archive >> >> Fixing this. Should be distributed. >> >> > 2 I have inherited project that uses SINGLE file db-lib.lib and all >> works. >> > But it size much bigger (2.5 Mb for x86). How it can be? may be old >> version >> > has such build output? >> >> libraries are like simple archive (ie zip files), you can put >> everything together. >> For some reason the library you used had everything inside (that's also >> a reason it was much bigger... or contained more debug information). >> >> > 3 It is correct approach to use 3 libs, or there is a way to get a >> single >> > file? >> > >> >> It's correct. And I prefer instead of having huge static library but >> self-contained. >> >> Frediano >> >> > Regards. >> > >> > On 15 April 2016 at 19:44, Velichko Yuriy >> wrote: >> > >> >> Thanks Alot!!! >> >> >> >> Btw, I think you can include this answer into FreeTDS docs, because it >> can >> >> be helpful to users. >> >> >> >> >> >> >> >> On 15 April 2016 at 18:52, Ramiro Morales wrote: >> >> >> >>> On Fri, Apr 15, 2016 at 10:29 AM, Velichko Yuriy < >> >>> velichko.yuriy at gmail.com> >> >>> wrote: >> >>> >> >>> > Hello! >> >>> > >> >>> > I've downloaded the latest version of FreeTDS, configured and >> builded >> >>> it >> >>> > with CMake and Visual Studio 2013. >> >>> > >> >>> > I need to use only db-lib as a static library. >> >>> > So I copied it to the project and linked with it. >> >>> > >> >>> > But on building the project I have got link errors like this: >> >>> > >> >>> > : unresolved external symbol _tdsdump_open referenced in function >> >>> > _tdsdbopen >> >>> > C:\.......\db-lib.lib(dblib.obj) >> >>> > >> >>> > I can't find out how to fix this issue. >> >>> > Help me please! ) >> >>> > >> >>> > Thanks! >> >>> > >> >>> >> >>> >> >>> You can download FreeTDS binaries for Windows from AppVeyor (the >> hosted >> >>> CI >> >>> platform used). >> >>> >> >>> There is a .zip file available as artifact of every sucessful build. >> >>> >> >>> The list of builds: >> >>> https://ci.appveyor.com/project/FreeTDS/freetds/history >> >>> >> >>> You can find there builds of code in the master banch and (from time >> to >> >>> time) builds from the post-0.95 release fixes-only Branch-0_95 branch. >> >>> >> >>> A recent sucessful build: >> >>> https://ci.appveyor.com/project/FreeTDS/freetds/build/448 >> >>> >> >>> Every build matrix element generates its artifact. e.g. for x86_64 >> builds >> >>> with Visual Studio 2015: >> >>> >> >>> >> https://ci.appveyor.com/project/FreeTDS/freetds/build/448/job/5a8osy4ey1bqir03 >> >>> and the resulting zip file: >> >>> >> >>> >> https://ci.appveyor.com/project/FreeTDS/freetds/build/448/job/5a8osy4ey1bqir03/artifacts >> >>> >> >>> I also maintain similar builds of the Branch-0_95 branch at >> >>> https://github.com/ramiro/freetds/releases >> >>> >> >>> If you don't want or can't use binaries built by third parties then >> the >> >>> appveyor.yml file and associated files (find them on the source tree) >> can >> >>> be of help as a source of information and experience to avoid common >> >>> pitfalls/pain points when building FreeTDS on Windows. >> >>> >> >>> HTH >> >>> >> >>> >> >>> -- >> >>> Ramiro Morales >> >>> @ramiromorales >> >>> _______________________________________________ >> >>> 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 jan.blom at peopleinteractive.se Mon Apr 18 12:56:47 2016 From: jan.blom at peopleinteractive.se (Jan Blom) Date: Mon, 18 Apr 2016 16:56:47 +0000 Subject: [freetds] Multiple connection retries to the same IP address Message-ID: Hello, I'm using FreeTDS 0.95 and have been puzzled why the connection timeout setting seemed not to work. Digging into the problem I notice the same target IP address always appear three times, for instance looking at the config dump from osql. I have provided the fqdn name for the host in freetds.conf. The FreeTDS implementation will loop over all IP addresses when trying to connect if there is a failure. This results in a 3x total timeout duration compared to the configuration. I cannot see a good reason for this logic, given it is the same IP address in all three attempts. The reason is that the call to getaddrinfo (in tds/config.c) doesn't send in any preference regarding address type. Therefore we get back something like this: 1. Family : AF_INET Type : SOCK_STREAM Protocol : IPPROTO_TCP Socket address: ('23.235.43.223', 0) 2. Family : AF_INET Type : SOCK_DGRAM Protocol : IPPROTO_UDP Socket address: ('23.235.43.223', 0) 3. Family : AF_INET Type : SOCK_RAW Protocol : IPPROTO_IP Socket address: ('23.235.43.223', 0) However, later on , when we actually connect the socket we will use SOCK_STREAM only. We don't care about UDP or raw sockets. My assumption would be that the tds_lookup_host() function should set hints.ai_socktype = SOCK_STREAM; This will result in only #1 above in return. Does this make sense or am I missing something here? Thanks for your time and support! Jan Blom From freddy77 at gmail.com Mon Apr 18 13:59:38 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Mon, 18 Apr 2016 18:59:38 +0100 Subject: [freetds] Multiple connection retries to the same IP address In-Reply-To: References: Message-ID: 2016-04-18 17:56 GMT+01:00 Jan Blom : > Hello, > > I'm using FreeTDS 0.95 and have been puzzled why the connection timeout setting seemed not to work. Digging into the problem I notice the same target IP address always appear three times, for instance looking at the config dump from osql. I have provided the fqdn name for the host in freetds.conf. > > The FreeTDS implementation will loop over all IP addresses when trying to connect if there is a failure. This results in a 3x total timeout duration compared to the configuration. I cannot see a good reason for this logic, given it is the same IP address in all three attempts. > > The reason is that the call to getaddrinfo (in tds/config.c) doesn't send in any preference regarding address type. Therefore we get back something like this: > > 1. > Family : AF_INET > Type : SOCK_STREAM > Protocol : IPPROTO_TCP > Socket address: ('23.235.43.223', 0) > > 2. > Family : AF_INET > Type : SOCK_DGRAM > Protocol : IPPROTO_UDP > Socket address: ('23.235.43.223', 0) > > 3. > Family : AF_INET > Type : SOCK_RAW > Protocol : IPPROTO_IP > Socket address: ('23.235.43.223', 0) > > However, later on , when we actually connect the socket we will use SOCK_STREAM only. We don't care about UDP or raw sockets. > > My assumption would be that the tds_lookup_host() function should set > hints.ai_socktype = SOCK_STREAM; > > This will result in only #1 above in return. > > Does this make sense or am I missing something here? > > > Thanks for your time and support! > Jan Blom > Make sense. It's just that the change was quite recent, previously we took into account just the first address so we didn't had this issue. I think your suggestion should go as a patch. Frediano From freddy77 at gmail.com Mon Apr 18 14:02:28 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Mon, 18 Apr 2016 19:02:28 +0100 Subject: [freetds] Need help with build on Windows In-Reply-To: References: Message-ID: Weird. Mac OS X defines strlcpy using __strlcpy_chk which should be a system function so should be contained in the standard .dylibs. Looks like linker is not picking up standard libraries. Frediano 2016-04-18 16:42 GMT+01:00 Velichko Yuriy : > One moe issue. > Now for build on mac. > > I build FreeTds for MacOS with: > > ./configure > make > make install > > Than take lib to my project and get link error > > Undefined symbols for architecture x86_64: > > "___strlcpy_chk", referenced from: > _tdsdbopen in libsybdb_64.a(dblib.o) > _db_env_chg in libsybdb_64.a(dblib.o) > _dbcolinfo in libsybdb_64.a(dblib.o) > _dbtablecolinfo in libsybdb_64.a(dblib.o) > _tds_alloc_dynamic in libsybdb_64.a(mem.o) > _tds7_get_instance_port in libsybdb_64.a(net.o) > _tds_get_locale in libsybdb_64.a(locale.o) > ... > > Any ideas? Because I can't find this method in sources. > > > On 18 April 2016 at 13:41, Velichko Yuriy wrote: > >> Ok, thanks for help! >> >> On 18 April 2016 at 13:34, Frediano Ziglio wrote: >> >>> 2016-04-18 11:04 GMT+01:00 Velichko Yuriy : >>> > I have tried to use db-lib.lib from AppVeyor archive and got same link >>> > issues. >>> > >>> > So I went back to CMake + Visual Studio + Manual build >>> > >>> > And figure out that need to use replacements.lib too. >>> > >>> >>> Yes, replacements was a library :-) >>> >>> > So if I link my application to >>> > >>> > db-lib.lib >>> > tds.lib >>> > replacements.lib >>> > >>> > the build performs without errors and all works fine. >>> > >>> > So there are few more question: >>> > >>> > 1 why replacements.lib is absent in AppVeyor archive >>> >>> Fixing this. Should be distributed. >>> >>> > 2 I have inherited project that uses SINGLE file db-lib.lib and all >>> works. >>> > But it size much bigger (2.5 Mb for x86). How it can be? may be old >>> version >>> > has such build output? >>> >>> libraries are like simple archive (ie zip files), you can put >>> everything together. >>> For some reason the library you used had everything inside (that's also >>> a reason it was much bigger... or contained more debug information). >>> >>> > 3 It is correct approach to use 3 libs, or there is a way to get a >>> single >>> > file? >>> > >>> >>> It's correct. And I prefer instead of having huge static library but >>> self-contained. >>> >>> Frediano >>> >>> > Regards. >>> > >>> > On 15 April 2016 at 19:44, Velichko Yuriy >>> wrote: >>> > >>> >> Thanks Alot!!! >>> >> >>> >> Btw, I think you can include this answer into FreeTDS docs, because it >>> can >>> >> be helpful to users. >>> >> >>> >> >>> >> >>> >> On 15 April 2016 at 18:52, Ramiro Morales wrote: >>> >> >>> >>> On Fri, Apr 15, 2016 at 10:29 AM, Velichko Yuriy < >>> >>> velichko.yuriy at gmail.com> >>> >>> wrote: >>> >>> >>> >>> > Hello! >>> >>> > >>> >>> > I've downloaded the latest version of FreeTDS, configured and >>> builded >>> >>> it >>> >>> > with CMake and Visual Studio 2013. >>> >>> > >>> >>> > I need to use only db-lib as a static library. >>> >>> > So I copied it to the project and linked with it. >>> >>> > >>> >>> > But on building the project I have got link errors like this: >>> >>> > >>> >>> > : unresolved external symbol _tdsdump_open referenced in function >>> >>> > _tdsdbopen >>> >>> > C:\.......\db-lib.lib(dblib.obj) >>> >>> > >>> >>> > I can't find out how to fix this issue. >>> >>> > Help me please! ) >>> >>> > >>> >>> > Thanks! >>> >>> > >>> >>> >>> >>> >>> >>> You can download FreeTDS binaries for Windows from AppVeyor (the >>> hosted >>> >>> CI >>> >>> platform used). >>> >>> >>> >>> There is a .zip file available as artifact of every sucessful build. >>> >>> >>> >>> The list of builds: >>> >>> https://ci.appveyor.com/project/FreeTDS/freetds/history >>> >>> >>> >>> You can find there builds of code in the master banch and (from time >>> to >>> >>> time) builds from the post-0.95 release fixes-only Branch-0_95 branch. >>> >>> >>> >>> A recent sucessful build: >>> >>> https://ci.appveyor.com/project/FreeTDS/freetds/build/448 >>> >>> >>> >>> Every build matrix element generates its artifact. e.g. for x86_64 >>> builds >>> >>> with Visual Studio 2015: >>> >>> >>> >>> >>> https://ci.appveyor.com/project/FreeTDS/freetds/build/448/job/5a8osy4ey1bqir03 >>> >>> and the resulting zip file: >>> >>> >>> >>> >>> https://ci.appveyor.com/project/FreeTDS/freetds/build/448/job/5a8osy4ey1bqir03/artifacts >>> >>> >>> >>> I also maintain similar builds of the Branch-0_95 branch at >>> >>> https://github.com/ramiro/freetds/releases >>> >>> >>> >>> If you don't want or can't use binaries built by third parties then >>> the >>> >>> appveyor.yml file and associated files (find them on the source tree) >>> can >>> >>> be of help as a source of information and experience to avoid common >>> >>> pitfalls/pain points when building FreeTDS on Windows. >>> >>> >>> >>> HTH >>> >>> >>> >>> >>> >>> -- >>> >>> Ramiro Morales >>> >>> @ramiromorales >>> >>> _______________________________________________ >>> >>> 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 cyreve at gmail.com Mon Apr 18 14:02:21 2016 From: cyreve at gmail.com (Richard Hughes) Date: Mon, 18 Apr 2016 19:02:21 +0100 Subject: [freetds] FreeTDS 1.0 Release Candidate 1 is out! In-Reply-To: References: Message-ID: <20160418190221.000017d8@gmail.com> On Sun, 17 Apr 2016 19:37:41 +0100, Frediano Ziglio wrote: > - ODBC BCP support; On that subject, I found a couple of bugs in my code - fixes are in the attached. Sorry for being so late giving them to you. Note that I haven't tested the change to src/dblib/bcp.c - it just looked like the right thing to do. Richard. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-fix-bugs-in-ODBC-BCP-and-augment-unit-tests-accordin.patch Type: application/octet-stream Size: 7948 bytes Desc: not available URL: From jan.blom at peopleinteractive.se Mon Apr 18 15:23:03 2016 From: jan.blom at peopleinteractive.se (Jan Blom) Date: Mon, 18 Apr 2016 19:23:03 +0000 Subject: [freetds] Multiple connection retries to the same IP address In-Reply-To: References: Message-ID: Excellent! Anything more I need to do? Best regards, Jan -----Original Message----- From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of Frediano Ziglio Sent: den 18 april 2016 20:00 To: FreeTDS Development Group Subject: Re: [freetds] Multiple connection retries to the same IP address 2016-04-18 17:56 GMT+01:00 Jan Blom : > Hello, > > I'm using FreeTDS 0.95 and have been puzzled why the connection timeout setting seemed not to work. Digging into the problem I notice the same target IP address always appear three times, for instance looking at the config dump from osql. I have provided the fqdn name for the host in freetds.conf. > > The FreeTDS implementation will loop over all IP addresses when trying to connect if there is a failure. This results in a 3x total timeout duration compared to the configuration. I cannot see a good reason for this logic, given it is the same IP address in all three attempts. > > The reason is that the call to getaddrinfo (in tds/config.c) doesn't send in any preference regarding address type. Therefore we get back something like this: > > 1. > Family : AF_INET > Type : SOCK_STREAM > Protocol : IPPROTO_TCP > Socket address: ('23.235.43.223', 0) > > 2. > Family : AF_INET > Type : SOCK_DGRAM > Protocol : IPPROTO_UDP > Socket address: ('23.235.43.223', 0) > > 3. > Family : AF_INET > Type : SOCK_RAW > Protocol : IPPROTO_IP > Socket address: ('23.235.43.223', 0) > > However, later on , when we actually connect the socket we will use SOCK_STREAM only. We don't care about UDP or raw sockets. > > My assumption would be that the tds_lookup_host() function should set > hints.ai_socktype = SOCK_STREAM; > > This will result in only #1 above in return. > > Does this make sense or am I missing something here? > > > Thanks for your time and support! > Jan Blom > Make sense. It's just that the change was quite recent, previously we took into account just the first address so we didn't had this issue. I think your suggestion should go as a patch. Frediano _______________________________________________ FreeTDS mailing list FreeTDS at lists.ibiblio.org http://lists.ibiblio.org/mailman/listinfo/freetds From freddy77 at gmail.com Mon Apr 18 15:54:12 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Mon, 18 Apr 2016 20:54:12 +0100 Subject: [freetds] Multiple connection retries to the same IP address In-Reply-To: References: Message-ID: Well, if you want you can test it works as expected for you :) Already pushed the patch. Frediano 2016-04-18 20:23 GMT+01:00 Jan Blom : > Excellent! Anything more I need to do? > > > Best regards, > Jan > > -----Original Message----- > From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of Frediano Ziglio > Sent: den 18 april 2016 20:00 > To: FreeTDS Development Group > Subject: Re: [freetds] Multiple connection retries to the same IP address > > 2016-04-18 17:56 GMT+01:00 Jan Blom : >> Hello, >> >> I'm using FreeTDS 0.95 and have been puzzled why the connection timeout setting seemed not to work. Digging into the problem I notice the same target IP address always appear three times, for instance looking at the config dump from osql. I have provided the fqdn name for the host in freetds.conf. >> >> The FreeTDS implementation will loop over all IP addresses when trying to connect if there is a failure. This results in a 3x total timeout duration compared to the configuration. I cannot see a good reason for this logic, given it is the same IP address in all three attempts. >> >> The reason is that the call to getaddrinfo (in tds/config.c) doesn't send in any preference regarding address type. Therefore we get back something like this: >> >> 1. >> Family : AF_INET >> Type : SOCK_STREAM >> Protocol : IPPROTO_TCP >> Socket address: ('23.235.43.223', 0) >> >> 2. >> Family : AF_INET >> Type : SOCK_DGRAM >> Protocol : IPPROTO_UDP >> Socket address: ('23.235.43.223', 0) >> >> 3. >> Family : AF_INET >> Type : SOCK_RAW >> Protocol : IPPROTO_IP >> Socket address: ('23.235.43.223', 0) >> >> However, later on , when we actually connect the socket we will use SOCK_STREAM only. We don't care about UDP or raw sockets. >> >> My assumption would be that the tds_lookup_host() function should set >> hints.ai_socktype = SOCK_STREAM; >> >> This will result in only #1 above in return. >> >> Does this make sense or am I missing something here? >> >> >> Thanks for your time and support! >> Jan Blom >> > > > Make sense. It's just that the change was quite recent, previously we took into account just the first address so we didn't had this issue. > I think your suggestion should go as a patch. > > 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 jan.blom at peopleinteractive.se Mon Apr 18 16:36:52 2016 From: jan.blom at peopleinteractive.se (Jan Blom) Date: Mon, 18 Apr 2016 20:36:52 +0000 Subject: [freetds] Patch to use configured connection timeout Message-ID: Hello, Using FreeTDS 0.95 in combination with unixODBC I notice that the connection timeout value configured in freetds.conf is never used when calling SQLDriverConnect. The attached patch makes us use the value from freetds.conf if we don't call SQLSetConnectAttr with SQL_ATTR_CONNECTION_TIMEOUT. The change is rather trivial. Let me know if you want me to produce a patch against head. Looking at the 1.0RC1 code it seems the issue is still present. Best regards, Jan Blom -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: connect_timeout_patch.txt URL: From fdsubs at t-online.hu Mon Apr 18 16:46:36 2016 From: fdsubs at t-online.hu (Daniel Fazekas) Date: Mon, 18 Apr 2016 22:46:36 +0200 Subject: [freetds] Conversion emoji symbols to UTF-8 In-Reply-To: References: Message-ID: <5707F4EA-3A99-426A-83FB-ECF468720627@t-online.hu> It is actually odd that merely upgrading solved that emoji issue. Emojis being largely in the Supplementary Multilingual Plane of Unicode require true UTF-16 support rather than the legacy UCS-2 encoding on the server communication side. In FreeTDS terms, that means that in addition to version 0.95+ you ought to include the following extra setting in your configuration file: use utf-16 = yes So a complete sample configuration would look something like tds version = 7.2 client charset = UTF-8 use utf-16 = yes Was it a Windows platform peculiarity that UTF-16 worked even with that required setting missing? In any case, I'd add that to your configuration just to be sure. It certaintly was necessary for me on Mac and Linux. > On Apr 18, 2016, at 12:09, Velichko Yuriy wrote: > > With version 0.95.91 all works fine. looks like this issue was fixed > earlier. > >>>>>>>> On 17 Apr 2016 12:59, "Velichko Yuriy" wrote: >>>>>>>> My .conf includes next rows: >>>>>>>> tds version = 7.0 >>>>>>>> client charset = UTF-8 From fdsubs at t-online.hu Mon Apr 18 17:22:50 2016 From: fdsubs at t-online.hu (Daniel Fazekas) Date: Mon, 18 Apr 2016 23:22:50 +0200 Subject: [freetds] Need help with build on Windows In-Reply-To: References: Message-ID: This looks like an issue of targeting mismatched OS releases by the different projects. Merely issuing "./configure" will by default target running on the current OS version or later, whereas the other project may be configured to target supporting an earlier release. The strlcpy ? __strlcpy_chk switcheroo took place between OS X 10.8 and OS X 10.9. So the other project could be set to target OS X 10.9 or newer, or FreeTDS rebuilt to target a matching older OS release. For example, CFLAGS="-mmacosx-version-min=10.8" ./configure make alternatively: export MACOSX_DEPLOYMENT_TARGET=10.8 ./configure make > On Apr 18, 2016, at 20:02, Frediano Ziglio wrote: > > Weird. Mac OS X defines strlcpy using __strlcpy_chk which should be a > system function so should be contained in the standard .dylibs. Looks > like linker is not picking up standard libraries. > > Frediano > > 2016-04-18 16:42 GMT+01:00 Velichko Yuriy : >> One moe issue. >> Now for build on mac. >> >> I build FreeTds for MacOS with: >> >> ./configure >> make >> make install >> >> Than take lib to my project and get link error >> >> Undefined symbols for architecture x86_64: >> >> "___strlcpy_chk", referenced from: >> _tdsdbopen in libsybdb_64.a(dblib.o) >> _db_env_chg in libsybdb_64.a(dblib.o) >> _dbcolinfo in libsybdb_64.a(dblib.o) >> _dbtablecolinfo in libsybdb_64.a(dblib.o) >> _tds_alloc_dynamic in libsybdb_64.a(mem.o) >> _tds7_get_instance_port in libsybdb_64.a(net.o) >> _tds_get_locale in libsybdb_64.a(locale.o) >> ... >> >> Any ideas? Because I can't find this method in sources. From freddy77 at gmail.com Tue Apr 19 06:26:27 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Tue, 19 Apr 2016 11:26:27 +0100 Subject: [freetds] Conversion emoji symbols to UTF-8 In-Reply-To: <5707F4EA-3A99-426A-83FB-ECF468720627@t-online.hu> References: <5707F4EA-3A99-426A-83FB-ECF468720627@t-online.hu> Message-ID: 2016-04-18 21:46 GMT+01:00 Daniel Fazekas : > It is actually odd that merely upgrading solved that emoji issue. > Emojis being largely in the Supplementary Multilingual Plane of Unicode require true UTF-16 support rather than the legacy UCS-2 encoding on the server communication side. > > In FreeTDS terms, that means that in addition to version 0.95+ you ought to include the following extra setting in your configuration file: > use utf-16 = yes > > So a complete sample configuration would look something like > tds version = 7.2 > client charset = UTF-8 > use utf-16 = yes > > Was it a Windows platform peculiarity that UTF-16 worked even with that required setting missing? This as replacements iconv use utf16 in place of ucs2. This however reminds me that "use utf-16" option default should be changed to 1 (true) for 1.0 version! I'm doing it right now. Frediano > In any case, I'd add that to your configuration just to be sure. > It certaintly was necessary for me on Mac and Linux. > >> On Apr 18, 2016, at 12:09, Velichko Yuriy wrote: >> >> With version 0.95.91 all works fine. looks like this issue was fixed >> earlier. >> >>>>>>>>> On 17 Apr 2016 12:59, "Velichko Yuriy" wrote: >>>>>>>>> My .conf includes next rows: >>>>>>>>> tds version = 7.0 >>>>>>>>> client charset = UTF-8 > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From freddy77 at gmail.com Tue Apr 19 06:35:05 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Tue, 19 Apr 2016 11:35:05 +0100 Subject: [freetds] Patch to use configured connection timeout In-Reply-To: References: Message-ID: Patch is good but for compatibility I prefer to apply only to 1.0 Frediano 2016-04-18 21:36 GMT+01:00 Jan Blom : > Hello, > > Using FreeTDS 0.95 in combination with unixODBC I notice that the connection timeout value configured in freetds.conf is never used when calling SQLDriverConnect. The attached patch makes us use the value from freetds.conf if we don't call SQLSetConnectAttr with SQL_ATTR_CONNECTION_TIMEOUT. > > The change is rather trivial. Let me know if you want me to produce a patch against head. Looking at the 1.0RC1 code it seems the issue is still present. > > > Best regards, > Jan Blom > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > From velichko.yuriy at gmail.com Tue Apr 19 06:53:00 2016 From: velichko.yuriy at gmail.com (Velichko Yuriy) Date: Tue, 19 Apr 2016 13:53:00 +0300 Subject: [freetds] Conversion emoji symbols to UTF-8 In-Reply-To: References: <5707F4EA-3A99-426A-83FB-ECF468720627@t-online.hu> Message-ID: Yes, without "use utf-16" symbols are broken. Set use utf-16 = yes and tds version = 7.2 fixes this problem on mac. If tds version = 7.0 - symbols are broken. On 19 April 2016 at 13:26, Frediano Ziglio wrote: > 2016-04-18 21:46 GMT+01:00 Daniel Fazekas : > > It is actually odd that merely upgrading solved that emoji issue. > > Emojis being largely in the Supplementary Multilingual Plane of Unicode > require true UTF-16 support rather than the legacy UCS-2 encoding on the > server communication side. > > > > In FreeTDS terms, that means that in addition to version 0.95+ you ought > to include the following extra setting in your configuration file: > > use utf-16 = yes > > > > So a complete sample configuration would look something like > > tds version = 7.2 > > client charset = UTF-8 > > use utf-16 = yes > > > > Was it a Windows platform peculiarity that UTF-16 worked even with that > required setting missing? > > This as replacements iconv use utf16 in place of ucs2. > This however reminds me that "use utf-16" option default should be > changed to 1 (true) for 1.0 version! > I'm doing it right now. > > Frediano > > > In any case, I'd add that to your configuration just to be sure. > > It certaintly was necessary for me on Mac and Linux. > > > >> On Apr 18, 2016, at 12:09, Velichko Yuriy > wrote: > >> > >> With version 0.95.91 all works fine. looks like this issue was fixed > >> earlier. > >> > >>>>>>>>> On 17 Apr 2016 12:59, "Velichko Yuriy" > wrote: > >>>>>>>>> My .conf includes next rows: > >>>>>>>>> tds version = 7.0 > >>>>>>>>> client charset = UTF-8 > > > > _______________________________________________ > > 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 velichko.yuriy at gmail.com Tue Apr 19 06:57:44 2016 From: velichko.yuriy at gmail.com (Velichko Yuriy) Date: Tue, 19 Apr 2016 13:57:44 +0300 Subject: [freetds] Need help with build on Windows In-Reply-To: References: Message-ID: Thanks! I figured out this fix few hours earlier, and had not time to respond here. On 19 April 2016 at 00:22, Daniel Fazekas wrote: > This looks like an issue of targeting mismatched OS releases by the > different projects. > Merely issuing "./configure" will by default target running on the current > OS version or later, whereas the other project may be configured to target > supporting an earlier release. > > The strlcpy ? __strlcpy_chk switcheroo took place between OS X 10.8 and OS > X 10.9. > So the other project could be set to target OS X 10.9 or newer, or FreeTDS > rebuilt to target a matching older OS release. > > For example, > CFLAGS="-mmacosx-version-min=10.8" ./configure > make > > alternatively: > > export MACOSX_DEPLOYMENT_TARGET=10.8 > ./configure > make > > > On Apr 18, 2016, at 20:02, Frediano Ziglio wrote: > > > > Weird. Mac OS X defines strlcpy using __strlcpy_chk which should be a > > system function so should be contained in the standard .dylibs. Looks > > like linker is not picking up standard libraries. > > > > Frediano > > > > 2016-04-18 16:42 GMT+01:00 Velichko Yuriy : > >> One moe issue. > >> Now for build on mac. > >> > >> I build FreeTds for MacOS with: > >> > >> ./configure > >> make > >> make install > >> > >> Than take lib to my project and get link error > >> > >> Undefined symbols for architecture x86_64: > >> > >> "___strlcpy_chk", referenced from: > >> _tdsdbopen in libsybdb_64.a(dblib.o) > >> _db_env_chg in libsybdb_64.a(dblib.o) > >> _dbcolinfo in libsybdb_64.a(dblib.o) > >> _dbtablecolinfo in libsybdb_64.a(dblib.o) > >> _tds_alloc_dynamic in libsybdb_64.a(mem.o) > >> _tds7_get_instance_port in libsybdb_64.a(net.o) > >> _tds_get_locale in libsybdb_64.a(locale.o) > >> ... > >> > >> Any ideas? Because I can't find this method in sources. > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > -- ?? ?????????, ??????? ????. From jan.blom at peopleinteractive.se Tue Apr 19 07:29:05 2016 From: jan.blom at peopleinteractive.se (Jan Blom) Date: Tue, 19 Apr 2016 11:29:05 +0000 Subject: [freetds] Patch to use configured connection timeout In-Reply-To: References: Message-ID: Here is the patch against master. Best regards, Jan Blom -----Original Message----- From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of Frediano Ziglio Sent: den 19 april 2016 12:35 To: FreeTDS Development Group Subject: Re: [freetds] Patch to use configured connection timeout Patch is good but for compatibility I prefer to apply only to 1.0 Frediano 2016-04-18 21:36 GMT+01:00 Jan Blom : > Hello, > > Using FreeTDS 0.95 in combination with unixODBC I notice that the connection timeout value configured in freetds.conf is never used when calling SQLDriverConnect. The attached patch makes us use the value from freetds.conf if we don't call SQLSetConnectAttr with SQL_ATTR_CONNECTION_TIMEOUT. > > The change is rather trivial. Let me know if you want me to produce a patch against head. Looking at the 1.0RC1 code it seems the issue is still present. > > > Best regards, > Jan Blom > > _______________________________________________ > 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 -------------- An embedded and charset-unspecified text was scrubbed... Name: connect_timeout_master_patch.txt URL: From freddy77 at gmail.com Tue Apr 19 08:28:00 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Tue, 19 Apr 2016 13:28:00 +0100 Subject: [freetds] Patch to use configured connection timeout In-Reply-To: References: Message-ID: Done already, was still applying correctly. Frediano 2016-04-19 12:29 GMT+01:00 Jan Blom : > Here is the patch against master. > > Best regards, > Jan Blom > > -----Original Message----- > From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of Frediano Ziglio > Sent: den 19 april 2016 12:35 > To: FreeTDS Development Group > Subject: Re: [freetds] Patch to use configured connection timeout > > Patch is good but for compatibility I prefer to apply only to 1.0 > > Frediano > > > 2016-04-18 21:36 GMT+01:00 Jan Blom : >> Hello, >> >> Using FreeTDS 0.95 in combination with unixODBC I notice that the connection timeout value configured in freetds.conf is never used when calling SQLDriverConnect. The attached patch makes us use the value from freetds.conf if we don't call SQLSetConnectAttr with SQL_ATTR_CONNECTION_TIMEOUT. >> >> The change is rather trivial. Let me know if you want me to produce a patch against head. Looking at the 1.0RC1 code it seems the issue is still present. >> >> >> Best regards, >> Jan Blom >> >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> http://lists.ibiblio.org/mailman/listinfo/freetds >> > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > From freddy77 at gmail.com Tue Apr 19 10:44:06 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Tue, 19 Apr 2016 15:44:06 +0100 Subject: [freetds] FreeTDS 1.0 Release Candidate 1 is out! In-Reply-To: <20160418190221.000017d8@gmail.com> References: <20160418190221.000017d8@gmail.com> Message-ID: Applied Thanks, Frediano 2016-04-18 19:02 GMT+01:00 Richard Hughes : > On Sun, 17 Apr 2016 19:37:41 +0100, Frediano Ziglio wrote: >> - ODBC BCP support; > > On that subject, I found a couple of bugs in my code - fixes are in the > attached. Sorry for being so late giving them to you. > > Note that I haven't tested the change to src/dblib/bcp.c - it just > looked like the right thing to do. > > Richard. > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > From velichko.yuriy at gmail.com Wed Apr 20 04:39:08 2016 From: velichko.yuriy at gmail.com (Velichko Yuriy) Date: Wed, 20 Apr 2016 11:39:08 +0300 Subject: [freetds] Conversion emoji symbols to UTF-8 In-Reply-To: References: <5707F4EA-3A99-426A-83FB-ECF468720627@t-online.hu> Message-ID: One more strange thing. 1. As you mentioned the default property use utf-16 differs on win (TRUE) and mac (FALSE). So I must to set "use utf-16 = yes" to avoid different behaviour, Good that it will be fixed in 1.0 2. ?? tds version = 7.2 - has no effect for emoji ?symbols ? just need to use ? utf-16 ?. 3 ? ? ?? ?? tds version = 7.2 ? - brokes another kind of strings.? After I set " ? tds version = 7.2 ? " ? I got few broken tests. I found? out that strings returned for sql_variant ? has the same problems like for emoji symbols - string starts with ? ? \0 symbol and has non zero length.? ? Looks like similar conversion issue. ?Using " ? tds version = 7. 0? " ? - fixes this issue - returned value is valid. To test this you can create Sequence and run query: select sys_seq.start_value FROM sys.sequences sys_seq ? On 19 April 2016 at 13:53, Velichko Yuriy wrote: > Yes, without "use utf-16" symbols are broken. > Set > use utf-16 = yes > and > tds version = 7.2 > fixes this problem on mac. > > If tds version = 7.0 - symbols are broken. > > On 19 April 2016 at 13:26, Frediano Ziglio wrote: > >> 2016-04-18 21:46 GMT+01:00 Daniel Fazekas : >> > It is actually odd that merely upgrading solved that emoji issue. >> > Emojis being largely in the Supplementary Multilingual Plane of Unicode >> require true UTF-16 support rather than the legacy UCS-2 encoding on the >> server communication side. >> > >> > In FreeTDS terms, that means that in addition to version 0.95+ you >> ought to include the following extra setting in your configuration file: >> > use utf-16 = yes >> > >> > So a complete sample configuration would look something like >> > tds version = 7.2 >> > client charset = UTF-8 >> > use utf-16 = yes >> > >> > Was it a Windows platform peculiarity that UTF-16 worked even with that >> required setting missing? >> >> This as replacements iconv use utf16 in place of ucs2. >> This however reminds me that "use utf-16" option default should be >> changed to 1 (true) for 1.0 version! >> I'm doing it right now. >> >> Frediano >> >> > In any case, I'd add that to your configuration just to be sure. >> > It certaintly was necessary for me on Mac and Linux. >> > >> >> On Apr 18, 2016, at 12:09, Velichko Yuriy >> wrote: >> >> >> >> With version 0.95.91 all works fine. looks like this issue was fixed >> >> earlier. >> >> >> >>>>>>>>> On 17 Apr 2016 12:59, "Velichko Yuriy" < >> velichko.yuriy at gmail.com> wrote: >> >>>>>>>>> My .conf includes next rows: >> >>>>>>>>> tds version = 7.0 >> >>>>>>>>> client charset = UTF-8 >> > >> > _______________________________________________ >> > FreeTDS mailing list >> > FreeTDS at lists.ibiblio.org >> > http://lists.ibiblio.org/mailman/listinfo/freetds >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> http://lists.ibiblio.org/mailman/listinfo/freetds >> > > > > -- > ?? ?????????, ??????? ????. > -- ?? ?????????, ??????? ????. From freddy77 at gmail.com Wed Apr 20 06:13:59 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Wed, 20 Apr 2016 11:13:59 +0100 Subject: [freetds] Conversion emoji symbols to UTF-8 In-Reply-To: References: <5707F4EA-3A99-426A-83FB-ECF468720627@t-online.hu> Message-ID: 2016-04-20 9:39 GMT+01:00 Velichko Yuriy : > One more strange thing. > > 1. As you mentioned the default property use utf-16 differs on win (TRUE) > and mac (FALSE). So I must to set "use utf-16 = yes" to avoid different > behaviour, Good that it will be fixed in 1.0 no, the default is the same, just that you are using the trivial iconv provided with FreeTDS which is not recommended. > 2. > > tds version = 7.2 - has no effect for emoji > symbols > just need to use > utf-16 > . > Good, so now should work for every protocol version. > 3 > > > > tds version = 7.2 > - brokes another kind of strings. Which ones? > After I set " > > tds version = 7.2 > > " > I got few broken tests. Which tests ? > I found out that strings returned for sql_variant has the same problems > like for emoji symbols - string starts with > > \0 symbol and has non zero length. > Looks like similar conversion issue. Using " > > tds version = 7. > 0 > " > - fixes this issue - returned value is valid. Weird. I'm trying this query on tsql select cast(cast(0x420435044104420420003dd84ddc20007400650073007400 as nvarchar(200)) as sql_variant) (which is based on your previous string) and looks the strings are always returned correctly. I tried from 7.0 to 7.3 without issues. > To test this you can create Sequence and run query: > select sys_seq.start_value FROM sys.sequences sys_seq > Can you post all queries you are using? Which exact sequence is not working? Are you trying some invalid coding? Frediano > > > > On 19 April 2016 at 13:53, Velichko Yuriy wrote: > >> Yes, without "use utf-16" symbols are broken. >> Set >> use utf-16 = yes >> and >> tds version = 7.2 >> fixes this problem on mac. >> >> If tds version = 7.0 - symbols are broken. >> >> On 19 April 2016 at 13:26, Frediano Ziglio wrote: >> >>> 2016-04-18 21:46 GMT+01:00 Daniel Fazekas : >>> > It is actually odd that merely upgrading solved that emoji issue. >>> > Emojis being largely in the Supplementary Multilingual Plane of Unicode >>> require true UTF-16 support rather than the legacy UCS-2 encoding on the >>> server communication side. >>> > >>> > In FreeTDS terms, that means that in addition to version 0.95+ you >>> ought to include the following extra setting in your configuration file: >>> > use utf-16 = yes >>> > >>> > So a complete sample configuration would look something like >>> > tds version = 7.2 >>> > client charset = UTF-8 >>> > use utf-16 = yes >>> > >>> > Was it a Windows platform peculiarity that UTF-16 worked even with that >>> required setting missing? >>> >>> This as replacements iconv use utf16 in place of ucs2. >>> This however reminds me that "use utf-16" option default should be >>> changed to 1 (true) for 1.0 version! >>> I'm doing it right now. >>> >>> Frediano >>> >>> > In any case, I'd add that to your configuration just to be sure. >>> > It certaintly was necessary for me on Mac and Linux. >>> > >>> >> On Apr 18, 2016, at 12:09, Velichko Yuriy >>> wrote: >>> >> >>> >> With version 0.95.91 all works fine. looks like this issue was fixed >>> >> earlier. >>> >> >>> >>>>>>>>> On 17 Apr 2016 12:59, "Velichko Yuriy" < >>> velichko.yuriy at gmail.com> wrote: >>> >>>>>>>>> My .conf includes next rows: >>> >>>>>>>>> tds version = 7.0 >>> >>>>>>>>> client charset = UTF-8 >>> > >>> > _______________________________________________ >>> > 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 velichko.yuriy at gmail.com Wed Apr 20 07:01:01 2016 From: velichko.yuriy at gmail.com (Velichko Yuriy) Date: Wed, 20 Apr 2016 14:01:01 +0300 Subject: [freetds] Conversion emoji symbols to UTF-8 In-Reply-To: References: <5707F4EA-3A99-426A-83FB-ECF468720627@t-online.hu> Message-ID: Your query works for me to: select cast(cast(0x420435044104420420003dd84ddc20007400650073007400 as nvarchar(200)) as sql_variant) Here an example for broken result: create sequence s1; select sys_seq.start_value FROM sys.sequences sys_seq where name = 's1'; On 20 April 2016 at 13:13, Frediano Ziglio wrote: > 2016-04-20 9:39 GMT+01:00 Velichko Yuriy : > > One more strange thing. > > > > 1. As you mentioned the default property use utf-16 differs on win (TRUE) > > and mac (FALSE). So I must to set "use utf-16 = yes" to avoid different > > behaviour, Good that it will be fixed in 1.0 > > no, the default is the same, just that you are using the trivial iconv > provided with FreeTDS which is not recommended. > > > 2. > > > > tds version = 7.2 - has no effect for emoji > > symbols > > just need to use > > utf-16 > > . > > > > Good, so now should work for every protocol version. > > > 3 > > > > > > > > tds version = 7.2 > > - brokes another kind of strings. > > Which ones? > > > After I set " > > > > tds version = 7.2 > > > > " > > I got few broken tests. > > Which tests ? > > > I found out that strings returned for sql_variant has the same problems > > like for emoji symbols - string starts with > > > > \0 symbol and has non zero length. > > Looks like similar conversion issue. Using " > > > > tds version = 7. > > 0 > > " > > - fixes this issue - returned value is valid. > > Weird. I'm trying this query on tsql > > select cast(cast(0x420435044104420420003dd84ddc20007400650073007400 as > nvarchar(200)) as sql_variant) > > (which is based on your previous string) and looks the strings are > always returned correctly. > I tried from 7.0 to 7.3 without issues. > > > To test this you can create Sequence and run query: > > select sys_seq.start_value FROM sys.sequences sys_seq > > > > Can you post all queries you are using? Which exact sequence is not > working? > Are you trying some invalid coding? > > Frediano > > > > > > > > > On 19 April 2016 at 13:53, Velichko Yuriy > wrote: > > > >> Yes, without "use utf-16" symbols are broken. > >> Set > >> use utf-16 = yes > >> and > >> tds version = 7.2 > >> fixes this problem on mac. > >> > >> If tds version = 7.0 - symbols are broken. > >> > >> On 19 April 2016 at 13:26, Frediano Ziglio wrote: > >> > >>> 2016-04-18 21:46 GMT+01:00 Daniel Fazekas : > >>> > It is actually odd that merely upgrading solved that emoji issue. > >>> > Emojis being largely in the Supplementary Multilingual Plane of > Unicode > >>> require true UTF-16 support rather than the legacy UCS-2 encoding on > the > >>> server communication side. > >>> > > >>> > In FreeTDS terms, that means that in addition to version 0.95+ you > >>> ought to include the following extra setting in your configuration > file: > >>> > use utf-16 = yes > >>> > > >>> > So a complete sample configuration would look something like > >>> > tds version = 7.2 > >>> > client charset = UTF-8 > >>> > use utf-16 = yes > >>> > > >>> > Was it a Windows platform peculiarity that UTF-16 worked even with > that > >>> required setting missing? > >>> > >>> This as replacements iconv use utf16 in place of ucs2. > >>> This however reminds me that "use utf-16" option default should be > >>> changed to 1 (true) for 1.0 version! > >>> I'm doing it right now. > >>> > >>> Frediano > >>> > >>> > In any case, I'd add that to your configuration just to be sure. > >>> > It certaintly was necessary for me on Mac and Linux. > >>> > > >>> >> On Apr 18, 2016, at 12:09, Velichko Yuriy > > >>> wrote: > >>> >> > >>> >> With version 0.95.91 all works fine. looks like this issue was fixed > >>> >> earlier. > >>> >> > >>> >>>>>>>>> On 17 Apr 2016 12:59, "Velichko Yuriy" < > >>> velichko.yuriy at gmail.com> wrote: > >>> >>>>>>>>> My .conf includes next rows: > >>> >>>>>>>>> tds version = 7.0 > >>> >>>>>>>>> client charset = UTF-8 > >>> > > >>> > _______________________________________________ > >>> > FreeTDS mailing list > >>> > FreeTDS at lists.ibiblio.org > >>> > http://lists.ibiblio.org/mailman/listinfo/freetds > >>> _______________________________________________ > >>> FreeTDS mailing list > >>> FreeTDS at lists.ibiblio.org > >>> http://lists.ibiblio.org/mailman/listinfo/freetds > >>> > >> > >> > >> > >> -- > >> ? ?????????, ??????? ????. > >> > > > > > > > > -- > > ? ?????????, ??????? ????. > > _______________________________________________ > > FreeTDS mailing list > > FreeTDS at lists.ibiblio.org > > http://lists.ibiblio.org/mailman/listinfo/freetds > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > -- ?? ?????????, ??????? ????. From freddy77 at gmail.com Wed Apr 20 07:07:53 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Wed, 20 Apr 2016 12:07:53 +0100 Subject: [freetds] Conversion emoji symbols to UTF-8 In-Reply-To: References: <5707F4EA-3A99-426A-83FB-ECF468720627@t-online.hu> Message-ID: 2016-04-20 12:01 GMT+01:00 Velichko Yuriy : > Your query works for me to: > > select cast(cast(0x420435044104420420003dd84ddc20007400650073007400 as > nvarchar(200)) as sql_variant) > > Here an example for broken result: > > create sequence s1; > select sys_seq.start_value FROM sys.sequences sys_seq where name = 's1'; > Is this related to emoji/encoding ? Can you post a TDSDUMP. I don't have a mssql 2012 to test with (it's tested by AppVeyor). Frediano > On 20 April 2016 at 13:13, Frediano Ziglio wrote: > >> 2016-04-20 9:39 GMT+01:00 Velichko Yuriy : >> > One more strange thing. >> > >> > 1. As you mentioned the default property use utf-16 differs on win (TRUE) >> > and mac (FALSE). So I must to set "use utf-16 = yes" to avoid different >> > behaviour, Good that it will be fixed in 1.0 >> >> no, the default is the same, just that you are using the trivial iconv >> provided with FreeTDS which is not recommended. >> >> > 2. >> > >> > tds version = 7.2 - has no effect for emoji >> > symbols >> > just need to use >> > utf-16 >> > . >> > >> >> Good, so now should work for every protocol version. >> >> > 3 >> > >> > >> > >> > tds version = 7.2 >> > - brokes another kind of strings. >> >> Which ones? >> >> > After I set " >> > >> > tds version = 7.2 >> > >> > " >> > I got few broken tests. >> >> Which tests ? >> >> > I found out that strings returned for sql_variant has the same problems >> > like for emoji symbols - string starts with >> > >> > \0 symbol and has non zero length. >> > Looks like similar conversion issue. Using " >> > >> > tds version = 7. >> > 0 >> > " >> > - fixes this issue - returned value is valid. >> >> Weird. I'm trying this query on tsql >> >> select cast(cast(0x420435044104420420003dd84ddc20007400650073007400 as >> nvarchar(200)) as sql_variant) >> >> (which is based on your previous string) and looks the strings are >> always returned correctly. >> I tried from 7.0 to 7.3 without issues. >> >> > To test this you can create Sequence and run query: >> > select sys_seq.start_value FROM sys.sequences sys_seq >> > >> >> Can you post all queries you are using? Which exact sequence is not >> working? >> Are you trying some invalid coding? >> >> Frediano >> >> > >> > >> > >> > On 19 April 2016 at 13:53, Velichko Yuriy >> wrote: >> > >> >> Yes, without "use utf-16" symbols are broken. >> >> Set >> >> use utf-16 = yes >> >> and >> >> tds version = 7.2 >> >> fixes this problem on mac. >> >> >> >> If tds version = 7.0 - symbols are broken. >> >> >> >> On 19 April 2016 at 13:26, Frediano Ziglio wrote: >> >> >> >>> 2016-04-18 21:46 GMT+01:00 Daniel Fazekas : >> >>> > It is actually odd that merely upgrading solved that emoji issue. >> >>> > Emojis being largely in the Supplementary Multilingual Plane of >> Unicode >> >>> require true UTF-16 support rather than the legacy UCS-2 encoding on >> the >> >>> server communication side. >> >>> > >> >>> > In FreeTDS terms, that means that in addition to version 0.95+ you >> >>> ought to include the following extra setting in your configuration >> file: >> >>> > use utf-16 = yes >> >>> > >> >>> > So a complete sample configuration would look something like >> >>> > tds version = 7.2 >> >>> > client charset = UTF-8 >> >>> > use utf-16 = yes >> >>> > >> >>> > Was it a Windows platform peculiarity that UTF-16 worked even with >> that >> >>> required setting missing? >> >>> >> >>> This as replacements iconv use utf16 in place of ucs2. >> >>> This however reminds me that "use utf-16" option default should be >> >>> changed to 1 (true) for 1.0 version! >> >>> I'm doing it right now. >> >>> >> >>> Frediano >> >>> >> >>> > In any case, I'd add that to your configuration just to be sure. >> >>> > It certaintly was necessary for me on Mac and Linux. >> >>> > >> >>> >> On Apr 18, 2016, at 12:09, Velichko Yuriy > > >> >>> wrote: >> >>> >> >> >>> >> With version 0.95.91 all works fine. looks like this issue was fixed >> >>> >> earlier. >> >>> >> >> >>> >>>>>>>>> On 17 Apr 2016 12:59, "Velichko Yuriy" < >> >>> velichko.yuriy at gmail.com> wrote: >> >>> >>>>>>>>> My .conf includes next rows: >> >>> >>>>>>>>> tds version = 7.0 >> >>> >>>>>>>>> client charset = UTF-8 >> >>> > >> >>> > _______________________________________________ >> >>> > 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 velichko.yuriy at gmail.com Wed Apr 20 07:41:33 2016 From: velichko.yuriy at gmail.com (Velichko Yuriy) Date: Wed, 20 Apr 2016 14:41:33 +0300 Subject: [freetds] Conversion emoji symbols to UTF-8 In-Reply-To: References: <5707F4EA-3A99-426A-83FB-ECF468720627@t-online.hu> Message-ID: On 20 April 2016 at 14:07, Frediano Ziglio wrote: > 2016-04-20 12:01 GMT+01:00 Velichko Yuriy : > > Your query works for me to: > > > > select cast(cast(0x420435044104420420003dd84ddc20007400650073007400 as > > nvarchar(200)) as sql_variant) > > > > Here an example for broken result: > > > > create sequence s1; > > select sys_seq.start_value FROM sys.sequences sys_seq where name = 's1'; > > > > Is this related to emoji/encoding ? > ?Already no, I think. Should I create new thread?? > Can you post a > ?? > TDSDUMP. I don't have a mssql 2012 to test with (it's > tested by AppVeyor). > > Frediano > > > On 20 April 2016 at 13:13, Frediano Ziglio wrote: > > > >> 2016-04-20 9:39 GMT+01:00 Velichko Yuriy : > >> > One more strange thing. > >> > > >> > 1. As you mentioned the default property use utf-16 differs on win > (TRUE) > >> > and mac (FALSE). So I must to set "use utf-16 = yes" to avoid > different > >> > behaviour, Good that it will be fixed in 1.0 > >> > >> no, the default is the same, just that you are using the trivial iconv > >> provided with FreeTDS which is not recommended. > >> > >> > 2. > >> > > >> > tds version = 7.2 - has no effect for emoji > >> > symbols > >> > just need to use > >> > utf-16 > >> > . > >> > > >> > >> Good, so now should work for every protocol version. > >> > >> > 3 > >> > > >> > > >> > > >> > tds version = 7.2 > >> > - brokes another kind of strings. > >> > >> Which ones? > >> > >> > After I set " > >> > > >> > tds version = 7.2 > >> > > >> > " > >> > I got few broken tests. > >> > >> Which tests ? > >> > >> > I found out that strings returned for sql_variant has the same > problems > >> > like for emoji symbols - string starts with > >> > > >> > \0 symbol and has non zero length. > >> > Looks like similar conversion issue. Using " > >> > > >> > tds version = 7. > >> > 0 > >> > " > >> > - fixes this issue - returned value is valid. > >> > >> Weird. I'm trying this query on tsql > >> > >> select cast(cast(0x420435044104420420003dd84ddc20007400650073007400 as > >> nvarchar(200)) as sql_variant) > >> > >> (which is based on your previous string) and looks the strings are > >> always returned correctly. > >> I tried from 7.0 to 7.3 without issues. > >> > >> > To test this you can create Sequence and run query: > >> > select sys_seq.start_value FROM sys.sequences sys_seq > >> > > >> > >> Can you post all queries you are using? Which exact sequence is not > >> working? > >> Are you trying some invalid coding? > >> > >> Frediano > >> > >> > > >> > > >> > > >> > On 19 April 2016 at 13:53, Velichko Yuriy > >> wrote: > >> > > >> >> Yes, without "use utf-16" symbols are broken. > >> >> Set > >> >> use utf-16 = yes > >> >> and > >> >> tds version = 7.2 > >> >> fixes this problem on mac. > >> >> > >> >> If tds version = 7.0 - symbols are broken. > >> >> > >> >> On 19 April 2016 at 13:26, Frediano Ziglio > wrote: > >> >> > >> >>> 2016-04-18 21:46 GMT+01:00 Daniel Fazekas : > >> >>> > It is actually odd that merely upgrading solved that emoji issue. > >> >>> > Emojis being largely in the Supplementary Multilingual Plane of > >> Unicode > >> >>> require true UTF-16 support rather than the legacy UCS-2 encoding on > >> the > >> >>> server communication side. > >> >>> > > >> >>> > In FreeTDS terms, that means that in addition to version 0.95+ you > >> >>> ought to include the following extra setting in your configuration > >> file: > >> >>> > use utf-16 = yes > >> >>> > > >> >>> > So a complete sample configuration would look something like > >> >>> > tds version = 7.2 > >> >>> > client charset = UTF-8 > >> >>> > use utf-16 = yes > >> >>> > > >> >>> > Was it a Windows platform peculiarity that UTF-16 worked even with > >> that > >> >>> required setting missing? > >> >>> > >> >>> This as replacements iconv use utf16 in place of ucs2. > >> >>> This however reminds me that "use utf-16" option default should be > >> >>> changed to 1 (true) for 1.0 version! > >> >>> I'm doing it right now. > >> >>> > >> >>> Frediano > >> >>> > >> >>> > In any case, I'd add that to your configuration just to be sure. > >> >>> > It certaintly was necessary for me on Mac and Linux. > >> >>> > > >> >>> >> On Apr 18, 2016, at 12:09, Velichko Yuriy < > velichko.yuriy at gmail.com > >> > > >> >>> wrote: > >> >>> >> > >> >>> >> With version 0.95.91 all works fine. looks like this issue was > fixed > >> >>> >> earlier. > >> >>> >> > >> >>> >>>>>>>>> On 17 Apr 2016 12:59, "Velichko Yuriy" < > >> >>> velichko.yuriy at gmail.com> wrote: > >> >>> >>>>>>>>> My .conf includes next rows: > >> >>> >>>>>>>>> tds version = 7.0 > >> >>> >>>>>>>>> client charset = UTF-8 > >> >>> > > >> >>> > _______________________________________________ > >> >>> > FreeTDS mailing list > >> >>> > FreeTDS at lists.ibiblio.org > >> >>> > http://lists.ibiblio.org/mailman/listinfo/freetds > >> >>> _______________________________________________ > >> >>> FreeTDS mailing list > >> >>> FreeTDS at lists.ibiblio.org > >> >>> http://lists.ibiblio.org/mailman/listinfo/freetds > >> >>> > >> >> > >> >> > >> >> > >> >> -- > >> >> ? ?????????, ??????? ????. > >> >> > >> > > >> > > >> > > >> > -- > >> > ? ?????????, ??????? ????. > >> > _______________________________________________ > >> > FreeTDS mailing list > >> > FreeTDS at lists.ibiblio.org > >> > http://lists.ibiblio.org/mailman/listinfo/freetds > >> _______________________________________________ > >> FreeTDS mailing list > >> FreeTDS at lists.ibiblio.org > >> http://lists.ibiblio.org/mailman/listinfo/freetds > >> > > > > > > > > -- > > ? ?????????, ??????? ????. > > _______________________________________________ > > FreeTDS mailing list > > FreeTDS at lists.ibiblio.org > > http://lists.ibiblio.org/mailman/listinfo/freetds > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > -- ?? ?????????, ??????? ????. From velichko.yuriy at gmail.com Wed Apr 20 08:06:42 2016 From: velichko.yuriy at gmail.com (Velichko Yuriy) Date: Wed, 20 Apr 2016 15:06:42 +0300 Subject: [freetds] Conversion emoji symbols to UTF-8 In-Reply-To: References: <5707F4EA-3A99-426A-83FB-ECF468720627@t-online.hu> Message-ID: I have tried FreeTDS from here, and all work fine. So the error on my side. Will try to find. On 20 April 2016 at 14:41, Velichko Yuriy wrote: > > > On 20 April 2016 at 14:07, Frediano Ziglio wrote: > >> 2016-04-20 12:01 GMT+01:00 Velichko Yuriy : >> > Your query works for me to: >> > >> > select cast(cast(0x420435044104420420003dd84ddc20007400650073007400 as >> > nvarchar(200)) as sql_variant) >> > >> > Here an example for broken result: >> > >> > create sequence s1; >> > select sys_seq.start_value FROM sys.sequences sys_seq where name = 's1'; >> > >> >> Is this related to emoji/encoding ? >> > ?Already no, I think. Should I create new thread?? > > >> Can you post a >> ?? >> TDSDUMP. I don't have a mssql 2012 to test with (it's >> tested by AppVeyor). >> >> Frediano >> >> > On 20 April 2016 at 13:13, Frediano Ziglio wrote: >> > >> >> 2016-04-20 9:39 GMT+01:00 Velichko Yuriy : >> >> > One more strange thing. >> >> > >> >> > 1. As you mentioned the default property use utf-16 differs on win >> (TRUE) >> >> > and mac (FALSE). So I must to set "use utf-16 = yes" to avoid >> different >> >> > behaviour, Good that it will be fixed in 1.0 >> >> >> >> no, the default is the same, just that you are using the trivial iconv >> >> provided with FreeTDS which is not recommended. >> >> >> >> > 2. >> >> > >> >> > tds version = 7.2 - has no effect for emoji >> >> > symbols >> >> > just need to use >> >> > utf-16 >> >> > . >> >> > >> >> >> >> Good, so now should work for every protocol version. >> >> >> >> > 3 >> >> > >> >> > >> >> > >> >> > tds version = 7.2 >> >> > - brokes another kind of strings. >> >> >> >> Which ones? >> >> >> >> > After I set " >> >> > >> >> > tds version = 7.2 >> >> > >> >> > " >> >> > I got few broken tests. >> >> >> >> Which tests ? >> >> >> >> > I found out that strings returned for sql_variant has the same >> problems >> >> > like for emoji symbols - string starts with >> >> > >> >> > \0 symbol and has non zero length. >> >> > Looks like similar conversion issue. Using " >> >> > >> >> > tds version = 7. >> >> > 0 >> >> > " >> >> > - fixes this issue - returned value is valid. >> >> >> >> Weird. I'm trying this query on tsql >> >> >> >> select cast(cast(0x420435044104420420003dd84ddc20007400650073007400 as >> >> nvarchar(200)) as sql_variant) >> >> >> >> (which is based on your previous string) and looks the strings are >> >> always returned correctly. >> >> I tried from 7.0 to 7.3 without issues. >> >> >> >> > To test this you can create Sequence and run query: >> >> > select sys_seq.start_value FROM sys.sequences sys_seq >> >> > >> >> >> >> Can you post all queries you are using? Which exact sequence is not >> >> working? >> >> Are you trying some invalid coding? >> >> >> >> Frediano >> >> >> >> > >> >> > >> >> > >> >> > On 19 April 2016 at 13:53, Velichko Yuriy >> >> wrote: >> >> > >> >> >> Yes, without "use utf-16" symbols are broken. >> >> >> Set >> >> >> use utf-16 = yes >> >> >> and >> >> >> tds version = 7.2 >> >> >> fixes this problem on mac. >> >> >> >> >> >> If tds version = 7.0 - symbols are broken. >> >> >> >> >> >> On 19 April 2016 at 13:26, Frediano Ziglio >> wrote: >> >> >> >> >> >>> 2016-04-18 21:46 GMT+01:00 Daniel Fazekas : >> >> >>> > It is actually odd that merely upgrading solved that emoji issue. >> >> >>> > Emojis being largely in the Supplementary Multilingual Plane of >> >> Unicode >> >> >>> require true UTF-16 support rather than the legacy UCS-2 encoding >> on >> >> the >> >> >>> server communication side. >> >> >>> > >> >> >>> > In FreeTDS terms, that means that in addition to version 0.95+ >> you >> >> >>> ought to include the following extra setting in your configuration >> >> file: >> >> >>> > use utf-16 = yes >> >> >>> > >> >> >>> > So a complete sample configuration would look something like >> >> >>> > tds version = 7.2 >> >> >>> > client charset = UTF-8 >> >> >>> > use utf-16 = yes >> >> >>> > >> >> >>> > Was it a Windows platform peculiarity that UTF-16 worked even >> with >> >> that >> >> >>> required setting missing? >> >> >>> >> >> >>> This as replacements iconv use utf16 in place of ucs2. >> >> >>> This however reminds me that "use utf-16" option default should be >> >> >>> changed to 1 (true) for 1.0 version! >> >> >>> I'm doing it right now. >> >> >>> >> >> >>> Frediano >> >> >>> >> >> >>> > In any case, I'd add that to your configuration just to be sure. >> >> >>> > It certaintly was necessary for me on Mac and Linux. >> >> >>> > >> >> >>> >> On Apr 18, 2016, at 12:09, Velichko Yuriy < >> velichko.yuriy at gmail.com >> >> > >> >> >>> wrote: >> >> >>> >> >> >> >>> >> With version 0.95.91 all works fine. looks like this issue was >> fixed >> >> >>> >> earlier. >> >> >>> >> >> >> >>> >>>>>>>>> On 17 Apr 2016 12:59, "Velichko Yuriy" < >> >> >>> velichko.yuriy at gmail.com> wrote: >> >> >>> >>>>>>>>> My .conf includes next rows: >> >> >>> >>>>>>>>> tds version = 7.0 >> >> >>> >>>>>>>>> client charset = UTF-8 >> >> >>> > >> >> >>> > _______________________________________________ >> >> >>> > FreeTDS mailing list >> >> >>> > FreeTDS at lists.ibiblio.org >> >> >>> > http://lists.ibiblio.org/mailman/listinfo/freetds >> >> >>> _______________________________________________ >> >> >>> FreeTDS mailing list >> >> >>> FreeTDS at lists.ibiblio.org >> >> >>> http://lists.ibiblio.org/mailman/listinfo/freetds >> >> >>> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> ? ?????????, ??????? ????. >> >> >> >> >> > >> >> > >> >> > >> >> > -- >> >> > ? ?????????, ??????? ????. >> >> > _______________________________________________ >> >> > FreeTDS mailing list >> >> > FreeTDS at lists.ibiblio.org >> >> > http://lists.ibiblio.org/mailman/listinfo/freetds >> >> _______________________________________________ >> >> FreeTDS mailing list >> >> FreeTDS at lists.ibiblio.org >> >> http://lists.ibiblio.org/mailman/listinfo/freetds >> >> >> > >> > >> > >> > -- >> > ? ?????????, ??????? ????. >> > _______________________________________________ >> > FreeTDS mailing list >> > FreeTDS at lists.ibiblio.org >> > http://lists.ibiblio.org/mailman/listinfo/freetds >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> http://lists.ibiblio.org/mailman/listinfo/freetds >> > > > > -- > ?? ?????????, ??????? ????. > -- ?? ?????????, ??????? ????. From freddy77 at gmail.com Wed Apr 20 09:37:01 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Wed, 20 Apr 2016 14:37:01 +0100 Subject: [freetds] Conversion emoji symbols to UTF-8 In-Reply-To: References: <5707F4EA-3A99-426A-83FB-ECF468720627@t-online.hu> Message-ID: It's not clear which library are you using. Note that SQL_VARIANT is not supported in TDS 7.0 so the server send data as normal text. Could be some paths/libraries do not support correctly SQL_VARIANT. Frediano 2016-04-20 13:06 GMT+01:00 Velichko Yuriy : > I have tried FreeTDS from here, and all work fine. So the error on my side. > Will try to find. > > On 20 April 2016 at 14:41, Velichko Yuriy wrote: > >> >> >> On 20 April 2016 at 14:07, Frediano Ziglio wrote: >> >>> 2016-04-20 12:01 GMT+01:00 Velichko Yuriy : >>> > Your query works for me to: >>> > >>> > select cast(cast(0x420435044104420420003dd84ddc20007400650073007400 as >>> > nvarchar(200)) as sql_variant) >>> > >>> > Here an example for broken result: >>> > >>> > create sequence s1; >>> > select sys_seq.start_value FROM sys.sequences sys_seq where name = 's1'; >>> > >>> >>> Is this related to emoji/encoding ? >>> >> Already no, I think. Should I create new thread? >> >> >>> Can you post a >>> >>> TDSDUMP. I don't have a mssql 2012 to test with (it's >>> tested by AppVeyor). >>> >>> Frediano >>> >>> > On 20 April 2016 at 13:13, Frediano Ziglio wrote: >>> > >>> >> 2016-04-20 9:39 GMT+01:00 Velichko Yuriy : >>> >> > One more strange thing. >>> >> > >>> >> > 1. As you mentioned the default property use utf-16 differs on win >>> (TRUE) >>> >> > and mac (FALSE). So I must to set "use utf-16 = yes" to avoid >>> different >>> >> > behaviour, Good that it will be fixed in 1.0 >>> >> >>> >> no, the default is the same, just that you are using the trivial iconv >>> >> provided with FreeTDS which is not recommended. >>> >> >>> >> > 2. >>> >> > >>> >> > tds version = 7.2 - has no effect for emoji >>> >> > symbols >>> >> > just need to use >>> >> > utf-16 >>> >> > . >>> >> > >>> >> >>> >> Good, so now should work for every protocol version. >>> >> >>> >> > 3 >>> >> > >>> >> > >>> >> > >>> >> > tds version = 7.2 >>> >> > - brokes another kind of strings. >>> >> >>> >> Which ones? >>> >> >>> >> > After I set " >>> >> > >>> >> > tds version = 7.2 >>> >> > >>> >> > " >>> >> > I got few broken tests. >>> >> >>> >> Which tests ? >>> >> >>> >> > I found out that strings returned for sql_variant has the same >>> problems >>> >> > like for emoji symbols - string starts with >>> >> > >>> >> > \0 symbol and has non zero length. >>> >> > Looks like similar conversion issue. Using " >>> >> > >>> >> > tds version = 7. >>> >> > 0 >>> >> > " >>> >> > - fixes this issue - returned value is valid. >>> >> >>> >> Weird. I'm trying this query on tsql >>> >> >>> >> select cast(cast(0x420435044104420420003dd84ddc20007400650073007400 as >>> >> nvarchar(200)) as sql_variant) >>> >> >>> >> (which is based on your previous string) and looks the strings are >>> >> always returned correctly. >>> >> I tried from 7.0 to 7.3 without issues. >>> >> >>> >> > To test this you can create Sequence and run query: >>> >> > select sys_seq.start_value FROM sys.sequences sys_seq >>> >> > >>> >> >>> >> Can you post all queries you are using? Which exact sequence is not >>> >> working? >>> >> Are you trying some invalid coding? >>> >> >>> >> Frediano >>> >> >>> >> > >>> >> > >>> >> > >>> >> > On 19 April 2016 at 13:53, Velichko Yuriy >>> >> wrote: >>> >> > >>> >> >> Yes, without "use utf-16" symbols are broken. >>> >> >> Set >>> >> >> use utf-16 = yes >>> >> >> and >>> >> >> tds version = 7.2 >>> >> >> fixes this problem on mac. >>> >> >> >>> >> >> If tds version = 7.0 - symbols are broken. >>> >> >> >>> >> >> On 19 April 2016 at 13:26, Frediano Ziglio >>> wrote: >>> >> >> >>> >> >>> 2016-04-18 21:46 GMT+01:00 Daniel Fazekas : >>> >> >>> > It is actually odd that merely upgrading solved that emoji issue. >>> >> >>> > Emojis being largely in the Supplementary Multilingual Plane of >>> >> Unicode >>> >> >>> require true UTF-16 support rather than the legacy UCS-2 encoding >>> on >>> >> the >>> >> >>> server communication side. >>> >> >>> > >>> >> >>> > In FreeTDS terms, that means that in addition to version 0.95+ >>> you >>> >> >>> ought to include the following extra setting in your configuration >>> >> file: >>> >> >>> > use utf-16 = yes >>> >> >>> > >>> >> >>> > So a complete sample configuration would look something like >>> >> >>> > tds version = 7.2 >>> >> >>> > client charset = UTF-8 >>> >> >>> > use utf-16 = yes >>> >> >>> > >>> >> >>> > Was it a Windows platform peculiarity that UTF-16 worked even >>> with >>> >> that >>> >> >>> required setting missing? >>> >> >>> >>> >> >>> This as replacements iconv use utf16 in place of ucs2. >>> >> >>> This however reminds me that "use utf-16" option default should be >>> >> >>> changed to 1 (true) for 1.0 version! >>> >> >>> I'm doing it right now. >>> >> >>> >>> >> >>> Frediano >>> >> >>> >>> >> >>> > In any case, I'd add that to your configuration just to be sure. >>> >> >>> > It certaintly was necessary for me on Mac and Linux. >>> >> >>> > >>> >> >>> >> On Apr 18, 2016, at 12:09, Velichko Yuriy < >>> velichko.yuriy at gmail.com >>> >> > >>> >> >>> wrote: >>> >> >>> >> >>> >> >>> >> With version 0.95.91 all works fine. looks like this issue was >>> fixed >>> >> >>> >> earlier. >>> >> >>> >> >>> >> >>> >>>>>>>>> On 17 Apr 2016 12:59, "Velichko Yuriy" < >>> >> >>> velichko.yuriy at gmail.com> wrote: >>> >> >>> >>>>>>>>> My .conf includes next rows: >>> >> >>> >>>>>>>>> tds version = 7.0 >>> >> >>> >>>>>>>>> client charset = UTF-8 >>> >> >>> > From velichko.yuriy at gmail.com Wed Apr 20 10:03:30 2016 From: velichko.yuriy at gmail.com (Velichko Yuriy) Date: Wed, 20 Apr 2016 17:03:30 +0300 Subject: [freetds] Conversion emoji symbols to UTF-8 In-Reply-To: References: <5707F4EA-3A99-426A-83FB-ECF468720627@t-online.hu> Message-ID: Thanks I'll keep it in mind. I use only db-lib as static library. On 20 April 2016 at 16:37, Frediano Ziglio wrote: > It's not clear which library are you using. Note that SQL_VARIANT is > not supported in TDS 7.0 so the server send data as normal text. Could > be some paths/libraries do not support correctly SQL_VARIANT. > > Frediano > > > 2016-04-20 13:06 GMT+01:00 Velichko Yuriy : > > I have tried FreeTDS from here, and all work fine. So the error on my > side. > > Will try to find. > > > > On 20 April 2016 at 14:41, Velichko Yuriy > wrote: > > > >> > >> > >> On 20 April 2016 at 14:07, Frediano Ziglio wrote: > >> > >>> 2016-04-20 12:01 GMT+01:00 Velichko Yuriy : > >>> > Your query works for me to: > >>> > > >>> > select cast(cast(0x420435044104420420003dd84ddc20007400650073007400 > as > >>> > nvarchar(200)) as sql_variant) > >>> > > >>> > Here an example for broken result: > >>> > > >>> > create sequence s1; > >>> > select sys_seq.start_value FROM sys.sequences sys_seq where name = > 's1'; > >>> > > >>> > >>> Is this related to emoji/encoding ? > >>> > >> Already no, I think. Should I create new thread? > >> > >> > >>> Can you post a > >>> > >>> TDSDUMP. I don't have a mssql 2012 to test with (it's > >>> tested by AppVeyor). > >>> > >>> Frediano > >>> > >>> > On 20 April 2016 at 13:13, Frediano Ziglio > wrote: > >>> > > >>> >> 2016-04-20 9:39 GMT+01:00 Velichko Yuriy >: > >>> >> > One more strange thing. > >>> >> > > >>> >> > 1. As you mentioned the default property use utf-16 differs on win > >>> (TRUE) > >>> >> > and mac (FALSE). So I must to set "use utf-16 = yes" to avoid > >>> different > >>> >> > behaviour, Good that it will be fixed in 1.0 > >>> >> > >>> >> no, the default is the same, just that you are using the trivial > iconv > >>> >> provided with FreeTDS which is not recommended. > >>> >> > >>> >> > 2. > >>> >> > > >>> >> > tds version = 7.2 - has no effect for emoji > >>> >> > symbols > >>> >> > just need to use > >>> >> > utf-16 > >>> >> > . > >>> >> > > >>> >> > >>> >> Good, so now should work for every protocol version. > >>> >> > >>> >> > 3 > >>> >> > > >>> >> > > >>> >> > > >>> >> > tds version = 7.2 > >>> >> > - brokes another kind of strings. > >>> >> > >>> >> Which ones? > >>> >> > >>> >> > After I set " > >>> >> > > >>> >> > tds version = 7.2 > >>> >> > > >>> >> > " > >>> >> > I got few broken tests. > >>> >> > >>> >> Which tests ? > >>> >> > >>> >> > I found out that strings returned for sql_variant has the same > >>> problems > >>> >> > like for emoji symbols - string starts with > >>> >> > > >>> >> > \0 symbol and has non zero length. > >>> >> > Looks like similar conversion issue. Using " > >>> >> > > >>> >> > tds version = 7. > >>> >> > 0 > >>> >> > " > >>> >> > - fixes this issue - returned value is valid. > >>> >> > >>> >> Weird. I'm trying this query on tsql > >>> >> > >>> >> select cast(cast(0x420435044104420420003dd84ddc20007400650073007400 > as > >>> >> nvarchar(200)) as sql_variant) > >>> >> > >>> >> (which is based on your previous string) and looks the strings are > >>> >> always returned correctly. > >>> >> I tried from 7.0 to 7.3 without issues. > >>> >> > >>> >> > To test this you can create Sequence and run query: > >>> >> > select sys_seq.start_value FROM sys.sequences sys_seq > >>> >> > > >>> >> > >>> >> Can you post all queries you are using? Which exact sequence is not > >>> >> working? > >>> >> Are you trying some invalid coding? > >>> >> > >>> >> Frediano > >>> >> > >>> >> > > >>> >> > > >>> >> > > >>> >> > On 19 April 2016 at 13:53, Velichko Yuriy < > velichko.yuriy at gmail.com> > >>> >> wrote: > >>> >> > > >>> >> >> Yes, without "use utf-16" symbols are broken. > >>> >> >> Set > >>> >> >> use utf-16 = yes > >>> >> >> and > >>> >> >> tds version = 7.2 > >>> >> >> fixes this problem on mac. > >>> >> >> > >>> >> >> If tds version = 7.0 - symbols are broken. > >>> >> >> > >>> >> >> On 19 April 2016 at 13:26, Frediano Ziglio > >>> wrote: > >>> >> >> > >>> >> >>> 2016-04-18 21:46 GMT+01:00 Daniel Fazekas : > >>> >> >>> > It is actually odd that merely upgrading solved that emoji > issue. > >>> >> >>> > Emojis being largely in the Supplementary Multilingual Plane > of > >>> >> Unicode > >>> >> >>> require true UTF-16 support rather than the legacy UCS-2 > encoding > >>> on > >>> >> the > >>> >> >>> server communication side. > >>> >> >>> > > >>> >> >>> > In FreeTDS terms, that means that in addition to version 0.95+ > >>> you > >>> >> >>> ought to include the following extra setting in your > configuration > >>> >> file: > >>> >> >>> > use utf-16 = yes > >>> >> >>> > > >>> >> >>> > So a complete sample configuration would look something like > >>> >> >>> > tds version = 7.2 > >>> >> >>> > client charset = UTF-8 > >>> >> >>> > use utf-16 = yes > >>> >> >>> > > >>> >> >>> > Was it a Windows platform peculiarity that UTF-16 worked even > >>> with > >>> >> that > >>> >> >>> required setting missing? > >>> >> >>> > >>> >> >>> This as replacements iconv use utf16 in place of ucs2. > >>> >> >>> This however reminds me that "use utf-16" option default should > be > >>> >> >>> changed to 1 (true) for 1.0 version! > >>> >> >>> I'm doing it right now. > >>> >> >>> > >>> >> >>> Frediano > >>> >> >>> > >>> >> >>> > In any case, I'd add that to your configuration just to be > sure. > >>> >> >>> > It certaintly was necessary for me on Mac and Linux. > >>> >> >>> > > >>> >> >>> >> On Apr 18, 2016, at 12:09, Velichko Yuriy < > >>> velichko.yuriy at gmail.com > >>> >> > > >>> >> >>> wrote: > >>> >> >>> >> > >>> >> >>> >> With version 0.95.91 all works fine. looks like this issue > was > >>> fixed > >>> >> >>> >> earlier. > >>> >> >>> >> > >>> >> >>> >>>>>>>>> On 17 Apr 2016 12:59, "Velichko Yuriy" < > >>> >> >>> velichko.yuriy at gmail.com> wrote: > >>> >> >>> >>>>>>>>> My .conf includes next rows: > >>> >> >>> >>>>>>>>> tds version = 7.0 > >>> >> >>> >>>>>>>>> client charset = UTF-8 > >>> >> >>> > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > -- ?? ?????????, ??????? ????. From freddy77 at gmail.com Thu Apr 21 02:54:26 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Thu, 21 Apr 2016 07:54:26 +0100 Subject: [freetds] FreeTDS 1.0 Release Candidate 2 is out! Message-ID: This release contains just small fixes: - added some notes to UserGuide for AppVeyor; - fix Sybperl build; - change "use utf-16" default to yes; - small fix for ODBC BCP and prefixed columns; - avoid too many connection attempts on failure. Frediano From john at capps.com Thu Apr 21 03:00:59 2016 From: john at capps.com (John Kendall) Date: Thu, 21 Apr 2016 07:00:59 +0000 Subject: [freetds] "Fix affected rows after insert with prepared query" side effect Message-ID: On Oct 19, 2015 this patch was applied to ct.c: "Fix affected rows after insert with prepared query" This patch has the side-effect of a 'rows affected' being displayed for every select statement within a ASE stored procedure. For example, sp_help returns 136 extra 'rows affected' lines. See below. Backing out this patch stops this from happening. I only tested this on sp_help, but I figured that was enough. FYI, this patch does not have this effect on MS SQL 2008's sp_help sproc. John sqsh> sp_help Movetype (1 row affected) Name Owner Object_type -------------------------------- -------------------- ---------------------------------------- Movetype dbo user table Column_name Type Length Pre ------------------------------------------------ ---------------- ------------------------ --- movetype char 2 NUL move_desc char 20 NUL move_revenue bit 1 NUL (1 row affected) (1 row affected) (1 row affected) (0 rows affected) (1 row affected) (0 rows affected) (1 row affected) (1 row affected) (1 row affected) (1 row affected) (1 row affected) (1 row affected) (1 row affected) Object has the following indexes (1 row affected) (1 row affected) (1 row affected) (1 row affected) (1 row affected) (1 row affected) (1 row affected) (1 row affected) (0 rows affected) (8 rows affected) (1 row affected) (1 row affected) (1 row affected) (1 row affected) (1 row affected) (1 row affected) (1 row affected) (1 row affected) (1 row affected) (1 row affected) (1 row affected) (1 row affected) (1 row affected) (1 row affected) (1 row affected) (1 row affected) (1 row affected) (1 row affected) (1 row affected) (0 rows affected) ... etc From freddy77 at gmail.com Thu Apr 21 06:04:54 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Thu, 21 Apr 2016 11:04:54 +0100 Subject: [freetds] "Fix affected rows after insert with prepared query" side effect In-Reply-To: References: Message-ID: 2016-04-21 8:00 GMT+01:00 John Kendall : > On Oct 19, 2015 this patch was applied to ct.c: > > "Fix affected rows after insert with prepared query" > > This patch has the side-effect of a 'rows affected' being displayed for every select statement within a ASE stored procedure. For example, sp_help returns 136 extra 'rows affected' lines. See below. Backing out this patch stops this from happening. I only tested this on sp_help, but I figured that was enough. FYI, this patch does not have this effect on MS SQL 2008's sp_help sproc. > > John > I'm not sure if this is a regression or an improvement. I have to check what's the original CT-Library behaviour. Frediano > > sqsh> sp_help Movetype > (1 row affected) > Name Owner Object_type > -------------------------------- -------------------- ---------------------------------------- > Movetype dbo user table > > Column_name Type Length Pre > ------------------------------------------------ ---------------- ------------------------ --- > movetype char 2 NUL > move_desc char 20 NUL > move_revenue bit 1 NUL > > (1 row affected) > (1 row affected) > (1 row affected) > (0 rows affected) > (1 row affected) > (0 rows affected) > (1 row affected) > (1 row affected) > (1 row affected) > (1 row affected) > (1 row affected) > (1 row affected) > (1 row affected) > Object has the following indexes > > (1 row affected) > (1 row affected) > (1 row affected) > (1 row affected) > (1 row affected) > (1 row affected) > (1 row affected) > (1 row affected) > (0 rows affected) > (8 rows affected) > (1 row affected) > (1 row affected) > (1 row affected) > (1 row affected) > (1 row affected) > (1 row affected) > (1 row affected) > (1 row affected) > (1 row affected) > (1 row affected) > (1 row affected) > (1 row affected) > (1 row affected) > (1 row affected) > (1 row affected) > (1 row affected) > (1 row affected) > (1 row affected) > (1 row affected) > (0 rows affected) > ... etc > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From marsupilami79 at gmx.de Thu Apr 21 06:22:43 2016 From: marsupilami79 at gmx.de (Marsupilami79) Date: Thu, 21 Apr 2016 12:22:43 +0200 Subject: [freetds] Conversion emoji symbols to UTF-8 In-Reply-To: References: <5707F4EA-3A99-426A-83FB-ECF468720627@t-online.hu> Message-ID: <5718A9F3.9040800@gmx.de> Hello Frediano, Am 20.04.2016 um 12:13 schrieb Frediano Ziglio: > [...] just that you are using the trivial iconv provided with FreeTDS > which is not recommended. I just have to ask - why isn't it recommended to use the trivial iconv? Are there known bugs besides the trivial iconv supporting only Unicode and ISO8859-1? I host some freetds dblib dlls on the Zeoslib project site and for Win64 it is only the one with the trivial iconv as I have no clue on how to comple iconv for 64 bits. And I want to be prepared for bugreprts... With best regards, Jan From freddy77 at gmail.com Thu Apr 21 07:16:15 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Thu, 21 Apr 2016 12:16:15 +0100 Subject: [freetds] Conversion emoji symbols to UTF-8 In-Reply-To: <5718A9F3.9040800@gmx.de> References: <5707F4EA-3A99-426A-83FB-ECF468720627@t-online.hu> <5718A9F3.9040800@gmx.de> Message-ID: 2016-04-21 11:22 GMT+01:00 Marsupilami79 : > Hello Frediano, > > Am 20.04.2016 um 12:13 schrieb Frediano Ziglio: >> [...] just that you are using the trivial iconv provided with FreeTDS >> which is not recommended. > > I just have to ask - why isn't it recommended to use the trivial iconv? > Are there known bugs besides the trivial iconv supporting only Unicode > and ISO8859-1? None, but this means that you can loose some characters while using data which cannot store Unicode. The standard varchar in MSSQL for instance is encoded in CP1252 encoding which is similar to ISO8859-1 but for instance can contain the euro symbol while ISO8859-1 cannot. This means that when you have a UTF-8 client which wants to insert an euro symbol the euro symbol you could have a failure or the symbol inserted as '?' or just skipped. > I host some freetds dblib dlls on the Zeoslib project site and for Win64 > it is only the one with the trivial iconv as I have no clue on how to > comple iconv for 64 bits. And I want to be prepared for bugreprts... On AppVeyor Ramiros did a very good job using win-iconv library. You can find win-iconv releases at https://github.com/win-iconv/win-iconv/releases. > > With best regards, > > Jan Frediano From james.k.lowden at icloud.com Thu Apr 21 12:29:23 2016 From: james.k.lowden at icloud.com (James K. Lowden) Date: Thu, 21 Apr 2016 12:29:23 -0400 Subject: [freetds] Conversion emoji symbols to UTF-8 In-Reply-To: References: <5707F4EA-3A99-426A-83FB-ECF468720627@t-online.hu> <5718A9F3.9040800@gmx.de> Message-ID: <20160421122923.0daf2908cdce8891b2d59102@icloud.com> On Thu, 21 Apr 2016 12:16:15 +0100 Frediano Ziglio wrote: > This means that when you have a UTF-8 client which wants to insert an > euro symbol the euro symbol you could have a failure or the symbol > inserted as '?' or just skipped. Hmm, in db-lib at least it was the case that encoding errors were handled differently depending on direction. (Since I doubt that's changed, I switch to present tense.) If the data cannot be represented in the client's encoding, a '?' is substituted and the error handler called with warning severity. The function returns successfully. Sending data to the server, if the data cannot be converted to the server's encoding, no substitution occurs. No data are sent. The error handler is called and the function returns an error. The rationale IMO is that the library cannot corrupt the data en route to the server; whatever the server receives it must assume is what the client intended. OTOH when the client receives server data and cannot render them in its character set, the user may still be able to interpret the results and act on the warning. --jkl From craigberry at mac.com Thu Apr 21 18:47:01 2016 From: craigberry at mac.com (Craig A. Berry) Date: Thu, 21 Apr 2016 17:47:01 -0500 Subject: [freetds] OS X build dies, missing ssl.h Message-ID: <5851B374-E46B-4988-8A4C-CA51C7BEC511@mac.com> I just tried a build as of git ea27e5044071d2c on OS X 10.11.4 and it fell down hard with: Making all in . CC mem.lo In file included from mem.c:33: ../../include/freetds/tls.h:37:12: fatal error: 'openssl/ssl.h' file not found # include ^ 1 error generated. At configuration time it said: checking if openssl is wanted... yes checking for OPENSSL... yes which as far as I can tell is derived from running: $ pkg-config --exists --print-errors ?openssl" which returns nothing. So it thinks it has OpenSSL. But it seems Apple has long-since deprecated it: Is there something reasonable that could make configure not detect the unmaintained bits of the OpenSSL libraries that have no associated headers in current OS X? ________________________________________ Craig A. Berry "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser From john at capps.com Thu Apr 21 20:03:04 2016 From: john at capps.com (John Kendall) Date: Fri, 22 Apr 2016 00:03:04 +0000 Subject: [freetds] "Fix affected rows after insert with prepared query" side effect In-Reply-To: References: Message-ID: Thu, 21 Apr 2016 11:04:54 +0100 Frediano Ziglio > 2016-04-21 8:00 GMT+01:00 John Kendall : >> On Oct 19, 2015 this patch was applied to ct.c: >> >> "Fix affected rows after insert with prepared query" >> >> This patch has the side-effect of a 'rows affected' being displayed for every select statement within a ASE stored procedure. For example, sp_help returns 136 extra 'rows affected' lines. See below. Backing out this patch stops this from happening. I only tested this on sp_help, but I figured that was enough. FYI, this patch does not have this effect on MS SQL 2008's sp_help sproc. >> >> John >> > > I'm not sure if this is a regression or an improvement. I have to > check what's the original CT-Library behaviour. > > Frediano Hi, Frediano. I compiled sqsh against Sybase 16 libs and it does not return all those 'rows affected' lines. I could be reading it wrong, but in the archives, it appears the patch applied was not the one requested by Dave Nichols. http://lists.ibiblio.org/pipermail/freetds/2015q4/029631.html Could we remove that patch? Thanks, John >> >> sqsh> sp_help Movetype >> (1 row affected) >> Name Owner Object_type >> -------------------------------- -------------------- ---------------------------------------- >> Movetype dbo user table >> >> Column_name Type Length Pre >> ------------------------------------------------ ---------------- ------------------------ --- >> movetype char 2 NUL >> move_desc char 20 NUL >> move_revenue bit 1 NUL >> >> (1 row affected) >> (1 row affected) >> (1 row affected) >> (0 rows affected) >> (1 row affected) >> (0 rows affected) >> (1 row affected) >> (1 row affected) >> (1 row affected) >> (1 row affected) >> (1 row affected) >> (1 row affected) >> (1 row affected) >> Object has the following indexes >> >> (1 row affected) >> (1 row affected) >> (1 row affected) >> (1 row affected) >> (1 row affected) >> (1 row affected) >> (1 row affected) >> (1 row affected) >> (0 rows affected) >> (8 rows affected) >> (1 row affected) >> (1 row affected) >> (1 row affected) >> (1 row affected) >> (1 row affected) >> (1 row affected) >> (1 row affected) >> (1 row affected) >> (1 row affected) >> (1 row affected) >> (1 row affected) >> (1 row affected) >> (1 row affected) >> (1 row affected) >> (1 row affected) >> (1 row affected) >> (1 row affected) >> (1 row affected) >> (1 row affected) >> (0 rows affected) >> ... etc >> >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> http://lists.ibiblio.org/mailman/listinfo/freetds > From craigberry at mac.com Thu Apr 21 22:33:03 2016 From: craigberry at mac.com (Craig A. Berry) Date: Thu, 21 Apr 2016 21:33:03 -0500 Subject: [freetds] [PATCH] assorted VMS build fixes Message-ID: <5F22CEB6-4DDE-4C10-AD91-4E8350FDE1B3@mac.com> I tested 1.0rc1 on VMS and we weren?t far off but a few things were needed to build. Patches attached and commit messages here inline for convenience: commit 93304ab677b3da08b2818e6e67fd211759c65ee9 Author: Craig A. Berry Date: Thu Apr 21 16:56:57 2016 -0500 Be careful cleaning up .map files in VMS build. We were cleaning up linker map files in the whole build directory tree, but there are now .map files in the documentation that we should leave alone. commit fe7ea92c4fd1547d3bd1f4d5c18cb82989c486a5 Author: Craig A. Berry Date: Thu Apr 21 16:54:42 2016 -0500 Build sec_negotiate and strlcat replacements on VMS. commit 2698e4111ca463bebc0760311387aa5e804a2b04 Author: Craig A. Berry Date: Thu Apr 21 16:50:03 2016 -0500 Make TDSVER optional on VMS as on other platforms. commit 97853e13221e7ec47a2f1715f7008e51fc078dc3 Author: Craig A. Berry Date: Thu Apr 21 16:47:39 2016 -0500 Daemonize based on HAVE_FORK, not _WIN32. Because fork() is the missing feature and VMS is also missing it. commit 01b82baa85a5318524e2a210e4983df8b725c5b9 Author: Craig A. Berry Date: Thu Apr 21 16:46:03 2016 -0500 Meet boolean expectations with boolean expressions in pool. We were sending pointers as booleans, which a picky compiler may warn about. ________________________________________ Craig A. Berry mailto:craigberry at mac.com "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Meet-boolean-expectations-with-boolean-expressions-i.patch Type: application/octet-stream Size: 1030 bytes Desc: not available URL: -------------- next part -------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Daemonize-based-on-HAVE_FORK-not-_WIN32.patch Type: application/octet-stream Size: 1084 bytes Desc: not available URL: -------------- next part -------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Make-TDSVER-optional-on-VMS-as-on-other-platforms.patch Type: application/octet-stream Size: 2492 bytes Desc: not available URL: -------------- next part -------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Build-sec_negotiate-and-strlcat-replacements-on-VMS.patch Type: application/octet-stream Size: 1266 bytes Desc: not available URL: -------------- next part -------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-Be-careful-cleaning-up-.map-files-in-VMS-build.patch Type: application/octet-stream Size: 1347 bytes Desc: not available URL: From freddy77 at gmail.com Fri Apr 22 05:22:01 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Fri, 22 Apr 2016 10:22:01 +0100 Subject: [freetds] [PATCH] assorted VMS build fixes In-Reply-To: <5F22CEB6-4DDE-4C10-AD91-4E8350FDE1B3@mac.com> References: <5F22CEB6-4DDE-4C10-AD91-4E8350FDE1B3@mac.com> Message-ID: Applied! Thanks, Frediano 2016-04-22 3:33 GMT+01:00 Craig A. Berry : > I tested 1.0rc1 on VMS and we weren?t far off but a few things were needed to build. Patches attached and commit messages here inline for convenience: > > commit 93304ab677b3da08b2818e6e67fd211759c65ee9 > Author: Craig A. Berry > Date: Thu Apr 21 16:56:57 2016 -0500 > > Be careful cleaning up .map files in VMS build. > > We were cleaning up linker map files in the whole build directory > tree, but there are now .map files in the documentation that we > should leave alone. > > commit fe7ea92c4fd1547d3bd1f4d5c18cb82989c486a5 > Author: Craig A. Berry > Date: Thu Apr 21 16:54:42 2016 -0500 > > Build sec_negotiate and strlcat replacements on VMS. > > commit 2698e4111ca463bebc0760311387aa5e804a2b04 > Author: Craig A. Berry > Date: Thu Apr 21 16:50:03 2016 -0500 > > Make TDSVER optional on VMS as on other platforms. > > commit 97853e13221e7ec47a2f1715f7008e51fc078dc3 > Author: Craig A. Berry > Date: Thu Apr 21 16:47:39 2016 -0500 > > Daemonize based on HAVE_FORK, not _WIN32. > > Because fork() is the missing feature and VMS is also missing it. > > commit 01b82baa85a5318524e2a210e4983df8b725c5b9 > Author: Craig A. Berry > Date: Thu Apr 21 16:46:03 2016 -0500 > > Meet boolean expectations with boolean expressions in pool. > > We were sending pointers as booleans, which a picky compiler may > warn about. > > > > ________________________________________ > Craig A. Berry > mailto:craigberry at mac.com > > "... getting out of a sonnet is much more > difficult than getting in." > Brad Leithauser > > > > > > > > > > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > From fredy at opag.ch Fri Apr 22 10:29:42 2016 From: fredy at opag.ch (Fredy Paquet) Date: Fri, 22 Apr 2016 16:29:42 +0200 Subject: [freetds] freebcp adding escaping In-Reply-To: <20160417182704.6f2b90ca9868615403166e0d@icloud.com> References: <56B184A9.1040603@smart-associates.biz> <20160417182704.6f2b90ca9868615403166e0d@icloud.com> Message-ID: <1461335382.7148.25.camel@montesa> Hello James Your CSV parser is very interesting, but it doesn't seem to handle the ugly quoting rules for CSV correctly. Also newline within a text field isn't processed correctly. Isn't there any better implementation around ? fp -- Fredy Paquet Mitglied der Gesch?ftsleitung OPAG Informatik AG Fabrikmattenweg 11 CH-4144 Arlesheim http://www.opag.ch Tel. ++41 61 716 92 22 Fax. ++41 61 716 92 29 On Sun, 2016-04-17 at 18:27 -0400, James K. Lowden wrote: > On Wed, 3 Feb 2016 15:40:09 +1100 > Andrew Punch wrote: > > > 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 disagree with Frediano; I think freebcp is the right place to add csv > support. But if I were in his shoes, I'd be reluctant to take your > patch without quite a bit more work and testing. > > It's not true that freebcp handles escape characters incorrectly. > freebcp *defines* its text-file formats, and that definition doesn't > include an escape mechanism. The column and row delimiters are strings > (not single characters). Any character sequence that does not > appear in the data will serve. ASCII includes US and RS codes (31 and > 30) which were intended for the purpose. (It would be a nice addition > to support them as named escapes for the -r and -t options of > freebcp.) > > The reason I'd be reluctant to apply your patch is that CSV is a > complex format. It's defined, sort of, by an RFC, but there are many > de facto variations on that theme, including using tabs instead of > commas as delimiters (in a Comma-Separated Variable format!) > > To parse CSV correctly, you need to parse it as a context-free > language. Regular expressions aren't good enough, and an ad hoc > work-for-me hack will likely be frustrating to users and developers > both. > > If you want to do the job correctly, then, you need to write or import > a parser for CSV grammar. As it happens, I've written one that could > perhaps be adapted and that I would be willing to contribute to the > FreeTDS project (http://www.schemamania.org/sql/sqlite/udf/). It's > certainly not the only one. It doesn't handle every variation, but it > did pass tests I found that were provided by another csv-parser as > examples. Let me know if you're interested. > > To answer your other questions: > > > 1. is dblib the best place to make the change? > > If so, it would be in the bcp functions. > > > 2. what is the best structure to pass parameters and flags? Namely: > > 1. Flag for delimiter escaping > > Please elaborate. > > > 2. The actual delimiter (I notice that the column delimiter > > changes to EOL for the last column) > > If you want to last column to include the column *separator*, define > your row separator to include it. For example, > > -t \\t -r\\t\\n > > would do the job. > > > 3. Flag for NULL string replacement (instead of ASCII NUL) > > 4. NULL string replacement > > This is a separate issue, and could go two ways: either convert > an external string to NULL in the database, or convert missing > external data to a particular string in the database. The only real > challenge is to define the freebcp option syntax; internally, it's just > a few calls to bcp_colfmt. > > HTH. > > --jkl > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3866 bytes Desc: not available URL: From freddy77 at gmail.com Fri Apr 22 10:48:57 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Fri, 22 Apr 2016 15:48:57 +0100 Subject: [freetds] OS X build dies, missing ssl.h In-Reply-To: <5851B374-E46B-4988-8A4C-CA51C7BEC511@mac.com> References: <5851B374-E46B-4988-8A4C-CA51C7BEC511@mac.com> Message-ID: 2016-04-21 23:47 GMT+01:00 Craig A. Berry : > I just tried a build as of git ea27e5044071d2c on OS X 10.11.4 and it fell down hard with: > > Making all in . > CC mem.lo > In file included from mem.c:33: > ../../include/freetds/tls.h:37:12: fatal error: 'openssl/ssl.h' file not found > # include > ^ > 1 error generated. > > At configuration time it said: > > checking if openssl is wanted... yes > checking for OPENSSL... yes > > which as far as I can tell is derived from running: > > $ pkg-config --exists --print-errors ?openssl" > > which returns nothing. So it thinks it has OpenSSL. But it seems Apple has long-since deprecated it: > > > > Is there something reasonable that could make configure not detect the unmaintained bits of the OpenSSL libraries that have no associated headers in current OS X? > So... Mac OS X removed the possibility to use the SSL part of OpenSSL project but they still say that the library is present and working? Looks like a bug to me. I think the "solution" would be to do a more accurate check (check that a small SSL_read test can be compiled and linked correctly including the openssl/ssl.h header). The mail suggest to use a different library. Not that easy to do. Is anyway GnuTLS an option (is it installed by default in Mac OS X) ? Frediano From freddy77 at gmail.com Fri Apr 22 12:19:54 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Fri, 22 Apr 2016 17:19:54 +0100 Subject: [freetds] OS X build dies, missing ssl.h In-Reply-To: References: <5851B374-E46B-4988-8A4C-CA51C7BEC511@mac.com> Message-ID: 2016-04-22 15:48 GMT+01:00 Frediano Ziglio : > 2016-04-21 23:47 GMT+01:00 Craig A. Berry : >> I just tried a build as of git ea27e5044071d2c on OS X 10.11.4 and it fell down hard with: >> >> Making all in . >> CC mem.lo >> In file included from mem.c:33: >> ../../include/freetds/tls.h:37:12: fatal error: 'openssl/ssl.h' file not found >> # include >> ^ >> 1 error generated. >> >> At configuration time it said: >> >> checking if openssl is wanted... yes >> checking for OPENSSL... yes >> >> which as far as I can tell is derived from running: >> >> $ pkg-config --exists --print-errors ?openssl" >> >> which returns nothing. So it thinks it has OpenSSL. But it seems Apple has long-since deprecated it: >> >> >> >> Is there something reasonable that could make configure not detect the unmaintained bits of the OpenSSL libraries that have no associated headers in current OS X? >> > > > So... Mac OS X removed the possibility to use the SSL part of OpenSSL > project but they still say that the library is present and working? > Looks like a bug to me. > > I think the "solution" would be to do a more accurate check (check > that a small SSL_read test can be compiled and linked correctly > including the openssl/ssl.h header). > The mail suggest to use a different library. Not that easy to do. Is > anyway GnuTLS an option (is it installed by default in Mac OS X) ? > Craig, can you try current master version? Did some improvements on OpenSSL detection. Frediano From craigberry at mac.com Fri Apr 22 13:49:23 2016 From: craigberry at mac.com (Craig A. Berry) Date: Fri, 22 Apr 2016 12:49:23 -0500 Subject: [freetds] OS X build dies, missing ssl.h In-Reply-To: References: <5851B374-E46B-4988-8A4C-CA51C7BEC511@mac.com> Message-ID: <4134B89F-7911-4FFA-A3DF-8EB68DF08F16@mac.com> > On Apr 22, 2016, at 11:19 AM, Frediano Ziglio wrote: > > 2016-04-22 15:48 GMT+01:00 Frediano Ziglio : >> 2016-04-21 23:47 GMT+01:00 Craig A. Berry : >>> >>> Is there something reasonable that could make configure not detect the unmaintained bits of the OpenSSL libraries that have no associated headers in current OS X? >>> >> >> >> So... Mac OS X removed the possibility to use the SSL part of OpenSSL >> project but they still say that the library is present and working? >> Looks like a bug to me. They did it this way intentionally. The library is still there for existing applications that have already linked against it, but the headers have been removed to prevent developers from building new applications using it. Given that the OpenSSL API has been a moving target that has broken binary compatibility, their solution, while a bit extreme, is not completely insane. >> I think the "solution" would be to do a more accurate check (check >> that a small SSL_read test can be compiled and linked correctly >> including the openssl/ssl.h header). >> The mail suggest to use a different library. Not that easy to do. Is >> anyway GnuTLS an option (is it installed by default in Mac OS X) ? No, there?s no GnuTLS by default. I believe it can be built from source and OpenSSL definitely can for people who need it. > Craig, > can you try current master version? > > Did some improvements on OpenSSL detection. That did the trick, thanks: $ grep SSL include/config.h /* Define if you have the OpenSSL. */ /* #undef HAVE_OPENSSL */ On to the next build failure. ________________________________________ Craig A. Berry mailto:craigberry at mac.com "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser From freddy77 at gmail.com Sat Apr 23 08:04:06 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Sat, 23 Apr 2016 13:04:06 +0100 Subject: [freetds] "Fix affected rows after insert with prepared query" side effect In-Reply-To: References: Message-ID: 2016-04-22 1:03 GMT+01:00 John Kendall : > Thu, 21 Apr 2016 11:04:54 +0100 Frediano Ziglio > >> 2016-04-21 8:00 GMT+01:00 John Kendall : >>> On Oct 19, 2015 this patch was applied to ct.c: >>> >>> "Fix affected rows after insert with prepared query" >>> >>> This patch has the side-effect of a 'rows affected' being displayed for every select statement within a ASE stored procedure. For example, sp_help returns 136 extra 'rows affected' lines. See below. Backing out this patch stops this from happening. I only tested this on sp_help, but I figured that was enough. FYI, this patch does not have this effect on MS SQL 2008's sp_help sproc. >>> >>> John >>> >> >> I'm not sure if this is a regression or an improvement. I have to >> check what's the original CT-Library behaviour. >> >> Frediano > > Hi, Frediano. > > I compiled sqsh against Sybase 16 libs and it does not return all those 'rows affected' lines. > I could be reading it wrong, but in the archives, it appears the patch applied was not the one requested by Dave Nichols. > There was another patch that make the change the same. > http://lists.ibiblio.org/pipermail/freetds/2015q4/029631.html > > Could we remove that patch? > I don't think so. But probably the patch fixed an issue and introduced a problem so we should find a solution. I think that Dave/Ondrei wanted to have the row number returned by a DONEINPROC in the case of a prepared statement. This does not mean they want all DONEINPROC from the server. Basically - before: no DONEINPROC - after: all DONEINPROC - wanted (you): one DONEINPROC (which one and how still to be defined) Does this make sense? > Thanks, > John > > I think this is the only no-build issue we had since the 1.0 RC. Not bad! Frediano > >>> >>> sqsh> sp_help Movetype >>> (1 row affected) >>> Name Owner Object_type >>> -------------------------------- -------------------- ---------------------------------------- >>> Movetype dbo user table >>> >>> Column_name Type Length Pre >>> ------------------------------------------------ ---------------- ------------------------ --- >>> movetype char 2 NUL >>> move_desc char 20 NUL >>> move_revenue bit 1 NUL >>> >>> (1 row affected) >>> (1 row affected) >>> (1 row affected) >>> (0 rows affected) >>> (1 row affected) >>> (0 rows affected) >>> (1 row affected) >>> (1 row affected) >>> (1 row affected) >>> (1 row affected) >>> (1 row affected) >>> (1 row affected) >>> (1 row affected) >>> Object has the following indexes >>> >>> (1 row affected) >>> (1 row affected) >>> (1 row affected) >>> (1 row affected) >>> (1 row affected) >>> (1 row affected) >>> (1 row affected) >>> (1 row affected) >>> (0 rows affected) >>> (8 rows affected) >>> (1 row affected) >>> (1 row affected) >>> (1 row affected) >>> (1 row affected) >>> (1 row affected) >>> (1 row affected) >>> (1 row affected) >>> (1 row affected) >>> (1 row affected) >>> (1 row affected) >>> (1 row affected) >>> (1 row affected) >>> (1 row affected) >>> (1 row affected) >>> (1 row affected) >>> (1 row affected) >>> (1 row affected) >>> (1 row affected) >>> (1 row affected) >>> (0 rows affected) >>> ... etc >>> From james.k.lowden at icloud.com Sat Apr 23 14:04:33 2016 From: james.k.lowden at icloud.com (James K. Lowden) Date: Sat, 23 Apr 2016 14:04:33 -0400 Subject: [freetds] freebcp adding escaping In-Reply-To: <1461335382.7148.25.camel@montesa> References: <56B184A9.1040603@smart-associates.biz> <20160417182704.6f2b90ca9868615403166e0d@icloud.com> <1461335382.7148.25.camel@montesa> Message-ID: <20160423140433.2d8718fd616a15d2dc92010a@icloud.com> On Fri, 22 Apr 2016 16:29:42 +0200 Fredy Paquet wrote: > Your CSV parser is very interesting, but it doesn't seem to handle > the ugly quoting rules for CSV correctly. Also newline within a text > field isn't processed correctly. ... > Isn't there any better implementation around ? As mentioned in the man page, you might look at http://sourceforge.net/projects/libcsv/. I don't remember why I wrote my own implementation, other than wanting to try my hand at writing a parser. Again, if there is interest in incorporating the feature in FreeTDS, I would be willing to polish it up. The challenge, btw, isn't so much to parse standard CSV files correctly. The challenge is that, in practice, many CSV files don't conform to the standard, yet the library is expected to DTRT regardless. --jkl From john at capps.com Sun Apr 24 11:49:36 2016 From: john at capps.com (John Kendall) Date: Sun, 24 Apr 2016 15:49:36 +0000 Subject: [freetds] "Fix affected rows after insert with prepared query" side effec Message-ID: <21B66FC6-4DCE-4662-8E65-14886DC5CD67@capps.com> 2016-04-23 13:04 GMT+01:00 Frediano Ziglio : > 2016-04-22 1:03 GMT+01:00 John Kendall : > > > Thu, 21 Apr 2016 11:04:54 +0100 Frediano Ziglio > > > >> 2016-04-21 8:00 GMT+01:00 John Kendall : > >>> On Oct 19, 2015 this patch was applied to ct.c: > >>> > >>> "Fix affected rows after insert with prepared query" > >>> > >>> This patch has the side-effect of a 'rows affected' being displayed for every > >>> select statement within a ASE stored procedure. For example, sp_help returns > >>> 136 extra 'rows affected' lines. See below. Backing out this patch stops this from > >>> happening. I only tested this on sp_help, but I figured that was enough. FYI, this > >>> patch does not have this effect on MS SQL 2008's sp_help sproc. > >>> > >>> John > >>> > >> > >> I'm not sure if this is a regression or an improvement. I have to > >> check what's the original CT-Library behaviour. > >> > >> Frediano > > > > Hi, Frediano. > > > > I compiled sqsh against Sybase 16 libs and it does not return all those 'rows affected' > > lines. I could be reading it wrong, but in the archives, it appears the patch applied was > > not the one requested by David Nichols. > > > > There was another patch that make the change the same. > > > http://lists.ibiblio.org/pipermail/freetds/2015q4/029631.html > > > > Could we remove that patch? > > > > I don't think so. But probably the patch fixed an issue and introduced a problem > so we should find a solution. I think that Dave/Ondrei wanted to have the row > number returned by a DONEINPROC in the case of a prepared statement. This > does not mean they want all DONEINPROC from the server. > > Basically > - before: no DONEINPROC > - after: all DONEINPROC > - wanted (you): one DONEINPROC (which one and how still to be defined) > Does this make sense? Yes. As far as I can tell, it should only return the count for the last statement that could affect rows: http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.infocenter.dc32300.1570/html/sqlug/X31520.htm So, the last insert, delete or update, perhaps? > > Thanks, > > > John > > > > > > I think this is the only no-build issue we had since the 1.0 RC. Not bad! Frediano > > > >>> > >>> sqsh> sp_help Movetype > >>> (1 row affected) > >>> Name Owner Object_type > >>> -------------------------------- -------------------- ---------------------------------------- > >>> Movetype dbo user table > >>> > >>> Column_name Type Length Pre > >>> ------------------------------------------------ ---------------- ------------------------ --- > >>> movetype char 2 NUL > >>> move_desc char 20 NUL > >>> move_revenue bit 1 NUL > >>> > >>> (1 row affected) > >>> (1 row affected) > >>> (1 row affected) > >>> (0 rows affected) > >>> (1 row affected) > >>> (0 rows affected) > >>> (1 row affected) > >>> (1 row affected) > >>> (1 row affected) > >>> (1 row affected) > >>> (1 row affected) > >>> (1 row affected) > >>> (1 row affected) > >>> Object has the following indexes > >>> > >>> (1 row affected) > >>> (1 row affected) > >>> ... etc > >>> From john at capps.com Sun Apr 24 11:55:22 2016 From: john at capps.com (John Kendall) Date: Sun, 24 Apr 2016 15:55:22 +0000 Subject: [freetds] "Fix affected rows after insert with prepared query" side effect Message-ID: Sorry, my last post had the wrong link to sybase infocenter. 2016-04-23 13:04 GMT+01:00 Frediano Ziglio : > 2016-04-22 1:03 GMT+01:00 John Kendall : > >> Thu, 21 Apr 2016 11:04:54 +0100 Frediano Ziglio >> >>> 2016-04-21 8:00 GMT+01:00 John Kendall : >>>> On Oct 19, 2015 this patch was applied to ct.c: >>>> >>>> "Fix affected rows after insert with prepared query" >>>> >>>> This patch has the side-effect of a 'rows affected' being displayed for every >>>> select statement within a ASE stored procedure. For example, sp_help returns >>>> 136 extra 'rows affected' lines. See below. Backing out this patch stops this from >>>> happening. I only tested this on sp_help, but I figured that was enough. FYI, this >>>> patch does not have this effect on MS SQL 2008's sp_help sproc. >>>> >>>> John >>>> >>> >>> I'm not sure if this is a regression or an improvement. I have to >>> check what's the original CT-Library behaviour. >>> >>> Frediano >> >> Hi, Frediano. >> >> I compiled sqsh against Sybase 16 libs and it does not return all those 'rows affected' >> lines. I could be reading it wrong, but in the archives, it appears the patch applied was >> not the one requested by David Nichols. >> > > There was another patch that make the change the same. > >> http://lists.ibiblio.org/pipermail/freetds/2015q4/029631.html >> >> Could we remove that patch? >> > > I don't think so. But probably the patch fixed an issue and introduced a problem > so we should find a solution. I think that Dave/Ondrei wanted to have the row > number returned by a DONEINPROC in the case of a prepared statement. This > does not mean they want all DONEINPROC from the server. > > Basically > - before: no DONEINPROC > - after: all DONEINPROC > - wanted (you): one DONEINPROC (which one and how still to be defined) > Does this make sense? Yes. As far as I can tell, it should only return the count for the last statement that could affect rows: http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.infocenter.dc36065.1570/html/ctlibmig/X65200.htm So, the last insert, delete or update, perhaps? >> Thanks, > >> John >> >> > > I think this is the only no-build issue we had since the 1.0 RC. Not bad! Frediano > > >>>> >>>> sqsh> sp_help Movetype >>>> (1 row affected) >>>> Name Owner Object_type >>>> -------------------------------- -------------------- ---------------------------------------- >>>> Movetype dbo user table >>>> >>>> Column_name Type Length Pre >>>> ------------------------------------------------ ---------------- ------------------------ --- >>>> movetype char 2 NUL >>>> move_desc char 20 NUL >>>> move_revenue bit 1 NUL >>>> >>>> (1 row affected) >>>> (1 row affected) >>>> (1 row affected) >>>> (0 rows affected) >>>> (1 row affected) >>>> (0 rows affected) >>>> (1 row affected) >>>> (1 row affected) >>>> (1 row affected) >>>> (1 row affected) >>>> (1 row affected) >>>> (1 row affected) >>>> (1 row affected) >>>> Object has the following indexes >>>> >>>> (1 row affected) >>>> (1 row affected) >>>> ... etc >>>> From cruisercoder at gmail.com Sun Apr 24 11:53:09 2016 From: cruisercoder at gmail.com (Erik Smith) Date: Sun, 24 Apr 2016 08:53:09 -0700 Subject: [freetds] dbopen: avoiding config with direct host/port Message-ID: Is there currently a way to open a connection without referencing the config files? This has been asked before but it's unclear if this is possible: http://lists.ibiblio.org/pipermail/freetds/2010q4/026425.html There doesn't seem to be a way to do this using this call: DBPROCESS *dbopen(LOGINREC * login, const char *server) There are fields within LOGINREC (such as host & port) that could be used to override config, but that doesn't seem to be the way it was implemented. Any ideas? erik From ken at metaskills.net Sun Apr 24 15:58:55 2016 From: ken at metaskills.net (Ken Collins) Date: Sun, 24 Apr 2016 15:58:55 -0400 Subject: [freetds] Setting `login->use_utf16` With DBLIB Using Sybdb.h Message-ID: So I saw the news about `use utf-16 = true` via the conf file for 0.95 and how this is the default in 1.0 release candidate. However, I was wondering if there is a way I can set this long in bit using either an environment variable or some other means when compiling against sybdb.h?? ?- Thanks in advance, ? ? Ken Collins From jan.blom at peopleinteractive.se Sun Apr 24 18:23:06 2016 From: jan.blom at peopleinteractive.se (Jan Blom) Date: Sun, 24 Apr 2016 22:23:06 +0000 Subject: [freetds] osql exits with error on Linux Message-ID: Hello, The osql script fails to execute on CentOS (tested on release 6 & 7). We need to add "-F" to grep to avoid interpreting patterns as a reg exp. Patch attached. Best regards, Jan Blom -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: osql_patch.txt URL: From freddy77 at gmail.com Mon Apr 25 08:19:12 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Mon, 25 Apr 2016 13:19:12 +0100 Subject: [freetds] Setting `login->use_utf16` With DBLIB Using Sybdb.h In-Reply-To: References: Message-ID: 2016-04-24 20:58 GMT+01:00 Ken Collins : > So I saw the news about `use utf-16 = true` via the conf file for 0.95 and how this is the default in 1.0 release candidate. However, I was wondering if there is a way I can set this long in bit using either an environment variable or some other means when compiling against sybdb.h? > > - Thanks in advance, > Ken Collins An environment variable looks to much. An option to set using setlshort/setllong would make sense to me. Does it sound reasonable? I don't understand how you want to use this option. Frediano From alex.pulver at intel.com Mon Apr 25 08:26:46 2016 From: alex.pulver at intel.com (Pulver, Alex) Date: Mon, 25 Apr 2016 12:26:46 +0000 Subject: [freetds] Getting "Unexpected EOF from the server" when trying to connect to MS SQL Server 2014 Message-ID: <3D59976831C0404BB2EAC2485DB2316E60E12DB9@HASMSX106.ger.corp.intel.com> Hi all, I am trying to connect to MS SQL 2014 Server from SLES11 host, using FreeTDS 0.95.51 version and its tsql utility. The server uses "Standard Mode" (SQL Server Authentication) and I am able to connect from Windows using SQL Server 2014 Management Studio. Before sending this email I've read through FreeTDS troubleshooting, FAQ, domains page, config page, archives and various SO questions - tried the recommended configurations but with no luck (details below). The command being run is: env TDSVER=7.0 TDSDUMP=/tmp/tdsdump.log TDSDUMPCONFIG=/tmp/tdsdumpconfig.log ./src/apps/tsql -H -p -U -P -D The output: locale is "C" locale charset is "ANSI_X3.4-1968" using default charset "ISO-8859-1" Setting as default database in login packet Error 20017 (severity 9): Unexpected EOF from the server ... Tailing TDSDUMP along with the execution shows that error is happening after the login packet is sent and FreeTDS tries to process the login tokens: login.c:852:quietly sending TDS 7+ login packet token.c:327:tds_process_login_tokens() << Error 20017 (severity 9): Unexpected EOF from the server >> query.c:3772:tds_disconnect() Looking on strace seems to confirm that server disconnects after login packet is received (poll() returns positive after sendto(), but recvfrom() returns 0): write(5, "login.c:852:quietly sending TDS "..., 48) = 48 ... poll([{fd=6, events=POLLOUT}, {fd=4, events=POLLIN}], 2, -1) = 1 ([{fd=6, revents=POLLOUT}]) sendto(6, "\20\1\0012\0\0\0\0*\1\0\0\0\0\0p\0\20\0\0\6\203\362\370U\354\0\0\0\0\0\0"..., 306, MSG_NOSIGNAL, NULL, 0) = 306 write(5, "token.c:327:tds_process_login_to"..., 39) = 39 poll([{fd=6, events=POLLIN}, {fd=4, events=POLLIN}], 2, -1) = 1 ([{fd=6, revents=POLLIN}]) recvfrom(6, "", 8, MSG_NOSIGNAL, NULL, NULL) = 0 write(5, "query.c:3772:tds_disconnect() \n", 31) = 31 Things I tried listed in no particular order (assuming the issue is with authentication and not network): * Use UTF-8 encoding * Disable SSPI: ./configure --disable-sspi (so that trusted authentication will not be triggered) * Compile with latest OpenSSL version we have installed: ./configure --with-openssl=/.../openssl/1.0.1/bin/openssl * Explicitly disable OpenSSL: ./configure --without-openssl * Modifying the code in ./src/tds/mem.c to disable check_ssl_hostname by setting it to 0 in both places it appears (assuming it triggers checking server's SSL certificate and fails to authenticate). Verified using debugger that *((tds)->login) object has check_ssl_hostname set to 0 * Modifying the code in ./src/tds/tls.c to change location of certificates pointed by ca_directory[] to a directory I know we have updated internal certificates Things I still need to check with MS SQL Server admins: * Try to see if they can give me access to server-side log for my connection attempts * Check if server requires two-way authentication for SQL Server Authentication - doesn't seem like it, but I will check If someone has any other ideas as to why the connection drops, or other things I can do to investigate further, I would really appreciate that! Thanks! Alex --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. From ikorot01 at gmail.com Mon Apr 25 09:49:25 2016 From: ikorot01 at gmail.com (Igor Korot) Date: Mon, 25 Apr 2016 09:49:25 -0400 Subject: [freetds] Getting "Unexpected EOF from the server" when trying to connect to MS SQL Server 2014 In-Reply-To: <3D59976831C0404BB2EAC2485DB2316E60E12DB9@HASMSX106.ger.corp.intel.com> References: <3D59976831C0404BB2EAC2485DB2316E60E12DB9@HASMSX106.ger.corp.intel.com> Message-ID: Hi, Alex, On Mon, Apr 25, 2016 at 8:26 AM, Pulver, Alex wrote: > Hi all, > > I am trying to connect to MS SQL 2014 Server from SLES11 host, using FreeTDS 0.95.51 version and its tsql utility. The server uses "Standard Mode" (SQL Server Authentication) and I am able to connect from Windows using SQL Server 2014 Management Studio. > Before sending this email I've read through FreeTDS troubleshooting, FAQ, domains page, config page, archives and various SO questions - tried the recommended configurations but with no luck (details below). Did you try telnet'ting to the machine/port? This will eliminate the network/firewall issues... Thank you. > > The command being run is: > env TDSVER=7.0 TDSDUMP=/tmp/tdsdump.log TDSDUMPCONFIG=/tmp/tdsdumpconfig.log ./src/apps/tsql -H -p -U -P -D > > The output: > locale is "C" > locale charset is "ANSI_X3.4-1968" > using default charset "ISO-8859-1" > Setting as default database in login packet > Error 20017 (severity 9): > Unexpected EOF from the server > ... > > Tailing TDSDUMP along with the execution shows that error is happening after the login packet is sent and FreeTDS tries to process the login tokens: > login.c:852:quietly sending TDS 7+ login packet > token.c:327:tds_process_login_tokens() > << > Error 20017 (severity 9): > Unexpected EOF from the server >>> > query.c:3772:tds_disconnect() > > Looking on strace seems to confirm that server disconnects after login packet is received (poll() returns positive after sendto(), but recvfrom() returns 0): > write(5, "login.c:852:quietly sending TDS "..., 48) = 48 > ... > poll([{fd=6, events=POLLOUT}, {fd=4, events=POLLIN}], 2, -1) = 1 ([{fd=6, revents=POLLOUT}]) > sendto(6, "\20\1\0012\0\0\0\0*\1\0\0\0\0\0p\0\20\0\0\6\203\362\370U\354\0\0\0\0\0\0"..., 306, MSG_NOSIGNAL, NULL, 0) = 306 > write(5, "token.c:327:tds_process_login_to"..., 39) = 39 > poll([{fd=6, events=POLLIN}, {fd=4, events=POLLIN}], 2, -1) = 1 ([{fd=6, revents=POLLIN}]) > recvfrom(6, "", 8, MSG_NOSIGNAL, NULL, NULL) = 0 > write(5, "query.c:3772:tds_disconnect() \n", 31) = 31 > > Things I tried listed in no particular order (assuming the issue is with authentication and not network): > * Use UTF-8 encoding > * Disable SSPI: ./configure --disable-sspi (so that trusted authentication will not be triggered) > * Compile with latest OpenSSL version we have installed: ./configure --with-openssl=/.../openssl/1.0.1/bin/openssl > * Explicitly disable OpenSSL: ./configure --without-openssl > * Modifying the code in ./src/tds/mem.c to disable check_ssl_hostname by setting it to 0 in both places it appears (assuming it triggers checking server's SSL certificate and fails to authenticate). Verified using debugger that *((tds)->login) object has check_ssl_hostname set to 0 > * Modifying the code in ./src/tds/tls.c to change location of certificates pointed by ca_directory[] to a directory I know we have updated internal certificates > > Things I still need to check with MS SQL Server admins: > * Try to see if they can give me access to server-side log for my connection attempts > * Check if server requires two-way authentication for SQL Server Authentication - doesn't seem like it, but I will check > > If someone has any other ideas as to why the connection drops, or other things I can do to investigate further, I would really appreciate that! > > Thanks! > Alex > --------------------------------------------------------------------- > Intel Israel (74) Limited > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From freddy77 at gmail.com Mon Apr 25 10:14:28 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Mon, 25 Apr 2016 15:14:28 +0100 Subject: [freetds] Getting "Unexpected EOF from the server" when trying to connect to MS SQL Server 2014 In-Reply-To: <3D59976831C0404BB2EAC2485DB2316E60E12DB9@HASMSX106.ger.corp.intel.com> References: <3D59976831C0404BB2EAC2485DB2316E60E12DB9@HASMSX106.ger.corp.intel.com> Message-ID: 2016-04-25 13:26 GMT+01:00 Pulver, Alex : > Hi all, > > I am trying to connect to MS SQL 2014 Server from SLES11 host, using FreeTDS 0.95.51 version and its tsql utility. The server uses "Standard Mode" (SQL Server Authentication) and I am able to connect from Windows using SQL Server 2014 Management Studio. > Before sending this email I've read through FreeTDS troubleshooting, FAQ, domains page, config page, archives and various SO questions - tried the recommended configurations but with no luck (details below). > > The command being run is: > env TDSVER=7.0 TDSDUMP=/tmp/tdsdump.log TDSDUMPCONFIG=/tmp/tdsdumpconfig.log ./src/apps/tsql -H -p -U -P -D > I would try with at least 7.2 version. > The output: > locale is "C" > locale charset is "ANSI_X3.4-1968" > using default charset "ISO-8859-1" > Setting as default database in login packet > Error 20017 (severity 9): > Unexpected EOF from the server > ... > > Tailing TDSDUMP along with the execution shows that error is happening after the login packet is sent and FreeTDS tries to process the login tokens: > login.c:852:quietly sending TDS 7+ login packet > token.c:327:tds_process_login_tokens() > << > Error 20017 (severity 9): > Unexpected EOF from the server >>> > query.c:3772:tds_disconnect() > > Looking on strace seems to confirm that server disconnects after login packet is received (poll() returns positive after sendto(), but recvfrom() returns 0): > write(5, "login.c:852:quietly sending TDS "..., 48) = 48 > ... > poll([{fd=6, events=POLLOUT}, {fd=4, events=POLLIN}], 2, -1) = 1 ([{fd=6, revents=POLLOUT}]) > sendto(6, "\20\1\0012\0\0\0\0*\1\0\0\0\0\0p\0\20\0\0\6\203\362\370U\354\0\0\0\0\0\0"..., 306, MSG_NOSIGNAL, NULL, 0) = 306 > write(5, "token.c:327:tds_process_login_to"..., 39) = 39 This means that server rejected the login. Like user/password wrong. Are you using Kerberos/SSPI or SQL logins? > poll([{fd=6, events=POLLIN}, {fd=4, events=POLLIN}], 2, -1) = 1 ([{fd=6, revents=POLLIN}]) > recvfrom(6, "", 8, MSG_NOSIGNAL, NULL, NULL) = 0 > write(5, "query.c:3772:tds_disconnect() \n", 31) = 31 > > Things I tried listed in no particular order (assuming the issue is with authentication and not network): > * Use UTF-8 encoding This would change if you have extra ASCII in your username/password. > * Disable SSPI: ./configure --disable-sspi (so that trusted authentication will not be triggered) SSPI is supported only in Windows so it's not affecting your build. > * Compile with latest OpenSSL version we have installed: ./configure --with-openssl=/.../openssl/1.0.1/bin/openssl > * Explicitly disable OpenSSL: ./configure --without-openssl > * Modifying the code in ./src/tds/mem.c to disable check_ssl_hostname by setting it to 0 in both places it appears (assuming it triggers checking server's SSL certificate and fails to authenticate). Verified using debugger that *((tds)->login) object has check_ssl_hostname set to 0 > * Modifying the code in ./src/tds/tls.c to change location of certificates pointed by ca_directory[] to a directory I know we have updated internal certificates > No, the check is done by FreeTDS, in this case the server is disconnecting. > Things I still need to check with MS SQL Server admins: > * Try to see if they can give me access to server-side log for my connection attempts > * Check if server requires two-way authentication for SQL Server Authentication - doesn't seem like it, but I will check > > If someone has any other ideas as to why the connection drops, or other things I can do to investigate further, I would really appreciate that! > You could try increasing the log level (see "debug flags" in http://www.freetds.org/userguide/freetdsconf.htm). Also I would try the "use ntlmv2" flag (same page above). > Thanks! > Alex Frediano From alex.pulver at intel.com Mon Apr 25 10:18:51 2016 From: alex.pulver at intel.com (Pulver, Alex) Date: Mon, 25 Apr 2016 14:18:51 +0000 Subject: [freetds] Getting "Unexpected EOF from the server" when trying to connect to MS SQL Server 2014 In-Reply-To: References: <3D59976831C0404BB2EAC2485DB2316E60E12DB9@HASMSX106.ger.corp.intel.com> Message-ID: <3D59976831C0404BB2EAC2485DB2316E60E12E65@HASMSX106.ger.corp.intel.com> Hi Igor, Yes, telnet is working: > telnet 3180 Trying ... Connected to . Escape character is '^]'. Regards, Alex Software Engineering Consultant Design & Technology Solutions (DTS) | Corporate Design Solutions (CDS) Hardware Design Kit (HDK): goto/hdk | Support: goto/dtsservices -----Original Message----- From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of Igor Korot Sent: Monday, April 25, 2016 16:49 To: FreeTDS Development Group Subject: Re: [freetds] Getting "Unexpected EOF from the server" when trying to connect to MS SQL Server 2014 Hi, Alex, On Mon, Apr 25, 2016 at 8:26 AM, Pulver, Alex wrote: > Hi all, > > I am trying to connect to MS SQL 2014 Server from SLES11 host, using FreeTDS 0.95.51 version and its tsql utility. The server uses "Standard Mode" (SQL Server Authentication) and I am able to connect from Windows using SQL Server 2014 Management Studio. > Before sending this email I've read through FreeTDS troubleshooting, FAQ, domains page, config page, archives and various SO questions - tried the recommended configurations but with no luck (details below). Did you try telnet'ting to the machine/port? This will eliminate the network/firewall issues... Thank you. > > The command being run is: > env TDSVER=7.0 TDSDUMP=/tmp/tdsdump.log TDSDUMPCONFIG=/tmp/tdsdumpconfig.log ./src/apps/tsql -H -p -U -P -D > > The output: > locale is "C" > locale charset is "ANSI_X3.4-1968" > using default charset "ISO-8859-1" > Setting as default database in login packet > Error 20017 (severity 9): > Unexpected EOF from the server > ... > > Tailing TDSDUMP along with the execution shows that error is happening after the login packet is sent and FreeTDS tries to process the login tokens: > login.c:852:quietly sending TDS 7+ login packet > token.c:327:tds_process_login_tokens() > << > Error 20017 (severity 9): > Unexpected EOF from the server >>> > query.c:3772:tds_disconnect() > > Looking on strace seems to confirm that server disconnects after login packet is received (poll() returns positive after sendto(), but recvfrom() returns 0): > write(5, "login.c:852:quietly sending TDS "..., 48) = 48 > ... > poll([{fd=6, events=POLLOUT}, {fd=4, events=POLLIN}], 2, -1) = 1 ([{fd=6, revents=POLLOUT}]) > sendto(6, "\20\1\0012\0\0\0\0*\1\0\0\0\0\0p\0\20\0\0\6\203\362\370U\354\0\0\0\0\0\0"..., 306, MSG_NOSIGNAL, NULL, 0) = 306 > write(5, "token.c:327:tds_process_login_to"..., 39) = 39 > poll([{fd=6, events=POLLIN}, {fd=4, events=POLLIN}], 2, -1) = 1 ([{fd=6, revents=POLLIN}]) > recvfrom(6, "", 8, MSG_NOSIGNAL, NULL, NULL) = 0 > write(5, "query.c:3772:tds_disconnect() \n", 31) = 31 > > Things I tried listed in no particular order (assuming the issue is with authentication and not network): > * Use UTF-8 encoding > * Disable SSPI: ./configure --disable-sspi (so that trusted authentication will not be triggered) > * Compile with latest OpenSSL version we have installed: ./configure --with-openssl=/.../openssl/1.0.1/bin/openssl > * Explicitly disable OpenSSL: ./configure --without-openssl > * Modifying the code in ./src/tds/mem.c to disable check_ssl_hostname by setting it to 0 in both places it appears (assuming it triggers checking server's SSL certificate and fails to authenticate). Verified using debugger that *((tds)->login) object has check_ssl_hostname set to 0 > * Modifying the code in ./src/tds/tls.c to change location of certificates pointed by ca_directory[] to a directory I know we have updated internal certificates > > Things I still need to check with MS SQL Server admins: > * Try to see if they can give me access to server-side log for my connection attempts > * Check if server requires two-way authentication for SQL Server Authentication - doesn't seem like it, but I will check > > If someone has any other ideas as to why the connection drops, or other things I can do to investigate further, I would really appreciate that! > > Thanks! > Alex > --------------------------------------------------------------------- > Intel Israel (74) Limited > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > > _______________________________________________ > 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 --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. From alex.pulver at intel.com Mon Apr 25 10:38:56 2016 From: alex.pulver at intel.com (Pulver, Alex) Date: Mon, 25 Apr 2016 14:38:56 +0000 Subject: [freetds] Getting "Unexpected EOF from the server" when trying to connect to MS SQL Server 2014 In-Reply-To: References: <3D59976831C0404BB2EAC2485DB2316E60E12DB9@HASMSX106.ger.corp.intel.com> Message-ID: <3D59976831C0404BB2EAC2485DB2316E60E12E91@HASMSX106.ger.corp.intel.com> Thanks Frediano! Your input helped to resolve this :) The problem was combination of two things: * Our current FreeTDS installation was compiled with OpenSSL 0.9.8, and probably the server was using a newer version for handshake. * I was trying to use TDSVER=7.0 in all recent attempts, and didn't try to bump it again. To summarize, the following worked: * Compile FreeTDS with OpenSSL 1.0.1: ./configure --with-openssl=/.../openssl/1.0.1/bin/openssl * Try connecting with TDSVER=7.2 (8.0 also works of course): env TDSVER=8.0 /.../tsql -H -p -U -P -D Regards, Alex -----Original Message----- From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of Frediano Ziglio Sent: Monday, April 25, 2016 17:14 To: FreeTDS Development Group Subject: Re: [freetds] Getting "Unexpected EOF from the server" when trying to connect to MS SQL Server 2014 2016-04-25 13:26 GMT+01:00 Pulver, Alex : > Hi all, > > I am trying to connect to MS SQL 2014 Server from SLES11 host, using FreeTDS 0.95.51 version and its tsql utility. The server uses "Standard Mode" (SQL Server Authentication) and I am able to connect from Windows using SQL Server 2014 Management Studio. > Before sending this email I've read through FreeTDS troubleshooting, FAQ, domains page, config page, archives and various SO questions - tried the recommended configurations but with no luck (details below). > > The command being run is: > env TDSVER=7.0 TDSDUMP=/tmp/tdsdump.log TDSDUMPCONFIG=/tmp/tdsdumpconfig.log ./src/apps/tsql -H -p -U -P -D > I would try with at least 7.2 version. > The output: > locale is "C" > locale charset is "ANSI_X3.4-1968" > using default charset "ISO-8859-1" > Setting as default database in login packet > Error 20017 (severity 9): > Unexpected EOF from the server > ... > > Tailing TDSDUMP along with the execution shows that error is happening after the login packet is sent and FreeTDS tries to process the login tokens: > login.c:852:quietly sending TDS 7+ login packet > token.c:327:tds_process_login_tokens() > << > Error 20017 (severity 9): > Unexpected EOF from the server >>> > query.c:3772:tds_disconnect() > > Looking on strace seems to confirm that server disconnects after login packet is received (poll() returns positive after sendto(), but recvfrom() returns 0): > write(5, "login.c:852:quietly sending TDS "..., 48) = 48 > ... > poll([{fd=6, events=POLLOUT}, {fd=4, events=POLLIN}], 2, -1) = 1 ([{fd=6, revents=POLLOUT}]) > sendto(6, "\20\1\0012\0\0\0\0*\1\0\0\0\0\0p\0\20\0\0\6\203\362\370U\354\0\0\0\0\0\0"..., 306, MSG_NOSIGNAL, NULL, 0) = 306 > write(5, "token.c:327:tds_process_login_to"..., 39) = 39 This means that server rejected the login. Like user/password wrong. Are you using Kerberos/SSPI or SQL logins? > poll([{fd=6, events=POLLIN}, {fd=4, events=POLLIN}], 2, -1) = 1 ([{fd=6, revents=POLLIN}]) > recvfrom(6, "", 8, MSG_NOSIGNAL, NULL, NULL) = 0 > write(5, "query.c:3772:tds_disconnect() \n", 31) = 31 > > Things I tried listed in no particular order (assuming the issue is with authentication and not network): > * Use UTF-8 encoding This would change if you have extra ASCII in your username/password. > * Disable SSPI: ./configure --disable-sspi (so that trusted authentication will not be triggered) SSPI is supported only in Windows so it's not affecting your build. > * Compile with latest OpenSSL version we have installed: ./configure --with-openssl=/.../openssl/1.0.1/bin/openssl > * Explicitly disable OpenSSL: ./configure --without-openssl > * Modifying the code in ./src/tds/mem.c to disable check_ssl_hostname by setting it to 0 in both places it appears (assuming it triggers checking server's SSL certificate and fails to authenticate). Verified using debugger that *((tds)->login) object has check_ssl_hostname set to 0 > * Modifying the code in ./src/tds/tls.c to change location of certificates pointed by ca_directory[] to a directory I know we have updated internal certificates > No, the check is done by FreeTDS, in this case the server is disconnecting. > Things I still need to check with MS SQL Server admins: > * Try to see if they can give me access to server-side log for my connection attempts > * Check if server requires two-way authentication for SQL Server Authentication - doesn't seem like it, but I will check > > If someone has any other ideas as to why the connection drops, or other things I can do to investigate further, I would really appreciate that! > You could try increasing the log level (see "debug flags" in http://www.freetds.org/userguide/freetdsconf.htm). Also I would try the "use ntlmv2" flag (same page above). > Thanks! > Alex Frediano _______________________________________________ FreeTDS mailing list FreeTDS at lists.ibiblio.org http://lists.ibiblio.org/mailman/listinfo/freetds --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. From freddy77 at gmail.com Mon Apr 25 10:45:06 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Mon, 25 Apr 2016 15:45:06 +0100 Subject: [freetds] Getting "Unexpected EOF from the server" when trying to connect to MS SQL Server 2014 In-Reply-To: <3D59976831C0404BB2EAC2485DB2316E60E12E91@HASMSX106.ger.corp.intel.com> References: <3D59976831C0404BB2EAC2485DB2316E60E12DB9@HASMSX106.ger.corp.intel.com> <3D59976831C0404BB2EAC2485DB2316E60E12E91@HASMSX106.ger.corp.intel.com> Message-ID: 2016-04-25 15:38 GMT+01:00 Pulver, Alex : > Thanks Frediano! Your input helped to resolve this :) > > The problem was combination of two things: > * Our current FreeTDS installation was compiled with OpenSSL 0.9.8, and probably the server was using a newer version for handshake. > * I was trying to use TDSVER=7.0 in all recent attempts, and didn't try to bump it again. > > To summarize, the following worked: > * Compile FreeTDS with OpenSSL 1.0.1: ./configure --with-openssl=/.../openssl/1.0.1/bin/openssl > * Try connecting with TDSVER=7.2 (8.0 also works of course): env TDSVER=8.0 /.../tsql -H -p -U -P -D > > Regards, > Alex > Great! Please don't use 8.0 as a version. Microsoft renamed 8.0 to 7.1 quite a while ago. In FreeTDS 1.0 we removed support for this old (compatible) "8.0" version. So 7.2/7.3/7.4 are newer than the "8.0" (which is the MS SQL Server 2000 protocol). Frediano > > -----Original Message----- > From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of Frediano Ziglio > Sent: Monday, April 25, 2016 17:14 > To: FreeTDS Development Group > Subject: Re: [freetds] Getting "Unexpected EOF from the server" when trying to connect to MS SQL Server 2014 > > 2016-04-25 13:26 GMT+01:00 Pulver, Alex : >> Hi all, >> >> I am trying to connect to MS SQL 2014 Server from SLES11 host, using FreeTDS 0.95.51 version and its tsql utility. The server uses "Standard Mode" (SQL Server Authentication) and I am able to connect from Windows using SQL Server 2014 Management Studio. >> Before sending this email I've read through FreeTDS troubleshooting, FAQ, domains page, config page, archives and various SO questions - tried the recommended configurations but with no luck (details below). >> >> The command being run is: >> env TDSVER=7.0 TDSDUMP=/tmp/tdsdump.log TDSDUMPCONFIG=/tmp/tdsdumpconfig.log ./src/apps/tsql -H -p -U -P -D >> > > I would try with at least 7.2 version. > >> The output: >> locale is "C" >> locale charset is "ANSI_X3.4-1968" >> using default charset "ISO-8859-1" >> Setting as default database in login packet >> Error 20017 (severity 9): >> Unexpected EOF from the server >> ... >> >> Tailing TDSDUMP along with the execution shows that error is happening after the login packet is sent and FreeTDS tries to process the login tokens: >> login.c:852:quietly sending TDS 7+ login packet >> token.c:327:tds_process_login_tokens() >> << >> Error 20017 (severity 9): >> Unexpected EOF from the server >>>> >> query.c:3772:tds_disconnect() >> >> Looking on strace seems to confirm that server disconnects after login packet is received (poll() returns positive after sendto(), but recvfrom() returns 0): >> write(5, "login.c:852:quietly sending TDS "..., 48) = 48 >> ... >> poll([{fd=6, events=POLLOUT}, {fd=4, events=POLLIN}], 2, -1) = 1 ([{fd=6, revents=POLLOUT}]) >> sendto(6, "\20\1\0012\0\0\0\0*\1\0\0\0\0\0p\0\20\0\0\6\203\362\370U\354\0\0\0\0\0\0"..., 306, MSG_NOSIGNAL, NULL, 0) = 306 >> write(5, "token.c:327:tds_process_login_to"..., 39) = 39 > > This means that server rejected the login. Like user/password wrong. > Are you using Kerberos/SSPI or SQL logins? > >> poll([{fd=6, events=POLLIN}, {fd=4, events=POLLIN}], 2, -1) = 1 ([{fd=6, revents=POLLIN}]) >> recvfrom(6, "", 8, MSG_NOSIGNAL, NULL, NULL) = 0 >> write(5, "query.c:3772:tds_disconnect() \n", 31) = 31 >> >> Things I tried listed in no particular order (assuming the issue is with authentication and not network): >> * Use UTF-8 encoding > > This would change if you have extra ASCII in your username/password. > >> * Disable SSPI: ./configure --disable-sspi (so that trusted authentication will not be triggered) > > SSPI is supported only in Windows so it's not affecting your build. > >> * Compile with latest OpenSSL version we have installed: ./configure --with-openssl=/.../openssl/1.0.1/bin/openssl >> * Explicitly disable OpenSSL: ./configure --without-openssl >> * Modifying the code in ./src/tds/mem.c to disable check_ssl_hostname by setting it to 0 in both places it appears (assuming it triggers checking server's SSL certificate and fails to authenticate). Verified using debugger that *((tds)->login) object has check_ssl_hostname set to 0 >> * Modifying the code in ./src/tds/tls.c to change location of certificates pointed by ca_directory[] to a directory I know we have updated internal certificates >> > > No, the check is done by FreeTDS, in this case the server is disconnecting. > >> Things I still need to check with MS SQL Server admins: >> * Try to see if they can give me access to server-side log for my connection attempts >> * Check if server requires two-way authentication for SQL Server Authentication - doesn't seem like it, but I will check >> >> If someone has any other ideas as to why the connection drops, or other things I can do to investigate further, I would really appreciate that! >> > > You could try increasing the log level (see "debug flags" in > http://www.freetds.org/userguide/freetdsconf.htm). > Also I would try the "use ntlmv2" flag (same page above). > >> Thanks! >> Alex > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > --------------------------------------------------------------------- > Intel Israel (74) Limited > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From alex.pulver at intel.com Mon Apr 25 10:50:25 2016 From: alex.pulver at intel.com (Pulver, Alex) Date: Mon, 25 Apr 2016 14:50:25 +0000 Subject: [freetds] Getting "Unexpected EOF from the server" when trying to connect to MS SQL Server 2014 In-Reply-To: References: <3D59976831C0404BB2EAC2485DB2316E60E12DB9@HASMSX106.ger.corp.intel.com> <3D59976831C0404BB2EAC2485DB2316E60E12E91@HASMSX106.ger.corp.intel.com> Message-ID: <3D59976831C0404BB2EAC2485DB2316E60E12F17@HASMSX106.ger.corp.intel.com> That's also good to know - thanks! Regards, Alex Software Engineering Consultant Design & Technology Solutions (DTS) | Corporate Design Solutions (CDS) Hardware Design Kit (HDK): goto/hdk | Support: goto/dtsservices -----Original Message----- From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of Frediano Ziglio Sent: Monday, April 25, 2016 17:45 To: FreeTDS Development Group Subject: Re: [freetds] Getting "Unexpected EOF from the server" when trying to connect to MS SQL Server 2014 2016-04-25 15:38 GMT+01:00 Pulver, Alex : > Thanks Frediano! Your input helped to resolve this :) > > The problem was combination of two things: > * Our current FreeTDS installation was compiled with OpenSSL 0.9.8, and probably the server was using a newer version for handshake. > * I was trying to use TDSVER=7.0 in all recent attempts, and didn't try to bump it again. > > To summarize, the following worked: > * Compile FreeTDS with OpenSSL 1.0.1: ./configure --with-openssl=/.../openssl/1.0.1/bin/openssl > * Try connecting with TDSVER=7.2 (8.0 also works of course): env TDSVER=8.0 /.../tsql -H -p -U -P -D > > Regards, > Alex > Great! Please don't use 8.0 as a version. Microsoft renamed 8.0 to 7.1 quite a while ago. In FreeTDS 1.0 we removed support for this old (compatible) "8.0" version. So 7.2/7.3/7.4 are newer than the "8.0" (which is the MS SQL Server 2000 protocol). Frediano > > -----Original Message----- > From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of Frediano Ziglio > Sent: Monday, April 25, 2016 17:14 > To: FreeTDS Development Group > Subject: Re: [freetds] Getting "Unexpected EOF from the server" when trying to connect to MS SQL Server 2014 > > 2016-04-25 13:26 GMT+01:00 Pulver, Alex : >> Hi all, >> >> I am trying to connect to MS SQL 2014 Server from SLES11 host, using FreeTDS 0.95.51 version and its tsql utility. The server uses "Standard Mode" (SQL Server Authentication) and I am able to connect from Windows using SQL Server 2014 Management Studio. >> Before sending this email I've read through FreeTDS troubleshooting, FAQ, domains page, config page, archives and various SO questions - tried the recommended configurations but with no luck (details below). >> >> The command being run is: >> env TDSVER=7.0 TDSDUMP=/tmp/tdsdump.log TDSDUMPCONFIG=/tmp/tdsdumpconfig.log ./src/apps/tsql -H -p -U -P -D >> > > I would try with at least 7.2 version. > >> The output: >> locale is "C" >> locale charset is "ANSI_X3.4-1968" >> using default charset "ISO-8859-1" >> Setting as default database in login packet >> Error 20017 (severity 9): >> Unexpected EOF from the server >> ... >> >> Tailing TDSDUMP along with the execution shows that error is happening after the login packet is sent and FreeTDS tries to process the login tokens: >> login.c:852:quietly sending TDS 7+ login packet >> token.c:327:tds_process_login_tokens() >> << >> Error 20017 (severity 9): >> Unexpected EOF from the server >>>> >> query.c:3772:tds_disconnect() >> >> Looking on strace seems to confirm that server disconnects after login packet is received (poll() returns positive after sendto(), but recvfrom() returns 0): >> write(5, "login.c:852:quietly sending TDS "..., 48) = 48 >> ... >> poll([{fd=6, events=POLLOUT}, {fd=4, events=POLLIN}], 2, -1) = 1 ([{fd=6, revents=POLLOUT}]) >> sendto(6, "\20\1\0012\0\0\0\0*\1\0\0\0\0\0p\0\20\0\0\6\203\362\370U\354\0\0\0\0\0\0"..., 306, MSG_NOSIGNAL, NULL, 0) = 306 >> write(5, "token.c:327:tds_process_login_to"..., 39) = 39 > > This means that server rejected the login. Like user/password wrong. > Are you using Kerberos/SSPI or SQL logins? > >> poll([{fd=6, events=POLLIN}, {fd=4, events=POLLIN}], 2, -1) = 1 ([{fd=6, revents=POLLIN}]) >> recvfrom(6, "", 8, MSG_NOSIGNAL, NULL, NULL) = 0 >> write(5, "query.c:3772:tds_disconnect() \n", 31) = 31 >> >> Things I tried listed in no particular order (assuming the issue is with authentication and not network): >> * Use UTF-8 encoding > > This would change if you have extra ASCII in your username/password. > >> * Disable SSPI: ./configure --disable-sspi (so that trusted authentication will not be triggered) > > SSPI is supported only in Windows so it's not affecting your build. > >> * Compile with latest OpenSSL version we have installed: ./configure --with-openssl=/.../openssl/1.0.1/bin/openssl >> * Explicitly disable OpenSSL: ./configure --without-openssl >> * Modifying the code in ./src/tds/mem.c to disable check_ssl_hostname by setting it to 0 in both places it appears (assuming it triggers checking server's SSL certificate and fails to authenticate). Verified using debugger that *((tds)->login) object has check_ssl_hostname set to 0 >> * Modifying the code in ./src/tds/tls.c to change location of certificates pointed by ca_directory[] to a directory I know we have updated internal certificates >> > > No, the check is done by FreeTDS, in this case the server is disconnecting. > >> Things I still need to check with MS SQL Server admins: >> * Try to see if they can give me access to server-side log for my connection attempts >> * Check if server requires two-way authentication for SQL Server Authentication - doesn't seem like it, but I will check >> >> If someone has any other ideas as to why the connection drops, or other things I can do to investigate further, I would really appreciate that! >> > > You could try increasing the log level (see "debug flags" in > http://www.freetds.org/userguide/freetdsconf.htm). > Also I would try the "use ntlmv2" flag (same page above). > >> Thanks! >> Alex > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > --------------------------------------------------------------------- > Intel Israel (74) Limited > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > > _______________________________________________ > 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 --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. From freddy77 at gmail.com Tue Apr 26 06:09:41 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Tue, 26 Apr 2016 11:09:41 +0100 Subject: [freetds] dbopen: avoiding config with direct host/port In-Reply-To: References: Message-ID: 2016-04-24 16:53 GMT+01:00 Erik Smith : > Is there currently a way to open a connection without referencing the > config files? This has been asked before but it's unclear if this is > possible: > > http://lists.ibiblio.org/pipermail/freetds/2010q4/026425.html > > There doesn't seem to be a way to do this using this call: > > DBPROCESS *dbopen(LOGINREC * login, const char *server) > > There are fields within LOGINREC (such as host & port) that could be used > to override config, but that doesn't seem to be the way it was implemented. > > Any ideas? > > erik Fill in LOGINREC as much information you need (like protocol version) then use : or \ as server. dbopen will try to read from configuration, fall back to server parsing host and port/instance then override settings with your LOGINREC informations. Frediano From freddy77 at gmail.com Tue Apr 26 06:19:11 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Tue, 26 Apr 2016 11:19:11 +0100 Subject: [freetds] osql exits with error on Linux In-Reply-To: References: Message-ID: Applied Thanks, Frediano 2016-04-24 23:23 GMT+01:00 Jan Blom : > Hello, > > The osql script fails to execute on CentOS (tested on release 6 & 7). We need to add "-F" to grep to avoid interpreting patterns as a reg exp. Patch attached. > > > Best regards, > Jan Blom > > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > From craigberry at mac.com Tue Apr 26 14:08:08 2016 From: craigberry at mac.com (Craig A. Berry) Date: Tue, 26 Apr 2016 13:08:08 -0500 Subject: [freetds] freebcp adding escaping In-Reply-To: <20160423140433.2d8718fd616a15d2dc92010a@icloud.com> References: <56B184A9.1040603@smart-associates.biz> <20160417182704.6f2b90ca9868615403166e0d@icloud.com> <1461335382.7148.25.camel@montesa> <20160423140433.2d8718fd616a15d2dc92010a@icloud.com> Message-ID: <42D42951-621B-4D31-95C5-864B7EFB39CC@mac.com> > On Apr 23, 2016, at 1:04 PM, James K. Lowden wrote: > > On Fri, 22 Apr 2016 16:29:42 +0200 > Fredy Paquet wrote: > >> Your CSV parser is very interesting, but it doesn't seem to handle >> the ugly quoting rules for CSV correctly. Also newline within a text >> field isn't processed correctly. > ... >> Isn't there any better implementation around ? > > As mentioned in the man page, you might look at > http://sourceforge.net/projects/libcsv/. > > I don't remember why I wrote my own implementation, other than wanting > to try my hand at writing a parser. Again, if there is interest in > incorporating the feature in FreeTDS, I would be willing to polish it > up. The challenge, btw, isn't so much to parse standard CSV files > correctly. The challenge is that, in practice, many CSV files don't > conform to the standard, yet the library is expected to DTRT > regardless. > There is a Perl extension that I think handles a lot of the corner cases: https://github.com/Tux/Text-CSV_XS The file CSV_XS.xs would be where the underlying C implementation resides. It would take some work to disentangle from the Perl interpreter details, but the logic is there. ________________________________________ Craig A. Berry mailto:craigberry at mac.com "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser From peterd at iea-software.com Tue Apr 26 20:17:26 2016 From: peterd at iea-software.com (Peter Deacon) Date: Tue, 26 Apr 2016 17:17:26 -0700 (Pacific Daylight Time) Subject: [freetds] DNS lookups not working with freetds Message-ID: Tried current freetds and name lookups are not working at all with some older Linux systems for me. Everything that isn't an IP address returns -2 (EAI_NONAME) The problem is triggered by setting ai_flags = AI_ADDRCONFIG in hints field of getaddrinfo and resolved by setting ai_flags = 0. >From what I've read in various man pages for getaddrinfo when set to 0 defaults are designed to be reasonable usually including AI_ADDRCONFIG anyway. Would switching to default for ai_flags break anything for anyone? thanks, ~Peter From velichko.yuriy at gmail.com Wed Apr 27 03:25:22 2016 From: velichko.yuriy at gmail.com (Velichko Yuriy) Date: Wed, 27 Apr 2016 10:25:22 +0300 Subject: [freetds] dbopen: avoiding config with direct host/port In-Reply-To: References: Message-ID: Is there a place in docs with description of parameters format? I guess it the same as for .conf file, but maybe it is different. For example : what separator need to use between entries? On 26 April 2016 at 13:09, Frediano Ziglio wrote: > 2016-04-24 16:53 GMT+01:00 Erik Smith : > > Is there currently a way to open a connection without referencing the > > config files? This has been asked before but it's unclear if this is > > possible: > > > > http://lists.ibiblio.org/pipermail/freetds/2010q4/026425.html > > > > There doesn't seem to be a way to do this using this call: > > > > DBPROCESS *dbopen(LOGINREC * login, const char *server) > > > > There are fields within LOGINREC (such as host & port) that could be used > > to override config, but that doesn't seem to be the way it was > implemented. > > > > Any ideas? > > > > erik > > > Fill in LOGINREC as much information you need (like protocol version) > then use : or \ as server. dbopen will try > to read from configuration, fall back to server parsing host and > port/instance then override settings with your LOGINREC informations. > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > From freddy77 at gmail.com Wed Apr 27 10:33:57 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Wed, 27 Apr 2016 15:33:57 +0100 Subject: [freetds] dbopen: avoiding config with direct host/port In-Reply-To: References: Message-ID: Ehmm...no, LOGINREC is a structure you have to set with setl* functions or related macros. Server syntax is specified in the previous mail... I'm not sure there are documentation... I'll check. Frediano 2016-04-27 8:25 GMT+01:00 Velichko Yuriy : > Is there a place in docs with description of parameters format? > I guess it the same as for .conf file, but maybe it is different. For > example : what separator need to use between entries? > > On 26 April 2016 at 13:09, Frediano Ziglio wrote: > >> 2016-04-24 16:53 GMT+01:00 Erik Smith : >> > Is there currently a way to open a connection without referencing the >> > config files? This has been asked before but it's unclear if this is >> > possible: >> > >> > http://lists.ibiblio.org/pipermail/freetds/2010q4/026425.html >> > >> > There doesn't seem to be a way to do this using this call: >> > >> > DBPROCESS *dbopen(LOGINREC * login, const char *server) >> > >> > There are fields within LOGINREC (such as host & port) that could be used >> > to override config, but that doesn't seem to be the way it was >> implemented. >> > >> > Any ideas? >> > >> > erik >> >> >> Fill in LOGINREC as much information you need (like protocol version) >> then use : or \ as server. dbopen will try >> to read from configuration, fall back to server parsing host and >> port/instance then override settings with your LOGINREC informations. >> >> Frediano >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> http://lists.ibiblio.org/mailman/listinfo/freetds >> > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From freddy77 at gmail.com Wed Apr 27 10:32:12 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Wed, 27 Apr 2016 15:32:12 +0100 Subject: [freetds] DNS lookups not working with freetds In-Reply-To: References: Message-ID: 2016-04-27 1:17 GMT+01:00 Peter Deacon : > Tried current freetds and name lookups are not working at all with some > older Linux systems for me. Everything that isn't an IP address returns -2 > (EAI_NONAME) > > The problem is triggered by setting ai_flags = AI_ADDRCONFIG in hints field > of getaddrinfo and resolved by setting ai_flags = 0. > > From what I've read in various man pages for getaddrinfo when set to 0 > defaults are designed to be reasonable usually including AI_ADDRCONFIG > anyway. > > Would switching to default for ai_flags break anything for anyone? > > thanks, > ~Peter The commit that introduced the flag is https://github.com/FreeTDS/freetds/commit/25edb8ef. I don't remember exactly but I don't remember all the problems. I think that without the flag some environment can send multiple queries and you increase the connection timeout in environment where the DNS do not return AAAA records. Unfortunately these environments were quite common :-( I don't know... possible todos/solutions: - look at the old ML thread(s) and try to understand why this flag was used (if I remember there were multiple threads); - add a freetds.conf option; - if getaddrinfo returns EAI_NONAME try without the flag. This would slow down connections only if users really used a wrong host name, should not that common. Frediano From craigberry at mac.com Fri Apr 29 08:48:40 2016 From: craigberry at mac.com (Craig A. Berry) Date: Fri, 29 Apr 2016 07:48:40 -0500 Subject: [freetds] [PATCH] Test tds_strl* routines on all platforms Message-ID: <942D6BA2-9559-460D-8E26-A2F3E881B1DE@mac.com> The src/replacements/unittests/strings.c failed to build for me on OS X. The test is explicitly using the routines with the tds_ prefix, which don?t exist when we aren?t using replacements. So this change makes them exist for test purposes only in the case where we wouldn?t normally get them. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Test-tds_strl-routines-on-all-platforms.patch Type: application/octet-stream Size: 1236 bytes Desc: not available URL: From craigberry at mac.com Fri Apr 29 09:41:43 2016 From: craigberry at mac.com (Craig A. Berry) Date: Fri, 29 Apr 2016 08:41:43 -0500 Subject: [freetds] 'compute' deprecated (Re: rc3 looks good on OpenVMS) In-Reply-To: References: <750487a0-dd58-4962-8a17-1c5380e8d145@me.com> Message-ID: <12736C9B-AD71-49BE-AC27-11F3BBE253AB@mac.com> > On May 28, 2015, at 5:16 PM, Frediano Ziglio wrote: > > Il 28/Mag/2015 09:58, "Craig A. Berry" ha scritto: >> With SQL 2012 this test below fails, but I >> think it's just because "compute" has been removed in SQL 2012: > Yes, that test check how compute queries reply so cannot work but is not a > Freetds issue I?m reviving this year-old thread because this is still a problem and getting to be a bigger one, and while it isn?t FreeTDS?s fault, it is FreeTDS?s problem if its test suite can?t even run to completion on 3 of the 4 currently-supported versions of Microsoft?s server (SQL 2005 went out of support a week or two ago, so SQL 2008 is the only one that can run the test suite). The following tests are the ones affected: src/ctlib/unittests/t0009 src/dblib/unittests/t0023 src/dblib/unittests/dbmorecmds I tried (unsuccessfully) to come up with a way to skip the tests when running on SQL 2012 or greater. The following check tells you what you?ve got, but only at run time, which is too late. The ?compute? keyword will still be seen at parse time so the script will already fail before this check runs. Plus it uses Microsoft-specific functions that will probably not parse on Sybase. IF CHARINDEX('Microsoft', @@VERSION) <> 0 BEGIN IF CAST(PARSENAME(CAST(SERVERPROPERTY('PRODUCTVERSION') AS VARCHAR), 4) AS INT) >= 11 BEGIN PRINT 'SKIP - SQL 2012 or greater' END END Not sure what to suggest. Anybody have a good way forward? > SQL text will be read from ../../../src/dblib/unittests/t0023.sql >> Starting dsa0:[craig.freetds-0^.95rc3.src.dblib.unittests]t0023.exe >> About to logon >> About to open >> creating table >> 1: create table #dblib0023 (col1 int not null, col2 char(1) not >> null, col3 datetime not null) >> insert >> 1: insert into #dblib0023 values (1, 'A', 'Jan 1 2002 >> 10:00:00AM') >> 1: insert into #dblib0023 values (2, 'A', 'Jan 2 2002 >> 10:00:00AM') >> 1: insert into #dblib0023 values (3, 'A', 'Jan 3 2002 >> 10:00:00AM') >> 1: insert into #dblib0023 values (8, 'B', 'Jan 4 2002 >> 10:00:00AM') >> 1: insert into #dblib0023 values (9, 'B', 'Jan 5 2002 >> 10:00:00AM') >> select >> 1: select col1, col2, col3 from #dblib0023 order by col2 compute >> sum(col1) by col2 compute max(col3) >> Msg 156, Level 15, State 1 >> Server 'ABC0012312?' >> , Line 1 >> >> Incorrect syntax near the keyword 'compute'. >> exit: no unanticipated messages allowed in unit tests ________________________________________ Craig A. Berry "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser From no-reply at appveyor.com Fri Apr 29 11:47:25 2016 From: no-reply at appveyor.com (AppVeyor) Date: Fri, 29 Apr 2016 15:47:25 +0000 Subject: [freetds] Build failed: freetds 518 Message-ID: <20160429154615.12337.40710.B72ACD79@appveyor.com> From no-reply at appveyor.com Fri Apr 29 13:03:19 2016 From: no-reply at appveyor.com (AppVeyor) Date: Fri, 29 Apr 2016 17:03:19 +0000 Subject: [freetds] Build completed: freetds 519 Message-ID: <20160429170310.24609.79041.943789CF@appveyor.com> From freddy77 at gmail.com Fri Apr 29 13:27:40 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Fri, 29 Apr 2016 18:27:40 +0100 Subject: [freetds] [PATCH] Test tds_strl* routines on all platforms In-Reply-To: <942D6BA2-9559-460D-8E26-A2F3E881B1DE@mac.com> References: <942D6BA2-9559-460D-8E26-A2F3E881B1DE@mac.com> Message-ID: Applied Thanks, Frediano 2016-04-29 13:48 GMT+01:00 Craig A. Berry : > The src/replacements/unittests/strings.c failed to build for me on OS X. The test is explicitly using the routines with the tds_ prefix, which don?t exist when we aren?t using replacements. So this change makes them exist for test purposes only in the case where we wouldn?t normally get them. > > > > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > From freddy77 at gmail.com Fri Apr 29 13:50:45 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Fri, 29 Apr 2016 18:50:45 +0100 Subject: [freetds] 'compute' deprecated (Re: rc3 looks good on OpenVMS) In-Reply-To: <12736C9B-AD71-49BE-AC27-11F3BBE253AB@mac.com> References: <750487a0-dd58-4962-8a17-1c5380e8d145@me.com> <12736C9B-AD71-49BE-AC27-11F3BBE253AB@mac.com> Message-ID: 2016-04-29 14:41 GMT+01:00 Craig A. Berry : > >> On May 28, 2015, at 5:16 PM, Frediano Ziglio wrote: >> >> Il 28/Mag/2015 09:58, "Craig A. Berry" ha scritto: >>> With SQL 2012 this test below fails, but I >>> think it's just because "compute" has been removed in SQL 2012: > >> Yes, that test check how compute queries reply so cannot work but is not a >> Freetds issue > > I?m reviving this year-old thread because this is still a problem and getting to be a bigger one, and while it isn?t FreeTDS?s fault, it is FreeTDS?s problem if its test suite can?t even run to completion on 3 of the 4 currently-supported versions of Microsoft?s server (SQL 2005 went out of support a week or two ago, so SQL 2008 is the only one that can run the test suite). > I though AppVeyor was running check against mssql 2012 !! > The following tests are the ones affected: > > src/ctlib/unittests/t0009 > src/dblib/unittests/t0023 > src/dblib/unittests/dbmorecmds > > I tried (unsuccessfully) to come up with a way to skip the tests when running on SQL 2012 or greater. The following check tells you what you?ve got, but only at run time, which is too late. The ?compute? keyword will still be seen at parse time so the script will already fail before this check runs. Plus it uses Microsoft-specific functions that will probably not parse on Sybase. > > IF CHARINDEX('Microsoft', @@VERSION) <> 0 > BEGIN > IF CAST(PARSENAME(CAST(SERVERPROPERTY('PRODUCTVERSION') AS VARCHAR), 4) AS INT) >= 11 > BEGIN > PRINT 'SKIP - SQL 2012 or greater' > END > END > > Not sure what to suggest. Anybody have a good way forward? > Could this be a solution for t0009 ? diff --git a/src/ctlib/unittests/t0009.c b/src/ctlib/unittests/t0009.c index a033ffe..d7efbde 100644 --- a/src/ctlib/unittests/t0009.c +++ b/src/ctlib/unittests/t0009.c @@ -8,8 +8,8 @@ #include #include "common.h" -static char software_version[] = "$Id: t0009.c,v 1.13 2011-05-16 08:51:40 freddy77 Exp $"; -static void *no_unused_var_warn[] = { software_version, no_unused_var_warn }; +static CS_RETCODE ex_servermsg_cb(CS_CONTEXT * context, CS_CONNECTION * connection, CS_SERVERMSG * errmsg); +static int compute_supported = 1; /* Testing: Retrieve compute results */ int @@ -91,6 +91,7 @@ main(int argc, char *argv[]) return 1; } + ct_callback(ctx, NULL, CS_SET, CS_SERVERMSG_CB, (CS_VOID *) ex_servermsg_cb); while ((results_ret = ct_results(cmd, &result_type)) == CS_SUCCEED) { switch ((int) result_type) { case CS_CMD_SUCCEED: @@ -98,6 +99,10 @@ main(int argc, char *argv[]) case CS_CMD_DONE: break; case CS_CMD_FAIL: + if (!compute_supported) { + try_ctlogout(ctx, conn, cmd, verbose); + return 0; + } fprintf(stderr, "ct_results() result_type CS_CMD_FAIL.\n"); return 1; case CS_ROW_RESULT: @@ -320,3 +325,14 @@ main(int argc, char *argv[]) return 0; } + +static CS_RETCODE +ex_servermsg_cb(CS_CONTEXT * context, CS_CONNECTION * connection, CS_SERVERMSG * srvmsg) +{ + if (strstr(srvmsg->text, "compute")) { + compute_supported = 0; + printf("Server does not support compute\n"); + return CS_SUCCEED; + } + return servermsg_cb(context, connection, srvmsg); +} >> SQL text will be read from ../../../src/dblib/unittests/t0023.sql >>> Starting dsa0:[craig.freetds-0^.95rc3.src.dblib.unittests]t0023.exe >>> About to logon >>> About to open >>> creating table >>> 1: create table #dblib0023 (col1 int not null, col2 char(1) not >>> null, col3 datetime not null) >>> insert >>> 1: insert into #dblib0023 values (1, 'A', 'Jan 1 2002 >>> 10:00:00AM') >>> 1: insert into #dblib0023 values (2, 'A', 'Jan 2 2002 >>> 10:00:00AM') >>> 1: insert into #dblib0023 values (3, 'A', 'Jan 3 2002 >>> 10:00:00AM') >>> 1: insert into #dblib0023 values (8, 'B', 'Jan 4 2002 >>> 10:00:00AM') >>> 1: insert into #dblib0023 values (9, 'B', 'Jan 5 2002 >>> 10:00:00AM') >>> select >>> 1: select col1, col2, col3 from #dblib0023 order by col2 compute >>> sum(col1) by col2 compute max(col3) >>> Msg 156, Level 15, State 1 >>> Server 'ABC0012312?' >>> , Line 1 >>> >>> Incorrect syntax near the keyword 'compute'. >>> exit: no unanticipated messages allowed in unit tests > > I did a test with AppVeyor and only these 3 tests are failing. Good! Frediano From peterd at iea-software.com Fri Apr 29 16:48:06 2016 From: peterd at iea-software.com (Peter Deacon) Date: Fri, 29 Apr 2016 13:48:06 -0700 (Pacific Daylight Time) Subject: [freetds] DNS lookups not working with freetds In-Reply-To: References: Message-ID: On Wed, 27 Apr 2016, Frediano Ziglio wrote: > The commit that introduced the flag is > https://github.com/FreeTDS/freetds/commit/25edb8ef. > I don't remember exactly but I don't remember all the problems. I > think that without the flag some environment can send multiple queries > and you increase the connection timeout in environment where the DNS > do not return AAAA records. Unfortunately these environments were > quite common :-( > I don't know... possible todos/solutions: > - look at the old ML thread(s) and try to understand why this flag was > used (if I remember there were multiple threads); > - add a freetds.conf option; > - if getaddrinfo returns EAI_NONAME try without the flag. This would > slow down connections only if users really used a wrong host name, > should not that common. Hi Frediano, Thanks, think I will just patch this locally. Using a very old environment (compatibility) that seems to be causing this behavior. After giving it more thought unlikely anyone would benefit from attempting to workaround what is now ancient history. I also misread getaddrinfo documentation about when default settings apply. ai_flags = 0 would turn off AI_ADDRCONFIG across the board which I wouldn't want. ~Peter From craigberry at mac.com Fri Apr 29 17:18:43 2016 From: craigberry at mac.com (Craig A. Berry) Date: Fri, 29 Apr 2016 16:18:43 -0500 Subject: [freetds] 'compute' deprecated (Re: rc3 looks good on OpenVMS) In-Reply-To: References: <750487a0-dd58-4962-8a17-1c5380e8d145@me.com> <12736C9B-AD71-49BE-AC27-11F3BBE253AB@mac.com> Message-ID: <06F21191-D7F3-4509-BF46-87CA7C5A6D63@mac.com> > On Apr 29, 2016, at 12:50 PM, Frediano Ziglio wrote: >> > I though AppVeyor was running check against mssql 2012 !! I don?t know how AppVeyor works but I was surprised to be the only one seeing this. >> The following tests are the ones affected: >> >> src/ctlib/unittests/t0009 >> src/dblib/unittests/t0023 >> src/dblib/unittests/dbmorecmds >> >> >> Not sure what to suggest. Anybody have a good way forward? >> > > Could this be a solution for t0009 ? > > diff --git a/src/ctlib/unittests/t0009.c b/src/ctlib/unittests/t0009.c > index a033ffe..d7efbde 100644 > --- a/src/ctlib/unittests/t0009.c > +++ b/src/ctlib/unittests/t0009.c > Yep, that did the trick for the ctlib case. ________________________________________ Craig A. Berry "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser From freddy77 at gmail.com Fri Apr 29 17:48:24 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Fri, 29 Apr 2016 22:48:24 +0100 Subject: [freetds] 'compute' deprecated (Re: rc3 looks good on OpenVMS) In-Reply-To: <06F21191-D7F3-4509-BF46-87CA7C5A6D63@mac.com> References: <750487a0-dd58-4962-8a17-1c5380e8d145@me.com> <12736C9B-AD71-49BE-AC27-11F3BBE253AB@mac.com> <06F21191-D7F3-4509-BF46-87CA7C5A6D63@mac.com> Message-ID: 2016-04-29 22:18 GMT+01:00 Craig A. Berry : > >> On Apr 29, 2016, at 12:50 PM, Frediano Ziglio wrote: >>> >> I though AppVeyor was running check against mssql 2012 !! > > I don?t know how AppVeyor works but I was surprised to be the only one seeing this. > >>> The following tests are the ones affected: >>> >>> src/ctlib/unittests/t0009 >>> src/dblib/unittests/t0023 >>> src/dblib/unittests/dbmorecmds >>> > >>> >>> Not sure what to suggest. Anybody have a good way forward? >>> >> >> Could this be a solution for t0009 ? >> >> diff --git a/src/ctlib/unittests/t0009.c b/src/ctlib/unittests/t0009.c >> index a033ffe..d7efbde 100644 >> --- a/src/ctlib/unittests/t0009.c >> +++ b/src/ctlib/unittests/t0009.c >> > > Yep, that did the trick for the ctlib case. > Let's see what AppVeyor say about other tests! https://ci.appveyor.com/project/FreeTDS/freetds/build/523 Frediano From freddy77 at gmail.com Sat Apr 30 19:22:12 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Sun, 1 May 2016 00:22:12 +0100 Subject: [freetds] FreeTDS 1.0 Release Candidate 4 is out! Message-ID: This release contains: - fix some compile issues with Mac OS X; - fix CT-Library rows counts; - fix minor compatibility issues with some unit tests; - other minor issues. Frediano From freddy77 at gmail.com Sat Apr 30 19:23:13 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Sun, 1 May 2016 00:23:13 +0100 Subject: [freetds] "Fix affected rows after insert with prepared query" side effect In-Reply-To: References: Message-ID: Now works much better. Please try last RC (4). Frediano 2016-04-24 16:55 GMT+01:00 John Kendall : > Sorry, my last post had the wrong link to sybase infocenter. > > 2016-04-23 13:04 GMT+01:00 Frediano Ziglio : > >> 2016-04-22 1:03 GMT+01:00 John Kendall : >> >>> Thu, 21 Apr 2016 11:04:54 +0100 Frediano Ziglio >>> >>>> 2016-04-21 8:00 GMT+01:00 John Kendall : >>>>> On Oct 19, 2015 this patch was applied to ct.c: >>>>> >>>>> "Fix affected rows after insert with prepared query" >>>>> >>>>> This patch has the side-effect of a 'rows affected' being displayed for every >>>>> select statement within a ASE stored procedure. For example, sp_help returns >>>>> 136 extra 'rows affected' lines. See below. Backing out this patch stops this from >>>>> happening. I only tested this on sp_help, but I figured that was enough. FYI, this >>>>> patch does not have this effect on MS SQL 2008's sp_help sproc. >>>>> >>>>> John >>>>> >>>> >>>> I'm not sure if this is a regression or an improvement. I have to >>>> check what's the original CT-Library behaviour. >>>> >>>> Frediano >>> >>> Hi, Frediano. >>> >>> I compiled sqsh against Sybase 16 libs and it does not return all those 'rows affected' >>> lines. I could be reading it wrong, but in the archives, it appears the patch applied was >>> not the one requested by David Nichols. >>> >> >> There was another patch that make the change the same. >> >>> http://lists.ibiblio.org/pipermail/freetds/2015q4/029631.html >>> >>> Could we remove that patch? >>> >> >> I don't think so. But probably the patch fixed an issue and introduced a problem >> so we should find a solution. I think that Dave/Ondrei wanted to have the row >> number returned by a DONEINPROC in the case of a prepared statement. This >> does not mean they want all DONEINPROC from the server. >> >> Basically >> - before: no DONEINPROC >> - after: all DONEINPROC >> - wanted (you): one DONEINPROC (which one and how still to be defined) >> Does this make sense? > > > Yes. > > As far as I can tell, it should only return the count for the last statement that could affect rows: > > http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.infocenter.dc36065.1570/html/ctlibmig/X65200.htm > > So, the last insert, delete or update, perhaps? > > > >>> Thanks, >> >>> John >>> >>> >> >> I think this is the only no-build issue we had since the 1.0 RC. Not bad! Frediano > >> >>>>> >>>>> sqsh> sp_help Movetype >>>>> (1 row affected) >>>>> Name Owner Object_type >>>>> -------------------------------- -------------------- ---------------------------------------- >>>>> Movetype dbo user table >>>>> >>>>> Column_name Type Length Pre >>>>> ------------------------------------------------ ---------------- ------------------------ --- >>>>> movetype char 2 NUL >>>>> move_desc char 20 NUL >>>>> move_revenue bit 1 NUL >>>>> >>>>> (1 row affected) >>>>> (1 row affected) >>>>> (1 row affected) >>>>> (0 rows affected) >>>>> (1 row affected) >>>>> (0 rows affected) >>>>> (1 row affected) >>>>> (1 row affected) >>>>> (1 row affected) >>>>> (1 row affected) >>>>> (1 row affected) >>>>> (1 row affected) >>>>> (1 row affected) >>>>> Object has the following indexes >>>>> >>>>> (1 row affected) >>>>> (1 row affected) >>>>> ... etc >>>>> > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From freddy77 at gmail.com Mon May 2 16:00:27 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Mon, 2 May 2016 21:00:27 +0100 Subject: [freetds] Setting `login->use_utf16` With DBLIB Using Sybdb.h In-Reply-To: References: Message-ID: Added the DBSETUTF8 option! Not really hard :-) Frediano 2016-05-02 12:18 GMT+01:00 Ken Collins : > The option to set the long would make sense to me. I love the default, but > would love to allow someone to set this in my client without going to a conf > file. Hope that helps. > > - Ken > > > On April 25, 2016 at 8:20:08 AM, Frediano Ziglio (freddy77 at gmail.com) wrote: > > 2016-04-24 20:58 GMT+01:00 Ken Collins : >> So I saw the news about `use utf-16 = true` via the conf file for 0.95 and >> how this is the default in 1.0 release candidate. However, I was wondering >> if there is a way I can set this long in bit using either an environment >> variable or some other means when compiling against sybdb.h? >> >> - Thanks in advance, >> Ken Collins > > An environment variable looks to much. > An option to set using setlshort/setllong would make sense to me. > Does it sound reasonable? I don't understand how you want to use this > option. > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From lacak at zoznam.sk Tue May 3 01:43:06 2016 From: lacak at zoznam.sk (LacaK) Date: Tue, 3 May 2016 07:43:06 +0200 Subject: [freetds] Setting `login->use_utf16` With DBLIB Using Sybdb.h In-Reply-To: References: Message-ID: <57283A6A.8070502@zoznam.sk> DBSETUTF16 ;-)) L. > Added the DBSETUTF8 option! Not really hard :-) > > Frediano > > > 2016-05-02 12:18 GMT+01:00 Ken Collins : >> The option to set the long would make sense to me. I love the default, but >> would love to allow someone to set this in my client without going to a conf >> file. Hope that helps. >> >> - Ken >> >> >> On April 25, 2016 at 8:20:08 AM, Frediano Ziglio (freddy77 at gmail.com) wrote: >> >> 2016-04-24 20:58 GMT+01:00 Ken Collins : >>> So I saw the news about `use utf-16 = true` via the conf file for 0.95 and >>> how this is the default in 1.0 release candidate. However, I was wondering >>> if there is a way I can set this long in bit using either an environment >>> variable or some other means when compiling against sybdb.h? >>> >>> - Thanks in advance, >>> Ken Collins >> An environment variable looks to much. >> An option to set using setlshort/setllong would make sense to me. >> Does it sound reasonable? I don't understand how you want to use this >> option. >> >> 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 velichko.yuriy at gmail.com Tue May 3 05:34:55 2016 From: velichko.yuriy at gmail.com (Velichko Yuriy) Date: Tue, 3 May 2016 12:34:55 +0300 Subject: [freetds] ntlmv2 default value Message-ID: Hello, what is default value for ntlmv2 option? If ''no", can you add method, like DBSETUTF16, to avoid using .conf file to setup this option? Thanks! From freddy77 at gmail.com Tue May 3 19:17:32 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Wed, 4 May 2016 00:17:32 +0100 Subject: [freetds] ntlmv2 default value In-Reply-To: References: Message-ID: Added! Frediano 2016-05-03 10:34 GMT+01:00 Velichko Yuriy : > Hello, what is default value for ntlmv2 option? > If ''no", can you add method, like DBSETUTF16, to avoid using .conf file to > setup this option? > > Thanks! > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From john at capps.com Wed May 4 12:07:48 2016 From: john at capps.com (John Kendall) Date: Wed, 4 May 2016 16:07:48 +0000 Subject: [freetds] "Fix affected rows after insert with prepared query" side effect In-Reply-To: References: Message-ID: <4169B878-547C-4ED3-A115-BDE358C805A5@capps.com> > On Apr 30, 2016, at 4:23 PM, Frediano Ziglio wrote: > > Now works much better. Please try last RC (4). > > Frediano > Looks good. Thank you! John > > 2016-04-24 16:55 GMT+01:00 John Kendall : >> Sorry, my last post had the wrong link to sybase infocenter. >> >> 2016-04-23 13:04 GMT+01:00 Frediano Ziglio : >> >>> 2016-04-22 1:03 GMT+01:00 John Kendall : >>> >>>> Thu, 21 Apr 2016 11:04:54 +0100 Frediano Ziglio >>>> >>>>> 2016-04-21 8:00 GMT+01:00 John Kendall : >>>>>> On Oct 19, 2015 this patch was applied to ct.c: >>>>>> >>>>>> "Fix affected rows after insert with prepared query" >>>>>> >>>>>> This patch has the side-effect of a 'rows affected' being displayed for every >>>>>> select statement within a ASE stored procedure. For example, sp_help returns >>>>>> 136 extra 'rows affected' lines. See below. Backing out this patch stops this from >>>>>> happening. I only tested this on sp_help, but I figured that was enough. FYI, this >>>>>> patch does not have this effect on MS SQL 2008's sp_help sproc. >>>>>> >>>>>> John >>>>>> >>>>> >>>>> I'm not sure if this is a regression or an improvement. I have to >>>>> check what's the original CT-Library behaviour. >>>>> >>>>> Frediano >>>> >>>> Hi, Frediano. >>>> >>>> I compiled sqsh against Sybase 16 libs and it does not return all those 'rows affected' >>>> lines. I could be reading it wrong, but in the archives, it appears the patch applied was >>>> not the one requested by David Nichols. >>>> >>> >>> There was another patch that make the change the same. >>> >>>> http://lists.ibiblio.org/pipermail/freetds/2015q4/029631.html >>>> >>>> Could we remove that patch? >>>> >>> >>> I don't think so. But probably the patch fixed an issue and introduced a problem >>> so we should find a solution. I think that Dave/Ondrei wanted to have the row >>> number returned by a DONEINPROC in the case of a prepared statement. This >>> does not mean they want all DONEINPROC from the server. >>> >>> Basically >>> - before: no DONEINPROC >>> - after: all DONEINPROC >>> - wanted (you): one DONEINPROC (which one and how still to be defined) >>> Does this make sense? >> >> >> Yes. >> >> As far as I can tell, it should only return the count for the last statement that could affect rows: >> >> http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.infocenter.dc36065.1570/html/ctlibmig/X65200.htm >> >> So, the last insert, delete or update, perhaps? >> >> >> >>>> Thanks, >>> >>>> John >>>> >>>> >>> >>> I think this is the only no-build issue we had since the 1.0 RC. Not bad! Frediano > >>> >>>>>> >>>>>> sqsh> sp_help Movetype >>>>>> (1 row affected) >>>>>> Name Owner Object_type >>>>>> -------------------------------- -------------------- ---------------------------------------- >>>>>> Movetype dbo user table >>>>>> >>>>>> Column_name Type Length Pre >>>>>> ------------------------------------------------ ---------------- ------------------------ --- >>>>>> movetype char 2 NUL >>>>>> move_desc char 20 NUL >>>>>> move_revenue bit 1 NUL >>>>>> >>>>>> (1 row affected) >>>>>> (1 row affected) >>>>>> (1 row affected) >>>>>> (0 rows affected) >>>>>> (1 row affected) >>>>>> (0 rows affected) >>>>>> (1 row affected) >>>>>> (1 row affected) >>>>>> (1 row affected) >>>>>> (1 row affected) >>>>>> (1 row affected) >>>>>> (1 row affected) >>>>>> (1 row affected) >>>>>> Object has the following indexes >>>>>> >>>>>> (1 row affected) >>>>>> (1 row affected) >>>>>> ... etc >>>>>> >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> http://lists.ibiblio.org/mailman/listinfo/freetds > From john at capps.com Wed May 4 13:46:54 2016 From: john at capps.com (John Kendall) Date: Wed, 4 May 2016 17:46:54 +0000 Subject: [freetds] freebcp in -n native switch not working with Sybase Message-ID: <4FC845CC-6951-40F7-855F-1BF69201525F@capps.com> On MS SQL Server this works: select col1="one", col2="2" into tempdb..tbl freebcp tempdb..tbl out tbl.bcp -n -Uusr -Ppw freebcp tempdb..tbl in tbl.bcp -n -Uusr -Ppw On Sybase the bcp in fails like so: Starting copy... Msg 20104, Level 3 Unexpected EOF encountered in bcp datafile bcp copy in failed Notes: The bcp file created is identical for on both server flavors. Using the character -c option works. Anyone else able to reproduce this problem? John From ikorot01 at gmail.com Wed May 4 14:28:21 2016 From: ikorot01 at gmail.com (Igor Korot) Date: Wed, 4 May 2016 14:28:21 -0400 Subject: [freetds] freebcp in -n native switch not working with Sybase In-Reply-To: <4FC845CC-6951-40F7-855F-1BF69201525F@capps.com> References: <4FC845CC-6951-40F7-855F-1BF69201525F@capps.com> Message-ID: Hi, John, On Wed, May 4, 2016 at 1:46 PM, John Kendall wrote: > On MS SQL Server this works: > > select col1="one", col2="2" into tempdb..tbl > > freebcp tempdb..tbl out tbl.bcp -n -Uusr -Ppw > freebcp tempdb..tbl in tbl.bcp -n -Uusr -Ppw > > On Sybase the bcp in fails like so: > > Starting copy... > > Msg 20104, Level 3 > Unexpected EOF encountered in bcp datafile > > bcp copy in failed > > > Notes: > The bcp file created is identical for on both server flavors. > Using the character -c option works. > > Anyone else able to reproduce this problem? Which version of the servers you use? Thank you. > > > John > > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From john at capps.com Wed May 4 19:39:19 2016 From: john at capps.com (John Kendall) Date: Wed, 4 May 2016 23:39:19 +0000 Subject: [freetds] freebcp in -n native switch not working with Sybase Message-ID: On Wed, May 4 14:28:21 EDT 2016 Igor Korot wrote: > Hi, John, > > On Wed, May 4, 2016 at 1:46 PM, John Kendall wrote: > > On MS SQL Server this works: > > > > select col1="one", col2="2" into tempdb..tbl > > > > freebcp tempdb..tbl out tbl.bcp -n -Uusr -Ppw > > freebcp tempdb..tbl in tbl.bcp -n -Uusr -Ppw > > > > On Sybase the bcp in fails like so: > > > > Starting copy... > > > > Msg 20104, Level 3 > > Unexpected EOF encountered in bcp datafile > > > > bcp copy in failed > > > > > > Notes: > > The bcp file created is identical for on both server flavors. > > Using the character -c option works. > > > > Anyone else able to reproduce this problem? > > Which version of the servers you use? 11.02 and 16.0 > Thank you. > > > > > > > John > From freddy77 at gmail.com Tue May 10 03:42:28 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Tue, 10 May 2016 08:42:28 +0100 Subject: [freetds] freebcp in -n native switch not working with Sybase In-Reply-To: <4FC845CC-6951-40F7-855F-1BF69201525F@capps.com> References: <4FC845CC-6951-40F7-855F-1BF69201525F@capps.com> Message-ID: 2016-05-04 18:46 GMT+01:00 John Kendall : > On MS SQL Server this works: > > select col1="one", col2="2" into tempdb..tbl > > freebcp tempdb..tbl out tbl.bcp -n -Uusr -Ppw > freebcp tempdb..tbl in tbl.bcp -n -Uusr -Ppw > > On Sybase the bcp in fails like so: > > Starting copy... > > Msg 20104, Level 3 > Unexpected EOF encountered in bcp datafile > > bcp copy in failed > > > Notes: > The bcp file created is identical for on both server flavors. > Using the character -c option works. > > Anyone else able to reproduce this problem? > > > John > Looks like the way the prefix length is computed is different between load and save time. For mssql works as varchar has a varint == 2, same as prefix computed to write. Frediano From freddy77 at gmail.com Tue May 10 04:01:46 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Tue, 10 May 2016 09:01:46 +0100 Subject: [freetds] freebcp in -n native switch not working with Sybase In-Reply-To: <4FC845CC-6951-40F7-855F-1BF69201525F@capps.com> References: <4FC845CC-6951-40F7-855F-1BF69201525F@capps.com> Message-ID: 2016-05-04 18:46 GMT+01:00 John Kendall : > On MS SQL Server this works: > > select col1="one", col2="2" into tempdb..tbl > > freebcp tempdb..tbl out tbl.bcp -n -Uusr -Ppw > freebcp tempdb..tbl in tbl.bcp -n -Uusr -Ppw > > On Sybase the bcp in fails like so: > > Starting copy... > > Msg 20104, Level 3 > Unexpected EOF encountered in bcp datafile > > bcp copy in failed > > > Notes: > The bcp file created is identical for on both server flavors. > Using the character -c option works. > > Anyone else able to reproduce this problem? > > > John > Fixed! Frediano From john at capps.com Tue May 10 11:49:42 2016 From: john at capps.com (John Kendall) Date: Tue, 10 May 2016 15:49:42 +0000 Subject: [freetds] freebcp in -n native switch not working with Sybase In-Reply-To: References: <4FC845CC-6951-40F7-855F-1BF69201525F@capps.com>, Message-ID: > On May 10, 2016, at 1:03 AM, Frediano Ziglio wrote: > > 2016-05-04 18:46 GMT+01:00 John Kendall : >> On MS SQL Server this works: >> >> select col1="one", col2="2" into tempdb..tbl >> >> freebcp tempdb..tbl out tbl.bcp -n -Uusr -Ppw >> freebcp tempdb..tbl in tbl.bcp -n -Uusr -Ppw >> >> On Sybase the bcp in fails like so: >> >> Starting copy... >> >> Msg 20104, Level 3 >> Unexpected EOF encountered in bcp datafile >> >> bcp copy in failed >> >> >> Notes: >> The bcp file created is identical for on both server flavors. >> Using the character -c option works. >> >> Anyone else able to reproduce this problem? >> >> >> John >> > > Fixed! You rule! As far as I'm concerned, it's ready for 1.0. :) > Frediano From john at capps.com Tue May 10 17:31:04 2016 From: john at capps.com (John Kendall) Date: Tue, 10 May 2016 21:31:04 +0000 Subject: [freetds] "Fix affected rows after insert with prepared query" side effect Message-ID: <8D691CA4-C0B7-433B-A434-0D5DDB777EE2@capps.com> It appears the patch for this ("fix ct-library rows count") has broken compute in ctlib: select col=1 into #tbl insert #tbl values (2) select * from #tbl compute sum(col) (1 row affected) (1 row affected) col ----------- 1 2 2 (3 rows affected) dblib (and ctlib RC1) does the expected: select col=1 into #tbl insert #tbl values (2) select * from #tbl compute sum(col) (1 row affected) (1 row affected) col ----------- 1 2 sum =========== 3 (3 rows affected) Sorry to keep finding things! John > On Apr 30, 2016, at 4:23 PM, Frediano Ziglio wrote: > > Now works much better. Please try last RC (4). > > Frediano > > > 2016-04-24 16:55 GMT+01:00 John Kendall : >> Sorry, my last post had the wrong link to sybase infocenter. >> >> 2016-04-23 13:04 GMT+01:00 Frediano Ziglio : >> >>> 2016-04-22 1:03 GMT+01:00 John Kendall : >>> >>>> Thu, 21 Apr 2016 11:04:54 +0100 Frediano Ziglio >>>> >>>>> 2016-04-21 8:00 GMT+01:00 John Kendall : >>>>>> On Oct 19, 2015 this patch was applied to ct.c: >>>>>> >>>>>> "Fix affected rows after insert with prepared query" >>>>>> >>>>>> This patch has the side-effect of a 'rows affected' being displayed for every >>>>>> select statement within a ASE stored procedure. For example, sp_help returns >>>>>> 136 extra 'rows affected' lines. See below. Backing out this patch stops this from >>>>>> happening. I only tested this on sp_help, but I figured that was enough. FYI, this >>>>>> patch does not have this effect on MS SQL 2008's sp_help sproc. >>>>>> >>>>>> John >>>>>> >>>>> >>>>> I'm not sure if this is a regression or an improvement. I have to >>>>> check what's the original CT-Library behaviour. >>>>> >>>>> Frediano >>>> >>>> Hi, Frediano. >>>> >>>> I compiled sqsh against Sybase 16 libs and it does not return all those 'rows affected' >>>> lines. I could be reading it wrong, but in the archives, it appears the patch applied was >>>> not the one requested by David Nichols. >>>> >>> >>> There was another patch that make the change the same. >>> >>>> http://lists.ibiblio.org/pipermail/freetds/2015q4/029631.html >>>> >>>> Could we remove that patch? >>>> >>> >>> I don't think so. But probably the patch fixed an issue and introduced a problem >>> so we should find a solution. I think that Dave/Ondrei wanted to have the row >>> number returned by a DONEINPROC in the case of a prepared statement. This >>> does not mean they want all DONEINPROC from the server. >>> >>> Basically >>> - before: no DONEINPROC >>> - after: all DONEINPROC >>> - wanted (you): one DONEINPROC (which one and how still to be defined) >>> Does this make sense? >> >> >> Yes. >> >> As far as I can tell, it should only return the count for the last statement that could affect rows: >> >> http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.infocenter.dc36065.1570/html/ctlibmig/X65200.htm >> >> So, the last insert, delete or update, perhaps? >> >> >> >>>> Thanks, >>> >>>> John >>>> >>>> >>> >>> I think this is the only no-build issue we had since the 1.0 RC. Not bad! Frediano > >>> >>>>>> >>>>>> sqsh> sp_help Movetype >>>>>> (1 row affected) >>>>>> Name Owner Object_type >>>>>> -------------------------------- -------------------- ---------------------------------------- >>>>>> Movetype dbo user table >>>>>> >>>>>> Column_name Type Length Pre >>>>>> ------------------------------------------------ ---------------- ------------------------ --- >>>>>> movetype char 2 NUL >>>>>> move_desc char 20 NUL >>>>>> move_revenue bit 1 NUL >>>>>> >>>>>> (1 row affected) >>>>>> (1 row affected) >>>>>> (1 row affected) >>>>>> (0 rows affected) >>>>>> (1 row affected) >>>>>> (0 rows affected) >>>>>> (1 row affected) >>>>>> (1 row affected) >>>>>> (1 row affected) >>>>>> (1 row affected) >>>>>> (1 row affected) >>>>>> (1 row affected) >>>>>> (1 row affected) >>>>>> Object has the following indexes >>>>>> >>>>>> (1 row affected) >>>>>> (1 row affected) >>>>>> ... etc >>>>>> From freddy77 at gmail.com Tue May 10 18:34:34 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Tue, 10 May 2016 23:34:34 +0100 Subject: [freetds] "Fix affected rows after insert with prepared query" side effect In-Reply-To: <8D691CA4-C0B7-433B-A434-0D5DDB777EE2@capps.com> References: <8D691CA4-C0B7-433B-A434-0D5DDB777EE2@capps.com> Message-ID: 2016-05-10 22:31 GMT+01:00 John Kendall : > It appears the patch for this ("fix ct-library rows count") has broken compute in ctlib: > > > select col=1 into #tbl insert #tbl values (2) select * from #tbl compute sum(col) > (1 row affected) > (1 row affected) > col > ----------- > 1 > 2 > 2 > > (3 rows affected) > > dblib (and ctlib RC1) does the expected: > > select col=1 into #tbl insert #tbl values (2) select * from #tbl compute sum(col) > (1 row affected) > (1 row affected) > col > ----------- > 1 > 2 > sum > =========== > 3 > > (3 rows affected) > > > Sorry to keep finding things! > > John > > Can you put some more detailed examples? Which program did you use? Frediano From john at capps.com Wed May 11 01:07:41 2016 From: john at capps.com (John Kendall) Date: Wed, 11 May 2016 05:07:41 +0000 Subject: [freetds] [GRAYMAIL] Re: "Fix affected rows after insert with prepared query" side effect In-Reply-To: References: <8D691CA4-C0B7-433B-A434-0D5DDB777EE2@capps.com> Message-ID: <8E4EC81F-7F2E-459A-93C8-14A28DC1E486@capps.com> > On May 10, 2016, at 3:34 PM, Frediano Ziglio wrote: > > 2016-05-10 22:31 GMT+01:00 John Kendall : >> It appears the patch for this ("fix ct-library rows count") has broken compute in ctlib: >> >> >> select col=1 into #tbl insert #tbl values (2) select * from #tbl compute sum(col) >> (1 row affected) >> (1 row affected) >> col >> ----------- >> 1 >> 2 >> 2 >> >> (3 rows affected) >> >> dblib (and ctlib RC1) does the expected: >> >> select col=1 into #tbl insert #tbl values (2) select * from #tbl compute sum(col) >> (1 row affected) >> (1 row affected) >> col >> ----------- >> 1 >> 2 >> sum >> =========== >> 3 >> >> (3 rows affected) >> >> >> Sorry to keep finding things! >> >> John >> >> > > Can you put some more detailed examples? Which program did you use? > > Frediano I'm using sqsh. The compute clause should return an extra result line. In the example I have given above, the table is a single column table with two rows with values 1 and 2. Adding the compute sum clause to the select should return a compute result of 3, instead it is returns an extra copy of the last row. My example is not a special case, no compute (sum, max, min, avg, etc) results seem to be returning from any queries with a compute clause. I never saw this problem before RC4. Backing out the 'fix ct-library rows count' patch on ct.c makes it return the expected result. John > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From sfhacker at hotmail.com Tue May 10 18:44:45 2016 From: sfhacker at hotmail.com (Sergio NNX) Date: Wed, 11 May 2016 08:44:45 +1000 Subject: [freetds] "Fix affected rows after insert with prepared query" side effect In-Reply-To: References: <8D691CA4-C0B7-433B-A434-0D5DDB777EE2@capps.com>, Message-ID: > > It appears the patch for this ("fix ct-library rows count") has broken compute in ctlib: This project is pretty good at unit testing. Perhaps for every change and/or new piece of functionality, we should add one or more unit test(s) and, of course, run all the existing tests to be sure we haven't broken anything. I could download the latest source code and test it locally, if that helps. From freddy77 at gmail.com Wed May 11 05:57:14 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Wed, 11 May 2016 10:57:14 +0100 Subject: [freetds] "Fix affected rows after insert with prepared query" side effect In-Reply-To: References: <8D691CA4-C0B7-433B-A434-0D5DDB777EE2@capps.com> Message-ID: 2016-05-10 23:44 GMT+01:00 Sergio NNX : >> > It appears the patch for this ("fix ct-library rows count") has broken compute in ctlib: > > This project is pretty good at unit testing. Perhaps for every change and/or new piece of functionality, we should add one or more unit test(s) and, of course, run all the existing tests to be sure we haven't broken anything. > test was written, but for the offending problem. I noted that t0009 test (the only one testing compute in ct-library) just print results not doing much tests on output so that's why I didn't got it. I already improved it, now it's time to fix it! > I could download the latest source code and test it locally, if that helps. > Didn't get the code that much, server send a mix of normal/compute rows without any done in the middle, the patch did change mainly done handling. If you want to try feel free. Looking at t0009 output before and after it's quite clear that compute was broken. Frediano From freddy77 at gmail.com Wed May 11 14:51:53 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Wed, 11 May 2016 19:51:53 +0100 Subject: [freetds] [GRAYMAIL] Re: "Fix affected rows after insert with prepared query" side effect In-Reply-To: <8E4EC81F-7F2E-459A-93C8-14A28DC1E486@capps.com> References: <8D691CA4-C0B7-433B-A434-0D5DDB777EE2@capps.com> <8E4EC81F-7F2E-459A-93C8-14A28DC1E486@capps.com> Message-ID: 2016-05-11 6:07 GMT+01:00 John Kendall : > >> On May 10, 2016, at 3:34 PM, Frediano Ziglio wrote: >> >> 2016-05-10 22:31 GMT+01:00 John Kendall : >>> It appears the patch for this ("fix ct-library rows count") has broken compute in ctlib: >>> >>> >>> select col=1 into #tbl insert #tbl values (2) select * from #tbl compute sum(col) >>> (1 row affected) >>> (1 row affected) >>> col >>> ----------- >>> 1 >>> 2 >>> 2 >>> >>> (3 rows affected) >>> >>> dblib (and ctlib RC1) does the expected: >>> >>> select col=1 into #tbl insert #tbl values (2) select * from #tbl compute sum(col) >>> (1 row affected) >>> (1 row affected) >>> col >>> ----------- >>> 1 >>> 2 >>> sum >>> =========== >>> 3 >>> >>> (3 rows affected) >>> >>> >>> Sorry to keep finding things! >>> >>> John >>> >>> Good, testing with updated unittests. AppVeyor is happy (but newer mssql don't support compute clause), Coverity is happy too. Let's wait for my tests and then I'll push the change. Oh... even sqsh looks better with compute clause. Frediano >> >> Can you put some more detailed examples? Which program did you use? >> >> Frediano > > I'm using sqsh. > > The compute clause should return an extra result line. In the example I have given above, the table is a single column table with two rows with values 1 and 2. Adding the compute sum clause to the select should return a compute result of 3, instead it is returns an extra copy of the last row. My example is not a special case, no compute (sum, max, min, avg, etc) results seem to be returning from any queries with a compute clause. I never saw this problem before RC4. Backing out the 'fix ct-library rows count' patch on ct.c makes it return the expected result. > > John > > >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> http://lists.ibiblio.org/mailman/listinfo/freetds > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From freddy77 at gmail.com Wed May 11 16:10:23 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Wed, 11 May 2016 21:10:23 +0100 Subject: [freetds] FreeTDS 1.0 Release Candidate 5 is out! Message-ID: This release contains: - new DB-library options: - DBSETLUTF16; - DBSETLNTLMV2; - per-DBPROCESS timeout using DBSETTIME; - fix compute column in CT-library; fix for native BCP using Sybase. No portability issues this time. I'm confident to have the final release in a week or so (I hope with no changes). Frediano From freddy77 at gmail.com Wed May 11 16:23:38 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Wed, 11 May 2016 21:23:38 +0100 Subject: [freetds] [GRAYMAIL] Re: "Fix affected rows after insert with prepared query" side effect In-Reply-To: <8E4EC81F-7F2E-459A-93C8-14A28DC1E486@capps.com> References: <8D691CA4-C0B7-433B-A434-0D5DDB777EE2@capps.com> <8E4EC81F-7F2E-459A-93C8-14A28DC1E486@capps.com> Message-ID: 2016-05-11 6:07 GMT+01:00 John Kendall : > >> On May 10, 2016, at 3:34 PM, Frediano Ziglio wrote: >> >> 2016-05-10 22:31 GMT+01:00 John Kendall : >>> It appears the patch for this ("fix ct-library rows count") has broken compute in ctlib: >>> >>> >>> select col=1 into #tbl insert #tbl values (2) select * from #tbl compute sum(col) >>> (1 row affected) >>> (1 row affected) >>> col >>> ----------- >>> 1 >>> 2 >>> 2 >>> >>> (3 rows affected) >>> >>> dblib (and ctlib RC1) does the expected: >>> >>> select col=1 into #tbl insert #tbl values (2) select * from #tbl compute sum(col) >>> (1 row affected) >>> (1 row affected) >>> col >>> ----------- >>> 1 >>> 2 >>> sum >>> =========== >>> 3 >>> >>> (3 rows affected) >>> >>> >>> Sorry to keep finding things! >>> >>> John >>> >>> >> >> Can you put some more detailed examples? Which program did you use? >> >> Frediano > > I'm using sqsh. > > The compute clause should return an extra result line. In the example I have given above, the table is a single column table with two rows with values 1 and 2. Adding the compute sum clause to the select should return a compute result of 3, instead it is returns an extra copy of the last row. My example is not a special case, no compute (sum, max, min, avg, etc) results seem to be returning from any queries with a compute clause. I never saw this problem before RC4. Backing out the 'fix ct-library rows count' patch on ct.c makes it return the expected result. > > John > Just to be sure, can you test 1.0rc5 ? Frediano From john at capps.com Wed May 11 16:36:40 2016 From: john at capps.com (John Kendall) Date: Wed, 11 May 2016 20:36:40 +0000 Subject: [freetds] "Fix affected rows after insert with prepared query" side effect In-Reply-To: References: <8D691CA4-C0B7-433B-A434-0D5DDB777EE2@capps.com> <8E4EC81F-7F2E-459A-93C8-14A28DC1E486@capps.com> Message-ID: On May 11, 2016, at 1:23 PM, Frediano Ziglio wrote: > 2016-05-11 6:07 GMT+01:00 John Kendall : >> >>> On May 10, 2016, at 3:34 PM, Frediano Ziglio wrote: >>> >>> 2016-05-10 22:31 GMT+01:00 John Kendall : >>>> It appears the patch for this ("fix ct-library rows count") has broken compute in ctlib: >>>> >>>> >>>> select col=1 into #tbl insert #tbl values (2) select * from #tbl compute sum(col) >>>> (1 row affected) >>>> (1 row affected) >>>> col >>>> ----------- >>>> 1 >>>> 2 >>>> 2 >>>> >>>> (3 rows affected) >>>> >>>> dblib (and ctlib RC1) does the expected: >>>> >>>> select col=1 into #tbl insert #tbl values (2) select * from #tbl compute sum(col) >>>> (1 row affected) >>>> (1 row affected) >>>> col >>>> ----------- >>>> 1 >>>> 2 >>>> sum >>>> =========== >>>> 3 >>>> >>>> (3 rows affected) >>>> >>>> >>>> Sorry to keep finding things! >>>> >>>> John >>>> >>>> >>> >>> Can you put some more detailed examples? Which program did you use? >>> >>> Frediano >> >> I'm using sqsh. >> >> The compute clause should return an extra result line. In the example I have given above, the table is a single column table with two rows with values 1 and 2. Adding the compute sum clause to the select should return a compute result of 3, instead it is returns an extra copy of the last row. My example is not a special case, no compute (sum, max, min, avg, etc) results seem to be returning from any queries with a compute clause. I never saw this problem before RC4. Backing out the 'fix ct-library rows count' patch on ct.c makes it return the expected result. >> >> John >> > > > Just to be sure, can you test 1.0rc5 ? > I already have. And it looks good. Thanks. While I have your attention, and you are in that part of the code, I wonder if you might look into this: http://lists.ibiblio.org/pipermail/freetds/2016q1/029725.html > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From john at capps.com Wed May 11 16:47:12 2016 From: john at capps.com (John Kendall) Date: Wed, 11 May 2016 20:47:12 +0000 Subject: [freetds] "Fix affected rows after insert with prepared query" side effect In-Reply-To: References: <8D691CA4-C0B7-433B-A434-0D5DDB777EE2@capps.com> <8E4EC81F-7F2E-459A-93C8-14A28DC1E486@capps.com> Message-ID: <0B5780AC-D13F-4EAC-849F-419A3180055F@capps.com> On May 11, 2016, at 1:23 PM, Frediano Ziglio wrote: > 2016-05-11 6:07 GMT+01:00 John Kendall : >> >>> On May 10, 2016, at 3:34 PM, Frediano Ziglio wrote: >>> >>> 2016-05-10 22:31 GMT+01:00 John Kendall : >>>> It appears the patch for this ("fix ct-library rows count") has broken compute in ctlib: >>>> >>>> >>>> select col=1 into #tbl insert #tbl values (2) select * from #tbl compute sum(col) >>>> (1 row affected) >>>> (1 row affected) >>>> col >>>> ----------- >>>> 1 >>>> 2 >>>> 2 >>>> >>>> (3 rows affected) >>>> >>>> dblib (and ctlib RC1) does the expected: >>>> >>>> select col=1 into #tbl insert #tbl values (2) select * from #tbl compute sum(col) >>>> (1 row affected) >>>> (1 row affected) >>>> col >>>> ----------- >>>> 1 >>>> 2 >>>> sum >>>> =========== >>>> 3 >>>> >>>> (3 rows affected) >>>> >>>> >>>> Sorry to keep finding things! >>>> >>>> John >>>> >>>> >>> >>> Can you put some more detailed examples? Which program did you use? >>> >>> Frediano >> >> I'm using sqsh. >> >> The compute clause should return an extra result line. In the example I have given above, the table is a single column table with two rows with values 1 and 2. Adding the compute sum clause to the select should return a compute result of 3, instead it is returns an extra copy of the last row. My example is not a special case, no compute (sum, max, min, avg, etc) results seem to be returning from any queries with a compute clause. I never saw this problem before RC4. Backing out the 'fix ct-library rows count' patch on ct.c makes it return the expected result. >> >> John >> > > > Just to be sure, can you test 1.0rc5 ? > I already have. And it looks good. Thanks. While I have your attention, and you are in that part of the code, I wonder if you might look into this: http://lists.ibiblio.org/pipermail/freetds/2016q1/029725.html I want to clarify what I'm asking you to look into. That was a multi-topic thread. The problem I am still interested in fixing is the ct_compute_info return values. (The rest of that thread turned out to just be client differences.) > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From freddy77 at gmail.com Fri May 13 02:30:05 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Fri, 13 May 2016 07:30:05 +0100 Subject: [freetds] ctlib compute columns (was: "Fix affected rows after insert with prepared query" side effect) Message-ID: It's always a good idea to open a new thread for a new topic! 2016-05-11 21:47 GMT+01:00 John Kendall : > > On May 11, 2016, at 1:23 PM, Frediano Ziglio wrote: > >> 2016-05-11 6:07 GMT+01:00 John Kendall : >>> >>>> On May 10, 2016, at 3:34 PM, Frediano Ziglio wrote: >>>> >>>> 2016-05-10 22:31 GMT+01:00 John Kendall : >>>>> It appears the patch for this ("fix ct-library rows count") has broken compute in ctlib: >>>>> >>>>> >>>>> select col=1 into #tbl insert #tbl values (2) select * from #tbl compute sum(col) >>>>> (1 row affected) >>>>> (1 row affected) >>>>> col >>>>> ----------- >>>>> 1 >>>>> 2 >>>>> 2 >>>>> >>>>> (3 rows affected) >>>>> >>>>> dblib (and ctlib RC1) does the expected: >>>>> >>>>> select col=1 into #tbl insert #tbl values (2) select * from #tbl compute sum(col) >>>>> (1 row affected) >>>>> (1 row affected) >>>>> col >>>>> ----------- >>>>> 1 >>>>> 2 >>>>> sum >>>>> =========== >>>>> 3 >>>>> >>>>> (3 rows affected) >>>>> >>>>> >>>>> Sorry to keep finding things! >>>>> >>>>> John >>>>> >>>>> >>>> >>>> Can you put some more detailed examples? Which program did you use? >>>> >>>> Frediano >>> >>> I'm using sqsh. >>> >>> The compute clause should return an extra result line. In the example I have given above, the table is a single column table with two rows with values 1 and 2. Adding the compute sum clause to the select should return a compute result of 3, instead it is returns an extra copy of the last row. My example is not a special case, no compute (sum, max, min, avg, etc) results seem to be returning from any queries with a compute clause. I never saw this problem before RC4. Backing out the 'fix ct-library rows count' patch on ct.c makes it return the expected result. >>> >>> John >>> >> >> >> Just to be sure, can you test 1.0rc5 ? >> > > I already have. And it looks good. Thanks. > While I have your attention, and you are in that part of the code, I wonder if you might look into this: > > http://lists.ibiblio.org/pipermail/freetds/2016q1/029725.html > > I want to clarify what I'm asking you to look into. That was a multi-topic thread. > The problem I am still interested in fixing is the ct_compute_info return values. > (The rest of that thread turned out to just be client differences.) > Patch looks good. Take a look at "compute operator" in include/freetds/tds.h. Looks like for dblib constants are defined as protocol so no transformation is required however ctlib (and our headers!) contain different constants. Your patch is good however: - I would add a small function to do the conversion; - I would add support for additional mssql operators (I would collapse CNT_BIG into count and *U ones in no -U constants). Frediano From Paul-Andre.Panon at avigilon.com Thu May 12 18:27:48 2016 From: Paul-Andre.Panon at avigilon.com (Paul-Andre Panon) Date: Thu, 12 May 2016 22:27:48 +0000 (UTC) Subject: [freetds] SQL Server Availability Groups References: <036c01d06054$d41268c0$7c373a40$@ladbrokes.com.au> <023d01d064fb$30be4850$923ad8f0$@ladbrokes.com.au> Message-ID: Alistair Roberts ladbrokes.com.au> writes: > > > -----Original Message----- > From: FreeTDS [mailto:freetds-bounces lists.ibiblio.org] On Behalf Of > Frediano Ziglio > Sent: Friday, 20 March 2015 8:25 PM > To: FreeTDS Development Group > Subject: Re: [freetds] SQL Server Availability Groups > > 2015-03-17 1:51 GMT+00:00 Alistair Roberts > ladbrokes.com.au>: > > Hi, > > > > > > > > Does FreeTDS support SQL 2014 Availability Groups? > > > > > > No, but it's open source so adding it would be good. > > > > > We are looking at migrating from SQL 2008 to SQL 2014 and then use > > Availability Groups for the databases. > > > > > > > > Ideally we are looking at using a sole IP but we may need to go with > > the multi-subnet approach for the AG listener. > > > > > > Do you have any details of the protocol and how does it work? > > The availability group has a listener IP and port (often 1433) that SQL > connections are directed to. It is possible to have read only replicas of > the same database. So if a connection has ReadIntent in the connection > string it will go to a read only version. In a multi-subnet cluster configuration, a separate IP address is assigned to the AG listener for each subnet containing a cluster node, where the listener IP address is consistent with the subnet of the the cluster nodes. So, for CIDR/24 subnets, if you have Cluster Node A : IP: aaa.aaa.aaa.xxx Cluster Node B : IP: bbb.bbb.bbb.yyy You will have two entries in DNS as the A record for the AG Listener: aaa.aaa.aaa.mmm and bbb.bbb.bbb.nnn You can have more than one secondary AG replica as well, resulting in more than 2 entries in the A record. The primary replica for the AG will respond to its listener IP address on the designated SQL Server port but the secondary replica node(s) will not respond. (You can configure a different port from 1433 but you want to be consistent across all the cluster nodes since you can only specify one port in the db connection string). The client driver needs to asynchronously attempt to open a TCP connection to all addresses in the DNS A record, then continue with the address which responds and discard the other connection attempt. The Microsoft driver implementations also start additional new TCP connection attempts to all nodes every second. If the ReadIntent option is set in the connection string then, once the connection to the primary (RW) replica is established, there is a new TDS exchange that you can use to find out the address of the read only replica. Once you have that information, the driver can close the connection to the primary replica and re-open a new TCP connection to the read-only replica. SQL Server 2016 Standard Edition apparently uses a limited version of this protocol to completely replace the (no longer supported) SQL Server 2008 database mirroring functionality. While ReadIntent support would be nice, much more important is supporting the multi-subnet connection model. A standard driver will only try the first entry in the DNS A record - if it is not the primary replica, no answer will be received and the connection attempt will fail. Since DNS uses round-robin ordering for multiple address records, there's at best a 50% chance that the connection attempt will fail. > > Regards > > > > > > Alistair Roberts > > > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > Cheers, Paul-Andre From freddy77 at gmail.com Fri May 13 03:08:11 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Fri, 13 May 2016 08:08:11 +0100 Subject: [freetds] SQL Server Availability Groups In-Reply-To: References: <036c01d06054$d41268c0$7c373a40$@ladbrokes.com.au> <023d01d064fb$30be4850$923ad8f0$@ladbrokes.com.au> Message-ID: 2016-05-12 23:27 GMT+01:00 Paul-Andre Panon : > Alistair Roberts ladbrokes.com.au> writes: > >> >> >> -----Original Message----- >> From: FreeTDS [mailto:freetds-bounces lists.ibiblio.org] On Behalf Of >> Frediano Ziglio >> Sent: Friday, 20 March 2015 8:25 PM >> To: FreeTDS Development Group >> Subject: Re: [freetds] SQL Server Availability Groups >> >> 2015-03-17 1:51 GMT+00:00 Alistair Roberts >> ladbrokes.com.au>: >> > Hi, >> > >> > >> > >> > Does FreeTDS support SQL 2014 Availability Groups? >> > >> > >> >> No, but it's open source so adding it would be good. >> >> > >> > We are looking at migrating from SQL 2008 to SQL 2014 and then use >> > Availability Groups for the databases. >> > >> > >> > >> > Ideally we are looking at using a sole IP but we may need to go with >> > the multi-subnet approach for the AG listener. >> > >> > >> >> Do you have any details of the protocol and how does it work? >> >> The availability group has a listener IP and port (often 1433) that SQL >> connections are directed to. It is possible to have read only replicas of >> the same database. So if a connection has ReadIntent in the connection >> string it will go to a read only version. > > In a multi-subnet cluster configuration, a separate IP address is assigned > to the AG listener for each subnet containing a cluster node, where the > listener IP address is consistent with the subnet of the the cluster nodes. > So, for CIDR/24 subnets, if you have > > Cluster Node A : IP: aaa.aaa.aaa.xxx > Cluster Node B : IP: bbb.bbb.bbb.yyy > > You will have two entries in DNS as the A record for the AG Listener: > aaa.aaa.aaa.mmm and bbb.bbb.bbb.nnn > > You can have more than one secondary AG replica as well, resulting in more > than 2 entries in the A record. > > The primary replica for the AG will respond to its listener IP address on > the designated SQL Server port but the secondary replica node(s) will not > respond. (You can configure a different port from 1433 but you want to be > consistent across all the cluster nodes since you can only specify one port > in the db connection string). The client driver needs to asynchronously > attempt to open a TCP connection to all addresses in the DNS A record, then > continue with the address which responds and discard the other connection > attempt. The Microsoft driver implementations also start additional new TCP > connection attempts to all nodes every second. > It make sense. Actually addresses are tried in sequence, not all together. It's not clear the 1-second attempts. I suppose they happens if all first ones failed. > If the ReadIntent option is set in the connection string then, once the > connection to the primary (RW) replica is established, there is a new TDS > exchange that you can use to find out the address of the read only replica. > Once you have that information, the driver can close the connection to the > primary replica and re-open a new TCP connection to the read-only replica. > It's not clear to me how the driver detect if a server is primary or not and how it gets details on the replica, I miss some bits in the protocol but I don't thing are hard to find. > SQL Server 2016 Standard Edition apparently uses a limited version of this > protocol to completely replace the (no longer supported) SQL Server 2008 > database mirroring functionality. > > > While ReadIntent support would be nice, much more important is supporting > the multi-subnet connection model. A standard driver will only try the first > entry in the DNS A record - if it is not the primary replica, no answer will > be received and the connection attempt will fail. Since DNS uses round-robin > ordering for multiple address records, there's at best a 50% chance that the > connection attempt will fail. > Actually ReadIntent is supported, at least you can pass to the server. Also current master will attempt (after a failure) to connect to second host. So you'll get a connection to the first available. What happens if the first that reply is a replica and you don't have the ReadIntent set? Do you have a similar environment setup? Could you do some tests? Could I have some network capture? Frediano From john at capps.com Fri May 13 05:00:52 2016 From: john at capps.com (John Kendall) Date: Fri, 13 May 2016 09:00:52 +0000 Subject: [freetds] ctlib compute columns (was: "Fix affected rows after insert with prepared query" side effect) In-Reply-To: References: Message-ID: > On May 12, 2016, at 11:30 PM, Frediano Ziglio wrote: > > It's always a good idea to open a new thread for a new topic! yes > 2016-05-11 21:47 GMT+01:00 John Kendall : >> >> On May 11, 2016, at 1:23 PM, Frediano Ziglio wrote: >> >>> 2016-05-11 6:07 GMT+01:00 John Kendall : >>>> >>>>> On May 10, 2016, at 3:34 PM, Frediano Ziglio wrote: >>>>> >>>>> 2016-05-10 22:31 GMT+01:00 John Kendall : >>>>>> It appears the patch for this ("fix ct-library rows count") has broken compute in ctlib: >>>>>> >>>>>> >>>>>> select col=1 into #tbl insert #tbl values (2) select * from #tbl compute sum(col) >>>>>> (1 row affected) >>>>>> (1 row affected) >>>>>> col >>>>>> ----------- >>>>>> 1 >>>>>> 2 >>>>>> 2 >>>>>> >>>>>> (3 rows affected) >>>>>> >>>>>> dblib (and ctlib RC1) does the expected: >>>>>> >>>>>> select col=1 into #tbl insert #tbl values (2) select * from #tbl compute sum(col) >>>>>> (1 row affected) >>>>>> (1 row affected) >>>>>> col >>>>>> ----------- >>>>>> 1 >>>>>> 2 >>>>>> sum >>>>>> =========== >>>>>> 3 >>>>>> >>>>>> (3 rows affected) >>>>>> >>>>>> >>>>>> Sorry to keep finding things! >>>>>> >>>>>> John >>>>>> >>>>>> >>>>> >>>>> Can you put some more detailed examples? Which program did you use? >>>>> >>>>> Frediano >>>> >>>> I'm using sqsh. >>>> >>>> The compute clause should return an extra result line. In the example I have given above, the table is a single column table with two rows with values 1 and 2. Adding the compute sum clause to the select should return a compute result of 3, instead it is returns an extra copy of the last row. My example is not a special case, no compute (sum, max, min, avg, etc) results seem to be returning from any queries with a compute clause. I never saw this problem before RC4. Backing out the 'fix ct-library rows count' patch on ct.c makes it return the expected result. >>>> >>>> John >>>> >>> >>> >>> Just to be sure, can you test 1.0rc5 ? >>> >> >> I already have. And it looks good. Thanks. >> While I have your attention, and you are in that part of the code, I wonder if you might look into this: >> >> http://lists.ibiblio.org/pipermail/freetds/2016q1/029725.html >> >> I want to clarify what I'm asking you to look into. That was a multi-topic thread. >> The problem I am still interested in fixing is the ct_compute_info return values. >> (The rest of that thread turned out to just be client differences.) >> > > Patch looks good. Take a look at "compute operator" in include/freetds/tds.h. > > Looks like for dblib constants are defined as protocol so no > transformation is required however ctlib (and our headers!) contain > different constants. Your patch is good however: > - I would add a small function to do the conversion; > - I would add support for additional mssql operators (I would collapse > CNT_BIG into count and *U ones in no -U constants). Aha! found them in include/freetds/proto.h. Thanks. Agree with your suggestions. Not sure what to do with these, however: SYBAOPSTDEV SYBAOPSTDEVP SYBAOPVAR SYBAOPVARP SYBAOPCHECKSUM_AGG I don't see an obvious mapping for them. This works for me: *** ct.c-orig 2016-05-11 12:49:42 -0700 --- ct.c 2016-05-13 01:46:33 -0700 *************** *** 57,62 **** --- 57,63 ---- int _ct_bind_data(CS_CONTEXT *ctx, TDSRESULTINFO * resinfo, TDSRESULTINFO *bindinfo, CS_INT offset); static void _ct_initialise_cmd(CS_COMMAND *cmd); static CS_RETCODE _ct_cancel_cleanup(CS_COMMAND * cmd); + static CS_INT _ct_map_compute_op(CS_INT comp_op); /* Added for CT_DIAG */ /* Code changes starts here - CT_DIAG - 01 */ *************** *** 2655,2661 **** int_val = 0; } else { curcol = resinfo->columns[colnum - 1]; ! int_val = curcol->column_operator; } memcpy(buffer, &int_val, sizeof(CS_INT)); if (outlen) --- 2656,2662 ---- int_val = 0; } else { curcol = resinfo->columns[colnum - 1]; ! int_val = _ct_map_compute_op(curcol->column_operator); } memcpy(buffer, &int_val, sizeof(CS_INT)); if (outlen) *************** *** 4630,4632 **** --- 4631,4655 ---- return CS_SUCCEED; } + static CS_INT + _ct_map_compute_op(CS_INT comp_op) + { + switch (comp_op) + { + case SYBAOPCNT: + case SYBAOPCNTU: + case SYBAOPCNT_BIG: + return CS_OP_COUNT; + case SYBAOPSUM: + case SYBAOPSUMU: + return CS_OP_SUM; + case SYBAOPAVG: + case SYBAOPAVGU: + return CS_OP_AVG; + case SYBAOPMIN: + return CS_OP_MIN; + case SYBAOPMAX: + return CS_OP_MAX; + } + return comp_op; + } John > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From freddy77 at gmail.com Wed May 18 16:41:01 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Wed, 18 May 2016 21:41:01 +0100 Subject: [freetds] FreeTDS 1.0 Released! Message-ID: Hi, finally ready. Changes (from NEWS file) User visible (not in a particular order): - Removed "8.0" from protocol version string accepted. Please update configuration files; - Default protocol version is now auto. This could slow down connection but make user experience less painful; - Sybase encrypted login. Set encryption to get it; - Support protocol version 7.4; - Add intent support to specify we don't want to change data; - Allow to attach database file during the login (MS SQL Server); - Support for Sybase time/date/bigdate/bigdatetime; - Pool is working again; - ODBC BCP (not complete); - Improved dbconvert and dbconvert_ps (more compatible); - Fixed dbspid; - Improved ODBC type information; - Better certificate verification; - AppVeyor is used for every build; - Try all IPs from DNS. This allows SQL Cluster connection to secondary servers. Implementation: - Removed Nmake support; - Type conversions simplified; - Better type handle code. Frediano From john at capps.com Wed May 18 16:49:13 2016 From: john at capps.com (John Kendall) Date: Wed, 18 May 2016 20:49:13 +0000 Subject: [freetds] TDS_INT8_MIN determined by shifting a negative value Message-ID: Is there another way to determine TDS_INT8_MIN in convert.c (line 96)? The new llvm compiler on OS X 10.11 is complaining about bit shifting a negative: warning: shifting a negative signed value is undefined [-Wshift-negative-value] John From cramm0 at gmail.com Wed May 18 17:01:16 2016 From: cramm0 at gmail.com (Ramiro Morales) Date: Wed, 18 May 2016 18:01:16 -0300 Subject: [freetds] FreeTDS 1.0 Released! In-Reply-To: References: Message-ID: Frediano, This is great news! My english is very basic so I'm afraid I'll be unable to find the word to convey how much I thank you and admire you for your sustained efforts driving recent releases. I don't want to forget to past project maintainers. Reaching 1.0 has been a long road. Thanks goes to them too! Regards, On Wed, May 18, 2016 at 5:41 PM, Frediano Ziglio wrote: > Hi, > finally ready. Changes (from NEWS file) > > > User visible (not in a particular order): > - Removed "8.0" from protocol version string accepted. Please > update configuration files; > - Default protocol version is now auto. This could slow down > connection but make user experience less painful; > - Sybase encrypted login. Set encryption to get it; > - Support protocol version 7.4; > - Add intent support to specify we don't want to change data; > - Allow to attach database file during the login (MS SQL Server); > - Support for Sybase time/date/bigdate/bigdatetime; > - Pool is working again; > - ODBC BCP (not complete); > - Improved dbconvert and dbconvert_ps (more compatible); > - Fixed dbspid; > - Improved ODBC type information; > - Better certificate verification; > - AppVeyor is used for every build; > - Try all IPs from DNS. This allows SQL Cluster connection > to secondary servers. > > Implementation: > - Removed Nmake support; > - Type conversions simplified; > - Better type handle code. > > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > -- Ramiro Morales @ramiromorales From john at capps.com Wed May 18 17:07:16 2016 From: john at capps.com (John Kendall) Date: Wed, 18 May 2016 21:07:16 +0000 Subject: [freetds] FreeTDS 1.0 Released! In-Reply-To: References: Message-ID: <4AD542C6-111B-4B5B-851C-E993B046ECFF@capps.com> I agree. 1.0 seems like a huge number after all these years! Many thanks to all, especially Frediano. John On May 18, 2016, at 2:01 PM, Ramiro Morales wrote: > Frediano, > > This is great news! > > My english is very basic so I'm afraid I'll be unable to find the word to > convey how much I thank you and admire you for your sustained efforts > driving recent releases. > > I don't want to forget to past project maintainers. Reaching 1.0 has been a > long road. Thanks goes to them too! > > Regards, > > > > On Wed, May 18, 2016 at 5:41 PM, Frediano Ziglio wrote: > >> Hi, >> finally ready. Changes (from NEWS file) >> >> >> User visible (not in a particular order): >> - Removed "8.0" from protocol version string accepted. Please >> update configuration files; >> - Default protocol version is now auto. This could slow down >> connection but make user experience less painful; >> - Sybase encrypted login. Set encryption to get it; >> - Support protocol version 7.4; >> - Add intent support to specify we don't want to change data; >> - Allow to attach database file during the login (MS SQL Server); >> - Support for Sybase time/date/bigdate/bigdatetime; >> - Pool is working again; >> - ODBC BCP (not complete); >> - Improved dbconvert and dbconvert_ps (more compatible); >> - Fixed dbspid; >> - Improved ODBC type information; >> - Better certificate verification; >> - AppVeyor is used for every build; >> - Try all IPs from DNS. This allows SQL Cluster connection >> to secondary servers. >> >> Implementation: >> - Removed Nmake support; >> - Type conversions simplified; >> - Better type handle code. >> >> >> Frediano >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> http://lists.ibiblio.org/mailman/listinfo/freetds >> > > > > -- > Ramiro Morales > @ramiromorales > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From randy at thesyrings.us Wed May 18 17:23:20 2016 From: randy at thesyrings.us (Randy Syring) Date: Wed, 18 May 2016 17:23:20 -0400 Subject: [freetds] FreeTDS 1.0 Released! In-Reply-To: References: Message-ID: <573CDD48.8040903@thesyrings.us> Great job, really! Persistent, faithful execution. *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 05/18/2016 04:41 PM, Frediano Ziglio wrote: > Hi, > finally ready. Changes (from NEWS file) > > > User visible (not in a particular order): > - Removed "8.0" from protocol version string accepted. Please > update configuration files; > - Default protocol version is now auto. This could slow down > connection but make user experience less painful; > - Sybase encrypted login. Set encryption to get it; > - Support protocol version 7.4; > - Add intent support to specify we don't want to change data; > - Allow to attach database file during the login (MS SQL Server); > - Support for Sybase time/date/bigdate/bigdatetime; > - Pool is working again; > - ODBC BCP (not complete); > - Improved dbconvert and dbconvert_ps (more compatible); > - Fixed dbspid; > - Improved ODBC type information; > - Better certificate verification; > - AppVeyor is used for every build; > - Try all IPs from DNS. This allows SQL Cluster connection > to secondary servers. > > Implementation: > - Removed Nmake support; > - Type conversions simplified; > - Better type handle code. > > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > From no-reply at appveyor.com Wed May 18 18:44:37 2016 From: no-reply at appveyor.com (AppVeyor) Date: Wed, 18 May 2016 22:44:37 +0000 Subject: [freetds] Build failed: freetds 580 Message-ID: <20160518224434.36181.83108.7B582AB9@appveyor.com> From lacak at zoznam.sk Thu May 19 01:05:52 2016 From: lacak at zoznam.sk (LacaK) Date: Thu, 19 May 2016 07:05:52 +0200 Subject: [freetds] FreeTDS 1.0 Released! In-Reply-To: References: Message-ID: <573D49B0.1080505@zoznam.sk> Thanks! -Laco. > Hi, > finally ready. Changes (from NEWS file) > > > User visible (not in a particular order): > - Removed "8.0" from protocol version string accepted. Please > update configuration files; > - Default protocol version is now auto. This could slow down > connection but make user experience less painful; > - Sybase encrypted login. Set encryption to get it; > - Support protocol version 7.4; > - Add intent support to specify we don't want to change data; > - Allow to attach database file during the login (MS SQL Server); > - Support for Sybase time/date/bigdate/bigdatetime; > - Pool is working again; > - ODBC BCP (not complete); > - Improved dbconvert and dbconvert_ps (more compatible); > - Fixed dbspid; > - Improved ODBC type information; > - Better certificate verification; > - AppVeyor is used for every build; > - Try all IPs from DNS. This allows SQL Cluster connection > to secondary servers. > > Implementation: > - Removed Nmake support; > - Type conversions simplified; > - Better type handle code. > > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > From freddy77 at gmail.com Thu May 19 06:52:57 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Thu, 19 May 2016 11:52:57 +0100 Subject: [freetds] TDS_INT8_MIN determined by shifting a negative value In-Reply-To: References: Message-ID: 2016-05-18 21:49 GMT+01:00 John Kendall : > Is there another way to determine TDS_INT8_MIN in convert.c (line 96)? > > The new llvm compiler on OS X 10.11 is complaining about bit shifting a negative: > > warning: shifting a negative signed value is undefined [-Wshift-negative-value] > > John > I would go for something like #define TDS_INT8_MIN (-((TDS_INT8)1)<<62)-((TDS_INT8)1)<<62)) Frediano From craigberry at mac.com Thu May 19 07:06:08 2016 From: craigberry at mac.com (Craig A. Berry) Date: Thu, 19 May 2016 06:06:08 -0500 Subject: [freetds] FreeTDS 1.0 Released! In-Reply-To: References: Message-ID: <536375BC-52D6-4644-B487-6EA53E7E718A@mac.com> > On May 18, 2016, at 3:41 PM, Frediano Ziglio wrote: > > Hi, > finally ready. Congratulations! ________________________________________ Craig A. Berry "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser From no-reply at appveyor.com Thu May 19 08:36:00 2016 From: no-reply at appveyor.com (AppVeyor) Date: Thu, 19 May 2016 12:36:00 +0000 Subject: [freetds] Build failed: freetds 590 Message-ID: <20160519123558.9588.41129.F416656B@appveyor.com> From sf at 4js.com Fri May 20 03:58:39 2016 From: sf at 4js.com (Sebastien FLAESCH) Date: Fri, 20 May 2016 09:58:39 +0200 Subject: [freetds] FreeTDS 1.0 Released! In-Reply-To: References: Message-ID: <573EC3AF.6010007@4js.com> Hi all, This is great! Congrats to all contributors (special thanks to Frediano!) We will give it a try and execute our QA test suite with this version. Seb On 05/18/2016 10:41 PM, Frediano Ziglio wrote: > Hi, > finally ready. Changes (from NEWS file) > > > User visible (not in a particular order): > - Removed "8.0" from protocol version string accepted. Please > update configuration files; > - Default protocol version is now auto. This could slow down > connection but make user experience less painful; > - Sybase encrypted login. Set encryption to get it; > - Support protocol version 7.4; > - Add intent support to specify we don't want to change data; > - Allow to attach database file during the login (MS SQL Server); > - Support for Sybase time/date/bigdate/bigdatetime; > - Pool is working again; > - ODBC BCP (not complete); > - Improved dbconvert and dbconvert_ps (more compatible); > - Fixed dbspid; > - Improved ODBC type information; > - Better certificate verification; > - AppVeyor is used for every build; > - Try all IPs from DNS. This allows SQL Cluster connection > to secondary servers. > > Implementation: > - Removed Nmake support; > - Type conversions simplified; > - Better type handle code. > > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > From sf at 4js.com Fri May 20 07:47:43 2016 From: sf at 4js.com (Sebastien FLAESCH) Date: Fri, 20 May 2016 13:47:43 +0200 Subject: [freetds] FreeTDS 1.0 Released! In-Reply-To: <573EC3AF.6010007@4js.com> References: <573EC3AF.6010007@4js.com> Message-ID: <573EF95F.4020203@4js.com> FYI, our specific QA tests passed with success. Seb On 05/20/2016 09:58 AM, Sebastien FLAESCH wrote: > Hi all, > > This is great! > > Congrats to all contributors (special thanks to Frediano!) > > We will give it a try and execute our QA test suite with this version. > > Seb > > On 05/18/2016 10:41 PM, Frediano Ziglio wrote: >> Hi, >> finally ready. Changes (from NEWS file) >> >> >> User visible (not in a particular order): >> - Removed "8.0" from protocol version string accepted. Please >> update configuration files; >> - Default protocol version is now auto. This could slow down >> connection but make user experience less painful; >> - Sybase encrypted login. Set encryption to get it; >> - Support protocol version 7.4; >> - Add intent support to specify we don't want to change data; >> - Allow to attach database file during the login (MS SQL Server); >> - Support for Sybase time/date/bigdate/bigdatetime; >> - Pool is working again; >> - ODBC BCP (not complete); >> - Improved dbconvert and dbconvert_ps (more compatible); >> - Fixed dbspid; >> - Improved ODBC type information; >> - Better certificate verification; >> - AppVeyor is used for every build; >> - Try all IPs from DNS. This allows SQL Cluster connection >> to secondary servers. >> >> Implementation: >> - Removed Nmake support; >> - Type conversions simplified; >> - Better type handle code. >> >> >> 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 no-reply at appveyor.com Sat May 21 10:51:56 2016 From: no-reply at appveyor.com (AppVeyor) Date: Sat, 21 May 2016 14:51:56 +0000 Subject: [freetds] Build completed: freetds 591 Message-ID: <20160521145156.99039.46246.15AFF627@appveyor.com> From no-reply at appveyor.com Fri May 27 03:09:11 2016 From: no-reply at appveyor.com (AppVeyor) Date: Fri, 27 May 2016 07:09:11 +0000 Subject: [freetds] Build failed: freetds 606 Message-ID: <20160527070911.13771.24860.3EB68DD0@appveyor.com> From no-reply at appveyor.com Fri May 27 06:55:36 2016 From: no-reply at appveyor.com (AppVeyor) Date: Fri, 27 May 2016 10:55:36 +0000 Subject: [freetds] Build completed: freetds 607 Message-ID: <20160527100035.4847.50895.9DDAC182@appveyor.com> From no-reply at appveyor.com Mon May 30 13:58:35 2016 From: no-reply at appveyor.com (AppVeyor) Date: Mon, 30 May 2016 17:58:35 +0000 Subject: [freetds] Build failed: freetds 610 Message-ID: <20160530175834.30691.24127.0EF4B72F@appveyor.com> From no-reply at appveyor.com Mon May 30 14:49:38 2016 From: no-reply at appveyor.com (AppVeyor) Date: Mon, 30 May 2016 18:49:38 +0000 Subject: [freetds] Build completed: freetds 611 Message-ID: <20160530184921.110806.3000.0BBBD57E@appveyor.com> From no-reply at appveyor.com Sat Jun 4 23:26:21 2016 From: no-reply at appveyor.com (AppVeyor) Date: Sun, 05 Jun 2016 03:26:21 +0000 Subject: [freetds] Build failed: freetds 616 Message-ID: <20160605032620.23354.29032.9B0ECE6D@appveyor.com> From john at capps.com Sun Jun 5 04:56:43 2016 From: john at capps.com (John Kendall) Date: Sun, 5 Jun 2016 08:56:43 +0000 Subject: [freetds] bcp -n -E fails on identity column Message-ID: Using the bcp -n (native file format) and -E (retain identity values) options together produces: Msg 20053, Level 4 Requested data conversion does not exist I see this happening on Sybase (11 & 16) and MS SQL 2008. Test to reproduce: select id_col=identity(5) into tempdb..tbl -- Sybase select id_col=identity(int) into tempdb..tbl -- MS SQL $ freebcp tempdb..tbl out tbl.bcp -S $DSQUERY -U usr -P pw -n -E Starting copy... Msg 20053, Level 4 Requested data conversion does not exist bcp copy out failed datacopy also has a problem with the -E option, I assume the problems are related. John From freddy77 at gmail.com Sun Jun 5 08:12:48 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Sun, 5 Jun 2016 13:12:48 +0100 Subject: [freetds] bcp -n -E fails on identity column In-Reply-To: References: Message-ID: On 5 Jun 2016 09:56, "John Kendall" wrote: > > Using the bcp -n (native file format) and -E (retain identity values) options together produces: > > Msg 20053, Level 4 > Requested data conversion does not exist > > > I see this happening on Sybase (11 & 16) and MS SQL 2008. > > > Test to reproduce: > > select id_col=identity(5) into tempdb..tbl -- Sybase > select id_col=identity(int) into tempdb..tbl -- MS SQL > > $ freebcp tempdb..tbl out tbl.bcp -S $DSQUERY -U usr -P pw -n -E > > Starting copy... > > Msg 20053, Level 4 > Requested data conversion does not exist > > bcp copy out failed > > datacopy also has a problem with the -E option, I assume the problems are related. > > John > > Which FreeTDS version are you using? Frediano From john at capps.com Sun Jun 5 13:15:34 2016 From: john at capps.com (John Kendall) Date: Sun, 5 Jun 2016 17:15:34 +0000 Subject: [freetds] [GRAYMAIL] bcp -n -E fails on identity column In-Reply-To: References: Message-ID: <466F87BD-615A-452E-877D-7D774D1D49BD@capps.com> > On Jun 5, 2016, at 5:12 AM, Frediano Ziglio wrote: > > On 5 Jun 2016 09:56, "John Kendall" wrote: >> >> Using the bcp -n (native file format) and -E (retain identity values) >> options together produces: >> >> Msg 20053, Level 4 >> Requested data conversion does not exist >> >> >> I see this happening on Sybase (11 & 16) and MS SQL 2008. >> >> >> Test to reproduce: >> >> select id_col=identity(5) into tempdb..tbl -- Sybase >> select id_col=identity(int) into tempdb..tbl -- MS SQL >> >> $ freebcp tempdb..tbl out tbl.bcp -S $DSQUERY -U usr -P pw -n -E >> >> Starting copy... >> >> Msg 20053, Level 4 >> Requested data conversion does not exist >> >> bcp copy out failed >> >> datacopy also has a problem with the -E option, I assume the problems are >> related. >> >> John >> >> > > Which FreeTDS version are you using? Sorry, those error messages came from an old v0.95.19 install. Using version 1.0, the bcp still fails, but with this message: Msg 20060, Level 11 Unknown datatype encountered Error in bcp_colfmt col 1 > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From paul-andre.panon at avigilon.com Wed May 18 18:56:19 2016 From: paul-andre.panon at avigilon.com (Paul-Andre Panon) Date: Wed, 18 May 2016 22:56:19 -0000 Subject: [freetds] SQL Server Availability Groups In-Reply-To: References: <036c01d06054$d41268c0$7c373a40$@ladbrokes.com.au> <023d01d064fb$30be4850$923ad8f0$@ladbrokes.com.au> Message-ID: Sorry about the long delay in my reply but I got busy on some other stuff. Congratulations on 1.0. I'm impressed you managed to include some support for this at the last minute. 2015-05-13 12:08 GMT-07:00 Frediano Ziglio wrote: > >2016-05-12 23:27 GMT+01:00 Paul-Andre Panon : >> In a multi-subnet cluster configuration, a separate IP address is >> assigned to the AG listener for each subnet containing a cluster node, >> where the listener IP address is consistent with the subnet of the the cluster nodes. >> So, for CIDR/24 subnets, if you have >> >> Cluster Node A : IP: aaa.aaa.aaa.xxx >> Cluster Node B : IP: bbb.bbb.bbb.yyy >> >> You will have two entries in DNS as the A record for the AG Listener: >> aaa.aaa.aaa.mmm and bbb.bbb.bbb.nnn >> >> You can have more than one secondary AG replica as well, resulting in >> more than 2 entries in the A record. >> >> The primary replica for the AG will respond to its listener IP address >> on the designated SQL Server port but the secondary replica node(s) >> will not respond. (You can configure a different port from 1433 but >> you want to be consistent across all the cluster nodes since you can >> only specify one port in the db connection string). The client driver >> needs to asynchronously attempt to open a TCP connection to all >> addresses in the DNS A record, then continue with the address which >> responds and discard the other connection attempt. The Microsoft >> driver implementations also start additional new TCP connection attempts to all nodes every second. >> > >It make sense. Actually addresses are tried in sequence, not all together. >It's not clear the 1-second attempts. I suppose they happens if all first ones failed. Well that's not what the technet article says. Look at the first two paragraphs in the section Connecting with MultiSubnetFailover on https://msdn.microsoft.com/en-us/library/hh205662 "During a multi-subnet failover, the client will attempt connections in parallel." Also, I interpreted "During a subnet failover, will aggressively retry the TCP connection." to mean that it opens multiple connections to each IP address. You can't just close the old one after 1 second because it might actually take more than one second to connect. The reason is that during a failover from one node to another (even with a controlled manual failover) the transition is not immediate and takes a few seconds. So rather than have the client be dependent on the exponentially increasing delay between packets of a standard TCP connect, it somehow makes more SYN packets be sent out with a 1s spacing. I'm assuming it does this with additional connections but maybe there's another way to do it. I haven't looked at what the MS JDBC driver code does, only at packet captures. I only ever saw it happen once in a packet capture, so it might have just been due to a SYN packet dropped by the network. > >> If the ReadIntent option is set in the connection string then, once >> the connection to the primary (RW) replica is established, there is a >> new TDS exchange that you can use to find out the address of the read only replica. >> Once you have that information, the driver can close the connection to >> the primary replica and re-open a new TCP connection to the read-only replica. >> > >It's not clear to me how the driver detect if a server is primary or not and how it gets details on the replica, I miss some bits in the protocol but I don't thing are hard to find. Only the cluster node hosting the primary replica answers TCP connection requests. So out of N IP addresses in the A record, only the primary replies. This is why you need to try them in parallel, because otherwise you need to wait for the connection timeout on each address, and timing out on 2 or 3 secondary addresses in sequence can take you past the login timeout before you get to the primary's IP address. You need to set up read-only routing to indicate what secondaries should handle read-only requests. I didn't set it up because we didn't see a need for it. I do remember seeing a link that talked about how it worked with TDS, but I can't find it right now. Here's a related MSDN article on the server-side configuration. https://msdn.microsoft.com/en-us/library/hh710054 You can see with the read-only route URL syntax for each replica, that it indicates a URL directly to the cluster node designated as a secondary replica (so it's a different computer name, and potentially port, as the listener). ALTER AVAILABILITY GROUP [] MODIFY REPLICA ON N'' WITH (SECONDARY_ROLE(READ_ONLY_ROUTING_URL=N'tcp://:')) Then the read_only_routing_list indicates multiple replicas, each with a URL to the hosting cluster node. The question is: what query does the stock MS client driver use to get the routing URL list so it can re-open a new connection to an appropriate cluster node? You could probably get that through a packet capture, but I didn't need or research that. I didn't find it in a web search. >> SQL Server 2016 Standard Edition apparently uses a limited version of >> this protocol to completely replace the (no longer supported) SQL >> Server 2008 database mirroring functionality. >> >> >> While ReadIntent support would be nice, much more important is >> supporting the multi-subnet connection model. A standard driver will >> only try the first entry in the DNS A record - if it is not the >> primary replica, no answer will be received and the connection attempt >> will fail. Since DNS uses round-robin ordering for multiple address >> records, there's at best a 50% chance that the connection attempt will fail. >> > >Actually ReadIntent is supported, at least you can pass to the server. >Also current master will attempt (after a failure) to connect to second host. >So you'll get a connection to the first available. > >What happens if the first that reply is a replica and you don't have the ReadIntent set? You will never get an answer from the listener IP address of a secondary replica. You can see the same thing with ICMP echos actually (as long as you don't block them with the Windows firewall). Ping the two+ IP addresses of an AG Listener and only the address associated with the primary replica will reply. >Do you have a similar environment setup? Yes. I was trying to do something similar for the jTDS driver. I ran some captures of some testing with the MS JDBC driver to observe its network behavior. My jTDS seemed to work if I used a Java NIO non-blocking socket for the connection and then switched them to blocking sockets after the connection was established, however that had some overhead. To avoid that overhead, I then tried to spin up a thread for each connection with standard blocking socket connects, but my thread synchronization was causing problems/interactions with the multiple threads of the calling application. >Could you do some tests? You probably can soon as well. SQL Server 2016 is to be released on June 1, so you could either use the developer or standard editions to set up a test cluster. The developer edition is supposed to be free and has full enterprise-equivalent functionality. If you have a VM environment, you should be able to set up a small 2 node cluster for testing. >Could I have some network capture? I do still have one Wireshark traffic capture from my JDBC tests, but it's not the one that shows the second retried SYN after 1sec. It also is a straight connect to the primary, not a read-intent connection to a secondary. Let me know where you want it. I don't have anything from any MS drivers for other frameworks like Native/OLE, or ODBC. >Frediano From ikorot01 at gmail.com Sun Jun 5 15:17:08 2016 From: ikorot01 at gmail.com (Igor Korot) Date: Sun, 5 Jun 2016 15:17:08 -0400 Subject: [freetds] OSX distribution Message-ID: Hi, ALL, Is there a dmg file to download for the release? Thank you. From dl.soluz at gmx.net Wed May 18 17:12:10 2016 From: dl.soluz at gmx.net (Dennis Luehring) Date: Wed, 18 May 2016 21:12:10 -0000 Subject: [freetds] FreeTDS 1.0 Released! In-Reply-To: References: Message-ID: <35e31714-363b-7712-ebb0-d1e18980a918@gmx.net> http://cppcheck.sourceforge.net/ found serveral small/big flaws (small memory leaks, out of bounds accessess etc.) are using address- and thread-sanitzer for testing? - great tools to find any memory access bugs Am 18.05.2016 um 22:41 schrieb Frediano Ziglio: > Hi, > finally ready. Changes (from NEWS file) > > > User visible (not in a particular order): > - Removed "8.0" from protocol version string accepted. Please > update configuration files; > - Default protocol version is now auto. This could slow down > connection but make user experience less painful; > - Sybase encrypted login. Set encryption to get it; > - Support protocol version 7.4; > - Add intent support to specify we don't want to change data; > - Allow to attach database file during the login (MS SQL Server); > - Support for Sybase time/date/bigdate/bigdatetime; > - Pool is working again; > - ODBC BCP (not complete); > - Improved dbconvert and dbconvert_ps (more compatible); > - Fixed dbspid; > - Improved ODBC type information; > - Better certificate verification; > - AppVeyor is used for every build; > - Try all IPs from DNS. This allows SQL Cluster connection > to secondary servers. > > Implementation: > - Removed Nmake support; > - Type conversions simplified; > - Better type handle code. > > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From a_wake at earthlink.net Tue May 31 13:38:57 2016 From: a_wake at earthlink.net (Andy Wakefield) Date: Tue, 31 May 2016 13:38:57 -0400 Subject: [freetds] version 1.0 In-Reply-To: References: Message-ID: <574DCC31.1040804@earthlink.net> Freddy, Great news on releasing 1.0, and many, many thanks to you and all who have worked so hard to make this excellent software available! One quick question - is git the only way to download version 1.0? I checked the website, and the "latest stable release" is still coming up with 0.95. Andy Wakefield From DJacopille at MFS.com Wed May 18 17:43:06 2016 From: DJacopille at MFS.com (Jacopille, David) Date: Wed, 18 May 2016 21:43:06 -0000 Subject: [freetds] FreeTDS 1.0 Released! In-Reply-To: References: Message-ID: Frediano and all, Thank you for the long term hard work. I wish there was a way to convey the quantity of work sitting on the shoulders of a solid FreeTDS implementation. Without being able to measure the benefit you may not know the gratitude deserved. It?s surely a staggering amount. Dave Jacopille On 5/18/16, 4:41 PM, "FreeTDS on behalf of Frediano Ziglio" wrote: >Hi, > finally ready. Changes (from NEWS file) > > >User visible (not in a particular order): >- Removed "8.0" from protocol version string accepted. Please > update configuration files; >- Default protocol version is now auto. This could slow down > connection but make user experience less painful; >- Sybase encrypted login. Set encryption to get it; >- Support protocol version 7.4; >- Add intent support to specify we don't want to change data; >- Allow to attach database file during the login (MS SQL Server); >- Support for Sybase time/date/bigdate/bigdatetime; >- Pool is working again; >- ODBC BCP (not complete); >- Improved dbconvert and dbconvert_ps (more compatible); >- Fixed dbspid; >- Improved ODBC type information; >- Better certificate verification; >- AppVeyor is used for every build; >- Try all IPs from DNS. This allows SQL Cluster connection > to secondary servers. > >Implementation: >- Removed Nmake support; >- Type conversions simplified; >- Better type handle code. > > >Frediano >_______________________________________________ >FreeTDS mailing list >FreeTDS at lists.ibiblio.org >http://lists.ibiblio.org/mailman/listinfo/freetds MFS Email system made the following annotation --------------------------------------------------------------------------------------------------------------------------------------- This email communication and any attachments may contain proprietary, confidential, or privileged information. If you are not the intended recipient, you are hereby notified that you have received this email in error and that any review, disclosure, dissemination, distribution or copying of it or its contents is prohibited. The sender does not waive confidentiality or any privilege by mistransmission. If you have received this email in error, please notify the sender immediately, delete this email, and destroy all copies and any attachments. From freddy77 at gmail.com Mon Jun 6 06:06:08 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Mon, 6 Jun 2016 11:06:08 +0100 Subject: [freetds] OSX distribution In-Reply-To: References: Message-ID: 2016-06-05 20:17 GMT+01:00 Igor Korot : > Hi, ALL, > Is there a dmg file to download for the release? > > Thank you. There is actually not any official Mac OS X release package. Frediano From freddy77 at gmail.com Mon Jun 6 06:22:56 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Mon, 6 Jun 2016 11:22:56 +0100 Subject: [freetds] version 1.0 In-Reply-To: <574DCC31.1040804@earthlink.net> References: <574DCC31.1040804@earthlink.net> Message-ID: 2016-05-31 18:38 GMT+01:00 Andy Wakefield : > Freddy, > > Great news on releasing 1.0, and many, many thanks to you and all who have > worked so hard to make this excellent software available! > Thanks! > One quick question - is git the only way to download version 1.0? I checked > the website, and the "latest stable release" is still coming up with 0.95. > > Andy Wakefield Just a problem in the script. Just fixed. Note that at ftp://ftp.freetds.org/pub/freetds/ you can access all content Frediano From freddy77 at gmail.com Mon Jun 6 06:31:06 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Mon, 6 Jun 2016 11:31:06 +0100 Subject: [freetds] FreeTDS 1.0 Released! In-Reply-To: <35e31714-363b-7712-ebb0-d1e18980a918@gmx.net> References: <35e31714-363b-7712-ebb0-d1e18980a918@gmx.net> Message-ID: 2016-05-18 22:12 GMT+01:00 Dennis Luehring : > http://cppcheck.sourceforge.net/ found serveral small/big flaws (small > memory leaks, out of bounds accessess etc.) > > are using address- and thread-sanitzer for testing? - great tools to find > any memory access bugs > Valgrind, Coverity (https://scan.coverity.com/projects/freetds2, now a bit higher as is using master), address sanitizer for my tests. Looks like numeric code is so complicated no tools is able to understand there are no overflows :-) Frediano > > Am 18.05.2016 um 22:41 schrieb Frediano Ziglio: >> >> Hi, >> finally ready. Changes (from NEWS file) >> >> >> User visible (not in a particular order): >> - Removed "8.0" from protocol version string accepted. Please >> update configuration files; >> - Default protocol version is now auto. This could slow down >> connection but make user experience less painful; >> - Sybase encrypted login. Set encryption to get it; >> - Support protocol version 7.4; >> - Add intent support to specify we don't want to change data; >> - Allow to attach database file during the login (MS SQL Server); >> - Support for Sybase time/date/bigdate/bigdatetime; >> - Pool is working again; >> - ODBC BCP (not complete); >> - Improved dbconvert and dbconvert_ps (more compatible); >> - Fixed dbspid; >> - Improved ODBC type information; >> - Better certificate verification; >> - AppVeyor is used for every build; >> - Try all IPs from DNS. This allows SQL Cluster connection >> to secondary servers. >> >> Implementation: >> - Removed Nmake support; >> - Type conversions simplified; >> - Better type handle code. >> >> >> Frediano From sf at 4js.com Thu Jun 9 04:40:34 2016 From: sf at 4js.com (Sebastien FLAESCH) Date: Thu, 9 Jun 2016 10:40:34 +0200 Subject: [freetds] OSX distribution In-Reply-To: References: Message-ID: <57592B82.6010204@4js.com> Hi Frediano, Ok there is not .dmg package, but is Mac OSX supported by FreeTDS 1.0? Do the source compile (I guess so, have seen "MACOSX" strings in the configure file. Are there tests done etc ? Where can we find the list of supported platforms BTW? Thanks, Seb On 06/06/2016 12:06 PM, Frediano Ziglio wrote: > 2016-06-05 20:17 GMT+01:00 Igor Korot : >> Hi, ALL, >> Is there a dmg file to download for the release? >> >> Thank you. > > > There is actually not any official Mac OS X release package. > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > From dl.soluz at gmx.net Mon Jun 6 06:53:03 2016 From: dl.soluz at gmx.net (Dennis Luehring) Date: Mon, 6 Jun 2016 12:53:03 +0200 Subject: [freetds] FreeTDS 1.0 Released! In-Reply-To: References: <35e31714-363b-7712-ebb0-d1e18980a918@gmx.net> Message-ID: cppcheck found some real bugs (report attached) and you should realy use adress-sanitizer (just an compile flag for gcc or clang) - everything it hits is a bug (not like valgrinds could-be-bug warnings) - the thread-sanitizer is just awesom Am 06.06.2016 um 12:31 schrieb Frediano Ziglio: > 2016-05-18 22:12 GMT+01:00 Dennis Luehring : > > http://cppcheck.sourceforge.net/ found serveral small/big flaws (small > > memory leaks, out of bounds accessess etc.) > > > > are using address- and thread-sanitzer for testing? - great tools to find > > any memory access bugs > > > > Valgrind, Coverity (https://scan.coverity.com/projects/freetds2, now a > bit higher as is using master), address sanitizer for my tests. Looks > like numeric code is so complicated no tools is able to understand > there are no overflows :-) > > Frediano > > > > > Am 18.05.2016 um 22:41 schrieb Frediano Ziglio: > >> > >> Hi, > >> finally ready. Changes (from NEWS file) > >> > >> > >> User visible (not in a particular order): > >> - Removed "8.0" from protocol version string accepted. Please > >> update configuration files; > >> - Default protocol version is now auto. This could slow down > >> connection but make user experience less painful; > >> - Sybase encrypted login. Set encryption to get it; > >> - Support protocol version 7.4; > >> - Add intent support to specify we don't want to change data; > >> - Allow to attach database file during the login (MS SQL Server); > >> - Support for Sybase time/date/bigdate/bigdatetime; > >> - Pool is working again; > >> - ODBC BCP (not complete); > >> - Improved dbconvert and dbconvert_ps (more compatible); > >> - Fixed dbspid; > >> - Improved ODBC type information; > >> - Better certificate verification; > >> - AppVeyor is used for every build; > >> - Try all IPs from DNS. This allows SQL Cluster connection > >> to secondary servers. > >> > >> Implementation: > >> - Removed Nmake support; > >> - Type conversions simplified; > >> - Better type handle code. > >> > >> > >> Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds -------------- next part -------------- [misc\cmake_checks.c:8]: (error) No pair for character ("). Can't process file. File is either invalid or unicode, which is currently not supported. [misc\cmake_checks.c:10]: (error) va_list 'va' used before va_start() was called. [misc\cmake_checks.c:16]: (error) va_list 'va' used before va_start() was called. [misc\cmake_checks.c:20]: (error) va_list 'va' used before va_start() was called. [misc\cmake_checks.c:18]: (error) va_list 'va' used before va_start() was called. [src\apps\datacopy.c:794]: (error) Memory leak: srcdata [src\ctlib\cs.c:78]: (warning) %u in format string (no. 1) requires 'unsigned int' but the argument type is 'int'. [src\ctlib\ct.c:3273] -> [src\ctlib\ct.c:3278]: (warning) Either the condition 'cmd==0' is redundant or there is possible null pointer dereference: cmd. [src\ctlib\unittests\common.c:295]: (error) Buffer is accessed out of bounds. [src\ctlib\unittests\ct_dynamic.c:55]: (warning) vfprintf format string requires 0 parameters but 1 is given. [src\ctlib\unittests\rpc_ct_param.c:357]: (error) Memory leak: coldata [src\ctlib\unittests\rpc_ct_setparam.c:402]: (error) Memory leak: coldata [src\dblib\dblib.c:1592]: (warning) %u in format string (no. 1) requires 'unsigned int' but the argument type is 'int'. [src\dblib\dblib.c:1622]: (warning) %u in format string (no. 1) requires 'unsigned int' but the argument type is 'int'. [src\dblib\dblib.c:1647]: (warning) %u in format string (no. 1) requires 'unsigned int' but the argument type is 'int'. [src\dblib\buffering.h:261]: (warning) Assert statement modifies 'ii'. [src\dblib\unittests\done_handling.c:44]: (warning) %u in format string (no. 1) requires 'unsigned int' but the argument type is 'int'. [src\dblib\unittests\done_handling.c:58]: (warning) %u in format string (no. 1) requires 'unsigned int' but the argument type is 'int'. [src\dblib\unittests\t0013.c:245]: (error) Common realloc mistake: 'rblob' nulled but not freed upon failure [src\dblib\unittests\t0013.c:118]: (error) Memory leak: blob [src\dblib\unittests\t0014.c:212]: (error) Common realloc mistake: 'rblob' nulled but not freed upon failure [src\dblib\unittests\t0016.c:68]: (warning) %d in format string (no. 2) requires 'int' but the argument type is 'unsigned int'. [src\odbc\connectparams.c:833]: (warning) Assignment of function parameter has no effect outside the function. Did you forget dereferencing it? [src\odbc\odbc.c:1729]: (error) Dereferencing 'stmt' after it is deallocated / released [src\odbc\odbc.c:1730]: (error) Dereferencing 'stmt' after it is deallocated / released [src\odbc\odbc.c:7352]: (error) va_list 'marker' used before va_start() was called. [src\odbc\odbc_util.c:1077]: (error) syntax error [src\odbc\unittests\binary_test.c:146]: (warning) %d in format string (no. 2) requires 'int' but the argument type is 'unsigned int'. [src\odbc\unittests\blob1.c:97]: (warning) %d in format string (no. 1) requires 'int' but the argument type is 'unsigned int'. [src\odbc\unittests\blob1.c:141]: (warning) %d in format string (no. 1) requires 'int' but the argument type is 'unsigned int'. [src\odbc\unittests\blob1.c:316]: (warning) %d in format string (no. 2) requires 'int' but the argument type is 'unsigned int'. [src\odbc\unittests\blob1.c:320]: (warning) %d in format string (no. 2) requires 'int' but the argument type is 'unsigned int'. [src\odbc\unittests\blob1.c:324]: (warning) %d in format string (no. 2) requires 'int' but the argument type is 'unsigned int'. [src\odbc\unittests\testodbc.c:403]: (warning) %d in format string (no. 1) requires 'int' but the argument type is 'unsigned int'. [src\odbc\unittests\testodbc.c:417]: (warning) %d in format string (no. 1) requires 'int' but the argument type is 'unsigned int'. [src\odbc\unittests\testodbc.c:419]: (warning) %d in format string (no. 1) requires 'int' but the argument type is 'unsigned int'. [src\odbc\unittests\testodbc.c:419]: (warning) %d in format string (no. 2) requires 'int' but the argument type is 'unsigned int'. [src\replacements\vasprintf.c:131]: (error) Memory leak: buf [src\replacements\strlcat.c:40] -> [src\replacements\unittests\strings.c:73]: (error) Modifying string literal "xyz" directly or indirectly is undefined behaviour. [src\server\query.c:51]: (error) Common realloc mistake: 'query' nulled but not freed upon failure [src\server\query.c:109]: (error) Common realloc mistake: 'query' nulled but not freed upon failure [src\server\query.c:126]: (error) Common realloc mistake: 'query' nulled but not freed upon failure [src\server\query.c:172]: (error) Common realloc mistake: 'query' nulled but not freed upon failure [src\tds\bulk.c:510]: (error) syntax error [src\tds\convert.c:1078]: (warning) %lu in format string (no. 2) requires 'unsigned long' but the argument type is 'signed long'. [src\tds\numeric.c:182] -> [src\tds\numeric.c:178]: (warning) Either the condition '!n' is redundant or there is division by zero at line 178. [src\tds\numeric.c:182] -> [src\tds\numeric.c:180]: (warning) Either the condition '!n' is redundant or there is division by zero at line 180. [src\tds\sec_negotiate_gnutls.h:318]: (warning) Possible null pointer dereference: nonce [src\tds\sec_negotiate_openssl.h:65]: (warning) Possible null pointer dereference: nonce [src\tds\tdsstring.c:88]: (error) Memory leak: p [src\tds\tdsstring.c:170]: (error) Memory leak: p [src\tds\token.c:1943]: (warning) Obsolete function 'alloca' called. In C99 and later it is recommended to use a variable length array instead. [src\tds\token.c:2444]: (error) Common realloc mistake: 's' nulled but not freed upon failure [src\tds\unittests\charconv.c:315] -> [src\tds\unittests\charconv.c:322]: (warning) Either the condition '!ctx' is redundant or there is possible null pointer dereference: ctx. [src\tds\unittests\t0004.c:57]: (error) Memory leak: long_query [vms\vmsarg_parse.c:533]: (error) Buffer is accessed out of bounds: month_2 [vms\vmsarg_parse.c:677]: (error) Array 'quote_string[1]' accessed at index 1, which is out of bounds. From freetds at ryandesign.com Mon Jun 6 07:25:39 2016 From: freetds at ryandesign.com (Ryan Schmidt) Date: Mon, 6 Jun 2016 06:25:39 -0500 Subject: [freetds] OSX distribution In-Reply-To: References: Message-ID: On Jun 6, 2016, at 5:06 AM, Frediano Ziglio wrote: > 2016-06-05 20:17 GMT+01:00 Igor Korot : >> Hi, ALL, >> Is there a dmg file to download for the release? >> >> Thank you. > > There is actually not any official Mac OS X release package. I'm the maintainer of freetds in the MacPorts package management system, and unfortunately, I've found that freetds 1.00 does not compile on OS X. (0.95.x versions did.) The error is: In file included from odbc.c:51: ../../include/odbcss.h:300:8: error: unknown type name 'BYTE' const BYTE * colptr; ^ ../../include/odbcss.h:305:29: error: unknown type name 'BYTE' bcp_colptr(HDBC hdbc, const BYTE * colptr, int table_column) ^ ../../include/odbcss.h:343:8: error: unknown type name 'BYTE' const BYTE * varaddr; ^ ../../include/odbcss.h:346:8: error: unknown type name 'BYTE' const BYTE * terminator; ^ ../../include/odbcss.h:353:27: error: unknown type name 'BYTE' bcp_bind(HDBC hdbc, const BYTE * varaddr, int prefixlen, int varlen, ^ ../../include/odbcss.h:354:8: error: unknown type name 'BYTE' const BYTE * terminator, int termlen, int vartype, int table_column) ^ From ikorot01 at gmail.com Tue Jun 7 23:21:56 2016 From: ikorot01 at gmail.com (Igor Korot) Date: Tue, 7 Jun 2016 23:21:56 -0400 Subject: [freetds] Remote connection Message-ID: Hi, list, This is my first post here with the question and I'm sure it is a stupid question. But unfortunately I have absolutely 0 experience with DB Administration. I installed SQL Server 2012 Express on my Windows 8.1 laptop, and I am able to connect to it from the localhost using ODBC connection from Server Management Studio. Now I'm trying to get connection from the Linux machine with freeTDS. I currently have 0.91 installed on my Linux box (Gentoo) which is latest. I can successfully ping both ways by IP address. However when I try to run "busybox telnet 192.168.1.4 1433" the machine just sits there. There is no FW running on the Windows box at the moment for the testing purposes. Since ping works and I can access the web I presume that the network is set up properly. So now my question is: is there an option in MS SQL to tell it to accept remote connections? Thank you for any pointers. From mnlists at tippingstructural.com Mon Jun 6 15:24:13 2016 From: mnlists at tippingstructural.com (Mark Nienberg) Date: Mon, 6 Jun 2016 12:24:13 -0700 Subject: [freetds] Minimum versions for MS Azure SQL Message-ID: I have been connecting to a local MS SQL database via PHP-pdo with FreeTDS for some time using CentOS 6. In this case the PHP is 5.3.3 and the FreeTDS is 0.91 from the EPEL repository. Now I need to make a similar connection to a MS SQL database hosted on the Microsoft Azure cloud. I have not been able to do so with the above versions. I also tested on a CentOS 7 machine, which has PHP 5.4.16 and FreeTDS 0.95. Again I did not succeed. I suppose the issue is related to this PHP - FreeTDS interaction: https://bugs.php.net/bug.php?id=64338 which seems to indicate a fix in PHP version 5.5. So then I upgraded the PHP on a test CentOS 6 machine to 5.6 using the Remi repository, but that didn't work either, so the problem may be the older FreeTDS on that machine. Does anyone know the minimum versions of PHP and FreeTDS that will connect to Azure? Thanks, Mark From peter.van.dijk at powerdns.com Tue Jun 7 08:02:23 2016 From: peter.van.dijk at powerdns.com (Peter van Dijk) Date: Tue, 07 Jun 2016 14:02:23 +0200 Subject: [freetds] OSX distribution In-Reply-To: References: Message-ID: <4512ECAF-C102-4042-9EE5-B9FA78387B6C@powerdns.com> Hello Igor, On 5 Jun 2016, at 21:17, Igor Korot wrote: > Hi, ALL, > Is there a dmg file to download for the release? If you install Homebrew (http://brew.sh/), FreeTDS is one `brew install freetds` away! Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ From freddy77 at gmail.com Fri Jun 10 06:40:20 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Fri, 10 Jun 2016 11:40:20 +0100 Subject: [freetds] OSX distribution In-Reply-To: References: Message-ID: 2016-06-06 12:25 GMT+01:00 Ryan Schmidt : > > On Jun 6, 2016, at 5:06 AM, Frediano Ziglio wrote: > >> 2016-06-05 20:17 GMT+01:00 Igor Korot : >>> Hi, ALL, >>> Is there a dmg file to download for the release? >>> >>> Thank you. >> >> There is actually not any official Mac OS X release package. > > I'm the maintainer of freetds in the MacPorts package management system, and unfortunately, I've found that freetds 1.00 does not compile on OS X. (0.95.x versions did.) The error is: > > > In file included from odbc.c:51: > ../../include/odbcss.h:300:8: error: unknown type name 'BYTE' > const BYTE * colptr; > ^ > ../../include/odbcss.h:305:29: error: unknown type name 'BYTE' > bcp_colptr(HDBC hdbc, const BYTE * colptr, int table_column) > ^ > ../../include/odbcss.h:343:8: error: unknown type name 'BYTE' > const BYTE * varaddr; > ^ > ../../include/odbcss.h:346:8: error: unknown type name 'BYTE' > const BYTE * terminator; > ^ > ../../include/odbcss.h:353:27: error: unknown type name 'BYTE' > bcp_bind(HDBC hdbc, const BYTE * varaddr, int prefixlen, int varlen, > ^ > ../../include/odbcss.h:354:8: error: unknown type name 'BYTE' > const BYTE * terminator, int termlen, int vartype, int table_column) > ^ I don't think will be hard to fix a -DBYTE="unsigned char" on CPPFLAGS should be a workaround. Or replace BYTE with "unsigned char" in odbcss.h (I think I'll manage this way). Could you confirm that last way works (I doubt it won't) ? Frediano From freddy77 at gmail.com Fri Jun 10 06:59:50 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Fri, 10 Jun 2016 11:59:50 +0100 Subject: [freetds] OSX distribution In-Reply-To: References: Message-ID: 2016-06-06 12:25 GMT+01:00 Ryan Schmidt : > > On Jun 6, 2016, at 5:06 AM, Frediano Ziglio wrote: > >> 2016-06-05 20:17 GMT+01:00 Igor Korot : >>> Hi, ALL, >>> Is there a dmg file to download for the release? >>> >>> Thank you. >> >> There is actually not any official Mac OS X release package. > > I'm the maintainer of freetds in the MacPorts package management system, and unfortunately, I've found that freetds 1.00 does not compile on OS X. (0.95.x versions did.) The error is: > > > In file included from odbc.c:51: > ../../include/odbcss.h:300:8: error: unknown type name 'BYTE' > const BYTE * colptr; > ^ > ../../include/odbcss.h:305:29: error: unknown type name 'BYTE' > bcp_colptr(HDBC hdbc, const BYTE * colptr, int table_column) > ^ > ../../include/odbcss.h:343:8: error: unknown type name 'BYTE' > const BYTE * varaddr; > ^ > ../../include/odbcss.h:346:8: error: unknown type name 'BYTE' > const BYTE * terminator; > ^ > ../../include/odbcss.h:353:27: error: unknown type name 'BYTE' > bcp_bind(HDBC hdbc, const BYTE * varaddr, int prefixlen, int varlen, > ^ > ../../include/odbcss.h:354:8: error: unknown type name 'BYTE' > const BYTE * terminator, int termlen, int vartype, int table_column) > ^ Could you try ftp://ftp.freetds.org/pub/freetds/stable/freetds-1.00.1.tar.bz2 ? Frediano From no-reply at appveyor.com Fri Jun 10 07:45:34 2016 From: no-reply at appveyor.com (AppVeyor) Date: Fri, 10 Jun 2016 11:45:34 +0000 Subject: [freetds] Build completed: freetds 617 Message-ID: <20160610114532.114506.63921.356C431F@appveyor.com> From joshua.h.lang at gmail.com Thu Jun 9 12:41:37 2016 From: joshua.h.lang at gmail.com (Joshua Lang) Date: Thu, 9 Jun 2016 09:41:37 -0700 Subject: [freetds] Remote connection In-Reply-To: References: Message-ID: Likely you'll need to configure SQL Server to accept connections over TCP/IP. See http://stackoverflow.com/questions/9138172/enable-tcp-ip-remote-connections-to-sql-server-express-already-installed-databas On Tue, Jun 7, 2016 at 8:21 PM, Igor Korot wrote: > Hi, list, > This is my first post here with the question and I'm sure it is a > stupid question. > But unfortunately I have absolutely 0 experience with DB Administration. > > I installed SQL Server 2012 Express on my Windows 8.1 laptop, and I am > able to > connect to it from the localhost using ODBC connection from Server > Management > Studio. > > Now I'm trying to get connection from the Linux machine with freeTDS. > I currently have 0.91 installed on my Linux box (Gentoo) which is latest. > I can successfully ping both ways by IP address. However when I try to > run "busybox telnet 192.168.1.4 1433" the machine just sits there. > There is no FW running on the Windows box at the moment for the testing > purposes. > > Since ping works and I can access the web I presume that the network is set > up properly. > > So now my question is: is there an option in MS SQL to tell it to accept > remote > connections? > > Thank you for any pointers. > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > From ikorot01 at gmail.com Thu Jun 9 11:31:11 2016 From: ikorot01 at gmail.com (Igor Korot) Date: Thu, 9 Jun 2016 11:31:11 -0400 Subject: [freetds] OSX distribution In-Reply-To: References: Message-ID: Hi, Ryan, On Mon, Jun 6, 2016 at 7:25 AM, Ryan Schmidt wrote: > > On Jun 6, 2016, at 5:06 AM, Frediano Ziglio wrote: > >> 2016-06-05 20:17 GMT+01:00 Igor Korot : >>> Hi, ALL, >>> Is there a dmg file to download for the release? >>> >>> Thank you. >> >> There is actually not any official Mac OS X release package. > > I'm the maintainer of freetds in the MacPorts package management system, and unfortunately, I've found that freetds 1.00 does not compile on OS X. (0.95.x versions did.) The error is: > > > In file included from odbc.c:51: > ../../include/odbcss.h:300:8: error: unknown type name 'BYTE' > const BYTE * colptr; > ^ > ../../include/odbcss.h:305:29: error: unknown type name 'BYTE' > bcp_colptr(HDBC hdbc, const BYTE * colptr, int table_column) > ^ > ../../include/odbcss.h:343:8: error: unknown type name 'BYTE' > const BYTE * varaddr; > ^ > ../../include/odbcss.h:346:8: error: unknown type name 'BYTE' > const BYTE * terminator; > ^ > ../../include/odbcss.h:353:27: error: unknown type name 'BYTE' > bcp_bind(HDBC hdbc, const BYTE * varaddr, int prefixlen, int varlen, > ^ > ../../include/odbcss.h:354:8: error: unknown type name 'BYTE' > const BYTE * terminator, int termlen, int vartype, int table_column) Which OSX/Xcode version you are trying it on? Thank you. > ^ > > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From ikorot01 at gmail.com Thu Jun 9 11:33:57 2016 From: ikorot01 at gmail.com (Igor Korot) Date: Thu, 9 Jun 2016 11:33:57 -0400 Subject: [freetds] Minimum versions for MS Azure SQL In-Reply-To: References: Message-ID: Hi, Mark, On Mon, Jun 6, 2016 at 3:24 PM, Mark Nienberg wrote: > I have been connecting to a local MS SQL database via PHP-pdo with FreeTDS > for some time using CentOS 6. In this case the PHP is 5.3.3 and the FreeTDS > is 0.91 from the EPEL repository. Now I need to make a similar connection > to a MS SQL database hosted on the Microsoft Azure cloud. I have not been > able to do so with the above versions. > > I also tested on a CentOS 7 machine, which has PHP 5.4.16 and FreeTDS 0.95. > Again I did not succeed. > > I suppose the issue is related to this PHP - FreeTDS interaction: > > https://bugs.php.net/bug.php?id=64338 > > which seems to indicate a fix in PHP version 5.5. > > So then I upgraded the PHP on a test CentOS 6 machine to 5.6 using the Remi > repository, but that didn't work either, so the problem may be the older > FreeTDS on that machine. > > Does anyone know the minimum versions of PHP and FreeTDS that will connect > to Azure? Is SQL Server version the same in both cases? Thank you. > > Thanks, > > Mark > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From freddy77 at gmail.com Fri Jun 10 09:47:06 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Fri, 10 Jun 2016 14:47:06 +0100 Subject: [freetds] Minimum versions for MS Azure SQL In-Reply-To: References: Message-ID: 2016-06-06 20:24 GMT+01:00 Mark Nienberg : > I have been connecting to a local MS SQL database via PHP-pdo with FreeTDS > for some time using CentOS 6. In this case the PHP is 5.3.3 and the FreeTDS > is 0.91 from the EPEL repository. Now I need to make a similar connection > to a MS SQL database hosted on the Microsoft Azure cloud. I have not been > able to do so with the above versions. > > I also tested on a CentOS 7 machine, which has PHP 5.4.16 and FreeTDS 0.95. > Again I did not succeed. > > I suppose the issue is related to this PHP - FreeTDS interaction: > > https://bugs.php.net/bug.php?id=64338 > > which seems to indicate a fix in PHP version 5.5. > > So then I upgraded the PHP on a test CentOS 6 machine to 5.6 using the Remi > repository, but that didn't work either, so the problem may be the older > FreeTDS on that machine. > > Does anyone know the minimum versions of PHP and FreeTDS that will connect > to Azure? > > Thanks, > > Mark Surely 0.95 works. But if I remember you have to enable encrypted login and compile with GnuTLS/OpenSSL support. See encryption on http://www.freetds.org/userguide/freetdsconf.htm and http://www.freetds.org/userguide/odbcconnattr.htm. Frediano From freetds at ryandesign.com Sat Jun 11 02:25:01 2016 From: freetds at ryandesign.com (Ryan Schmidt) Date: Sat, 11 Jun 2016 01:25:01 -0500 Subject: [freetds] OSX distribution In-Reply-To: References: Message-ID: <1BAABA50-DD01-4510-A6FF-4A8E34C6C841@ryandesign.com> On Jun 10, 2016, at 5:59 AM, Frediano Ziglio wrote: > 2016-06-06 12:25 GMT+01:00 Ryan Schmidt wrote: >> >> I'm the maintainer of freetds in the MacPorts package management system, and unfortunately, I've found that freetds 1.00 does not compile on OS X. (0.95.x versions did.) The error is: >> >> >> In file included from odbc.c:51: >> ../../include/odbcss.h:300:8: error: unknown type name 'BYTE' >> const BYTE * colptr; >> ^ >> ../../include/odbcss.h:305:29: error: unknown type name 'BYTE' >> bcp_colptr(HDBC hdbc, const BYTE * colptr, int table_column) >> ^ >> ../../include/odbcss.h:343:8: error: unknown type name 'BYTE' >> const BYTE * varaddr; >> ^ >> ../../include/odbcss.h:346:8: error: unknown type name 'BYTE' >> const BYTE * terminator; >> ^ >> ../../include/odbcss.h:353:27: error: unknown type name 'BYTE' >> bcp_bind(HDBC hdbc, const BYTE * varaddr, int prefixlen, int varlen, >> ^ >> ../../include/odbcss.h:354:8: error: unknown type name 'BYTE' >> const BYTE * terminator, int termlen, int vartype, int table_column) >> ^ > > Could you try ftp://ftp.freetds.org/pub/freetds/stable/freetds-1.00.1.tar.bz2 ? Yes, that works, thanks. I've updated MacPorts freetds to this version. BTW, the ChangeLog and NEWS files don't appear to have been updated in 1.00.1. On Jun 9, 2016, at 10:31 AM, Igor Korot wrote: > Which OSX/Xcode version you are trying it on? OS X El Capitan 10.11.5 and 10.11.6 beta 1, Xcode 7.3.1. From merlereinhart at mac.com Fri Jun 10 10:10:26 2016 From: merlereinhart at mac.com (Merle Reinhart) Date: Fri, 10 Jun 2016 10:10:26 -0400 Subject: [freetds] OSX distribution In-Reply-To: References: Message-ID: Frediano, That tarball fixes the compile issue at least on Mac OS X 10.11.x (El Capitan). Thanks!!! It turns out the problem would only occur when compiling FreeTDS with iodbc. It was fine compile with unixodbc. I finally tracked down 'why' it occurs. In iodbc, the sql.h include calls sqltypes.h which calls iodbcunix.h which has a conditional definition of BYTE: #if defined (OBSOLETE_WINDOWS_TYPES) typedef unsigned char BYTE; #endif In unixodbc, the sql.h include calls sqltypes.h which contains an unconditional definition of BYTE: typedef unsigned char BYTE; So, the compile would fail using iodbc apparently due to OBSOLETE_WINDOWS_TYPES not being defined anywhere, but would work using unixodbc. I was just about to report the exact same issue when I saw Ryan's mail. Again, thank you very much for all the work. Merle > Message: 6 > Date: Fri, 10 Jun 2016 11:59:50 +0100 > From: Frediano Ziglio > To: FreeTDS Development Group > Subject: Re: [freetds] OSX distribution > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > 2016-06-06 12:25 GMT+01:00 Ryan Schmidt : >> >> On Jun 6, 2016, at 5:06 AM, Frediano Ziglio wrote: >> >>> 2016-06-05 20:17 GMT+01:00 Igor Korot : >>>> Hi, ALL, >>>> Is there a dmg file to download for the release? >>>> >>>> Thank you. >>> >>> There is actually not any official Mac OS X release package. >> >> I'm the maintainer of freetds in the MacPorts package management system, and unfortunately, I've found that freetds 1.00 does not compile on OS X. (0.95.x versions did.) The error is: >> >> >> In file included from odbc.c:51: >> ../../include/odbcss.h:300:8: error: unknown type name 'BYTE' >> const BYTE * colptr; >> ^ >> ../../include/odbcss.h:305:29: error: unknown type name 'BYTE' >> bcp_colptr(HDBC hdbc, const BYTE * colptr, int table_column) >> ^ >> ../../include/odbcss.h:343:8: error: unknown type name 'BYTE' >> const BYTE * varaddr; >> ^ >> ../../include/odbcss.h:346:8: error: unknown type name 'BYTE' >> const BYTE * terminator; >> ^ >> ../../include/odbcss.h:353:27: error: unknown type name 'BYTE' >> bcp_bind(HDBC hdbc, const BYTE * varaddr, int prefixlen, int varlen, >> ^ >> ../../include/odbcss.h:354:8: error: unknown type name 'BYTE' >> const BYTE * terminator, int termlen, int vartype, int table_column) >> ^ > > > Could you try ftp://ftp.freetds.org/pub/freetds/stable/freetds-1.00.1.tar.bz2 ? > > Frediano > From freddy77 at gmail.com Sat Jun 11 03:47:22 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Sat, 11 Jun 2016 08:47:22 +0100 Subject: [freetds] OSX distribution In-Reply-To: <1BAABA50-DD01-4510-A6FF-4A8E34C6C841@ryandesign.com> References: <1BAABA50-DD01-4510-A6FF-4A8E34C6C841@ryandesign.com> Message-ID: 2016-06-11 7:25 GMT+01:00 Ryan Schmidt : > > On Jun 10, 2016, at 5:59 AM, Frediano Ziglio wrote: > >> 2016-06-06 12:25 GMT+01:00 Ryan Schmidt wrote: >>> >>> I'm the maintainer of freetds in the MacPorts package management system, and unfortunately, I've found that freetds 1.00 does not compile on OS X. (0.95.x versions did.) The error is: >>> >>> >>> In file included from odbc.c:51: >>> ../../include/odbcss.h:300:8: error: unknown type name 'BYTE' >>> const BYTE * colptr; >>> ^ >>> ../../include/odbcss.h:305:29: error: unknown type name 'BYTE' >>> bcp_colptr(HDBC hdbc, const BYTE * colptr, int table_column) >>> ^ >>> ../../include/odbcss.h:343:8: error: unknown type name 'BYTE' >>> const BYTE * varaddr; >>> ^ >>> ../../include/odbcss.h:346:8: error: unknown type name 'BYTE' >>> const BYTE * terminator; >>> ^ >>> ../../include/odbcss.h:353:27: error: unknown type name 'BYTE' >>> bcp_bind(HDBC hdbc, const BYTE * varaddr, int prefixlen, int varlen, >>> ^ >>> ../../include/odbcss.h:354:8: error: unknown type name 'BYTE' >>> const BYTE * terminator, int termlen, int vartype, int table_column) >>> ^ >> >> Could you try ftp://ftp.freetds.org/pub/freetds/stable/freetds-1.00.1.tar.bz2 ? > > Yes, that works, thanks. I've updated MacPorts freetds to this version. > > BTW, the ChangeLog and NEWS files don't appear to have been updated in 1.00.1. > Yes, it's the way it works, post release updated (which are created automatically) does not create/update NEWS or ChangeLog. Note however the ChangeLog is not distributed and actually is no more updated since 2012 as now changes are in git log. Probably the ChangeLog files should be removed from git too, make no sense and you get them back from history if needed. Would however make sense to have a new ChangeLog in the distribution file containing changes since the release. > > On Jun 9, 2016, at 10:31 AM, Igor Korot wrote: > >> Which OSX/Xcode version you are trying it on? > > OS X El Capitan 10.11.5 and 10.11.6 beta 1, Xcode 7.3.1. > Frediano From freddy77 at gmail.com Sat Jun 11 03:58:21 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Sat, 11 Jun 2016 08:58:21 +0100 Subject: [freetds] OSX distribution In-Reply-To: References: Message-ID: Hi Merle, thanks to test it out. I think now the big concern about Mac OS X is the OpenSSL support removal from Apple. Would be great to have the support for Mac OS X system libraries for TLS support. I have a Mac so I could try however I was not able to compile FreeTDS with iODBC. I also installed iODBC (why is not included by default?) but FreeTDS was not finding the headers/library. Should I add some option? Recently I had a report stating that ODBC on Mac OS X is compiling as module instead of library causing some problems. I don't know if the DM load drivers as module or as library. Actually there is no such difference on other operating systems. What the difference between a module and a library on Mac OS X? Looking at http://stackoverflow.com/questions/2339679/what-are-the-differences-between-so-and-dylib-on-osx looks like module were required for dynamic loading. Nowadays however dynamic libraries work always. I think the best option would be to use modules if DM is used or library otherwise taking attention to link only to DM instead of module. Frediano 2016-06-10 15:10 GMT+01:00 Merle Reinhart : > Frediano, > > That tarball fixes the compile issue at least on Mac OS X 10.11.x (El Capitan). Thanks!!! > > It turns out the problem would only occur when compiling FreeTDS with iodbc. It was fine compile with unixodbc. I finally tracked down 'why' it occurs. > > In iodbc, the sql.h include calls sqltypes.h which calls iodbcunix.h which has a conditional definition of BYTE: > #if defined (OBSOLETE_WINDOWS_TYPES) > typedef unsigned char BYTE; > #endif > > > In unixodbc, the sql.h include calls sqltypes.h which contains an unconditional definition of BYTE: > typedef unsigned char BYTE; > > So, the compile would fail using iodbc apparently due to OBSOLETE_WINDOWS_TYPES not being defined anywhere, but would work using unixodbc. > > I was just about to report the exact same issue when I saw Ryan's mail. > > > Again, thank you very much for all the work. > > Merle > > > >> Message: 6 >> Date: Fri, 10 Jun 2016 11:59:50 +0100 >> From: Frediano Ziglio >> To: FreeTDS Development Group >> Subject: Re: [freetds] OSX distribution >> Message-ID: >> >> Content-Type: text/plain; charset=UTF-8 >> >> 2016-06-06 12:25 GMT+01:00 Ryan Schmidt : >>> >>> On Jun 6, 2016, at 5:06 AM, Frediano Ziglio wrote: >>> >>>> 2016-06-05 20:17 GMT+01:00 Igor Korot : >>>>> Hi, ALL, >>>>> Is there a dmg file to download for the release? >>>>> >>>>> Thank you. >>>> >>>> There is actually not any official Mac OS X release package. >>> >>> I'm the maintainer of freetds in the MacPorts package management system, and unfortunately, I've found that freetds 1.00 does not compile on OS X. (0.95.x versions did.) The error is: >>> >>> >>> In file included from odbc.c:51: >>> ../../include/odbcss.h:300:8: error: unknown type name 'BYTE' >>> const BYTE * colptr; >>> ^ >>> ../../include/odbcss.h:305:29: error: unknown type name 'BYTE' >>> bcp_colptr(HDBC hdbc, const BYTE * colptr, int table_column) >>> ^ >>> ../../include/odbcss.h:343:8: error: unknown type name 'BYTE' >>> const BYTE * varaddr; >>> ^ >>> ../../include/odbcss.h:346:8: error: unknown type name 'BYTE' >>> const BYTE * terminator; >>> ^ >>> ../../include/odbcss.h:353:27: error: unknown type name 'BYTE' >>> bcp_bind(HDBC hdbc, const BYTE * varaddr, int prefixlen, int varlen, >>> ^ >>> ../../include/odbcss.h:354:8: error: unknown type name 'BYTE' >>> const BYTE * terminator, int termlen, int vartype, int table_column) >>> ^ >> >> >> Could you try ftp://ftp.freetds.org/pub/freetds/stable/freetds-1.00.1.tar.bz2 ? >> >> Frediano >> > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From freddy77 at gmail.com Sun Jun 12 10:50:19 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Sun, 12 Jun 2016 15:50:19 +0100 Subject: [freetds] OSX distribution In-Reply-To: References: Message-ID: 2016-06-11 8:58 GMT+01:00 Frediano Ziglio : > Hi Merle, > thanks to test it out. I think now the big concern about Mac OS X is > the OpenSSL support removal from Apple. Would be great to have the > support for Mac OS X system libraries for TLS support. > I have a Mac so I could try however I was not able to compile FreeTDS > with iODBC. I also installed iODBC (why is not included by default?) > but FreeTDS was not finding the headers/library. Should I add some > option? > I tried with the Mac OS X and I would have some feedback... - the iODBC library is contained in the Essential package (libiodbc.dylib); - Essential package contains pkgconfig file (int /usr/lib/pkgconfig) but not pkg-config script; - Xcode does not contain pkg-config either; - Apple removed isql.h and other iODBC include files from Xcode MacOSX 10.8 include directory. Also they removed iodbc-config. Did they decide to deprecate iODBC? - I installed iODBC PKG from iODBC website. The isql.h include try to include a as isql.h is not supported anymore however there is no iODBC directory/link which contains a sql.h so the include fails! Looks like they are trying to make thing much harder for developers :-( Not counting that my PKG database has still Xcode MacOSX 10.8 files but files are not present anymore. > Recently I had a report stating that ODBC on Mac OS X is compiling as > module instead of library causing some problems. I don't know if the > DM load drivers as module or as library. Actually there is no such > difference on other operating systems. What the difference between a > module and a library on Mac OS X? > Looking at http://stackoverflow.com/questions/2339679/what-are-the-differences-between-so-and-dylib-on-osx > looks like module were required for dynamic loading. Nowadays however > dynamic libraries work always. I think the best option would be to use > modules if DM is used or library otherwise taking attention to link > only to DM instead of module. > Frediano > > 2016-06-10 15:10 GMT+01:00 Merle Reinhart : >> Frediano, >> >> That tarball fixes the compile issue at least on Mac OS X 10.11.x (El Capitan). Thanks!!! >> >> It turns out the problem would only occur when compiling FreeTDS with iodbc. It was fine compile with unixodbc. I finally tracked down 'why' it occurs. >> >> In iodbc, the sql.h include calls sqltypes.h which calls iodbcunix.h which has a conditional definition of BYTE: >> #if defined (OBSOLETE_WINDOWS_TYPES) >> typedef unsigned char BYTE; >> #endif >> >> >> In unixodbc, the sql.h include calls sqltypes.h which contains an unconditional definition of BYTE: >> typedef unsigned char BYTE; >> >> So, the compile would fail using iodbc apparently due to OBSOLETE_WINDOWS_TYPES not being defined anywhere, but would work using unixodbc. >> >> I was just about to report the exact same issue when I saw Ryan's mail. >> >> >> Again, thank you very much for all the work. >> >> Merle >> >> >> >>> Message: 6 >>> Date: Fri, 10 Jun 2016 11:59:50 +0100 >>> From: Frediano Ziglio >>> To: FreeTDS Development Group >>> Subject: Re: [freetds] OSX distribution >>> Message-ID: >>> >>> Content-Type: text/plain; charset=UTF-8 >>> >>> 2016-06-06 12:25 GMT+01:00 Ryan Schmidt : >>>> >>>> On Jun 6, 2016, at 5:06 AM, Frediano Ziglio wrote: >>>> >>>>> 2016-06-05 20:17 GMT+01:00 Igor Korot : >>>>>> Hi, ALL, >>>>>> Is there a dmg file to download for the release? >>>>>> >>>>>> Thank you. >>>>> >>>>> There is actually not any official Mac OS X release package. >>>> >>>> I'm the maintainer of freetds in the MacPorts package management system, and unfortunately, I've found that freetds 1.00 does not compile on OS X. (0.95.x versions did.) The error is: >>>> >>>> >>>> In file included from odbc.c:51: >>>> ../../include/odbcss.h:300:8: error: unknown type name 'BYTE' >>>> const BYTE * colptr; >>>> ^ >>>> ../../include/odbcss.h:305:29: error: unknown type name 'BYTE' >>>> bcp_colptr(HDBC hdbc, const BYTE * colptr, int table_column) >>>> ^ >>>> ../../include/odbcss.h:343:8: error: unknown type name 'BYTE' >>>> const BYTE * varaddr; >>>> ^ >>>> ../../include/odbcss.h:346:8: error: unknown type name 'BYTE' >>>> const BYTE * terminator; >>>> ^ >>>> ../../include/odbcss.h:353:27: error: unknown type name 'BYTE' >>>> bcp_bind(HDBC hdbc, const BYTE * varaddr, int prefixlen, int varlen, >>>> ^ >>>> ../../include/odbcss.h:354:8: error: unknown type name 'BYTE' >>>> const BYTE * terminator, int termlen, int vartype, int table_column) >>>> ^ >>> >>> >>> Could you try ftp://ftp.freetds.org/pub/freetds/stable/freetds-1.00.1.tar.bz2 ? >>> From ikorot01 at gmail.com Sun Jun 12 11:29:03 2016 From: ikorot01 at gmail.com (Igor Korot) Date: Sun, 12 Jun 2016 08:29:03 -0700 Subject: [freetds] OSX distribution In-Reply-To: References: Message-ID: Hi, Frediano, On Sun, Jun 12, 2016 at 7:50 AM, Frediano Ziglio wrote: > 2016-06-11 8:58 GMT+01:00 Frediano Ziglio : >> Hi Merle, >> thanks to test it out. I think now the big concern about Mac OS X is >> the OpenSSL support removal from Apple. Would be great to have the >> support for Mac OS X system libraries for TLS support. >> I have a Mac so I could try however I was not able to compile FreeTDS >> with iODBC. I also installed iODBC (why is not included by default?) >> but FreeTDS was not finding the headers/library. Should I add some >> option? >> > > I tried with the Mac OS X and I would have some feedback... > - the iODBC library is contained in the Essential package (libiodbc.dylib); > - Essential package contains pkgconfig file (int /usr/lib/pkgconfig) > but not pkg-config script; > - Xcode does not contain pkg-config either; > - Apple removed isql.h and other iODBC include files from Xcode MacOSX > 10.8 include directory. Also they removed iodbc-config. Did they > decide to deprecate iODBC? No, the package is contained in iODBC framework. > - I installed iODBC PKG from iODBC website. The isql.h include try to > include a as isql.h is not supported anymore however > there is no iODBC directory/link which contains a sql.h so the include > fails! You need to link with /Library/Frameworks/iODBC.Framework. The iODBC/sql.h are symbolic links to inside the iODBC Framework. Thank you. > > Looks like they are trying to make thing much harder for developers :-( > > Not counting that my PKG database has still Xcode MacOSX 10.8 files > but files are not present anymore. > >> Recently I had a report stating that ODBC on Mac OS X is compiling as >> module instead of library causing some problems. I don't know if the >> DM load drivers as module or as library. Actually there is no such >> difference on other operating systems. What the difference between a >> module and a library on Mac OS X? >> Looking at http://stackoverflow.com/questions/2339679/what-are-the-differences-between-so-and-dylib-on-osx >> looks like module were required for dynamic loading. Nowadays however >> dynamic libraries work always. I think the best option would be to use >> modules if DM is used or library otherwise taking attention to link >> only to DM instead of module. >> > > Frediano > >> >> 2016-06-10 15:10 GMT+01:00 Merle Reinhart : >>> Frediano, >>> >>> That tarball fixes the compile issue at least on Mac OS X 10.11.x (El Capitan). Thanks!!! >>> >>> It turns out the problem would only occur when compiling FreeTDS with iodbc. It was fine compile with unixodbc. I finally tracked down 'why' it occurs. >>> >>> In iodbc, the sql.h include calls sqltypes.h which calls iodbcunix.h which has a conditional definition of BYTE: >>> #if defined (OBSOLETE_WINDOWS_TYPES) >>> typedef unsigned char BYTE; >>> #endif >>> >>> >>> In unixodbc, the sql.h include calls sqltypes.h which contains an unconditional definition of BYTE: >>> typedef unsigned char BYTE; >>> >>> So, the compile would fail using iodbc apparently due to OBSOLETE_WINDOWS_TYPES not being defined anywhere, but would work using unixodbc. >>> >>> I was just about to report the exact same issue when I saw Ryan's mail. >>> >>> >>> Again, thank you very much for all the work. >>> >>> Merle >>> >>> >>> >>>> Message: 6 >>>> Date: Fri, 10 Jun 2016 11:59:50 +0100 >>>> From: Frediano Ziglio >>>> To: FreeTDS Development Group >>>> Subject: Re: [freetds] OSX distribution >>>> Message-ID: >>>> >>>> Content-Type: text/plain; charset=UTF-8 >>>> >>>> 2016-06-06 12:25 GMT+01:00 Ryan Schmidt : >>>>> >>>>> On Jun 6, 2016, at 5:06 AM, Frediano Ziglio wrote: >>>>> >>>>>> 2016-06-05 20:17 GMT+01:00 Igor Korot : >>>>>>> Hi, ALL, >>>>>>> Is there a dmg file to download for the release? >>>>>>> >>>>>>> Thank you. >>>>>> >>>>>> There is actually not any official Mac OS X release package. >>>>> >>>>> I'm the maintainer of freetds in the MacPorts package management system, and unfortunately, I've found that freetds 1.00 does not compile on OS X. (0.95.x versions did.) The error is: >>>>> >>>>> >>>>> In file included from odbc.c:51: >>>>> ../../include/odbcss.h:300:8: error: unknown type name 'BYTE' >>>>> const BYTE * colptr; >>>>> ^ >>>>> ../../include/odbcss.h:305:29: error: unknown type name 'BYTE' >>>>> bcp_colptr(HDBC hdbc, const BYTE * colptr, int table_column) >>>>> ^ >>>>> ../../include/odbcss.h:343:8: error: unknown type name 'BYTE' >>>>> const BYTE * varaddr; >>>>> ^ >>>>> ../../include/odbcss.h:346:8: error: unknown type name 'BYTE' >>>>> const BYTE * terminator; >>>>> ^ >>>>> ../../include/odbcss.h:353:27: error: unknown type name 'BYTE' >>>>> bcp_bind(HDBC hdbc, const BYTE * varaddr, int prefixlen, int varlen, >>>>> ^ >>>>> ../../include/odbcss.h:354:8: error: unknown type name 'BYTE' >>>>> const BYTE * terminator, int termlen, int vartype, int table_column) >>>>> ^ >>>> >>>> >>>> Could you try ftp://ftp.freetds.org/pub/freetds/stable/freetds-1.00.1.tar.bz2 ? >>>> > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From merlereinhart at mac.com Sun Jun 12 12:27:55 2016 From: merlereinhart at mac.com (Merle Reinhart) Date: Sun, 12 Jun 2016 12:27:55 -0400 Subject: [freetds] OSX distribution In-Reply-To: References: Message-ID: Frediano, Yes, Apple has deprecated a number of open source packages including iODBC. They are still including the libraries to allow older apps to continue running, but have removed the include files so that new apps can?t use the built-in libraries. They took that stance several versions of OS X ago. Since then, I?ve been building iODBC myself (I use the source tarball from iodbc.org) and linking FreeTDS successfully against that. My configure line for iODBC is: sh bootstrap.sh ./configure --prefix=/usr/local/iodbc --with-iodbc-inidir=/Library/ODBC --disable-gui CFLAGS="-arch i386 -arch x86_64" I also build against the Fink libraries (should work with MacPorts and HomeBrew as well) which pulls in a newer readline, a newer libiconv, recent openssl, etc. The configure line I use for FreeTDS is: ./configure --with-iodbc=/usr/local/iodbc --enable-sybase-compat --prefix=/usr/local/freetds --with-libiconv-prefix=/sw --disable-debug --disable-server --disable-pool --enable-krb5 CC=clang This works well for use where I work. We use sqsh for sql access, odbc access via python/pyodbc, tcl tdbc and via lisp. The databases we access are Sybase and MS SQL with Mac OS X, Linux and Solaris. I?m not sure what to suggest for a FreeTDS build on Mac OS X without any additional external packages as I?m not sure how many features would have to be left behind in that situation (or if would work at all given what Apple as deprecated and will likely completely remove in a future OS release). Merle > On Jun 12, 2016, at 10:50 AM, Frediano Ziglio wrote: > > 2016-06-11 8:58 GMT+01:00 Frediano Ziglio : >> Hi Merle, >> thanks to test it out. I think now the big concern about Mac OS X is >> the OpenSSL support removal from Apple. Would be great to have the >> support for Mac OS X system libraries for TLS support. >> I have a Mac so I could try however I was not able to compile FreeTDS >> with iODBC. I also installed iODBC (why is not included by default?) >> but FreeTDS was not finding the headers/library. Should I add some >> option? >> > > I tried with the Mac OS X and I would have some feedback... > - the iODBC library is contained in the Essential package (libiodbc.dylib); > - Essential package contains pkgconfig file (int /usr/lib/pkgconfig) > but not pkg-config script; > - Xcode does not contain pkg-config either; > - Apple removed isql.h and other iODBC include files from Xcode MacOSX > 10.8 include directory. Also they removed iodbc-config. Did they > decide to deprecate iODBC? > - I installed iODBC PKG from iODBC website. The isql.h include try to > include a as isql.h is not supported anymore however > there is no iODBC directory/link which contains a sql.h so the include > fails! > > Looks like they are trying to make thing much harder for developers :-( > > Not counting that my PKG database has still Xcode MacOSX 10.8 files > but files are not present anymore. > >> Recently I had a report stating that ODBC on Mac OS X is compiling as >> module instead of library causing some problems. I don't know if the >> DM load drivers as module or as library. Actually there is no such >> difference on other operating systems. What the difference between a >> module and a library on Mac OS X? >> Looking at http://stackoverflow.com/questions/2339679/what-are-the-differences-between-so-and-dylib-on-osx >> looks like module were required for dynamic loading. Nowadays however >> dynamic libraries work always. I think the best option would be to use >> modules if DM is used or library otherwise taking attention to link >> only to DM instead of module. >> > > Frediano > >> >> 2016-06-10 15:10 GMT+01:00 Merle Reinhart : >>> Frediano, >>> >>> That tarball fixes the compile issue at least on Mac OS X 10.11.x (El Capitan). Thanks!!! >>> >>> It turns out the problem would only occur when compiling FreeTDS with iodbc. It was fine compile with unixodbc. I finally tracked down 'why' it occurs. >>> >>> In iodbc, the sql.h include calls sqltypes.h which calls iodbcunix.h which has a conditional definition of BYTE: >>> #if defined (OBSOLETE_WINDOWS_TYPES) >>> typedef unsigned char BYTE; >>> #endif >>> >>> >>> In unixodbc, the sql.h include calls sqltypes.h which contains an unconditional definition of BYTE: >>> typedef unsigned char BYTE; >>> >>> So, the compile would fail using iodbc apparently due to OBSOLETE_WINDOWS_TYPES not being defined anywhere, but would work using unixodbc. >>> >>> I was just about to report the exact same issue when I saw Ryan's mail. >>> >>> >>> Again, thank you very much for all the work. >>> >>> Merle >>> >>> >>> >>>> Message: 6 >>>> Date: Fri, 10 Jun 2016 11:59:50 +0100 >>>> From: Frediano Ziglio >>>> To: FreeTDS Development Group >>>> Subject: Re: [freetds] OSX distribution >>>> Message-ID: >>>> >>>> Content-Type: text/plain; charset=UTF-8 >>>> >>>> 2016-06-06 12:25 GMT+01:00 Ryan Schmidt : >>>>> >>>>> On Jun 6, 2016, at 5:06 AM, Frediano Ziglio wrote: >>>>> >>>>>> 2016-06-05 20:17 GMT+01:00 Igor Korot : >>>>>>> Hi, ALL, >>>>>>> Is there a dmg file to download for the release? >>>>>>> >>>>>>> Thank you. >>>>>> >>>>>> There is actually not any official Mac OS X release package. >>>>> >>>>> I'm the maintainer of freetds in the MacPorts package management system, and unfortunately, I've found that freetds 1.00 does not compile on OS X. (0.95.x versions did.) The error is: >>>>> >>>>> >>>>> In file included from odbc.c:51: >>>>> ../../include/odbcss.h:300:8: error: unknown type name 'BYTE' >>>>> const BYTE * colptr; >>>>> ^ >>>>> ../../include/odbcss.h:305:29: error: unknown type name 'BYTE' >>>>> bcp_colptr(HDBC hdbc, const BYTE * colptr, int table_column) >>>>> ^ >>>>> ../../include/odbcss.h:343:8: error: unknown type name 'BYTE' >>>>> const BYTE * varaddr; >>>>> ^ >>>>> ../../include/odbcss.h:346:8: error: unknown type name 'BYTE' >>>>> const BYTE * terminator; >>>>> ^ >>>>> ../../include/odbcss.h:353:27: error: unknown type name 'BYTE' >>>>> bcp_bind(HDBC hdbc, const BYTE * varaddr, int prefixlen, int varlen, >>>>> ^ >>>>> ../../include/odbcss.h:354:8: error: unknown type name 'BYTE' >>>>> const BYTE * terminator, int termlen, int vartype, int table_column) >>>>> ^ >>>> >>>> >>>> Could you try ftp://ftp.freetds.org/pub/freetds/stable/freetds-1.00.1.tar.bz2 ? >>>> > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From nem at emptec.com Sun Jun 12 13:59:10 2016 From: nem at emptec.com (Nem W Schlecht) Date: Sun, 12 Jun 2016 12:59:10 -0500 Subject: [freetds] Old dblib.c bug still there Message-ID: Hello all, First off, I just want to thank all of the developers in this community for continuing work on such a useful and excellent application. I cannot thank and appreciate you all enough! Thank you, Thank You, THANK YOU!! I recently grabbed the last stable release and came across an issue that seems to constantly be plaguing me and has been around for a long time. I had reported this back in July of 2014, but the proposed solution (stripping all but one space) would still screw up some of my stored procedures (that have lots of spaces in strings for formatting purposes). My original post and reply: http://lists.ibiblio.org/pipermail/freetds/2014q3/028964.html http://lists.ibiblio.org/pipermail/freetds/2014q3/028966.html The issue is with lines 7311-7314 in dblib.c: 7311 case NTBSTRINGBIND: /* strip trailing blanks, null term */ 7312 while (srclen && src[srclen - 1] == ' ') { 7313 --srclen; 7314 } Looks like something good to do, right? Get rid of any blanks that we don't need. However, this keeps messing up my output when I use "defncopy" to dump out some of my stored procedures. If it just so happens that you have a large stored procedure or large string in that stored procedure *and* there are one or more spaces exactly at a multiple of byte 4000, dblib.c will strip out the spaces, causing either data corruption or an SQL syntax error in the stored procedure. I'm attaching an example to reproduce the issue. Load in 'dbo.big_proc-load.sql' and then immediately run 'defncopy' to dump it back out. Each digit should have 40 spaces between it, but on line 96, it only contains 8 spaces. dblib grabbed the first 4000 bytes, saw there there were spaces, and truncated it back to the last non-space character. I've actually had this happen (just by pure chance) in actual code as well, where a line like this: SELECT some_field_name AS some_field_alias has been turned into: SELECT some_field_nameAS some_field_alias Thus causing an error the next time the stored procedure is run, since the field name is now incorrect. I've modified my copy of dblib.c and commented out lines 7312-7314 (as I did so 2 years ago and I've had to negative effects), but would like to hear thoughts/opinions of the developers and would really like this issue fixed. Again, thank you all so much for all of your hard work on FreeTDS! -- Nem W Schlecht "Perl did the magic. I just waved the wand." -------------- next part -------------- A non-text attachment was scrubbed... Name: dbo.big_proc-load.sql Type: text/x-sql Size: 4073 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dbo.big_proc-defncopy-bad.sql Type: text/x-sql Size: 4045 bytes Desc: not available URL: From freddy77 at gmail.com Tue Jun 14 07:58:14 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Tue, 14 Jun 2016 12:58:14 +0100 Subject: [freetds] Old dblib.c bug still there In-Reply-To: References: Message-ID: 2016-06-12 18:59 GMT+01:00 Nem W Schlecht : > Hello all, > > First off, I just want to thank all of the developers in this community for > continuing work on such a useful and excellent application. I cannot thank > and appreciate you all enough! Thank you, Thank You, THANK YOU!! > > > I recently grabbed the last stable release and came across an issue that > seems to constantly be plaguing me and has been around for a long time. I > had reported this back in July of 2014, but the proposed solution > (stripping all but one space) would still screw up some of my stored > procedures (that have lots of spaces in strings for formatting purposes). > > My original post and reply: > http://lists.ibiblio.org/pipermail/freetds/2014q3/028964.html > http://lists.ibiblio.org/pipermail/freetds/2014q3/028966.html > > The issue is with lines 7311-7314 in dblib.c: > > 7311 case NTBSTRINGBIND: /* strip trailing blanks, null > term */ > 7312 while (srclen && src[srclen - 1] == ' ') { > 7313 --srclen; > 7314 } > > Looks like something good to do, right? Get rid of any blanks that we > don't need. However, this keeps messing up my output when I use "defncopy" > to dump out some of my stored procedures. > Well... this is the expected behaviour of NTBSTRINGBIND. The problem is not in dblib.c but in defncopy that expects a different behaviour. > If it just so happens that you have a large stored procedure or large > string in that stored procedure *and* there are one or more spaces exactly > at a multiple of byte 4000, dblib.c will strip out the spaces, causing > either data corruption or an SQL syntax error in the stored procedure. > > I'm attaching an example to reproduce the issue. > > Load in 'dbo.big_proc-load.sql' and then immediately run 'defncopy' to dump > it back out. Each digit should have 40 spaces between it, but on line 96, > it only contains 8 spaces. dblib grabbed the first 4000 bytes, saw there > there were spaces, and truncated it back to the last non-space character. > > I've actually had this happen (just by pure chance) in actual code as well, > where a line like this: > > SELECT some_field_name AS some_field_alias > > has been turned into: > > SELECT some_field_nameAS some_field_alias > > Thus causing an error the next time the stored procedure is run, since the > field name is now incorrect. > > I've modified my copy of dblib.c and commented out lines 7312-7314 (as I > did so 2 years ago and I've had to negative effects), but would like to > hear thoughts/opinions of the developers and would really like this issue > fixed. > > Again, thank you all so much for all of your hard work on FreeTDS! > Seems that all bindings with varlen != 0 (as you don't want an overflow too): - does blank padding; - are limited; - strip blanks. All stuff you don't want for your usage. The possible solution is to not use binding but dbdata and family. Frediano From bill.d.thompson at baml.com Tue Jun 14 08:43:20 2016 From: bill.d.thompson at baml.com (Thompson, William) Date: Tue, 14 Jun 2016 12:43:20 +0000 Subject: [freetds] Old dblib.c bug still there In-Reply-To: References: Message-ID: <4A990489BF566041A7724DC577BB060417581B3A@smtp_mail.bankofamerica.com> I Agree with Freddy - if you want to make a change to test it out, I'd make the change to defncopy.c Try changing that NTBSTRINGBIND to plain old STRINGBIND, and see how that affects the behaviour. It looks to me like it should stop the trailing blanks from being stripped off -----Original Message----- From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of Frediano Ziglio Sent: 14 June 2016 12:58 To: FreeTDS Development Group Subject: Re: [freetds] Old dblib.c bug still there 2016-06-12 18:59 GMT+01:00 Nem W Schlecht : > Hello all, > > First off, I just want to thank all of the developers in this > community for continuing work on such a useful and excellent > application. I cannot thank and appreciate you all enough! Thank you, Thank You, THANK YOU!! > > > I recently grabbed the last stable release and came across an issue > that seems to constantly be plaguing me and has been around for a long > time. I had reported this back in July of 2014, but the proposed > solution (stripping all but one space) would still screw up some of my > stored procedures (that have lots of spaces in strings for formatting purposes). > > My original post and reply: > http://lists.ibiblio.org/pipermail/freetds/2014q3/028964.html > http://lists.ibiblio.org/pipermail/freetds/2014q3/028966.html > > The issue is with lines 7311-7314 in dblib.c: > > 7311 case NTBSTRINGBIND: /* strip trailing blanks, null > term */ > 7312 while (srclen && src[srclen - 1] == ' ') { > 7313 --srclen; > 7314 } > > Looks like something good to do, right? Get rid of any blanks that we > don't need. However, this keeps messing up my output when I use "defncopy" > to dump out some of my stored procedures. > Well... this is the expected behaviour of NTBSTRINGBIND. The problem is not in dblib.c but in defncopy that expects a different behaviour. > If it just so happens that you have a large stored procedure or large > string in that stored procedure *and* there are one or more spaces > exactly at a multiple of byte 4000, dblib.c will strip out the spaces, > causing either data corruption or an SQL syntax error in the stored procedure. > > I'm attaching an example to reproduce the issue. > > Load in 'dbo.big_proc-load.sql' and then immediately run 'defncopy' to > dump it back out. Each digit should have 40 spaces between it, but on > line 96, it only contains 8 spaces. dblib grabbed the first 4000 > bytes, saw there there were spaces, and truncated it back to the last non-space character. > > I've actually had this happen (just by pure chance) in actual code as > well, where a line like this: > > SELECT some_field_name AS some_field_alias > > has been turned into: > > SELECT some_field_nameAS some_field_alias > > Thus causing an error the next time the stored procedure is run, since > the field name is now incorrect. > > I've modified my copy of dblib.c and commented out lines 7312-7314 (as > I did so 2 years ago and I've had to negative effects), but would like > to hear thoughts/opinions of the developers and would really like this > issue fixed. > > Again, thank you all so much for all of your hard work on FreeTDS! > Seems that all bindings with varlen != 0 (as you don't want an overflow too): - does blank padding; - are limited; - strip blanks. All stuff you don't want for your usage. The possible solution is to not use binding but dbdata and family. Frediano _______________________________________________ FreeTDS mailing list FreeTDS at lists.ibiblio.org http://lists.ibiblio.org/mailman/listinfo/freetds ---------------------------------------------------------------------- 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 nem at emptec.com Tue Jun 14 11:58:52 2016 From: nem at emptec.com (Nem W Schlecht) Date: Tue, 14 Jun 2016 10:58:52 -0500 Subject: [freetds] Old dblib.c bug still there In-Reply-To: <4A990489BF566041A7724DC577BB060417581B3A@smtp_mail.bankofamerica.com> References: <4A990489BF566041A7724DC577BB060417581B3A@smtp_mail.bankofamerica.com> Message-ID: On Tue, Jun 14, 2016 at 7:43 AM, Thompson, William wrote: > I Agree with Freddy - if you want to make a change to test it out, I'd > make the change to defncopy.c > Try changing that NTBSTRINGBIND to plain old STRINGBIND, and see how that > affects the behaviour. > It looks to me like it should stop the trailing blanks from being stripped > off > > > Gave this a shot. In my test stored procedure, it now adds around 12,000 extra spaces. Not quite what I was hoping for. :) Looks like it wants to pad it out to 16,000 chars. I think it would work correctly if limited_dest_space weren't set in dblib.c copy_data_to_host_var(). Yes, I changed line 577 of defncopy.c from: erc = dbbind(dbproc, ctext, NTBSTRINGBIND, sizeof(sql_text), (BYTE *) sql_text); to: erc = dbbind(dbproc, ctext, STRINGBIND, 0, (BYTE *) sql_text); And now defncopy is working correctly on my test stored procedure. Is this going to mess anything else up, though? > > -----Original Message----- > From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of > Frediano Ziglio > Sent: 14 June 2016 12:58 > To: FreeTDS Development Group > Subject: Re: [freetds] Old dblib.c bug still there > > 2016-06-12 18:59 GMT+01:00 Nem W Schlecht : > > Hello all, > > > > First off, I just want to thank all of the developers in this > > community for continuing work on such a useful and excellent > > application. I cannot thank and appreciate you all enough! Thank you, > Thank You, THANK YOU!! > > > > > > I recently grabbed the last stable release and came across an issue > > that seems to constantly be plaguing me and has been around for a long > > time. I had reported this back in July of 2014, but the proposed > > solution (stripping all but one space) would still screw up some of my > > stored procedures (that have lots of spaces in strings for formatting > purposes). > > > > My original post and reply: > > http://lists.ibiblio.org/pipermail/freetds/2014q3/028964.html > > http://lists.ibiblio.org/pipermail/freetds/2014q3/028966.html > > > > The issue is with lines 7311-7314 in dblib.c: > > > > 7311 case NTBSTRINGBIND: /* strip trailing blanks, > null > > term */ > > 7312 while (srclen && src[srclen - 1] == ' ') { > > 7313 --srclen; > > 7314 } > > > > Looks like something good to do, right? Get rid of any blanks that we > > don't need. However, this keeps messing up my output when I use > "defncopy" > > to dump out some of my stored procedures. > > > > Well... this is the expected behaviour of NTBSTRINGBIND. The problem is > not in dblib.c but in defncopy that expects a different behaviour. > > > If it just so happens that you have a large stored procedure or large > > string in that stored procedure *and* there are one or more spaces > > exactly at a multiple of byte 4000, dblib.c will strip out the spaces, > > causing either data corruption or an SQL syntax error in the stored > procedure. > > > > I'm attaching an example to reproduce the issue. > > > > Load in 'dbo.big_proc-load.sql' and then immediately run 'defncopy' to > > dump it back out. Each digit should have 40 spaces between it, but on > > line 96, it only contains 8 spaces. dblib grabbed the first 4000 > > bytes, saw there there were spaces, and truncated it back to the last > non-space character. > > > > I've actually had this happen (just by pure chance) in actual code as > > well, where a line like this: > > > > SELECT some_field_name AS some_field_alias > > > > has been turned into: > > > > SELECT some_field_nameAS some_field_alias > > > > Thus causing an error the next time the stored procedure is run, since > > the field name is now incorrect. > > > > I've modified my copy of dblib.c and commented out lines 7312-7314 (as > > I did so 2 years ago and I've had to negative effects), but would like > > to hear thoughts/opinions of the developers and would really like this > > issue fixed. > > > > Again, thank you all so much for all of your hard work on FreeTDS! > > > > Seems that all bindings with varlen != 0 (as you don't want an overflow > too): > - does blank padding; > - are limited; > - strip blanks. > All stuff you don't want for your usage. The possible solution is to not > use binding but dbdata and family. > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > > ---------------------------------------------------------------------- > 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. > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > -- Nem W Schlecht "Perl did the magic. I just waved the wand." From bill.d.thompson at baml.com Wed Jun 15 04:37:43 2016 From: bill.d.thompson at baml.com (Thompson, William) Date: Wed, 15 Jun 2016 08:37:43 +0000 Subject: [freetds] Old dblib.c bug still there In-Reply-To: References: <4A990489BF566041A7724DC577BB060417581B3A@smtp_mail.bankofamerica.com> Message-ID: <4A990489BF566041A7724DC577BB060417581E34@smtp_mail.bankofamerica.com> Hi. Glad you found a solution! >From looking at the code, I can see why that would be just what was needed! The STRINGBIND is basically saying "don't strip any trailing blanks off the returned string" Passing 0 as the size of the destination field is basically telling dbbind "don't worry, I've got enough space to take whatever you're giving me, just give me what you've got" So it should the give you the stored procedure text as is. The only worry in programming terms is that 16000 bytes won't be enough to hold what sql server gives us, But think that highly unlikely, given we know what we're selecting... My guess would be that the users of defncopy could be counted on a couple of hands. The stripping off blanks behaviour would mess up many stored procedures where a syntactically significant blank fell at the end of one of the syscomments rows, e.g. row 1: "....SELECT * FROM " row 2: "MYTABLE WHERE....." so your fix is an improvement I have no doubt! Make the change, and give it to Freddy as a patch. If this would then be your first contribution to the project, welcome! Bill -----Original Message----- From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of Nem W Schlecht Sent: 14 June 2016 16:59 To: FreeTDS Development Group Subject: Re: [freetds] Old dblib.c bug still there On Tue, Jun 14, 2016 at 7:43 AM, Thompson, William wrote: > I Agree with Freddy - if you want to make a change to test it out, I'd > make the change to defncopy.c Try changing that NTBSTRINGBIND to plain > old STRINGBIND, and see how that affects the behaviour. > It looks to me like it should stop the trailing blanks from being > stripped off > > > Gave this a shot. In my test stored procedure, it now adds around 12,000 extra spaces. Not quite what I was hoping for. :) Looks like it wants to pad it out to 16,000 chars. I think it would work correctly if limited_dest_space weren't set in dblib.c copy_data_to_host_var(). Yes, I changed line 577 of defncopy.c from: erc = dbbind(dbproc, ctext, NTBSTRINGBIND, sizeof(sql_text), (BYTE *) sql_text); to: erc = dbbind(dbproc, ctext, STRINGBIND, 0, (BYTE *) sql_text); And now defncopy is working correctly on my test stored procedure. Is this going to mess anything else up, though? > > -----Original Message----- > From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of > Frediano Ziglio > Sent: 14 June 2016 12:58 > To: FreeTDS Development Group > Subject: Re: [freetds] Old dblib.c bug still there > > 2016-06-12 18:59 GMT+01:00 Nem W Schlecht : > > Hello all, > > > > First off, I just want to thank all of the developers in this > > community for continuing work on such a useful and excellent > > application. I cannot thank and appreciate you all enough! Thank > > you, > Thank You, THANK YOU!! > > > > > > I recently grabbed the last stable release and came across an issue > > that seems to constantly be plaguing me and has been around for a > > long time. I had reported this back in July of 2014, but the > > proposed solution (stripping all but one space) would still screw up > > some of my stored procedures (that have lots of spaces in strings > > for formatting > purposes). > > > > My original post and reply: > > http://lists.ibiblio.org/pipermail/freetds/2014q3/028964.html > > http://lists.ibiblio.org/pipermail/freetds/2014q3/028966.html > > > > The issue is with lines 7311-7314 in dblib.c: > > > > 7311 case NTBSTRINGBIND: /* strip trailing blanks, > null > > term */ > > 7312 while (srclen && src[srclen - 1] == ' ') { > > 7313 --srclen; > > 7314 } > > > > Looks like something good to do, right? Get rid of any blanks that > > we don't need. However, this keeps messing up my output when I use > "defncopy" > > to dump out some of my stored procedures. > > > > Well... this is the expected behaviour of NTBSTRINGBIND. The problem > is not in dblib.c but in defncopy that expects a different behaviour. > > > If it just so happens that you have a large stored procedure or > > large string in that stored procedure *and* there are one or more > > spaces exactly at a multiple of byte 4000, dblib.c will strip out > > the spaces, causing either data corruption or an SQL syntax error in > > the stored > procedure. > > > > I'm attaching an example to reproduce the issue. > > > > Load in 'dbo.big_proc-load.sql' and then immediately run 'defncopy' > > to dump it back out. Each digit should have 40 spaces between it, > > but on line 96, it only contains 8 spaces. dblib grabbed the first > > 4000 bytes, saw there there were spaces, and truncated it back to > > the last > non-space character. > > > > I've actually had this happen (just by pure chance) in actual code > > as well, where a line like this: > > > > SELECT some_field_name AS some_field_alias > > > > has been turned into: > > > > SELECT some_field_nameAS some_field_alias > > > > Thus causing an error the next time the stored procedure is run, > > since the field name is now incorrect. > > > > I've modified my copy of dblib.c and commented out lines 7312-7314 > > (as I did so 2 years ago and I've had to negative effects), but > > would like to hear thoughts/opinions of the developers and would > > really like this issue fixed. > > > > Again, thank you all so much for all of your hard work on FreeTDS! > > > > Seems that all bindings with varlen != 0 (as you don't want an > overflow > too): > - does blank padding; > - are limited; > - strip blanks. > All stuff you don't want for your usage. The possible solution is to > not use binding but dbdata and family. > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > > ---------------------------------------------------------------------- > 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. > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > -- Nem W Schlecht "Perl did the magic. I just waved the wand." _______________________________________________ FreeTDS mailing list FreeTDS at lists.ibiblio.org http://lists.ibiblio.org/mailman/listinfo/freetds ---------------------------------------------------------------------- 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 matthew.green at datamartcomputing.com Wed Jun 15 05:47:21 2016 From: matthew.green at datamartcomputing.com (matthew.green at datamartcomputing.com) Date: Wed, 15 Jun 2016 09:47:21 +0000 Subject: [freetds] Old dblib.c bug still there In-Reply-To: <4A990489BF566041A7724DC577BB060417581E34@smtp_mail.bankofamerica.com> References: <4A990489BF566041A7724DC577BB060417581E34@smtp_mail.bankofamerica.com> <4A990489BF566041A7724DC577BB060417581B3A@smtp_mail.bankofamerica.com> Message-ID: Forgive me if I'm saying something stupid but: I haven't looked at the code but I would imagine, for Sybase (or should I say SAP ASE) at least, the data is coming from the text column in syscomments which is varchar(255). You get multiple lines if the text of the procedure or trigger is bigger than that.... which is where the problem you're talking about comes from, assuming I've understood correctly. If memory serves there used to be a limit of 16K for procedural objects but that went a long time ago (12.5?) and we've certainly got a lot of procedural objects over the 16000 size. I think the new limit is: "The maximum amount of text in a stored procedure is 16MB.". I use defncopy quite a lot but I have to admit I've never used it from FreeTDS. Cheers, Matthew. June 15 2016 10:38 AM, "Thompson, William" wrote: > Hi. > > Glad you found a solution! > From looking at the code, I can see why that would be just what was needed! > The STRINGBIND is basically saying "don't strip any trailing blanks off the returned string" > Passing 0 as the size of the destination field is basically telling dbbind > "don't worry, I've got enough space to take whatever you're giving me, just give me what you've > got" > So it should the give you the stored procedure text as is. > > The only worry in programming terms is that 16000 bytes won't be enough to hold what sql server > gives us, > But think that highly unlikely, given we know what we're selecting... > > My guess would be that the users of defncopy could be counted on a couple of hands. > The stripping off blanks behaviour would mess up many stored procedures where a syntactically > significant blank > fell at the end of one of the syscomments rows, e.g. > row 1: "....SELECT * FROM " > row 2: "MYTABLE WHERE....." > > so your fix is an improvement I have no doubt! > Make the change, and give it to Freddy as a patch. > > If this would then be your first contribution to the project, welcome! > > Bill > > -----Original Message----- > From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of Nem W Schlecht > Sent: 14 June 2016 16:59 > To: FreeTDS Development Group > Subject: Re: [freetds] Old dblib.c bug still there > > On Tue, Jun 14, 2016 at 7:43 AM, Thompson, William >> wrote: >> >> I Agree with Freddy - if you want to make a change to test it out, I'd >> make the change to defncopy.c Try changing that NTBSTRINGBIND to plain >> old STRINGBIND, and see how that affects the behaviour. >> It looks to me like it should stop the trailing blanks from being >> stripped off > > Gave this a shot. In my test stored procedure, it now adds around 12,000 extra spaces. Not quite > what I was hoping for. :) Looks like it wants to pad it out to 16,000 chars. > > I think it would work correctly if limited_dest_space weren't set in dblib.c > copy_data_to_host_var(). > > Yes, I changed line 577 of defncopy.c from: > > erc = dbbind(dbproc, ctext, NTBSTRINGBIND, sizeof(sql_text), (BYTE *) sql_text); > > to: > > erc = dbbind(dbproc, ctext, STRINGBIND, 0, (BYTE *) sql_text); > > And now defncopy is working correctly on my test stored procedure. Is this going to mess anything > else up, though? > >> -----Original Message----- >> From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of >> Frediano Ziglio >> Sent: 14 June 2016 12:58 >> To: FreeTDS Development Group >> Subject: Re: [freetds] Old dblib.c bug still there >> >> 2016-06-12 18:59 GMT+01:00 Nem W Schlecht : >>> Hello all, >>> >>> First off, I just want to thank all of the developers in this >>> community for continuing work on such a useful and excellent >>> application. I cannot thank and appreciate you all enough! Thank >>> you, >> Thank You, THANK YOU!! >>> >>> >>> I recently grabbed the last stable release and came across an issue >>> that seems to constantly be plaguing me and has been around for a >>> long time. I had reported this back in July of 2014, but the >>> proposed solution (stripping all but one space) would still screw up >>> some of my stored procedures (that have lots of spaces in strings >>> for formatting >> purposes). >>> >>> My original post and reply: >>> http://lists.ibiblio.org/pipermail/freetds/2014q3/028964.html >>> http://lists.ibiblio.org/pipermail/freetds/2014q3/028966.html >>> >>> The issue is with lines 7311-7314 in dblib.c: >>> >>> 7311 case NTBSTRINGBIND: /* strip trailing blanks, >> null >>> term */ >>> 7312 while (srclen && src[srclen - 1] == ' ') { >>> 7313 --srclen; >>> 7314 } >>> >>> Looks like something good to do, right? Get rid of any blanks that >>> we don't need. However, this keeps messing up my output when I use >> "defncopy" >>> to dump out some of my stored procedures. >>> >> >> Well... this is the expected behaviour of NTBSTRINGBIND. The problem >> is not in dblib.c but in defncopy that expects a different behaviour. >> >>> If it just so happens that you have a large stored procedure or >>> large string in that stored procedure *and* there are one or more >>> spaces exactly at a multiple of byte 4000, dblib.c will strip out >>> the spaces, causing either data corruption or an SQL syntax error in >>> the stored >> procedure. >>> >>> I'm attaching an example to reproduce the issue. >>> >>> Load in 'dbo.big_proc-load.sql' and then immediately run 'defncopy' >>> to dump it back out. Each digit should have 40 spaces between it, >>> but on line 96, it only contains 8 spaces. dblib grabbed the first >>> 4000 bytes, saw there there were spaces, and truncated it back to >>> the last >> non-space character. >>> >>> I've actually had this happen (just by pure chance) in actual code >>> as well, where a line like this: >>> >>> SELECT some_field_name AS some_field_alias >>> >>> has been turned into: >>> >>> SELECT some_field_nameAS some_field_alias >>> >>> Thus causing an error the next time the stored procedure is run, >>> since the field name is now incorrect. >>> >>> I've modified my copy of dblib.c and commented out lines 7312-7314 >>> (as I did so 2 years ago and I've had to negative effects), but >>> would like to hear thoughts/opinions of the developers and would >>> really like this issue fixed. >>> >>> Again, thank you all so much for all of your hard work on FreeTDS! >>> >> >> Seems that all bindings with varlen != 0 (as you don't want an >> overflow >> too): >> - does blank padding; >> - are limited; >> - strip blanks. >> All stuff you don't want for your usage. The possible solution is to >> not use binding but dbdata and family. >> >> Frediano >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> http://lists.ibiblio.org/mailman/listinfo/freetds >> >> ---------------------------------------------------------------------- >> 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. >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> http://lists.ibiblio.org/mailman/listinfo/freetds > > -- > Nem W Schlecht > "Perl did the magic. I just waved the wand." > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > > ---------------------------------------------------------------------- > 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. > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From nem at emptec.com Wed Jun 15 11:37:29 2016 From: nem at emptec.com (Nem W Schlecht) Date: Wed, 15 Jun 2016 10:37:29 -0500 Subject: [freetds] Old dblib.c bug still there In-Reply-To: <4A990489BF566041A7724DC577BB060417581E34@smtp_mail.bankofamerica.com> References: <4A990489BF566041A7724DC577BB060417581B3A@smtp_mail.bankofamerica.com> <4A990489BF566041A7724DC577BB060417581E34@smtp_mail.bankofamerica.com> Message-ID: Well, I use defncopy all the time. :) Glad we worked through this. Should I mail this to Freddy directly or is attaching it here (as I've done) good enough? On Wed, Jun 15, 2016 at 3:37 AM, Thompson, William wrote: > Hi. > > Glad you found a solution! > From looking at the code, I can see why that would be just what was needed! > The STRINGBIND is basically saying "don't strip any trailing blanks off > the returned string" > Passing 0 as the size of the destination field is basically telling dbbind > "don't worry, I've got enough space to take whatever you're giving me, > just give me what you've got" > So it should the give you the stored procedure text as is. > > The only worry in programming terms is that 16000 bytes won't be enough to > hold what sql server gives us, > But think that highly unlikely, given we know what we're selecting... > > My guess would be that the users of defncopy could be counted on a couple > of hands. > The stripping off blanks behaviour would mess up many stored procedures > where a syntactically significant blank > fell at the end of one of the syscomments rows, e.g. > row 1: "....SELECT * FROM " > row 2: "MYTABLE WHERE....." > > so your fix is an improvement I have no doubt! > Make the change, and give it to Freddy as a patch. > > If this would then be your first contribution to the project, welcome! > > Bill > > > -----Original Message----- > From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of Nem > W Schlecht > Sent: 14 June 2016 16:59 > To: FreeTDS Development Group > Subject: Re: [freetds] Old dblib.c bug still there > > On Tue, Jun 14, 2016 at 7:43 AM, Thompson, William < > bill.d.thompson at baml.com > > wrote: > > > I Agree with Freddy - if you want to make a change to test it out, I'd > > make the change to defncopy.c Try changing that NTBSTRINGBIND to plain > > old STRINGBIND, and see how that affects the behaviour. > > It looks to me like it should stop the trailing blanks from being > > stripped off > > > > > > > Gave this a shot. In my test stored procedure, it now adds around 12,000 > extra spaces. Not quite what I was hoping for. :) Looks like it wants to > pad it out to 16,000 chars. > > I think it would work correctly if limited_dest_space weren't set in > dblib.c copy_data_to_host_var(). > > Yes, I changed line 577 of defncopy.c from: > > erc = dbbind(dbproc, ctext, NTBSTRINGBIND, sizeof(sql_text), (BYTE *) > sql_text); > > to: > > erc = dbbind(dbproc, ctext, STRINGBIND, 0, (BYTE *) sql_text); > > > And now defncopy is working correctly on my test stored procedure. Is > this going to mess anything else up, though? > > > > > > > > -----Original Message----- > > From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of > > Frediano Ziglio > > Sent: 14 June 2016 12:58 > > To: FreeTDS Development Group > > Subject: Re: [freetds] Old dblib.c bug still there > > > > 2016-06-12 18:59 GMT+01:00 Nem W Schlecht : > > > Hello all, > > > > > > First off, I just want to thank all of the developers in this > > > community for continuing work on such a useful and excellent > > > application. I cannot thank and appreciate you all enough! Thank > > > you, > > Thank You, THANK YOU!! > > > > > > > > > I recently grabbed the last stable release and came across an issue > > > that seems to constantly be plaguing me and has been around for a > > > long time. I had reported this back in July of 2014, but the > > > proposed solution (stripping all but one space) would still screw up > > > some of my stored procedures (that have lots of spaces in strings > > > for formatting > > purposes). > > > > > > My original post and reply: > > > http://lists.ibiblio.org/pipermail/freetds/2014q3/028964.html > > > http://lists.ibiblio.org/pipermail/freetds/2014q3/028966.html > > > > > > The issue is with lines 7311-7314 in dblib.c: > > > > > > 7311 case NTBSTRINGBIND: /* strip trailing blanks, > > null > > > term */ > > > 7312 while (srclen && src[srclen - 1] == ' ') { > > > 7313 --srclen; > > > 7314 } > > > > > > Looks like something good to do, right? Get rid of any blanks that > > > we don't need. However, this keeps messing up my output when I use > > "defncopy" > > > to dump out some of my stored procedures. > > > > > > > Well... this is the expected behaviour of NTBSTRINGBIND. The problem > > is not in dblib.c but in defncopy that expects a different behaviour. > > > > > If it just so happens that you have a large stored procedure or > > > large string in that stored procedure *and* there are one or more > > > spaces exactly at a multiple of byte 4000, dblib.c will strip out > > > the spaces, causing either data corruption or an SQL syntax error in > > > the stored > > procedure. > > > > > > I'm attaching an example to reproduce the issue. > > > > > > Load in 'dbo.big_proc-load.sql' and then immediately run 'defncopy' > > > to dump it back out. Each digit should have 40 spaces between it, > > > but on line 96, it only contains 8 spaces. dblib grabbed the first > > > 4000 bytes, saw there there were spaces, and truncated it back to > > > the last > > non-space character. > > > > > > I've actually had this happen (just by pure chance) in actual code > > > as well, where a line like this: > > > > > > SELECT some_field_name AS some_field_alias > > > > > > has been turned into: > > > > > > SELECT some_field_nameAS some_field_alias > > > > > > Thus causing an error the next time the stored procedure is run, > > > since the field name is now incorrect. > > > > > > I've modified my copy of dblib.c and commented out lines 7312-7314 > > > (as I did so 2 years ago and I've had to negative effects), but > > > would like to hear thoughts/opinions of the developers and would > > > really like this issue fixed. > > > > > > Again, thank you all so much for all of your hard work on FreeTDS! > > > > > > > Seems that all bindings with varlen != 0 (as you don't want an > > overflow > > too): > > - does blank padding; > > - are limited; > > - strip blanks. > > All stuff you don't want for your usage. The possible solution is to > > not use binding but dbdata and family. > > > > Frediano > > _______________________________________________ > > FreeTDS mailing list > > FreeTDS at lists.ibiblio.org > > http://lists.ibiblio.org/mailman/listinfo/freetds > > > > ---------------------------------------------------------------------- > > 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. > > _______________________________________________ > > FreeTDS mailing list > > FreeTDS at lists.ibiblio.org > > http://lists.ibiblio.org/mailman/listinfo/freetds > > > > > > -- > Nem W Schlecht > "Perl did the magic. I just waved the wand." > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > > ---------------------------------------------------------------------- > 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. > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > -- Nem W Schlecht nem at emptec.com Empyreal Technologies http://www.emptec.com/ "Perl did the magic. I just waved the wand." -------------- next part -------------- diff --git a/freetds-1.00.3/src/apps/defncopy.c b/freetds-1.00.3-defncopyfix/src/apps/defncopy.c index e76d1b3..4890492 100644 --- a/freetds-1.00.3/src/apps/defncopy.c +++ b/freetds-1.00.3-defncopyfix/src/apps/defncopy.c @@ -574,7 +574,7 @@ print_results(DBPROCESS *dbproc) assert(sizeof(sql_text) >= dbcollen(dbproc, ctext)); return 0; } - erc = dbbind(dbproc, ctext, NTBSTRINGBIND, sizeof(sql_text), (BYTE *) sql_text); + erc = dbbind(dbproc, ctext, STRINGBIND, 0, (BYTE *) sql_text); if (erc == FAIL) { fprintf(stderr, "%s:%d: dbbind(), column %d failed\n", options.appname, __LINE__, ctext); return -1; From nem at emptec.com Thu Jun 16 09:57:26 2016 From: nem at emptec.com (Nem W Schlecht) Date: Thu, 16 Jun 2016 08:57:26 -0500 Subject: [freetds] Old dblib.c bug still there In-Reply-To: <4A990489BF566041A7724DC577BB060417581E34@smtp_mail.bankofamerica.com> References: <4A990489BF566041A7724DC577BB060417581B3A@smtp_mail.bankofamerica.com> <4A990489BF566041A7724DC577BB060417581E34@smtp_mail.bankofamerica.com> Message-ID: Well, I use defncopy all the time. :) Glad we worked through this. Should I mail this to Freddy directly or is attaching it here (as I've done) good enough? (Sorry if this is a repeat message - I didn't see the message I sent yesterday show up in the archive) On Wed, Jun 15, 2016 at 3:37 AM, Thompson, William wrote: > Hi. > > Glad you found a solution! > From looking at the code, I can see why that would be just what was needed! > The STRINGBIND is basically saying "don't strip any trailing blanks off the returned string" > Passing 0 as the size of the destination field is basically telling dbbind > "don't worry, I've got enough space to take whatever you're giving me, just give me what you've got" > So it should the give you the stored procedure text as is. > > The only worry in programming terms is that 16000 bytes won't be enough to hold what sql server gives us, > But think that highly unlikely, given we know what we're selecting... > > My guess would be that the users of defncopy could be counted on a couple of hands. > The stripping off blanks behaviour would mess up many stored procedures where a syntactically significant blank > fell at the end of one of the syscomments rows, e.g. > row 1: "....SELECT * FROM " > row 2: "MYTABLE WHERE....." > > so your fix is an improvement I have no doubt! > Make the change, and give it to Freddy as a patch. > > If this would then be your first contribution to the project, welcome! > > Bill > > > -----Original Message----- > From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of Nem W Schlecht > Sent: 14 June 2016 16:59 > To: FreeTDS Development Group > Subject: Re: [freetds] Old dblib.c bug still there > > On Tue, Jun 14, 2016 at 7:43 AM, Thompson, William > wrote: > >> I Agree with Freddy - if you want to make a change to test it out, I'd >> make the change to defncopy.c Try changing that NTBSTRINGBIND to plain >> old STRINGBIND, and see how that affects the behaviour. >> It looks to me like it should stop the trailing blanks from being >> stripped off >> >> >> > Gave this a shot. In my test stored procedure, it now adds around 12,000 extra spaces. Not quite what I was hoping for. :) Looks like it wants to pad it out to 16,000 chars. > > I think it would work correctly if limited_dest_space weren't set in dblib.c copy_data_to_host_var(). > > Yes, I changed line 577 of defncopy.c from: > > erc = dbbind(dbproc, ctext, NTBSTRINGBIND, sizeof(sql_text), (BYTE *) sql_text); > > to: > > erc = dbbind(dbproc, ctext, STRINGBIND, 0, (BYTE *) sql_text); > > > And now defncopy is working correctly on my test stored procedure. Is this going to mess anything else up, though? > > > > >> >> -----Original Message----- >> From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of >> Frediano Ziglio >> Sent: 14 June 2016 12:58 >> To: FreeTDS Development Group >> Subject: Re: [freetds] Old dblib.c bug still there >> >> 2016-06-12 18:59 GMT+01:00 Nem W Schlecht : >> > Hello all, >> > >> > First off, I just want to thank all of the developers in this >> > community for continuing work on such a useful and excellent >> > application. I cannot thank and appreciate you all enough! Thank >> > you, >> Thank You, THANK YOU!! >> > >> > >> > I recently grabbed the last stable release and came across an issue >> > that seems to constantly be plaguing me and has been around for a >> > long time. I had reported this back in July of 2014, but the >> > proposed solution (stripping all but one space) would still screw up >> > some of my stored procedures (that have lots of spaces in strings >> > for formatting >> purposes). >> > >> > My original post and reply: >> > http://lists.ibiblio.org/pipermail/freetds/2014q3/028964.html >> > http://lists.ibiblio.org/pipermail/freetds/2014q3/028966.html >> > >> > The issue is with lines 7311-7314 in dblib.c: >> > >> > 7311 case NTBSTRINGBIND: /* strip trailing blanks, >> null >> > term */ >> > 7312 while (srclen && src[srclen - 1] == ' ') { >> > 7313 --srclen; >> > 7314 } >> > >> > Looks like something good to do, right? Get rid of any blanks that >> > we don't need. However, this keeps messing up my output when I use >> "defncopy" >> > to dump out some of my stored procedures. >> > >> >> Well... this is the expected behaviour of NTBSTRINGBIND. The problem >> is not in dblib.c but in defncopy that expects a different behaviour. >> -- Nem W Schlecht "Perl did the magic. I just waved the wand." -------------- next part -------------- diff --git a/freetds-1.00.3/src/apps/defncopy.c b/freetds-1.00.3-defncopyfix/src/apps/defncopy.c index e76d1b3..4890492 100644 --- a/freetds-1.00.3/src/apps/defncopy.c +++ b/freetds-1.00.3-defncopyfix/src/apps/defncopy.c @@ -574,7 +574,7 @@ print_results(DBPROCESS *dbproc) assert(sizeof(sql_text) >= dbcollen(dbproc, ctext)); return 0; } - erc = dbbind(dbproc, ctext, NTBSTRINGBIND, sizeof(sql_text), (BYTE *) sql_text); + erc = dbbind(dbproc, ctext, STRINGBIND, 0, (BYTE *) sql_text); if (erc == FAIL) { fprintf(stderr, "%s:%d: dbbind(), column %d failed\n", options.appname, __LINE__, ctext); return -1; From adam.baratz at gmail.com Thu Jun 16 12:18:34 2016 From: adam.baratz at gmail.com (Adam Baratz) Date: Thu, 16 Jun 2016 12:18:34 -0400 Subject: [freetds] dbcanquery() with pdo_dblib Message-ID: Hi, I'm looking at fixing this bug with the PHP pdo_dblib extension: https://bugs.php.net/bug.php?id=67130 I have it built to use FreeTDS to communicate with MSSQL. My understanding from the docs is that dbcanquery() does what's needed here. Basically, it should be called before using dbresults() to get the next rowset[1]. However, that doesn't seem to resolve the issue. The call succeeds, but the call to dbresults() will then fail. What I've found works is fetching the rows manually: RETCODE ret = SUCCESS; while (ret == SUCCESS) { ret = dbnextrow(H->link); } I don't want to do anything with these rows, so I'd rather not do this. Am I missing something basic about how dbcanquery() is supposed to be used? Thanks, Adam --- [1] https://github.com/php/php-src/blob/aed42496534fe54c5c0ce64fe0ca5c9d801d6161/ext/pdo_dblib/dblib_stmt.c#L144 From bill.d.thompson at baml.com Fri Jun 17 04:16:47 2016 From: bill.d.thompson at baml.com (Thompson, William) Date: Fri, 17 Jun 2016 08:16:47 +0000 Subject: [freetds] dbcanquery() with pdo_dblib In-Reply-To: References: Message-ID: <4A990489BF566041A7724DC577BB060417583507@smtp_mail.bankofamerica.com> Hi Adam, I don't think you've misunderstood what dbcanquery is supposed to do. The Sybase documentation says that it is equivalent to calling dbnextrow until it reurns NO_MORE_ROWS, which is pretty much what you've replicated. So it looks like our implementation of dbcanquery() isn't exactly the same as doing that... It's difficult to see what might be happening without a debug log Can you run your test of dbcanquery() with TDSDUMP logging set? And then post with the log attached? See http://www.freetds.org/userguide/logging.htm Cheers, Bill -----Original Message----- From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of Adam Baratz Sent: 16 June 2016 17:19 To: freetds at lists.ibiblio.org Subject: [freetds] dbcanquery() with pdo_dblib Hi, I'm looking at fixing this bug with the PHP pdo_dblib extension: https://bugs.php.net/bug.php?id=67130 I have it built to use FreeTDS to communicate with MSSQL. My understanding from the docs is that dbcanquery() does what's needed here. Basically, it should be called before using dbresults() to get the next rowset[1]. However, that doesn't seem to resolve the issue. The call succeeds, but the call to dbresults() will then fail. What I've found works is fetching the rows manually: RETCODE ret = SUCCESS; while (ret == SUCCESS) { ret = dbnextrow(H->link); } I don't want to do anything with these rows, so I'd rather not do this. Am I missing something basic about how dbcanquery() is supposed to be used? Thanks, Adam --- [1] https://github.com/php/php-src/blob/aed42496534fe54c5c0ce64fe0ca5c9d801d6161/ext/pdo_dblib/dblib_stmt.c#L144 _______________________________________________ FreeTDS mailing list FreeTDS at lists.ibiblio.org http://lists.ibiblio.org/mailman/listinfo/freetds ---------------------------------------------------------------------- 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 nem at emptec.com Thu Jun 16 16:20:24 2016 From: nem at emptec.com (Nem W Schlecht) Date: Thu, 16 Jun 2016 15:20:24 -0500 Subject: [freetds] Another defncopy patch - check dbopen results Message-ID: I have another defncopy patch to fix another issue. The results from dbopen() are just checked with an assert() call. Thus, if I type in the wrong database name, username, whatever, I get a core dump that I have to clean up from a typo on my part. What do you all think of a quick check/message/exit, similar to what happens with tsql? Patch attached. Just checks to see if dbproc has a value. If not, prints an error message and exit(1)s. Otherwise, continues on. I deal with a lot of servers and a lot of usernames/passwords, so this one hits me fairly often. -- Nem W Schlecht "Perl did the magic. I just waved the wand." -------------- next part -------------- A non-text attachment was scrubbed... Name: defncopyfix-20160616.patch Type: application/octet-stream Size: 533 bytes Desc: not available URL: From freddy77 at gmail.com Fri Jun 17 17:41:27 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Fri, 17 Jun 2016 22:41:27 +0100 Subject: [freetds] Another defncopy patch - check dbopen results In-Reply-To: References: Message-ID: 2016-06-16 21:20 GMT+01:00 Nem W Schlecht : > I have another defncopy patch to fix another issue. The results from > dbopen() are just checked with an assert() call. Thus, if I type in > the wrong database name, username, whatever, I get a core dump that I > have to clean up from a typo on my part. What do you all think of a > quick check/message/exit, similar to what happens with tsql? > > Patch attached. Just checks to see if dbproc has a value. If not, > prints an error message and exit(1)s. Otherwise, continues on. > > I deal with a lot of servers and a lot of usernames/passwords, so this > one hits me fairly often. > > > -- > Nem W Schlecht > "Perl did the magic. I just waved the wand." > Merged, thanks From adam.baratz at gmail.com Fri Jun 17 11:22:03 2016 From: adam.baratz at gmail.com (Adam Baratz) Date: Fri, 17 Jun 2016 11:22:03 -0400 Subject: [freetds] dbcanquery() with pdo_dblib In-Reply-To: <4A990489BF566041A7724DC577BB060417583507@smtp_mail.bankofamerica.com> References: <4A990489BF566041A7724DC577BB060417583507@smtp_mail.bankofamerica.com> Message-ID: Thanks, see attached. I [redacted] the auth transmission. On Fri, Jun 17, 2016 at 4:16 AM, Thompson, William wrote: > Hi Adam, > > I don't think you've misunderstood what dbcanquery is supposed to do. The > Sybase documentation says that it is equivalent to calling dbnextrow until > it reurns NO_MORE_ROWS, which is pretty much what you've replicated. > So it looks like our implementation of dbcanquery() isn't exactly the same > as doing that... > > It's difficult to see what might be happening without a debug log > Can you run your test of dbcanquery() with TDSDUMP logging set? And then > post with the log attached? > See http://www.freetds.org/userguide/logging.htm > > Cheers, > > Bill > > > -----Original Message----- > From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of > Adam Baratz > Sent: 16 June 2016 17:19 > To: freetds at lists.ibiblio.org > Subject: [freetds] dbcanquery() with pdo_dblib > > Hi, > > I'm looking at fixing this bug with the PHP pdo_dblib extension: > https://bugs.php.net/bug.php?id=67130 > > I have it built to use FreeTDS to communicate with MSSQL. > > My understanding from the docs is that dbcanquery() does what's needed > here. Basically, it should be called before using dbresults() to get the > next rowset[1]. However, that doesn't seem to resolve the issue. The call > succeeds, but the call to dbresults() will then fail. What I've found works > is fetching the rows manually: > > RETCODE ret = SUCCESS; > > while (ret == SUCCESS) { > ret = dbnextrow(H->link); > } > > I don't want to do anything with these rows, so I'd rather not do this. Am > I missing something basic about how dbcanquery() is supposed to be used? > > Thanks, > Adam > > --- > [1] > > https://github.com/php/php-src/blob/aed42496534fe54c5c0ce64fe0ca5c9d801d6161/ext/pdo_dblib/dblib_stmt.c#L144 > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > > ---------------------------------------------------------------------- > 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. > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > -------------- next part -------------- A non-text attachment was scrubbed... Name: freetds.log Type: application/octet-stream Size: 10778 bytes Desc: not available URL: From freddy77 at gmail.com Sat Jun 18 08:31:08 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Sat, 18 Jun 2016 13:31:08 +0100 Subject: [freetds] Old dblib.c bug still there In-Reply-To: References: <4A990489BF566041A7724DC577BB060417581B3A@smtp_mail.bankofamerica.com> <4A990489BF566041A7724DC577BB060417581E34@smtp_mail.bankofamerica.com> Message-ID: 2016-06-15 16:37 GMT+01:00 Nem W Schlecht : > Well, I use defncopy all the time. :) Glad we worked through this. Should > I mail this to Freddy directly or is attaching it here (as I've done) good > enough? > Merged with a comment for overflow. Frediano > On Wed, Jun 15, 2016 at 3:37 AM, Thompson, William > wrote: > >> Hi. >> >> Glad you found a solution! >> From looking at the code, I can see why that would be just what was needed! >> The STRINGBIND is basically saying "don't strip any trailing blanks off >> the returned string" >> Passing 0 as the size of the destination field is basically telling dbbind >> "don't worry, I've got enough space to take whatever you're giving me, >> just give me what you've got" >> So it should the give you the stored procedure text as is. >> >> The only worry in programming terms is that 16000 bytes won't be enough to >> hold what sql server gives us, >> But think that highly unlikely, given we know what we're selecting... >> >> My guess would be that the users of defncopy could be counted on a couple >> of hands. >> The stripping off blanks behaviour would mess up many stored procedures >> where a syntactically significant blank >> fell at the end of one of the syscomments rows, e.g. >> row 1: "....SELECT * FROM " >> row 2: "MYTABLE WHERE....." >> >> so your fix is an improvement I have no doubt! >> Make the change, and give it to Freddy as a patch. >> >> If this would then be your first contribution to the project, welcome! >> >> Bill >> >> >> -----Original Message----- >> From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of Nem >> W Schlecht >> Sent: 14 June 2016 16:59 >> To: FreeTDS Development Group >> Subject: Re: [freetds] Old dblib.c bug still there >> >> On Tue, Jun 14, 2016 at 7:43 AM, Thompson, William < >> bill.d.thompson at baml.com >> > wrote: >> >> > I Agree with Freddy - if you want to make a change to test it out, I'd >> > make the change to defncopy.c Try changing that NTBSTRINGBIND to plain >> > old STRINGBIND, and see how that affects the behaviour. >> > It looks to me like it should stop the trailing blanks from being >> > stripped off >> > >> > >> > >> Gave this a shot. In my test stored procedure, it now adds around 12,000 >> extra spaces. Not quite what I was hoping for. :) Looks like it wants to >> pad it out to 16,000 chars. >> >> I think it would work correctly if limited_dest_space weren't set in >> dblib.c copy_data_to_host_var(). >> >> Yes, I changed line 577 of defncopy.c from: >> >> erc = dbbind(dbproc, ctext, NTBSTRINGBIND, sizeof(sql_text), (BYTE *) >> sql_text); >> >> to: >> >> erc = dbbind(dbproc, ctext, STRINGBIND, 0, (BYTE *) sql_text); >> >> >> And now defncopy is working correctly on my test stored procedure. Is >> this going to mess anything else up, though? >> >> >> >> >> > >> > -----Original Message----- >> > From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of >> > Frediano Ziglio >> > Sent: 14 June 2016 12:58 >> > To: FreeTDS Development Group >> > Subject: Re: [freetds] Old dblib.c bug still there >> > >> > 2016-06-12 18:59 GMT+01:00 Nem W Schlecht : >> > > Hello all, >> > > >> > > First off, I just want to thank all of the developers in this >> > > community for continuing work on such a useful and excellent >> > > application. I cannot thank and appreciate you all enough! Thank >> > > you, >> > Thank You, THANK YOU!! >> > > >> > > >> > > I recently grabbed the last stable release and came across an issue >> > > that seems to constantly be plaguing me and has been around for a >> > > long time. I had reported this back in July of 2014, but the >> > > proposed solution (stripping all but one space) would still screw up >> > > some of my stored procedures (that have lots of spaces in strings >> > > for formatting >> > purposes). >> > > >> > > My original post and reply: >> > > http://lists.ibiblio.org/pipermail/freetds/2014q3/028964.html >> > > http://lists.ibiblio.org/pipermail/freetds/2014q3/028966.html >> > > >> > > The issue is with lines 7311-7314 in dblib.c: >> > > >> > > 7311 case NTBSTRINGBIND: /* strip trailing blanks, >> > null >> > > term */ >> > > 7312 while (srclen && src[srclen - 1] == ' ') { >> > > 7313 --srclen; >> > > 7314 } >> > > >> > > Looks like something good to do, right? Get rid of any blanks that >> > > we don't need. However, this keeps messing up my output when I use >> > "defncopy" >> > > to dump out some of my stored procedures. >> > > >> > >> > Well... this is the expected behaviour of NTBSTRINGBIND. The problem >> > is not in dblib.c but in defncopy that expects a different behaviour. >> > >> > > If it just so happens that you have a large stored procedure or >> > > large string in that stored procedure *and* there are one or more >> > > spaces exactly at a multiple of byte 4000, dblib.c will strip out >> > > the spaces, causing either data corruption or an SQL syntax error in >> > > the stored >> > procedure. >> > > >> > > I'm attaching an example to reproduce the issue. >> > > >> > > Load in 'dbo.big_proc-load.sql' and then immediately run 'defncopy' >> > > to dump it back out. Each digit should have 40 spaces between it, >> > > but on line 96, it only contains 8 spaces. dblib grabbed the first >> > > 4000 bytes, saw there there were spaces, and truncated it back to >> > > the last >> > non-space character. >> > > >> > > I've actually had this happen (just by pure chance) in actual code >> > > as well, where a line like this: >> > > >> > > SELECT some_field_name AS some_field_alias >> > > >> > > has been turned into: >> > > >> > > SELECT some_field_nameAS some_field_alias >> > > >> > > Thus causing an error the next time the stored procedure is run, >> > > since the field name is now incorrect. >> > > >> > > I've modified my copy of dblib.c and commented out lines 7312-7314 >> > > (as I did so 2 years ago and I've had to negative effects), but >> > > would like to hear thoughts/opinions of the developers and would >> > > really like this issue fixed. >> > > >> > > Again, thank you all so much for all of your hard work on FreeTDS! >> > > >> > >> > Seems that all bindings with varlen != 0 (as you don't want an >> > overflow >> > too): >> > - does blank padding; >> > - are limited; >> > - strip blanks. >> > All stuff you don't want for your usage. The possible solution is to >> > not use binding but dbdata and family. >> > >> > Frediano >> > _______________________________________________ >> > FreeTDS mailing list >> > FreeTDS at lists.ibiblio.org >> > http://lists.ibiblio.org/mailman/listinfo/freetds >> > >> > ---------------------------------------------------------------------- >> > 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. >> > _______________________________________________ >> > FreeTDS mailing list >> > FreeTDS at lists.ibiblio.org >> > http://lists.ibiblio.org/mailman/listinfo/freetds >> > >> >> >> >> -- >> Nem W Schlecht >> "Perl did the magic. I just waved the wand." >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> http://lists.ibiblio.org/mailman/listinfo/freetds >> >> ---------------------------------------------------------------------- >> 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. >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> http://lists.ibiblio.org/mailman/listinfo/freetds >> > > > > -- > Nem W Schlecht nem at emptec.com > Empyreal Technologies http://www.emptec.com/ > "Perl did the magic. I just waved the wand." > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > From freddy77 at gmail.com Sat Jun 18 14:18:41 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Sat, 18 Jun 2016 19:18:41 +0100 Subject: [freetds] dbcanquery() with pdo_dblib In-Reply-To: References: <4A990489BF566041A7724DC577BB060417583507@smtp_mail.bankofamerica.com> Message-ID: 2016-06-17 16:22 GMT+01:00 Adam Baratz : > Thanks, see attached. I [redacted] the auth transmission. > I think you found a bug. state is not set correctly after discarding the results :( Not really hard to fix but I'd like a test for it. Frediano > On Fri, Jun 17, 2016 at 4:16 AM, Thompson, William > wrote: > >> Hi Adam, >> >> I don't think you've misunderstood what dbcanquery is supposed to do. The >> Sybase documentation says that it is equivalent to calling dbnextrow until >> it reurns NO_MORE_ROWS, which is pretty much what you've replicated. >> So it looks like our implementation of dbcanquery() isn't exactly the same >> as doing that... >> >> It's difficult to see what might be happening without a debug log >> Can you run your test of dbcanquery() with TDSDUMP logging set? And then >> post with the log attached? >> See http://www.freetds.org/userguide/logging.htm >> >> Cheers, >> >> Bill >> >> >> -----Original Message----- >> From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of >> Adam Baratz >> Sent: 16 June 2016 17:19 >> To: freetds at lists.ibiblio.org >> Subject: [freetds] dbcanquery() with pdo_dblib >> >> Hi, >> >> I'm looking at fixing this bug with the PHP pdo_dblib extension: >> https://bugs.php.net/bug.php?id=67130 >> >> I have it built to use FreeTDS to communicate with MSSQL. >> >> My understanding from the docs is that dbcanquery() does what's needed >> here. Basically, it should be called before using dbresults() to get the >> next rowset[1]. However, that doesn't seem to resolve the issue. The call >> succeeds, but the call to dbresults() will then fail. What I've found works >> is fetching the rows manually: >> >> RETCODE ret = SUCCESS; >> >> while (ret == SUCCESS) { >> ret = dbnextrow(H->link); >> } >> >> I don't want to do anything with these rows, so I'd rather not do this. Am >> I missing something basic about how dbcanquery() is supposed to be used? >> >> Thanks, >> Adam >> >> --- >> [1] >> >> https://github.com/php/php-src/blob/aed42496534fe54c5c0ce64fe0ca5c9d801d6161/ext/pdo_dblib/dblib_stmt.c#L144 >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> http://lists.ibiblio.org/mailman/listinfo/freetds >> >> ---------------------------------------------------------------------- >> 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. >> _______________________________________________ >> 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 Sat Jun 18 16:26:22 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Sat, 18 Jun 2016 21:26:22 +0100 Subject: [freetds] dbcanquery() with pdo_dblib In-Reply-To: References: <4A990489BF566041A7724DC577BB060417583507@smtp_mail.bankofamerica.com> Message-ID: Fixed. Frediano 2016-06-17 16:22 GMT+01:00 Adam Baratz : > Thanks, see attached. I [redacted] the auth transmission. > > On Fri, Jun 17, 2016 at 4:16 AM, Thompson, William > wrote: > >> Hi Adam, >> >> I don't think you've misunderstood what dbcanquery is supposed to do. The >> Sybase documentation says that it is equivalent to calling dbnextrow until >> it reurns NO_MORE_ROWS, which is pretty much what you've replicated. >> So it looks like our implementation of dbcanquery() isn't exactly the same >> as doing that... >> >> It's difficult to see what might be happening without a debug log >> Can you run your test of dbcanquery() with TDSDUMP logging set? And then >> post with the log attached? >> See http://www.freetds.org/userguide/logging.htm >> >> Cheers, >> >> Bill >> >> >> -----Original Message----- >> From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of >> Adam Baratz >> Sent: 16 June 2016 17:19 >> To: freetds at lists.ibiblio.org >> Subject: [freetds] dbcanquery() with pdo_dblib >> >> Hi, >> >> I'm looking at fixing this bug with the PHP pdo_dblib extension: >> https://bugs.php.net/bug.php?id=67130 >> >> I have it built to use FreeTDS to communicate with MSSQL. >> >> My understanding from the docs is that dbcanquery() does what's needed >> here. Basically, it should be called before using dbresults() to get the >> next rowset[1]. However, that doesn't seem to resolve the issue. The call >> succeeds, but the call to dbresults() will then fail. What I've found works >> is fetching the rows manually: >> >> RETCODE ret = SUCCESS; >> >> while (ret == SUCCESS) { >> ret = dbnextrow(H->link); >> } >> >> I don't want to do anything with these rows, so I'd rather not do this. Am >> I missing something basic about how dbcanquery() is supposed to be used? >> >> Thanks, >> Adam >> >> --- >> [1] >> >> https://github.com/php/php-src/blob/aed42496534fe54c5c0ce64fe0ca5c9d801d6161/ext/pdo_dblib/dblib_stmt.c#L144 >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at lists.ibiblio.org >> http://lists.ibiblio.org/mailman/listinfo/freetds >> >> ---------------------------------------------------------------------- >> 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. >> _______________________________________________ >> 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 adam.baratz at gmail.com Mon Jun 20 17:07:46 2016 From: adam.baratz at gmail.com (Adam Baratz) Date: Mon, 20 Jun 2016 17:07:46 -0400 Subject: [freetds] dbcanquery() with pdo_dblib In-Reply-To: References: <4A990489BF566041A7724DC577BB060417583507@smtp_mail.bankofamerica.com> Message-ID: Thanks for the fast fix! On Sat, Jun 18, 2016 at 4:26 PM, Frediano Ziglio wrote: > Fixed. > > Frediano > > 2016-06-17 16:22 GMT+01:00 Adam Baratz : > > Thanks, see attached. I [redacted] the auth transmission. > > > > On Fri, Jun 17, 2016 at 4:16 AM, Thompson, William < > bill.d.thompson at baml.com > >> wrote: > > > >> Hi Adam, > >> > >> I don't think you've misunderstood what dbcanquery is supposed to do. > The > >> Sybase documentation says that it is equivalent to calling dbnextrow > until > >> it reurns NO_MORE_ROWS, which is pretty much what you've replicated. > >> So it looks like our implementation of dbcanquery() isn't exactly the > same > >> as doing that... > >> > >> It's difficult to see what might be happening without a debug log > >> Can you run your test of dbcanquery() with TDSDUMP logging set? And then > >> post with the log attached? > >> See http://www.freetds.org/userguide/logging.htm > >> > >> Cheers, > >> > >> Bill > >> > >> > >> -----Original Message----- > >> From: FreeTDS [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of > >> Adam Baratz > >> Sent: 16 June 2016 17:19 > >> To: freetds at lists.ibiblio.org > >> Subject: [freetds] dbcanquery() with pdo_dblib > >> > >> Hi, > >> > >> I'm looking at fixing this bug with the PHP pdo_dblib extension: > >> https://bugs.php.net/bug.php?id=67130 > >> > >> I have it built to use FreeTDS to communicate with MSSQL. > >> > >> My understanding from the docs is that dbcanquery() does what's needed > >> here. Basically, it should be called before using dbresults() to get the > >> next rowset[1]. However, that doesn't seem to resolve the issue. The > call > >> succeeds, but the call to dbresults() will then fail. What I've found > works > >> is fetching the rows manually: > >> > >> RETCODE ret = SUCCESS; > >> > >> while (ret == SUCCESS) { > >> ret = dbnextrow(H->link); > >> } > >> > >> I don't want to do anything with these rows, so I'd rather not do this. > Am > >> I missing something basic about how dbcanquery() is supposed to be used? > >> > >> Thanks, > >> Adam > >> > >> --- > >> [1] > >> > >> > https://github.com/php/php-src/blob/aed42496534fe54c5c0ce64fe0ca5c9d801d6161/ext/pdo_dblib/dblib_stmt.c#L144 > >> _______________________________________________ > >> FreeTDS mailing list > >> FreeTDS at lists.ibiblio.org > >> http://lists.ibiblio.org/mailman/listinfo/freetds > >> > >> ---------------------------------------------------------------------- > >> 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. > >> _______________________________________________ > >> 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 adam.baratz at gmail.com Tue Jun 21 17:45:58 2016 From: adam.baratz at gmail.com (Adam Baratz) Date: Tue, 21 Jun 2016 17:45:58 -0400 Subject: [freetds] version detection Message-ID: Following up on my pdo_dblib thread, I'd like to be able to detect which version of FreeTDS is installed. So I can know when the dbnextrow() workaround should be used instead of dbcanquery(). As far as I can tell, the version only gets exposed through dbversion(), which is a string I'd have to parse. Thanks, Adam From fm at 4js.com Wed Jun 22 10:12:44 2016 From: fm at 4js.com (Fabrice Manfroi) Date: Wed, 22 Jun 2016 16:12:44 +0200 Subject: [freetds] Build error on AIX 6/7 with freeTDS 1.00.6 (current stable) Message-ID: <8dd4964a-1b67-83c9-0f06-5de7b9ba39bd@4js.com> Hello, I'm trying to build the last stable freeTDS sources but it fails with the following compilation errors: tls.c:719: error: 'AF_INET6' undeclared (first use in this function) tls.c:719: error: (Each undeclared identifier is reported only once tls.c:719: error: for each function it appears in.) tls.c:722: error: 'AF_INET' undeclared (first use in this function) It seems that an include of the sys/socket.h header is missing. I propose the attached patch to fix the problem. Best Regards. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-build-error-on-AIX-6.1-7.1-7.2.patch Type: text/x-patch Size: 857 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From freddy77 at gmail.com Wed Jun 22 10:16:28 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Wed, 22 Jun 2016 15:16:28 +0100 Subject: [freetds] Build error on AIX 6/7 with freeTDS 1.00.6 (current stable) In-Reply-To: <8dd4964a-1b67-83c9-0f06-5de7b9ba39bd@4js.com> References: <8dd4964a-1b67-83c9-0f06-5de7b9ba39bd@4js.com> Message-ID: 2016-06-22 15:12 GMT+01:00 Fabrice Manfroi : > Hello, > > I'm trying to build the last stable freeTDS sources but it fails with > the following compilation errors: > > tls.c:719: error: 'AF_INET6' undeclared (first use in this function) > tls.c:719: error: (Each undeclared identifier is reported only once > tls.c:719: error: for each function it appears in.) > tls.c:722: error: 'AF_INET' undeclared (first use in this function) > > It seems that an include of the sys/socket.h header is missing. > > I propose the attached patch to fix the problem. > > Best Regards. > I would prefer the include in the C file. tds.h is included everywhere. Frediano From john at capps.com Wed Jun 22 11:01:05 2016 From: john at capps.com (John Kendall) Date: Wed, 22 Jun 2016 15:01:05 +0000 Subject: [freetds] bcp -n -E fails on identity column Message-ID: <4DD72274-7D03-42D8-9BA3-4DF694D0E8C4@capps.com> My last attempt to report this was a bit muddled. Here's another try. Using version 1.00.6. Using the bcp -n (native file format) and -E (retain identity values) options together produces: Msg 20060, Level 11 Unknown datatype encountered Error in bcp_colfmt col 1 I see this happening on Sybase (11 & 16) and MS SQL 2008. Test to reproduce: select id_col=identity(5) into tempdb..tbl -- Sybase select id_col=identity(int) into tempdb..tbl -- MS SQL $ freebcp tempdb..tbl out tbl.bcp -S $DSQUERY -U usr -P pw -n -E Msg 20060, Level 11 Unknown datatype encountered Error in bcp_colfmt col 1 datacopy also has a problem with the -E option, I assume the problems are related. John From fm at 4js.com Wed Jun 22 10:35:22 2016 From: fm at 4js.com (Fabrice Manfroi) Date: Wed, 22 Jun 2016 16:35:22 +0200 Subject: [freetds] Build error on AIX 6/7 with freeTDS 1.00.6 (current stable) In-Reply-To: References: <8dd4964a-1b67-83c9-0f06-5de7b9ba39bd@4js.com> Message-ID: <72d8fd8d-14d9-a830-ad22-95cf9a99841a@4js.com> No problem. New patch attached. Best Regards. On 06/22/2016 04:16 PM, Frediano Ziglio wrote: > I would prefer the include in the C file. tds.h is included everywhere. -- Fabrice MANFROI -- Four J's Development Tools (www.4js.com) fm at 4js.com - Tel +33 (0)3 88 18 61 20 - Fax +33 (0)3 88 18 61 21 -- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-build-error-on-AIX-6.1-7.1-7.2.patch Type: text/x-patch Size: 814 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From freddy77 at gmail.com Wed Jun 22 11:41:19 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Wed, 22 Jun 2016 16:41:19 +0100 Subject: [freetds] version detection In-Reply-To: References: Message-ID: 2016-06-21 22:45 GMT+01:00 Adam Baratz : > Following up on my pdo_dblib thread, I'd like to be able to detect which > version of FreeTDS is installed. So I can know when the dbnextrow() > workaround should be used instead of dbcanquery(). As far as I can tell, > the version only gets exposed through dbversion(), which is a string I'd > have to parse. > > Thanks, > Adam I don't see another way using dblib calls. You could use some packaging method testing the version. As dbversion just returns a constant string you could just use a function caching the results, like bool check_dbcanquery_works(void) { static bool initialized = false; static bool ok = false; if (!initialized) { const char *version = dbversion(); int maj, min, fix = 0; if (sscanf(version, "freetds v%d.%d.%d", &maj, &min, &fix) >= 2 && ((maj << 24) | (min << 16) | fix) >= 0x01000006) ok = true; initialized = true; } return ok; } Frediano From freddy77 at gmail.com Sat Jun 25 12:13:49 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Sat, 25 Jun 2016 17:13:49 +0100 Subject: [freetds] Build error on AIX 6/7 with freeTDS 1.00.6 (current stable) In-Reply-To: <72d8fd8d-14d9-a830-ad22-95cf9a99841a@4js.com> References: <8dd4964a-1b67-83c9-0f06-5de7b9ba39bd@4js.com> <72d8fd8d-14d9-a830-ad22-95cf9a99841a@4js.com> Message-ID: I'll merge as soon as possible, the patch is good On 22 Jun 2016 17:23, "Fabrice Manfroi" wrote: > No problem. > > New patch attached. > > Best Regards. > > On 06/22/2016 04:16 PM, Frediano Ziglio wrote: > > I would prefer the include in the C file. tds.h is included everywhere. > > -- > Fabrice MANFROI > -- > Four J's Development Tools (www.4js.com) > fm at 4js.com - Tel +33 (0)3 88 18 61 20 - Fax +33 (0)3 88 18 61 21 > -- > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > > From fm at 4js.com Sat Jun 25 13:10:21 2016 From: fm at 4js.com (Fabrice MANFROI) Date: Sat, 25 Jun 2016 19:10:21 +0200 Subject: [freetds] Build error on AIX 6/7 with freeTDS 1.00.6 (current stable) In-Reply-To: References: <8dd4964a-1b67-83c9-0f06-5de7b9ba39bd@4js.com> <72d8fd8d-14d9-a830-ad22-95cf9a99841a@4js.com> Message-ID: <576EBAFD.4090203@4js.com> Thanks! Regards. Le 25/06/2016 18:13, Frediano Ziglio a ?crit : > I'll merge as soon as possible, the patch is good -- Fabrice MANFROI -- Four J's Development Tools (www.4js.com) fm at 4js.com - Tel +33 (0)3 88 18 61 20 - Fax +33 (0)3 88 18 61 21 -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: OpenPGP digital signature URL: From freddy77 at gmail.com Sun Jun 26 03:34:37 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Sun, 26 Jun 2016 08:34:37 +0100 Subject: [freetds] bcp -n -E fails on identity column In-Reply-To: <4DD72274-7D03-42D8-9BA3-4DF694D0E8C4@capps.com> References: <4DD72274-7D03-42D8-9BA3-4DF694D0E8C4@capps.com> Message-ID: 2016-06-22 16:01 GMT+01:00 John Kendall : > My last attempt to report this was a bit muddled. Here's another try. > Using version 1.00.6. > > Using the bcp -n (native file format) and -E (retain identity values) options together produces: > > Msg 20060, Level 11 > Unknown datatype encountered > > Error in bcp_colfmt col 1 > > > I see this happening on Sybase (11 & 16) and MS SQL 2008. > > > Test to reproduce: > > select id_col=identity(5) into tempdb..tbl -- Sybase > select id_col=identity(int) into tempdb..tbl -- MS SQL > > $ freebcp tempdb..tbl out tbl.bcp -S $DSQUERY -U usr -P pw -n -E > Msg 20060, Level 11 > Unknown datatype encountered > > Error in bcp_colfmt col 1 > > datacopy also has a problem with the -E option, I assume the problems are related. > > John > Hi, finally found some time to look at this issue. Basically the sequence become: 1- do a query to get row format 2- initialize bcp 3- do a query for identity inserts 4- fill the bcp columns information with information from step 1. The problem is that the step 3 clear the information needed in step 4. Moving the query at step 1 after 3 (I put after bcp_control and before bcp_columns) fix the issue. Not sure about datacopy. Can you test master (or tomorrow nightly snapshot) ? Frediano From freddy77 at gmail.com Sun Jun 26 03:36:18 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Sun, 26 Jun 2016 08:36:18 +0100 Subject: [freetds] Build error on AIX 6/7 with freeTDS 1.00.6 (current stable) In-Reply-To: <576EBAFD.4090203@4js.com> References: <8dd4964a-1b67-83c9-0f06-5de7b9ba39bd@4js.com> <72d8fd8d-14d9-a830-ad22-95cf9a99841a@4js.com> <576EBAFD.4090203@4js.com> Message-ID: Merged! Frediano 2016-06-25 18:10 GMT+01:00 Fabrice MANFROI : > Thanks! > > Regards. > > Le 25/06/2016 18:13, Frediano Ziglio a ?crit : >> I'll merge as soon as possible, the patch is good > > > -- > Fabrice MANFROI > -- > Four J's Development Tools (www.4js.com) > fm at 4js.com - Tel +33 (0)3 88 18 61 20 - Fax +33 (0)3 88 18 61 21 > -- > > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds > From john at capps.com Sun Jun 26 04:39:33 2016 From: john at capps.com (John Kendall) Date: Sun, 26 Jun 2016 08:39:33 +0000 Subject: [freetds] bcp -n -E fails on identity column In-Reply-To: References: <4DD72274-7D03-42D8-9BA3-4DF694D0E8C4@capps.com> Message-ID: > On Jun 26, 2016, at 12:34 AM, Frediano Ziglio wrote: > > 2016-06-22 16:01 GMT+01:00 John Kendall : >> My last attempt to report this was a bit muddled. Here's another try. >> Using version 1.00.6. >> >> Using the bcp -n (native file format) and -E (retain identity values) options together produces: >> >> Msg 20060, Level 11 >> Unknown datatype encountered >> >> Error in bcp_colfmt col 1 >> >> >> I see this happening on Sybase (11 & 16) and MS SQL 2008. >> >> >> Test to reproduce: >> >> select id_col=identity(5) into tempdb..tbl -- Sybase >> select id_col=identity(int) into tempdb..tbl -- MS SQL >> >> $ freebcp tempdb..tbl out tbl.bcp -S $DSQUERY -U usr -P pw -n -E >> Msg 20060, Level 11 >> Unknown datatype encountered >> >> Error in bcp_colfmt col 1 >> >> datacopy also has a problem with the -E option, I assume the problems are related. >> >> John >> > > Hi, > finally found some time to look at this issue. > > Basically the sequence become: > 1- do a query to get row format > 2- initialize bcp > 3- do a query for identity inserts > 4- fill the bcp columns information with information from step 1. > The problem is that the step 3 clear the information needed in step 4. > Moving the query at step 1 after 3 (I put after bcp_control and before > bcp_columns) fix the issue. Not sure about datacopy. > > Can you test master (or tomorrow nightly snapshot) ? > > Frediano That fixed the bcp out, but if I then truncate the table and try to copy back into it I get (with Sybase 11 & 16): freebcp tempdb..tbl in tbl.bcp -S $DSQUERY -U usr -P pw -n -E Starting copy... Msg 20219, Level 4 Internal Conversion error Msg 20219, Level 4 Internal Conversion error Msg 20219, Level 4 Internal Conversion error Msg 20219, Level 4 Internal Conversion error Msg 20219, Level 4 Internal Conversion error Msg 20219, Level 4 Internal Conversion error Msg 20219, Level 4 Internal Conversion error Msg 20219, Level 4 Internal Conversion error Msg 20219, Level 4 Internal Conversion error Msg 20219, Level 4 Internal Conversion error Msg 20219, Level 4 Internal Conversion error bcp copy in failed From freddy77 at gmail.com Mon Jun 27 06:23:45 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Mon, 27 Jun 2016 11:23:45 +0100 Subject: [freetds] bcp -n -E fails on identity column In-Reply-To: References: <4DD72274-7D03-42D8-9BA3-4DF694D0E8C4@capps.com> Message-ID: Now I remember the "fix binary file for freebcp" in https://trello.com/b/bk0UZNRJ/freetds-todo-list ! Basically NUMERIC is written as TDS_NUMERIC and read is completely missing and buggy ! Actually not sure what the dump should contain. Can you use bcp (native Ms/Sybase) to dump a file with mssql/sybase? Frediano 2016-06-26 9:39 GMT+01:00 John Kendall : > >> On Jun 26, 2016, at 12:34 AM, Frediano Ziglio wrote: >> >> 2016-06-22 16:01 GMT+01:00 John Kendall : >>> My last attempt to report this was a bit muddled. Here's another try. >>> Using version 1.00.6. >>> >>> Using the bcp -n (native file format) and -E (retain identity values) options together produces: >>> >>> Msg 20060, Level 11 >>> Unknown datatype encountered >>> >>> Error in bcp_colfmt col 1 >>> >>> >>> I see this happening on Sybase (11 & 16) and MS SQL 2008. >>> >>> >>> Test to reproduce: >>> >>> select id_col=identity(5) into tempdb..tbl -- Sybase >>> select id_col=identity(int) into tempdb..tbl -- MS SQL >>> >>> $ freebcp tempdb..tbl out tbl.bcp -S $DSQUERY -U usr -P pw -n -E >>> Msg 20060, Level 11 >>> Unknown datatype encountered >>> >>> Error in bcp_colfmt col 1 >>> >>> datacopy also has a problem with the -E option, I assume the problems are related. >>> >>> John >>> >> >> Hi, >> finally found some time to look at this issue. >> >> Basically the sequence become: >> 1- do a query to get row format >> 2- initialize bcp >> 3- do a query for identity inserts >> 4- fill the bcp columns information with information from step 1. >> The problem is that the step 3 clear the information needed in step 4. >> Moving the query at step 1 after 3 (I put after bcp_control and before >> bcp_columns) fix the issue. Not sure about datacopy. >> >> Can you test master (or tomorrow nightly snapshot) ? >> >> Frediano > > That fixed the bcp out, but if I then truncate the table and try to copy back into it I get (with Sybase 11 & 16): > > freebcp tempdb..tbl in tbl.bcp -S $DSQUERY -U usr -P pw -n -E > > Starting copy... > > Msg 20219, Level 4 > Internal Conversion error > > Msg 20219, Level 4 > Internal Conversion error > > Msg 20219, Level 4 > Internal Conversion error > > Msg 20219, Level 4 > Internal Conversion error > > Msg 20219, Level 4 > Internal Conversion error > > Msg 20219, Level 4 > Internal Conversion error > > Msg 20219, Level 4 > Internal Conversion error > > Msg 20219, Level 4 > Internal Conversion error > > Msg 20219, Level 4 > Internal Conversion error > > Msg 20219, Level 4 > Internal Conversion error > > Msg 20219, Level 4 > Internal Conversion error > > bcp copy in failed > > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From freddy77 at gmail.com Mon Jun 27 08:12:58 2016 From: freddy77 at gmail.com (Frediano Ziglio) Date: Mon, 27 Jun 2016 13:12:58 +0100 Subject: [freetds] bcp -n -E fails on identity column In-Reply-To: References: <4DD72274-7D03-42D8-9BA3-4DF694D0E8C4@capps.com> Message-ID: Fixed Frediano 2016-06-26 9:39 GMT+01:00 John Kendall : > >> On Jun 26, 2016, at 12:34 AM, Frediano Ziglio wrote: >> >> 2016-06-22 16:01 GMT+01:00 John Kendall : >>> My last attempt to report this was a bit muddled. Here's another try. >>> Using version 1.00.6. >>> >>> Using the bcp -n (native file format) and -E (retain identity values) options together produces: >>> >>> Msg 20060, Level 11 >>> Unknown datatype encountered >>> >>> Error in bcp_colfmt col 1 >>> >>> >>> I see this happening on Sybase (11 & 16) and MS SQL 2008. >>> >>> >>> Test to reproduce: >>> >>> select id_col=identity(5) into tempdb..tbl -- Sybase >>> select id_col=identity(int) into tempdb..tbl -- MS SQL >>> >>> $ freebcp tempdb..tbl out tbl.bcp -S $DSQUERY -U usr -P pw -n -E >>> Msg 20060, Level 11 >>> Unknown datatype encountered >>> >>> Error in bcp_colfmt col 1 >>> >>> datacopy also has a problem with the -E option, I assume the problems are related. >>> >>> John >>> >> >> Hi, >> finally found some time to look at this issue. >> >> Basically the sequence become: >> 1- do a query to get row format >> 2- initialize bcp >> 3- do a query for identity inserts >> 4- fill the bcp columns information with information from step 1. >> The problem is that the step 3 clear the information needed in step 4. >> Moving the query at step 1 after 3 (I put after bcp_control and before >> bcp_columns) fix the issue. Not sure about datacopy. >> >> Can you test master (or tomorrow nightly snapshot) ? >> >> Frediano > > That fixed the bcp out, but if I then truncate the table and try to copy back into it I get (with Sybase 11 & 16): > > freebcp tempdb..tbl in tbl.bcp -S $DSQUERY -U usr -P pw -n -E > > Starting copy... > > Msg 20219, Level 4 > Internal Conversion error > > Msg 20219, Level 4 > Internal Conversion error > > Msg 20219, Level 4 > Internal Conversion error > > Msg 20219, Level 4 > Internal Conversion error > > Msg 20219, Level 4 > Internal Conversion error > > Msg 20219, Level 4 > Internal Conversion error > > Msg 20219, Level 4 > Internal Conversion error > > Msg 20219, Level 4 > Internal Conversion error > > Msg 20219, Level 4 > Internal Conversion error > > Msg 20219, Level 4 > Internal Conversion error > > Msg 20219, Level 4 > Internal Conversion error > > bcp copy in failed > > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From stu at spacehopper.org Tue Jun 28 17:19:52 2016 From: stu at spacehopper.org (Stuart Henderson) Date: Tue, 28 Jun 2016 21:19:52 +0000 (UTC) Subject: [freetds] sqsh build fails with FreeTDS 1.0 Message-ID: sqsh build is failing with newer FreeTDS. There's an easily fixed CS_TDS_80 that can be replaced with CS_TDS_71, but when that's done I run into this in src/dsp_conv.c: /* * Take the existing format and strip it down according to the * type of date that we are processing and replace the ms * field if it exists. */ #if defined(CS_BIGDATETIME_TYPE) && defined(CS_BIGTIME_TYPE) if (dt_fmt->datatype == CS_BIGDATETIME_TYPE || dt_fmt->datatype == CS_BIGTIME_TYPE) fmt = dsp_datetime_strip( dt_fmt->datatype, conv_fmt, (int) dr.datesecfrac ); else #endif fmt = dsp_datetime_strip( dt_fmt->datatype, conv_fmt, (int) dr.datemsecond ); - CS_BIGDATETIME_TYPE etc are now defined, but the structure doesn't include datesecfrac: dsp_conv.c: In function 'dsp_datetime_conv': dsp_conv.c:665: error: 'CS_DATEREC' has no member named 'datesecfrac' Any suggestions for a better fix than just #if 0'ing it out? Thanks. From ikorot01 at gmail.com Wed Jun 29 10:42:47 2016 From: ikorot01 at gmail.com (Igor Korot) Date: Wed, 29 Jun 2016 10:42:47 -0400 Subject: [freetds] sqsh build fails with FreeTDS 1.0 In-Reply-To: References: Message-ID: Hi, Stuart, On Tue, Jun 28, 2016 at 5:19 PM, Stuart Henderson wrote: > sqsh build is failing with newer FreeTDS. There's an easily fixed > CS_TDS_80 that can be replaced with CS_TDS_71, but when that's done > I run into this in src/dsp_conv.c: What is you OS? What is you configure line? What is the exact error message you received? Thank you. > > /* > * Take the existing format and strip it down according to the > * type of date that we are processing and replace the ms > * field if it exists. > */ > #if defined(CS_BIGDATETIME_TYPE) && defined(CS_BIGTIME_TYPE) > if (dt_fmt->datatype == CS_BIGDATETIME_TYPE || dt_fmt->datatype == CS_BIGTIME_TYPE) > fmt = dsp_datetime_strip( dt_fmt->datatype, conv_fmt, (int) dr.datesecfrac ); > else > #endif > fmt = dsp_datetime_strip( dt_fmt->datatype, conv_fmt, (int) dr.datemsecond ); > > > - CS_BIGDATETIME_TYPE etc are now defined, but the structure > doesn't include datesecfrac: > > dsp_conv.c: In function 'dsp_datetime_conv': > dsp_conv.c:665: error: 'CS_DATEREC' has no member named 'datesecfrac' > > Any suggestions for a better fix than just #if 0'ing it out? > Thanks. > > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From merlereinhart at mac.com Wed Jun 29 11:43:47 2016 From: merlereinhart at mac.com (Merle Reinhart) Date: Wed, 29 Jun 2016 11:43:47 -0400 Subject: [freetds] sqsh build fails with FreeTDS 1.0 In-Reply-To: References: Message-ID: <91F31C50-6994-42E1-8F74-F9176B6EB81D@mac.com> I ran into this even before FreeTDS 1.0 when I was trying to check out some of the features of 7.2 and 7.3 via sqsh. Here was what I patched to let those tds versions pass through. Basically, I just removed 8.0 and added the 7.x subversions since I knew that was coming. This was quick and dirty, so it is very possible there may be other changes that really should be made, but this will get it to build (at least on Mac OS X). I never got a chance to get back to it to verify if there were other changes or not, so I never passed this upstream to the sqsh folks. Merle --- src/cmd_connect.c.orig 2014-04-04 04:22:38.000000000 -0400 +++ src/cmd_connect.c 2015-12-02 17:22:42.000000000 -0500 @@ -860,8 +860,12 @@ /* Then we use freetds which uses enum instead of defines */ else if (strcmp(tds_version, "7.0") == 0) version = CS_TDS_70; - else if (strcmp(tds_version, "8.0") == 0) - version = CS_TDS_80; + else if (strcmp(tds_version, "7.1") == 0) + version = CS_TDS_71; + else if (strcmp(tds_version, "7.2") == 0) + version = CS_TDS_72; + else if (strcmp(tds_version, "7.3") == 0) + version = CS_TDS_73; #endif else version = CS_TDS_50; /* default version */ @@ -1258,8 +1262,14 @@ case CS_TDS_70: env_set( g_env, "tds_version", "7.0" ); break; - case CS_TDS_80: - env_set( g_env, "tds_version", "8.0" ); + case CS_TDS_71: + env_set( g_env, "tds_version", "7.1" ); + break; + case CS_TDS_72: + env_set( g_env, "tds_version", "7.2" ); + break; + case CS_TDS_73: + env_set( g_env, "tds_version", "7.3" ); break; #endif default: --- doc/sqsh.pod.orig 2014-03-12 10:19:43.000000000 -0400 +++ doc/sqsh.pod 2015-12-02 17:24:44.000000000 -0500 @@ -145,12 +145,13 @@ =item -G tds_version Set the TDS version to use. Valid versions are 4.0, 4.2, 4.6, 4.9.5, 5.0 and -freetds additionally supports versions 7.0 and 8.0. The specified value is -assigned to the variable B<$tds_version>. Input validation is not performed by -sqsh. However, when an invalid TDS version is specified, the default version of -5.0 will be used. After a session is setup, the variable B<$tds_version> will be -set to the TDS version in effect. The variable will not be available if option --G is not used. Meant for test and debugging purposes only. +freetds additionally supports versions 7.0, 7.1, 7.2 and 7.3. The specified +value is assigned to the variable B<$tds_version>. Input validation is not +performed by sqsh. However, when an invalid TDS version is specified, the +default version of 5.0 will be used. After a session is setup, the variable +B<$tds_version> will be set to the TDS version in effect. The variable will not +be available if option -G is not used. Meant for test and debugging purposes +only. TDS stands for Tabular Data Stream and is the communication protocol Sybase and Microsoft uses for Client-Server communication. > On Jun 28, 2016, at 5:19 PM, Stuart Henderson wrote: > > sqsh build is failing with newer FreeTDS. There's an easily fixed > CS_TDS_80 that can be replaced with CS_TDS_71, but when that's done > I run into this in src/dsp_conv.c: > > /* > * Take the existing format and strip it down according to the > * type of date that we are processing and replace the ms > * field if it exists. > */ > #if defined(CS_BIGDATETIME_TYPE) && defined(CS_BIGTIME_TYPE) > if (dt_fmt->datatype == CS_BIGDATETIME_TYPE || dt_fmt->datatype == CS_BIGTIME_TYPE) > fmt = dsp_datetime_strip( dt_fmt->datatype, conv_fmt, (int) dr.datesecfrac ); > else > #endif > fmt = dsp_datetime_strip( dt_fmt->datatype, conv_fmt, (int) dr.datemsecond ); > > > - CS_BIGDATETIME_TYPE etc are now defined, but the structure > doesn't include datesecfrac: > > dsp_conv.c: In function 'dsp_datetime_conv': > dsp_conv.c:665: error: 'CS_DATEREC' has no member named 'datesecfrac' > > Any suggestions for a better fix than just #if 0'ing it out? > Thanks. > > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/freetds From stu at spacehopper.org Thu Jun 30 09:16:18 2016 From: stu at spacehopper.org (Stuart Henderson) Date: Thu, 30 Jun 2016 13:16:18 +0000 (UTC) Subject: [freetds] sqsh build fails with FreeTDS 1.0 References: Message-ID: On 2016-06-29, Merle Reinhart wrote: > I ran into this even before FreeTDS 1.0 when I was trying to check out > some of the features of 7.2 and 7.3 via sqsh. Yes, that's the easily-fixed one I mentioned. On 2016-06-29, Igor Korot wrote: > Hi, Stuart, > > On Tue, Jun 28, 2016 at 5:19 PM, Stuart Henderson wrote: >> sqsh build is failing with newer FreeTDS. There's an easily fixed >> CS_TDS_80 that can be replaced with CS_TDS_71, but when that's done >> I run into this in src/dsp_conv.c: > > What is you OS? What is you configure line? What is the exact error > message you received? OS is OpenBSD/amd64 -current (not that it's relevant in this case), and I showed the exact error message: >> dsp_conv.c: In function 'dsp_datetime_conv': >> dsp_conv.c:665: error: 'CS_DATEREC' has no member named 'datesecfrac' freetds-1.00.9/include/cspublic.h now lists new bind types e.g. 581:#define CS_BIGDATETIME_TYPE TDS_STATIC_CAST(CS_INT, 35) The code in dsp_conv.c does this: >> /* >> * Take the existing format and strip it down according to the >> * type of date that we are processing and replace the ms >> * field if it exists. >> */ >> #if defined(CS_BIGDATETIME_TYPE) && defined(CS_BIGTIME_TYPE) >> if (dt_fmt->datatype == CS_BIGDATETIME_TYPE || dt_fmt->datatype == CS_BIGTIME_TYPE) >> fmt = dsp_datetime_strip( dt_fmt->datatype, conv_fmt, (int) dr.datesecfrac ); >> else >> #endif >> fmt = dsp_datetime_strip( dt_fmt->datatype, conv_fmt, (int) dr.datemsecond ); dr is a CS_DATEREC struct, but the definition in cstypes.h doesn't have datesecfrac and datesecprec fields so it's clear why the error occurs. Perhaps the better fix would be for FreeTDS to add them to the struct and cs_dt_crack(). http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.infocenter.dc20155.1550/html/newfesd/newfesd48.htm