> Oh, I completely forgot that people can do that. So, Robert, you case
> is exactly the case I was talking about. As Simon said your SELECT
> opens read-only transaction and then as you issue your first UPDATE
> this transaction have to be converted to writing one. This is a call
On Mon, Jun 14, 2010 at 4:36 PM, Simon Slavin wrote:
> Do you mean you're making changes as you call SQLite to _step() through the
> results of the SELECT ? Or do you read all the results of the SELECT into
> memory, then make changes to the database ?
Thanks, your and Pavel's clarifications have been very helpful.
sqlite-users mailing list
On Fri, Jun 11, 2010 at 5:26 PM, Pavel Ivanov wrote:
> 1. Ensure that you have no transactions started with SELECT and
> continued with INSERT/DELETE/UPDATE
This is interesting. I often have situations where I SELECT something
and then do manipulations (INSERT/DELETE/UPDATE)
Thanks, that was it. I don't know exactly how the errors were
interrelated, but once I told sqlite (via the PRAGMA thing) to use
memory for tmp stuff, all was fine.
I'm working under a cygwin environment which seems to be a bit shaky
when it comes to system-specific stuff like permissions.
On Mon, Aug 11, 2008 at 1:42 PM, P Kishor <[EMAIL PROTECTED]> wrote:
> ahhh... I did misread the question. Yes, the above explanation seems
> logical. Your app is probably tying up the db, so you can't drop the
> table from the command line.
No it ain't. That's of course the first thing I
why is it that I can look at the ".schema" of a db with the sqlite3
command line tool, but can't drop a table or view? After all, if the
db file weren't open, I couldn't even see the schema.
My problem is that I've written an app that uses views to access data.
After usage, I don't
Mail list logo