Report e relazioni tabelle

di il
28 risposte

Report e relazioni tabelle

Ciao a tutti! mi sto cimentando in maniera assolutamente autodidattica con access da quando in ditta abbiamo adottato un gestionale interamente in access.
Non essendo un gestionale vero e proprio poichè si limita principalmente alla gestione delle commesse, sto cercando di ampliarne un pochino le capacità per agevolizzare il lavoro in ufficio (è una piccola carpenteria meccanica...il tempo è denaro, soprattutto se si concentra troppo in ufficio).

Venendo al dunque...per adesso tabelle, codici VBA e maschere pian piano sono riuscito a gestirli.
Le cose che volevo fare, più o meno, sono riuscito a farle.
Un po' scopiazzando sulle parti di programma già presente, un po' sbirciando su internet.

Ho implementato il discorso "preventivi" creando tre tabelle.
La prima è quella che raccoglie i dati principali del preventivo.
Le altre due fanno riferimento ai materiali (PreventivoMateriali) una...ed alle lavorazioni l'altra (PreventivoLavorazioni).

La tabella principale "Preventivi" ha IDPreventivo come chiave primaria(con un formato del tipo: "P2012-001").
Le altre due tabelle non hanno alcuna chiave, ma hanno un campo dedicato all'idpreventivo (rispettivamente "IDPreLav" e "IDPreMat").

In pratica ho creato una maschera in cui questi campi sono correlati e la maschera principale mi da i dati del record della tabella Preventivi.
Poi ci sono due sottomaschere continue dove si possono inserire materiali da una parte e lavorazioni dall'altra.
Ecco un esempio di preventivo:



Finqui nessun problema.
Il mio problema ce l'ho quando inizio ad avere a che fare con un report attraverso il quale fare la stampa del mio preventivo.
Non riesco ad impostare l'origine record del report...
Cioè se apro solo due tabelle, ad esempio Preventivi e PreventiviMateriali, non ho alcun problema...perchè l'elenco dei materiali è corretto (vedi immagini seguenti).






Se mi azzardo ad aprire tre tabelle (che sono quelle che mi servono per popolare il report), mi si moltiplicano le righe dell'elenco dei materiali (vedi immagini qui sotto).





Ho provato a cercare di capire come funzionano relazioni e joint e quelle cose lì...credo sia questo il problema del mio report..ma non so districarmici.
Ho letto qui e là ma questa volta mi sono un po' incagliato.

Sono consapevole di essere caduto in un errore da pivello eheh (me lo posso permettere perchè lo sono!)...però spero che qualcuno di voi abbia tempo e voglia di darmi una piccola dritta.
Grazie mille in anticipo!

PS: Io sto cercando di fare un report con due tabelle affiancate, sulla falsariga della mia maschera...dite che ce la farò o è qualcosa che non si può fare?
Grazie ancora.

Maurizio

28 Risposte

  • Re: Report e relazioni tabelle

    Ci sono un paio di cose che secondo me non vanno...
  • Re: Report e relazioni tabelle

    Ciao Alex, grazie mille per la risposta praticamente immediata.

    Ti spiego qual'è la logica per la quale ho deciso di procedere così:
    Prima facevamo i preventivi tramite un foglio di calcolo excel che era impostato più o meno così...
    Cioè da una parte i materiali e dall'altra le lavorazioni.
    Questo perchè visivamente sia nell'immissione dei dati, sia nel report abbiamo la necessità di distinguere le due cose.
    Da ignorante in materia io ho subito pensato a due tabelle distinte attraverso le quali poter ottenere due sottomaschere continue.

    Per quanto riguarda il punto 2, è semplicemente una considerazione (quella di non aver chiavi primarie nelle tabelle lavorazioni e materiali), nel senso che nella mia assoluta ignoranza di access ho proceduto così:
    1) Ho fatto una tabella Preventivo con IDPreventivo come chiave primaria.
    2) Avendo deciso di fare altre due tabelle collegate a questa principale, ho messo un campo in cui memorizzare il medesimo dato (IDPreLav e IDPreMat) in maniera da poter correlare.
    Io in qualche modo ho intuito che una chiave primaria anche per queste altre tabelle sarebbe stata una buona cosa, ma la mia testa mi diceva che avrebbe dovuto essere rispettivamente IDPreLav e IDPreMat.
    Il fatto è che posso avere più record correlati con il medesimo preventivo, anzi è la norma che ci siano più righe.
    Quindi non sono riuscito a fare ste chiave primaria. Non le ho dato molta importanza perchè ho visto che la maschera mi funzionava. Poi sono arrivato al report...e qui probabilmente il problema si è fatto sentire.

    In ogni caso ti dico che è buona la tua seconda ipotesi, sicuramente la mia "tecnica base" nella pianificazione è stata l'ERRORE..dettato dall'ignoranza e dall'inesperienza.

    Non ho ancora iniziato ad utilizzare la parte dei preventivi, posso tranquillamente stravolgere tutto.
    Mi sa che mi conviene proprio riflettere, come dici tu, sulla struttura.
    Se riuscirò nel mio intento di tener separati visivamente sia nella maschera sia nel report i dati relativi ai materiali ed alle lavorazioni bene...altrimenti amen.
    Cosa mi consigli di fare?
    Grazie ancora!

    Maurizio
  • Re: Report e relazioni tabelle

    Visto che sei all'inizio del progetto è veramente consigliato ricominciare tutto da capo con una struttura piu corretta.
    Ti dico come organizzerei io il tutto, sempre se ho capito bene il tuo post.
    Come ti è stato già suggerito unirei le tabelle Lavorazioni e Materiali in un unica tabella.
    Non c'è scritto da nessuna parte che una colonna non possa avere parecchi campi se appartengono tutti alla stessa struttura logica. Per separarli per una visualizzazioni migliore si possono creare query separate solo con i campi desiderati.
    Poi lascerei fare gestire ad access le chiavi primarie e gli eventuali campi che vuoi siano unici li impongo unici da tabella ma non li ergo a chiavi primarie.

    Quindi due tabelle con una relazione una a molti in questa maniera



    Poi creo due query di selezione dalla tabella Materiali&Lavorazioni
    cosi strutturate


    Per la maschera creo con il wizard una con origine la sola tabella preventivo e poi nella struttura
    ci trascino le due query che creeranno le sottomaschere che potrai disporre come ti pare. Ovviamente saranno legate dall'ID_Pre che inserirai quando richiesto

    il risultato è questo



    In pratica come prima ma strutturalmente piu corretta.

    Poi il report lo creo esattamente come la maschera. Wizard sulla tabella preventivo e trascinamento delle due query nella struttura uniti per ID_PRE
    Il risultato sarà questo
  • Re: Report e relazioni tabelle

    Tremendamente chiaro! Ti ringrazio tantissimo.
    Adesso me lo studio per bene e ci lavoro.

    In pratica una sola "sotto-tabella" (chiamiamola così) e gestisco maschera e report attraverso due query mirate su tale sotto-tabella.

    Vi farò sapere come è andata a lavoro ultimato, o, al max, chiederò ancora aiuto!
    grazie ancora!

    Maurizio
  • Re: Report e relazioni tabelle

    Purtroppo il suggerimento è errato...

    Manca nella considerazione il doppio legame che puà UNIRE i PREVENTIVI con le PRESTAZIONI o con le CAUSALI.

    Un preventivo ha Molte CAUSALI, ma una CAUSALE può appartenere a MOLTI PREVENTIVI.

    Questo si realizza con una Relazione complessa definita MOLTI-MOLTI che fisicamente non esiste
    e si realizza usando una Tabella di appoggio o dettaglio.

    Quindi
    Tabella PREVENTIVI
    Tabella CAUSALI(o prestazioni e materiali)
    Tabella DettaglioCausaliPerPreventivo

    Invito sempre a riflettere prima di iniziare a scrivere o strutturare tabelle.
    Saluti.
  • Re: Report e relazioni tabelle

    Ho fatto una cosa ancora più eterodossa ^^

    Visto che oramai quello che ho fatto era già fatto, prima di rifare tutto ho provato semplicemente a trascinare nel mio report le due sottomaschere rispettivamente dei materiali e delle lavorazioni.

    Senza chiavi primarie nelle tabelle e con una specie di relazione uno-a-molti fra IDPreventivo e IDPreMat e IDPreLav la cosa sembra funzionare.
    Ho praticamente ripresentato nel report tutto ciò che ho nella maschera.

    Testo il tutto e vi faccio sapere come va.

    Mi sa che ho violato tutte le regole di access, ma questo programma deve trovarmi simpatico..
  • Re: Report e relazioni tabelle

    @Alex ha scritto:


    Purtroppo il suggerimento è errato...

    Manca nella considerazione il doppio legame che puà UNIRE i PREVENTIVI con le PRESTAZIONI o con le CAUSALI.
    Un preventivo ha Molte CAUSALI, ma una CAUSALE può appartenere a MOLTI PREVENTIVI.
    Non sono affatto d'accordo con Alex.
    Resto della mia idea per la struttura e considero la sua correzione al mio suggerimento una autentica sciocchezza considerando irrilevante ai fini dell'obiettivo di weldox il legame 1causale-molti preventivi.

    Io "vedo" un solo preventivo e tanti record con molti campi in comune in cui in alcuni c'è il costo del materiale e in altri c'è la mano d'opera.
  • Re: Report e relazioni tabelle

    nelsonblu ha scritto:


    Non sono affatto d'accordo con Alex.
    Resto della mia idea per la struttura e considero la sua correzione al mio suggerimento una autentica sciocchezza considerando irrilevante ai fini dell'obiettivo di weldox il legame 1causale-molti preventivi.

    Io "vedo" un solo preventivo e tanti record con molti campi in comune in cui in alcuni c'è il costo del materiale e in altri c'è la mano d'opera.
    Guarda che non stiamo giocando a chi lo ha più lungo...

    Quello che ho esposto è spiegato tecnicamente ed è originato dalla conoscenza ed applicazione di criteri BASE della NORMALIZZAZIONE.
    Non ho detto [nelsonblu] è un *****, ho detto che il suggerimento è errato motivandolo.

    Poco centra se le cose stanno in piedi anche con accrocchi, la prima cosa che un TECNICO deve sapere è che i suggerimenti da dare devono sempre essere in linea con quanto la teoria suggerisce.

    I forum sono accrescimento tecnico e la partecipazione deve essere qualitativa non quantitativa, non si ottiene ragione facendo come i BIMBI... ma si portano a suffragio spiegazioni tecniche rilevanti e basate su un minimo di conoscenza.

    Per il resto ogni errore concettuale espresso avrà la mia critica tecnica e non personale perchè le informazioni devono essere giuste in modo più assoluto e non relativo.
  • Re: Report e relazioni tabelle

    Forse non mi sono spiegato...
    Il mio non essere d'accordo è proprio TECNICO.
    Io la relazione molti a molti di cui tu parli, ripeto, NON LA VEDO.
    La tua motivazione
    Manca nella considerazione il doppio legame che puà UNIRE i PREVENTIVI con le PRESTAZIONI o con le CAUSALI
    ti sembra una motivazione?
    Me la fai vedere la tabella di join in dettaglio e come è collegata 1 a molti alle altre due tabelle nel nostro caso specifico? e come e perchè serve realmente alla causa?
    Ma di quale doppio legame stai parlando?? E come rientra questo presunto doppio legame nell'obiettivo di weldox.
    Quello che ho esposto è spiegato tecnicamente ed è originato dalla conoscenza ed applicazione di criteri BASE della NORMALIZZAZIONE.
    Qualche libro sulla normalizzazione l'ho letto anch'io.
    Poco centra se le cose stanno in piedi anche con accrocchi, la prima cosa che un TECNICO deve sapere è che i suggerimenti da dare devono sempre essere in linea con quanto la teoria suggerisce.
    La prima cosa che un tecnico deve sapere è che la ridondanza è un errore grave.
  • Re: Report e relazioni tabelle

    Accidenti, mi spiace ragazzi...non volevo che la discussione arrivasse a questi toni.
    Comunque ho finito adesso di sistemare il report e va bene per quello che serve a noi!

    Mi avete dato qualche dritta semplice ma molto importante alle quali non ero arrivato.....principalmente che mi ha risolto la questione è stata quella del trascinare le sottomaschere nel report in modo da poter formare due tabelle separate.
    Mi si sono generati i campi in automatico sul report...formattati bene, in maniera da essere facilmente modificabili ed adattabili.
    In poche ore ho raggiunto lo scopo!

    Ecco! (a questo link l'immagine completa: http://img62.imageshack.us/img62/6466/immagine1fk.jp )

  • Re: Report e relazioni tabelle

    nelsonblu ha scritto:


    Forse non mi sono spiegato...
    Non vedo motivo di proseguire, ci sono grosse lacune concettuali ed un'arroganza di base che ostruisce il tutto.

    Chi legge con un minimo di conoscenze darà il suo giudizio.
    Saluti.
  • Re: Report e relazioni tabelle

    Peccato.. mi aspettavo la tabella di join di una relazione molti a molti.
    Non vedo motivo di proseguire, ci sono grosse lacune concettuali ed un'arroganza di base che ostruisce il tutto
    Torna umile
  • Re: Report e relazioni tabelle

    Ciao

    Effettivamente in questo caso la causale servirebbe. Il motivo è semplice. Il ciclo di un documento fiscale è, in genere: preventivo - ordine - fatturazione (alex, correggimi se sbaglio, non ricordo alla perfezione ). Tale ciclo presuppone che un preventivo venga "inglobato" all'interno di un ordine, il quale verrà "inglobato" nella fattura finale. Questo perchè, ovviamente, i dati saranno uguali (parlo delle righe, cioè gli articoli venduti/comprati). La causale ci viene in aiuto per la movimentazione di magazzino, cosa che dovrà essere presa in considerazione ovviamente. E un buon programmatore non deve pensare solo al presente, ma anche al futuro. Ecco perchè Alex ha visto tale cosa, anche se non scritta. Però Alex non vedo la relazione molti a molti, perché la causale, da quel che ricordo dal vecchio lavoro, può essere si multiplo all'interno del documento, ma se riferito ad un articolo, quindi una causale per rigaDocumento. Quindi una causale può avere sì molte righeDocumenti, ma una rigaDocumento può avere una sola causale, quindi diventa una relazione una a molti.

    Se posso, vorrei aggiungere una tabella articoli, in modo da incentrare tutti gli articoli per le varie "zone" del gestionale che sta nascendo (documentazione, magazzino, ....).

    Ora come ora mantengo il thread aperto, ma sotto sorveglianza. Voglio ricordarvi che un forum è un posto dove scambiarsi idee e aiuti, e non attaccarsi l'un l'altro. qua si discute, non si litiga
  • Re: Report e relazioni tabelle

    Credo ci sia un fraintendimento sul concetto di CAUSALE.
    La Causale è la Voce di prezzo, che può essere Multipla, che compone il preventivo.

    Di norma infatti un preventivo(Tabella Preventivi) comprende voci di Catalogo(divise in Categorie).

    La dove il preventivo può avere molti Articoli/Causali serve una Tabella 1-Molti.
    Ma il problema si complica in quanto i preventivi sono MOLTI ma anche gli ARTICOLI/CAUSALI sono molti.

    Quindi già mi trovo con 2 Tabelle
    1° Tabella Preventivi
    2° Tabella Catalogo Articoli o Causali o Voci Prezzo

    Come faccio a mettere in relazione queste 2 Tabelle che contendgono i dati per comporre
    da una parte il PREVENTIVO dall'altra i riferimenti alle VOCI di CATALOGO ARTICOLI...?

    Per fare in modo che un Preventivo abbia un legame con Molti Articoli, quindi un'elenco di CAUSALI che concorrono a comporre il TOTALE serve un'altra tabella, nella quale convergono la PK della Tabella Preventivo e la PK della Tabella CATALOGO.

    Questa è la Relazione Molti-Molti, non c'è altro modo per gestire queste cose al fine di avere FLESSIBILITA'.

    Spero di aver chiarito il concetto.
Devi accedere o registrarti per scrivere nel forum
28 risposte