Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #36839 > unrolled thread

sqlite3 puzzle

Back to article view | Back to comp.lang.python

Contents

  sqlite3 puzzle llanitedave <llanitedave@veawb.coop> - 2013-01-14 23:09 -0800
    Re: sqlite3 puzzle Rob Day <robert.day@merton.oxon.org> - 2013-01-15 14:36 +0000
      Re: sqlite3 puzzle llanitedave <llanitedave@veawb.coop> - 2013-01-15 07:51 -0800
        Re: sqlite3 puzzle Rob Day <robert.day@merton.oxon.org> - 2013-01-15 17:13 +0000
          Re: sqlite3 puzzle llanitedave <llanitedave@veawb.coop> - 2013-01-15 12:29 -0800
            Re: sqlite3 puzzle Rob Day <robert.day@merton.oxon.org> - 2013-01-15 22:27 +0000
              Re: sqlite3 puzzle llanitedave <llanitedave@veawb.coop> - 2013-01-15 14:46 -0800
              Re: sqlite3 puzzle llanitedave <llanitedave@veawb.coop> - 2013-01-15 14:46 -0800
          Re: sqlite3 puzzle llanitedave <llanitedave@veawb.coop> - 2013-01-15 12:29 -0800
      Re: sqlite3 puzzle llanitedave <llanitedave@veawb.coop> - 2013-01-15 07:51 -0800
    Re: sqlite3 puzzle inq1ltd <inq1ltd@inqvista.com> - 2013-01-15 11:54 -0500

#36839 — sqlite3 puzzle

I'm trying to get an application working in Python 2.7 and wx.Python which contains an embedded sqlite3 file.  There are a few tables with foreign keys defined.  In looking at the sqlite3 documentation, it says 

"Assuming the library is compiled with foreign key constraints enabled, it must still be enabled by the application at runtime, using the PRAGMA foreign_keys command." 
It goes on to say that foreign keys must be enabled separately for each connection, which is fine as my app has only one.

So I put the following test code in my initialization method:

    # open database file
    self.geologger_db = sqlite3.connect('geologger.mgc')
    self.db_cursor = self.geologger_db.cursor()
    self.foreign_key_status = self.db_cursor.execute("PRAGMA foreign_keys = ON")
    self.foreign_key_status = self.foreign_key_status.fetchone()

    print self.foreign_key_status

I ran this several times while I was arranging the downstream queries, and each time it returned '(1,)', which means foreign keys is enabled.

But I was using a variable named 'cmd1' as a placeholder until I changed the name to the more descriptive 'self.foreign_key_status'.  Since I made the name change, however, the code only returns 'None'.  Reverting to the previous variable name has no effect.

Yes, I'm closing the connection with self.db_cursor.close() at the end of each run.

According to the sqlite3 website, getting no return value, not even a '0', means that "the version of SQLite you are using does not support foreign keys (either because it is older than 3.6.19 or because it was compiled with SQLITE_OMIT_FOREIGN_KEY or SQLITE_OMIT_TRIGGER defined)."

How can that be a compilation issue when it worked previously?  Does this somehow relate to it being a Python plugin instance?

I'm very confused.

[toc] | [next] | [standalone]

#36856

On 15 January 2013 07:09, llanitedave <llanitedave@veawb.coop> wrote:

> So I put the following test code in my initialization method:
>
>     # open database file
>     self.geologger_db = sqlite3.connect('geologger.mgc')
>     self.db_cursor = self.geologger_db.cursor()
>     self.foreign_key_status = self.db_cursor.execute("PRAGMA foreign_keys = ON")
>     self.foreign_key_status = self.foreign_key_status.fetchone()
>
>     print self.foreign_key_status
>
> I ran this several times while I was arranging the downstream queries, and each time it returned '(1,)', which means foreign keys is enabled.
>
> But I was using a variable named 'cmd1' as a placeholder until I changed the name to
> the more descriptive 'self.foreign_key_status'.  Since I made the name change, however,
> the code only returns 'None'.  Reverting to the previous variable name has no effect.

Hmm - your code doesn't quite match up with the docs at
http://docs.python.org/2/library/sqlite3.html. That seems to suggest
that you should call fetchone() on the cursor, not on the result of
execute().

Does the following work?

    # open database file
    self.geologger_db = sqlite3.connect('geologger.mgc')
    self.db_cursor = self.geologger_db.cursor()
    self.db_cursor.execute("PRAGMA foreign_keys = ON")
    print self.db_cursor.fetchone()


--
Robert K. Day
robert.day@merton.oxon.org

[toc] | [prev] | [next] | [standalone]

#36857

On Tuesday, January 15, 2013 6:36:51 AM UTC-8, Rob Day wrote:
> On 15 January 2013 07:09, llanitedave <llanitedave@veawb.coop> wrote:
> 
> 
> 
> > So I put the following test code in my initialization method:
> 
> >
> 
> >     # open database file
> 
> >     self.geologger_db = sqlite3.connect('geologger.mgc')
> 
> >     self.db_cursor = self.geologger_db.cursor()
> 
> >     self.foreign_key_status = self.db_cursor.execute("PRAGMA foreign_keys = ON")
> 
> >     self.foreign_key_status = self.foreign_key_status.fetchone()
> 
> >
> 
> >     print self.foreign_key_status
> 
> >
> 
> > I ran this several times while I was arranging the downstream queries, and each time it returned '(1,)', which means foreign keys is enabled.
> 
> >
> 
> > But I was using a variable named 'cmd1' as a placeholder until I changed the name to
> 
> > the more descriptive 'self.foreign_key_status'.  Since I made the name change, however,
> 
> > the code only returns 'None'.  Reverting to the previous variable name has no effect.
> 
> 
> 
> Hmm - your code doesn't quite match up with the docs at
> 
> http://docs.python.org/2/library/sqlite3.html. That seems to suggest
> 
> that you should call fetchone() on the cursor, not on the result of
> 
> execute().
> 
> 
> 
> Does the following work?
> 
> 
> 
>     # open database file
> 
>     self.geologger_db = sqlite3.connect('geologger.mgc')
> 
>     self.db_cursor = self.geologger_db.cursor()
> 
>     self.db_cursor.execute("PRAGMA foreign_keys = ON")
> 
>     print self.db_cursor.fetchone()
> 
> 
> 
> 
> 
> --
> 
> Robert K. Day
> 
> robert.day@merton.oxon.org

Thanks for the suggestion, Rob, but that didn't make any difference.  I've never had an issue with putting the execute object into a variable and calling "fetch" on that variable.  

I can accept reality if it turns out that foreign keys simply isn't enabled on the Python distribution of sqlite, although I don't know why that should be the case.  I'm just curious as to why it worked at first and then stopped working.

[toc] | [prev] | [next] | [standalone]

#36861

On 15 January 2013 15:51, llanitedave <llanitedave@veawb.coop> wrote:
> Thanks for the suggestion, Rob, but that didn't make any difference.  I've never had an issue with putting the execute object into a variable and calling "fetch" on that variable.
>
> I can accept reality if it turns out that foreign keys simply isn't enabled on the Python distribution of sqlite, although I don't know why that should be the case.  I'm just curious as to why it worked at first and then stopped working.

Well - you might be able to accept that, but I'm not sure I can! If it
was working before, it must be compiled in, and so it must be possible
to make it work again.

http://www.sqlite.org/foreignkeys.html#fk_enable seems to suggest that
"PRAGMA foreign_keys = ON" never returns anything, and it's only
"PRAGMA foreign_keys" which returns 0, 1 or None (when unsupported).
With that in mind, does the following code work?

# open database file

self.geologger_db = sqlite3.connect('geologger.mgc')
self.db_cursor = self.geologger_db.cursor()
self.db_cursor.execute("PRAGMA foreign_keys = ON")
self.db_cursor.execute("PRAGMA foreign_keys")
print self.db_cursor.fetchone()

[toc] | [prev] | [next] | [standalone]

#36867

On Tuesday, January 15, 2013 9:13:13 AM UTC-8, Rob Day wrote:
> On 15 January 2013 15:51, llanitedave <llanitedave@veawb.coop> wrote:
> 
> > Thanks for the suggestion, Rob, but that didn't make any difference.  I've never had an issue with putting the execute object into a variable and calling "fetch" on that variable.
> 
> >
> 
> > I can accept reality if it turns out that foreign keys simply isn't enabled on the Python distribution of sqlite, although I don't know why that should be the case.  I'm just curious as to why it worked at first and then stopped working.
> 
> 
> 
> Well - you might be able to accept that, but I'm not sure I can! If it
> 
> was working before, it must be compiled in, and so it must be possible
> 
> to make it work again.
> 
> 
> 
> http://www.sqlite.org/foreignkeys.html#fk_enable seems to suggest that
> 
> "PRAGMA foreign_keys = ON" never returns anything, and it's only
> 
> "PRAGMA foreign_keys" which returns 0, 1 or None (when unsupported).
> 
> With that in mind, does the following code work?
> 
> 
> 
> # open database file
> 
> 
> 
> self.geologger_db = sqlite3.connect('geologger.mgc')
> 
> self.db_cursor = self.geologger_db.cursor()
> 
> self.db_cursor.execute("PRAGMA foreign_keys = ON")
> 
> self.db_cursor.execute("PRAGMA foreign_keys")
> 
> print self.db_cursor.fetchone()

"http://www.sqlite.org/foreignkeys.html#fk_enable seems to suggest that "PRAGMA foreign_keys = ON" never returns anything, and it's only "PRAGMA foreign_keys" which returns 0, 1 or None (when unsupported)."

That was it, exactly, Rob.  I don't know where I got the idea that I was getting  a '1' from the 'ON' command, although I was sure that I'd seen it.  But once I just called "foreign_key" it returned just fine.

Ummm...  Obviously I was up fiddling around too late.  Yeah, that's it.


Thanks!  It's solved now.

[toc] | [prev] | [next] | [standalone]

#36870

Glad I could help!

<evangelism>
Using a local source control system like git, bzr or hg is really
useful in situations like these - it's far, far easier to debug issues
of the form "I made changes and now it's broken" when you can do `git
diff yesterday's-version today's-version` and see exactly what the
changes were.
</evangelism>

On 15 January 2013 20:29, llanitedave <llanitedave@veawb.coop> wrote:
> On Tuesday, January 15, 2013 9:13:13 AM UTC-8, Rob Day wrote:
>> On 15 January 2013 15:51, llanitedave <llanitedave@veawb.coop> wrote:
>>
>> > Thanks for the suggestion, Rob, but that didn't make any difference.  I've never had an issue with putting the execute object into a variable and calling "fetch" on that variable.
>>
>> >
>>
>> > I can accept reality if it turns out that foreign keys simply isn't enabled on the Python distribution of sqlite, although I don't know why that should be the case.  I'm just curious as to why it worked at first and then stopped working.
>>
>>
>>
>> Well - you might be able to accept that, but I'm not sure I can! If it
>>
>> was working before, it must be compiled in, and so it must be possible
>>
>> to make it work again.
>>
>>
>>
>> http://www.sqlite.org/foreignkeys.html#fk_enable seems to suggest that
>>
>> "PRAGMA foreign_keys = ON" never returns anything, and it's only
>>
>> "PRAGMA foreign_keys" which returns 0, 1 or None (when unsupported).
>>
>> With that in mind, does the following code work?
>>
>>
>>
>> # open database file
>>
>>
>>
>> self.geologger_db = sqlite3.connect('geologger.mgc')
>>
>> self.db_cursor = self.geologger_db.cursor()
>>
>> self.db_cursor.execute("PRAGMA foreign_keys = ON")
>>
>> self.db_cursor.execute("PRAGMA foreign_keys")
>>
>> print self.db_cursor.fetchone()
>
> "http://www.sqlite.org/foreignkeys.html#fk_enable seems to suggest that "PRAGMA foreign_keys = ON" never returns anything, and it's only "PRAGMA foreign_keys" which returns 0, 1 or None (when unsupported)."
>
> That was it, exactly, Rob.  I don't know where I got the idea that I was getting  a '1' from the 'ON' command, although I was sure that I'd seen it.  But once I just called "foreign_key" it returned just fine.
>
> Ummm...  Obviously I was up fiddling around too late.  Yeah, that's it.
>
>
> Thanks!  It's solved now.
> --
> http://mail.python.org/mailman/listinfo/python-list



-- 
Robert K. Day
robert.day@merton.oxon.org

[toc] | [prev] | [next] | [standalone]

#36871

Yabut I'm talking about changes I'd made 30 seconds before to code I'd written 5 minutes before.  My short-term memory is nothing to write home about, even if I could remember my mailing address!


On Tuesday, January 15, 2013 2:27:28 PM UTC-8, Rob Day wrote:
> Glad I could help!
> 
> 
> 
> <evangelism>
> 
> Using a local source control system like git, bzr or hg is really
> 
> useful in situations like these - it's far, far easier to debug issues
> 
> of the form "I made changes and now it's broken" when you can do `git
> 
> diff yesterday's-version today's-version` and see exactly what the
> 
> changes were.
> 
> </evangelism>
> 
> 
> 
> On 15 January 2013 20:29, llanitedave <llanitedave@veawb.coop> wrote:
> 
> > On Tuesday, January 15, 2013 9:13:13 AM UTC-8, Rob Day wrote:
> 
> >> On 15 January 2013 15:51, llanitedave <llanitedave@veawb.coop> wrote:
> 
> >>
> 
> >> > Thanks for the suggestion, Rob, but that didn't make any difference.  I've never had an issue with putting the execute object into a variable and calling "fetch" on that variable.
> 
> >>
> 
> >> >
> 
> >>
> 
> >> > I can accept reality if it turns out that foreign keys simply isn't enabled on the Python distribution of sqlite, although I don't know why that should be the case.  I'm just curious as to why it worked at first and then stopped working.
> 
> >>
> 
> >>
> 
> >>
> 
> >> Well - you might be able to accept that, but I'm not sure I can! If it
> 
> >>
> 
> >> was working before, it must be compiled in, and so it must be possible
> 
> >>
> 
> >> to make it work again.
> 
> >>
> 
> >>
> 
> >>
> 
> >> http://www.sqlite.org/foreignkeys.html#fk_enable seems to suggest that
> 
> >>
> 
> >> "PRAGMA foreign_keys = ON" never returns anything, and it's only
> 
> >>
> 
> >> "PRAGMA foreign_keys" which returns 0, 1 or None (when unsupported).
> 
> >>
> 
> >> With that in mind, does the following code work?
> 
> >>
> 
> >>
> 
> >>
> 
> >> # open database file
> 
> >>
> 
> >>
> 
> >>
> 
> >> self.geologger_db = sqlite3.connect('geologger.mgc')
> 
> >>
> 
> >> self.db_cursor = self.geologger_db.cursor()
> 
> >>
> 
> >> self.db_cursor.execute("PRAGMA foreign_keys = ON")
> 
> >>
> 
> >> self.db_cursor.execute("PRAGMA foreign_keys")
> 
> >>
> 
> >> print self.db_cursor.fetchone()
> 
> >
> 
> > "http://www.sqlite.org/foreignkeys.html#fk_enable seems to suggest that "PRAGMA foreign_keys = ON" never returns anything, and it's only "PRAGMA foreign_keys" which returns 0, 1 or None (when unsupported)."
> 
> >
> 
> > That was it, exactly, Rob.  I don't know where I got the idea that I was getting  a '1' from the 'ON' command, although I was sure that I'd seen it.  But once I just called "foreign_key" it returned just fine.
> 
> >
> 
> > Ummm...  Obviously I was up fiddling around too late.  Yeah, that's it.
> 
> >
> 
> >
> 
> > Thanks!  It's solved now.
> 
> > --
> 
> > http://mail.python.org/mailman/listinfo/python-list
> 
> 
> 
> 
> 
> 
> 
> -- 
> 
> Robert K. Day
> 
> robert.day@merton.oxon.org

[toc] | [prev] | [next] | [standalone]

#36872

Yabut I'm talking about changes I'd made 30 seconds before to code I'd written 5 minutes before.  My short-term memory is nothing to write home about, even if I could remember my mailing address!


On Tuesday, January 15, 2013 2:27:28 PM UTC-8, Rob Day wrote:
> Glad I could help!
> 
> 
> 
> <evangelism>
> 
> Using a local source control system like git, bzr or hg is really
> 
> useful in situations like these - it's far, far easier to debug issues
> 
> of the form "I made changes and now it's broken" when you can do `git
> 
> diff yesterday's-version today's-version` and see exactly what the
> 
> changes were.
> 
> </evangelism>
> 
> 
> 
> On 15 January 2013 20:29, llanitedave <llanitedave@veawb.coop> wrote:
> 
> > On Tuesday, January 15, 2013 9:13:13 AM UTC-8, Rob Day wrote:
> 
> >> On 15 January 2013 15:51, llanitedave <llanitedave@veawb.coop> wrote:
> 
> >>
> 
> >> > Thanks for the suggestion, Rob, but that didn't make any difference.  I've never had an issue with putting the execute object into a variable and calling "fetch" on that variable.
> 
> >>
> 
> >> >
> 
> >>
> 
> >> > I can accept reality if it turns out that foreign keys simply isn't enabled on the Python distribution of sqlite, although I don't know why that should be the case.  I'm just curious as to why it worked at first and then stopped working.
> 
> >>
> 
> >>
> 
> >>
> 
> >> Well - you might be able to accept that, but I'm not sure I can! If it
> 
> >>
> 
> >> was working before, it must be compiled in, and so it must be possible
> 
> >>
> 
> >> to make it work again.
> 
> >>
> 
> >>
> 
> >>
> 
> >> http://www.sqlite.org/foreignkeys.html#fk_enable seems to suggest that
> 
> >>
> 
> >> "PRAGMA foreign_keys = ON" never returns anything, and it's only
> 
> >>
> 
> >> "PRAGMA foreign_keys" which returns 0, 1 or None (when unsupported).
> 
> >>
> 
> >> With that in mind, does the following code work?
> 
> >>
> 
> >>
> 
> >>
> 
> >> # open database file
> 
> >>
> 
> >>
> 
> >>
> 
> >> self.geologger_db = sqlite3.connect('geologger.mgc')
> 
> >>
> 
> >> self.db_cursor = self.geologger_db.cursor()
> 
> >>
> 
> >> self.db_cursor.execute("PRAGMA foreign_keys = ON")
> 
> >>
> 
> >> self.db_cursor.execute("PRAGMA foreign_keys")
> 
> >>
> 
> >> print self.db_cursor.fetchone()
> 
> >
> 
> > "http://www.sqlite.org/foreignkeys.html#fk_enable seems to suggest that "PRAGMA foreign_keys = ON" never returns anything, and it's only "PRAGMA foreign_keys" which returns 0, 1 or None (when unsupported)."
> 
> >
> 
> > That was it, exactly, Rob.  I don't know where I got the idea that I was getting  a '1' from the 'ON' command, although I was sure that I'd seen it.  But once I just called "foreign_key" it returned just fine.
> 
> >
> 
> > Ummm...  Obviously I was up fiddling around too late.  Yeah, that's it.
> 
> >
> 
> >
> 
> > Thanks!  It's solved now.
> 
> > --
> 
> > http://mail.python.org/mailman/listinfo/python-list
> 
> 
> 
> 
> 
> 
> 
> -- 
> 
> Robert K. Day
> 
> robert.day@merton.oxon.org

[toc] | [prev] | [next] | [standalone]

#36868

On Tuesday, January 15, 2013 9:13:13 AM UTC-8, Rob Day wrote:
> On 15 January 2013 15:51, llanitedave <llanitedave@veawb.coop> wrote:
> 
> > Thanks for the suggestion, Rob, but that didn't make any difference.  I've never had an issue with putting the execute object into a variable and calling "fetch" on that variable.
> 
> >
> 
> > I can accept reality if it turns out that foreign keys simply isn't enabled on the Python distribution of sqlite, although I don't know why that should be the case.  I'm just curious as to why it worked at first and then stopped working.
> 
> 
> 
> Well - you might be able to accept that, but I'm not sure I can! If it
> 
> was working before, it must be compiled in, and so it must be possible
> 
> to make it work again.
> 
> 
> 
> http://www.sqlite.org/foreignkeys.html#fk_enable seems to suggest that
> 
> "PRAGMA foreign_keys = ON" never returns anything, and it's only
> 
> "PRAGMA foreign_keys" which returns 0, 1 or None (when unsupported).
> 
> With that in mind, does the following code work?
> 
> 
> 
> # open database file
> 
> 
> 
> self.geologger_db = sqlite3.connect('geologger.mgc')
> 
> self.db_cursor = self.geologger_db.cursor()
> 
> self.db_cursor.execute("PRAGMA foreign_keys = ON")
> 
> self.db_cursor.execute("PRAGMA foreign_keys")
> 
> print self.db_cursor.fetchone()

"http://www.sqlite.org/foreignkeys.html#fk_enable seems to suggest that "PRAGMA foreign_keys = ON" never returns anything, and it's only "PRAGMA foreign_keys" which returns 0, 1 or None (when unsupported)."

That was it, exactly, Rob.  I don't know where I got the idea that I was getting  a '1' from the 'ON' command, although I was sure that I'd seen it.  But once I just called "foreign_key" it returned just fine.

Ummm...  Obviously I was up fiddling around too late.  Yeah, that's it.


Thanks!  It's solved now.

[toc] | [prev] | [next] | [standalone]

#36858

On Tuesday, January 15, 2013 6:36:51 AM UTC-8, Rob Day wrote:
> On 15 January 2013 07:09, llanitedave <llanitedave@veawb.coop> wrote:
> 
> 
> 
> > So I put the following test code in my initialization method:
> 
> >
> 
> >     # open database file
> 
> >     self.geologger_db = sqlite3.connect('geologger.mgc')
> 
> >     self.db_cursor = self.geologger_db.cursor()
> 
> >     self.foreign_key_status = self.db_cursor.execute("PRAGMA foreign_keys = ON")
> 
> >     self.foreign_key_status = self.foreign_key_status.fetchone()
> 
> >
> 
> >     print self.foreign_key_status
> 
> >
> 
> > I ran this several times while I was arranging the downstream queries, and each time it returned '(1,)', which means foreign keys is enabled.
> 
> >
> 
> > But I was using a variable named 'cmd1' as a placeholder until I changed the name to
> 
> > the more descriptive 'self.foreign_key_status'.  Since I made the name change, however,
> 
> > the code only returns 'None'.  Reverting to the previous variable name has no effect.
> 
> 
> 
> Hmm - your code doesn't quite match up with the docs at
> 
> http://docs.python.org/2/library/sqlite3.html. That seems to suggest
> 
> that you should call fetchone() on the cursor, not on the result of
> 
> execute().
> 
> 
> 
> Does the following work?
> 
> 
> 
>     # open database file
> 
>     self.geologger_db = sqlite3.connect('geologger.mgc')
> 
>     self.db_cursor = self.geologger_db.cursor()
> 
>     self.db_cursor.execute("PRAGMA foreign_keys = ON")
> 
>     print self.db_cursor.fetchone()
> 
> 
> 
> 
> 
> --
> 
> Robert K. Day
> 
> robert.day@merton.oxon.org

Thanks for the suggestion, Rob, but that didn't make any difference.  I've never had an issue with putting the execute object into a variable and calling "fetch" on that variable.  

I can accept reality if it turns out that foreign keys simply isn't enabled on the Python distribution of sqlite, although I don't know why that should be the case.  I'm just curious as to why it worked at first and then stopped working.

[toc] | [prev] | [next] | [standalone]

#36863

[Multipart message — attachments visible in raw view] — view raw

On Monday, January 14, 2013 11:09:28 PM llanitedave wrote:
> I'm trying to get an application working in Python 2.7 and wx.Python which
> contains an embedded sqlite3 file.  There are a few tables with foreign
> keys defined.  In looking at the sqlite3 documentation, it says
> 
> "Assuming the library is compiled with foreign key constraints enabled, it
> must still be enabled by the application at runtime, using the PRAGMA
> foreign_keys command." It goes on to say that foreign keys must be enabled
> separately for each connection, which is fine as my app has only one.
> 
> So I put the following test code in my initialization method:
> 
>     # open database file
>     self.geologger_db = sqlite3.connect('geologger.mgc')
>     self.db_cursor = self.geologger_db.cursor()
>     self.foreign_key_status = self.db_cursor.execute("PRAGMA foreign_keys =
> ON") self.foreign_key_status = self.foreign_key_status.fetchone()
> 
>     print self.foreign_key_status
> 
> I ran this several times while I was arranging the downstream queries, and
> each time it returned '(1,)', which means foreign keys is enabled.
> 
> But I was using a variable named 'cmd1' as a placeholder until I changed the
> name to the more descriptive 'self.foreign_key_status'.  Since I made the
> name change, however, the code only returns 'None'.  Reverting to the
> previous variable name has no effect.
> 
> Yes, I'm closing the connection with self.db_cursor.close() at the end of
> each run.
> 
> According to the sqlite3 website, getting no return value, not even a '0',
> means that "the version of SQLite you are using does not support foreign
> keys (either because it is older than 3.6.19 or because it was compiled
> with SQLITE_OMIT_FOREIGN_KEY or SQLITE_OMIT_TRIGGER defined)."
> 
> How can that be a compilation issue when it worked previously?  Does this
> somehow relate to it being a Python plugin instance?
> 
> I'm very confused.

I haven't run this myself but after 

self.foreign_key_status.fetchone()

try :
 self.geologger_db.commit()

then close the db

jimonlinux

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web