-
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
-
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
-
Related to
JtdsPreparedStatement setTime setTimestamp Daylight DST Bug - ID: 1176221
https://sourceforge.net/tracker/index.php?func=detail&aid=1176221&group_id=33291&atid=407762
Some background:
1. Our application stores all our dates in GMT. Hence when we insert dates using a PreparedStatement we use the method public void setTimestamp(int parameterIndex, Timestamp x, Calendar cal...
2009-10-28 03:18:48 UTC in jTDS - SQL Server and Sybase JDBC driver
