> 1) You have to loop through the resultset twice, > once to put it in memory, the other to process > it in your application.
Yes. > > 2) The sqlite3_prepare() and sqlite3_finalize() > both should be in a loop as well right? Since > they can throw SQLITE_BUSY and SQLITE_SCHEMA > themselves. So that should be a nested loop. I don't believe that's right. I might be wrong here but SQLITE_SCHEMA is only thrown if people change the database schema while you're using it. I wouldn't do that under any circumstances. BUSY just tells you someone is using it and you should wait. I didn't believe you had to prepare the sql again unless the schema was changed. > So we now have about 25-30 lines of code > including a nested loop so to step through a > *relatively* simple resultset. I think it should work for any result set. > > PS. What if sqlite *optionally* placed the > resultset in memory for the user. Then they > would they have to worry about BUSY or SCHEMA > errors whilst stepping through it? I think this is over simplification. If you write an application with the busy and schema events "hidden" what happens if the database goes busy? Does your app just hang? or Terminate? Shouldn't you be proactive about handling errors? I did this by writing a c++ wrapper that loads the result into a standard container list. It's a perfect place to use try/catch error trapping. If the database goes busy I retry for a resonable period. If it stays busy I throw() an error and give the user an apology and an explanation.
