I'am trying to use package RODBCto access a mdb-file.
The mdb-file is created with ESRI GIS.
I want to change some entries in the attribute table.
If i try
sqlQuery(channnel = rddall, "SELECT* FROM abt_F;")
sqlFetch(channel=rddall,"txt_L ")
R crashes.
Screenshot
> sessionInfo()
R version 3.1.2 (2014-10-31)
Platform: i386-w64-mingw32/i386 (32-bit)
locale:
[1] LC_COLLATE=German_Austria.1252 LC_CTYPE=German_Austria.1252 LC_MONETARY=German_Austria.1252
[4] LC_NUMERIC=C LC_TIME=German_Austria.1252
attached base packages:
[1] splines grid stats graphics grDevices utils datasets methods base
other attached packages:
[1] RODBC_1.3-12 brew_1.0-6 Hmisc_3.15-0 ggplot2_1.0.0 Formula_1.2-1 survival_2.37-7
[7] lattice_0.20-29 rgdal_1.1-8 sp_1.2-2
loaded via a namespace (and not attached):
[1] acepack_1.3-3.3 cluster_1.15.3 colorspace_1.2-5 digest_0.6.8 foreign_0.8-61
[6] gtable_0.1.2 latticeExtra_0.6-26 MASS_7.3-35 munsell_0.4.2 nnet_7.3-8
[11] plyr_1.8.3 proto_0.3-10 RColorBrewer_1.1-2 Rcpp_0.11.5 reshape2_1.4.1
[16] rpart_4.1-10 scales_0.2.4 stringr_0.6.2 tcltk_3.1.2 tools_3.1.2
Likely too late, but I just came across this question after encountering a similar problem. R was crashing for me when I tried to sqlFetch a table directly from my ArcGIS-created .mdb, and when I tried to fetch the table via a different non-GIS .mdb (I added the table to that database as an External Linked table, from the GIS .mdb). I finally got R to load the table correctly when I created a query in my non-GIS .mdb that basically replicated the initial table (although I dropped some of the unneeded columns in that query). Now, I just left the query as-is in my non-GIS .mdb, and sqlFetch the query, and it's working fine. Not really an R solution, but a potential workaround that may work for some folks.
Related
When aggregating data with summarise the group_by function from the line before is often being ignored. I can solve this problem by calling dplyr:: before the function, but this problem is nevertheless counter-intuitive and problematic. Here is an example of what is happening:
df <- data.frame(grp = c("a", "a", "b", "b"),
value = c( 1:4))
> df %>% group_by(grp) %>%
+ summarise(value = mean(value))
value
1 2.5
> df %>% group_by(grp) %>%
+ dplyr::summarise(value = mean(value))
# A tibble: 2 x 2
grp value
<fct> <dbl>
1 a 1.5
2 b 3.5
I've read that loading plyr after dplyr can sometimes lead to this problem - and after not loading plyr at all anymore I get this unwanted behavior less often.
I'm using R version 3.6.1 on Windows 10 x64 and dplyr version 0.8.3.
Session Info
> sessionInfo()
R version 3.6.1 (2019-07-05)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 10 x64 (build 17763)
Matrix products: default
locale:
[1] LC_COLLATE=English_United States.1252 LC_CTYPE=English_United States.1252 LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C LC_TIME=English_United States.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] lazyeval_0.2.2 data.table_1.12.2 shinythemes_1.1.2 shinycssloaders_0.2.0 plyr_1.8.4
[6] plotly_4.9.0 shiny_1.3.2 dplyr_0.8.3 mgcv_1.8-28 nlme_3.1-140
[11] kableExtra_1.1.0 scales_1.0.0 readxl_1.3.1 tidyr_0.8.3 knitr_1.23
[16] lubridate_1.7.4 ggplot2_3.2.0 reshape2_1.4.3 rlang_0.4.0 DT_0.7
[21] tibble_2.1.3 qlcMatrix_0.9.7 sparsesvd_0.2 slam_0.1-45 Matrix_1.2-17
loaded via a namespace (and not attached):
[1] httr_1.4.0 jsonlite_1.6 viridisLite_0.3.0 splines_3.6.1 assertthat_0.2.1 highr_0.8
[7] cellranger_1.1.0 yaml_2.2.0 pillar_1.4.2 backports_1.1.4 lattice_0.20-38 glue_1.3.1
[13] digest_0.6.20 RColorBrewer_1.1-2 promises_1.0.1 rvest_0.3.4 colorspace_1.4-1 htmltools_0.3.6
[19] httpuv_1.5.1 pkgconfig_2.0.2 purrr_0.3.2 xtable_1.8-4 webshot_0.5.1 later_0.8.0
[25] docopt_0.6.1 withr_2.1.2 cli_1.1.0 magrittr_1.5 crayon_1.3.4 mime_0.7
[31] evaluate_0.14 fansi_0.4.0 xml2_1.2.1 tools_3.6.1 hms_0.5.0 stringr_1.4.0
[37] munsell_0.5.0 compiler_3.6.1 grid_3.6.1 rstudioapi_0.10 htmlwidgets_1.3 crosstalk_1.0.0
[43] labeling_0.3 rmarkdown_1.14 gtable_0.3.0 R6_2.4.0 zeallot_0.1.0 utf8_1.1.4
[49] readr_1.3.1 stringi_1.4.3 Rcpp_1.0.2 vctrs_0.2.0 tidyselect_0.2.5 xfun_0.8
UPDATE:
Thanks to the comment from #r2evans, I ran this line of code to see which package was loading plyr, unbeknownst to me:
Filter(function(p) grepl("\\bplyr\\b", packageDescription(p)$Imports), gsub("package:", "", grep("^package:", search(), value = TRUE)))
It turns out loading reshape2 was also loading plyr - so loading dplyr last has resolved this issue for me.
This is a common problem, but finding the culprit can be problematic. Some techniques to remedy the problem:
Knowing which version of the function you are trying to use is likely the first step, as it identifies which package is in conflict. This is a common problem with me with summarize (dplyr, plyr, and Hmisc), lag (dplyr and stats), and less-often filter (same two). You can see which version you are using by either typing the function and watching the function-body scroll by, or you can just type:
environment(summarise)
# <environment: namespace:dplyr>
Sometimes, the package load was just bad-luck timing based on trying new code, attempting branches of analysis, etc ... and something that is in the search path just isn't needed anymore. Finding this culprit can be annoying, but if you know you don't need a package anymore, you can always detach("package:___") and try again1.
Occasionally, just restarting the R session is sufficient. This is hampered sometimes by the auto-saving of the workspace, in that attached packages and such are restored (with conflicts still in place). So restarting to a fresh R session can be helpful. If you rely on the data-saving aspects of saving the workspace, then try an explicit saving of the variables you need (this can be painstaking if a lot) and reloading just those variables ...
If none of the above works (or you don't want to restart R), you can find which of your currently-loaded packages are causing the culprit-conflict by doing something like this:
Filter(function(p) any(grepl("\\bplyr\\b", packageDescription(p)[c("Imports","Depends","Suggests","LinkingTo")])),
gsub("package:", "", grep("^package:", search(), value = TRUE)))
If nothing currently in the search() path (of packages ... not directories of executables) has "legitimately"2 caused the import of your conflict-causing package, then you'll see character(0) ... otherwise, you'll see the packages to blame.
From here, the order that packages are loaded is key: whichever is loaded last wins: think about loading packages as adding layers on top of each other: the one that is on top is the version that you will see. You can always access the version of a conflicted package directly with the double-colon notation (e.g., dplyr::lag instead of just lag), and in fact that is often the preferred method to reference non-base packages when writing your own package. (It is not always required, but its verbosity can be both declarative and unambiguous.)
Notes:
Some packages do not detach well, often due to DLL loading. You can try detach(..., force=TRUE), but sometimes the safest way is to just restart R.
it is always possible to cause the loading of another package from functions, even if the DESCRIPTION file does not mention this act. I believe CRAN is pretty good about catching and preventing this behavior, but side-loading packages (e.g., from GitHub) can easily bypass this safety feature.
The conflicts between dplyr and plyr have been known for years (e.g., https://github.com/tidyverse/dplyr/issues/347 from 2014, and loading dplyr after plyr is causing issues from 2015). That is why the plyr warning in dplyr was added to dplyr startup messages in 2014.
I have a ggplot2 plotting function as part of my code.
The function works fine when the file is sourced as R code, however when I include this function in an R package (and of course I include ggplot2 and scales both in the DESCRIPTION and in the NAMESPACE files of the package) I am getting the following error:
Error in initFields(scales = scales) :
could not find function "initRefFields"
The respective call of scales in the ggplot2 object is the following:
+ facet_wrap(~PV_Type, ncol = 1, scales = "free") +
I run the latest R (3.2.0) and the latest ggplot2 (1.0.1) installed from source.
A possible solution/explanation will be highly appreciated!
EDIT: The output of sessionInfo() is the following:
R version 3.2.0 (2015-04-16)
Platform: x86_64-apple-darwin13.4.0 (64-bit)
Running under: OS X 10.10.3 (Yosemite)
locale:
[1] C/UTF-8/C/C/C/C
attached base packages:
[1] stats graphics grDevices utils datasets base
other attached packages:
[1] argparse_1.0.1 proto_0.3-10 greater_1.0
loaded via a namespace (and not attached):
[1] Rcpp_0.11.6 DEoptimR_1.0-2 RColorBrewer_1.1-2 plyr_1.8.2
[5] methods_3.2.0 class_7.3-12 prabclus_2.2-6 tools_3.2.0
[9] digest_0.6.8 mclust_5.0.1 gtable_0.1.2 lattice_0.20-31
[13] mvtnorm_1.0-2 findpython_1.0.1 gridExtra_0.9.1 trimcluster_0.1-2
[17] stringr_1.0.0 cluster_2.0.1 RGraphics_2.0-12 fpc_2.1-9
[21] stats4_3.2.0 diptest_0.75-6 grid_3.2.0 nnet_7.3-9
[25] getopt_1.20.0 robustbase_0.92-3 flexmix_2.3-13 pander_0.5.1
[29] ggplot2_1.0.1 reshape2_1.4.1 kernlab_0.9-20 magrittr_1.5
[33] scales_0.2.4 modeltools_0.2-21 MASS_7.3-40 colorspace_1.2-6
[37] stringi_0.4-1 munsell_0.4.2 rjson_0.2.15
The .libPaths() is also rather common for my installation:
>.libPaths()
[1] "/Library/Frameworks/R.framework/Versions/3.2/Resources/library"
Perhaps I should also add that I call the function which requires the scales package from a command line R script.
(This is not a duplicate of ggplot2 Error in initFields as I tried all their recommendations (apart from reverting back to R 2.14 of course) and none worked).
I think I have found a solution/workaround.
As I noticed from sessionInfo() the methods package was not attached but rather loaded in the namespace. Therefore after attaching methods (as well as grid which was needed for a consequent function) my script work fine by oading the functions from the package.
My working sessionInfo() looks like this now:
R version 3.2.0 (2015-04-16)
Platform: x86_64-apple-darwin13.4.0 (64-bit)
Running under: OS X 10.10.3 (Yosemite)
locale:
[1] C/UTF-8/C/C/C/C
attached base packages:
[1] grid methods stats graphics grDevices utils datasets
[8] base
other attached packages:
[1] argparse_1.0.1 proto_0.3-10 greater_1.0
loaded via a namespace (and not attached):
[1] Rcpp_0.11.6 DEoptimR_1.0-2 RColorBrewer_1.1-2 plyr_1.8.2
[5] class_7.3-12 prabclus_2.2-6 tools_3.2.0 digest_0.6.8
[9] mclust_5.0.1 gtable_0.1.2 lattice_0.20-31 mvtnorm_1.0-2
[13] findpython_1.0.1 gridExtra_0.9.1 trimcluster_0.1-2 stringr_1.0.0
[17] cluster_2.0.1 RGraphics_2.0-12 fpc_2.1-9 stats4_3.2.0
[21] diptest_0.75-6 nnet_7.3-9 getopt_1.20.0 robustbase_0.92-3
[25] flexmix_2.3-13 pander_0.5.1 ggplot2_1.0.1 reshape2_1.4.1
[29] kernlab_0.9-20 magrittr_1.5 scales_0.2.4 modeltools_0.2-21
[33] MASS_7.3-40 colorspace_1.2-6 stringi_0.4-1 munsell_0.4.2
[37] rjson_0.2.15
Thanks very much for the contribution, however I would appreciate an explanation on firstly why there is the need to explicitly attach these two packages (methods and grid) when the functions are loaded as a package, and it is not required when the function are sourced by source().
I'm trying to use the bind_rows() function from dplyr (ver 0.4.1), but R command line can't find the function. It can find the help for the function, but any efforts to use the function are met with
> bind_rows()
Error: could not find function "bind_rows"
Am I doing something wrong? I understand bind_rows() was only introduced in ver 0.4.0, but I have a newer version than that.
Here is my sessionInfo()
> R version 3.1.1 (2014-07-10)
> Platform: x86_64-apple-darwin13.1.0 (64-bit)
>
> locale:
> [1] en_GB.UTF-8/en_GB.UTF-8/en_GB.UTF-8/C/en_GB.UTF-8/en_GB.UTF-8
>
> attached base packages:
> [1] utils datasets graphics grDevices stats methods base
>
> other attached packages:
> [1] lubridate_1.3.3 tidyr_0.2.0 dplyr_0.4.1 swirl_2.2.16 mvoutlier_2.0.5 sgeostat_1.0-25
>
>loaded via a namespace (and not attached):
> [1] assertthat_0.1 colorspace_1.2-4 DEoptimR_1.0-1 digest_0.6.4 GGally_0.4.8
> [6] ggplot2_1.0.0 grid_3.1.1 gtable_0.1.2 httr_0.5 magrittr_1.0.1
>[11] MASS_7.3-34 memoise_0.2.1 munsell_0.4.2 mvtnorm_1.0-0 parallel_3.1.1
>[16] pcaPP_1.9-49 pls_2.4-3 plyr_1.8.1 proto_0.3-10 Rcpp_0.11.2
>[21] RCurl_1.95-4.3 reshape_0.8.5 reshape2_1.4 robCompositions_1.9.0 robustbase_0.91-1
>[26] rrcov_1.3-4 scales_0.2.4 stats4_3.1.1 stringr_0.6.2 tcltk_3.1.1
>[31] testthat_0.8.1 tools_3.1.1 yaml_2.1.13
Did you try to call it with the package prefix, e.g.
dplyr::bind_rows()
This should work even if there is a conflict with one of the other packages.
Closing all R sessions and re-installing dplyr worked in this situation. Thanks to David Arenburg for the prompt.
I am trying to generate a proper dendrogram in R with ggplot2 (more specifically ggdendro::ggdendrogram) because I would like to share it over plotly with my collaborators and currently I do not think it is possible with the api to generate a dendrogram with plotly.
I am mainly having troubles with the "axis" labeling when I rotate the dendrogram:
require(ggplot2)
require(ggdendro)
hc<-hclust(dist(iris[,1:4]),method="ward.D2")
ggd<-ggdendrogram(hc,rotate=TRUE)
ggd+scale_y_reverse()
This results in the following plot, where the tick labels are on the wrong side:
I would like to obtain a similar result as from R base graphics when executing plot(as.dendrogram(hc),horiz=TRUE)
As a bonus, I would like to be able to color the leaf (tick) labels separately as well as draw rect.hclust-like boxes, but this is not strictly necessary. I do know my way a little bit around ggplot2 syntax so no need to explain every possible solution in great length.
If relevant please find my sessionInfo() below, I am using R through Rstudio server on an Ubuntu 12.04 LTS server:
sessionInfo()
R version 3.1.0 (2014-04-10)
Platform: x86_64-pc-linux-gnu (64-bit)
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C LC_TIME=C LC_COLLATE=C LC_MONETARY=C LC_MESSAGES=C LC_PAPER=C
[8] LC_NAME=C LC_ADDRESS=C LC_TELEPHONE=C LC_MEASUREMENT=C LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] ggdendro_0.1-14 cluster_1.15.2 plotly_0.4 RJSONIO_1.2-0.2 RCurl_1.95-4.1 bitops_1.0-6 devtools_1.5
[8] extrafont_0.16 RColorBrewer_1.0-5 scales_0.2.4 vegan_2.0-10 lattice_0.20-29 permute_0.8-3 splitstackshape_1.2.0
[15] data.table_1.9.2 BurStMisc_1.00 reshape2_1.4 xlsx_0.5.5 xlsxjars_0.6.0 rJava_0.9-6 ggplot2_0.9.3.1
[22] plyr_1.8.1
loaded via a namespace (and not attached):
[1] MASS_7.3-32 Rcpp_0.11.1 Rttf2pt1_1.3 colorspace_1.2-4 digest_0.6.4 evaluate_0.5.5 extrafontdb_1.0 formatR_0.10 grid_3.1.0
[10] gtable_0.1.2 httr_0.3 knitr_1.6 labeling_0.2 memoise_0.2.1 munsell_0.4.2 parallel_3.1.0 proto_0.3-10 stringr_0.6.2
[19] tools_3.1.0 whisker_0.3-2
If I include \usepackage{Sweavel} in my .rnw file, I get an X11 popup error "It seems you are using the Sweave-specific syntax; you may need Sweave2knitr("IPT-baseline-test.rnw") to convert it to knitr" when I compile in RStudio (Version 0.98.484). The document compiles, but I have to dismiss the error.
(1) Any ideas why \usepackage{Sweavel} triggers the error?
(2) Is there a way to turn off the popup since the document compiles anyway?
> sessionInfo()
R version 3.0.2 (2013-09-25)
Platform: x86_64-apple-darwin10.8.0 (64-bit)
locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] knitr_1.5
loaded via a namespace (and not attached):
[1] colorspace_1.2-4 dichromat_2.0-0 digest_0.6.3 evaluate_0.5.1
[5] formatR_0.10 ggplot2_0.9.3.1 grid_3.0.2 gtable_0.1.2
[9] labeling_0.2 MASS_7.3-29 munsell_0.4.2 plyr_1.8
[13] proto_0.3-10 RColorBrewer_1.0-5 reshape2_1.2.2 scales_0.2.3
[17] stringr_0.6.2 tools_3.0.2
You shouldn't need to \usepackage{Sweavel} explicitly, I think -- knitr should handle that automatically. If you really want to suppress this false positive , you can rename Sweavel.sty to a file name that doesn't start with Sweave ... the which_sweave() function at https://github.com/yihui/knitr/blob/de7c65c58acfb1f3f5c0ac2f00b92cd2546be943/R/utils-sweave.R shows you what patterns knitr is looking for to detect "old Sweave syntax", specifically in this case the regular expression
regexp <-
'^\\s*\\\\(usepackage(\\[.*\\])?\\{Sweave|SweaveInput\\{|SweaveOpts\\{)'
So changing to mySweavel.sty should work ...
grepl(regexp,"\\usepackage{Sweave}") ## TRUE
grepl(regexp,"\\usepackage{Sweavel}") ## TRUE
grepl(regexp,"\\usepackage{mySweavel}") ## FALSE
My guess is that you have a newer version of knitr on your new than on your old machine, and it's trying harder to detect old Sweave syntax.
Removing the Sweave tag in the latex document prevented the warnings. It did not prevent the rendering of the file. Thus, the suggestion made in one of the comments above worked... knit2pdf (in my case) figures it out. - E