Newsgroup: it.comp.lang.delphi
Titolo: Come fate vio?

Un'applicazione contabile offre all'utente una serie di situazioni e report 
assai simil tra loro, ma che mostrano i vari oggetti contabili, tipo 
Entrate, uscite, etc , a diverso livello di sommarizzazione , dal dettaglio 
fino ai totali generali, con criteri di raggruppamento va,ri in funzione del 
tempo (Anni, mesi) e/o di tipi di operazione (Banche, Carte di Credito), 
etc.
Uso per questo un grande numero di select, molte parametrizzate in modo da 
ridurne quanto più possibile il numero.
Delle voci di menu indirizzano l'utente nella scelta dell'una o dell'altra 
situazione e il programma esegue ogni volta delle query per produrre quando 
richiesto.
Mi chiedo come potrei minimizzare le risorse, ad esempio 1) evitando di 
rieseguire le query  che sono già state eseguit, o 2) strutturando le select 
in modo diverso.
1) Come posso accorgermi se, per esempio, l'utente ha richiesto un report, 
poi ha fatto qualche altra attività ed è tornato successivamente ad 
riesaminarlo?
2) Quasi sempre una situazione contabile richiede più livelli di 
sommarizzazione. Meglio eseguire tante query quanti sono questi livelli o 
fare invece una query che produce il livello più basso e ricavare i livelli 
superiori calcolandoli dalla scansione di questi?
Come fate voi?
 
 

 superiori calcolandoli dalla scansione di questi? 
 
Intanto, dai per scontato che tutto si possa risolvere CON UNA SOLA QUERY.
Sei VERAMENTE certo che questo presupposto sia vero?
 

Cerco di essere più chiaro.
1-Non eseguire più volte la stessa query. Faccio un esempio dalla mia 
applicazione, dove in un menu dedicato ai rendiconto scelgo di farmi 
presentare il "Rendiconto per Categoria". Poi scelgo il "Rendiconto" per 
Centro di costo. Ritorno sul primo per chiarirmi un dubbio e poi torno sul 
secondo. Oggi come oggi, rieseguo due volte le query implicate nei due 
report.
2-Strutturare le query in modo diverso. Nell'esempio sopra, le query 
eseguite sono molte e presentano gli stessi dati diversamente raggruppati. 
In ognuno dei due casi, c'è almeno una query che calcola i totali generali 
e, nel primo caso, una  query che calcola i totali raggruppati per categoria 
e nel secondo, due query con un raggruppamento per Centro di costo e 
un'altra per Centro di costo e categoria.
Un'idea di ristrutturazione delle query, adottabile in questo caso e non in 
generale ovviamente, potrebbe essere di fare una sola query a livello di 
Centro di costo e categoria e poi calcolare a programma i totali dei livelli 
superiori fino al totale generale scandendo il risultato della query.
Avrei altre idee in mente, ma mi fermo qui per verificare se quello che dico 
ha un senso.
 
"Alberto Salvati"  ha scritto nel messaggio 
news:5dcc0c22-771b-460f...@googlegroups.com...


Ciao,

Scusami non ho capito bene cosa vuoi fare.
Mi scuso anche con chi ha piu' esperienza di me  ... per quello che 
andro' a scrivere .....
 
Se nelle varie interrogazioni *SEI CERTO* che il risultato finale non 
cambia, cioe' non vari i dati allora per evitare ricalcoli vari puoi 
usare tante query quante sono le tue necessita' avendo cura di non 
distruggere l'oggetto delle query che, a questo punto, saranno variabili 
globali o della mainform.
Una cosa del genere
 
QMeseAnno : TQuery;
QCateCredito : TQuery
QQuellochevoui : TQuery
 
Esegui la select per una query e la tieni li, poi cambi procedura esegui 
un'altra query e la tieni li ecc... essendo gia' pronte le puoi 
richiamare quando vuoi.
Il problema e' se cambiano i dati, in quel caso quelle query non vanno 
piu' bene.
 
Altra alternativa, forse da brividi, e' aprire una form per ogni query 
cosi' da averla a disposizione nelle varie fasi delle tue interrogazioni.
Apri le finestre con SHOW e non con SHOWMODAL.
Una cosa tipo l'ambiente di sviluppo dove le varie finestre (object 
inspector ecc..) le puoi aprire, chiudere, ridimensionare ecc...
Pero' ti fai carico tu della loro chiusura e del loro free.
 
Un'altra possibilita' e' aprire la form del report e riempirla di 
checkbox; ogni checkbox ha un'opzione che sara' inclusa o meno nella 
query, una cosa del tipo
 
if checkBox1.checked then
begin
   QStr:='Select ';
end;
if chckbox2.checked then
begin
   if QSTr<>'' then QStr:=QStr + 'quello che vuoi'
   else
   QStr:=quello che vuoi
end;
ecc...
 
In un mio programma l'ho usato e sta funzionando alla grande, una sola 
form per diverse tipologie di report.
 
 
Nel caso abbia capito male (molto probabile) ... scusami
 
questo argomento interessa anche anche me, cosi' da poter migliorare 
codici esistenti.
 
Ciao
Daniele
 
 

Scusami ...
che cosa usi per i report ??
 
Io sono rimasto a QuickReport, ma sembra abbandonato dopo la scomparsa 
dell'autore ...
 
Grazie
 
Ciao
Daniele
 

 form per diverse tipologie di report. 
 
Diverse...QUANTE? 5, 6 o 100?
 
A.

 dell'autore ... 
 
Nulla cambi affinchè nulla cambi...
 
 
 
A.

 Diverse...QUANTE? 5, 6 o 100?
Sono 12 checkbox, 4 combobox e 3 radio.
Per le mie necessita' questa form racchiude le interrogazioni di cui ho 
bisogno e la query si costruisce in base alle varie selezioni.
Certo, quando si preme il pulsante "esegui" ci sono una marea di "if" e 
la stringa sql generata ritorna quello per cui e' stata impostata.
Se prima di stampare torno indietro, la query viene ricalcolata ....
 
Poi sarebbe interessante sapere come ha risolto il problema ...
 
Ciao e alla prossima ..
 
Daniele

 Nulla cambi affinchè nulla cambi...
Non e' cosi' facile ...
Per i, quando capita, nuovi programmi sotto 10.4 sono alla ricerca di 
nuovi strumenti, fastreport mi convince poco .... ma forse e' dovuto 
alla mia eta' e mi adatto poco ...
Per quelli vecchi dove ogni tanto c'e' un po di manutenzione ed e' stato 
usato QR, mantengo la 10.3
Per migrare da QR ad altri il tempo richiesto e' troppo ....
 
Se usi ancora delphi, tu per i report che libreria stai usando ?
 
Grazie e ciao
 
Daniele
 

 rientri lo rigeneri.
 
Esatto.
 
A.

  tu per i report che libreria stai usando ? 
 
Non faccio report da che manco ricordo.
Comunque, non vi sono molte scelte oltre fastreport e reportbuilder. L'outsider è Crystal ma non lo uso da molti anni e credo che non sia proprio economico.
 
 
A.
 
 

 Maledetto il giorno in cui chi ha progettato delphi 1 ha lasciato il paradigma strutturato...così ci ritroviamo tanto codice delphi scritto come se fosse il maledetto vb6...
Su questo non posso dire nulla perche' non ho la tua esperienza.
 
E' un piacere chiaccherare con te, peccato che intervieni poco ...
 
Buon fine settimana
 
Daniele
 

 Comunque, non vi sono molte scelte oltre fastreport e reportbuilder. L'outsider è Crystal ma non lo uso da molti anni e credo che non sia proprio economico.
Li vado a "sbirciare" e cerco di capirne di piu'.
A dire il vero pensavo chw QuickReport era gestito da una software house 
medio grande .... invece ho appreso che:
- Non so che cosa fa questa societa'
- Riguardo QR si e' fermata alla versione 6.0 per delphi 10.3 e che 
l'installazione per 10.4 e' stata fatta da utenti volenterosi.
 
Tempo fa, per altre librerie (credo le zeos lib ma vado a spanne) avevi 
messo in guardia dicendo che molto spesso (ed e' vero) componenti free o 
shareware spariscono o non sono aggiornati per motivi legati a chi 
programma.
Chi andava a sapere che questo destino avrebbe colpito anche QR ?
 
Buon fine settimana ...
 
Daniele

Mi pare di aver capito che non vale la pena preoccuparsi di qualche 
eventuale ripetizione nell'esecuzione di una stessa select.
L'idea di avere delle query parametrizzate e costruite in funzione di scelte 
fatte dall'utente a cui tu accenni l'ho realizzata con una funzionalità 
libera di ricerca su tutti i movimenti contabili, utilizzatissima,  che è 
utile anche per fare indagini su situazioni particolari atipiche per le 
quali non è stato predisposto un apposito report.
Anche in questo caso comunque, oltre alla select costruita in funzione delle 
scelte fatte, eseguo sempre anche una seconda select per totalizzare almeno 
il campo Importo. Al posto di scandire di nuovo l'intero archivio dei 
movimenti, avrei per esempio potuto ricavare i totali programmaticamente 
scandendo il risultato della prima query e sommando (esempio) il campo 
Importo...
 
"Daniele"  ha scritto nel messaggio news:s4kagi$hap$1...@gioia.aioe.org...


L'idea alla quale tu accenni (form con varie scelte possibili) l'ho 
realizzata con una funzionalità, utilizzatissima, di ricerca libera su tutti 
i movimenti contabili, utile anche nei casi di indagini da farsi su esigenze 
atipiche non coperte da alcun report. Anche in questo caso, io eseguo 
comunque una seconda select per fornire (per alcuni campi Importo) i totali 
generali. Avrei potuto ottenere lo stesso risultato scandendo 
programmaticamente il risultato della select costruita con le scelte fatte e 
sommando i campi Importo.
Mi pare comunque di poter concludere che non valga tanto la pena 
preoccuparsi di una eventuale ripetuta esecuzione della stessa select per 
risparmiare qualche secondo o decimo di secondo..
 
"Daniele"  ha scritto nel messaggio news:s4kagi$hap$1...@gioia.aioe.org...
 


 globali o della mainform.
 
A mio avviso, il miglior prefisso per una variabile globale è //
 
HTH
 
David