View aggregate
3 views
Skip to first unread message
Janox - Uniteam s.r.l.
Mar 26, 2026, 7:44:13 AMMar 26
to jxsu...@googlegroups.com
Ciao Tommaso,
ho una view con una sum definita nelle sue proprietà senza il flag di aggregazione automatica attivo (eseguo una recordset aggregate nella action di ricerca che esegue recordset first -> aggregate).
La variabile di appoggio la metto nel footer di una colonna.
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.
Immagino che se la view è vuota la recordset aggregate non venga scatenata veramente.
Ho risolto azzerando la variabile di appoggio subito prima della aggregate e ho risolto, ma volevo segnalartelo per capire se il comportamento è voluto oppure no e, se voluto, va ricordato al programmatore in un qualche modo.
A disposizione
Grazie
Ciao e buona giornata
ho una view con una sum definita nelle sue proprietà senza il flag di aggregazione automatica attivo (eseguo una recordset aggregate nella action di ricerca che esegue recordset first -> aggregate).
La variabile di appoggio la metto nel footer di una colonna.
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.
Immagino che se la view è vuota la recordset aggregate non venga scatenata veramente.
Ho risolto azzerando la variabile di appoggio subito prima della aggregate e ho risolto, ma volevo segnalartelo per capire se il comportamento è voluto oppure no e, se voluto, va ricordato al programmatore in un qualche modo.
A disposizione
Grazie
Ciao e buona giornata
---------------------------------------------------------------------------
Janox
---------------------------------------------------------------------------
Via San Pier Tommaso, 18/3 - 40139 Bologna (BO) - Italia
---------------------------------------------------------------------------
Tel: (+39) 051 54 24 10
Mail: ja...@uniteambo.it
Web: https://www.uniteambo.it/
Assistenza: https://custom.teamviewer.com/6z4s2dm
---------------------------------------------------------------------------
Janox
---------------------------------------------------------------------------
Via San Pier Tommaso, 18/3 - 40139 Bologna (BO) - Italia
---------------------------------------------------------------------------
Tel: (+39) 051 54 24 10
Mail: ja...@uniteambo.it
Web: https://www.uniteambo.it/
Assistenza: https://custom.teamviewer.com/6z4s2dm
---------------------------------------------------------------------------
Tommaso Vannini
Mar 28, 2026, 9:34:51 PMMar 28
to jxsu...@googlegroups.com
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)
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
copia del programma e la metti sotto il mio developer.
> Immagino che se la view è vuota la recordset aggregate non venga
> scatenata veramente.
> 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.
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)
Janox - Uniteam s.r.l.
Mar 30, 2026, 4:10:24 AMMar 30
to jxsu...@googlegroups.com
Buongiorno Tommaso,
sotto il tuo dev trovi il prg tommy_view_aggregate, usa il db lardini.
Nella action ricerca trovi le istruzioni di reset variabile del footer (attualmente a false, quindi "senza mia patch") e la recordset aggregate.
Pensavo di aver patchato correttamente il prg ma in realtà no.
Come dici tu la variabile di appoggio viene azzerata correttamente ma non viene scritta nel footer perchè non ci sono righe nella view.
Non so se questo sia il comportamento voluto, ma mi aspetterei di vedere 0 nella colonna "Ordinato".
Per testare il "problema" esegui come primo filtro "stagione = AI27", clicca ricerca e vedrai correttamente il totale nella colonna "Ordinato", poi aggiungi il filtro "commessa = 1111111111", clicca ricerca.
Non ci saranno record e non si vedrà 0 nel totale colonna "Ordinato".
Ripeto che alla fine non è un problema, se non ci sono righe il totale è per forza 0 di conseguenza, ma se senza sforzo e senza destabilizzazioni sia possibile scrivere comunque "0" sono certo che l'utente sarà più contento.
Spero di averti dato tutte le info...
Grazie mille
Ciao e buona giornata
sotto il tuo dev trovi il prg tommy_view_aggregate, usa il db lardini.
Nella action ricerca trovi le istruzioni di reset variabile del footer (attualmente a false, quindi "senza mia patch") e la recordset aggregate.
Pensavo di aver patchato correttamente il prg ma in realtà no.
Come dici tu la variabile di appoggio viene azzerata correttamente ma non viene scritta nel footer perchè non ci sono righe nella view.
Non so se questo sia il comportamento voluto, ma mi aspetterei di vedere 0 nella colonna "Ordinato".
Per testare il "problema" esegui come primo filtro "stagione = AI27", clicca ricerca e vedrai correttamente il totale nella colonna "Ordinato", poi aggiungi il filtro "commessa = 1111111111", clicca ricerca.
Non ci saranno record e non si vedrà 0 nel totale colonna "Ordinato".
Ripeto che alla fine non è un problema, se non ci sono righe il totale è per forza 0 di conseguenza, ma se senza sforzo e senza destabilizzazioni sia possibile scrivere comunque "0" sono certo che l'utente sarà più contento.
Spero di averti dato tutte le info...
Grazie mille
Ciao e buona giornata
---------------------------------------------------------------------------
Janox
---------------------------------------------------------------------------
Via San Pier Tommaso, 18/3 - 40139 Bologna (BO) - Italia
---------------------------------------------------------------------------
Tel: (+39) 051 54 24 10
Mail: ja...@uniteambo.it
Web: https://www.uniteambo.it/
Assistenza: https://custom.teamviewer.com/6z4s2dm
---------------------------------------------------------------------------
Janox
---------------------------------------------------------------------------
Via San Pier Tommaso, 18/3 - 40139 Bologna (BO) - Italia
---------------------------------------------------------------------------
Tel: (+39) 051 54 24 10
Mail: ja...@uniteambo.it
Web: https://www.uniteambo.it/
Assistenza: https://custom.teamviewer.com/6z4s2dm
---------------------------------------------------------------------------
Janox - Uniteam s.r.l.
Mar 30, 2026, 4:33:02 AMMar 30
to jxsu...@googlegroups.com
Mi sono dimenticato lo screenshot dell'action
"ricerca":
---------------------------------------------------------------------------
Janox
---------------------------------------------------------------------------
Via San Pier Tommaso, 18/3 - 40139 Bologna (BO) - Italia
---------------------------------------------------------------------------
Tel: (+39) 051 54 24 10
Mail: ja...@uniteambo.it
Web: https://www.uniteambo.it/
Assistenza: https://custom.teamviewer.com/6z4s2dm
---------------------------------------------------------------------------
Janox
---------------------------------------------------------------------------
Via San Pier Tommaso, 18/3 - 40139 Bologna (BO) - Italia
---------------------------------------------------------------------------
Tel: (+39) 051 54 24 10
Mail: ja...@uniteambo.it
Web: https://www.uniteambo.it/
Assistenza: https://custom.teamviewer.com/6z4s2dm
---------------------------------------------------------------------------
Janox - Uniteam s.r.l.
Mar 30, 2026, 8:43:41 AMMar 30
to jxsu...@googlegroups.com
Chiedo giusto per scrupolo: tu lavori con il parametro di applicazione "bug_aggregate" ad OFF, vero..?!
Ho appena verificato che il parametro è a ON sia in sviluppo sia
in produzione...
---------------------------------------------------------------------------
Janox
---------------------------------------------------------------------------
Via San Pier Tommaso, 18/3 - 40139 Bologna (BO) - Italia
---------------------------------------------------------------------------
Tel: (+39) 051 54 24 10
Mail: ja...@uniteambo.it
Web: https://www.uniteambo.it/
Assistenza: https://custom.teamviewer.com/6z4s2dm
---------------------------------------------------------------------------
Janox
---------------------------------------------------------------------------
Via San Pier Tommaso, 18/3 - 40139 Bologna (BO) - Italia
---------------------------------------------------------------------------
Tel: (+39) 051 54 24 10
Mail: ja...@uniteambo.it
Web: https://www.uniteambo.it/
Assistenza: https://custom.teamviewer.com/6z4s2dm
---------------------------------------------------------------------------
--
--
Hai ricevuto questo messaggio in quanto sei iscritto al gruppo di supporto per gli sviluppatori Janox (www.janox.it).
---
Hai ricevuto questo messaggio perché sei iscritto al gruppo "jxsupport" di Google Gruppi.
Per annullare l'iscrizione a questo gruppo e non ricevere più le sue email, invia un'email a jxsupport+...@googlegroups.com.
Per visualizzare questa discussione, visita https://groups.google.com/d/msgid/jxsupport/5083b7bd-366c-492d-a8bc-e57e52bb45cc%40uniteambo.it.
Tommaso Vannini
Mar 30, 2026, 9:26:48 AMMar 30
to jxsu...@googlegroups.com
Ciao Maurizio,
come da conversazione:
Il footer per essere visualizzato deve essere valorizzato e 0 (zero)
viene letto come blank.
La soluzione più semplice è mettere nel footer un'espressione del tipo:
(o2zero(<var>) ? '-' : o2val(<var>))
Dove ovviamente al posto del trattino puoi mettere l'espressione che
preferisci ("N. 0", "Zero", ecc...).
> Ho appena verificato che il parametro è a ON sia in sviluppo sia in
> produzione...
Confido che risolverai quanto prima :)
Se sei d'accordo direi di chiudere questo thread.
come da conversazione:
Il footer per essere visualizzato deve essere valorizzato e 0 (zero)
viene letto come blank.
La soluzione più semplice è mettere nel footer un'espressione del tipo:
(o2zero(<var>) ? '-' : o2val(<var>))
Dove ovviamente al posto del trattino puoi mettere l'espressione che
preferisci ("N. 0", "Zero", ecc...).
> Ho appena verificato che il parametro è a ON sia in sviluppo sia in
> produzione...
Se sei d'accordo direi di chiudere questo thread.
Janox - Uniteam s.r.l.
Mar 30, 2026, 9:29:00 AMMar 30
to jxsu...@googlegroups.com
Ciao Tommaso,
La soluzione più semplice è mettere nel footer un'espressione del tipo: (o2zero(<var>) ? '-' : o2val(<var>))
Perfetto, procedo in questo senso.
Ho appena verificato che il parametro è a ON sia in sviluppo sia in produzione...Confido che risolverai quanto prima :)
Assolutamente si!
Se sei d'accordo direi di chiudere questo thread.
Si puoi chiudere.
Grazie mille
Ciao e buona giornata
---------------------------------------------------------------------------
Janox
---------------------------------------------------------------------------
Via San Pier Tommaso, 18/3 - 40139 Bologna (BO) - Italia
---------------------------------------------------------------------------
Tel: (+39) 051 54 24 10
Mail: ja...@uniteambo.it
Web: https://www.uniteambo.it/
Assistenza: https://custom.teamviewer.com/6z4s2dm
---------------------------------------------------------------------------
Janox
---------------------------------------------------------------------------
Via San Pier Tommaso, 18/3 - 40139 Bologna (BO) - Italia
---------------------------------------------------------------------------
Tel: (+39) 051 54 24 10
Mail: ja...@uniteambo.it
Web: https://www.uniteambo.it/
Assistenza: https://custom.teamviewer.com/6z4s2dm
---------------------------------------------------------------------------
Tommaso Vannini
May 24, 2026, 8:27:35 PMMay 24
to Janox, Maurizio Magnani - Data Technology s.r.l.
Ciao Maurizio,
riporto qui il thread "Problema parametro bug_aggregate", come da tua
richiesta, ed ho chiuso l'altro.
Ovviamente ci sono due comportamenti diversi per il parametro
"bug_aggragate" ad ON/OFF e, effettivamente, entrambi mostrano delle
criticità, nella tua segnalazione.
Il comportamento con "bug_aggragate" ad ON, con aggregazioni a zero,
come ti ho spiegato nella precedente mail, è quello storicamente atteso,
canonico, ma è appunto quello che dobbiamo superare, perché errato.
Con il parametro ad OFF spiego il comportamento, per chi ci legge in
copia:
Hai una vista con view-selector ed un filtro per le sole righe
selezionate.
Azionando il filtro le aggregazioni risultano corrette, ma c'è
un'"apparente" sostituzione del record corrente nella vista filtrata,
con un record del vecchio dataset (non filtrato).
Questo dipende dal modo in cui riporto le proprietà della vista dopo il
loop di calcolo, ma qui la cosa si complica assai.
Premetto, per chi non volesse leggersi tutta la spiegazione successiva,
che credo di aver già corretto il problema.
La patch è presente in ufficio (module "jxenv.inc") e sarà inclusa nei
prossimi rilasci, se confermata.
NOTA:
Questa cosa non inficia la stabilità della runtime attualmente in
rilascio.
Possiamo consolidare questa runtime per il parametro "bug_aggregate" ad
ON, come lo avete sempre tenuto tutti, per cui non è cambiato (e non
cambierà) niente.
Tuttavia se riuscissi ad includere nella versione, prima del
consolidamento effettivo, anche un comportamento coerente per il
parametro ad OFF sarei molto più contento.
Ora vediamo il problema nel dettaglio, per chi ha voglia di seguirci.
Questa cosa del loop per le aggregazioni risale ad almeno 10 anni fa (è
precedente al mio tracing accurato su Git).
Nel tempo ho avuto più volte l'esigenza di fare un loop su una vista per
calcolare qualcosa, cercando di lasciare la vista il più intatta
possibile, rispetto al suo stato effettivo.
Se faccio un loop su una vista cambio un sacco di cose della vista:
prima di tutto il dataset (se sono intervenuti dei filtri) e
sicuramente il record corrente (se diverso dal primo).
Ad esempio, se la vista è in insert, con un buffer valorizzato, dopo
il loop mi perdo il buffer...
E poi posso cambiarne le dipendenze, a seconda dei filtri che
intervengono, ecc...
A questa esigenza, nel tempo, ho dato risposte diverse, adottando
tecniche diverse.
In particolare la logica utilizzata per le aggregazioni è condivisa con
la logica della count, o2view_total(), comportamento per il quale non
avete un parametro "bug_*", ma viene utilizzato sempre da tutti, da
diversi anni, quindi estremamente consolidato.
Sulla o2view_total(), però, è stato fatto un lavoro di affinamento
enorme (ai tempi di Valerio) ed infatti non dà problemi apparenti (vedi
sotto cosa intendo per apparenti).
La logica utilizzata per il loop delle aggregate e dalla view-total è
molto complicata, si salva un array di cloni delle proprietà, e poi li
ripristina sulla vista originale...
Insomma, alla fine andavo a mettere nella vista, dopo il loop, un record
corrente (solo apparente) che ormai non apparteneva più al dataset.
Da qui l'errore segnalato.
Sulla logica della o2view_total() veniva presa un'accortezza in più, per
cui, in casi come questo, alla fine, veniva ricostruita la vista.
Ho riportato questa accortezza anche nella logica di aggregazione e mi
sembra che risolva, nella patch attuale.
Tuttavia non son soddisfatto:
Credo che sia la logica della o2view_total() che quella delle
aggregazioni possano causare alcuni effetti collaterali indesiderati e
inaspettati: quanto meno la perdita del record corrente, in alcune
condizioni.
Voi, plausibilmente, non vi siete mai accorti dei problemi,
fondamentalmente per due motivi:
1. non sono operazioni (soprattutto la view-toal) che di solito vengono
fatte con l'interazione su un singolo record: se aggiungete un
filtro nella sezione dei filtri, esterna alla grid, nella maggior
parte dei casi vi sembrerà normale che il puntatore torni sul primo
record;
2. uno dei problemi è che questa cosa causa l'esecuzione di almeno una
query in più del necessario e questa non è una cosa che voi potete
notare o monitorate, tantomeno se legata ad operazioni globali sul
dataset.
Come sicuramente ricorderai per i recenti sviluppi sul view-selector
eravamo incorsi in problemi simili.
In quello sviluppo, con almeno 10 anni di esperienza in più, credo di
aver dato una soluzione migliore all'esigenza di looppare su una vista,
cercando di lasciarla nel proprio stato attuale, che potrebbe essere
usata in tutti i casi.
Tuttavia non mi sembra il caso di mettere mano a questa cosa ora, quindi
credo che, per il consolidamento attuale, convenga attenerci alla
conferma della patch.
Quindi, ricapitolando:
Il problema dovrebbe essere risolto, riportando una logica ampiamente
condivisa e consolidata, come quella della view-total.
Per il futuro vorrei (davvero) standardizzare un modo di creare una
copia di una vista, per farci quello che mi serve, ma lasciandola nel
proprio stato attuale, e vorrei adottare questa tecnica standard in
tutti i casi, view-total, aggragate, view-selector-count, ma anche in
altri, che sono certo di avere, sparsi in runtime.
Questo scopo, però, direi di non ricercarlo nell'ambito dell'attuale
consolidamento, ma di destinarlo a sviluppi futuri: mi aprirò un TODO a
riguardo, perché credo che sarebbe importante, sia ai fini della
stabilità, che della manutenibilità della runtime.
Attendo conferma correzione.
riporto qui il thread "Problema parametro bug_aggregate", come da tua
richiesta, ed ho chiuso l'altro.
Ovviamente ci sono due comportamenti diversi per il parametro
"bug_aggragate" ad ON/OFF e, effettivamente, entrambi mostrano delle
criticità, nella tua segnalazione.
Il comportamento con "bug_aggragate" ad ON, con aggregazioni a zero,
come ti ho spiegato nella precedente mail, è quello storicamente atteso,
canonico, ma è appunto quello che dobbiamo superare, perché errato.
Con il parametro ad OFF spiego il comportamento, per chi ci legge in
copia:
Hai una vista con view-selector ed un filtro per le sole righe
selezionate.
Azionando il filtro le aggregazioni risultano corrette, ma c'è
un'"apparente" sostituzione del record corrente nella vista filtrata,
con un record del vecchio dataset (non filtrato).
Questo dipende dal modo in cui riporto le proprietà della vista dopo il
loop di calcolo, ma qui la cosa si complica assai.
Premetto, per chi non volesse leggersi tutta la spiegazione successiva,
che credo di aver già corretto il problema.
La patch è presente in ufficio (module "jxenv.inc") e sarà inclusa nei
prossimi rilasci, se confermata.
NOTA:
Questa cosa non inficia la stabilità della runtime attualmente in
rilascio.
Possiamo consolidare questa runtime per il parametro "bug_aggregate" ad
ON, come lo avete sempre tenuto tutti, per cui non è cambiato (e non
cambierà) niente.
Tuttavia se riuscissi ad includere nella versione, prima del
consolidamento effettivo, anche un comportamento coerente per il
parametro ad OFF sarei molto più contento.
Ora vediamo il problema nel dettaglio, per chi ha voglia di seguirci.
Questa cosa del loop per le aggregazioni risale ad almeno 10 anni fa (è
precedente al mio tracing accurato su Git).
Nel tempo ho avuto più volte l'esigenza di fare un loop su una vista per
calcolare qualcosa, cercando di lasciare la vista il più intatta
possibile, rispetto al suo stato effettivo.
Se faccio un loop su una vista cambio un sacco di cose della vista:
prima di tutto il dataset (se sono intervenuti dei filtri) e
sicuramente il record corrente (se diverso dal primo).
Ad esempio, se la vista è in insert, con un buffer valorizzato, dopo
il loop mi perdo il buffer...
E poi posso cambiarne le dipendenze, a seconda dei filtri che
intervengono, ecc...
A questa esigenza, nel tempo, ho dato risposte diverse, adottando
tecniche diverse.
In particolare la logica utilizzata per le aggregazioni è condivisa con
la logica della count, o2view_total(), comportamento per il quale non
avete un parametro "bug_*", ma viene utilizzato sempre da tutti, da
diversi anni, quindi estremamente consolidato.
Sulla o2view_total(), però, è stato fatto un lavoro di affinamento
enorme (ai tempi di Valerio) ed infatti non dà problemi apparenti (vedi
sotto cosa intendo per apparenti).
La logica utilizzata per il loop delle aggregate e dalla view-total è
molto complicata, si salva un array di cloni delle proprietà, e poi li
ripristina sulla vista originale...
Insomma, alla fine andavo a mettere nella vista, dopo il loop, un record
corrente (solo apparente) che ormai non apparteneva più al dataset.
Da qui l'errore segnalato.
Sulla logica della o2view_total() veniva presa un'accortezza in più, per
cui, in casi come questo, alla fine, veniva ricostruita la vista.
Ho riportato questa accortezza anche nella logica di aggregazione e mi
sembra che risolva, nella patch attuale.
Tuttavia non son soddisfatto:
Credo che sia la logica della o2view_total() che quella delle
aggregazioni possano causare alcuni effetti collaterali indesiderati e
inaspettati: quanto meno la perdita del record corrente, in alcune
condizioni.
Voi, plausibilmente, non vi siete mai accorti dei problemi,
fondamentalmente per due motivi:
1. non sono operazioni (soprattutto la view-toal) che di solito vengono
fatte con l'interazione su un singolo record: se aggiungete un
filtro nella sezione dei filtri, esterna alla grid, nella maggior
parte dei casi vi sembrerà normale che il puntatore torni sul primo
record;
2. uno dei problemi è che questa cosa causa l'esecuzione di almeno una
query in più del necessario e questa non è una cosa che voi potete
notare o monitorate, tantomeno se legata ad operazioni globali sul
dataset.
Come sicuramente ricorderai per i recenti sviluppi sul view-selector
eravamo incorsi in problemi simili.
In quello sviluppo, con almeno 10 anni di esperienza in più, credo di
aver dato una soluzione migliore all'esigenza di looppare su una vista,
cercando di lasciarla nel proprio stato attuale, che potrebbe essere
usata in tutti i casi.
Tuttavia non mi sembra il caso di mettere mano a questa cosa ora, quindi
credo che, per il consolidamento attuale, convenga attenerci alla
conferma della patch.
Quindi, ricapitolando:
Il problema dovrebbe essere risolto, riportando una logica ampiamente
condivisa e consolidata, come quella della view-total.
Per il futuro vorrei (davvero) standardizzare un modo di creare una
copia di una vista, per farci quello che mi serve, ma lasciandola nel
proprio stato attuale, e vorrei adottare questa tecnica standard in
tutti i casi, view-total, aggragate, view-selector-count, ma anche in
altri, che sono certo di avere, sparsi in runtime.
Questo scopo, però, direi di non ricercarlo nell'ambito dell'attuale
consolidamento, ma di destinarlo a sviluppi futuri: mi aprirò un TODO a
riguardo, perché credo che sarebbe importante, sia ai fini della
stabilità, che della manutenibilità della runtime.
Attendo conferma correzione.
Janox - Uniteam s.r.l.
May 25, 2026, 3:49:18 AMMay 25
to Tommaso Vannini, Janox
Buongiorno Tommaso,
ho fatto varie prove sul programma del video.
ho fatto varie prove sul programma del video.
- bug_aggregate = OFF
- Il programma si comporta come deve, quindi confermo la correzione con la patch del server.
- bug_aggregate = ON
- Mi sembra di capire, ho letto la mail
due volte ma forse non ho proprio capito tutto, che le
aggregazioni su una vista con un campo formula "selector" e
relativo filtro "min-max" su di esso fa si che
l'aggregazione sulla vista non sia risolvibile, è corretto
quello che dico?
Quindi, in pratica, in tutte le viste dove viene usato il selector con relativo filtro "visualizza righe selezionate", le aggregazioni non funzionano (forse non sono mai funzionate ma o non avevo casi oppure le facevo in altro modo scorrendomi la vista per intero e valorizzando "il totale" man mano che trovavo un record con selector true).
Ho scritto una cavolata? Mi serve per capire come gestire eventuali casi e/o implementazioni future se per qualche motivo mi dovessi trovare obbligato a tenere il parametro ad ON.
Carico la patch sul server di produzione, dove c'è già l'ultima runtime, e metto il parametro bug_aggregate a OFF.
Vediamo cosa succede.
Puoi lasciare il thread aperto per qualche giorno?
Grazie mille
Ciao e buona giornata
---------------------------------------------------------------------------
Janox
---------------------------------------------------------------------------
Via San Pier Tommaso, 18/3 - 40139 Bologna (BO) - Italia
---------------------------------------------------------------------------
Tel: (+39) 051 54 24 10
Mail: ja...@uniteambo.it
Web: https://www.uniteambo.it/
Assistenza: https://custom.teamviewer.com/6z4s2dm
---------------------------------------------------------------------------
Janox
---------------------------------------------------------------------------
Via San Pier Tommaso, 18/3 - 40139 Bologna (BO) - Italia
---------------------------------------------------------------------------
Tel: (+39) 051 54 24 10
Mail: ja...@uniteambo.it
Web: https://www.uniteambo.it/
Assistenza: https://custom.teamviewer.com/6z4s2dm
---------------------------------------------------------------------------
Tommaso Vannini
May 25, 2026, 6:35:51 PMMay 25
to Janox
Ciao Maurizio.
> bug_aggregate = OFF
> Il programma si comporta come deve, quindi confermo la correzione con
> la patch del server.
Ottimo.
> bug_aggregate = ON
> le aggregazioni su una vista con un campo formula "selector" e
> relativo filtro "min-max" su di esso fa si che l'aggregazione sulla
> vista non sia risolvibile, è corretto quello che dico?
Sì, ma non solo in caso di selector: come ti ho detto un filtro su
qualunque formula rende la vista non aggregabile.
> (forse non sono mai funzionate ma o non avevo casi
Ti garantisco che non hanno mai funzionato, il comportamento con
"bug_aggregate" ad ON è quello di 20 anni fa, ma anche di più.
Credo che dopo i recenti sviluppi tu abbia intensificato l'utilizzo del
view-selector, magari è per questo che lo noti solo ora.
Comunque io erano parecchi anni che non mi spiegavo come potevate
lavorare col "bug_aggregate" ad ON...
> oppure le facevo in altro modo scorrendomi la vista per intero e
> valorizzando "il totale" man mano che trovavo un record con selector
> true).
Che è esattamente quello che fa la runtime con "bug_aggregate" ad OFF,
ma con vari vantaggi:
1. lo fa (solo) quando serve, quindi non dovete preoccuparvi se cambia
qualcosa nella forma della vista;
2. lo fa molto più velocemente, con un loop in fetch dedicato che non
sposta l'intero contesto del programma per ogni record del dataset;
3. lo fa su una view di servizio (correzione in oggetto), che lascia
intatta la vista originale.
> Mi serve per capire come gestire eventuali casi e/o implementazioni
> future se per qualche motivo mi dovessi trovare obbligato a tenere il
> parametro ad ON.
Non vedo perché dovresti: consolidiamo il comportamento ad OFF, se
emergessero altre criticità correggiamole (ma dubito che ce ne saranno
altre) e un giorno potremo auspicabilmente togliere il parametro.
Secondo me potrai tenerlo ad OFF sempre e dimenticarti il problema, a
partire dal consolidamento di questa release.
> Puoi lasciare il thread aperto per qualche giorno?
Anche più di qualche giorno, se non ci saranno controindicazioni
rilascerò il 3 giugno.
> bug_aggregate = OFF
> Il programma si comporta come deve, quindi confermo la correzione con
> la patch del server.
> bug_aggregate = ON
> le aggregazioni su una vista con un campo formula "selector" e
> relativo filtro "min-max" su di esso fa si che l'aggregazione sulla
> vista non sia risolvibile, è corretto quello che dico?
qualunque formula rende la vista non aggregabile.
> (forse non sono mai funzionate ma o non avevo casi
"bug_aggregate" ad ON è quello di 20 anni fa, ma anche di più.
Credo che dopo i recenti sviluppi tu abbia intensificato l'utilizzo del
view-selector, magari è per questo che lo noti solo ora.
Comunque io erano parecchi anni che non mi spiegavo come potevate
lavorare col "bug_aggregate" ad ON...
> oppure le facevo in altro modo scorrendomi la vista per intero e
> valorizzando "il totale" man mano che trovavo un record con selector
> true).
ma con vari vantaggi:
1. lo fa (solo) quando serve, quindi non dovete preoccuparvi se cambia
qualcosa nella forma della vista;
2. lo fa molto più velocemente, con un loop in fetch dedicato che non
sposta l'intero contesto del programma per ogni record del dataset;
3. lo fa su una view di servizio (correzione in oggetto), che lascia
intatta la vista originale.
> Mi serve per capire come gestire eventuali casi e/o implementazioni
> future se per qualche motivo mi dovessi trovare obbligato a tenere il
> parametro ad ON.
emergessero altre criticità correggiamole (ma dubito che ce ne saranno
altre) e un giorno potremo auspicabilmente togliere il parametro.
Secondo me potrai tenerlo ad OFF sempre e dimenticarti il problema, a
partire dal consolidamento di questa release.
> Puoi lasciare il thread aperto per qualche giorno?
rilascerò il 3 giugno.
Tommaso Vannini
Jun 2, 2026, 9:36:23 PMJun 2
to Janox
Ciao Maurizio,
questa patch è presente in release odierna.
Possiamo chiudere?
questa patch è presente in release odierna.
Possiamo chiudere?
Janox - Uniteam s.r.l.
Jun 3, 2026, 3:19:59 AMJun 3
to jxsu...@googlegroups.com
Ciao Tommaso,
si puoi chiudere.
Ho messo il parametro ad OFF sul server SaaS di produzione.
Se dovessero emergere problemi riaprirò il thread.
Grazie mille
Un saluto e buona giornata
si puoi chiudere.
Ho messo il parametro ad OFF sul server SaaS di produzione.
Se dovessero emergere problemi riaprirò il thread.
Grazie mille
Un saluto e buona giornata
---------------------------------------------------------------------------
Janox
---------------------------------------------------------------------------
Via San Pier Tommaso, 18/3 - 40139 Bologna (BO) - Italia
---------------------------------------------------------------------------
Tel: (+39) 051 54 24 10
Mail: ja...@uniteambo.it
Web: https://www.uniteambo.it/
Assistenza: https://custom.teamviewer.com/6z4s2dm
---------------------------------------------------------------------------
Janox
---------------------------------------------------------------------------
Via San Pier Tommaso, 18/3 - 40139 Bologna (BO) - Italia
---------------------------------------------------------------------------
Tel: (+39) 051 54 24 10
Mail: ja...@uniteambo.it
Web: https://www.uniteambo.it/
Assistenza: https://custom.teamviewer.com/6z4s2dm
---------------------------------------------------------------------------
Reply all
Reply to author
Forward
This conversation is locked
You cannot reply and perform actions on locked conversations.
0 new messages