It looks like result::get_row_count() always returns zero after running a query. For example:

sqlite::query q(conn_, "SELECT key, size FROM cache ORDER BY access_time ASC;"); auto r = q.emit_result(); cerr << "row_count: " << r->get_row_count() << endl;

This prints 0 for a table with three records.

The problem I have is that I want to iterate over the results to do things with each record. But I can't. The approach in the example does not work:

do { cerr << "key: " << y->get_string(0) << endl; } while (y->next_row());

The problem here is that the result set may be empty, in which case I don't want to do anything. But I cannot write a pre-tested loop without get_row_count(). The do loop will execute at least once, even if there are no results.

If I do run the above loop on an empty result set, I get

key: NULL

That's despite the fact that the corresponding table column is defined as NOT NULL.

What's the suggested way to process results row by row and doing nothing if there are no results?

Hi First thing first, thank you so much for sharing your efforts

I think there is just a little typo in given sample code line sqlite::execute insert(con, "INSERT INTO TEST VALUE(?, ?);"); should be sqlite::execute ins(con, "INSERT INTO TEST VALUES(?, ?);");

transaction::~transaction(){ if (m_isActive) commit(); }

This seems really strange. Why does the destructor commit the transaction instead of rolling it back? The whole point of RAII is to make sure that, if something goes wrong, things are cleaned up. Consider something like this:

{ transaction t; // Some SQL statements here // Some other C++ code here that might throw // Some more SQL statements here } // t committed here, why?

If something throws in this block, the transaction will still be committed, even though there was an exception. This seems really counter-intuitive. I would expect the transaction to be rolled back unless it is explicitly committed, because that is the fail-safe behavior. I believe the destructor should roll back rather than commit. Can you explain why things are the other way around?

It seems there is a problem in bind():

void command::bind(int idx, std::vector const & v) { bind(idx,&v.at(0),v.size()); }

If I call this with an empty vector, the bind throws because v.at(0) is out of range. I believe this should be something like:

if (!v.size() == 0) { bind(idx,&v.at(0),v.size()); } else { bind(++last_arg_idx); }

Dear Authors, we would like to package your software in our build farm build.opensuse.org giving the opportunity to thousand of users to be able to get the software directly with their package manager.

Unfortunately, we would like to have clarification about the license. All the allowed and well known licenses are located there. https://docs.google.com/spreadsheet/pub?key=0AqPp4y2wyQsbdGQ1V3pRRDg5NEpGVWpubzdRZ0tjUWc Could you have a look, and clarify the kind of BSD like you use.

Thanks

When I get a database_exception, I can get at the string for the error message, but not at the underlying error code. That's really inconvenient because I can't selectively react to different error conditions other than by parsing the error string. Doing that is really brittle. It would be nice to have an accessor on the exception classes that returns the underlying error code.

make install will install the library binary, but not the header files. The usual for a library package is to install both the library and header files on make install, but the Makefile.am file is set to install only libs. Headers should be added to a _HEADERS section.

Hi Here is my contribution to your code, its working good on powersystems.

Thanks for the code, its working good.

What do these changes do?

Added Architecture "ppc64le"

Are there changes in behavior for the user?

No

• Make it possible to build with MSVC (Visual C++) using CMake and LIBRARY_TYPE=Static
• Fix a couple of CMake developer warnings - they are related to the usage of quoted variables in if() statements (variables can be used without quotes in conditionals, e.g. "${VAR}" can be written as VAR).

This is just to make you aware that I'm building 32 and 64 bit packages of vsqlite-- for Slackware Linux. They could be found on my site SlackPack at this URL and if you consider you could add a reference in "Install with package manager" section of the site.

Hello, I very much like your library and would like to bring an issue to your attention.

There appears to be two typos in the example code on the project's website. http://vsqlite.virtuosic-bytes.com/

The first is execption instead of exception. The other is VALUE instead of VALUES in the prepared SQL statement.

I hope this helps.

It is possible that if during the rollback or commit command that there may be a disk error that will cause SQLite to return an error. When that happens we must not attempt to rollback again.

This was seen when running multi-threaded and a bug in some code resulted in the SQLite file descripter being closed in the middle of a transaction.

The function emit works without Qt and Qt works without vsqlite++. When using both together, you get the following compiler error:

In file included from src/./vsqlite++/include/sqlite/execute.hpp:35,
                 from src/./database.hpp:5,
                 from src/./todo.hpp:8,
                 from src/gui/mainwindow.cpp:9:
src/vsqlite++/include/sqlite/command.hpp:80:19: error: expected unqualified-id before ‘)’ token
         bool emit();

A simple renaming of the function emit(), which just forwards step(), in vsqlite++ solves this error.

Is there any reason for sqlite::command::emit or will it stay equal to sqlite::command::step?

What about C++11 (or C++14) compatibilty (using a recent compiler like GCC 4.9 or future 5.0, or Clang/LLVM 3.5 or 3.6, on Linux)?

In particular, I'm interested in

• using std::shared_ptr, not boost::shared_ptr
• using C++11 closures and/or for-ranged loops for iterating on the rows resulting from some SQL request.

Regards.