Come fate vio?

[Stark]

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?

[Alberto Salvati]

Prima di tutto, realizzare oggi un gestionale magazzino/contabilità etc, è una follia, salvo casi molto particolari.
A parte ciò, generalizzare ciò che hai descritto risulta complicato, sopratutto a causa di ciò che c'è tra la sedia e la scrivania.

Post by Stark
Mi chiedo come potrei minimizzare le risorse, ad esempio 1) evitando di
rieseguire le query che sono già state eseguit,

Descrivi tecnocamente che cosa vuol dire "evitare le query che sono state già eseguite".

o 2) strutturando le select

Post by Stark
in modo diverso.

Come sopra.

Post by Stark
1) Come posso accorgermi se, per esempio, l'utente ha richiesto un report,
poi ha fatto qualche altra attività ed è tornato successivamente ad
riesaminarlo?

A cosa serve accorgersi di ciò?

Post by Stark
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?

Intanto, dai per scontato che tutto si possa risolvere CON UNA SOLA QUERY.
Sei VERAMENTE certo che questo presupposto sia vero?

[Stark]

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-944d-***@googlegroups.com...

Prima di tutto, realizzare oggi un gestionale magazzino/contabilità etc, è
una follia, salvo casi molto particolari.
A parte ciò, generalizzare ciò che hai descritto risulta complicato,
sopratutto a causa di ciò che c'è tra la sedia e la scrivania.

Post by Stark
Mi chiedo come potrei minimizzare le risorse, ad esempio 1) evitando di
rieseguire le query che sono già state eseguit,

Descrivi tecnocamente che cosa vuol dire "evitare le query che sono state
già eseguite".

o 2) strutturando le select

Post by Stark
in modo diverso.

Come sopra.

Post by Stark
1) Come posso accorgermi se, per esempio, l'utente ha richiesto un report,
poi ha fatto qualche altra attività ed è tornato successivamente ad
riesaminarlo?

A cosa serve accorgersi di ciò?

Post by Stark
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?

Intanto, dai per scontato che tutto si possa risolvere CON UNA SOLA QUERY.
Sei VERAMENTE certo che questo presupposto sia vero?

[Daniele]

Ciao,

Post by Stark
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?

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

[Alberto Salvati]

Post by Daniele
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.

Intanto, parlare di variabili globali nel 21° secolo è, a dir poco, una BESTEMMIA.
Detto ciò, tenere query aperte a caso non è gratis...Ogni query aperta mantiene attivo un cursore che alloca risorse del server database.
Se hai 20 utenti e ognuno tiene aperte 20 query arrivi a 400 cursori aperti....

Infine, il concetto di "risultato finale non cambia" è una cazzata.
Basarsi su questo presupposto è SBAGLIATO: se il presupposto CADE, il rischio serio non è usare tanto usare dati non aggiornati quanto NON ACCORGERSI che i dati sono cambiati.

Post by Daniele
Altra alternativa, forse da brividi, e' aprire una form per ogni query
cosi' da averla a disposizione nelle varie fasi delle tue interrogazioni.

Query in un una form?? Ma siamo matti?

Post by Daniele
Apri le finestre con SHOW e non con SHOWMODAL.

..trascuri di sottolineare che devi implementare un sistema per gestire il rientro su una form già aperta.

Post by Daniele
Pero' ti fai carico tu della loro chiusura e del loro free.

In quali casi NON sarebbe a suo carico la free?

Post by Daniele
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
In un mio programma l'ho usato e sta funzionando alla grande, una sola
form per diverse tipologie di report.

Diverse...QUANTE? 5, 6 o 100?

A.

[Daniele]

Ciao, ogni tanto ci si rilegge ...

Post by Alberto Salvati
Intanto, parlare di variabili globali nel 21° secolo è, a dir poco, una BESTEMMIA.

Bhe il mondo e' pieno di bestemiatori .... anche tra i programmatori
professionisti, categoria a cui non appartengo.

Post by Alberto Salvati
Detto ciò, tenere query aperte a caso non è gratis...Ogni query aperta mantiene attivo un cursore che alloca risorse del server database.
Se hai 20 utenti e ognuno tiene aperte 20 query arrivi a 400 cursori aperti....
Infine, il concetto di "risultato finale non cambia" è una cazzata.
Basarsi su questo presupposto è SBAGLIATO: se il presupposto CADE, il rischio serio non è usare tanto usare dati non aggiornati quanto NON ACCORGERSI che i dati sono cambiati.

Infatti quello e' il problema. Non so quali siano le sue necessita',
nella quotidianita' quando generi un report poi lo utilizzi, se esci e
rientri lo rigeneri.

Post by Alberto Salvati

Post by Daniele
Altra alternativa, forse da brividi, e' aprire una form per ogni query
cosi' da averla a disposizione nelle varie fasi delle tue interrogazioni.

Query in un una form?? Ma siamo matti?

No le query stanno fuori grafica nei datamodule, nella form visualizzi i
dati

Post by Alberto Salvati

Post by Daniele
Apri le finestre con SHOW e non con SHOWMODAL.

..trascuri di sottolineare che devi implementare un sistema per gestire il rientro su una form già aperta.

Come si dice ... nulla e' gratuito .... non ci sono scorciatoie !!!

Post by Alberto Salvati

Post by Daniele
Pero' ti fai carico tu della loro chiusura e del loro free.

In quali casi NON sarebbe a suo carico la free?

Glom .... :-(((

Post by Alberto Salvati

Post by Daniele
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
In un mio programma l'ho usato e sta funzionando alla grande, una sola
form per diverse tipologie di report.

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

[Alberto Salvati]

Post by Daniele

Post by Alberto Salvati
Intanto, parlare di variabili globali nel 21° secolo è, a dir poco, una BESTEMMIA.

Bhe il mondo e' pieno di bestemiatori .... anche tra i programmatori

Quindi, siccome tanti scrivono codice ad cazzum, siamo anche noi autorizzati a usare variabili globali?
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...

Post by Daniele
nella quotidianita' quando generi un report poi lo utilizzi, se esci e
rientri lo rigeneri.

Esatto.

A.

[Daniele]

Ciao alberto,

Post by Alberto Salvati

Post by Daniele

Post by Alberto Salvati
Intanto, parlare di variabili globali nel 21° secolo è, a dir poco, una BESTEMMIA.

Bhe il mondo e' pieno di bestemiatori .... anche tra i programmatori

Quindi, siccome tanti scrivono codice ad cazzum, siamo anche noi autorizzati a usare variabili globali?

Assolutamente no, sai benissino che dai tuoi interventi ho imparato
tantissimo e questa e' l'ennesima occasione ... per me.
Quando mi riferivo ai programmatori .... era sullo stesso delphi il
quale ne ha di variabili globali.

Post by Alberto Salvati
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

[Stark]

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$***@gioia.aioe.org...

Ciao,

Post by Stark
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?

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

[Stark]

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$***@gioia.aioe.org...

Ciao,

Post by Stark
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?

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

[David Lastrucci]

Ciao Daniele,

Post by Daniele
Mi scuso anche con chi ha piu' esperienza di me ... per quello che
andro' a scrivere .....

Almeno questo

Post by Daniele
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.

A mio avviso, il miglior prefisso per una variabile globale è //

HTH

David

[Daniele]

Scusami ...
che cosa usi per i report ??

Io sono rimasto a QuickReport, ma sembra abbandonato dopo la scomparsa
dell'autore ...

Grazie

Ciao
Daniele

[Alberto Salvati]

Post by Daniele
che cosa usi per i report ??

Cosa c'entra con il tuo problema?

Post by Daniele
Io sono rimasto a QuickReport, ma sembra abbandonato dopo la scomparsa
dell'autore ...

Nulla cambi affinchè nulla cambi...



A.

[Daniele]

Ciao,

Post by Alberto Salvati

Post by Daniele
che cosa usi per i report ??

Cosa c'entra con il tuo problema?

Assolutamente niente ...
Una domanda .... Dato che non riesco a portare QuickReport 5.06 sotto
10.4.x forse trovavo una soluzione !!

Post by Alberto Salvati

Post by Daniele
Io sono rimasto a QuickReport, ma sembra abbandonato dopo la scomparsa
dell'autore ...

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

[Alberto Salvati]

Post by Daniele
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 ...

FastReport non è male.
Anni fa, una "volpe" si inventò "fuzzy Report" derivandolo dalla versione free di fastReport.
Ovviamente non erano compatibili.
Non so se dare un "premio" a chi si è inventato sta cosa o chi HA USATO sta cosa.

Post by Daniele
Se usi ancora delphi,

Purtroppo si.
Dico purtroppo in quanto non è più la "roccia" che era fino a qualche anno fa.
Mentre visual studio è migliorato tanto, Delphi è peggiorato. Potendo, lo mollerei "5 ANNI FA"...

Post by Daniele
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.

[Daniele]

Ciao,

Post by Alberto Salvati
FastReport non è male.
Anni fa, una "volpe" si inventò "fuzzy Report" derivandolo dalla versione free di fastReport.
Ovviamente non erano compatibili.
Non so se dare un "premio" a chi si è inventato sta cosa o chi HA USATO sta cosa.

Perche' risparmiare !!!
Ad entrambi !!! eheheheh

Post by Alberto Salvati
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.

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