cancellazione record in table sqlite3

[md9327]

Per caso non viene chiusa la connessione ?
E' probabile che il file sqlite rimanga aperto per qualche motivo, non permettendone più la lettura da qualche altra applicazione che, invece, controlla il bit di chiusura.

Un consiglio per i campi autoincrement: se in ambiente multiutenza, nel range di tempo tra la lettura dell'ultimo valore, e la scrittura dello stesso incrementato, potrebbero esserci degli accessi contemporanei che rendono invalido lo sforzo. Se prendiamo il caso che il valore corrente sia 10, e predisponiamo il successivo inserimento con il valore 11, e se qualcuno nel frattempo chiede la stessa cosa, anche quest'ultimo imposterà il valore 11, per cui il database avrà due "11", incasinando così la chiave. Ovviamente, se è presente un controllo da parte del database (come su MySQL o PostgreSQL), l'ultimo record verrebbe rigettato, riportando un errore, ma in sqlite non sò cosa possa accadere...

[g.paolo]

Ci avevo gia pensato infatti, e la tua osservazione cade proprio a fagiuolo!
Pensavo di aggiungere un campo boolean ad ogni table, e quando il primo lo apre in EDIT, la prima operazione che fa lo mette TRUE come impegnato, così gli altri possono solo leggerlo fintantochè le modifiche apportate non sono chiuse.
Non so se funzionerà, ma penso di provarci.

[md9327]

Bè, così in fondo simuli il lock del record...
Però fai sempre attenzione alle modifiche concorrenti...

[g.paolo]

Bisogna proprio essere oltremodo sfigati per arrivare a registrare contemporaneamente il blocco nel medesimo microsecondo!
Io intendo infatti registrare il nuovo record vuoto con il flag di blocco prima di effettuare le modifiche finali e pertanto penso sia alquanto improbabile una sovrapposizione di eventi, non credi?
Nel momento in cui il secondo utente accede al medesimo record per attivare il proprio flag di blocco, trovandolo occupato gli viene ritornato il messaggio di indisponibilità e pertanto gli viene proposto il nuovo record seguente.
Se invece si tratta di EDIT, il primo che accede lo blocca e gli altri ricevono il mess di indisponibilità.
Dimmi dove fa acqua il mio ragionamento per cortesia.

[md9327]

Nessuna pecca nel tuo ragionamento logico, ma per quanto riguarda la sfiga ti faccio presente la "Legge di Murphy" e, comunque e a parte gli scherzi, il problema si verifica in percentuale proporzialmente al numero di utenti connessi. Ovviamente se sei solo tu, la cosa non si verifica.

La logica di locking e della contemporaneità degli eventi, è una logica abbastanza complessa, e comunque adottata da tutti i dbms più evoluti. Su sqlite non ho esperienza, per cui le mie parole possono essere buttate al cesso, se sqlite già prevede questa logica.

Ad ogni modo, la tua implementazione può andare bene.

Approvo ! :-)

[g.paolo]

Grazie Gran Maestro, le tue parole mi confortano!

[fsurfing]

scusate ma sqlite è un database locale per cui credo che il problema di due utenti che scrivano un record nello stesso istante non si può verificare a meno che un utente non utilizzi contemporaneamente due programmi.
secondo mettere una routine di blocco  all' interno di un programma è inutile
visto che il programma lo realizziamo noi ed eviteremo di lasciare procedure con database aperti.

Secondo me ogni procedura che accede al db deve sempre essere lei ad aprire la connessione e di conseguenza a chiuderla, evitando di avere una apertura della connessione a inizio programma e la chiusura a fine programma  :-)

[leo72]

Per evitare problemi di sovrapposizione di accessi, penso basti dire al DB di utilizzare una connessione esclusiva con "BEGIN EXCLUSIVE". In questo modo ogni accesso successivo al DB verrà bloccato finché essa non sarà terminata.

[g.paolo]

@fsurfing
Se io metto il DB Sqlite su un server come backend ed installo i frontend sui client che ne elaborano i dati, non faccio nulla di più di quello che faccio ora con due file Access, uno sul server con i soli dati, ed uno sui client con il prg di gestione.
Quindi in tal caso il problema si pone eccome, a meno che qualcuno mi dica che non è possibile accedere ad un file SQlite3 nel modo che ho appena spiegato.

@Leo
E' una cosa che voglio proprio provare quella che hai detto; se così fosse penso che Sqlite si meriti qualche apprezzamento in più.

[fsurfing]

@darth, non vorrei fare il rompiscatole... ed è anche possibile che mi sbaglio ma mi pare di aver letto tempo fa da qualche parte (Preciso é! :lol: )che sqlite non fosse affatto consigliato per utilizzo in applicazioni client-server per questioni di sicurezza ( ad esempio non puoi impostare password e utente)ma solo per qpplicazioni stand-alone.
poi ti ripeto sono anche io un profano ma sicuramente ponendo il problema qualcuno  potrà chiarirci le idee :-)

[fsurfing]

sqlite browser lo puoi trovare qui: http://sourceforge.net/projects/sqlitebrowser/

è semplicissimo, lo scarichi , lo decomprimi e lo utilizzi subito senza installarlo, vedrai che lo troverai meglio di kexi :-)

[g.paolo]

Ti ringrazio per l'informazione circa il programma. Mo lo provo subito!
Per quanto concerne come dici tu le password e la sicurezza, queste le ho sempre gestite a livello di frontend e mai sul backend che comunque era protetto in modo completo sia dalla visualizzazione che dalla modifica, e quando dico visualizzazione mi riferisco al fatto che sul disco del server non lo vedi affatto.
La gestione della sicurezza da parte di questi database con le palle, mi ha sempre lasciato un po perplesso, perchè quando una cosa non sai come funziona, diffidi sempre.
Comunque, mai dire mai, quindi voglio provare anche con MySql.

[fsurfing]

:cappello: vedo che di server e affini ne sai molto più di me!

comunque tieni presente che i dati contenuti in db sqlite si leggono benissimo con un semplice editor esadecimale in quanto non vengono criptati

[andy60]

Io uso l'editor del database di Gambas, anche quella è una strada. Per la creazione del db relazionale sto sperimentando Ombrello Kde, che non mi crea il database ma puo' esportare i comandi di creazione in una query mysql.

[leo72]

Il consiglio di usare SQLite solo per applicazioni stand-alone deriva dal fatto che non tratta i thread come gli altri DB. Quindi non ha una coda in cui inserisce le query e le esegue via via. Se ad esempio apro una transazione su una tabella per aggiungere dei dati dalla postazione A e poi vado a prendermi un caffé prima di salvare la transazione stessa, il collega sulla postazione B può modificare il DB prima di me e magari gli stessi dati a cui io stavo lavorando. Ecco perché o si utilizzano solo transazioni esclusive, in modo che dalla postazione B si abbia il messaggio di "DB occupato" oppure si crea a livello di codice un sistema di ticket in modo tale che non possano sovrapporsi 2 transazioni sugli stessi dati.