informazioni per creare database

[DragoRosso]

OK DragoRosso, ovviamente hai ragione, continuo vederne il contenuto ma se chiudo la connessione mi chiude anche la query... sbaglio..?

Non puoi avere componenti DB attivi senza connessione al database. Quindi ritengo, ma è da verificare, che tutti le query e gli altri componenti legati alla connessione vengano chiusi e gli eventuali risultati vengano posti a nil.

Ciao

[Maurizio De Santis]

OK DragoRosso, ovviamente hai ragione, continuo vederne il contenuto ma se chiudo la connessione mi chiude anche la query... sbaglio..?

Non puoi avere componenti DB attivi senza connessione al database. Quindi ritengo, ma è da verificare, che tutti le query e gli altri componenti legati alla connessione vengano chiusi e gli eventuali risultati vengano posti a nil.

Ciao

Chiarissimo DragoRosso, cercavo questa conferma, quindi per poter usare sqlit3 in multiutenza debbo limitare l'I/O e trasferire i risulatati delle query in un buffer in memoria..! Grazie ancora..!

[DragoRosso]

Come diceva @xinyiman, puoi usare un dataset in memoria copiando le tabelle che ti servono, così eviti di fare tanti I/O.

Fai attenzione, lavorare in rete con SQLite (ma pure con altri insieme di dati, qualsiasi essi siano) è abbastanza rischioso. La funzionalità del database viene garantita se il DB stesso si trova nello stesso sistema in cui opera la DLL (non c'è scritto da nessuna parte questo, ma basta leggere le note sul sito di SQLite https://sqlite.org/index.html per capirlo).

Non è pensato ne strutturato per lavorare in rete. Se cerchi nel ns. forum SQLITE troverai delle discussioni anche "accese" su ciò.

Ciao

[Maurizio De Santis]

Come diceva @xinyiman, puoi usare un dataset in memoria copiando le tabelle che ti servono, così eviti di fare tanti I/O.

Fai attenzione, lavorare in rete con SQLite (ma pure con altri insieme di dati, qualsiasi essi siano) è abbastanza rischioso. La funzionalità del database viene garantita se il DB stesso si trova nello stesso sistema in cui opera la DLL (non c'è scritto da nessuna parte questo, ma basta leggere le note sul sito di SQLite https://sqlite.org/index.html per capirlo).

Non è pensato ne strutturato per lavorare in rete. Se cerchi nel ns. forum SQLITE troverai delle discussioni anche "accese" su ciò.

Ciao

Grazie DragoRosso ho letto un poco dei post relativi alla concorrenza e lo approfondirò sicuramente ...
tieni presente che che gli accessi all'archivio saranno veramente il minimo sindacale risolvo il problema
delle connessioni gestendo le tabelle in questo modo:

type
    VociTF = record

    ID_VociTF    : integer;
    Tipo            : string[1];
    CapoFila      : string[1];
    Codice         : string[10];
    Descrizione  : string[100];
end;

ArrayVociTF : array of VociTF;

Quanto sopra per ogni tabella, in questo modo evito anche le singole select agli ID e poi stiamo a vedere...

Ho ripreso un progetto che avevo già realizzato moltissimi anni or sono e dei quali ho ... PERSO I SORGENTI ...
credo di essere un maniaco per eccellenza dei backup ... che dire..?

Dammi se puoi un parere sulla mia soluzione di tipizzare gli array o se pensi ad altra soluzione ... Grazie ancora a tutti voi..!


 

[DragoRosso]

type
    VociTF = record

    ID_VociTF    : integer;
    Tipo            : string[1];
    CapoFila      : string[1];
    Codice         : string[10];
    Descrizione  : string[100];
end;
ArrayVociTF : array of VociTF;

Quanto sopra per ogni tabella, in questo modo evito anche le singole select agli ID e poi stiamo a vedere...
Ho ripreso un progetto che avevo già realizzato moltissimi anni or sono e dei quali ho ... PERSO I SORGENTI ...
credo di essere un maniaco per eccellenza dei backup ... che dire..?
Dammi se puoi un parere sulla mia soluzione di tipizzare gli array o se pensi ad altra soluzione ... Grazie ancora a tutti voi..!

Và bene anche il classico array. Era più elegante un dataset virtuale, ma se non hai necessità di visualizzarle in controlli visuali và bene così.

E comunque se dovessi visualizzarli, invece di usare un controllo DB userai un controllo normale con la complicazione di riempirlo a codice.

Ciao.

[Maurizio De Santis]

Ragazzi, sono basito ... ho posto questa domanda a chatGPT: multiutenza con sqllite3

Ecco la risposta:

SQLite3 supporta l'accesso multiutenza al database, il che significa che più utenti possono accedere contemporaneamente allo stesso database. Tuttavia, è importante prendere alcune precauzioni per garantire che l'accesso multiutenza non causi problemi di concorrenza o corruzione del database.

Ecco alcuni suggerimenti per supportare l'accesso multiutenza a un database SQLite3:

Utilizza una connessione al database separata per ogni utente che accede al database. In questo modo, ogni utente ha la propria istanza del database e le operazioni di scrittura effettuate da un utente non interferiranno con quelle degli altri utenti.

Utilizza il meccanismo di blocco di SQLite3 per garantire che le operazioni di scrittura siano effettuate in modo sicuro. SQLite3 utilizza un sistema di locking basato sui file per garantire che solo un utente alla volta possa scrivere sul database. Ciò significa che se un utente sta scrivendo sul database, gli altri utenti possono solo leggere il database e non possono effettuare operazioni di scrittura.

Utilizza la transazione di SQLite3 per garantire l'integrità dei dati. Le transazioni consentono di eseguire una serie di operazioni di scrittura come un'unità atomica, in modo che tutte le operazioni di scrittura vengano eseguite o tutte vengano annullate in caso di errore. Ciò garantisce che il database rimanga in uno stato coerente anche in caso di problemi di concorrenza.

Evita di utilizzare tabelle temporanee condivise tra gli utenti, poiché ciò può causare problemi di concorrenza. Se è necessario utilizzare tabelle temporanee, assicurati di creare una tabella temporanea separata per ogni utente.

Assicurati che tutti gli utenti utilizzino la stessa versione del database. Se si utilizzano versioni diverse del database, potrebbero verificarsi problemi di compatibilità che causano problemi di corruzione dei dati.

In generale, è importante prestare attenzione alla progettazione e all'implementazione del sistema multiutenza per garantire la sicurezza e l'integrità dei dati del database.

PS... lo sto usando per la prima volta...!

[DragoRosso]

Ho sempre detto che ChatGPT è oltre .... 

A parte gli scherzi, SQLite non è multiutenza nativamente.

Puoi renderlo multiutenza posizionando tra i client e il db un tuo server (programma server) che gestisca la multiutenza e soprattutto la comunicazione. In pratica i client non faranno accesso diretto al DB ma solo al tuo server.

Ricordiamoci sempre che l'accesso al DB tramite SQL è senza crittografia, indi per cui il traffico è visibile (a meno che tu non crittografi il contenuto a priori) in rete.

Ma a questo punto forse è meglio pensare ad un'altra struttura con DB diversi (tipo FireBird ad esempio) che è multiutenza.

Per ciò che riguarda ChatGPT invece, è sempre necessario prendere con le pinze quanto suggerisce. L'IA che vediamo nei film (dal mitico Blade Runner originale, al Io Robot) non esiste ancora ... per fortuna almeno per il nostro tempo.

Ciao

[Maurizio De Santis]

Ho sempre detto che ChatGPT è oltre .... 

A parte gli scherzi, SQLite non è multiutenza nativamente.

Puoi renderlo multiutenza posizionando tra i client e il db un tuo server (programma server) che gestisca la multiutenza e soprattutto la comunicazione. In pratica i client non faranno accesso diretto al DB ma solo al tuo server.

Ricordiamoci sempre che l'accesso al DB tramite SQL è senza crittografia, indi per cui il traffico è visibile (a meno che tu non crittografi il contenuto a priori) in rete.


Ma a questo punto forse è meglio pensare ad un'altra struttura con DB diversi (tipo FireBird ad esempio) che è multiutenza.

Per ciò che riguarda ChatGPT invece, è sempre necessario prendere con le pinze quanto suggerisce. L'IA che vediamo nei film (dal mitico Blade Runner originale, al Io Robot) non esiste ancora ... per fortuna almeno per il nostro tempo.

Ciao

Ciao DragoRosso, io ho scoperto chatGPT oggi e mi ha lasciato basito per il supporto in termini di linguaggi di programmazione con esempi chiari ed esaustivi ... certo sempre e comunque con le pinze ... comunque il supporto alla programmazione è eccellente..!😉👍

[giacomarko]

Chat GPT  a parte,

provato anche io per quel programma sostitutivo della barra di Windows di qualche mese fa, alla fine il supporto non è stato risolutivo e la soluzione è arrivata dal forum, non mi ha impressionato più di tanto,

detto questo domando per curiosità,

non capisco perché voler usare un DB, che non è progettato per la multiutenza, e infarcirlo di controlli per usarlo in multiutenza,

con tutti i rischi del caso, e i problemi che ne potrebbero derivare,

m

[bonmario]

detto questo domando per curiosità,

non capisco perché voler usare un DB, che non è progettato per la multiutenza, e infarcirlo di controlli per usarlo in multiutenza,

con tutti i rischi del caso, e i problemi che ne potrebbero derivare,

m

Per quanto mi riguarda, l'ho fatto tempo fa con un progetto ormai in disuso, per pura semplicità e comodità: a memoria, per far funzionare SQLite, basta copiare una dll nella stessa directory dove c'è l'eseguibile. Per quanto riguarda quel progetto, sapevo già in partenza che il programma sarebbe stato usato al massimo da 3 o 4 persone contemporaneamente, ma che la probabilità che 2 o più persone avessero potuto scrivere nel DB contemporaneamente erano quasi nulle. Quindi, avevo gestito il tutto tramite un file civetta, che mi permetteva di capire se potevo scrivere o se dovevo aspettare perché altri stavano scrivendo.
Il programma è stato usato per 2 o 3 anni senza nessun problema dal punto di vista della concorrenzialità.

Ciao, Mario

[giacomarko]

Capito,

resta però una soluzione "anomala",

dove giochi la carta che serve solo una dll, a fronte del fatto di gestire gli accessi al DB, per una cosa che nasce limitata e quasi nulla espandibile,

voglio dire,

ti avessero chiesto, un anno dopo, abbiamo necessità di ampliare, allargare il numero di utenti....
avresti dovuto cambiare tutto,

non è che personalmente SQLite lo schifo, di fatto lo uso principalmente per le configurazione personali.

[tito_livio]

Anche se la concorrenza è poca o nulla, mettere il file sqlite su di un server è una cosa che non farei (quasi) mai.
Con sqlite non c'è un programma che per noi fa le query sul server ma la query viene fatta, elaborata, dal pc client.
Quindi tutti i dati della o delle tabelle interessate devono "camminare" attraverso la rete per essere elaborati sul client e poi eventualmente devono tornare i record modificati se ce ne sono.
A questo punto il programma diventa lento se cresce come quantità di dati oppure se si usa una connessione lenta.
Quindi, una volta che si comincia a costruire una nuova applicazione e se si pensa che i dati col tempo poi diventino tanti, secondo me è meglio partire col piede giusto.

[bonmario]

Naturalmente, ognuno fa le valutazioni in base al caso specifico.
Nell'esempio che ho fatto prima, si sapeva già in partenza che quello era un programma che sarebbe durato per 2 o 3 anni al massimo, e delle altre considerazioni che ho spiegato prima.

Naturalmente, se il contesto fosse stato diverso, quindi col sospetto che il numero di utenti sarebbe potuto aumentare, o altro, avrei fatto il tutto con Firebird o altro.

Ciao, Mario

[DragoRosso]

L'uso di un DB o un altro dipende prevalentemente dallo scopo e dal grado di domestichezza che ha il programmatore con i DB / RDBMS e con il linguaggio di programmazione (tipo Lazarus, ASP, .net, etc ...) e con il linguaggio di interfacciamento con il motore DB (normalmente SQL).

Se pensate che SQLite non necessita di installazione, provate viceversa a pensare all'installazione e manutenzione di DB che invece hanno necessità di essere installati e mantenuti (FireBird in primis ad esempio). E le console di gestione e manutenzione ?

Un utente alla prime armi vede e segue delle dinamiche che gli appaiono più semplici, ma d'altronde tali utenti non gestiscono ovviamente il magazzino di Amazon ... 

L'uso di SQLite è sempre stato sconsigliato in RETE e in Multiutenza: ovviamente se gestiamo i ns. conti della spesa ... bhè allora forse è giustificato, non è che se perdiamo la registrazione di uno scontrino ci arriva la finanza a casa.

Ciao