Re: tsql script problems

"Tony Baldarelli" <[email protected]>
Newsgroups gmane.comp.db.tds.freetds
Message-ID <019301cbf86b$9fa28b10$dee7a130$@com>
Ok, I fixed it by using openssl ( instead of gnutls ) with
freetds-0.91.dev.20110409RC1 ( from
http://www.ibiblio.org/pub/Linux/ALPHA/freetds/stable/release_candidates/fre
etds-0.91rc1.tgz ), and then I replaced the challenge.c file with the one
Frediano told me to use to get compilation to work
(http://freetds.cvs.sourceforge.net/viewvc/freetds/freetds/src/tds/challenge
.c?revision=1.47.2.1 ).  So far I have not run into any problems.

So, openssl works fine, but it seems the below problem occurs with gnuTLS.
I am fine using openssl, but just wanted people to know my final conclusion.

Thanks for your time.

 
Tony


-----Original Message-----
From: Tony Baldarelli [mailto:[email protected]] 
Sent: Sunday, April 10, 2011 5:31 PM
To: 'FreeTDS Development Group'
Subject: RE: [freetds] tsql script problems

Note that I am able to repeat the situations below with freetds-0.82,
freetds-0.82.1.dev.20110409, and freetds-0.91.dev.20110409RC1.  0.91 gives
me a slightly different error, but the results are the same.  Here are the
errors for 0.91:
	[tonyb:v9_odbc:V3_18]> tsql -C
	Compile-time settings (established with the "configure" script)
	                            Version: freetds v0.91.dev.20110409RC1
      	       freetds.conf directory: /usr/local/etc
	     MS db-lib source compatibility: no
      	  Sybase binary compatibility: no
            	          Thread safety: yes
                  	    iconv library: yes
	                        TDS version: 5.0
      	                        iODBC: no
            	               unixodbc: yes
	              SSPI "trusted" logins: no
      	                     Kerberos: no
	[tonyb:v9_odbc:V3_18]> sql < testMBOCount.sql 
	locale is "en_US"
	locale charset is "ISO-8859-1"
	using default charset "ISO-8859-1"
	Warning: using insecure memory!
	1> 2> 3> 
	3614
	(1 row affected)
	1> 
	[tonyb:v9_odbc:V3_18]> sql < tempMBO.sql      
	locale is "en_US"
	locale charset is "ISO-8859-1"
	using default charset "ISO-8859-1"
	Warning: using insecure memory!
	Error 20004 (severity 9):
	        Read from the server failed
	        OS error 104, "Connection reset by peer"
	1> 2> 3> 4> 5> 6> 7> 8> 9> 10> 11> 12> 13> 14> 15> 16> 17> 18> 19>
20> 21> 22> 23> 24> 25> 26> 27> 28> 29> 30> 31> 32> 33> 34> 35> 36> 37> 38>
39> 40> 41> 42> 43> 44> 45> 46> 47> 48> 49> 50> 51> 52> 53> 54> 55> 56> 57>
58> 59> 60> 61> 62> 63> 64> 65> 66> 67> 68> 69> 70> 71> 72> 73> 74> 75> 1>

Note that with 0.91, I get the "using insecure memory" error as well, which
is kind of weird.

 
Tony


-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Tony Baldarelli
Sent: Friday, April 08, 2011 7:38 PM
To: 'FreeTDS Development Group'
Subject: [freetds] tsql script problems

Hello,

                I have a simple SQL script that works without incident:

[tonyb:v9_odbc:V3_18]> tsql -S MyServer2005 -U <user id removed for
security> -P <password removed for security> << EOF

> select count(*) from mbo;

> go

> EOF

locale is "en_US"

locale charset is "ISO-8859-1"

1> 2> 

3614

(1 row affected)

1> [tonyb:v9_odbc:V3_18]>

 

See below for the logs:

1.       Development machine #1 log file: http://goo.gl/n4ZYU

2.       Development machine #1 TDSDUMP output: http://goo.gl/JCsrA 

3.       Development machine #2 log file: http://goo.gl/xuosy 

4.       Development machine #2 TDSDUMP output: http://goo.gl/4FaIJ

 

 

But then I have a more complex one that gives me an error on the machines
using a newer version of tsql ( 0.82 ), using GNUTLS for SSL encryption.
The error I get is here:

+ tsql -S MyServer2005 -U nortel -P builder789

locale is "en_US"

locale charset is "ISO-8859-1"

^MMsg 20004, Level 9, State -1, Server OpenClient, Line -1

Read from the server failed

locale is "en_US"

locale charset is "ISO-8859-1"

1> 2> 3> 4> 5> 6> 7> 8> 9> 10> 11> 12> 13> 14> 15> 16> 17> 18> 19> 20> 21>
22> 23> 24> 25> 26> 27> 28> 29> 30> 31> 32> 33> 34> 35> 36> 37> 38> 39> 40>
41> 42> 43> 44> 45> 46> 47> 48> 49> 50> 51> 52> 53> 54> 55> 56> 57> 58> 59>
60> 61> 62> 63> 64> 65> 66> 67> 68> 69> 70> 71> 72> 73> 74> 75> 1>

 

This SQL works on another machine that uses a different version of tsql (
albeit accessing a different SQL Server, with SSL off ).

1.       Development machine #1 log file: http://goo.gl/StfNy 

2.       Development machine #1 TDSDUMP output: http://goo.gl/7D3wH 

3.       Development machine #2 log file: http://goo.gl/xYXWo 

4.       Development machine #2 TDSDUMP output: http://goo.gl/CVXOm 

5.       Production machine log file: http://goo.gl/KeLaX 

6.       Production machine TDSDUMP output: http://goo.gl/vOXTa

 

I mention the production server only because the exact same SQL script works
there.  So the problem is not the SQL script itself.  It is something with
tsql.  I suspect it is something with gnuTLS, based on the TDSDUMP file, but
that is just a guess.

 

I am currently waiting for a patch that should let me use openssl instead of
gnuTLS, but I need to attach this issue from all angles in case the openssl
option does not work.  Thus my trying to get gnuTLS to work.  Thanks for
your help.

 

 

Tony

 

_______________________________________________
FreeTDS mailing list
[email protected]
http://lists.ibiblio.org/mailman/listinfo/freetds
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.