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

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

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

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


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

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

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

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

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

55
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?

56
Programmazione / Re:CDate non funziona
« il: 28 Maggio 2018, 16:05:31 »
Devi usare CDate(Val("dataStringa")) se vuoi continuare a usare CDate.

Perchè, quale altra soluzione suggeriresti?
 :(

57
Programmazione / CDate non funziona
« il: 28 Maggio 2018, 13:05:11 »
L'istruzione CDate non mi funziona più.
Citazione
Codice: [Seleziona]
Dim dData As Date
..............................................................
 dData = CDate($DtMM & "/" & $DtGG & "/" & $AADtCont)
Con Gambas 3.9:
Variabili locali:
     $DtMM  = "05"
     $DtGG = "28"
     $AADtCont = "2018"

dData = 28/05/2018 00:00:00


Con Gambas 3.10:
Variabili locali:
     $DtMM  = "05"
     $DtGG = "28"
     $AADtCont = "2018"

dData = 27/05/2018 22:00:00

Come si vede il campo dData, nella versione 3.10 contiene una data alterata di un giorno rispetto ai valori di partenza.

A parte il chiaro errore da segnalare, secondo me, ma io come posso fare per ottenere la data corretta?
 :(

58
Programmazione / Re:DateBox.value
« il: 28 Maggio 2018, 12:21:21 »
Oops!  :o
Che figura ...

Scusa Gianluigi, non avevo capito proprio a cosa ti riferivi. É vero, DateBox1.Value restituisce un valore di tipo Data.  :rolleyes: :rolleyes: :rolleyes:
Sono proprio invecchiato. Meglio non prendere più iniziative diel genere "Inforamazioni utili per gli amici"
 :hard:

 :(

59
Programmazione / Re:DateBox.value
« il: 27 Maggio 2018, 23:25:20 »
Se hai guardato bene il codice che ho scritto, la mia data si trova dentro un tipo di campo stringa. Per fare quello che proponi tu, dovrei prima convertire la mia stringa in una data e, soltanto a questo punto potrei utilizzare un'istruzione come quella suggerita da te.
Secondo me, faccio prima così.

Inoltre l'istruzione CDate non funziona più come prima e il perchè lo spiego in un'altra discussione, dopo avere fatto un' ulteriore prova,  proprio con l'istruzione che mi hai ricordato nel tuo post.
 ;)

60
Programmazione / DateBox.value
« il: 27 Maggio 2018, 15:29:57 »
Oggi ho installato fedora28 e successivamente vi ho installato Gambas3.10. Ho provato ad eseguire il mio programma ContabFam ed ho incontrato una sorpresa inaspettata, infatti rilevando la data digitata dall'utente con l'istruzione
Codice: [Seleziona]
Dim   DataDig As String
.......................................
DataDig = DateBox1.value
DateBox1.value contiene "GG/MM/AAAA 00:00:00"
DataDig, dopo l'istruzione contiene "MM/GG/AAAA 00:00:00, mentre fino a Gambas3.9 la stessa istruzione forniva in DataDig "MM/GG/AAAA"

La novità provoca un errore nell'istruzione successiva che era
Codice: [Seleziona]
DataDig = Right(DataDig, 4) & Left(DataDig, 2) & Mid(DataDig, 4, 2) 
perciò ho dovuto modificare quest'ultima istruzione nella seguente:
Codice: [Seleziona]
DataDig = Mid(DataDig, 7, 4) & Left(DataDig, 2) & Mid(DataDig, 4, 2) [code]
in modo da ottenere in DataDig sempre una data nel formato AAAAMMGG, come occorre al programma.

La strada scelta mi permette di far funzionare il programma sia in Gambas3.10 che in Gambas3.9

Percò: ... occhio.
 :ciao: :ciao:


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