source/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:
   4
   5 I have learned the hard way it is important to be aware that
   6
   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.
  12
  13 #+end_quote
  14
  15 [[https://www.rforge.net/RJDBC/][Source]]
  16
  17 This because RODBC does not have the same behaviour.
  18
  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.
  21
  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.
  27
  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.
  40
  41 So yes, type-handling is a rather complex issue.