I have a simple function that should fetch a table using a DBI::dbConnect() connection. I am having trouble with the call to tbl() that works fine in an interactive session.
My function:
a2_db_read <- function(con, tbl_name, schema = "dbo"){
if(schema == "dbo"){
dplyr::tbl(con, tbl_name)
}
else{
dplyr::tbl(con, dbplyr::in_schema(schema, tbl_name))
}
}
If I make the call dplyr::tbl() I get:
Error in UseMethod("tbl") :
no applicable method for 'tbl' applied to an object of class "Microsoft SQL Server"
If I make the call dbplyr::tbl() I get:
a2_db_read(a2_con_uat, "AVL Data")
Error: 'tbl' is not an exported object from 'namespace:dbplyr'
How can I get that call to succeed in a function? My package Imports is:
Imports:
DBI,
dbplyr,
dplyr,
ggplot2,
odbc
I got it working with dplyr::tbl(), the correct usage.
The problem was that my connection was stored as an object in a package when in fact the connection needs to be made every time I restart R.
On a fresh R environment, the stored stale connection caused the error:
Error in UseMethod("tbl") :
no applicable method for 'tbl' applied to an object of class "Microsoft SQL Server"
When I regenerated the connection, it worked.
Related
I am trying to use pool to connect to my DuckDB/SQLite database .
con <- pool::dbPool(
drv = duckdb::duckdb(),
dbname = "data",
host = "FINAL_data.duckdb")
when I then type
dplyr::tbl(con,"data")
I can't open the database.
Error in dbplyr::as.sql(from, con) : unused argument (con)
So I try:
dplyr::tbl("data")
Error in UseMethod("tbl") :
no applicable method for 'tbl' applied to an object of class "character"
So I went back to
con <- dbConnect(duckdb::duckdb(), "FINAL_data.duckdb")
bigdf<-tbl(con,"data")
And this won't open the database now at all (which previously worked fine). The DB is still on disk and about 24G in size. Any thoughts as to what's going on are really appreciated!
Error in .local(conn, statement, ...) :
duckdb_prepare_R: Failed to prepare query SELECT *
FROM "data" AS "zzz6"
WHERE (0 = 1)
Error: Catalog Error: Table with name data does not exist!
LINE 2: FROM "data" AS "zzz6"
I experienced the same issue and it seems to be an incompatibility between the pool and dbplyr version.
For version of pool 0.1.5 and up you need to used dbplyr version 2.0.0 and up.
If you use lower version of dbplyr e.g. 1.4.4 you need to downgrade your pool to e.g. 0.1.4.3
I am using REMP package in R to find methylation in repetitive elements. I have stumbled upon the function initREMP, which is giving me the error:
remparcel <- initREMP(arrayType = "EPIC", REtype = "Alu", ncore = 1)
Start Alu annotation data initialization ... (0 sec.)
Illumina platform: EPIC
Error in .Hub("AnnotationHub", hub, cache, proxy, localHub, ...) :
Local database does not exist.
Repeat call with 'localHub=FALSE'
I installed annotationhub package from the bioconductor and tried the function again. Still the error remains.
Finally I got the answer.If you are working behind a proxy server getAnnotationHub function will not be able to make connection with the URL.Therefor we have to set the proxy using
library(AnnotationHub) setAnnotationHubOption("PROXY","https://username:password#proxy:port")
then try the
AnnotationHub( hub=getAnnotationHubOption("URL"),
cache=getAnnotationHubOption("CACHE"),
proxy=getAnnotationHubOption("PROXY"),
localHub=FALSE)
Connecting Excel with 'ABC' throught Excel works, connecting R with Excel by DDE works also, but how to connect R with 'ABC' application ?
I have application providing DDE interface, from Excel I could retrieve value from it with this DDE reference :
='ABC'|DDE!_nazwa_value
from R I've tried to use tcltk2 library, as follows :
tcltk2::tk2dde.request(service="ABC", topic="DDE", item="_nazwa_value")
but error occurs :
Error in structure(.External(.C_dotTcl, ...), class = "tclObj") :
[tcl] remote server cannot handle this command.
[1] "Error in structure(.External(.C_dotTcl, ...), class = \"tclObj\") : \n [tcl] remote server cannot handle this command.\n\n"
attr(,"class")
[1] "try-error"
attr(,"condition")
<simpleError in structure(.External(.C_dotTcl, ...), class = "tclObj"): [tcl] remote server cannot handle this command.
I'm only trying to use tcltk dde functions to retrieve data from application, I think that item part of my tk2dde.request is wrong, but I've tried various modification (without _ for example), do you know any clues or resources for solving this problem ?
EDIT
something is wrong I don't see ABC server nor DDE topic on server-topic list :
tk2dde.services() but Excel can still connect and retrieve value using ='ABC'|DDE!_nazwa_value, DDE Query also do not see it
You can read in the article about DDE in tcl/tk wiki:
(Talking about using Internet Explorer) ... All of the above experiments should "work" reliably, in that, from the user perspective, IE indeed acts as described. However, back in the Tcl process, [dde] typically throws a "remote server cannot handle this command" exception. That's because, in KBK's analysis, DDE gives no "way to distinguish 'result expected, but the server failed to provide it' from 'no result is expected'." The only way not to receive a DMLERR_NOTPROCESSED is to invoke "dde exec -async ..."
Note: i tried tcl examples of DDE using Excel + "request" and i got the same error as you: "remote server cannot handle this command".
Saludos!,
I'm having a constant error whenever I try to execute my data function forcing it to run on Spotfire Server.
The script works fine on R Studio and also on Spotfire if the Run Location configuration is set to "Force Local" or "Default".
When I use the Force Server, I get the following error message when executing a query:
Could not execute function call. TIBCO Spotfire Statistics Services returned an error:
'Error in sqlQuery(myconn, mappingQuery, errors = TRUE, rows_at_time = : first argument is not an open RODBC channel'.
at Spotfire.Dxp.Data.DataFunctions.Executors.RemoteFunctionClient.OnExecuting(FunctionClient funcClient)
at Spotfire.Dxp.Data.DataFunctions.Executors.AbstractFunctionClient.<RunFunction>d__0.MoveNext()
at Spotfire.Dxp.Data.DataFunctions.Executors.SPlusFunctionExecutor.<ExecuteFunction>d__0.MoveNext()
at Spotfire.Dxp.Data.DataFunctions.DataFunctionExecutorService.<ExecuteFunction>d__6.MoveNext()
Even if I have a straightforward script and query like the one below, the results are the same:
require(RODBC)
myconn <- odbcDriverConnect("Driver={SQL Server};Server=MY_SERVER;Database=MY_DATABASE;Trusted_Connection=True")
# myconn <- odbcDriverConnect("Driver={SQL Server};Server=MY_SERVER;Database=MY_DATABASE;UID=MY_USER;Pwd=MY_PASSWORD") ## Same result with trusted connection or user/password
query <- "SELECT * FROM MY_TABLE"
df <- sqlQuery(myconn, query)
print(df)
Have anyone ever seen this?
Thanks!
The error seems to suggest that the "RODBC" package's 'odbcDriverConnect()' function might not be finding the ODBC drivers it needs on the server that TIBCO Spotfire Statistics Services (TSSS) is installed on.
Try installing the required odbc drivers on the machine where the TIBCO Spotfire Statistics Services is installed.
Just updated to R 3.0 and updated all the packages, including DBI. To my surprise, a script that I often use stopped working.
I am unable to connect to a MySQL database using dbConnect. The code script instantly, so only a few lines will reproduce the problem
> require("RMySQL")
> m = dbDriver("MySQL")
> dbConnect(m, user = 'user', password = 'pass', dbname = 'dbname', host = 'localhost', client.flag = CLIENT_MULTI_STATEMENTS)
Error in as.integer(from) :
cannot coerce type 'S4' to vector of type 'integer'
Calls: dbConnect ... mysqlNewConnection -> isIdCurrent -> as -> asMethod
Also tried it as:
dbConnect(MySQL(), user = 'user', password = 'pass', dbname = 'dbname', host = 'localhost', client.flag = CLIENT_MULTI_STATEMENTS)
but the same problem
Also tried removing other parameters, but the same issue from the dbDriver.
What changed in the DBI package with the latest update? How can I fix this?
I noticed that the DBI package is orphaned so don't know who to ask.
I had the same issue with R 3.0.1 on ubuntu.
Installing the latest version of the RMySQL-package resolved the problem:
> install.pacakges("RMySQL")
Make sure to restart R after the installation.
I'm still digging into the issue, but I think I've identified multiple causes of this issue. At their root, they all have to do with R expecting an S4 object but getting back an integer instead. I believe these are generally a result of the connection failing to establish.
Why is it failing? One thing I've noticed is that if you fail to close to many of your connections (~16 [see the number of maximum connections specified in the driver handle call] open) DBI won't/can't open a new connection. Make sure you are calling dbDisconnect as needed. Usually, this sort of problem results in a sensible error message, however sometimes results in the above referenced error. If possible access the DB through an abstraction layer, e.g. dplyr as some will monitor the db connections and kill them if they are inactive. Whereas, AFIK if you open a connection in a function and the function breaks, you have no way to close the open connection unless you returned the driver object from your initial call to dbConnect. In this case you have no choice but to restart your instance of R (possibly resetting your machine and clearing your workspace as well).
The other issue I recently encountered is that if RMySQL masks RPostgreSQL, then RPostgreSQL will fail. The reverse does not appear to be the case, but because others have mentioned RPostgreSQL in here as showing the same error message, it seemed worthy of note.
Update
The latest version of RMySQL (0.10.1) seems to have finished off RPostgreSQL - RPostgreSQL now fails to work regardless of load order. The same people working on RMySQL appear to be working on RPostgres (https://github.com/rstats-db/RPostgres) and this conflict appears to be a non-issue if using that package instead of RPostgreSQL. Specifically, use RPostgres::Postgres() in the place of RPostgreSQL::PostgreSQL() when specifying the driver in dbConnect. Other packages, e.g. dplyr, currently assume RPostgreSQL, so this issue can still bite (but it seems a resolution is in the works (https://github.com/rstats-db/RMySQL/issues/28).