-
We could always switch the Calendar instance in ConnectionJDBC2.java to a private static ThreadLocal which should mirror the behaviour in 1.2.4. 1.2.2 did not use ThreadLocal, which was only introduced in 1.2.3 to fix issue 1955499.
Is there any particular facet of the patch that you are concerned about, or are you just not 100% confident until more tests are passed?
I'll try and get started...
2009-11-11 00:06:13 UTC in jTDS - SQL Server and Sybase JDBC driver
-
Sorry I didn't realise I wasn't logged in. The previous comment was made by me.
2009-11-10 01:12:54 UTC in jTDS - SQL Server and Sybase JDBC driver
-
What is the current status of this proposed patch?.
2009-11-06 07:03:12 UTC in jTDS - SQL Server and Sybase JDBC driver
-
I just came across patch ID 2731952
https://sourceforge.net/tracker/?func=detail&aid=2731952&group_id=33291&atid=407764
which the submitter claims to have overcome this problem. However, it seems the patch hasn't been accepted, and it was also targeted for version 1.2.2, which of course is now obsolete.
I'll have to download 1.2.2 and apply the changes to that version and give my opinion on...
2009-11-06 06:53:04 UTC in jTDS - SQL Server and Sybase JDBC driver
-
I ran the supplied unit test with 1.2.4 and it fails on
CSUnitTest.testDataTypes0027() wtih the error message
Testcase: testDataTypes0027(net.sourceforge.jtds.test.CSUnitTest): Caused an ERROR
Numeric overflow in conversion of value 200 to type TINYINT.
java.sql.SQLException: Numeric overflow in conversion of value 200 to type TINYINT.
This is because the value 200 is not a valid java...
2009-11-06 04:46:24 UTC in jTDS - SQL Server and Sybase JDBC driver
-
Proposed solution:
Have net.sourceforge.jtds.jdbc.Support, always use a Calendar that has a TimeZone that can support all possible date/times. The simplest one would be the GMT timezone.
This will require code handling the new Timestamp object further down the track e.g. net.sourceforge.jtds.jdbc.DateTime will also have to use a Calendar object with the GMT timezone. We will have to watch out...
2009-11-05 14:13:26 UTC in jTDS - SQL Server and Sybase JDBC driver
-
Are there any plans to work on this bug? No matter what arguments you put forward about impacting performance, the fact remains that jtds doesn't satisfy the contract put forward in the description of Statement.setMaxRows().
Like nielsg, we have an adhoc querying tool and this is causing problems when a user tries to delete/update more rows than our default max rows (usually 5000).
2009-11-05 00:27:30 UTC in jTDS - SQL Server and Sybase JDBC driver
-
Just to clarify I'm not a developer on this project, just a user. I was trying to point you in the right direction with regards to your usage of the driver
I do agree with you about the timestamp. However, jtds doesn't do it this way - the problem lies in the fact they use a Calendar with the local timezone to create their own internal DateTime class as you have highlighted. I don't think they...
2009-11-04 14:44:17 UTC in jTDS - SQL Server and Sybase JDBC driver
-
Your comment of
"When the drivers takes the time stamps and tries to get the year, month,
day, hour, minutes, seconds it must use UTC/GMT as time zone
and not the local one."
is only correct if you want your dates to be stored in UTC/GMT. This is not always the timezone required by the user of the database. if you require the dates to be stored in UTC/GMT, you should always use...
2009-11-04 05:49:46 UTC in jTDS - SQL Server and Sybase JDBC driver
-
JtdsCallableStatement is a subclass of JtdsPreparedStatement and calls JtdsPreparedStatement.setTimestamp().
After re-reading the details, I think the problem may lie in the retrieval of the data. Assuming that you are using SQL Server, the date/time columns do not store any TimeZone information. Hence when you retrieve the date-time using Statement.getTimestamp, you should use the overloaded...
2009-11-03 23:59:42 UTC in jTDS - SQL Server and Sybase JDBC driver
