[Risolto] DB.SqLite - volumi supportabili

[Gianluigi]

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.

[Picavbg]

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) & " ---"

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".

[Gianluigi]

E quanto ci mette DB Browser for SQLite a fare l'estrazione?

[Picavbg]

E quanto ci mette DB Browser for SQLite a fare l'estrazione?

Penso che ti riferisca  alla rilevazione ripetuta qui sotto

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.

[Gianluigi]

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?

[Picavbg]

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.

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.

[tornu]

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 ( ).
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 

[Gianluigi]

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 

[Picavbg]

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".

[Picavbg]

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?

[Picavbg]

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:

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).
 

[Gianluigi]

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).

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.

[Picavbg]

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

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   

[Gianluigi]

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.

[tornu]

  Ottimo esempio