On 2008-06-03 14:29, James A. Donald wrote:
On Tue, 03 Jun 2008 12:07:07 +0200, "M.-A. Lemburg" <[EMAIL PROTECTED]>
wrote:
As others have mentioned, in systems that have long running logical
transactions, it's usually best to collect the data until the very
end and then apply all changes in one
On Tue, 03 Jun 2008 12:07:07 +0200, "M.-A. Lemburg" <[EMAIL PROTECTED]>
wrote:
> As others have mentioned, in systems that have long running logical
> transactions, it's usually best to collect the data until the very
> end and then apply all changes in one go (and one database
> transaction).
I u
On 2008-06-03 00:17, James A. Donald wrote:
On Wed, 21 May 2008 07:23:04 -0700 (PDT), Paul Boddie
MySQL appears to use "repeatable read" by default [1] as its
transaction isolation level, whereas PostgreSQL (for example) uses
"read committed" by default [2]. I would guess that if you were using
On 3 Jun, 00:17, James A. Donald <[EMAIL PROTECTED]> wrote:
> On Wed, 21 May 2008 07:23:04 -0700 (PDT), Paul Boddie
>
> > MySQL appears to use "repeatable read" by default [1] as its
> > transaction isolation level, whereas PostgreSQL (for example) uses
> > "read committed" by default [2]. I would
On Mon, 02 Jun 2008 20:59:09 -0700, <[EMAIL PROTECTED]> wrote:
James A. Donald
> > If one has transactions open for a long time, or transactions that
> > involve a great deal of data, this will result in poor performance or
> > poor scalability. But one may have such large transactions without
On Wed, 21 May 2008 07:23:04 -0700 (PDT), Paul Boddie
> MySQL appears to use "repeatable read" by default [1] as its
> transaction isolation level, whereas PostgreSQL (for example) uses
> "read committed" by default [2]. I would guess that if you were using
> PostgreSQL, this particular problem wo
On 23 Mai, 17:18, John Nagle <[EMAIL PROTECTED]> wrote:
>
> Exactly. Although it seems counterintutive, it's not enough
> to do a COMMIT after UPDATE and INSERT operations. You also have to
> do a COMMIT after a SELECT if you're going to reuse the database handle
> and do another SELECT. Ot
Paul Boddie wrote:
On 21 Mai, 15:22, [EMAIL PROTECTED] wrote:
I did and I confirmed this by modifying the data, selecting it from
the mysql command line client to verify the changes, then running the
report again. If I exit the application and then start it again,
everything works as expected un
On May 21, 3:23 pm, Paul Boddie <[EMAIL PROTECTED]> wrote:
> Note that if you have a connection open in your program, especially if
> that connection has already been used to select data, it may be the
> case that you then have to perform a rollback or commit before
> attempting to access newly ad
On 21 Mai, 15:22, [EMAIL PROTECTED] wrote:
>
> I did and I confirmed this by modifying the data, selecting it from
> the mysql command line client to verify the changes, then running the
> report again. If I exit the application and then start it again,
> everything works as expected until the seco
On May 21, 1:49 pm, "Jerry Hill" <[EMAIL PROTECTED]> wrote:
> Did you remember to commit your changes before re-running the report?
> Python's DB API requires that any auto-commit feature of the
> underlying database be turned off by default, so you are required to
> commit changes yourself. If y
On Wed, May 21, 2008 at 6:30 AM, <[EMAIL PROTECTED]> wrote:
> The first time you run a report, everything works as expected but if
> you run it a second time, after modifying data, it seems that the data
> from before the modification is selected on the second report run.
Did you remember to comm
Hi there,
I'm having a problem with the Python db api, using MySQL.
I've written a program with a GUI using wxPython, the GUI is contained
in main.py which imports another module - reports.py. There are
several reports that are selected using the gui, and each report is a
class in the file report
13 matches
Mail list logo
