I have strange effects when retrieving columns of type DATE from SQLServer2008 using the Microsoft JDBC-Driver version 3.0 when running under the official Oracle JDK 1.7.0. Host OS is Windows Server 2003.
All Date columns are retrieved as two days in the past with respect to the value actually stored in the column.
I cooked up a minimal code example the test this out (Test table and data):
CREATE TABLE Java7DateTest (
dateColumn DATE
);
INSERT INTO Java7DateTest VALUES('2011-10-10');
Code:
public class Java7SQLDateTest {
public static void main(final String[] argv) {
try {
Class.forName("com.microsoft.sqlserver.jdbc.SQLServerDriver");
Connection connection = DriverManager.getConnection(
"jdbc:sqlserver://192.168.0.1:1433;databaseName=dbNameHere",
"user", "password");
PreparedStatement statement = connection.prepareStatement("SELECT * FROM Java7DateTest");
ResultSet resultSet = statement.executeQuery();
while (resultSet.next()) {
final java.sql.Date date = resultSet.getDate("dateColumn");
final String str = resultSet.getString("dateColumn");
System.out.println(date + " (raw: " + str + ")");
}
resultSet.close();
statement.close();
connection.close();
} catch (final Throwable t) {
throw new RuntimeException(t.getMessage(), t);
}
}
}
Running this code on above configuration prints: "2011-10-08 (raw: 2011-10-08)".
Under JRE 1.6.0_27 it prints: "2011-10-10 (raw: 2011-10-10)"
I could not find anything that seems to relate to my problem with google, so I'm assuming that its either something stupid I overlooked or nobody is using Java7 yet.
Can anybody confirm this problem? What are my alternatives if I still want to use Java7?
Edit: The problem occurs even when running with -Xint, so its not caused by Hotspot bugs.
Edit2: Old drivers (Microsoft 1.28) work properly with JDK1.7.0 (we were using that driver until maybe two years ago, I think).
jTDS also works perfectly fine with the example. I am considering switching to jTDS, but I am reluctant to do so because I have not the faintest idea what the effects on our productive environment may be. Ideally it should just work, but that what I believed when I switched my dev box to Java7, too.
There is one pretty fat database in the production environment, that is too big to create a copy of, for testing (or rather our server has so little disk left). So setting up a test environment for that one app is not straigthforward, I would have to stitch up a shrinked database for that.
Edit3: jTDS has its own set of catches attached. I found a behavioral difference that breaks one of our applications. ResultSet.getObject() returns different object types for SmallInt columns depending on driver (Short vs Integer). Also jTDS does not implement JDBC4 Connection interface, Connect.isValid() is not supported.
Edit4: I noticed last week that MSSQL-JDBC 3.0 refuses to connect to any DB after I updated to JDK1.6.0_29. jTDS it is then... we switched the productive server yesterday (I fixed tow places where the application was relying on peculiarities of the driver), and so far we had have no problems.
Thank you for your feedback. The Microsoft JDBC Driver for SQL Server does not yet support JRE 1.7.
We are aware of the getDate issue between our JDBC driver & JRE 1.7 and we are looking into publishing a hotfix to enable customers to move forward with non-production testing of our driver with JRE 1.7.
We will publish a link to the hotfix on our blog once available.
http://blogs.msdn.com/b/jdbcteam/
The hotfix is now available. http://blogs.msdn.com/b/jdbcteam/archive/2012/01/20/hotfix-available-for-date-issue-when-using-jre-1-7.aspx
Our blog also contains information on the known issues with JRE 1.6u29 & 1.6u30.
Shamitha Reddy
Program Manager - Microsoft JDBC Driver for SQL Server
I don't quite have an answer for you. But, I've recreated your situation as you described. It is the same with the jdbc driver v3.101 and v3.202 and v4.ctp3 when run under jdk1.7. However, the v2 driver from MS gives your expected answer both under jdk1.6 and jdk1.7. If you need a quick fix and can move to an older jdbc driver, that may work for you.
Other thoughts are on how the MS jdbc driver handles dates and conversion of Date objects between SQL Server and the jvm. Since the storage of the date is without a time zone, the interpretation of the Date object by the driver is based on the default time zone for the machine running the jdbc driver. For instance, if you store a smalldate of '2011-10-11 12:00' and retrieve it from a machine with the default time zone set to GMT-7 then the resulting UTC time of the Date object would be '2011-10-11 19:00'. It could be that there is some change in jdk1.7 that impacts this conversion process in the driver resulting in a wild offset. You might experiment with the ResultSet.getDate(column, Calendar) method to see if a Calendar with a specific time zone gets you the result you want or helps make sense of why you are seeing the strange offset in the conversion.
I don't have a SQL Server setup, but I can't reproduce your problem with PostgreSQL 9.0 and MySQL 5.1 on Windows 7 x64 with JDK 1.7.0. So JDK 1.7.0 can be excluded from being suspect. I have the impression that the SQL Server JDBC driver is to blame here. I'd suggest to use the jTDS JDBC driver instead. It has always been praised for its better performance and stability as opposed to the MS-provided SQL Server JDBC driver.
Information and download link for the hotpatch from Microsoft Support can be found here:
http://support.microsoft.com/kb/2652061
I was experiencing the same issue, where the date would be off by two days, and this hotpatch fixed it.
This is also an issue in OpenJDK 1.6.0_20. However, the mssql driver works fine with Suns JRE 1.6.0_16.
Related
I have a DB2/zOS database that I need to access. When I create the connection on DBeaver it tests fine and when I open the connection it lets me browse schemas and tables.
The top stacktrace gives a generic SQLError, but I think the culprit is a java.nio.charset.UnsupportedCharsetException: Cp280.
I'm pretty sure it's a query problem (as opposed to a ResultSet problem) because even if I type gibberish in the query it throws the same exception.
I think it's a problem with my particular machine as trying it on my coworker's PC it goes through without a itch. We use the same version of DBeaver, the same connection, the same VPN and the same drivers. I've already tried updating my db2jcc4.jar to the latest 10.1 release, remaking the connection (although with the same settings) and rebooting my PC.
Would really appreciate some help. Thanks.
My thanks to Gord for trying to help, unfortunately it seemed like it was a DBeaver bug that was fixed in version 6.1.2, which came out yesterday. It works fine now.
I am struggling with the above - I've installed PowerQuery (64 bit Excel 2013 setup) and under the database connection options, despite following the instructions here to download the Ngpsql data provider for PostgreSQL:
https://support.office.com/en-ie/article/Connect-to-a-PostgreSQL-database-Power-Query-bf941e52-066f-4911-a41f-2493c39e69e4?ui=en-US&rs=en-IE&ad=IE
I can still only see a limited set of options under under the database list, which do not include a PostgreSQL database. Now having hunted around on the web I found this thread:
https://superuser.com/questions/950100/connect-to-postgresql-database-from-excel-2013-power-query-with-npgsql
Which seems to suggest that the reason I cannot see the Postgresql option is that I am not using an OfficePro installation (think it was home edition).
Does anyone have any pointers - any workaround for this? Or do I really have to get a different version of office to get data from a Postgresql db, short of converting the database into Access or something? Thanks
[I have Office 2013 Pro.]
I had to do this in addition to installing "PowerQuery_2.44.4675.281 (64-bit) [en-us].msi" (I ticked GAC installation on the installation dialog) and "Npgsql-3.2.3.msi". Also, rebooted the machine.
Everything then started to work connection-wise.
But when returning large amounts of data into Excel with Powerquery at times I would get "type cast" errors - I could not map it down to NULLs or anything easy to determine. Powerquery seems a fine tool for some usages and I am sure this error can be fixed with data transformation steps.
If you just want to get the postgres data - you can use VBA + ADO. I have just finished setting it up and it works.
Install "psqlodbc_x64.msi".
Add references to your vba project.
Finally I created the connection with this connecton string (no windows DSN setup required - modify the string below as per your setup):
cnn.Open "Driver={PostgreSQL Unicode(x64)};Server=127.0.0.1;Port=xxxx;UID=postgres;PWD=postgres; Database=db_name;"
I could also successfully add it as a data source using the same connection string.
Before you close me for a duplicate. I know there is a work around for this at the link below.
My question is: why is this "suddenly" happening? I work at company and we have probably 40+ dts packages running regularly. None have ever had this issue when going between our Oracle and SQL Server 2008 platforms.
I suspect it is because of some update to one of the platforms, or because we migrated to a new server for SQL Server.
Does anyone know what setting this would be that needs to be changed in order to avoid this?
Additionally, every package we create / edit throws warnings for this, however, every legacy package works just fine.
SSIS Package: convert between unicode and non-unicode string data types
You mention that you migrated to new SQL Server. I suspect that you also change architecture from 32-bit to 64-bit which can cause your problems.
To determine this is your case run your DTS/SSIS from command line using default dtexec from Program Files\...\Binn and second from Program Files(x86)\...\Binn.
Second you mentioned that your legacy dts works fine, try to delete their source adapter and recreate it and check if it'll cause your problem.
Possible solution: install 32-bit Oracle drivers and use them
from SQL Server Agent Job in tab Execution Options set Use 32 bit Runtime
Read carefully 64 bit Considerations for Integration Services
To fix this issue I used the connection type:
Microsoft OLE DB Provider for Oracle.
Note I did not have to install any special version
This alone did not fix the issue, I also had to edit my OLE DB Souce connection properties. Under Custom Properties is the choice for AlwaysUseDefaultCodePage. This is by default set to false, when I set it to true this fixed my issue. I have not seen this error come back since.
Firstly, my cconfig is:
Language: ColdFusion 10(and installed update 11)
DB is MS SQL Server 2012
Using the jtds jdbc(tried versions 1.2.6, 1.2.8 and 1.3.0)
I'm currently having a problem running queries where I use cfqueryparam with a cfsqltype of cf_sql_nvarchar. The problem is the page just hangs. If I look at the application log of ColdFusion, I see the error of:
"net.sourceforge.jtds.jdbc.JtdsPreparedStatement.setNString(ILjava/lang/String;)V The specific sequence of files included or processed is:" followed by the test filename.
I'm running a very basic select query on a nvarchar column, but the page doesn't load and that error is logged.
I know it's gotta be something to do with the jtds jdbc as if I connect through the regular sql driver it'll work perfectly.
So did anybody experience this before? If so, what was your resolution?
Thanks
I did a quick search and the results suggest jtds does not support setNString(). I checked the driver source for 1.3.1, and as mentioned in the comments here the method is not implemented:
"..while getNString is implemented the code just consists of // TODO
Auto-generated method stub and throw new AbstractMethodError();.."
So it sounds like you may need to use cf_sql_varchar, combined with the "String Format" setting, like in previous versions. Obviously, the other option is to use a different driver (one that does support setNString(), such as Adobe's driver or the MS SQL Server driver).
Try using cf_sql_varchar. cf_sql_nvarchar is not a valid option according to the Documentation and you should use cf_sql_varchar
I have written a job server that runs 1 or more jobs concurrently (or simultaneously depending on the number of CPUs on the system). A lot of the jobs created connect to a SQL Server database, perform a query, fetch the results and write the results to a CSV file. For these types of jobs I use pyodbc and Microsoft SQL Server ODBC Driver 1.0 for Linux to connect, run the query, then disconnect.
Each job runs as a separate process using the python multiprocessing module. The job server itself is kicked off as a double forked background process.
This all ran fine until I noticed today that the first SQL Server job ran fine but the second seemed to hang (i.e. look as though it was running forever).
On further investigation I noticed the process for this second job had become zombified so I ran a manual test as follows:
[root#myserver jobserver]# python
Python 2.6.6 (r266:84292, Dec 7 2011, 20:48:22)
[GCC 4.4.6 20110731 (Red Hat 4.4.6-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
import pyodbc
conn = pyodbc.connect('DRIVER={SQL Server Native Client 11.0};SERVER=MY-DATABASE-SERVER;DATABASE=MY-DATABASE;UID=MY-ID;PWD=MY-PASSWORD')
c = conn.cursor()
c.execute('select * from my_table')
<pyodbc.Cursor object at 0x1d373f0>
r = c.fetchall()
len(r)
19012
c.close()
conn.close()
conn = pyodbc.connect('DRIVER={SQL Server Native Client 11.0};SERVER=MY-DATABASE-SERVER;DATABASE=MY-DATABASE;UID=MY-ID;PWD=MY-PASSWORD')
Segmentation fault
So as you can see the first connection to the database works fine but any subsequent attempts to connect fail with a segmentation fault.
I cannot for the life of me figure out why this has started happening or the solution, all worked fine before today and no code has been changed.
Any help on this issue would be much appreciated.
I had a very similar problem and in my case the solution was to upgrade the ODBC driver on the machine I was trying to make the connection from. I'm afraid I don't know much about why that fixed the problem. I suspect something was changed or upgraded on the database server I was trying to connect to.
This answer might be too late for the OP but I wanted to share it anyway since I found this question while I was troubleshooting the problem and was a little discouraged when I didn't see any answers.
I cannot detail the specifics of the underlying mechanics behind this problem. I can however say that the problem was being caused by using the Queue class in python's multiprocessing module. Whether I was implementing this Queue correctly remains unanswered but it appears the queue was not terminating the sub process (and the underlying database connection) properly after each job completed which led to the segmentation faults.
To solve this I implemented my own queuing system which was basically a list of Process objects executed in the order they were put into the list. A loop then made periodic checks on the status of those processes until all had completed. The next batch of jobs would then be retrieved and executed.
I also encounter this problem recently. My config includes unixODBC-2.3.0 plus MS ODBC Driver 1.0 for Linux. After some experiments, we speculate that the problem may arise due to database upgrade (to SQLServer 2008 SP1 in our case), thus triggering some bugs in the MS ODBC driver. The problem also occurs in this thread:
http://social.technet.microsoft.com/Forums/sqlserver/en-US/23fafa84-d333-45ac-8bd0-4b76151e8bcc/sql-server-driver-for-linux-causes-segmentation-fault?forum=sqldataaccess
I also tried upgrade my driver manager to unixODBC-2.3.2 but with no luck. My final solution is using FreeTDS 0.82.6+ with unixODBC-2.3.2. This version of FreeTDS driver goes badly along with unixODBC-2.3.0, for the manager keeps complaining about function non-support of the driver. Everything goes smooth if unixODBC is upgraded.