Martijn Schuemie

Hi @PRijnbeek, Completely agree! @pbr6cornell, we had discussed this recently and had come up with a new label, but I forgot what it was. Do you remember? Cheers, Martijn

Thanks! I think this fits nicely with our new development to use dbplyr backends for the various data platforms @ablack3

We may want to think about giving each DBMS its own `createConnectionDetails` function, with arguments specific to that DBMS? So `createConnectionDetailsBigQuery()`, `createConnectionDetailsSqlServer()`, etc.. Looping in @ablack3 , who is working...

Obviously, having a dedicated OhdsiSql backend in dbplyr would be great, but it would also be a *lot* of work, implying a lot of future maintenance (have you looked at...

I think I'm misunderstanding what you're proposing. I thought you wanted to create a backend that generates OhdsiSql, which would then be translated into the various supported dialects using SqlRender....

But if I read the PR correctly, you don't need a DatabaseConnector backend? You just give the DatabaseConnector connection the class corresponding to the DBMS, so the correct dbplyr backend...

I think I understand now. This is what I also was trying to suggest [here](https://github.com/OHDSI/DatabaseConnector/issues/224#issuecomment-1671278728). We could keep the backend using SqlRender for platforms that don't yet have a dbplyr...

Ok, I've created https://github.com/OHDSI/DatabaseConnector/tree/dbplyr_backends, and merged your PR there. We already have lots of unit tests for dbplyr, let's see how well they perform with this new approach.

You should have write access now. I would prefer the DBI functions to continue to translate by default when the user directly calls these functions. That fits the idea that...

Note that the changes to the odbc package Hadley mentioned are now (since 1.4.0) in effect. The various database classes are now [formally exported](https://github.com/r-dbi/odbc/blob/3bca21dd86c00dd04debcda1c93338ccf9dcdf1e/NAMESPACE#L24-L41), so we don't have to re-define...