Re: [sqlite] passing error messages to pysqlite

Kieth, thanks for the info, however, I tested the following code on a LOCAL copy of the database, one where at the sqlite3 command line I was able to do an insert without problems, and yet, the python code returned the 'database is locked; error message in the code (I used a wxpython

Re: [sqlite] passing error messages to pysqlite

Well that would be because the database is locked. Is the version of SQLite being used by Python the same version as the command line tool is using? What is the OS -- is the database stored somewhere that the OS thinks you are not permitted to change files (feature of windows). Do you have

Re: [sqlite] passing error messages to pysqlite

Just tried the same code on a different system, using sqlite3 3.8.2 Same result. Mark On Saturday, October 04, 2014 10:44:20 AM Mark Halegua wrote: > Kieth, > > thanks for the info, however, I tested the following code on a LOCAL copy of > the database, one where at the sqlite3 command line I

Re: [sqlite] passing error messages to pysqlite

Kieth, the database is not locked. It is a copy residing on the local hard drive in the same directory as the python code and that version of sqlite3. I was able to do an insert with the same sqlite3 in that directory as the code, so this behavior is somehow wrong. The two systems I've

Re: [sqlite] passing error messages to pysqlite

Ah, ok. after doing a database commit I get the error going to stderr. Now it's just a matter of capturing/redirecting the stderr output and using an except there. Thanks. Maqrk On Friday, October 03, 2014 09:06:56 PM Keith Medcalf wrote: > Are you committing the change? > >

Re: [sqlite] passing error messages to pysqlite

the sqlite3 command line doesn't require a commit, it gave an error after the attempted insert command. pysqlite requires one? Mark On Friday, October 03, 2014 09:06:56 PM Keith Medcalf wrote: > Are you committing the change? > > >-Original Message- > >From:

Re: [sqlite] passing error messages to pysqlite

and now the windows version, with sqlite 3.8.6 and a local database and local code in the same directory is doing the same, database locked. And yet, at the command line I could do an insert no problem. Mark On Saturday, October 04, 2014 12:00:59 PM Mark Halegua wrote: > Kieth, > > the

Re: [sqlite] passing error messages to pysqlite

And python is using that same version of SQLite3.dll? That is, pysqlite2 or sqlite3 or whatever version of the module you are using to interface to sqlite3.dll returns '3.8.6' when you do something like: 2014-10-04 10:19:52 [D:\Temp] >python Python 2.7.8 (default, Jun 30 2014, 16:03:49) [MSC

[sqlite] libsqlfs - a file system in a SQLite database

"The libsqlfs library implements a POSIX style file system on top of an SQLite database. It allows applications to have access to a full read/write file system in a single file, complete with its own file hierarchy and name space. This is useful for

Re: [sqlite] libsqlfs - a file system in a SQLite database

On Sat, Oct 4, 2014 at 1:49 PM, Simon Slavin wrote: > > > "The libsqlfs library implements a POSIX style file system on top of an > SQLite database. It allows applications to have access to a full > read/write > file system in

Re: [sqlite] passing error messages to pysqlite

in python I do from pysqlite2 import dbapi2 as sqlite which works well. When I do: >>> sqlite.sqlite_version '3.8.2' >>> sqlite.version '2.6.3' That's from the Linux Min 17 system. under kubuntu 11.04 it's 3.7.4 and 2.6.0 Under windows xp I get 3.8.5 and 2.6.3 Mark On Saturday,

Re: [sqlite] passing error messages to pysqlite

in python I do from pysqlite2 import dbapi2 as sqlite which works well. When I do: >>> sqlite.sqlite_version '3.8.2' >>> sqlite.version '2.6.3' That's from the Linux Min 17 system. under kubuntu 11.04 it's 3.7.4 and 2.6.0 Under windows xp I get 3.8.5 and 2.6.3 Mark On Saturday, October

[sqlite] Long lived prepared statements

I think I know the answer to this so I'm looking for some conformation. What I do is to prepare a relatively large and complex query. Then I run the same query forever never doing a finalize. My assumption is I will have no memory leakage. *Jim Dodgen*

Re: [sqlite] Long lived prepared statements

On 4 Oct 2014, at 10:08pm, Jim Dodgen wrote: > What I do is to prepare a relatively large and complex query. Then I run > the same query forever never doing a finalize. My assumption is I will > have no memory leakage. You can do _step() and _reset() and _bind_() as many times

Re: [sqlite] Long lived prepared statements

It might be I need more of a Perl DBI question the order of the statements I do are as follows prepare >> - Done once execute << done many times followed by: fetchrow_array << until exhausted finish << never done I just don't see that the Execute/Fetchrow-array activity is going to leave a

Re: [sqlite] Long lived prepared statements

On 4 Oct 2014, at 11:16pm, Jim Dodgen wrote: > It might be I need more of a Perl DBI question Whoops. Yes, my answer was geared to users of the C API and thin shims to it. I have no idea how Perl DBI works. Sorry about that, and I hope you can get a response from a Perl