Leggere dabase.DB sqlite3 da remote

[Giuani]

Salve a tutti,
ho realizzato un piccolo database sqlite3 gestione biblioteca libri, tutto ok.
Ora vorrei mettere il database in un sito web e leggerlo da remote.
Ho girovagato un po' sul web, ma non ho trovato una soluzione.
Domanda:
qual è  il codice Lazarus per leggere un dabase.DB sqlite3 da remote ?
Grazie dell'attenzione

[nomorelogic]

ciao
dovresti avere un dbserver remoto da qualche parte, in ascolto su una determinata porta
nella connessione invece di specificare un db locale dovresti specificare un db remoto

però non credo che sqlite3 sia una buona scelta per un db remoto
non lo conosco affatto, ma se non ricordo male è stato concepito per utilizzo locale e monoutente

forse dovresti usare mysql per questo tipo di lavori

[Giuani]

Grazie per  la risposta.
In verità ho solo caricato il database testi.DB sul sito, credendo che tale database potesse essere letto  da qualsiasi altra postazione in remote, ma da quel che leggo credo sia necessario altro sul sito remote dove è collocato il  DB testi.DB:
che cosa ?
dove lo posso trovare ?

[Stilgar]

Allora.sqlite è una librerira per lavorare in locale senza tanti sbattimenti. E' montato in tanti dispositivi embedded/mobile per la sua semplicità di utilizzo e poca necessità di risorse. Se vuoi poter leggere il tuo database da remoto devi poter permettere al tuo programma di accedere al file system del web server. Fargli credere che sia in locale, ma leggerlo da fuori. Credo che il tuo provider non veda di buon occhio la soluzione.
Se hai un piano hosting minimamente decente dovresti avere i dati di accesso al tuo db personale. In ogni caso, se sono piani "base" non dovresti poter raggiungere il database da fuori. Dovresti passare a infrastrutture un attimo più costose.
Se il web server è una macchina aziendale o domestico, chiedi al sistemista nel primo caso, nel secondo puoi installare MariaDB o FirebirdSQL.Convertire le tue tabelle sqlite in strutture relazionali remote e dialogare attraverso le librerie di accesso (dll/so).
Spero di aver dato una mano.

Stilgar

PS.A seconda delle scelte e degli scenari possiamo continuare con i suggerimenti.

[Giuani]

Si una grande mano.
Credevo a qualcosa di facile, ma ho capito che devo lavorarci sopra.
Ci provo.
Grazie di tutto.

[SB]

E' possibile usare sqlite in un sito web anche con hosting. Io lo faccio per il mio siterello.
Avendo a disposizione un sistema Windows+ASP.NET ho realizzato una dll in FP che può essere caricata dal codice C# della pagina.
A quel punto si passano alla dll i parametri che servono e puoi operare tranquillamente con FP+sqlite.
Nelle ultime versioni sqlite si è evoluto e dovrebbe essere multiutente.
Non hai le prestazioni dei DBMS più evoluti (che si pagano) ma per piccoli siti a basso traffico penso possa bastare.
Al momento funziona.
Certo può sempre succedere che in qualche modo ne blocchino l'utilizzo visto che non è previsto nel contratto di hosting.

[Giuani]

Bene, ora ci studio
Grazie SB

[DragoRosso]

@SB
"Nelle ultime versioni sqlite si è evoluto e dovrebbe essere multiutente."

No, ancora SQLite non è multiutente. Per renderlo multiutente la tua applicazione deve gestire l'accesso contemporaneo di più richieste, ma il motore di SQLite agirà sempre per singola "transaction".

Riferimento: https://www.sqlite.org/whentouse.html

Buon lavoro Giuani, hai una bellissima e appassionante sfida avanti a te.

[SB]

"Multiutente" nel senso che ammette connessioni contemporanee da parte di più utenti agli stessi file.
Poi l'accesso effettivo avviene tramite appositi interlock che limitano l'operatività.
Ovviamente non è un DBMS al pari di altri DBMS ben più corposi (e ottimizzati) che però richiedono installazione sul server o pagamento di quota extra.
Non avrà le stesse prestazioni degli altri ma per esigenze ridotte (spendere il meno possibile e pochi utenti contemporanei) potrebbe andare bene.
Certo se uno è disposto a spendere qualche centinaio di euro all'anno si può pensare a soluzioni più prestanti.

[SB]

Dal sito SQLite (https://www.sqlite.org/whentouse.html):
"Websites

SQLite works great as the database engine for most low to medium traffic websites (which is to say, most websites). The amount of web traffic that SQLite can handle depends on how heavily the website uses its database. Generally speaking, any site that gets fewer than 100K hits/day should work fine with SQLite. The 100K hits/day figure is a conservative estimate, not a hard upper bound. SQLite has been demonstrated to work with 10 times that amount of traffic.

The SQLite website (https://www.sqlite.org/) uses SQLite itself, of course, and as of this writing (2015) it handles about 400K to 500K HTTP requests per day, about 15-20% of which are dynamic pages touching the database. Dynamic content uses about 200 SQL statements per webpage. This setup runs on a single VM that shares a physical server with 23 others and yet still keeps the load average below 0.1 most of the time. "

La sua semplicità lo rende molto leggero e probabilmente il tempo di attesa per l'interlocking viene compensato dal ridotto tempo necessario per la connessione

[DragoRosso]

@SB

Concordo su quanto scrivi, ma devo solo precisare un concetto che deve essere chiaro:

"SQLite only supports one writer at a time per database file. But in most cases, a write transaction only takes milliseconds and so multiple writers can simply take turns. SQLite will handle more write concurrency that many people suspect. Nevertheless, client/server database systems, because they have a long-running server process at hand to coordinate access, can usually handle far more write concurrency than SQLite ever will."

Su questo concetto SQLite non è multiutente. Inoltre il meccanismo di "interlock", che è implementato nativamente "sul" sistema operativo può portare brutte soprese ...

"SQLite will work over a network filesystem, but because of the latency associated with most network filesystems, performance will not be great. Also, file locking logic is buggy in many network filesystem implementations (on both Unix and Windows).".

Se è necessario garantire le prestazioni (intendo sopratutto quelle di integrità), occorre pensarci molto bene prima di usarlo in maniera nativa multiutente.
Io comunque dal 2007 ho abbandonato quasi al 100% MSDE e SQLExpress, MySQL e altri a favore di SQLite (  ), che ritengo sia un ottimo database, facilmente integrabile anche in architetture client / server rendondolo perfettamente multiutente, multiconcorrente  e con prestazioni assolutamente dignitose.

Penso che siamo andati un pò OT rispetto all'argomento del thread ... mi scuso se ho trascinato la discussione ....

[Giuani]

Che si sia andato oltre va bene.
A me interessa l'aspetto didattico e non tanti quello pratico, qui trovo indicazioni per studiare.
Grazie a tutti.