On Mon, 2010-10-25 at 22:17 +0200, Marco Fochesato wrote:
> Testato, passa anche da me nel mio database.
> Ma ci voglio capire qualcosa di più
> Ciao intanto.
Allora, siccome l'esempio di Daniele non riproduceva il mio errore.. ho
cambiato il programmino generando il MIO errore, quello della
Il giorno mar, 26/10/2010 alle 15.23 +0200, franco93it ha scritto:
> 2010/10/24 Simone Federici
> import PyZenity
> update = PyZenity.Progress(text='', percentage=0,
> auto_close=False, pulsate=False)
> update(1)
> update(2)
> update(20)
> up
2010/10/24 Simone Federici
> import PyZenity
> update = PyZenity.Progress(text='', percentage=0, auto_close=False,
> pulsate=False)
> update(1)
> update(2)
> update(20)
> update(100)
>
Grazie Simone, questo è il modo giusto.
Con pygtk fare una cosa tipo questa è fattibile anche ad un inesperto
Il giorno 26/ott/2010, alle ore 12.01, Manlio Perillo ha scritto:
> A quanto ho capito, dato che le transazioni non sono realmente (?)
> isolate, con i deferred contraint lo stato inconsistente all'interno di
> una transazione potrebbe "fuggire" al di fuori della stessa.
Questa sorta di timore c
Il 25/10/2010 15:37, Daniele Varrazzo ha scritto:
> [...]
> La soluzione di Giovanni non verteva solo sull'usare cascade nella
> definizione di fkey: posporre il check della fkey alla fine della
> transazione consente di sporchettare con i dati come si vuole, passando
> attraverso stati inconsisten
