Transaction-test (EndTran) fails on Linux

[GoogleCodeExporter]

I am not sure this is actually a problem of odbc, it might be a freetds thing 
but I'm not capable enough to find out.

What steps will reproduce the problem?
1. go test -run TestMSSQLTransactions

What do you see instead?
The test blocks until the test runtime terminates it after 10 minutes.
It blocks in zapi_unix.go on line 64:
r := C.SQLEndTran(C.SQLSMALLINT(handleType), C.SQLHANDLE(handle), 
C.SQLSMALLINT(completionType))

What version of the product are you using? On what operating system?
DB Server:
MS-SQL 2008 server, empty database.
Client:
Linux (Debian Wheezy, 64 bit), unixodbc (2.2.14p2-5) and freetds (0.91-2).

Please provide any additional information below.
I can provide access details to the server I used to test it with (on 24/7). If 
it would help, I could also probably provide ssh access to the client machine.

Original issue reported on code.google.com by gov...@ver.slu.is on 21 Aug 2013 at 5:14

[GoogleCodeExporter]

I think, you might be right about this could be to do with freetds. I don't 
have MS-SQL 2008 to try it here. I will try to find one and see if it works 
with windows client. 

Blocking in C.SQLEndTran indicates that something is not right in freeetds. 
Perhaps, you can rewrite this test in a different language to try and see, if 
you get similar problem.

I don't know what to do, I will think about it more when I have more time.

Alex

Original comment by alex.bra...@gmail.com on 22 Aug 2013 at 7:29

• Changed state: Accepted

[GoogleCodeExporter]

I will send you the access details to my SQL server should you want to use it.

In the meantime I will try out the code on a Windows machine too and I will see 
if I can run this test in another language as well. I'm not used to writing 
odbc on Linux at all though.

Original comment by gov...@ver.slu.is on 22 Aug 2013 at 9:00

[GoogleCodeExporter]

Just tried running tests against your server and, while it is slow, everything 
works:

# go test -run=MS -v ...
=== RUN TestMSSQLCreateInsertDelete
--- PASS: TestMSSQLCreateInsertDelete (21.41 seconds)
=== RUN TestMSSQLTransactions
--- PASS: TestMSSQLTransactions (30.96 seconds)
=== RUN TestMSSQLTypes
--- PASS: TestMSSQLTypes (144.92 seconds)
=== RUN TestMSSQLIntAfterText
--- PASS: TestMSSQLIntAfterText (3.61 seconds)
=== RUN TestMSSQLStmtAndRows
--- PASS: TestMSSQLStmtAndRows (32.49 seconds)
=== RUN TestMSSQLIssue5
--- PASS: TestMSSQLIssue5 (32.13 seconds)
=== RUN TestMSSQLDeleteNonExistent
--- PASS: TestMSSQLDeleteNonExistent (7.86 seconds)
PASS
ok      code.google.com/p/odbc  273.392s

I am using linux-386 system with freetds-0.91 and unixODBC-2.3.1. I am out of 
ideas what could be wrong with your system. You said it blocks in C.SQLEndTran, 
perhaps you could see what happens there - maybe look at SQL Server for any 
transaction locks that holding your connection, alternatively step inside 
C.SQLEndTran with gdb. Unfortunately, I am not clear myself about the plan.

Thank you for providing access to investigate, you saved me the hassle. I have 
another SQL Server 2008 issue to resolve 
(http://code.google.com/p/odbc/issues/detail?id=14). Would it be OK for me to 
run it against your system?

Alex

Original comment by alex.bra...@gmail.com on 23 Aug 2013 at 12:03

[GoogleCodeExporter]

Thanks a bunch for testing this yourself with similar versions.
I'll have more time to investigate this myself later today.

I've become convinced it is a bug in either freetds or unixodbc. I've set up 
another unrelated linux-machine (Ubuntu this time) and I'm having the same 
issues. The only difference is that freetds is one version lower than with 
Debian (0.91-1build1).
My next step is to try and upgrade unixODBC to 2.3.1 and see what that gives.
Unfortunately, even though 2.3.1 is out since 2011, even sid doesn't have it 
yet.

Please, by all means, feel free to use that database whenever you need. It 
doesn't cost me anything extra to have that database running so I'll keep it 
online as long as I keep the server.

Govert

Original comment by gov...@ver.slu.is on 23 Aug 2013 at 9:56

[GoogleCodeExporter]

I can confirm that the problem is in unixodbc. After manually building 2.3.1 on 
my system all the tests run succesfully.

Thanks for your time and I apologize for having wasted it.

Govert

Original comment by gov...@ver.slu.is on 24 Aug 2013 at 12:15

[GoogleCodeExporter]

Glad you can run it now.

Alex

Original comment by alex.bra...@gmail.com on 25 Aug 2013 at 8:51

• Changed state: Done