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