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 tested this on are both Linux, one is kubuntu 11.04 with
sqlite3
version 3.7.4 the otehr is Linux Mint 17, KDE, and sqlite3 version 3.8.2
I'm about to test the code on a winxp vm with another local copy of the
database and code.
Mark
On Saturday, October 04, 2014 09:39:35 AM Keith Medcalf wrote:
> 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
> another outstanding transaction that you have not commit or rollback?
>
> Note rollback's are not automatic either, so after you get an error trying
> to commit, the transaction is still open and will be commit/rollback again
> next time your try to commit or rollback.
>
> Is the database file in use by something else? Do you have a busy wait
> timeout set? What Operating System are you running on?
> On Saturday, 4 October, 2014 08:44, Mark Halegua <phanto...@mindspring.com>
> said:
> >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 messagebox widget to display the error).
> >
> >Why would it return a locked message in this case?
> >
> >Here's the code:
> > def OnSave(self, event):
> > self.dbupdated = True
> > self.pub_title = self.pub_text.GetValue()
> > self.pub_remarks = self.remarks_text.GetValue()
> > print self.pub_title
> > print self.pub_remarks
> > # update relevant tables(s)
> > self.cdata.execute('insert into publishers(publisher_name,
> >
> >remarks) values("test", "remarks");')
> >
> > try:
> > self.database.commit()
> >
> > except sqlite.Error, dberr:
> > wx.MessageBox(dberr.args[0], 'DB Warning',
> >
> >wx.OK)
> >
> > self.dbupdated = False
> >
> > # clear fields
> >
> > if self.dbupdated:
> > self.pub_text.SetValue(' ')
> > self.remarks_text.SetValue(' ')
> >
> > print 'dbupdated = ' , self.dbupdated
> > print self.add
> > self.add = False
> > print self.add
> >
> >sqlite3 version 3.7.4
> >
> >Mark
> >
> >On Friday, October 03, 2014 10:37:06 PM Keith Medcalf wrote:
> >> Yes. pysqlite/sqlite3 in python tries to manage transactions for you
> >
> >by
> >
> >> automatically starting them, and you need to commit them yourself.
> >
> >This is
> >
> >> controlled by the isolation_level attribute set on the connection (can
> >
> >also
> >
> >> be set as a parameter when you open the connection).
> >>
> >> The default value is '' (an empty string). Other valid values are
> >> 'IMMEDIATE', 'EXCLUSIVE' and None. Basically, pysqlite tries to detect
> >
> >the
> >
> >> type of statement you are running and if it is a DML statement (select,
> >> insert, update, delete) it automatically begins a transaction for you
> >
> >if
> >
> >> one is not in progress by first doing a 'BEGIN '+isolation_level. If
> >
> >the
> >
> >> statement is something other than DML, then it will 'COMMIT' before
> >> executing the DDL (CREATE/DROP) then it will 'COMMIT' after executing
> >
> >it.
> >
> >> It does not know about the "WITH" statement, so treats those as DDL
> >
> >rather
> >
> >> than DML.
> >>
> >> Setting isolation_level to None tells pysqlite/sqlite3 to not manage
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
