Spatialite e Qspatialite: Messaggio di Errore sotto Debian Linux - SQL error. Database is locked

[mando]

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

_______________________________________________
[hidden email]
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

[a.furieri]

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.

_______________________________________________
[hidden email]
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

[a.furieri]

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.

_______________________________________________
[hidden email]
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

[mando]

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 <[hidden email]>

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.

_______________________________________________
[hidden email]
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

_______________________________________________
[hidden email]
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]

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 <[hidden email]> 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
>
> _______________________________________________
> [hidden email]
> 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 àèìòù
-----------------
_______________________________________________
[hidden email]
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

[pcav]

-----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:databaseislocked
>
> La 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-----
_______________________________________________
[hidden email]
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

[a.furieri]

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.

_______________________________________________
[hidden email]
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