Salve a tutti, stiamo facendo un corso di Qgis e stiamo provando ad utilizzare spatialite.
Dopo aver creato con successo una tabella, successivamente abbiamo provato a crearne una nuova e abbiamo iniziato a ricevere SQL error. Database is locked.
Abbiamo provato a chiudere sia QGis che spatialite-gui e anche a Riavviare la macchina, ma il database rimane bloccato.
Suggerimenti?
Ciao e grazie!
Luca
On Wed, 27 Mar 2013 15:30:23 +0100, Luca Mandolesi wrote:
Salve a tutti, stiamo facendo un corso di Qgis e stiamo provando ad
utilizzare spatialite.
Dopo aver creato con successo una tabella, successivamente abbiamo
provato a crearne una nuova e abbiamo iniziato a ricevere SQL error.
Database is locked.Abbiamo provato a chiudere sia QGis che spatialite-gui e anche a
Riavviare la macchina, ma il database rimane bloccato.
Luca,
sinceri rallegramenti; e' la prima volta in assoluto che sento una
roba del genere, direi state esplorando frontiere ancora ignote alla
scienza ufficiale 
giusto per curiosita': quali versioni di sqlite / qgis ?
ma soprattuto: su quale sistema operativo ?
N.B.: SQLite non e' minimamente pensato per gestire accessi concorrenti
in scrittura.
detto in soldoni: e' bene che un unico processo alla volta cerchi di fare
delle operazioni di scrittura. tanto a maggior ragione se le connessioni
avvengono usando due librerie distinte che appartengono a due diverse versioni
di SQLite.
quello che e' invece ragionevole e' *leggere* un medesimo DB-file da parte
di molti processi concomitanti; ma deve trattarsi appunto di pure operazioni
di lettura senza alcuna scrittura (come ovviamente non e' per una CREATE TABLE).
insomma, se gli accessi concorrenti sono un prerequisito indispensabile, usare
sqlite / spatialite e' assolutamente fuori discussione: in questi casi occorre
evidentemente usare un DBMS client/server come PostgreSQL.
il punto piu' sconcertante e' che il DB-file resti bloccato anche dopo che
hai riavviato il sistema.
per quanto a mia conoscenza, SQLite si basa per intero sul locking di sistema,
e quindi evidentemente non puo' lasciare tracce di sorta dopo un reboot.
quindi ritengo molto piu' probabile che il problema sia piuttosto nel logfile:
se guardi bene, vedrai che ogni volta che apri in scrittura/aggiornamento un
DB SQLite nella medesima cartella appare magicamente un logfile che ha un
nome strettamente analogo a quello del DB-file.
- se lo trovi, prova a cancellarlo manualmente; magari puo' servire a ripristinare
correttamente il funzionamento del tuo DB (ovviamente perderai le ultime modifiche).
- se invece non esiste, temo che l'unica spiegazione ragionevole e' quella di
presumere che una qualche dissennata interazione tra due versioni contrastanti
della libsqlite abbia finito per danneggiare fisicamente il DB-file.
in questo caso puoi sempre provare ad usare lo strumento analyzer di SQLite
per avere ulteriori lumi. lo trovi qua: http://www.sqlite.org/download.html
ciao Sandro
--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.
Luca scusa,
mi accorgo solo ora che lo dici nell'intestazione che usi Debian;
ovviamente se sei su Linux devi anche controllare se tutti quanti i permessi
di accesso (per il DB-file, per il logfile e per la directory che ospita
entrambi) sono coerenti.
se p.es. il tuo processo non riesce a creare (o cancellare) il logfile non e'
per nulla insolito che possano saltare fuori errori abbstanza fantasiosi.
ciao Sandro
--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.
Vedo che come errore pysqlite lo conosce bene: http://trac.edgewall.org/wiki/PySqlite#OperationalError:databaseislocked
La versione di sqlite3 che ho a disposizione è la 3.7.3
Il plugin che stiamo usando sotto Qgis è Qspatialite.
Il database è usato da un solo utente e il problema si è presentato dopo aver provato ad aggiungere una tabella col plugin Qspatialite; pochi secondi prima ne avevamo aggiunte altre senza problemi.
Ho provato a seguire i comandi di recover usati nel link soprastante… e il database torna a funzionare con un nuovo nome tipo recovered.db. Nonappena riuso il vecchio nome l’errore riappare.
Ora non ho modo di verificare il problema del log, domani verifico. Cmq pare che tutto sia strettamente legato al nome del file, dato che modificandolo torna a funzionare. Peccato che il progetto di QGis con molti files e molte vestizioni salta… Ho provato anche a rinominare il nome del DB nel progetto xml di Qgis ma la modifica non va a buon fine, ma non ci ho guardato molto.
Domani continuo ad indagare.
Ciao ciao
Luca
2013/3/27 <a.furieri@lqt.it>
Luca scusa,
mi accorgo solo ora che lo dici nell’intestazione che usi Debian;
ovviamente se sei su Linux devi anche controllare se tutti quanti i permessi
di accesso (per il DB-file, per il logfile e per la directory che ospita
entrambi) sono coerenti.se p.es. il tuo processo non riesce a creare (o cancellare) il logfile non e’
per nulla insolito che possano saltare fuori errori abbstanza fantasiosi.ciao Sandro
–
Il messaggio e’ stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e’
risultato non infetto.
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e’ una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell’Associazione GFOSS.it.
638 iscritti al 28.2.2013
Mi sono gia' imbattuto in questo genere di errore,
ma era un caso differente.
Avevo tentato di leggere uno spatialite 4.0 da qgis su windows.
Poiche' il driver di splite nn era allineato, qgis crasho', rimanendo zombie.
Cosi' facendo mantenne il db locked e mi costrinse a riavviare il pc.
Al riavvio pero' il db era sbloccato.
Qui mi pare di capire che è rimasto bloccato.
Questo è molto strano.
L'unica spiegazizone che mi do' è che il db si trovava in uno stato
ibrido e quando hai riavviato lui è rimasto in tale stato.
Una cosa di questo genere potrebbe succedere se ad esempio le
transazioni sono state disabilitate.
Altrimenti si sarebbe scatenato un rollback che avrebbe ripristinato
uno stato valido.
Il 27 marzo 2013 15:30, Luca Mandolesi <mandoluca@gmail.com> ha scritto:
Salve a tutti, stiamo facendo un corso di Qgis e stiamo provando ad
utilizzare spatialite.
Dopo aver creato con successo una tabella, successivamente abbiamo provato a
crearne una nuova e abbiamo iniziato a ricevere SQL error. Database is
locked.Abbiamo provato a chiudere sia QGis che spatialite-gui e anche a Riavviare
la macchina, ma il database rimane bloccato.Suggerimenti?
Ciao e grazie!
Luca_______________________________________________
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni
dell'Associazione GFOSS.it.
638 iscritti al 28.2.2013
--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Il 27/03/2013 19:44, Luca Mandolesi ha scritto:
Vedo che come errore pysqlite lo conosce
bene: http://trac.edgewall.org/wiki/PySqlite#OperationalError:databaseislockedLa versione di sqlite3 che ho a disposizione è la 3.7.3
Il plugin che stiamo usando sotto Qgis è Qspatialite.
Usa DB Manager.
Saluti.
- --
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc
Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlFTRKsACgkQ/NedwLUzIr713ACgsLxrcbvY7UQaW614WoQNYZ8W
O4QAnAtgJAGyyceBbtStSeHvwWNYzjtt
=PXE8
-----END PGP SIGNATURE-----
On Wed, 27 Mar 2013 19:44:12 +0100, Luca Mandolesi wrote:
Il database è usato da un solo utente e il problema si è presentato
dopo aver provato ad aggiungere una tabella col plugin Qspatialite;
pochi secondi prima ne avevamo aggiunte altre senza problemi.
se e' veramente come dici, allora sembrerebbe un problema tutto
interno al connector Python (pysqlite, oppure pyspatialite).
torna abbastanza bene; infatti io che non uso mai Python ma uso
direttamente le API C/C++ non ho mai visto nulla di simile.
nota bene: se usi pyspatialite erano gia' state sollevati numerosi
dubbi sulla sua effettiva stabilita', visto che pare che in molti casi
venga distribuita una versione che incorpora una "copia interna" di
libsqlite (possibilmente diversa dalla libsqlite di sistema).
non so darti ulteriori dettagli (pyspatialite, a dispetto del nome,
si basa su spatialite ma non e' "roba mia").
Ecluderei che questo possa accadere su Debian, visto che ha due packagers
"belli tosti" come Frankie e Dapal, che sono due vecchie rocce
Ho provato a seguire i comandi di recover usati nel link
soprastante... e il database torna a funzionare con un nuovo nome tipo
recovered.db.
Ora non ho modo di verificare il problema del log, domani verifico.
Cmq pare che tutto sia strettamente legato al nome del file, dato che
modificandolo torna a funzionare.
pare decisamente la conferma di un problema legato al logfile.
l'associazione tra db-file e log-file ovviamente avviene perche' hanno
nomi direttamente correlati.
se tu rinomini il db-file ottieni sostanzialmente lo stesso risultato come
se tu cancellassi il log-file; in ogni caso spezzi il legame tra i due,
perche' ovviamente verrà creato un ulteriore log-file "vergine" corrispondente
al nuovo nome, mentre l'altro verra' del tutto ignorato.
Nonappena riuso il vecchio nome l'errore riappare.
direi che questo ci toglie anche gli ultimi dubbi residui, no ?
qualcosa di malefico e' sicuramente accaduto a quel disgraziato log-file
giusto per completezza: non appena SQLite tenta di modificare il DB (INSERT,
UPDATE, DELETE, CREATE etc) col cavolo che va a scrivere direttamente nel
DB-file. non puo' farlo, perche' e' ACID e transazionale.
quindi tutte le modifiche vengono temporaneamente scritte nel log-file;
solo quando ti decidi ad eseguire una COMMIT, finalmente le modifiche vengono
consolidate definitivamente nel DB-file, ed il log-file verra' cancellato dato
che non serve piu' a nulla.
cosa succede se per qualche motivo il sistema si blocca all'improvviso mentre
hai una qualche transazione sospesa ?
(abort secco, p.es. caduta di alimentazione elettrica).
e' abbastanza ovvio: quando andrai a riaprire una nuva connessione, per prima
cosa SQLite andra' a verificare se esiste un log-file corrispondente.
e cerchera' di utilizzarlo per riportare comunque il db-file in uno stato
pienamente consistente.
se per qualsiasi motivo (come sta accadendo a te) SQLite non riesce a leggere
correttamente il log-file sei in stallo matto; la connessione non potra' mai
andare a buon fine, ed il problema diventera' perfettamente ciclico.
ciao Sandro
--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.