Visualizza post

Questa sezione ti permette di visualizzare tutti i post inviati da questo utente. N.B: puoi vedere solo i post relativi alle aree dove hai l'accesso.


Post - Picavbg

Pagine: 1 2 [3] 4 5 ... 108
31
Programmazione / Re:Oggetto DateBox, controllo digitazione
« il: 27 Novembre 2018, 15:25:29 »
A me sembra un non problema, occorre semplificare al massimo l'intervento del nostro codice sul comportamento della grafica.
Se, come succede ad esempio in DBSpeedyTest, dopo aver scritto la/le date devi agire su un widget (abitualmente un Button) il controllo dell'esattezza dei dati lo fai li e se qualcosa non va metti a Null il valore e gli dai il SetFocus
Benissimo, però, come avrai certamente capito quello del DateBox è solo un esempio; il problema si può presentare alla fine di una  digitazione qualsiasi all'interno  di una TextBox o di una TextArea o ancora diun a ComboBox, ...
Non sempre conviene operare come suggerisci tu, anche perchè, così facendo, vai ad alterare l'errata digitazione che invece deve essere mantenuta per permettere all'utente di vedere quello che ha sbagliato, in modo che possa apportare la correzione. Apponendo NULL infatti obblighi la ridigitazione completa del dato, con la possibilità di ripetere l'errore di prima.

La verità è che, secondo me, l'evento LostFocus dovrebbe essere scatenato in Gambas ancor prima che l'oggetto corrente perda il focus, esattamente come succede in Visual Basic. Ciò permetterebbe di operare un controllo a posteriori sulla digitazione appena ultimata, ancor prima che l'oggettio perda il Focus e, in caso di errori, mantenere il Foicus all'interno dell'oggetto corrente fino alla correzione formale del dato digitato.

Il disturbo appena citato che soffro da quando ho conosciuto Gambas, è secondo me un corto circuito del linguaggio vestito della sua parte grafica. Esso costituisce uno dei motivi per cui vorrei passare a scrivere con un altro strumento di programmazione, ma probabilmente sono ormai troppo vecchio per studiare ancora.

32
Programmazione / Oggetto DateBox, controllo digitazione
« il: 27 Novembre 2018, 10:03:55 »
Ho ripreso a programmare in Gambas e sono tornati i problemi di sempre:  come controllare la correttezza formale della digitazione della data, nel caso che l'oggetto sia "DateBox", prima di abbandonare completamente l'oggetto per passare ad un altro.
Il problema sorge soprattutto quando il passaggio da un oggetto all'altro sia gestito attraverso il mouse.
L'evento LostFocus si manifesta, ahimè, soltanto dopo che l'oggetto destinatario dell'ultima digitazione sia stato abbandonato. Risulta perciò tardivo e, riattivare, in caso di digitazione formalmente errata, il SetFocus sullo stesso diventa tremendamente difficoltoso (lo dico per esperienze passate).
Stavo pensando di sfruttare uno degli eventi disponibili per il mouse come MouseDown, MoseUP,  MouseMove, però mi sono chiesto: ma come fanno gli amici del forum Gambas?
Ripeto: lo scopo è quello di controllare, a digitazione conclusa, la sua correttezza prima che il Focus passi ad un altro oggetto, in modo da permetterne l'eventuale correzione, mentre, appunto, il Focus è ancora puntato sul DateBox corrente.

33
Programmazione in generale / Re:DB.SqLite - volumi supportabili
« il: 22 Novembre 2018, 10:26:10 »
 :2birre:

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

35
Programmazione in generale / Re:DB.SqLite - volumi supportabili
« il: 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:

36
Programmazione in generale / Re:DB.SqLite - volumi supportabili
« il: 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:

37
Programmazione in generale / Re:DB.SqLite - volumi supportabili
« il: 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?

38
Programmazione in generale / Re:DB.SqLite - volumi supportabili
« il: 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".

39
Programmazione in generale / Re:DB.SqLite - volumi supportabili
« il: 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.

40
Programmazione in generale / Re:DB.SqLite - volumi supportabili
« il: 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.

41
Programmazione in generale / Re:DB.SqLite - volumi supportabili
« il: 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".

42
Programmazione in generale / Re:DB.SqLite - volumi supportabili
« il: 13 Novembre 2018, 15:42:13 »
Va bene.
Seguirò i vostri consiglim e suggerimenti.
A presto.

43
Programmazione in generale / Re:DB.SqLite - volumi supportabili
« il: 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:


44
Programmazione in generale / Re:DB.SqLite - volumi supportabili
« il: 11 Novembre 2018, 10:20:26 »
Scusate.
Cos'è il modulo gamberrra e a che serve?
 ???

45
Programmazione in generale / Re:DB.SqLite - volumi supportabili
« il: 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.



Pagine: 1 2 [3] 4 5 ... 108