Newsgroup: it.comp.appl.access
Titolo: report moltiplica i record aiuto!

ragazzi buonasera, ho un grosso problema. nel report mi si ripetono i record, non ho controllato quante volte mi ripete lo stesso record ma ho ottenuto 4000 pagine circa da 200 record!! cosa può essere?

 ragazzi buonasera, ho un grosso problema. nel report mi si ripetono i record, non ho controllato quante volte mi ripete lo stesso record ma ho ottenuto 4000 pagine circa da 200 record!! cosa può essere?
 
Query sbagliata.
 
Apri la query e vedi cosa ottieni
 
Ciao

Probabilmente il report viene popolato da una query. E altrettanto probabilmente la relazione che lega le tabelle della query è sbagliata (oppure non sono relazionate). 
Verifica cosa fa la query. 
OC

ecco il codice sql:
 
SELECT CONTA.CODICE_FISCALE, DIPENDENTE.COGNOME, DIPENDENTE.NOME, CONTA.TIPO_COMPENSO, COMPENSO.DESCRIZIONE, CONTA.IMPONIBILE_PREV, CONTA.CONTRIB_DIP, CONTA.CONTRIB_AMM, CONTA.IMPONIBILE_FC, CONTA.RITENUTE_FC, CONTA.IMPONIBILE_IRPEF_AC, CONTA.IRPEF_AC, CONTA.IMPONIBILE_IRAP, CONTA.RITENUTE_IRAP FROM COMPENSO INNER JOIN (DIPENDENTE INNER JOIN CONTA ON DIPENDENTE.CODICE_FISCALE = CONTA.CODICE_FISCALE) ON COMPENSO.TIPO_COMPENSO = CONTA.TIPO_COMPENSO;
 
adesso vi spiego.. come potete vedere, praticamente quasi tutti i campi provengono dalla tabella CONTA. i campi NOME e COGNOME provengono dalla tabella DIPENDENTE che è collegata alla tabella CONTA tramite il campo CODICE_FISCALE. quindi forse l'inner join che mi ha fatto automaticamente access è sbagliato? mentre per quanto riguarda il campo DESCRIZIONE, quello è preso dalla tabella COMPENSO che ha un campo TIPO_COMPENSO presente anche nella tabella CONTA. questo è tutto, forse access mi ha scritto il codice sql sbagliato e quindi per questo mi si duplicano i record con le stesse info?

 SELECT CONTA.CODICE_FISCALE, DIPENDENTE.COGNOME, DIPENDENTE.NOME, CONTA.TIPO_COMPENSO, COMPENSO.DESCRIZIONE, CONTA.IMPONIBILE_PREV, CONTA.CONTRIB_DIP, CONTA.CONTRIB_AMM, CONTA.IMPONIBILE_FC, CONTA.RITENUTE_FC, CONTA.IMPONIBILE_IRPEF_AC, CONTA.IRPEF_AC, CONTA.IMPONIBILE_IRAP, CONTA.RITENUTE_IRAP FROM COMPENSO INNER JOIN (DIPENDENTE INNER JOIN CONTA ON DIPENDENTE.CODICE_FISCALE = CONTA.CODICE_FISCALE) ON COMPENSO.TIPO_COMPENSO = CONTA.TIPO_COMPENSO;
CUT
 forse access mi ha scritto il codice sql sbagliato e quindi per questo mi si duplicano i record con le stesse info?
 
Access scrive il codice in base ai collegamenti che costruisci graficamente nella visualizzazione struttura della query.
 
Oltretutto puoi ben vedere, nella query che posti, che gli INNER JOIN sono quelli che descrivi.
 
Ti avevo fatto una domanda, hai aperto la query e verificato il risultato?
 
Ciao


si ho copiato il codice della query creata dal report e incollata in una nuova query. il risultato è lo stesso, cioè i record, non tutti si ripetono per circa 31 volte

 si ho copiato il codice della query creata dal report e incollata in una nuova query. il risultato è lo stesso, cioè i record, non tutti si ripetono per circa 31 volte
 
nella tabella CONTA ci sono altri campi (forse date o luoghi delle registrazioni) per cui con quelli che estrai nella query succede che il binomio CODICE_FISCALE + TIPO_COMPENSO è GIA' ripetuto n volte ?

 nella tabella CONTA ci sono altri campi (forse date o luoghi delle registrazioni) per cui con quelli che estrai nella query succede che il binomio CODICE_FISCALE + TIPO_COMPENSO è GIA' ripetuto n volte ?
 
nella tabella CONTA ci sono 284 record. per ogni CODICE_FISCALE ci sono circa due o tre TIPO_COMPENSO

 si ho copiato il codice della query creata dal report e incollata in una nuova query. il risultato è lo stesso, cioè i record, non tutti si ripetono per circa 31 volte
 
... ho copiato il codice della query creata dal report  ...
 
dando questa indicazione appare (chi legge è portato a ritenere) che NON sia tu quello che ha approntato il report, e che quindi NON sia mai stato visto cosa generava quella query prima di ritenerla valida come origine di un report.
 
Se invece la query è stata già riscontrata valida c'è il sospetto del "crac" (almeno del report): quindi copiare su nuovo db tutti gli oggetti necessari a riformare il report e incrociare le dita (prima e dopo la copia)
 


Hai controllato le tabelle?
fai così, apri le singole tabelle e filtra il codice fiscale nelle tabelle che colleghi col codice fiscale e fai lo stesso con la tabella che contiene il tipocompenso
 
Ciao


la query non è valida


Provato con SELECT DISTINCT ecc... eccc...?
 


no , non ho provato perchè non sono un esperto anzi nemmeno un principiante. se puoi farmi questo favore puoi riscrivermi la query utilizzando select distinct?

Il giorno martedì 28 novembre 2017 08:36:33 UTC+1, mantro ha scritto:

ho semplicemente aggiunto distinct dopo select e tutto si è risolto. ti ringrazio davvero mi hai salvato

 nella tabella CONTA ci sono 284 record. per ogni CODICE_FISCALE ci sono circa due o tre TIPO_COMPENSO
dovresti ottenere dai 568 agli 852 record (ammesso che nella tabella DIPENDENTE siano presenti solo record con codice fiscale univoco).
Rimane da capire: nella tabella DIPENDENTE sono presenti CODICE_FISCALE non univoci (più record con lo stesso codice fiscale)?
Quanti record contiene DIPENDENTE?
 
Ciao
Mat.

 Mat.
 
e anche:
 nella tabella COMPENSO sono presenti TIPO_COMPENSO non univoci ?
(i record in queste DUE tabelle, DIPENDENTE e  COMPENSO, sono completati da campi "di validità": data, luogo, firma del registrante, ecc. ecc. ?)
 


grazie per la lezione gratuita. molto simpatica la frase 'tu dimmi quello che io devo fare e io lo faccio', saresti un ottimo prof. di informatica.
 
non mi sono spiegato bene, mi scusi. nella tabella CONTA ci sono 284 record, incluse le ripetizioni di CODICE_FISCALE, cioè 284 record che comprendono più compensi per lo stesso codice fiscale, cioè per qualche dipendente ci sono due record o tre, cioè due o tre compensi diversi, il totale sono sempre 284 record. la tabella DIPENDENTI riporta per ogni record un codice fiscale diverso e ogni codice fiscale è ovviamente univoco. fatto sta che il numero dei record della tabella CONTA è 284 e io ottengo nel report esattamente 284 record, quindi posso stare sicuro che è andato tutto a porto vero?


la tabella COMPENSO ha solo due campi: TIPO_COMPENSO e DESCRIZIONE
la tabella CONTA, oltre al codice fiscale e tutti i dati contabili, ha un campo denominato TIPO_COMPENSO.
la tabella DIPENDENTE ha oltre al campo CODICE_FISCALE, i campi NOME e COGNOME, DATA_NASCITA, LUOGO_NASCITA ma a me interessa solo nome e cognome

Il giorno martedì 28 novembre 2017 18:08:34 UTC+1, nicola cantalupo ha scritto:
[Cut]
No, no, nessuna lezione: ho condiviso una considerazione che deriva da esperienza fatta :)
 
Sul fatto che sia tutto apposto non saprei dirti ne si, ne no: al momento la query da il risultato che ti serve ma il fatto che tu sia dovuto ricorrere a 'DISTINCT' significa che sotto sotto c'è qualcosa che non va.
 
Ciao
Mat.
 
p.s. la battuta 'tu dimmi...' non è mia, cercala su Google.
 

 
[CUT]
 
Ci sono, però, situazioni in cui il SELECT DISTINCT, a mio parere, non 
lo puoi evitare, con tutto il rispetto e la stima, ovviamente, per le 
tue argomentazioni (io sono un autodidatta che ha moooolto "attinto" a 
questo ng).
Condizione essenziale: corretti collegamenti con chiavi primarie e 
chiavi esterne delle tabelle.
 
"SELECT DISTINCT tblMilles.Tab FROM tblMilles;"
Questo enunciato mi ricava solamente 12 record (tblMilles.Tab=tabelle - 
ossia capitoli di spesa - di un condominio) su 225.
Non posso usare WHERE perché non posso ricavare i criteri di selezione 
dalla tabella che contiene i 225 record essendo i nominativi (con tanto 
di ID) ripetuti più volte per capitoli di spesa diversi, così come i 
capitoli di spesa, ripetuti più volte per nominativi diversi. In pratica 
il classico join (tabella Anagrafica -> tabella Capitoli di spesa) 
molti-molti.
 
L'enunciato sopra riportato mi serve per originare una query a campi 
incrociati origine dati di un report tabellare.
Su tutto l'applicativo i SELECT DISTINCT usati sono diversi e il tutto 
funziona a perfezione (ovviamente dopo aver sbattuto il muso su un 
milione di altre cose). Qui stiamo parlando di un paio di migliaia di 
record.
 
Ma su un altro applicativo che elabora pratiche di... (beh... 
appelliamoci alla privacy...) in cui la PK è il cod. fisc., ho quasi 70 
mila record, e questo funziona da ormai 12 anni (A2000 poi rielaborato 
in A2010) senza problemi.
Secondo il tuo parere pensi che la mia "fiducia" nel DISTINCT sia mal 
riposta?
Grazie
 
--
mantro

 mantro
 
Ciao mantro,
da come descrivi l'uso che fai di DISTINCT la tua "fiducia" non verrà tradita.
 
La questione che è emersa in questa discussione non era su DISTINCT "brutto e cattivo" era piuttosto sull'uso brutto e cattivo, sull'aggirare il problema anziché trovarne l'origine (e se possibile eliminarlo).
L'uso di DISTINCT in questo contesto è un po' come mettere On Error Resume Next all'inizio di una routine vba per evitare che si fermi per un errore di Runtime di cui non riusciamo a trovare l'origine: il codice non si ferma ma l'errore è ancora li.
 
Se si è consapevoli di come funziona la nostra query e del perché usiamo DISTINCT, allora è ok.
 
Ciao
Mat.

 mantro
 
RIPETO la tua definizione, che vale anche per me:
(io sono un autodidatta che ha moooolto "attinto" a questo ng)
 
e pongo una osservazione/domanda
(visto che non avevo considerato la clausola DISTINCT)
 
se invece di utilizzare la clausola DISTINCT si "stabilizzano" i soli record di interesse con una query di raggruppamento sul campo (sui campi ?) ripetuti,
mettiamo Access "in condizioni migliori" ?
e ancor più se il raggruppamento viene stabilizzato con una tabella temporanea ?


Condivido in toto quanto dici.
 
Ciao
 
--
mantro
 


Ciao,
l'uso del raggruppamento (GROUP BY) in sostituzione di DISTINCT non credo che porti vantaggi di prestazioni/uso di risorse (ma forse qualcuno ha fatto prove attendibili con Access, io no), a questo punto visto che il risultato è uguale allora io resterei su DISTINCT, almeno per la leggibilità del codice Sql e per risparmiare qualche carattere sul testo digitato: se i campi da restituire sono parecchi la clausola GROUP BY si allunga di conseguenza.
 
Riguardo la tabella temporanea: è una possibilità ma la userei solo nel caso dovessi riutilizzare più volte il risultato della query per evitare di ripetere l'esecuzione, altrimenti aggiungerebbe passaggi (scrittura nella tabella e successiva lettura) per ottenere lo stesso risultato.
 
Vorrei solo precisare che nel contesto di questo thread è "possibile" che DISTINCT sia la soluzione corretta, ma da come sono stati descritti i dati contenuti nelle tabelle, dal codice sql della query postata all'inizio, e dal fatto che il risultato dell'esecuzione è "inatteso" (i record si moltiplicano), è probabile che sia necessario fare un passo indietro e rivedere il problema.
 
Ciao
Mat.


Semplifico quanto scritto nel precedente post:
 
nome	Capitolo
-----	---------
ID1	A
ID1	C
ID1	D
ID1	E
ID2	A
ID2	B
ID2	C
ID2	E
ID2	F
ID3	A
ID3	B
ID3	E
ID3	F
 
In questo caso sia "SELECT DISTINCT MiaTab.Capitolo FROM MiaTab;" che 
"SELECT MiaTab.Capitolo FROM MiaTab GROUP BY MiaTab.Capitolo;" danno lo 
stesso risultato. Ma l'esempio è troppo semplice.
Nella mia esperienza ho imparato che devo provare, riprovare e riprovare 
ancora finché non ottengo quello che mi serve con "costo" minore in 
termini di prestazioni ma, soprattutto con sicurezza maggiore.
Come i guru di questo ng insegnano, ci possono essere varie tecniche, 
tutte valide, per ottenere un risultato. Bisogna valutare di volta in 
volta la convenienza.
Per ciò che mi riguarda anch'io a volte ricorro a tabelle temporanee 
soprattutto quando le query sono complesse ed in particolar modo quando 
mi servono poi per creare query a campi incrociati. È giusto?... non è 
giusto?... Non lo so! Come sopra... provare... provare...
 
--
mantro


accetto volentieri ottimi consigli che per di piu' sono gratuiti quindi la ringrazio di cuore