Newsgroup: it.comp.appl.access
Titolo: un Database Modello Network

Salve, lo ammetto, non mi è mai capitato di progettare un Db a rete... più complesso dei db Molti a Molti, in cui i figli hanno più genitori.
Avete qualche suggerimento? Uno schema di relazioni tra tabelle? 
Vi ringrazio


Spiega cosa intendi per 'Db a rete' o 'Database Modello Network'
 

Chiarisco: 
Mario ha molti record, cioè il proprio fatturato (Uno a molti)
Mario ha tre figli: Salvo, Pippo,Sandra (ognuno dei quali hai suoi molti record - i propri fatturati)
Salvo avrà 12 figli
Pippo avrà 3 figli
Sandra avrà 8 figli
...Ogni nuovo record in anagrafica quindi è Padre... ma è anche figlio,nipote, bisnipote di.....MARIO.
Occorre sempre tenere in memoria l'albero genealogico....


Basta una tabella unica
id, nome, indirizzo, telefono, ecc.....
Oltre ai campi classici, come sopra, ci aggiungi un bel id_padre e sei a 
posto puoi tenere nota chi e' figlio di chi
 
 


Si hai ragione. C'ero appena arrivato...anche se dopo complicati  triplici salti mortali !!!!! :-) :-) :-)
grazie!


mi sa di no se non è un refuso "in cui i figli hanno più genitori"
qui siamo di fronte a un grafo, non ad un albero
 
BFS
 

 qualche suggerimento? Uno schema di relazioni tra tabelle?  Vi ringrazio
 
1 - Sviluppa l'intero database in locale con un unico file
    (tabelle, Form, Report, Moduli, etc)
2 - completato il tutto dividi in locale il database in BE (BackEnd)
    con le tabelle e FrontEnd (tutto il resto)
3 - Esegui sul FE il link con le tabelle del BE
4 - Funzionando il tutto porta il BE sul verver in rete e modifica
    i link del FE con le tabelle del BE in rete.
 
Per quanto riguarda i figli con più genitori crea due tabelle: Padri
e Figli collegate Uno(Padri)-a-Molti(figli). Se poi vuoi cercare
i vari Padri di un Figlio lo faria con query, VBA o altro facile
marchingegno.
 
Se Padri e Figli sono invece già incasinati nel server... dovrai
spiegare le modalità del pasticcio.
 
Bruno

Se la relazione è come la descrivi... non è proprio così banale,
 ma la differenza la fa il livello gerarchico che vuoi o devi
 ottenere e di conseguenza la flessibilità.
 
Diciamo che la struttura più flessibile si ottiene con 2 tabelle
 ma non padre-figli che non consentirebbe una profondità oltre ad
 1.
Quindi se la tua profondità è questa può andare.
Se invece un figlio può a sua volta essere padre... allora non va bene.
 
In modo più tecnico per poter assolvere a qualsiasi flessibilità
 gestionale le 2 tabelle sarebbero da strutturare
 cosi:
 
1) Tabella elementi
2) Tabella Relazioni
 
Legate 1-M
 
Chiaramente questo approccio si riflette poi nella gestione
 gerarchica vera e propria... non complessa ma da
 conoscere.
 
-- 
@Alex
 
 
----Android NewsGroup Reader----
https://piaohong.s3-us-west-2.amazonaws.com/usenet/index.html
 


Avete tutti ragione, non è semplice e me ne sono accorto nei giorni a seguire.
La profondità da raggiungere ' Da ME ai miei avi, e da ME ai miei figli.
Anche se ho creato due tabelle: una ME verso Molti Figli e una ME verso Molti padri...
ciò che mi chiedo è come faccio a far comparire in una query
Un mio Record (vendita di un chilo di patate) a i tutti i miei padri: Cioè a ID 50, 42, 36 , 22, 15, 9, 4, 2, 1 .
Questo mio record non è come una semplice tabella prodotti a cui tutti possono attingere, se vogliono.
Dal momento in cui registro la vendita, il record DEVE apparire nella loro lista vendite, come se l'avessero effettua loro. 
Sono piuttosto impantanato. Magare la soluzione è sotto il naso ma non la vedo. 

Il giorno mercoledì 20 gennaio 2021 alle 21:07:01 UTC+1 @Alex ha scritto:

Mi sa che hai ragione.
la mia tabella Vendite ha un IDVendite (elementi)
la mia tabella Padri un Id_Figlio di vendite (relazioni)


Bruno, non ho capito perchè sei partito dal FE e dal BE? 
Il problema ce l'ho a prescindere dalla divisione del DB. :-) 
Oppure mi sfugge qualcosa di ciò che volevi dire


Ciao BF
Non credo sia un Grafo.
Una mia vendita non va a finire ai miei zii
ma solo a mio padre, mio nonno, mio bisnonno. E' un albero. 

Mario Pug used his keyboard to write :

Ho interpretato troppo frettolosamente "non mi è mai capitato di
progettare un Db a rete..." e ho pensato che tu avessi due
problemi: il DB in rete, e l'albero genealogico.
Come non detto.
 
Bruno


Allora, per quanto obbrobriosa, sono arrivato a questa soluzione:
Una Tabella Associa che ha due chiavi esterne: IDVendite, legata alla tabella Vendite
e IDPadri, legata alla tabella Padri
Nella tabella Vendite, la vendita è un solo record, con data, e importo per esempio
Nella Tabella Associata compare quella vendita, per quanti sono i padri.
Solo che...ahimé un solo record di Vendite, nella tab Associata, viene replicato tante volte quanti sono i padri.
Se ho 56 Padri, saranno 56 record ognuno con il suo IDPadre. (in modo da essere visualizzato in automatico da ognuno di essi)
Moltiplicato per i tutto il Network Multilevel.... Saranno davvero tanti record ripetuti. (Record, non campi, i campi al completo saranno nella query)
Se poi si pensa che La tabella Vendite ha una Tabella Figlia coi i dettagli e che tali dettagli devono figurare anch'essi ai padri...
Queste tabelle Associate (una per IDVendita e una per VenditeDettagli).... avranno un infinità di record tutti uguali.
Ma non c'è scampo, mi sa. 
Io Creeeedo di essere arrivato alla soluzione ma se non la vedo non ci credo!
Che ne pensate?
 


-----------------------------------------------------------------
 
Quello che mi spiace davvero, è che in questo sito non si possano cancellare le colossali cazzate che,
in preda alla disperazione uno scrive!!!!
E d'altra parte...la Vs non risposta è eloquente! :-) 


personalmente credo che dovresti spiegare esattamente cosa devi gestire 
sarebbe più facile capire cosa fare e come aiutarti
padri, figli, vendite..non è che si capisca molto
 
BFS
 


No
La 'non risposta' puo' essere dettata dal fatto che si e' sempre di 
corsa, ci sono sempre mille altre cose da fare, e la fequentazione del 
ng e' uno dei piaceri di fine lavoro o del notturno
Quindi non pensare ad una precisa volonta' di sopire la discussione 
semplicemente non partecipandovi
Piuttosto, se vuoi essere aiutato devi cercare di spiegare meglio cosa 
vuoi ottenere, perche' ancor oggi mica s'e' capito cosa vuoi fare ("..in 
cui i figli hanno più genitori.." )
E non perche' si sia curiosi su cosa ci farai col codice ma perche' 
esistono molti casi di 'mattoncini' gia' pronti che rendono inutile 
inventare la ruota ogni volta
Quindi la prima regola e' farsi capire su cosa si desidera ottenere e 
quali informazioni sono a disposizione, solo cosi' si puo' iniziare


Chi si spiega meglio è costretto ad essere un po' più prolisso e me ne scuso.
Però premetto: il mio, non voleva affatto essere una sorta di rimprovero nei confronti degli iscritti al forum! Ce l'avevo con me , per aver scritto un mucchio di cavolate (con la ragione del poi).
Andiamo al dunque:
Un database di un marketing multilevel pone dei problemi che mai mi si erano presentati. 
E cioè: l'utente, compie operazioni (vendite di prodotti) che avranno conseguenze verso l'alto: le provvigioni della sua vendita. 
Per esempio, io che sono ad un livello 1 (basso), faccio una vendita. 
La mia vendita deve apparire in automatico a tutti gli utenti dei livelli superiori (2,3,4...fino a 20 livelli),
affinché le provvigioni della mia vendita siano calcolate, a seconda dei livelli superiori:
3% della vendita al livello 2
5% della vendita al livello 3
10% della vendita al livello 4 e così via....
Di conseguenza il mio ID Utente deve riconoscere tutti gli ID Utenti dei miei (Padri) . 
Immagina un "dio" che crea Adamo ed ed Eva che creano i loro figli che si riprodurranno etc.
Io devo tenere traccia del mio "filo genetico diretto" : Padre, Nonno, bisNonno, TrisNonno....MAI zio, o fratelli  e sorelle del padre.  (Scusate la metafora ma è la migliore per capirsi senza usare un grafico).
Le provvigioni della mia vendita vanno solo ai miei diretti superiori. (In realtà, nel mio caso, da un certo livello in poi, si percepiscono le provvigione di tutti, e questo complicherà le cose. Prima invento una "macchina" e poi dovrò sfasciarle per inseguire altre esigenze). 
 
La necessità di conoscere i padri nasce dal fatto che la mia vendita deve essere visualizzata(con le aliquote diverse), da tutti i miei superiori in Automatico. 
Io Utente di 18° livello, nel mio profilo devo visualizzare le vendite eseguite da tutti i miei figli e nipoti. 
Così il livello 17 , 16, 15 , 14. Ciò, ahimè, comporta una duplicazione della mia vendita per quanti sono i miei padri, per esempio 19 record uguali in cui cambia solo l'IdAnagrafica  in modo che la vendita sia visibile in automatico a tutti i padri identificati. Questa è la parte inelegante del Db, ma non vedo altre soluzioni.   
 
Da un punto di vista strutturale io sono arrivato alle seguenti conclusioni. 
IDAnagrafica è collegato ad un IDCollaboratori (Figli) che hanno così due ID: uno quello di provenienza (idAnagrafica lato Molti) e l'altro il nuovo IDAnagrafica (lato Uno) in quanto potenziali padri dei nuovi collaboratori.
Poi c'è un IDProdotto (attenzione, IDProdotto non è mai uguale, non può essere preso da una tabella prodotti!!! E' personalizzato ogni volta)., e questo complica le cose.
Ora....  Se come dice RobertoA esistono  'mattoncini' gia' pronti che rendono inutile
inventare la ruota ogni volta.... io ascolto!!!
Grazie, spero di essermi spiegato meglio.
 


Abbi pazienza ma ancora non capisco perche' parli che "..il tuo ID 
utente deve riconoscere tutti gli ID utenti dei miei padri.."
 
Se sei al 1 livello (basso), immagino che sarai stato creato da UN SOLO 
PADRE che si trova al 2 livello (un livello superiore), su questo 
attendo conferma, perche' la mia affermazione non rispecchia quello che 
hai scritto tu
 
Se fosse cosi, quindi da un padre potranno dipendere 0-n figli, allora 
per le anagrafiche basta, o meglio io farei, una singola tabella
Che abbia l'ID dell'anagrafica, quindi tuo nome e cognome ed altro, ed 
un campo con ID_PADRE per mantenere la memoria sull'anagrafica dalla 
quale deriva (ed alla quale dovra' riconoscere dei dindini sulle vendite 
o su parte di esse)
 
Per le vendite io terrei le due classiche tabelle VenditeTestate e 
VenditeRighe, nella testata ci metti un riferimento all'ID anagrafica 
del venditore, un riferimento all'anagrafica dell'ID acquirente, una 
manciata di altri dati a caso (data, numero documento, motivo vendita, 
annotazioni, ecc...) e nelle righe ci metti il 'cosa' e' stato venduto e 
le provvigioni previste
 
Per il calcolo provvigioni puoi fare una routine che ricalcoli tutto al 
volo oppure tenerle memorizzate in apposita tabella ed aggiornarla solo 
durante aggiunte/eliminazioni/cambiamenti delle VenditeRighe
 
Se le vendite non riguardano articoli classici ma si tratta di vendite 
'anomale' non e' neanche necessaria una tabella Articoli, ma basta 
scrivere a mano nella descrizione sulle righe della tabella VenditeRighe
 
Questo per imbastire il discorso ed iniziare a lavorare
Poi e' mettendolo in piedi e pasticciando un po' che si evidenziano 
eventuali problemi

RobertoA was thinking very hard :

Cioè psticciando ancora più di quanto s'è già pasticciato?
 
Bruno


Grazie per la risposte. Andiamo per ordine:
IDUtente   Nome          Padre
1                Mario            0
2                Salvatore      1
3                Rosalba        1
4                Sabrina         3
5                Giuseppe      4
6                Cristina         4 
7                Antonio         3
8                Gianfranco   7
Gianfranco deve riconoscere dindi ad Antonio, Rosalba e Mario.
Non a Cristina, Giuseppe, Sabrina e Salvatore
 

Questo significa che Gianfranco, Livello 1, deve tenere traccia dei propri padri.

 
 
IL padre di Gianfranco, e' l'ID 7 e quindi Antonio
Non ce ne sono altri di padri
 
Se ogni anagrafica (eccetto la prima) contiene informazioni anche sul 
proprio padre, e' chiaro che di una qualsiasi anagrafica potrai risalire 
al padre, poi al nonno, poi al bisnonno e cosi' via
E quindi accreditare loro gli importi che riterrai opportuno
 


Alla fin fine, è quello che ho fatto. Solo che tu dici che occorre avere riferimento solo al padre, mentre poi di fatto, come tu stesso scrivi, si devono ricercare  nonni e bisnonni! Dietro quel "potrai risalire" c'è infatti una routine. Poiché mentre in due classiche tabelle Uno-Molti, è l'UNO che registra i Molti, per cui la dipendenza è logica e diretta, in questo caso sono i Molti che si registrano e devono conoscere (prima o poi) da dove arrivano, e vuoi o non vuoi occorre una Routine; che ho fatto e che sto rodando.
Anche per quanto riguarda il resto del Db, ho impostato le cose classicamente, come tu descrivi. Cioè la parte Molti "Vendite testata" si riferisce alla parte Uno "Anagrafica". 
Il mio dubbio, (quando parlo di ineleganza) nasce quando la vendita di Pippo (Livello 1) deve essere visualizzata sul profilo o account o form.... (chiamiamola come ci pare), insomma deve comparire nelle liste vendita di Pluto (livello2), Topolino (livello 3), Minnie (livello 4)... 
ciò significa che questa RIGA della tabella Vendite deve avere lo stesso IdMolti, non solo del Padre, (quello ce l'ha già) ma di tutti gli IDAnagrafica dei padri precedenti. 
Significa cioè creare una Copia della riga con questi id-figli. Se non chiariamo questo punto non ne usciamo :-) 
Anche qui occorre un lavoro di routine "copia e incollla", ma in ogni caso si tratta di copie di righe da legare ai dovuti IDAnagrafica. 
Mi segui o ti sembra che stia delirando? 
 
grazie per la lettura. 
 


a mio parere questa tabella va bene
immagino avrai poi una query vendite
con
 
 
IDVendita, IDUtente, TotaleVendita
 
ricavata da testate e righe vendite
 
a questo punto devi usare la ricorsione per calcolare a "ritroso" tutte 
le vendite
 
vedi qui:
https://it.wikipedia.org/wiki/Algoritmo_ricorsivo
 
 
qualcosa tipo
 
sub calcolaVendite (ID integer)
	scansiono le vendite di tutti i figli	
	totVendite=TotVendite+venditacorrente			
	per ogni id figlio
        	calcolaVendite (IDfiglio)   <--ecco la ricorsione
	finche id corrente ha un figlio <- condizione di uscita
 
end sub
 
non è una banalità ma non vedo alternative
qui la trovi spiegata per bene con esempi semplici
http://pages.di.unipi.it/corradini/Didattica/LIP-07/Metodi/Ricorsione/main.html
 
 
ciao
BFS
 


https://www.youtube.com/watch?app=desktop&v=jYQWVnKEFRk
 

 qualche suggerimento? Uno schema di relazioni tra tabelle?  Vi ringrazio
 
È simile a questo il risultato che vorresti ottenere?
 
https://1drv.ms/u/s!AvTaMfd5-b2o1DKujFVVCvQBPPdW?e=HuD0am
 
 
Bruno


Mi diletto a occuparmi di Database ma non capisco nemmeno come funziona 'sto sito: una volta c'erano le funzioni "Quote" o "Cit"... insomma la possibilità di rispondere riferendosi ad un determinato post?.... Ora si risponde a tutti e basta?
Cmq... CIT - Bruno Campanini: No, non credo che sia ciò che mi serve. Leggo tipi di Elettrodomestici e campi con le varie opzioni. A meno che mi sia sfuggita qualcosa, non fa al caso  mio.   
 
CIT - FBS: Non ho studiato informatica (semmai mi sono rivolto ad Excel e poi ad Access per sopperire alla mia mancanza di "flessibilità mentale verso la matematica" :-) ) Tuttavia mi pare d'aver capito che un Algoritmo Ricorsivo è una modalità per affrontare i calcoli: partendo da un algoritmo semplice poi via via si integrano i vari risultati fino al raggiungimento del calcolo più complesso.  Solo  che io non ho problemi ad elaborare i seppur complicati calcoli relativi alle righe vendite. Il mio problema sono le righe vendite. Le quali, (e mi spiace ripetermi), non sono figlie di un solo padre. Pertanto dovranno essere duplicate per mezzo di una routine , tante volte quanti sono i padri. In modo che ogni riga diventi "sua figlia".  Esempio:
idpadriMolti ____VenditaProdotto____IMPORTO
1_______________vendita1____________100 euro
4_______________vendita1____________100 euro
18______________vendita1____________100 euro
20______________vendita1____________100 euro
I campi sono tutti uguali tranne l'IDFiglio
in modo da essere visualizzato da tutti i padri.
Solo questo "mi infastidisce" da un punto di vista dalla "eleganza".
FBS, può darsi sia io che non abbia capito cosa volevi dire....
 

Mario Pug explained on 01-02-21 :


> darsi sia io che non abbia capito cosa volevi dire....
 
Nessuno si è mai lamentato come tu fai del comportamento del NG il 
quale
è unicamente congruente con le spiegazioni che finora hai dato.
Invece di lamentarti soltanto, perché non compili un piccolissimo
esempio concreto...
L'avrebbere compreso tutti e in molti l'avrebbereo già risolto. te
lo garantisco!
 
"
Il mio problema sono le righe vendite. Le quali,
(e mi spiace ripetermi), non sono figlie di un solo padre.
"
 
Ormai hai scritto tanto quanto la metà dei Promessi Sposi e non ha
capito un c... nessuno, e tutti si sono datim alla fuga.
 
Mi ripeto: scrivi un dettagliato esempino della circostanza
che vuoi documentare/calcolare e vedrai che la soluzione te la
trovano in tanti.
 
Bruno


Bruno, non capisco davvero da dove viene questa sorta di disappunto.
Io non mi sono MAI lamentato del comportamento di chi frequenta questo Forum che, a spizzichi e bocconi, frequento da più di 20 anni!!! Stamattina ho solo fatto qualche battuta sulle FUNZIONI del sito, non sul comportamento degli utenti!   
Entrando nel merito: gli esempi, per quanto riguarda i miei dubbi , li ho fatti , li ho spiegati fino a stamattina. Se mi spiego pessimamente devo avere un problema alla base! Mi Spiace, ma non c'è volontà nel mio spiegarmi male! 
Andiamo al tuo "albero". Quelli da te indicati sono CAMPI in cui i valori sono Padri,figli, nipoti. I miei sono Record, non campi. Assurdo aggiungere Campi per i figli che verranno. Devono essere Record.  Attualmente sono Record di un solo Padre , ma devono essere visualizzati da più persone (nell'albero) come da schema fatto stamattina. 

It happens that Mario Pug formulated :

Morale della favola, tu un esempio non vuoi o non sei in grado
di farlo a da quel che dici non ha capito niente nessuno.
Infatti nessuno ha preso carta e matita e messo giù
qualche traccia di codice, solo chiacchiere.
 
Bruno


Non ho mai detto quanto affermi e lo sai. 

Ripropongo la mia osservazione iniziale, solo a titolo di ragionamento, non mi addentro minimamente nel tuo caso specifico... su cui ragionerai tu se riterrai che l'esposizione sotto possa avere affinità con la tua situazione.
 
Se vogliamo affrontare la questione della gestione Gerarchica, serve individuare bene da subito l'esigenza.
Ci sono 2 linee da considerare che si scelgono in base alla profondità richiesta o necessaria.
1) Profondità 1, ovvero 1 Prodotto può avere solo 1 Padre, questo è banale e si ottempera con una Relazione 1-M, ma se questa è l'esigenza l'argomento è già chiuso in quanto banale e non starei nemmeno a considerarlo.
 
2) Profondità (n) ovvero non definita e volutamente non definibile, quindi da 1÷n, in questo caso ci sarebbero 2 sottoelementi da considerare, ma io preferisco usare sempre quello più flessibile.
Qui parliamo di vera gestione gerarchica ad albero, in cui ogni elemento può avere più figli ma anche che ogni elemento può avere più padri.
In questo caso per la gestione si usano 2 Tabelle fisiche, ma, nella realtà una Tabella viene usata in SELF_REFERENCE... in modo da consentire la gestione ricorsiva a livelli non definiti.
 
Faccio un esempio culinario, che risulta banale solo per chi non capisce di cosa si parla...
Se vogliamo gestire delle ricette di cucina, dobbiamo comprendere che servono 3 Elementi concettuali:
1)	Prodotto: Materie Prime(queste per definizione non avranno mai figli, ma solo padri, ed in questa osservazione sta il concetto di TIPO)
Prezzemolo, Mele, Farina, Acqua ecc...
2)	Prodotto: Materie Semilavorate (queste per definizione possono avere sia figli, che padri)
Crema Zabaione, Pasta Frolla, Budino... (queste materie essendo a loro volta costituite da ricette, avranno N figli ma magari uno di essi è a sua volta un Semilavorato)
3)	Prodotto: Materia Finale (queste per definizione hanno SOLO figli e nessun genitore)
Torta di Mele (sarà fatta da Pasta Frolla, il semilavorato di prima e... Mele ecc...)
 
Per realizzare questa struttura(semplifico per la comprensione):
tblProdotti
IdProdotto
Tipo (1=Finito;2=Semilavorato;3=Primo)
Nome
Prezzo
 
tblRicetta(questa è la tabella che costituisce i rapporti gerarchici, in questo caso culinario è la Ricetta)
IdProdotto
IdParent
Qtà
UM
 
Nella rappresentazione ER si disegneranno le tabelle in questo modo:
tblProdotti(1)<--->(m)tblRicetta(m)<--->(1) tblProdotti_1
 
Quella che ho indicato come [tblProdotti_1] è appunto l'utilizzo in SELF_REFERENCE della Tabella prodotti, e consente che ogni elemento possa essere flessibilmente gerarchico.
 
La distinzione che ho fatto inizialmente, sui 3 tipi è fondamentale quando si realizza l’interfaccia grafica, in quanto si dovrà consentire di selezionare come Ingredienti della Ricetta solo Prodotti con Tipo>1
 
Ovviamente questo ragionamento banalizzato sulle ricette è solo per facilitarne la comprensione, ma è applicabile a qualsiasi gestione gerarchica Multilivello, produzione di componentistica elettrica/meccanica per la realizzazione di prodotti finiti o parziali.
 
La difficoltà sta poi nella gestione dell’interfaccia grafica, che va da se che trova la massima chiarezza nell’utilizzo del TreeView in linea concettuale, ma in realtà è solo una questione di organizzazione.
 
Ci sono poi 2 aspetti da non sottovalutare:
1)	Ricavare la 
DI.BA
 del prodotto, e di conseguenza il costo complessivo splittato per singolo ITEM con totali parziali e totali generali dello stesso.
2)	Stampare l’esploso della 
DI.BA
, i REPORT
 
Per il primo serve appunto come ti ha indicato anche BSF, usando come DB JET creare una funzione ricorsiva in VBA che partendo dall’Articolo scala la profondità gerarchica e calcola il costo... la funzione da scrivere è banale in se ma non così tanto, diciamo che non è a prova di stupido, e se sei abituato a non dichiarare le Variabili usate e la profondità aumenta, il sistema va in Overflow sicuramente...
 
Ci sono invece RDBMS che supportano funzioni SQL ricorsive... ed in questo caso la gestione cambia dovendo delegare il Server, e sicuramente cambiano, in meglio, anche le prestazioni.
 
Quì trovi qualche indicazione:
https://it.qaz.wiki/wiki/Hierarchical_and_recursive_queries_in_SQL
 
 
Per il secondo punto invece serve conoscere bene la gestione dei Report.
Mentre per gerarchie ad 1 Livello, ripeto è banale e si gestisce con un Raggruppamento, quando NON si conosce a priori la profondità della Gerarchia, o meglio quando non si è posto un LIMITE stretto alla gerarchia, perché non si sa a prescindere il livello di profondità da rappresentare... questo modo ri gestire l'ambiente non funziona.
In questo caso serve ribaltare i concetti e slegarsi dalla Gerarchia, sfruttando una Tabella dedicata, che consente di SERIALIZZARE i dati da gerarchici a sequenziali come fosse una tabella di Excel, includendo il Livello di profondità gerarchica ed i dati necessari ai ricalcoli.
Il report pertanto diventa semplice da gestire come un banale report MONOLIVELLO, in cui eventualmente si può gestire l’aspetto grafico dell’indentazione sapendo il LIVELLO ed usando Caratteri a spaziatura fissa.
 
 
Saluti
@Alex