[risolto] edit database

[milio]

ho aggiunto una progress bar cosi' si puo' vedere se il programma sta andando avanti... sfalsa un po' il risultato perche' ho dovuto mette dei wait 0.1 per fare il refresh del form...

[fsurfing]

errore mio non ho avuto la pazienza di aspettare

test1 2 min e 11
test2 2 min e 04
test3 1 secondo e 19

[milio]

a giudicare dal risultato il tuo pc di prova non e' tanto 'giovane'

[milio]

comunque dex chiedeva un modo veloce per fare l'update dell tabella, e visto i risultati credo che la soluzione migliore sia quella di riscrivere l'intera tabella

[milio]

forse ho trovato la soluzione:

con la seconda prova (quella sei record concatenati) inizio la query con un "BEGIN; "
poi 200 update a seguire e un bel " END;" finale
risultato test: 1.8 sec. !
provar per credere...
ps. ho saltato il primo test per far piu' veloce.

[claudio]

Secondo me è inutile mettere il saldo progressivo della cassa nel record, perché ad ogni modifica o inserimento
deve essere aggiornato in  tutti i record della tabella, però puoi aggiungere un campo in cui riporti il valore del
campo Entrata con segno positivo o il valore del campo Uscita con segno negativo, e rifare i calcoli utilizzando
un solo campo della tabella.

[milio]

Si e' vero, ma la mia era pura curiosita'...

Ho provato a passargli i 1422 update in un botto solo.... 0,4 sec!

[dex]

milio
ho provato il test, e in effetti l'ultimo impiega meno di 1 sec.

mi chiedevo tu hai fatto un test con 1400 rec e 200 insert, quindi hai fatto 7 cicli completi.

se invece di 1400 fossero stati 1398? oppure 1410?

[dex]

Secondo me è inutile mettere il saldo progressivo della cassa nel record, perché ad ogni modifica o inserimento
deve essere aggiornato in  tutti i record della tabella, però puoi aggiungere un campo in cui riporti il valore del
campo Entrata con segno positivo o il valore del campo Uscita con segno negativo, e rifare i calcoli utilizzando
un solo campo della tabella.

ad ogni inserimento la cassa viene aggiornata ma risulta velocissimo in quanto prima di inserire un nuovo record mi basta leggere l'ultimo record cassa, e non ho bisogno di aggiornarlo su tutti i record ma solo sul nuovo.

il problema si pone se un utente và a modificare un vecchio record, in quel caso la cassa va ricalcolata su tutto il database o al limite dal record modificato fino alla fine.
Anche se riportassi i valori + e  - come dici tu non toglie che per avere la cassa aggiornata devo sempre rifare il calcolo dal record modificato.

[claudio]

Nell'applicazione che ho realizzato 'PrimanotaContabile' (nella sezione progetti in cerca di aiuto con sorgente allegato), c'è la gestione delle entrate e uscite di cassa, che ho impostato nel seguente modo:
Nel record inserisco la data dell'operazione e il relativo valore dell'entrata o uscita di cassa, poi se ad esempio voglio visualizzare in una gridview il mastrino della cassa dal 01/03/2010 al 15/03/2010, prima con una semplice query mi calcolo il saldo cassa al 28/02/2010 e lo assegno ad una variabile, successivamente nel ciclo di lettura dei record compresi nel periodo di estrazione, ad ogni record letto aggiorno la variabile del saldo cassa e ne inserisco il valore nel gridview.

[dex]

@claudio

il tuo è un procedimento diverso ma le modalità di calcolo sono le stesse, bisogna far leggere il database uno ad uno ed effettuare calcoli.
anzi a mio parere il tuo metodo è ancora più laborioso, in quanto ogni volta che vuoi sapere il saldo devi far scorrere tutto il database.
per evitare ciò mi salvo il saldo in ogni record, in qualsiasi momento sò sempre il saldo senza effettuare nessun calcolo, solo e se un record viene modificato devo rifare il calcolo del saldo.

finchè avevo pochi record non si era presentato il problema, quando ne sono diventati varie centinaia ho notato il rallentamento.

secondo me con il tuo metodo avrai lo stesso problema. hai provato ha fare dei test con migliaia di record?

[claudio]

Per sapere il saldo cassa in un dato giorno mi basta una semplice interrogazione al database, senza scorrere alcun record. Solo se devo visualizzare le operazioni comprese in un intervallo di date, sono obbligato a scorrere i record per calcolare e visualizzare il saldo, che chiaramente varierà dopo ogni singola operazione.
Poi è normale che l'elaborazione impieghi più tempo a seconda del numero di registrazioni.

[milio]

milio
ho provato il test, e in effetti l'ultimo impiega meno di 1 sec.

mi chiedevo tu hai fatto un test con 1400 rec e 200 insert, quindi hai fatto 7 cicli completi.

se invece di 1400 fossero stati 1398? oppure 1410?

Infatti se guardi il test erano esattamente 1422 i record
Comunque ho provato a passargli con il BEGIN .... END tutte le 1422 UPDATE ed e' stato piu' veloce che riscrivere la tabella...

[dex]

@milio

ho provato anche io con il begin è talmente veloce che sembra che non fà nulla, unico neo la cassa non risulta esatta.
ho effettuato varie prove ed ho scoperto che alla fine conteggia il penultimo record.

esempio  845 record
843 cassa 152.00
844 cassa 183.00
845 cassa 215.00

ricalcolando con il tuo metodo mi dà sempre 183.00

edit: mi correggo il record cassa è in ritardo di 1 su tutto il database

esempio nei record ho
1 entrate 50 uscite 0 cassa 50
2 entrate 20 uscite 0 cassa 50
3 entrate 10 uscite 0 cassa 70
4 entrate 0 uscite 40 cassa 80

[dex]

Per sapere il saldo cassa in un dato giorno mi basta una semplice interrogazione al database, senza scorrere alcun record. Solo se devo visualizzare le operazioni comprese in un intervallo di date, sono obbligato a scorrere i record per calcolare e visualizzare il saldo, che chiaramente varierà dopo ogni singola operazione.
Poi è normale che l'elaborazione impieghi più tempo a seconda del numero di registrazioni.

scusa ma se per sapere il saldo a un determinato giorno vuol dire che salvi il valore saldo da qualche parte?