Newsgroup: it.comp.appl.access
Titolo: Raggupamento nei report

Salve, non riesco a risolvere un problema coi report. Ho la necessità di
raggruppare i risultati di un report chiamato 'Estratto conto' secondo il
soggetto. I soggetti interessati sono più di uno: clienti, agenti, scuole e
fornitori. Ciascuno di essi è identificato da un codice e un tipo. Il codice
è di tipo contatore mentre il tipo va da 1 a 4 (essendo 4 i tipi di
soggetti). La chiave è a due campi (codice + tipo), poichè essendo il codice
di tipo contatore posso avere lo stesso codice per una categoria differente,
quindi abbinato al tipo posso identificare univocamente un soggetto
interessato all'estratto conto. Quando scelgo il campo di raggruppamento nel
report posso indicare un solo campo (e non i 2 campi che costituiscono la
chiave) quindi ciò che ovviamente accade è che un soggetto di tipo 1 (es.
scuola) con codice 25 e un'altro di tipo 2 (es. agente) avente lo stesso
codice 25, me li ritrovo insieme. Inoltre vorrei ordinare secondo il campo
'ragione sociale' (presente nello stesso gruppo in cui vi sono codice e
tipo), che è l'unico che viene visualizzato all' utente. Purtroppo la
maschera di Ordinamento Raggruppamento non solo mi costringe ad usare un
solo campo ma mi obbliga anche a scegliere quello come campo secondo cui
ordinare!
Grazia

 Grazia
Nella finestra "ordinamento e raggruppamento" del report selezionerai:
- nella prima riga: 'tipo' (ordinamento crescente)
- nella seconda riga: 'ragione sociale' (ordinamento crescente)
Poi ti dovrai giostrare un poco con le intestazioni/interruzioni/eccetera,
ma il più è fatto.
Ciao,
--
Alberto


Ci avevo provato a fare qualcosa del genere, ma il risultato non è proprio
quello atteso. Infatti così mi mette prima tutti gli Agenti (tipo 1)
ordinati in modo crescente secondo la ragione sociale, poi passa ai Clienti
(tipo 2) etc...A me servono tutti insieme ordinati secondo la ragione
sociale. Ti faccio un esempio:
Quello che fa è
Agente
Abbracciavento    altri campi
Arnesano             altri campi...
Cardone               altri campi
Colella                  altri campi
Cliente
Acquaviva            altri campi.....
Carulli                  altri campi.....
Cirulli                   altri campi.....
Quello che mi serve è invece:
Agente   Abbracciavento
Cliente   Acquaviva
Agente   Arnesano
Agente   Cardone
Cliente   Carulli
Cliente   Cirulli
Agente   Colella
E' banale come richiesta ma non ho trovato nulla in proposito. Spero tu
possa aiutarmi ancora.
Grazia

 ha scritto nel messaggio
news:FDNN7.209689$sq5.10...@news.infostrada.it...

Ma allora è ancora più semplice:
In "ordinamento e raggruppamento" imposti solo la prima riga ('ragione
sociale' - 'crescente')
Nel 'corpo' del report metterai
- prima una casella di testo associata al campo 'tipo'
- poi una casella di testo associata al campo 'ragione sociale'
e il gioco dovrebbe essere fatto.
Oppure c'è ancora qualcos'altro che mi sfugge?
Ciao
--
Alberto


Magari fosse cosě semplice. Cosě come avevo specificato nella richiesta
iniziale, il campo 'ragione sociale' della tabella estratto conto non č
chiave. La chiave č data da 'tipo soggetto' + 'codice'. Di conseguenza se un
cliente ha lo stesso cognome di un  un agente, ecco che mi ritrovo le
fatture di quell'agente e di quel cliente mescolate e riferite ad uno dei
due, che si ritroverebbe nel suo estratto conto anche le fatture dell'altro!
L'unica soluzione č raggruppare secondo i due campi chiave. Ma non finisce
qui. Ammesso di riuscirci, come faccio ad ottenere l'ordinamento secondo il
campo ragione sociale, che dovrebbe comparire nello stesso gruppo in cui vi
sono codice e tipo? In parole povere nell'intestazione di gruppo ci
dovrebbero esssere i tre campi, il raggruppamento deve essere fatto secondo
due di essi e l'ordinamento secondo l'altro. Secondo te č Access che non mi
consente di fare questo, e quindi meglio non pensarci piů, oppure il modo
c'č ma io lo ignoro? Se i principi di progettazione di un database prevedono
l'esistenza di chiavi a piů campi evidentemente a livello semantico questi
campi dovrebbero essere visti come  concetti che all'occorrenza devono
viaggiare insieme. Mi chiedo a questo punto perchč l'interfaccia dovrebbe
obbligarmi a separare questi concetti. Scusa la filosofia.
Spero tu mi risponda ancora.
Ciao
Grazia

 ha scritto nel messaggio
news:cNuN7.203315$sq5.9...@news.infostrada.it...

La risposta del report mi sembra coerente.
Per fare cio che vuoi dovresti impostare un criterio di dipendenza tra
agente e clienti.
Normalmente Agenti e Clienti dovrebbero andare in due tabelle diverse da
legare con una realzione uno a molti, tuttavia si può ovviare creando nella
tabella comune un campo dove indichi che un cliente e "figlio" di un
determinato agente, es. specificando il suo codice di agente.
--
                     Angelo
------------------------------------------------------
Sito comune di it.comp.appl.access
http://www.sitocomune.com
------------------------------------------------------

 ha scritto nel messaggio
news:cNuN7.203315$sq5.9...@news.infostrada.it...

Scusa leggendo meglio ho capito che non esiste un legame di dipendenza e
quindi è ancora più facile.
Ordina prima per ragione sociale e poi per soggetto, nell'intestazione
soggetto riporta soggetto e ragione sociale, e nel corpo gli altri
controlli.
I report sono molto elastici e non necessariamente seguono l'ordinamento
delle chiavi.


 ha scritto nel messaggio
news:Qr5O7.216148$sq5.10...@news.infostrada.it...

Cosě, a spanne, direi che č senz'altro possibile. Devo perň ragionarci con
calma e, credo, farmi dare alcuni chiarimenti: domani sera o lunedě. Giusto
anche quello che dice Angelo riguardo la possibilitŕ di effettuare
l'ordinamento anche in base a campi 'non chiave'.
Ci sentiamo,
Ciao
--
Alberto

 wrote in message
Z19O7.218009$sq5.10...@news.infostrada.it...

Forse l'ultima mail spiega in modo più chiaro la situazione: agenti,
clienti, scuole e fornitori sono tutte tabelle diverse aventi il codice
(contatore) come chiave (il tipo soggetto non è un campo di queste tabelle).
La tabella estratto conto ha invece come chiave codice+ tipo soggetto per
distinguere le varie tabelle. Il soggetto in realtà non esiste come come
campo, parlo di soggetto quando voglio riferirmi ad una qualunque delle
quattro categorie, identificate appunto da codice + tipo soggetto. Sarebbe
stato un disastro creare 4 tabelle di estratto conto, una per ogni tipo
soggetto. Lo dico per la manutenzione, se un domani nasce una nuova
categoria di soggetti sarebbe necessario progettare due nuove tabelle:
vorrei mantenere la gestione dai dati separata dal frond-end. Come ho già
detto non essendo la ragione sociale chiave se ho soggetti di diverse
categorie ( ma può succedere anche nella stessa categoria)  con la stessa
ragione sociale, mi ritroverei la fatture dei due mescolate. Quindi la
soluzione logicamente sembra semplice, basterebbe che l'intefaccia mi
consentisse di rispettare la logica del database con campi chiave a due
campi, che quindi dovrebbero essere raggruppati insieme  allo stesso
livello. Per la questione invece dell'ordinamento in base al campo ragione
sociale (diverso quindi dai campi di raggruppamento) non ho idee.
Ciao
Grazia

 ha scritto nel messaggio
news:TiJO7.228707$sq5.11...@news.infostrada.it...

Forse ho capito!
Il report funziona in quel modo perchè va a "pescare" le combinazioni
codice+tipo soggetto che trova nella tab estratto conto, e non c'è verso di
farlo funzionare diversamente se non ricorrendo ad una serie di query
"viziose".
La soluzione che adotterei, (e che adotto) è la seguente:
a) una sola tabella con chiave idnome di tipo contatore per tutti i tuoi
nominativi, con un campo idcategoria; oppure con chiave complessa se un
nominativo può appartenere a diverse categorie;
b) una tabella categorie con campo idcategoria indicizzato con le quattro o
enne categorie legato con una relazione uno a molti alla tabella dei
nominativi;
c) una tabella fatture con chiave complessa tipo: idnome, numfattura; legata
con relazione molti a uno con la tabella dei nominativi.
Ora la struttura è "normale" e la puoi ricombinare con query, form e report
per fare tutto quello che vuoi.


 ha scritto nel messaggio
news:Qr5O7.216148$sq5.10...@news.infostrada.it...

Ciao,
ho letto anche quello che hai scritto ad Angelo e ci capisco qualcosa in piů
(ma qualcosa continua a non essermi chiaro). Ti dico cosa ho capito e tu
dimmi dove sbaglio:
Hai 4 tabelle dalla struttura uguale, ognuna dedicata ad un 'tipo' di
soggetto.
Hai una tabella 'estratto conto' in cui immetti le fatture; tramite il campo
'tipo' e il campo 'contatore' identifichi il soggetto cui ogni singola
fattura si riferisce.
Vuoi elencare le fatture, suddivise per soggetto, ordinando i soggetti in
ordine alfabetico e ovviamente tenendo separati eventuali omonimi (presenti
in tabelle diverse).
- Dove sbaglio?
- Se nella tabella 'estratto conto' gli unici riferimenti al 'soggetto' sono
'tipo' e 'contatore', come hai risolto il problema del collegamento alle
tabelle degli anagrafici per ottenere la ragione sociale? Hai fatto una
query di unione? In che modo?
A mio avviso il problema non č di difficile soluzione, perň prima bisogna
avere il quadro completo.
Fammi (facci) sapere.
Ciao
--
Alberto


Modificare la struttura del database ora che ci sono circa 5000 fatture
inserite non mi sembra possibile (in pratica mi era stato chiesto di
aggiungere un "piccolo" report). Vorrei comunque capire
meglio il tuo suggerimento. Se ho ben capito un unica tabella di soggetti,
in modo da avere un codice univoco per ogni soggetto qualunque sia la sua
categoria. E' un tipo di organizzazione che effettivamente semplifica di
molto la gestione, anche se non è esente da inconvenienti: le 4 tabelle
(agenti, clienti...) hanno dei campi comuni e dei campi propri, tipo il nome
del direttore nelle scuole che darebbe luogo a valori nulli nelle altre
categorie; un processo di ristrutturazione del database suggerirebbe un
partizionamento orizzontale della tabella unica nelle 4 tabelle, in quanto
gli accessi spesso riguardano un sottoinsieme dei record (posso fare delle
query che interessano ad esempio solo i clienti); infine questa grande
tabella conterrebbe troppi record e rallenterebbe gli accessi.
Non ho invece ben capito perchè la tabella fatture dovrebbe avere chiave a
due campi: il numero fattura parte da 1 il primo giorno dell'anno, non fa
distinzioni di categoria e riparte da uno il 1° Gennaio di ogni anno, quindi
non è un buon candidato per la chiave, meglio un semplice contatore visto
che ogni fattura ha vita a se stante. O mi sfugge qualcosa? Come giustamente
pensi con una struttura del genere l'ordinamento nel report non avrebbe più
bisogno del raggruppamento su due campi, basterebbe il campo codice che ora
è univoco. Comunque così dovrebbe effettivamente funzionare: ordino per
ragione sociale, primo gruppo, e poi codice, secondo gruppo così se trova
due nomi uguali li separa in base alla seconda chiave 'codice'.
Pensi che sia possibile modificare senza far danni la struttura del database
con i dati già inseriti?
Un'altra soluzione che mantiene la struttura originaria ci sarebbe, anche se
non dà garanzie al 100% ( ma penso almeno al 99%). Se mi sentisse il mio
professore... Potrei comunque ordinare per ragione sociale e poi codice,
anche se il codice questa volta non è univoco. Ma quante probabilità ci sono
che due soggetti abbiano lo stesso nome ad anche lo stesso codice? (per
avere lo stesso codice devono appartenere a due categorie diverse) Penso
molto basse. Se poi invece di usare un campo cognome e un campo nome uso un
unico campo CognomeNome le probabilità si abbassano ulteriormente.
Un'altra soluzione sarebbe quella di dire al mio cliente che l'ordinamento
per nome non si può avere! :-)))
Ciao
Grazia

Ciao, leggendo proprio ora la risposta di Alberto, mi è venuto il dubbio di
non essere stata abbastanza chiara circa la tabella estratto conto. Questa
tabella e distinta da quella in cui vengono memorizzate le fatture che si
chiama 'scarico'. E' qui che uso un semplice contatore come chiave. La
tabella estratto conto ha chiave codice +tipo secondo la mia struttura,
secondo la struttura che mi hai suggerito dovrebbe invece avere un' unica
chiave contatore perchè qui sarebbe univoco. Leggi  la risposta che
ho dato ad Alberto, circa la costruzione della tabella estratto conto.
Ho inoltre testato con un prototipo la struttura che mi proponi, sperando di
averla capita.
 Se ordino per ragione sociale e poi per codice univoco ho lo stesso
risultato che avrei con la mia struttura ordinando per ragione sociale, tipo
e codice:
Gli omonimi vengono raggruppati in un'unica intestazione e, all'interno di
questa, suddivisi in base al diverso codice. Nella mia struttura sono invece
divisi prima per tipo e poi per codice. Quindi se due agenti e un cliente
hanno lo stesso nome avrei come risultato:
    ROSSI
            CLIENTE                /* tipo 1
                    CODICE 20
                            tutte le sue fatture
            CLIENTE
                    CODICE  56
                            tutte le sue fatture
            AGENTE              /* tipo2
                    CODICE 15        /* questo agente potrebbe anche avere
codice 20 o 56
                                                /* in tal caso comunque
resterebbe distinto dal cliente
                            tutte le sue fatture
Con la tua struttura avrei
        ROSSI
            CODICE 15
                    tutte le fatture
            CODICE 20
                    tutte le fatture
            CODICE 56
                    tutte le fatture
 anche se i codici non sarebbero gli stessi.
Quindi il problema non è secondo me risolvibile, nasce da un vizio di
Access: l'impossibilità di raggruppare secondo un campo chiave ( magari 2) e
ordinare secondo un altro all'interno dello stesso gruppo.
Io mi sto arrendendo....
Grazia

 query di unione? In che modo?
La costruzione di questa tabella non č tanto semplice, ci provo.
Ho due query una relativa allo scarico l'altra al reso dove seleziono quali
fatture  e note credito vanno in estratto conto (es quelle non ancora
pagate). Sull'evento Open del report creo la tabella di estratto conto (che
viene distrutta all'evento Close), le due query rappresentano i recordset
che uso nella procedura,  č una specie di query di  unione ma fatta da
codice. Il campo ragione sociale riesco ad inserirlo nella tabella estratto
conto mediante 4 cicli if :
se il tipo del soggetto č 1 allora vado aprire un recordset sulla tabella
clienti da cui recupero il nome, e cosě per gli altri.
Comunque credo di dovermi accontentare della soluzione in cui ordino prima
per rag. sociale, poi per tipo e infine per codice.
L'ordinamento riesco averlo, solo che se ho due librerie Pentagono una a
Bari e l'altra a Lecce, vengono messe nella stessa intestazione. Riesco a
distinguere le fatture dell'una da quelle dell'altra perchč le raggruppa in
base al codice. Il problema non si pone se invece di scegliere la stampa di
tutti gli estratti conto, scelgo la stampa per soggetto in cui filtro con
rag. sociale codice e tipo.
Leggi comunque la mia risposta ad Angelo.
Ciao
Grazia


Ciao.


 ha scritto nel messaggio
news:t13P7.235209$sq5.11...@news.infostrada.it...

... ffiuuuhh! (scusa): hai un sistema di dati veramente "interessante" ....
Guarda che comunque anche a mio avviso la soluzione di Angelo č la piů
logica e la piů produttiva...
Comunque, cerchiamo di tornare al punto:
Tu generi una tabella temporanea in cui si trovano tutti gli elementi utili
per la tua stampa, tra i quali questi campi:
- codice (univoco nell'ambito di una stessa tabella 'di origine')
- tipo di soggetto
- ragione sociale
- tutti gli altri elementi di ogni singola fattura o nota di accredito
(una riga per ogni documento).
Se č cosě (altrimenti dě come č), non č possibile impostare l'"ordinamento e
raggruppamento" a:
    ragione sociale - crescente
    tipo - crescente
    codice - crescente
nell'intestazione 'codice' metterai tre caselle di testo (tipo - ragione
sociale - - codice --- magari anche l'indirizzo)
nel corpo le relative fatture/note di credito
??
Ciao
Alberto

 per rag. sociale, poi per tipo e infine per codice.
Mai accontentarsi di qualcosa che non convince.
Per normalizzare ancora i tuoi dati ti consiglio di lavorare con un'unica
tabella fatture dove inserirai gli estremi delle fatture (valori positivi) e
delle note di credito (valori negativi).
La tabella estratto conto è superflua perche' puoi ottenerla tramite una
query che interroga la tabella fatture.
Alla fine vedrai che se lavori su una base dati ben progettata costruirci su
tutti gli altri oggetti: query, forms e reports sarà facile e veloce,
viceversa anche un banalissimo report ti farà soffrire.
Spero che anche Alberto sia d'accordo.
       Ciao, Angelo

 ha scritto nel messaggio
news:rmbP7.240110$sq5.11...@news.infostrada.it...

Ciao Angelo,
assolutamente d'accordo: tre tabelle (movimenti, anagrafica, tiposoggetto).
Purtroppo, come anche tu saprai benissimo, certe volte ci si trova - anche
non per colpa propria - con dati organizzati in modo "originale" e però
bisogna ottenere lo stesso subito alcuni risultati. Io stavo cercando di
capire se - provvisoriamente - poteva essere ipotizzabile alimentare il
report con due query di unione, una per fatture+accrediti e l'altra per gli
anagrafici, generando in entrambe un "supercodice" (tipo+id) tramite il
quale relazionarle.
Successivamente mi è parso però di capire che una origine dati "sufficiente
per le sue esigenze" Grazia la ha già predisposta; quindi sentiamo cosa dice
lei ora.
Magari hai qualche altro suggerimento da aggiungere?
Ciao
--
Alberto

"The-real-Isaac" <sartori.rossi.nospam@tin> ha scritto nel messaggio
news:uswP7.2632$Sq4....@news1.tin.it...

....forse ho suggerito anche troppo
Ciao, angelo

[CUT]

Vabbè, allora vediamo se Grazia ci fa sapere a che punto è...
ciao
--
Alberto