-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incorrect SQL generated against Oracle databases when no schema is specified #3080
Comments
Hi @mungojam , is the |
Good question. No, it's where most of our tables live and we all have access to tables within it (don't know if within is the right term, schemas confuse me..). Don't know if you saw my edit, it looks like just removing the surrounding brackets and speech-marks in the generated SQL would fix it. I guess that means that there is a default schema thing going on under the covers. I would do a pull request, but I'm a bit snowed under at the moment. |
I have encountered this same issue, though I hadn't tried specifying a schema as a work around yet. It seems to work well at this point, though it would be nice if it worked in the specified manner. |
This is going to need some digging by someone who knows more about Oracle's SQL dialect than me. Simply removing the quotes is not an option because that will cause a different set of problems with reserved words, case sensitivity, etc. |
One thing I didn't check was whether just removing the brackets and leaving the speech marks would have done the trick. I'm not at work for a week now to check. @rlusch would you mind checking to see if the following query works?
|
A good reference for oracle quoting rules appears to be this: https://docs.oracle.com/cd/B28359_01/server.111/b28286/sql_elements008.htm#SQLRF00223 (although I think it's using schema in a different sense to dbplyr) I think the most likely explanation is that the name of your table is actually "MY_TABLE". Since dbplyr uses quoted identifiers everywhere, you need to refer to tables by their actual names, which are typically in upper case. |
That is a useful page of explanation, so thank you, and you are right about the capitalisation, it does work when I use all caps. It's Oracle design at fault in my view. However, I am the first person in our area to really use R with Oracle and I fully expect others are going to get hit by this once we start moving to R more. It's going to be a pain point. I know it's a long shot to ask this, but it would be ideal for us if the default was for it to automatically toUpper the table name before quoting unless the user passed in the table name in back-ticks or something, e.g. `my_Table`. Is it worth me raising an issue for this request, or will it just get rejected? People are so used to not worrying about case when just writing a query in toad or whatever tool and I can't imagine many companies having tables with only the capitalisation varying. |
Yeah, unfortunately while that would solve your immediate problem, my sense is that it will create more problems in the longer run. |
ok, understood. I'll drill in to people to use ALL_CAPs whenever they can. They'll need to get used to it for field names anyway |
Incidentally, when using the schema (which allows for lower caps), the names don't look like they are quoted, at least no speech marks, but maybe that's what tidyverse/dbplyr@3cc019d is fixing (I can't try out GitHub releases at work): tbl(con, in_schema("schema_owner", "my_table")) %>%
filter(X >= 13) %>%
show_query() Leads to unquoted and therefore working query: SELECT *
FROM (schema_owner.my_table)
WHERE ("X" >= 13.0) |
When using tbl() with our Oracle database, we have to provide the schema name using in_schema. But when calling dbGetQuery directly we seem to get away without it.
Looks like this would be fixed by removing the brackets and speech marks from the table name if there is no schema:
The text was updated successfully, but these errors were encountered: