Gambas-it

Programmazione => Programmazione in generale => Topic aperto da: Picavbg - 03 Novembre 2018, 12:30:57

Titolo: [Risolto] DB.SqLite - volumi supportabili
Inserito da: Picavbg - 03 Novembre 2018, 12:30:57
Buongiorno a tutti.
Come alcuni di voi sanno, l'unico mio programmone in Gambas3 si chiama ContabFam e gestisce all'interno delle sue classi un DB Sqlite3.
Quest'ultimo, dopo anni di accumulo dati, distribuiti nelle sue 13 tabelle , ha raggiunto volumi ragguardevoli. Ordinariamente i tempi di risposta sono eccellenti, tranne che quando avvio la ricerca per la stampa dei movimenti contabili registrati per una giornata qualunque delle di tutte quelle presenti, nel DB.
Per la ricerca dei movimenti viene eseguito un 'accesso al DB per  lo scorrimento dei record contenuti principalmente nella tabella dei movimenti giornalieri di cassa che contiene al momento oltre 54000 record (complessivamente il DB è formato da circa 106000 record). Per la precisione,  dalla schedulazione dell'evento, alla emissione della finestra contenenti i dati richiesti, passano circa 24". Mi sembrano veramente tanti.
Rispetto a circa 2 anni fa il tempo d'attesa è più che raddoppiato , perciò penso che continuando ad ingrossare il volume del DB, più avanti, potrò benissimo avviare la richiesta, e nel frattempo, andare a prendere un caffè al bar. Al mio rientro, troverò la finestra coi movimenti della giornata.  ;)
Allora ... per evitare  di prendere dover troppi caffè, sto cercando una soluzione, in modo da fare rientrare il tempo di risposta ad un intervallo ragionevole per un minielaboratore.
La mia lunga esperienza nel campo dell'elaborazione dei dati mi dice che le strade possibili sono 2, alternativa l'una rispetto all'altra:
- indicizzare tutte le tabelle del DB;
- frazionare il DB attuale un più DB, di ridotte dimensioni.
Le due alrrenative sono entrambi onerose, ma io non ne conosco altre.
Ricordo che all'epoca della realizzazione del mio progetto non sono riuscito a creare un indice nel DB in questione.
Chi mi vuole dare una mano ad avviare uno studio sulla riorganizzazione del DB?
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: Gianluigi - 03 Novembre 2018, 15:17:09
Per creare un indice in SQLite puoi leggere qui:
https://sqlite.org/lang_createindex.html
https://www.w3schools.com/sql/sql_create_index.asp
Gli indici vanno impostati su tabelle già create (e riempite).
Normalmente la/le colonne sono NOT NULL UNIQUE e quindi si usa la formula:
Codice: [Seleziona]
CREATE UNIQUE INDEX "nome-indice" ON nome-tabella (nome-colonna ASC o DESC);
Se i dati non sono univoci basta togliere UNIQUE.

Però visto che scrivi
Citazione
...(complessivamente il DB è formato da circa 106000 record). Per la precisione,  dalla schedulazione dell'evento, alla emissione della finestra contenenti i dati richiesti, passano circa 24". Mi sembrano veramente tanti. Rispetto a circa 2 anni fa il tempo d'attesa è più che raddoppiato...
credo che i dati siano veramente troppo pochi per causare un tale rallentamento e già due anni fa i tempi erano biblici.
A meno che tu non sia su un computer veramente lento in generale, non escluderei che le cause della lentezza siano dovute ad altri motivi, infatti poco più di 100.000 record sono una bazzecola anche per SQLite che può sopportare e trattare milioni di records.

Su questo attendo il parere degli esperti di DB.
Comunque se creando l'indice non cambia nulla..
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: Picavbg - 03 Novembre 2018, 23:42:58
Gli indici vanno impostati su tabelle già create (e riempite).
Normalmente la/le colonne sono NOT NULL UNIQUE
Ormai è passato troppo tempo dalla creazione del DB e non ricordo assolutamente come sono definite le colonne delle singole tabelle. Devo rivedere tutto, compresa la gestione del DB nel programma perchè. penso che, indicizzando le tabelle, cambi anche il codice scritto per la lettura e l'aggiornamento dei record in esso contenuti, nonchè per la registrazione di nuovi record.
Citazione
non escluderei che le cause della lentezza siano dovute ad altri motivi,
Ho provato qualche mese fa a sostituire il disco dei dati con uno di tipo SSD, ma il risultato non è cambiato, così ho continuato ad usare un disco SATA.
Credo inoltre che se il problema fosse dipendente dalla vetustà del mio pc, il problemma della lentezza si dovrebbe verificare sempre, invece si verifica solo per la ricerca dei record appartenenti alla stessa data.
 ???
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: Gianluigi - 04 Novembre 2018, 10:23:35
Se ho capito bene devi indicizzare la colonna (o sono più di una?) delle date che tu hai in formato txt.
Non credo che tu qui possa avere dei campi vuoti, faresti bene a controllare.
Probabilmente i rallentamenti sono dovuti al campo txt e a possibili NULL.
Dovresti postare la query di interrogazione e i codici di formattazione ecc. che riguardano questa colonna.
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: tornu - 04 Novembre 2018, 12:40:02
Ciao Picavbg,
io non ho mai usato SqLite, per i miei progetti sia piccoli che "grandi" ho sempre utilizzato MySql
che sicuramente a livello di gestione è similare ma dispone di strumenti e funzionalità che sicuramente
mancano a SqLite. Ma nel tuo caso dove parliamo di circa 106000 record si può dire che sicuramente non
parliamo di un "grande" Database, quindi la lentezza che hai riscontrato nel tempo nell'estrapolare i dati
tramite le tue query sicuramente è data da una ottimizzazione non corretta del DB. L'indicizzazione delle
tabelle sicuramente è la prima cosa da verificare e implementare se non presenti, è una cosa basilare,
noterai delle differenze abissali. Ti posto questo piccolo estratto da letture e informazioni acquisite nel tempo
per far capire a te (ma sicuramente già lo sai) e a chiunque approcci i DataBase.
Ottimizzare database MySQL e velocizzare le query: un esempio concreto
Si supponga, come "esempio estremo", di avere la seguente tabella MySQL:


CREATE TABLE dipendenti (
matricola char(10) NOT NULL,
nome varchar(40),
cognome varchar(40),
indirizzo text(150),
telefono varchar(25),
salario int(11),
salario_straordinario int(10) NOT NULL
);

Per estrarre dal database il dato relativo al salario del dipendente contraddistinto dall'identificativo 693369, si utilizzerà la query che segue:

SELECT salario FROM dipendenti WHERE matricola = '693369';

MySQL, però, di base non dispone di alcun "appoggio" per trovare rapidamente l'informazione cercata: dovrà quindi esaminare il contenuto dell'intera tabella (potenzialmente migliaia di record) per restituire il dato sul salario.
Utilizzando un indice, MySQL potrà viceversa trovare le informazioni richieste molto più rapidamente.
Il "segreto" consiste nel creare l'indice sul campo o sui campi per i quali si attiva la clausola WHERE di SQL.

Nell'esempio, se si crea un indice per il campo matricola, i record cercati saranno trovati da MySQL molto velocemente.

Gli indici, in MySQL, funzionano in maniera molto simile agli indici di un qualunque libro. Si immagini un testo tecnico sprovvisto di indice: per trovare il capitolo Ottimizzare MySQL bisognerà necessariamente sfogliare tutte le pagine; con un indice, invece, ci si potrà recare rapidamente alla pagina giusta.  :ciao:
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: Gianluigi - 04 Novembre 2018, 13:53:48

Ormai è passato troppo tempo dalla creazione del DB e non ricordo assolutamente come sono definite le colonne delle singole tabelle. Devo rivedere tutto, compresa la gestione del DB nel programma perchè. penso che, indicizzando le tabelle, cambi anche il codice scritto per la lettura e l'aggiornamento dei record in esso contenuti, nonchè per la registrazione di nuovi record.


Se tu scarichi l'applicazione DB Browser for SQLite, puoi fare doppio clic sul tuo database per aprirlo nell'applicazione.
Nella scheda Create Table evidenzi la query CREATE TABLE... della tabella che ti interessa e poi dalla scheda (ora agibile) Modify Table puoi vedere come è stata costruita la tabella ed eventualmente variarla.
Non servono variazioni in quanto l'indicizzazione di una o più colonne di tabella non comporta variazioni nelle query di interrogazione, le rende solo più veloci come spiegato da Tornu.
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: Picavbg - 04 Novembre 2018, 22:27:00
Grazie per le indicazioni. Farò un controllo sul DB per mettere in pratica poi quanto mi avete cortesemente suggerito.
A presto.
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: Gianluigi - 04 Novembre 2018, 23:32:02
Ti allego un piccolo progetto che filtra i record sulla colonna Data (usdat) non indicizzata, a me lo fa in pochi attimi.
Così puoi verificare su una base concreta.
Nota il database si carica di dati automaticamente all'apertura e salva in "user.home/application.name"

P.S. Ho rimosso l'allegato potete scaricarlo da qui (http://www.gambas-it.org/smf/index.php?topic=6644.msg44589#msg44589)
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: Picavbg - 05 Novembre 2018, 17:29:47
Ti allego un piccolo progetto che filtra i record sulla colonna Data (usdat) non indicizzata, a me lo fa in pochi attimi.
Così puoi verificare su una base concreta.
Grazie Gianluigi. Sei sempre disponibile e ti sono grato.
La mia lettura scansionata della tabella  movimgg (quella incriminata, contenente oltre 54000 record) è fatta attraverso il seguente codice
Codice: [Seleziona]
 i_dataStamp = Int(Val($_DataStamp))
  ApriDB = New OpenDB
  $_TbParFrm.Add("0")
  i_RgGriStamp = (-1)
  RecMovgg = ApriDB.DBConnection.EXEC("SELECT * FROM movimgg WHERE DtCoMovgg = '" & i_dataStamp & "' ORDER BY NuProMovvgg")
  For Each RecMovgg
    $_LirEuro = RecMovgg!MonMovvggPuò darsi che esista DtCoMovgg
    i_RgGriStamp += 1
    GridStamp[i_RgGriStamp, 1].text = RecMovgg!DescrMovvgg
    fImpMov = RecMovgg!ImpMovvgg
    If fImpMov > 0 Then
        i_CaselGriStamp = 3
    Else
      fImpMov *= (-1)
      i_CaselGriStamp = 4
    Endif
Riporto anche il codice relativo alla Open del DB
Codice: [Seleziona]
'------------------------------- OpenDB.Class ------------------------------------------------------------------------------------------
Public bSwOpErr As Boolean

Public DBConnection As New Connection   'inizializza la nuova connessione

'**************************--- la prossima riga  vale per tutti ---***********************
Public $DbPath As String = user.home & "/mont/dativari/contabfam"             'Percorso di ricerca del Database ContabFam.db"
Public $IconPath As String = user.home & "/mont/dativari/contabfam/IconVar"   'Persocorso di ricerca delle picture utilizzate nel programma
'***********************************************************************************************
Public $DbNome As String = "ContabFamdb"        'Nome del Database

Public Sub _new()
'----------------------------------------
  With
      DBConnection
            .Close
            .Type = "sqlite3"
            .Host = $DbPath
            .Name = $DbNome
            .OPEN    'Apro il DB
  End With'------------------------------- OpenDB.Class ------------------------------------------------------------------------------------------
Public bSwOpErr As Boolean

Public DBConnection As New Connection   'inizializza la nuova connessione

'**************************--- la prossima riga  vale per tutti ---**************************
'Public $_DbPath As String = user.home & "/contabfam"                         'Percorso di ricerca del Database ContabFam.db"
Public $DbPath As String = user.home & "/mont/dativari/contabfam"             'Percorso di ricerca del Database ContabFam.db"
Public $IconPath As String = user.home & "/mont/dativari/contabfam/IconVar"   'Persocorso di ricerca delle picture utilizzate nel programma
'***********************************************************************************************
Public $DbNome As String = "ContabFamdb"        'Nome del Database

Public Sub _new()
'----------------------------------------
  With
      DBConnection
            .Close
            .Type = "sqlite3"
            .Host = $DbPath
            .Name = $DbNome
            .OPEN    'Apro il DB
  End With
  bSwOpErr = False    'OPEN eseguita correttamente
  Catch
    bSwOpErr = True     'Errore nella Open
End
  bSwOpErr = False    'OPEN eseguita correttamente
  Catch
    bSwOpErr = True     'Errore nella Open
End
Come puoi vedere l'istruzione di lettura della tabella, oggetto della mia sofferenza è quella di selezione dei record interessanti alla mia ricerca e del successivo caricamento in una GidView, attraverso l'istruzione for each:
Codice: [Seleziona]
RecMovgg = ApriDB.DBConnection.EXEC("SELECT * FROM movimgg WHERE DtCoMovgg = '" & i_dataStamp & "' ORDER BY NuProMovvgg")
  For Each RecMovgg
L'istruzione SQL "EXEC" procede alla scansione dei record di tabella riportanti la stessa data contabile (DtCoMovgg),  disponendoli altresìi in ordine di numero prograssivo di operazione.
Io ho visto che tu non hai adoperato istruzioni SQL. Che sia proprio l'istruzione SQL a provocare rallentamenti così esasperanti?
Non sono in grado di valutarlo. Ricordo che allora ho faticato non poco per mettere a punto l'orologio gestionale del mio DB attraverso i DB.EXEC.
Esiste un metodo più semplice? Non lo so. A me è venuto allora facile e comprensibile costruirlo così.
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: Gianluigi - 05 Novembre 2018, 18:18:39
Citazione
Io ho visto che tu non hai adoperato istruzioni SQL. Che sia proprio l'istruzione SQL a provocare rallentamenti così esasperanti?
Io uso solo istruzioni SQL, è che amo tenere le cose in ordine e tutto l'SQL che mi serve lo riunisco in un modulo (MBase.module).
Poi utilizzo funzioni pubbliche per interrogare il database.
In questo modo tendo ad abbassare gli inevitabili errori.
Così, almeno per me, è tutto più chiaro.
Io uso questo metodo:
Chiamo la funzione di interrogazione che:
Crea la stringa di interrogazione
Apre il database
Esegue l'interrogazione passandola a una stringa o ad un vettore
Chiude il database
Ritorna il/i risultati alla routine chiamante.

Ma a parte questo io non ho capito ma le date nella tabella movimgg sono di tipo Integer?

Citazione
La mia lettura scansionata della tabella  movimgg (quella incriminata, contenente oltre 54000 record) è fatta attraverso il seguente codice
Una scansione su una colonna TEXT non indicizzata di circa 60.000 dati SQLite la fa in circa 10 millesimi di secondo, quindi vedi tu...

Sappimi dire quanto ci metti a scansionare una data col mio programma sul tuo computer io come massimo ci ho messo 2 secondi ma normalmente meno di uno.

Indicizzando la colonna ottengo miglioramenti insignificanti (1 o 2 centesimi di secondo e parliamo di 200.000 record).
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: Gianluigi - 06 Novembre 2018, 11:45:05
Buongiorno a tutti.
...
Chi mi vuole dare una mano ad avviare uno studio sulla riorganizzazione del DB?
Perché non azzeriamo tutto quanto detto e ti decidi a spostare il tuo progetto su un altro database?
C'è MySQL (tornu docet) ma se vuoi c'è anche il lascito di Sotema (la guida all'installazione e uso di Postgresql).
Lo so è un azardo ma qui siamo di fronte a un database già collaudato e funzionte.
Sono tantissimi i programmi che per riorganizzarsi si aggiornano completamente...
Cosa te ne pare?
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: Picavbg - 06 Novembre 2018, 15:29:02
non ho capito ma le date nella tabella movimgg sono di tipo Integer?
Si,  è una colonna definita "INTEGER"

Citazione
Sappimi dire quanto ci metti a scansionare una data col mio programma sul tuo computer io come massimo ci ho messo 2 secondi ma normalmente meno di uno.
Scusa, ma non ho capito come posso fare. Il tuo programma punta a un DB che io non possiedo e pertanto mi risponde "NESSUN DATO TROVATO"
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: Picavbg - 06 Novembre 2018, 15:43:32
Perché non azzeriamo tutto quanto detto e ti decidi a spostare il tuo progetto su un altro database?
C'è MySQL (tornu docet) ma se vuoi c'è anche il lascito di Sotema (la guida all'installazione e uso di Postgresql).
Lo so è un azardo ma qui siamo di fronte a un database già collaudato e funzionte.
Cosa te ne pare?
:o ???
Mi fa semplicemente paura. mi sento già la febbre addosso.  :rolleyes:
Citazione
Sono tantissimi i programmi che per riorganizzarsi si aggiornano completamente...
Significa riscrivere tutti i passi di programma che puntano al DB e, poi, migrare il DB attuale sul nuovo, non dopo però averlo studiato.
Io non sono così studioso come  te, Tornu e gli altri bravi amici del Forum, ma ricordo che le strutture di Mysql e Postgresql sono consigliate nella gestione di DB in una rete di pc connessa ad un server.
É  stato questo il motivo per cui, all'epoca, l'unico tipo di DB rimasto da impiegare in Gambas fu Sqlite.
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: Gianluigi - 06 Novembre 2018, 17:49:27
non ho capito ma le date nella tabella movimgg sono di tipo Integer?
Si,  è una colonna definita "INTEGER"
Io non sapevo che avessi usato Integer e la prova l'ho fatta con Text.
Citazione
Citazione
Sappimi dire quanto ci metti a scansionare una data col mio programma sul tuo computer io come massimo ci ho messo 2 secondi ma normalmente meno di uno.
Scusa, ma non ho capito come posso fare. Il tuo programma punta a un DB che io non possiedo e pertanto mi risponde "NESSUN DATO TROVATO"

Il programma allegato crea alla partenza il database nella tua home e se c'è errore te lo dovrebbe segnalare.
Per sicurezza l'ho scaricato e provato in un vecchio PC ci mette un po ma funziona.
Avvialo e dagli il tempo di creare e inserire nella tabella user 200.001 records

P.S. Se ti risponde "Nessun Dato Trovato" vuol dire che si è creato il database controlla in Hone/NomeProgramma/database
Potrebbe non essere riuscito a creare i record prova a cancellare la cartella in home e a riavviare e poi attendi che appaia la finestra.
Potrebbe anche essere successo che tu hai beccato un arco di tempo che non esiste lui crea date fra il 2009 e il 2018 non oltre il 28 di ogni mese (non avevo voglia di lavorare troppo)  ;D
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: Gianluigi - 06 Novembre 2018, 18:17:16

Mi fa semplicemente paura. mi sento già la febbre addosso.  :rolleyes:
:D
Citazione

Significa riscrivere tutti i passi di programma che puntano al DB e, poi, migrare il DB attuale sul nuovo, non dopo però averlo studiato.
Io non sono così studioso come  te, Tornu e gli altri bravi amici del Forum, ma ricordo che le strutture di Mysql e Postgresql sono consigliate nella gestione di DB in una rete di pc connessa ad un server.
É  stato questo il motivo per cui, all'epoca, l'unico tipo di DB rimasto da impiegare in Gambas fu Sqlite.

Come già ci hanno spiegato in tanti, questi database possono essere usati anche nel nostro computer un po come SQLite.
Invece che collegarti al database sul server esterno ti colleghi in localhost.
Se si usa Postgresql, per quel poco che ho fatto ti assicuro che le interrogazioni sono simili a quelle di SQLite.
SQL rimane sempre quello.
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: Gianluigi - 07 Novembre 2018, 00:41:22
Ho creato due nuove app di test, che allego, una che usa le date Integer e l'altra String.
Inserisce e toglie indici anche se quello possibilmente utile è sulla colonna date.
Il filtro sull'intervallo data va usato su piccoli intervalli max due settimane, ed è già molto lento, se non vogliamo attese interminabili (con e senza filtro).
Sarei curioso se Tornu lo provasse e lo confrontasse con mySQL per vedere le differenze, naturalmente cambiando in mySQL le date nel giusto valore.

Acc. come è tardi vado a dormire...  :sleepy:

P.S. Ho rimosso gli allegati potete scaricare da qui (http://www.gambas-it.org/smf/index.php?topic=6644.msg44589#msg44589) (per ora solo quello con date stringa)
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: Picavbg - 07 Novembre 2018, 16:56:50
Effettivamente la data che avevo dato nella prova precedente non era contenuta nel DB. Ho riprovato ed effettivamente è velocissimo. Tuttavia ho notato che il tuo DB contiene una sola tabella, mentre il mio ne contiene 11. Può darsi che ciò faccia la differenza.
Prima di rassegnarmi, vorrei provare a leggere la mia tabella d+movimgg tramite il "DB Browser for SQLite", però come al solito, prima devo imparare ad usarlo.

Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: Picavbg - 07 Novembre 2018, 18:58:04
Incredibile!  Ho eseguito due modi diversi di vista dei alcuni record contenuti nella tabella movimgg indicata nel post precedente, la prima volta agendo sulla data direttamente nella casella filter, in testa alla colonna  DtCoMovgg, la seconda volta creando una vista attraverso la digitazione del comando sql preso dal mio programma. In entrambi i casi la risposta è stata praticamente immediata.
Ho rivisto la porzione di codice interessato a creare la vista corrispondente. Devo analizzare meglio il suo contenuto ed il n° di cicli che esegue nellla compisizione della gridview di destinazione, perchè a questo punto è il programma che ha una qualche anomalia di scrittura.
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: Gianluigi - 07 Novembre 2018, 20:06:00
Incredibile!  Ho eseguito due modi diversi di vista dei alcuni record contenuti nella tabella movimgg indicata nel post precedente, la prima volta agendo sulla data direttamente nella casella filter, in testa alla colonna  DtCoMovgg, la seconda volta creando una vista attraverso la digitazione del comando sql preso dal mio programma. In entrambi i casi la risposta è stata praticamente immediata.
Ho rivisto la porzione di codice interessato a creare la vista corrispondente. Devo analizzare meglio il suo contenuto ed il n° di cicli che esegue nellla compisizione della gridview di destinazione, perchè a questo punto è il programma che ha una qualche anomalia di scrittura.

Infatti, anche io ho postato dei programmi che non andavano bene perché con troppi loop.
Guada un po questo allegato che filtra migliaia di date in pochi attimi.
Occorre eliminare i loop ripetitivi.

P.S. Ho allegato anche quello con date integer, non mi pare ci siano differenze di nota nei tempi di esecuzione.
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: tornu - 07 Novembre 2018, 20:50:23
Ho visto che dalle risposte praticamente Picavbg ha trovato l'inghippo che rallentava la risposta della query che
interrogava il suo DB.
Volevo solo far notare a Picavbg che il numero di tabelle presenti in un DB non incide sulla velocità di risposta dello
stesso ma il numero di record che la tabella contiene (ma devono essere veramente tanti), se indicizzata correttamente,
che non ci siano dati ridondanti (se non in casi particolari) e come sono costruite le query Sql. Ovviamente come nel tuo
caso impatta anche Gambas, specialmente nel popolare Gridview, Listview e oggetti similari.
Comunque per curiosità provo il test proposto da Gianluigi, vi posterò i risultati.
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: Picavbg - 07 Novembre 2018, 22:07:07
Ho visto che dalle risposte praticamente Picavbg ha trovato l'inghippo che rallentava la risposta della query che
interrogava il suo DB.
Ancora non ho accertato in pieno tale inghippo. La mia è una deduzione logica, che deve essere ancora dimostrata.
Ho visto che dalle risposte praticamente Picavbg ha trovato l'inghippo che rallentava la risposta della query che
interrogava il suo DB.
Volevo solo far notare a Picavbg che il numero di tabelle presenti in un DB non incide sulla velocità di risposta dello
stesso ma il numero di record che la tabella contiene (ma devono essere veramente tanti), se indicizzata correttamente,
che non ci siano dati ridondanti (se non in casi particolari) e come sono costruite le query Sql. Ovviamente come nel tuo
caso impatta anche Gambas, specialmente nel popolare Gridview, Listview e oggetti similari.
Il mio DB non presenta dati ridondanti, a meno che non vogliamo considerare tali quelli costituenti le chiavi di accesso che in SQL si distinguerebbero in chiavi primarie e secondarie.
Credo anch'io che una parte di responsabilità sia da attribuire a classi come Gridview e Pdfwriter, fortemente utilizzate per arrivare alla composizione della vista  e stampa della query di rilevazione dati dal DB..
Infatti, quando accedo al DB per riprendere i dati di una data contabile da modificare o da completare la formazione delle righe della relativa Gridview è rapidissima, nonostante che vi siano interessate più tabelle del DB (adesso non ricordo quante esattamente).
All'epoca ho dichiarato come colonna indice   autoincrementale la prima di ciascuna tabella che riporta un numero progressivo di record, colonna praticamente insignificante.
Questa si potrebbe effettivamente eliminare e, di conseguenza anche l'indice.
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: Picavbg - 07 Novembre 2018, 22:15:36
Guada un po questo allegato che filtra migliaia di date in pochi attimi.
Occorre eliminare i loop ripetitivi.
Si, effettivamente è praticanmente istantaneo. :check:
Bravissimo!
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: Gianluigi - 07 Novembre 2018, 23:07:19
Ho aggiunto (http://www.gambas-it.org/smf/index.php?topic=6644.msg44589#msg44589) anche il test con le date integer
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: Gianluigi - 08 Novembre 2018, 09:11:47

Comunque per curiosità provo il test proposto da Gianluigi, vi posterò i risultati.

Grazie  :D, l'unica prova significativa rimane quella tra due date molto distanti.
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: Gianluigi - 09 Novembre 2018, 18:10:37
C'era un bug nelle app, all'apertura con database già creato non inserivano il filtro, le ho aggiornate.

Al posto di c'era ho messo la cera, qualcuno è scivolato?  ;D
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: tornu - 09 Novembre 2018, 20:39:24
Ho fatto la prova con il test proposto da Gianluigi su DB MySql, ho modificato quelle
parti di codice non compatibili con questo DB, i risultati non mi sembrano esaltanti per
200000 record. Vi posto le schermate e mi accingo a modificare il DB con le mie conoscenze,
vi posterò i risultati.
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: Gianluigi - 09 Novembre 2018, 23:10:56
In effetti se ci si limita ad interrogare DB Browser i risultati sono immediati  :-\
Citazione
179947 rows returned in 102ms from: SELECT *
FROM tuser
WHERE usdat >= '2009-11-09'
AND usdat <= '2018-11-09'

Anche se io dalla app. ottengo risultati migliori dei tuoi:
1 o 2 centesimi di sec per l'interrogazione giornaliera
e 14 o 9 secondi circa per circa 180000 a seconda che parta da appena aperto oppure che prima abbia fatto l'interrogazione giornaliera.

Tieni anche conto che nella tua applicazione il filtro non viene attivato all'apertura occorre impostarlo (vedi bug sopra).
 :ot: Vedo che non hai il modulo canberra come hai installato?
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: Gianluigi - 09 Novembre 2018, 23:48:49
Comunque se si fa questa semplice prova:
Codice: [Seleziona]
Public Sub Form_Open()

  With GridView1
    .Header = 3
    .Columns.Count = 4
    .Columns[0].Width = 60
    .Columns[0].Text = "ID"
    .Columns[1].Width = 120
    .Columns[1].Text = "Nome"
    .Columns[2].Width = 120
    .Columns[2].Text = "Cognome"
    .Columns[3].Text = "DATA"
  End With

End


Public Sub btnPopola_Click()

  Dim i As Integer
  Dim StartTime, DiffTime As Float

  StartTime = Timer
  For i = 0 To 179946
    GridView1.Rows.Count = i + 1
    GridView1[i, 0].Text = i + 1
    GridView1[i, 1].Text = "Daphne"
    GridView1[i, 2].Text = "Verdone"
    GridView1[i, 3].Text = "01/04/2018"
  Next
  DiffTime = Round(Timer - StartTime, -2)
  Message.Info(i & " record filtrati su 200.001 In " & DiffTime)

End

Si può constatare che ci mette più tempo del programma, la vedo dura ridurre i tempi...
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: tornu - 10 Novembre 2018, 12:41:23
In effetti se ci si limita ad interrogare DB Browser i risultati sono immediati  :-\
Citazione
179947 rows returned in 102ms from: SELECT *
FROM tuser
WHERE usdat >= '2009-11-09'
AND usdat <= '2018-11-09'
Che ne deduci?
Forse la visualizzazione dei dati non dipende solo dalla velocità di estrazione dal DB, anche se le sue impostazioni e la
costruzione delle query di interrogazione sono fondamentali. Codice Gambas e Gridview ?
Continuo a fare prove

:ot: Vedo che non hai il modulo canberra come hai installato?
Da repository PPA http://ppa.launchpad.net/gambas-team/gambas3/ubuntu bionic
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: Picavbg - 10 Novembre 2018, 23:35:11
Siete due grandi!
Oggi ho riflettuto su come revisionare le query di interrogazione delle tabelle di DB interessate, in modo da riunire la ricerca in un unica istruzione sql.
In aggiunta, siccome, per l'uso che ne faccio, la gridview di destinazione si compone di una 20 di righe, al massimo,  pensavo di raccogliere la risposta della nuova query in un array e trasferire, dopo, il contenuto di detto array nella gridview da mostrare nella form.
Mi direte che posso ulteriormente allungare i tempi, però se lo scaricamento dal DB è rallentato dalla costruzione della gridview, forse, separando lo scaricamento dalla costruzione e valorizzazione della gridview, il tempo complessivo d'esecuzione si potrà addirittura ridurre.
Dovrò verificare il tutto. Spero al più presto.


Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: Gianluigi - 11 Novembre 2018, 01:19:54

:ot: Vedo che non hai il modulo canberra come hai installato?
Da repository PPA http://ppa.launchpad.net/gambas-team/gambas3/ubuntu bionic

Per installare in Ubuntu il modulo occorre dare questo comando:
Codice: [Seleziona]
sudo apt-get install libcanberra-gtk-module
Però non sono sicuro che possa servire installarlo a posteriori, provare non costa nulla.
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: Picavbg - 11 Novembre 2018, 10:20:26
Scusate.
Cos'è il modulo gamberrra e a che serve?
 ???
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: Gianluigi - 11 Novembre 2018, 11:00:31
Scusate.
Cos'è il modulo gamberrra e a che serve?
 ???

Da Ubuntu package (https://packages.ubuntu.com/search?keywords=libcanberra-gtk-module&searchon=names&suite=bionic&section=all) : (lib): traduce i segnali dei widget GTK+ nei suoni degli eventi
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: tornu - 11 Novembre 2018, 13:53:26
...
In aggiunta, siccome, per l'uso che ne faccio, la gridview di destinazione si compone di una 20 di righe, al massimo,  pensavo di raccogliere la risposta della nuova query in un array e trasferire, dopo, il contenuto di detto array nella gridview da mostrare nella form.
...
Ciao Picavbg,
è una tecnica che uso spesso anche io quando devo visualizzare parecchi dati in una Gridview, visualizzare un numero ridotto
di righe (impostabile con il metodo che uso io) e "sfogliando" i dati.
Non ho mai fatto prove riguardo la velocità di caricamento, ma per logica dovrebbe essere più veloce.
Io non uso array di "appoggio" per visualizzare un numero ridotto di dati rispetto a quelli contenuti nel result,
ma uso una query specifica.
Questo pomeriggio o al massimo questa sera ti posto il codice che uso per questa tecnica, poi valuta tu.
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: tornu - 11 Novembre 2018, 13:56:41

Per installare in Ubuntu il modulo occorre dare questo comando:
Codice: [Seleziona]
sudo apt-get install libcanberra-gtk-module
Però non sono sicuro che possa servire installarlo a posteriori, provare non costa nulla.
Ciao Gianluigi,
già fatto dopo la tua segnalazione.
Sì, puoi installarlo anche a posteriori.
Ti ringrazio comunque per i tuoi sempre graditi e preziosi suggerimenti.  ;)
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: Gianluigi - 11 Novembre 2018, 15:13:40
Io non uso array di "appoggio" per visualizzare un numero ridotto di dati rispetto a quelli contenuti nel result,
ma uso una query specifica.
Questo pomeriggio o al massimo questa sera ti posto il codice che uso per questa tecnica, poi valuta tu.

Mooooolto interessante  :D  :ok:

Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: tornu - 11 Novembre 2018, 21:49:12
Eccolo, mi scuso se non vi posto un programma di esempio ma solo il codice, ma purtroppo non ho avuto tempo,
se qualcuno ha la bontà di provarlo mi faccia sapere se ci sono errori, con MySql funziona benissimo non sò se è
adattabile anche a SqLite.  :ciao:
Codice: [Seleziona]
Private $iMaxRows As Integer = 15  ' Nr. max righe per pagina
Private $iCurrentPage As Integer  ' Pagina corrente
Private $iMaxPage As Integer  ' Nr. max pagine

Public Sub Form_Open()
  Me.Center()

  Crea_Griglia()  ' Avvia Sub creazione griglia
End

Private Sub Crea_Griglia() ' Creazione GridView dati
  With grdDati
    .Rows.Count = 0
    .Columns.Count = 4
    .Columns[0].Text = "Dato 1"
    .Columns[1].Text = "Dato 2"
    .Columns[2].Text = "Dato 3"
    .Columns[3].Text = "Dato 4"
  End With
End

Private Sub Conta_Record()  ' Conteggio record
  Dim rs As Result
  Dim iTmp As Integer

  rs = MGlobal.db.Exec("SELECT COUNT(campo1) FROM tabella")  ' Query conteggio dati

  iTmp = rs.Count Div $iMaxRows ' Suddivisione record per numero max righe (15) impostate per visualizzazione pagine in grdDati

  If rs.Count Mod $iMaxRows > 0 Then  ' Numerazione pagine
      $iMaxPage = iTmp + 1
    Else
      $iMaxPage = iTmp
  Endif

  GeneratePaging(0) ' Avvia Sub selezione dati e generazione pagine
  $iCurrentPage = 1
  NrPagine($iCurrentPage) ' Avvia Sub visualizzazione Nr. pagine
End

Private Sub GeneratePaging(iPage As Integer)  ' Selezione dati e generazione pagine
  Dim sSql As String
  Dim iStartOffset As Integer

  If iPage <= 0 Then  ' Impostazione numerazione pagine = 1 se pagine <= 0
    iPage = 1
  Endif

  iStartOffset = (iPage - 1) * $iMaxRows  ' Calcolo numero max pagine

  sSql = "SELECT campo1"
  sSql &= " FROM tabella"
  sSql &= " ORDER BY campo1"
  sSql &= " LIMIT "
  sSql = sSql & iStartOffset & "," & $iMaxRows

  grdDati.Clear()
  Crea_Griglia()  ' Avvia Sub creazione griglia
  Vis_Dati(grdDati, sSql)  ' Avvia Sub visualizzazione dati
End

Private Sub Vis_Dati(grd As GridView, sQuery As String)  ' Visualizzazione dati
  Dim i As Integer
  Dim rs As Result

  rs = MGlobal.db.Exec(sQuery)

  With rs
    grd.Rows.Count = 0
    If .Count <> 0 Then
        grd.Columns.Count = .Fields.Count
        grd.Rows.Count = .Count
        i = 0
        While i < .Count
          grd[i, 0].Text = rs!campo1
          grd[i, 1].Text = rs!campo2
          grd[i, 2].Text = rs!campo3
          grd[i, 3].Text = rs!campo4
          i = i + 1
          .MoveNext
        Wend
        MGlobal.db.Close()
      Else
        MGlobal.db.Close()
    Endif
  End With
End

Public Sub tbnPgAvanti_Click()  ' Pagina Avanti
  $iCurrentPage = $iCurrentPage + 1

  If $iCurrentPage >= $iMaxPage Then
    $iCurrentPage = $iMaxPage
  Endif

  MGlobal.db.Open()
  GeneratePaging($iCurrentPage) ' Avvia Sub generazione pagine
  NrPagine($iCurrentPage) ' Avvia Sub Nr. Pagine
End

Public Sub tbnPgIndietro_Click()  ' Pagina Indietro
  $iCurrentPage = $iCurrentPage - 1

  If $iCurrentPage <= 1 Then
    $iCurrentPage = 1
  Endif

  MGlobal.db.Open()
  GeneratePaging($iCurrentPage) ' Avvia Sub conteggio record
  NrPagine($iCurrentPage) ' Avvia Sub visualizzazione Nr. pagine
End

Public Sub NrPagine(iPag As Integer)  ' Numerazione pagine
  txlNrPagine.Text = iPag & "<FONT color=black> di </FONT>" & $iMaxPage
End
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: Picavbg - 11 Novembre 2018, 22:49:59
Grazie tornu.
Io non conosco MySql, ma dalle vostre prove vedo che i DB rispondono con sorprendente velocità alle richieste di estrazione dati.
Devo perciò correggere la parte relativa alla compilazione della gridview, e non solo.
Infatti la mia gridview ha una quantità di righe variabili, a seconda del numero dei record prodotti dalla query stessa, perciò all'epoca della realizzazione del passo di programma relativo ho pensato di aggiungere alla gridview di base 1 riga ad ogni record restituito dalla query, Inoltre la mia query non è unica ma è formata da successivi accessi al DB, uno per ciascuna tabella interessata nella compilazione della gridview.
É il risultato della mia completa inesperienza di allora sulla formazione di una query. Oggi capisco che è tutto da rivedere; devo perciò costruire un'unica query che mi restituisca tutti i dati componenti la singola riga da scrivere sulla gridview, inoltre, con la valorizzazione di un array di servizio, posso conoscere esattamente il n° di righe che comporranno la gridview finale e posso generare quest'ultima in maniera unica e definitiva, subito dopo avere riempito l'array di transito.
Spero di avere spiegato bene le modifiche che ho in mente di realizzare.  :'(
 :coder:

Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: Gianluigi - 12 Novembre 2018, 09:40:28
@Picavbg
mi intrometto solo per metterti in guardia, intanto non confondere le mie elementari query con quelle di tornu, ma soprattutto ti esorto a leggere bene quello che fa il suo codice.
Principalmente le query, devi studiarti Count e Limit altrimenti sei destinato a ripetere gli stessi errori.
Comunque, se crede e ne ha voglia lascio a tornu, che ne sa molto ma molto più di me, il compito di approfondire l'argomento relativo alla visualizzazione parziale dei risultati di una query.
Ad oggi non sono ancora riuscito a creare una visualizzazione "scorrevole" dei dati limitati in una griglia.  :bad:
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: Picavbg - 13 Novembre 2018, 15:42:13
Va bene.
Seguirò i vostri consiglim e suggerimenti.
A presto.
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: Gianluigi - 14 Novembre 2018, 00:09:42
Potrei dire "contrordine ragazzi" sono finalmente riuscito a far fare quello che volevo alla gridview.
Ora Filtra in pochi attimi milioni di dati e li mostra nella griglia dalla quale possiamo scorrere tutti i dati dal primo all'ultimo e variare anche le dimensioni della griglia.
L'unica cosa che mi fa un po pensare è l'uso del timer, se fossi riuscito con l'osservatore avrei preferito.
Dico contrordine perché sono tornato ai vettori.
@Picavbg ti consiglio di studiarti bene la routine GridView1_Data, nel tuo caso con così pochi record non serve neanche appoggiarsi al Timer, puoi caricare tutto in un colpo solo.

Attenzione che il file allegato carica la prima volta nel database due milioni di record pertanto ci mette un po, ad esempio nel mio computer abbastanza veloce impiega ad aprirsi, ma solo la prima volta, circa 15 secondi in quello tredicenne di mia moglie circa due minuti chiudendosi con l'avviso che il programma restituiva il valore 1, ma poi si avvia normalmente e riesce a filtrare con nonschalance tutti e due i milioni di dati.  :)

@tornu cosa ne dici, secondo te può andare?
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: Gianluigi - 14 Novembre 2018, 10:09:02
La cosa che non mi va del codice appena postato è che se si agisce sulla scroll bar questa si comporta in modo bizzarro andando su quando si ricarica il vettore e poi subito giù inseguendo il mouse.
Se tento di assegnare in partenza il totale delle righe alla gridview, ottengo sempre l'errore di fuori limite e non mi è venuta nessuna idea sul come evitarlo.
Qualche vostra proposta / idea?
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: tornu - 14 Novembre 2018, 22:15:43
...
@tornu cosa ne dici, secondo te può andare?
Velocissimo rispetto agli esempi precedente, non ho avuto tempo di analizzare il codice,
mi pare di aver capito dalle tue spiegazioni che hai cambiato il modo di popolare la
GridView, giusto?  :ok:
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: tornu - 14 Novembre 2018, 22:17:44
La cosa che non mi va del codice appena postato è che se si agisce sulla scroll bar questa si comporta in modo bizzarro andando su quando si ricarica il vettore e poi subito giù inseguendo il mouse.
Se tento di assegnare in partenza il totale delle righe alla gridview, ottengo sempre l'errore di fuori limite e non mi è venuta nessuna idea sul come evitarlo.
Qualche vostra proposta / idea?
Non ho capito il tuo disappunto sul codice, a me funziona benissimo lo scroll  ???
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: Gianluigi - 14 Novembre 2018, 22:54:17

mi pare di aver capito dalle tue spiegazioni che hai cambiato il modo di popolare la
GridView, giusto?  :ok:

Giusto, sono ritornato al primo amore, cioè quello di caricare un vettore, la differenza consiste nel fatto che questo è di 50000 record per volta (fornendo l'offset alla funzione preposta).
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: Gianluigi - 14 Novembre 2018, 22:58:45

Non ho capito il tuo disappunto sul codice, a me funziona benissimo lo scroll  ???

Naturalmente mi riferisco ad almeno 100.000 record filtrati; se si fa lo scrolling con la rotella o la freccetta in basso OK funziona bene.
Ma se invece agiamo sul cursore dello scroll e lo trasciniamo verso il basso noterai il malfunzionamento da me riferito.
Credo che così come è congeniato ora il codice sia inevitabile in quanto i dati (totali) si raddoppiano e il cursore dello scroll al caricamento delle nuove 50000 righe si va a riposizionare al centro e via via sempre più in basso me sempre sopra alla posizione di fondo che è quella appena prima del nuovo carico di righe.

I casi sono due:
O si riesce a caricare tutta la griglia all'inizio e allora il cursore dello scroll non si deve riposizionare, ma non so proprio come non mandare out of bound i vettori in quanto uno spostandolo velocemente può trovarsi alla riga 300.000 con caricato appena il primo vettore. Si dovrebbe poter bloccare il cursore.

Oppure occorre fare in modo che il cursore dello scroll rimanga sempre in fondo e non ritorni prima al centro e poi un po più giù ecc.

Spero di essermi spiegato.
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: Picavbg - 15 Novembre 2018, 17:31:58
Riprendo la discussione dal punto in cui l'avevo lasciata, relativamente all'esagerato impegno di tempo per la compilazione di alcuni movimenti del mio DB su una gridview.
Scusate la precisazione, ma il sopravvenuto difetto del cursore sulla barra di scorrimento verticale, ci ha portato un pò fuori dal tema della corrente discussione.

Prima di apportare una qualsiasi modifica al segmento di codice che estrae ed espone record dal DB, ho voluto rendermi meglio conto sui momenti in cui si verificano le lungaggini elaborative.
Devo anche dire che 'l'estrazione dei dati occorrenti non avviene in un solo momento, così come la compilazione della gridview. Piuttosto che descriverlo a parole, preferisco riportare qui sotto le righe di Debug con l'esposizione dell'orario rilevato di volta in volta con l'istruzione
Codice: [Seleziona]
 Debug "---" & Time(Now) & " ---"

Citazione
FormPrint01._new.111: 
FormPrint01._new.112:  -------------------------------------- Estrazione movimenti da DbContabFam ------------------------------
FormPrint01._new.113: --- inizio ore 16:53:33.288 ---
FormPrint01._new.177: --- fine ore 16:53:33.308 ---
FormPrint01._new.179: ----------------------------------------------------------------------------------------------------------------
FormPrint01._new.180: 
FormPrint01._new.181:  -------------------------------------- Formattazione Righe: totali, Riporto, a riptare ---------------------------
---
FormPrint01._new.244: --- fine ore 16:53:33.309 ---
FormPrint01._new.246: ----------------------------------------------------------------------------------------------------------------
FormPrint01._new.248: 
FormPrint01._new.249:  -------------------------------------- Compilazione Righe: Resta di Cassa ------------------------------
FormPrint01._new.324: --- fine ore 16:53:33.311 ---
FormPrint01._new.326: ----------------------------------------------------------------------------------------------------------------
FormPrint01._new.327: 
FormPrint01._new.328: -------------------------------------- Estrazione Movimenti di Pretito Momentaneo ------------------------------
FormPrint01._new.331: --- fine ore 16:53:56.795 ---
FormPrint01._new.333: ----------------------------------------------------------------------------------------------------------------
FormPrint01._new.334: 
FormPrint01._new.335: -------------------------------------- Compilazione Righe di Pretito Momentaneo ------------------------------
FormPrint01._new.380: --- fine ore 16:53:56.796 ---
Si vede chiaramente che dal momento in cui comincia l'estrazione, l'unico tratto di programma "stonato" è quello relativo all'estrazione dei movimenti di Prestito Momentaneo che comincia a h. 16:53:33.311 e finisce a h.16:53:56.795 con una durata di 23.484 secondi che risponde quasi in toto alla mia attesa dal momento in cui clicco il pulsante virtuale |Stampa|.
Quindi tutto il ragionamento fatto vari post fa su una diversa modalità di caricamento della gridview cade. Devo invece analizzare più approfonditamente il gruppo di istruzioni pertinenti l'estrazione di quei particolari record facenti capo ad concetto di "Movimenti per prestiti momentanei".
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: Gianluigi - 15 Novembre 2018, 22:10:39
E quanto ci mette DB Browser for SQLite a fare l'estrazione?
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: Picavbg - 16 Novembre 2018, 09:44:43
E quanto ci mette DB Browser for SQLite a fare l'estrazione?
Penso che ti riferisca  alla rilevazione ripetuta qui sotto
Citazione
FormPrint01._new.324: --- fine ore 16:53:33.311 ---
FormPrint01._new.326: ----------------------------------------------------------------------------------------------------------------
FormPrint01._new.327: 
FormPrint01._new.328: -------------------------------------- Estrazione Movimenti di Pretito Momentaneo ------------------------------
FormPrint01._new.331: --- fine ore 16:53:56.795 ---
FormPrint01._new.333: ----------------------------------------------------------------------------------------------------------------
per complessivi 23" e 484 ms.

Vi farò sapere dopo approfondimento, ma ancora non ho avuto tempo di addentrarmi nell'analisi del segmento di codice.
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: Gianluigi - 16 Novembre 2018, 14:37:03
No intendevo dire, ammesso e non concesso che tu l'estrazione dei dati la faccia con una query, se fai girare la query direttamente in DB Browser for SQLite, quanto tempo impiega?
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: Picavbg - 16 Novembre 2018, 19:46:22
No intendevo dire, ammesso e non concesso che tu l'estrazione dei dati la faccia con una query, se fai girare la query direttamente in DB Browser for SQLite, quanto tempo impiega?
Ora ho capito.

Purtroppo non posso darti una risposta immediata perchè dovrei costruire la query in DB Browser, uguale alla mia nuova query:
Codice: [Seleziona]
 sql = "SELECT * FROM prestmom,movimgg,piancont WHERE "
  sql &= "prestmom.DtCoPriPrestMom >= '20111201' "     'Istruzione valida fino alla completa eliminazione dei sospesi antichi
  sql &= "AND prestmom.DtCoUltPrestMom <= $DataStamp  "     'in modo da considerare anche i movimenti estinti in data successiva a quella corrente
  sql &= "AND prestmom.DtSolPrestMom =  movimgg.DtSolMovgg "
  sql &= "AND prestmom.OraSolPrestMom =  movimgg.OraSolMovgg "
  sql &= " ORDER BY prestmom.StaPrestMom, prestmom.DtCoPriPrestMom, movimgg.DtCoMovgg"
  ApriDB = New OpenDB
  RecStampMov = ApriDB.DBConnection.EXEC(sql)
  For Each RecStampMov
    iConta += 1
  Next
Per ora non fa altro. Mi è servita solo per capire quanto tempo impiega ad estrarre i record pertinenti ai vincoli di estrazione.

Citazione
FormPrint01._new.114:  -------------------------------------- Estrazione movimenti da DbContabFam ------------------------------
FormPrint01._new.115: --- inizio ore 19:31:38.987 ---
FormPrint01._new.179: --- fine ore 19:31:39.028 ---
FormPrint01._new.181: ----------------------------------------------------------------------------------------------------------------
FormPrint01._new.182: 
FormPrint01._new.183:  -------------------------------------- Formattazione Righe: totali, Riporto, a riptare ---------------------------
---
FormPrint01._new.246: --- fine ore 19:31:39.03 ---
FormPrint01._new.248: ----------------------------------------------------------------------------------------------------------------
FormPrint01._new.250: 
FormPrint01._new.251:  -------------------------------------- Compilazione Righe: Resta di Cassa ------------------------------
FormPrint01._new.326: --- fine ore 19:31:39.032 ---
FormPrint01._new.328: ----------------------------------------------------------------------------------------------------------------
FormPrint01._new.329: 
FormPrint01._new.330: -------------------------------------- Estrazione Movimenti ATTIVI di Pretito Momentaneo --------------------------
FormPrint01._new.343: --- fine ore 19:31:39.034 ---

La query che provocava inspiegabili lungaggini di tempo non esiste più ed i nuovi tempi di esecuzione sono assolutamente da primato.
Naturalmente, occorre aggiungere le istruzioni di compilazione righe nella gridview corrente, ma sono abbastanza fiducioso.
Infatti, mentre prima gestivo un numero imprecisato di query a seconda dei movimenti incontrati con la prima di quest'ultima estrazione, ora i dati occorrenti sono tutti già pronti per essere elaborati e caricati nella gridview.

Vi farò sapere,...  magari non stasera o domani.
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: tornu - 16 Novembre 2018, 22:07:14
Ciao Picavbg,
premesso che non conosco la struttura delle tabelle che richiami nella query, usi SELECT * che in parole povere
significa dammi tutti i campi delle tabelle richiamate in base alle condizioni impostate con gli AND, ma ti servono
tutti per visualizzare i dati che stai filtrando?
Ti ho fatto questa domanda perchè spesso si fà l'errore di richiamare tutti i campi di una tabella anche se non servono,
anche questo metodo è fonte di rallentamento specialmente in DB "corposi".
Per quanto riguarda la GridView ti posto un esempio della stessa "sfogliabile" a pagine.
Ho utilizzato uno degli esempi di Gianluigi con SqLite ( :hard:).
Mi perdonerà Gianluigi per aver "raffazzonato" il suo codice (anche per mancanza di tempo) , ma funziona, purtroppo
alcune funzioni con SqLite non mi erano chiare  :-[
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: Gianluigi - 16 Novembre 2018, 22:36:32
Citazione
Purtroppo non posso darti una risposta immediata perchè dovrei costruire la query in DB Browser, uguale alla mia nuova query

Ma il database ce l'hai ti basta aprirlo con DB Browser for SQLite e interrogarlo dalla scheda Execute SQL  :-\

Ti stavo scrivendo questo, ma vedo che tornu mi ha preceduto, lo posto ugualmente anche se rischio di ripetere quello che dice lui:
Codice: [Seleziona]
SELECT * /* Sei proprio sicuro che ti servano tutte le colonne? */
FROM prestmom,movimgg,piancont /* e piancont, perché selezioni tutta la tabella e non la usi? Sono un po tanto arrugginito con le query ma qui non manca qualcosa del tipo
FROM prestmom
INNER JOIN movimgg */
WHERE prestmom.DtCoPriPrestMom >= 20111201 /* <--- senza apostrofi (non sono integer?) */
AND prestmom.DtCoUltPrestMom <= $DataStamp /* <--- insisto non sono integer le tue date? */
AND prestmom.DtSolPrestMom =  movimgg.DtSolMovgg
AND prestmom.OraSolPrestMom =  movimgg.OraSolMovgg
ORDER BY prestmom.StaPrestMom, prestmom.DtCoPriPrestMom, movimgg.DtCoMovgg

@Tornu,
ho scaricato il file ora non ho tempo, domani pomeriggio lo guardo  :ciao:
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: Picavbg - 16 Novembre 2018, 23:26:32
nella query, usi SELECT * che in parole povere
significa dammi tutti i campi delle tabelle richiamate in base alle condizioni impostate con gli AND, ma ti servono
tutti per visualizzare i dati che stai filtrando?
Domanda corretta. Hai fatto bene a ricordarmelo. Devo dire che non ci ho riflettuto molto sopra, infatti ho copiato e modificato una query precedente ed ho dimenticato di sostituire allo "*" l'elenco delle colonne che mi interessano.
In effetti la query andrebbe fatta così:
Codice: [Seleziona]
sql = "SELECT prestmom.DtCoPriPrestMom AS DtCoIniPreMom, prestmom.DtCoUltPrestMom AS DtCoUltimaPreMom, prestmom.DtSolPrestMom As DtSolPreMom," 
  sql &= "prestmom.OraSolPrestMom AS OreSolPreMom, prestmom.CoVoPrestMom AS CoVocePreMom,prestmom.StaPrestMom AS StatusPreMm"
  sql &= "movimgg.DtCoMovgg AS DtContMovvGG,  movimgg.DtSolMovgg AS DtSoleMovvGG, movimgg.OraSolMovgg AS OraSoleMovvGG, "
  sql &= "movimgg.ImpMovvgg AS ImpMovim. movimgg.MonMovvgg AS LirEurMovim, "
  sql &= "piancont.NumVoce AS CoVoPiaConti, piancont.NomeVoce AS VocePiaConti"
  sql &= "From prestmom, movimgg, piancont WHERE " ""
  sql &= "DtCoIniPreMom >= '20111201' "     'Istruzione valida fino alla completa eliminazione dei sospesi antichi
  sql &= "AND DtCoUltimaPreMom <= $DataStamp  "     'in modo da considerare anche i movimenti estinti in data successiva a quella corrente
  sql &= "AND DtSolPreMom =  DtSoleMovvGG "
  sql &= "AND OreSolPreMom =  OraSoleMovvGG "
  sql &= " ORDER BY StatusPreMm, CoVocePreMom, DtCoIniPreMom, DtContMovvGG"
  ApriDB = New OpenDB
  RecStampMov = ApriDB.DBConnection.EXEC(sql)
Credo infatti, se non, ricordo male, che vadano indicati prima di "FROM" tutte le colonne necessarie, non solo per il contenuto da estrarre, ma anche perchè sono citate nello "ORDER BY".
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: Picavbg - 16 Novembre 2018, 23:37:26
Codice: [Seleziona]
[quote author=Gianluigi link=topic=6644.msg44646#msg44646 date=1542404192]
Ma il database ce l'hai ti basta aprirlo con DB Browser for SQLite e interrogarlo dalla scheda Execute SQL  :-\

Si, l'ho visto e l'ho anche eseguito, ma penso di avere sbagliato qualcosa, perchè, mentre la stessa query nel programma impiega pochissimi ms ed estra 343 record, quella eseguita in DB Browser ha impiegato poco più di 22 secondi ed estrae nientemeno che 103000 record.  Quindi c'è qualcosa che non funziona. Non so ancora dove.
A proposito, sai se è possibile indirizzare, in DB Browser,il risultato della query in un file.text?
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: Picavbg - 17 Novembre 2018, 16:57:13
Trovato l'inghippo. Ora la query funziona sia nel programma che nella ricerca del DB Browser for SqLite.
Entrami estraggono 748 record con questi tempi:
Citazione
programma = 196 ms.     ( Compilazione Righe: Resta di Cassa................................................fine ore 16:29:46.574 ---)
                                             (Estrazione Movimenti ATTIVI di Pretito Momentaneo.....................fine ore 16:29:46.77 ---   N° Record estratti = 748)
Db Browser = 748 rows returned in 859ms from: SELECT

Ho soltanto un piccolo problema, oggetto dell'inghippo: ho dovuto togliere dalla query una colonna della tabella piancont,  perchè quando l'aggiungo entrambi le ricerche vanno letteralmente in tilt, con tempi lunghissimi e volume di estrazione assurdo (1.358.728).
Una soluzione potrebbe essere quella di accedere alla tabella piancont del DB, soltanto al momento di aggiungere alla grdview le righe di movimenti attivi, fra tutti quelli rilevati dalla query, alla data di rilevazione.  Si tratta di pochissime righe (< 10).
 :ciao:
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: Gianluigi - 17 Novembre 2018, 20:11:51
A proposito, sai se è possibile indirizzare, in DB Browser,il risultato della query in un file.text?
Lo puoi esportare come CSV, c'è un tasto a destra del riquadro dei risultarti (terzo riquadro in fondo).

Citazione
programma = 196 ms.
Db Browser = 859ms

Non è possibile, praticamente è come se il browser ti stesse dicendo che la query è sbagliata.
Dovresti fare un database che esemplifica cosa stai facendo, caricato con dati di fantasia ma che permetta di riprodurre quanto vuoi fare con l'interrogazione.
Altrimenti diventa impossibile aiutarti.
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: Picavbg - 18 Novembre 2018, 09:13:04
Citazione
programma = 196 ms.
Db Browser = 859ms
Non è possibile, praticamente è come se il browser ti stesse dicendo che la query è sbagliata.
Si, potrei avere sbagliato a copiare la query nella finestra SQl del DB Browser. Mi dispiace non avere potuto rispondere alla tua domanda correttamente

Citazione
Dovresti fare un database che esemplifica cosa stai facendo, caricato con dati di fantasia ma che permetta di riprodurre quanto vuoi fare con l'interrogazione.
Altrimenti diventa impossibile aiutarti.
Io credo, caro GianLuigi che, avendo a disposizione un DB reale, non abbia alcun bisogno di andare a fantasticare strutture particolari. Le risposte le ho già avute, insieme ai vostri preziosissimi consigli. Poi ho capito solo ieri che nella query antica c'è un termine di confronto perditempo:
Codice: [Seleziona]
 sql &= "prestmom.DtCoPriPrestMom >= '20111201' "   
, infatti non ha senso mantenere fermo un termine iniziale di ricerca con una data fissa: I rapporti di debito/credito momentanei hanno breve durata e normalmente si risolvono nel giro di pochi giorni o settimane. Dovrebbe essere già abbastanza congruo considerare tutti i movimenti relativi con inzio  un anno fa, però ho modificato tale termine di confronto nella query, riferendomi ad una data di inizio prestito antica di due anni:
Codice: [Seleziona]
 iDtAMG = Int(Val($DataStamp))
 iDt2anniFa = iDtAMG - 20000
 sql = "SELECT prestmom.DtCoPriPrestMom AS DtCoIniPreMom, prestmom.DtCoUltPrestMom AS DtCoUltimaPreMom, prestmom.DtSolPrestMom As DtSolPreMom, "
--- bla --- bla --- bla ---
  sql &= "From prestmom, movimgg WHERE "
'  sql &= "From prestmom, movimgg, piancont WHERE "
  sql &= "prestmom.DtCoPriPrestMom >= '" & iDt2anniFa & "' "      'Istruzione valida fino alla completa eliminazione dei sospesi antichi
  sql &= "AND prestmom.DtCoUltPrestMom <= '" & iDtAMG & "' "   
--- bla --- bla --- bla ---
 sql &= "ORDER BY  prestmom.CoVoPrestMom, prestmom.StaPrestMom, prestmom.DtCoPriPrestMom, movimgg.DtCoMovgg"
Così facendo, i movimenti estratti in cui ricercare quelli non ancora estinti, si sono ridotti a 318
Come vedi l'anomalia è praticamente risolta. Mi resta solo di mettere a punto il segmento di programma per individuare detti movimenti ed accodarli nella grdview.
Dato che sono già ordinati per codice-voce-di-prestito-momentaneo, Status-di-prestito-momentaneo, data-di-inizio--di-prestito-momentaneo, data-contabile-di-movimentazione, me li ritrovo già disposti, per ciascun  codice voce, dal più antico al più recente e, mentre sto scrivendo, penso di riunirli per codice-voce-di-prestito-momentaneo e data-di-inizio--di-prestito-momentaneo, e scrioverli direttamente nella gridview, sensa nemmeno avere bisogno di creare un array di passaggio intermedio.

Dopo avere portato a termine la modifica, dovrò soltanto rilevare i nuovi tempi di esecuzione e brindare con voi, lo spero fiduciosamente, per il traguardo raggiunto.  ;)
A presto   :ciao:
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: Gianluigi - 20 Novembre 2018, 10:51:37
Per quanto riguarda la GridView ti posto un esempio della stessa "sfogliabile" a pagine.
...

Credo di aver capito il meccanismo dell'evento Data della GridView, penso che sia più pratico e immediato rispetto all'uso dell'impaginazione.
Ho pubblicato un esempio di funzionamento sulla Farm come scritto qui (http://www.gambas-it.org/smf/index.php?topic=6678.msg44665#new).
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: tornu - 21 Novembre 2018, 22:02:27
 :ok: Ottimo esempio  :2birre:
Titolo: [Risolto] Re:DB.SqLite - volumi supportabili
Inserito da: Picavbg - 22 Novembre 2018, 10:25:14
Finalmente è finita. La modifica apportata, dopo qualche problema di messa a punto, si è conclusa nel migliore dei modi.
Ora la query è svolta in tempi assolutamente sorprendenti, come si può constatare dalle righe di debug rioportate qui sotto:

Citazione
FormPrint01._new.263:  -------------------------------------- Compilazione Righe: Resta di Cassa ------------------------------
FormPrint01._new.344: --- fine ore 10:11:03.531 ---
FormPrint01._new.346: ----------------------------------------------------------------------------------------------------------------
FormPrint01._new.347: 
FormPrint01._new.348: -------------------------------------- Estrazione Movimenti ATTIVI di Pretito Momentaneo ------------------------------
FormPrint01._new.418: --- fine ore 10:11:03.979 ---   N° Record estratti = 594

Il tutto si è concluso in 438 ms.

Grazie per il vostro aiuto illuminante.
Titolo: Re:DB.SqLite - volumi supportabili
Inserito da: Picavbg - 22 Novembre 2018, 10:26:10
 :2birre: