]> git.vanrenterghem.biz Git - www2.vanrenterghem.biz.git/blob - posts/fun_with_RJDBC_and_RODBC.mdwn
65e30052905944611b5ac4517c5267ff76b204c6
[www2.vanrenterghem.biz.git] / posts / fun_with_RJDBC_and_RODBC.mdwn
1 [[!meta date="2016-06-24 14:17:16 +0800"]]
3 I have learned the hard way it is important to be aware that
5 > Type-handling is a rather complex issue, especially with JDBC as different databases support different data types. RJDBC attempts to simplify this issue by internally converting all data types to either character or numeric values. 
7 [Source](https://www.rforge.net/RJDBC/)
9 This because RODBC does not have the same behaviour. 
11 When switching a few R scripts over from using RJDBC to access a MS SQL Server database to RODBC, I ran into some odd problems.
13 First, I noticed `as.Date(query,output$datecolumn)` resulted in what looked like 2016-06-21 becoming 2016-06-22. That's right, R started adding a day to the date. `as.Date(strptime(query.output$datecolumn, "%Y-%m-%d"))` put a stop to that madness.
15 Another problem had to do with an XML value being returned by a query. The application generating that XML for some reason opts to not store it as an XML data type but instead uses a varchar. That makes it is very hard to use XQuery, so I had opted to do the hard work in R by taking the whole XML value into R - despite this making the retrieval of query results almost impossible. In order to convert that column to an XML data type in R, I was able to do `sapply(response.xml$response, xmlParse)` on the output of a SQL query using RJDBC. Once the output from the RODBC connection had to be processed, this needed to become `sapply(response.xml$response, xmlParse, asText = TRUE)`. It is interesting this wasn't needed for the RJDBC output.
17 So yes, type-handling is a rather complex issue.