On 21 Jun 2012, at 3:22pm, Dennis Volodomanov <i...@psunrise.com> wrote:
> Strangely enough (albeit expected), sqlite3 shell returns the expected > results (e.g. 1, 1 and "integer|0") for the queries. The "integer|64" could > be an SQLiteStudio-specific thing, I don't know. > > I'm opening the DB using sqlite3_open_v2() with these flags: > SQLITE_OPEN_CREATE|SQLITE_OPEN_READWRITE|SQLITE_OPEN_SHAREDCACHE - could the > shared cache play a role in this, along with read uncommitted? > > Given that the result is ok in the shell, I assume it's the way I've compiled > the amalgamation (see the flags I've posted earlier) or the way I open it - > is there anything peculiar about either of those? It should be completely impossible to get the results you describe, no matter what compilation options or flags you choose for SQLite, how you misuse transactions, or what kind of access modes you're using. It's possible to make SQLite give error messages instead of getting the correct results, probably related to file locking. But it's not meant to be possible to make SQLite give the wrong results and no error message, no matter how badly you mess things up. It's possible that you've discovered a bug in SQLite, but the posts I'm seeing here, including my own, suspect you're doing something wrong in your use of the API: either overwriting memory, or duplicating handles, or something else which violates the conventions for using C APIs. I think we will only be able to get further if you can produce a minimal example which demonstrates your problem. Try making a little program that doesn't use threads. If you can't duplicate the problem like that, try one that does use threads. If you can't make a small program that duplicates your problem, it might be something about your big program that's doing it. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
