dbplyr | Database backend for dplyr | Database library

I am guessing that instead of seeing tidy SQL queries that look like:

FYI, your reproducible example is a grouped dataframe, that's why I passed it to ungroup first. If it weren't a grouped dataframe then you do not need that pipe.

I do this using dbExecute from the DBI package.

The key idea is to extract the query that defines the current remote table and make this a sub-query in a larger SQL query that writes the table. This requires that (1) the schema exists, (2) you have permission to write new tables, and (3) you know the correct SQL syntax.

Doing this directly might look like:

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

This is tricky, and the answer below doesn't solve this 100%. Now there are a number of different ways assertr lets you handle errors/stops, just see ?error_stop (which is the default).

You need to not only filter out rows that fail, but also collect them (all) for later inspection.

Below I wrote my own error handler. It fetches those rows that fail, filter them away, and stores them in the global environment under the varibale my.failed.rows.

So, for dplyr version 1.0.3 it is working perfectly fine.

I think that wrapping your paste0(...) in !!sym() will work. I'd try:

You could use DBI::Id to specify the table/schema, and then dbReadTable:

Well, actually I still don't get a satisfying solution. What I exactly wanted to do is to drop containing NA rows in R environment without typing an SQL query, I think dbplyr doesn't support this function yet.

Then I wrote a little and simple code to make my wish come true;