Skip to content
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

Cannot prepare parameterized SQL query using "?" #726

Closed
Viktor-PRI opened this issue Jan 13, 2024 · 5 comments · Fixed by #740
Closed

Cannot prepare parameterized SQL query using "?" #726

Viktor-PRI opened this issue Jan 13, 2024 · 5 comments · Fixed by #740
Assignees
Labels
bug an unexpected problem or unintended behavior
Milestone

Comments

@Viktor-PRI
Copy link

Viktor-PRI commented Jan 13, 2024

Starting from version odbc 1.4, unable to prepare sql queries with "?" parameters. It worked in versions 1.3.5 and older.
for example: Oracle use ":param", Postgres - "$1" , FirebirdSQL - "?"
I understand that this DBMS is rare, but how can I help to fix this error?

Example for FirebirdSQL

###### OK ######
> packageVersion("odbc")
[1] ‘1.3.5’
> prepare <- dbSendQuery(conn, "select * from sec$users where sec$user_name = ?")
> prepare
<OdbcResult>
  SQL  select * from sec$users where sec$user_name = ?
  ROWS Fetched: 0 [complete]
       Changed: 0

###### ERROR ######
> packageVersion("odbc")
[1] ‘1.4.1’
> prepare <- dbSendQuery(conn, "select * from sec$users where sec$user_name = ?")
Error: nanodbc/nanodbc.cpp:1710: 07002
[ODBC Firebird Driver]COUNT field incorrect 
@detule detule self-assigned this Jan 13, 2024
@detule
Copy link
Collaborator

detule commented Jan 13, 2024

hi @Viktor-PRI - thanks for the report.

We changed some of the defaults with the 1.4.0 release - now when sending/executing a query, if the params argument is NULL ( default ), the execution is routed to an odbc API that does not allow for statement/preparing/parameter binding ( but is in theory, more performant ).

In your use case - I suspect the problem can be solved either by specifying immediate = FALSE, or by passing the parameters in the params argument at the same time you are sending the statement to be prepared.

> prepare <- dbSendQuery(conn, "select * from rdb$config where rdb$config_id = ?")
Error: nanodbc/nanodbc.cpp:1710: 00000
[ODBC Firebird Driver]COUNT field incorrect
> prepare <- dbSendQuery(conn, "select * from rdb$config where rdb$config_id = ?", immediate = FALSE)
> prepare
<OdbcResult>
   SQL  select * from rdb$config where rdb$config_id = ?
   ROWS Fetched: 0 [complete]
        Changed: 0
>

@hadley
Copy link
Member

hadley commented Jan 16, 2024

@detule I do think it was a mistake to set immediate = is.null(params) here, since dbSendQuery() is often followed by a dbBind(). I'm happy to fix this since I made the change.

@Viktor-PRI
Copy link
Author

Viktor-PRI commented Jan 17, 2024

@hadley Yes, I use it...

    prepare <- dbSendQuery(conn, update_sql, immediate = FALSE)
    
    for (i in 1:nrow(DT)) {
      dbBind(prepare, DT[i], batch_rows = 1)
    }

    dbClearResult(prepare)

@detule
Copy link
Collaborator

detule commented Jan 17, 2024

Thanks @Viktor-PRI. A bit curious about the use case - binding the rows one-by-one is somewhat idiosyncratic, but maybe that's a function of the type of query your are executing.

For comparison, dbWriteTable uses a prepared statement - we prepare that INSERT statement with, at times, hundreds/thousands of rows at a time.

@hadley Copy / reverting the behavior of dbSendQuery sounds good.

@Viktor-PRI
Copy link
Author

Viktor-PRI commented Jan 17, 2024

Thanks @detule for your interest.
Using binding one-by-one is bad idea, but FirebirdSQL 3 and older don't support multirow batch.

@hadley hadley added this to the v1.4.2 milestone Jan 18, 2024
hadley added a commit that referenced this issue Jan 18, 2024
@hadley hadley added the bug an unexpected problem or unintended behavior label Jan 18, 2024
hadley added a commit that referenced this issue Jan 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug an unexpected problem or unintended behavior
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants