Ciao Maurizio,
non sono riuscito a vedere il problema.
Non so più davvero come dirlo: non date mai per scontato che un
comportamento osservato, specialmente su funzionalità consolidate, sia
facilmente riproducibile!
Anche perché, se lo fosse realmente stato, sarebbe già emerso e sarebbe
già stato risolto.
Quindi quando mi segnalate un problema fornitemi sempre un contesto in
cui verificarlo, altrimenti:
- io perdo un sacco di tempo cercando di replicarlo, magari
inutilmente;
- voi otterrete la soluzione più tardi.
> Ho risolto azzerando la variabile di appoggio subito prima della
> aggregate
Giusto patchare quanto prima per esigenze applicative: ma fai prima una
copia del programma e la metti sotto il mio developer.
> Immagino che se la view è vuota la recordset aggregate non venga
> scatenata veramente.
No, viene scatenata sempre.
> Ho notato che se la view ha dei record funziona tutto, ma se applico
> un filtro che non mi restituisce record, la variabile di appoggio non
> viene aggiornata con 0 ma rimane con l'ultimo valore corrispondente ad
> almeno 1 record nella view.
Non sono riuscito a vedere questa cosa, in nessun modo.
Dai miei test la variabile viene correttamente aggiornata a zero, come a
qualunque altro valore.
Al limite, a seconda di come è scritto il footer, in caso di zero può
non comparire la riga del footer, ma non un vecchio (o errato) valore.
Chiedo giusto per scrupolo: tu lavori con il parametro di applicazione
"bug_aggregate" ad OFF, vero..?!
Tuttavia la runtime ha due percorsi logici piuttosto diversi, a seconda
che le aggregate siano o non siano "countable", cioè effettivamente
ricavabili da un'aggregazione sul DB o che necessitino di un loop,
perché non risolvibili in query SQL.
Possibile che la tua vista abbia filtri su formule o link non risolte in
join..?
Ancora una volta direi che l'unica soluzione è che tu mi fornisca il
caso specifico.
Fammi sapere.
Saluti
--
. Tommaso Vannini
. <
tvan...@janox.it>
. Software analysis & development
. Janox project manager (
www.janox.it)