Home > Back-end >  SQLite3 C , need a workaround for a sqlite3_stepback
SQLite3 C , need a workaround for a sqlite3_stepback

Time:01-30

I'm currently programming a .dll in C using the functionalities from the sqlite3.c file which can be found in the official SQLite page

The sqlite3.c contains various functions to do basic stuff with sqlite3 like connect to a DB, open a recordset, execute SQL statements, etc..

One of the functions used to navigate to the next returned record in a recordset is sqlite3_step. Unfortunately, there is not a sqlite_stepback or something similar.

In my case, I need to do a step and then do a stepback in a function to determine the size of the data that will be returned, so that the application using the .dll creates a buffer of the correct size to allocate all the data that will be returned.

I need help with any of these two possible workarounds:

  • Generate a sort of stepback function, issue being that I don't know the inner workings of sqlite3.c.
  • The recordsets are stored in what seems to be a struct defined as sqlite3_stmt. For my particular issue I could copy the full sqlite3_stmt to another variable, do a step in the copied sqlite3_stmt, and then destroy it, leaving intact the original recordset in its current position. I haven't managed to find a way to properly copy a sqlite3_stmt.

I think the best option if possible, would be the second one.

Thanks in advance :D

CodePudding user response:

I need to do a step and then do a stepback in a function to determine the size of the data that will be returned

No, you don't. If you did, someone else would have needed it before you, and the function would exist. Therefore we know some other way is possible, and probably better.

Just reorganize how you're accepting requests from the caller versus how you're interacting with SQLite. Maybe, in some sense, you have to be "one step ahead" of the application to provide it with the information it requires.

When sqlite3_step returns, you can call any number of functions to determine the values in the row and their sizes. You have what you need. There's no need at that juncture to go back to the previous row.

In case you doubt me, I worked on FreeTDS for many years. The TDS protocol is a stream from the DBMS. There's no "going back". FreeTDS offers three APIs, all of which do have some kind of client-side cursor to let the application scroll back to previously provided rows. But that functionality takes place entirely within the client library, with no server interaction.

I implemented some of that, but never used it in any of my applications. The fastest way through the data is forward, once.

  •  Tags:  
  • Related