Acquista i nostri libri consigliati su Amazon.it
+ Rispondi al messaggio
Pagina 1 di 2 12 ultimoultimo
Visualizzazione dei risultati da 1 a 10 su 19

Query parametrica da maschera - problemi sulla gestione dei parametri....

  1. #1
    Jocman non è in linea Scolaretto
    Ciao a tutti.
    Sto realizzando un DB per la gestione del carico e lo scarico dei materiali di magazzino.
    Il DB è organizzato principalmente su queste 3 tabelle (poi ci sono anche delle tabelle accessorie da cui prelevo dei valori fissi): tabella principale Anagrafe (cioè la categoria dei materiali), tabella collegata uno-a-molti Dettaglio (cioè dove inserisco i lotti dei vari materiali > un materiale può avere più lotti), tabella Storico (dove registro i movimenti di carico/scarico)
    Dopo lunghe peripezie, le sezioni di consultazione archivio, carico e scarico sembra funzionino a dovere.
    Per consultare l'archivio, utilizzo due query: una mi cerca il codice a barre (relativo al lotto e quindi registrato in tabella Dettaglio), vede quale è l’ID collegato con la tabella Anagrafe e genera una tabella temporanea con questo valore; una seconda query prende questo valore, lo cerca in tabella Anagrafe e mi fornisce a video i dati richiesti (cioè l’unione delle due tabelle Anagrafe e Dettaglio) relativi a quel prodotto.
    Il carico e lo scarico funzionano bene (ometto di descriverne la struttura).
    Ogni volta che effettuo un carico / scarico, via VBA prelevo i valori dei campi che mi interessano e li accodo alla tabella Storico, che è costituita dei seguenti campi:

    StoricoMateriali: contatore
    IDDettagli: numerico – fa riferimento all’ID della tabella Dettaglio (che è unico per ogni lotto in tabella Dettaglio)
    IDMateriali: numerico – fa riferimento all’ID della tabella Anagrafe (cioè l'ID "padre" cui il lotto è collegato)
    Data: data/ora – lo mette in automatico con la funzione NOW() ogni volta che effettuo un movimento
    Movimento: testo - assume 2 valori: Carico o Scarico
    Lotto: testo – il numero di lotto su cui sto lavorando
    Quantita01: numerico – registra la giacenza prima del movimento
    Quantita02: numerico – registra la quantità movimentata
    Quantita03: numerico – registra la quantità dopo il movimento
    Nome: testo – il nome di chi materialmente esegue il movimento

    Ho però la necessità di gestire anche uno storico dei movimenti per interrogare il DB circa i materiali ed i relativi movimenti.
    E qui mi sono impantanato da circa una settimana, nonostante abbia provato diverse soluzioni trovate cercando in rete.
    Fondamentalmente, ho creato una maschera con cinque interruttori: Carico, Scarico, Nome, IntervalloData, Tipologia.
    Tralasciando l’aspetto grafico (che funziona), nella mie intenzioni c’era di usare una query parametrica che prendesse i dati da questa maschera a seconda degli interruttori premuti.
    La soluzione che avevo trovato è di associare, ad esempio, una casella di testo all’interruttore Carico che, quando premuto, associava via VBA il valore “Carico” alla casella. Discorso analogo per l’interruttore Scarico e Nome (in quest’ultimo caso abilita una combo box che pesca i nomi da una tabella).
    L’interruttore IntervalloData abilita due caselle di testo (Da – A) dove inserire le date (se non abilitate, per default Da assume valore 30/12/1899 e A la data odierna +1).
    L’interruttore Tipologia attiva una combo box che visualizza una stringa relativa al materiale e contestualmente alla sua scelta visualizza su due caselle di testo il relativo IDDettagli e IDMateriali.
    La query avrebbe dovuto prelevare i valori scelti nella maschera a seconda degli interruttori attivati (nel caso non attivati avrebbe assunto che quel campo fosse *), e generare il report in base ai criteri forniti.
    L’unica query che ha funzionato (parziale) è questa:

    SELECT tblStorico.*
    FROM tblStorico
    WHERE ((tblStorico.Movimento)=[Forms]![frmMaterialiStorico]![txtCarico])) OR (((tblStorico.Movimento)=[Forms]![frmMaterialiStorico]![txtScarico]))
    ORDER BY tblStorico.Data;
    
    che mi discrimina in base al movimento.
    Discorso analogo per la ricerca con le date.

    L’ultima soluzione che avevo trovato per mettere insieme tutti i criteri della maschera era la seguente (anche se non è completa):

    SELECT tblStorico.*
    FROM tblStorico
    WHERE (((tblStorico.Data) Between [Forms]![frmMaterialiStorico]![txtData1] And [Forms]![frmMaterialiStorico]![txtData2]) AND ((tblStorico.IDDettagli) Like NZ([Forms]![frmMaterialiStorico]![txtIDDettagli],"*"))) OR (((tblStorico.IDMateriali) Like NZ([Forms]![frmMaterialiStorico]![txtIDMateriali],"*")) AND ((tblStorico.Movimento)=[Forms]![frmMaterialiStorico]![txtCarico])) OR (((tblStorico.Movimento)=[Forms]![frmMaterialiStorico]![txtScarico]))
    ORDER BY tblStorico.Data;
    
    Purtroppo mi restituisce sempre tutti record presenti nella tabella Storico, indipendentemente da cosa io scelga.….

    La gestione IDDettagli e IDMateriali è problematica almeno per me, ma suppongo che scritta in quel modo venga ignorata (le caselle di testo della maschera sono vuote, quindi…). In teoria, io vorrei scegliere dalla combo Tipologia la stringa relativo al materiale (ad esempio Guanti taglia M lotto 01 – questa stringa mi viene generata da una query) e poi inviare alla query i due campi IDDettagli e IDMateriali. E su questo aspetto fino ad ora (visti i risultati) non mi ci sono ancora messo….

    Chiedo scusa per la prolissità, ma spero di aver illustrato quanto più dettagliatamente la situazione.
    Mi potete dare qualche suggerimento su come ottenere il risultato?
    Grazie
    Andrea

  2. #2
    OsvaldoLaviosa non è in linea Topo di biblioteca
    Hai molti problemi di organizzazione tabelle a monte che ti impedisce di proseguire poi.
    Hai detto AnagraficaMateriali uno-a-molti con Dettagli. Poi metti due ID numerici dentro la tabella Storico. Io ho capito che IDMateriale proviene da AnagraficaMateriali: se hai fatto così è sbagliato.
    In tabella Storico non devi mettere tutti quei campi Quantità, devi solo registrare i singoli movimenti. Future query stabiliranno i vari calcoli intermedi, totali, progressivi...come pare a te.
    Puoi spiegare che vuol dire Lotto? Cosa è un Lotto? Devi spiegarlo proprio terra terra...penso sia un termine strettamente tecnico del tuo campo che, almeno io, non so cosa significa.

  3. #3
    Jocman non è in linea Scolaretto
    Ciao Osvaldo.
    Innanzitutto grazie per la risposta.
    Cerco di spiegarmi meglio sulle cose che ti danno perplessità (mi rendo conto di aver messo tante notizie).
    Partiamo dal più semplice: il Lotto.
    Non è il gioco statale (scusa la battutaccia, è giusto per sorridere); semplicemente, la produzione industriale avviene per lotti di fabbricazione (che, per inciso, hanno date di scadenza diverse), così in caso di errore si riesce a individuare quale è il lotto difettoso e lo si elimina (se fai mente locale, ogni tanto in TV dicono che l'industria X ha provveduto al ritiro del materiale difettoso; ecco, lo possono identificare grazie al numero di lotto). Nel mio caso (non essendo una industria), io mi ritrovo con diversi lotti per uno stesso tipo di prodotto. Ad esempio, compro 10 scatole di guanti. Se ho fortuna, mi verranno consegnate 10 confezioni tutte dello stesso lotto produttivo; solitamente invece me ne ritrovo di lotti produttivi diversi. Ogni lotto è identificato da un codice alfanumerico univoco. Il mio "lotto" pertanto è un codice che io uso per gestire quella specifica scatola che poi movimento in magazzino.
    Qui aggancio anche il discorso IDMateriali e IDDettagli:
    IDMateriali: è il contatore che uso nella tabella Anagrafe; nell'esempio, identifica il prodotto generico, cioè i guanti.
    IDDettagli: è il contatore che uso nella tabella Dettagli; nell'esempio, ogni scatola di guanti con un numero di lotto diverso avrà un suo IDDettagli. Ne deriva che per ogni IDMateriali ci possono essere X IDDettagli (uno-a-molti).
    Quindi la situazione media che potrei trovarmi è: mi consegnano 10 pacchi di guanti che appartengono a 3 lotti produttivi diversi; le mie tabelle avranno questi ID:
    Tabella Anagrafe - IDMateriali: 1 (cioè "guanti")
    Tabella Dettagli - IDDettagli: 1 (cioè "guanti lotto 1" - 3 scatole)
    2 (cioè "guanti lotto 2" - 5 scatole)
    3 (cioè "guanti lotto 3" - 2 scatole)
    Quello che materialmente faccio ogni volta che carico del materiale è: cercare la descrizione generica intabella Anagrafe (quindi mi serve l’IDMateriali) poi genero il sottorecord intabella Dettagli con il suo IDDettagli, dove registro le informazioni di carico: numero di lotto, eventuale scadenza, ditta fornitrice e quantità caricata. Al termine della procedura, ottengo la generazione di un mio codice a barre (anche esso salvato nella tabella Dettagli in corrispondenza del record) che serve a me poi per la gestione di quello specifico lotto di materiale caricato.
    In effetti nella tabella Dettagli, se la aprissi, io mi ritrovo con solo cifre o informazioni inutili (tipo il nome della ditta fornitrice), ma non riuscirei a capire quel record a cosa si riferisce (se a guanti, a fazzoletti, etc etc). Nell’interrogazione archivio mi vengono in aiuto le 2 query che ho creato, che trovano i dati in relazione tra loro e me li visualizzano in modo “umano”.
    Un discorso analogo è per la tabella Storico: anche questa contiene dati “inutili” (l’unico testo è il nome di chi effettua l’operazione), gli unici due elementi identificabili sono proprio i due ID (che in questa tabella sono solo campi numerici, lo STORICO ha un suo ID progressivo - mi rendo conto che ho descritto in modo equivoco la struttura della tabella Storico). Mi dici che è sbagliato mettere i due ID nella tabella Storico. Se mettessi uno solo dei due ID otterrei queste due possibilità (secondo me):

    1)Metto solo IDMateriali? Ok, ma quale lotto collegato a quell’ID ho caricato/scaricato? (non ho il relativo IDDettaglio che mi identifica il lotto)
    2)Metto solo IDDettaglio? Ok, ma quel lotto di che articolo è? (non ho il relativo IDMateriali che identifica il prodotto)

    Usandoli entrambe invece so che: IDMateriale è “1”? ok, identifica i guanti. IDDettagli è “2”? ok identifica il lotto “2” dei guanti. So che ho caricato/scaricato una scatola di “guanti” appartenenti al lotto “2”.
    Per quanto riguarda il discorso “quantita”… Forse hai ragione, non ci sarebbe la necessità di registrare ogni volta tutte queste informazioni, ma per il momento (siccome il DB è ancora in fase di sviluppo, ma ho necessità di usare la gestione carico/scarico subito) ho pensato di cominciare a salvarle, poi un domani lavorerò sui dettagli.
    La mia difficoltà con la gestione della tabella Storico (cioè lo sviluppo della query parametrica) è perché sicuramente in futuro mi interesserà reperire informazioni del tipo: quanti guanti ho caricato/scaricato in totale? Oppure: quanti guanti ho caricato nel primo semestre? Oppure: chi ha movimentato questo lotto? Oppure: Tizio cosa ha movimentato in questo periodo? Oppure un mix di tutto….
    Spero di aver fatto luce un po’ sulle tue perplessità.
    Comunque grazie ancora per l’aiuto ed il tempo che mi stai dedicando.
    Andrea

  4. #4
    OsvaldoLaviosa non è in linea Topo di biblioteca
    Io ho bisogno di ragionare per piccoli passi. Hai previsto una tabella Lotti apposita? Per me occorre considerare le seguenti tabelle:

    Lotti
    IDLotto
    NomeLotto
    Indirizzo
    ...altri campi identificativi

    Materiali (il nome Anagrafe lo trovo terribile!!!)
    IDMateriale
    NomeMateriale (es. guanti)

    Prodotti (forse tu l'hai chiamata Dettagli, ma stiamo parlando della stessa tabella? Hai previsto anche altri campi?)
    IDProdotto
    DataProduzione
    DataScadenza
    IDLotto
    IDMateriale

    Relazioni:
    Lotti.IDLotto uno-a-molti con Prodotti.IDLotto
    Materiali.IDMateriale uno-a-molti con Prodotti.IDMateriale

    Puoi confermare questo mio primo quadro logico?

  5. #5
    Jocman non è in linea Scolaretto
    Ciao Osvaldo.

    Allora, ti posto la struttura delle mie tabelle (il nome Anagrafe lo so che è orribile, ma a breve dovrò implementare la gestione di materiali diversi, per cui le tabelle verranno rinominate in qualcosa tipo Materiali1Anagrafe, Materiali2Anagrafe, etc etc….lo so, è un casino, ma farò così…):

    tblAnagrafe:
    IDMateriali (Contatore)
    Tipologia (testo) (qui inserisco "guanti", o altro)
    Descrizione (testo) (qui specifico il tipo, "lattice" es. se i guanti sono in lattice o cotone)
    Quantita (numerico)
    QuantitaMinima (numerico) (cioè il limite per effettuare un ordine)
    Misura (testo) (o anche per definere un modello, etc etc)
    Barcode (testo) (questo mi serve per altri motivi ma è diverso da Barcode2 della prossima tabella)
    Collocazione (testo)
    Note (testo)

    tblDettaglio:
    IDDettaglio (contatore)
    IDMateriali (numerico) (usato nella relazione uno-a-molti)
    Lotto (testo)
    Scadenza (data)
    Barcode2 (testo) (questo è il codice a barre chegenero e uso per le operazioni di carico/ scarico)
    Quantita (numerico)
    Ditta (testo)

    tblStorico:
    Storico (contatore)
    IDDettaglio (numerico)
    IDMateriali (numerico)
    Data (data)
    Movimento (testo)
    Lotto (testo)
    Quantita1 (numerico) (prima del movimento)
    Quantita2 (numerico) (quanta ne movimento)
    Quantita3 (numerico) (dopo il movimento)
    Operatore (testo)

    Relazioni:
    tblAnagrafe.IDMateriali uno-a-molti con tblDettaglio.IDMateriali

    La tblStorico non è relazionata con niente, è indipendente e mi serve solo per tenere traccia dei movimenti

    queste sono le strutture che utilizzo

  6. #6
    OsvaldoLaviosa non è in linea Topo di biblioteca
    No. Non ci siamo proprio.
    Non puoi avere più tabelle che parlano lo stesso linguaggio. È sbagliato parlare di Materiali1Anagrafe, Materiali2Anagrafe ecc...
    Non puoi avere una tabella Storico che non sia relazionata con niente.
    Non puoi usare le tabelle di Access come se fossero (vagamente) quelle di Excel. Le logiche di queste due applicazioni, proprio in casi come questi, fanno cascare l'asino, in quanto mettono in luce le loro fondamentali differenze.
    Ti invito a studiare correttamente Access e a coglierne gli aspetti più strettamente archivistici e meno quelli aritmetici.

  7. #7
    Bogus non è in linea Scolaretto
    Aldilà della struttura del db che non condivido, per quanto riguarda la query in questione:
    1 non serve mettere in maschera due caselle di testo in maschera una per il carico e una per lo scarico, ne basta una e così anche nelle relative condizioni nella query.
    2 tra le condizioni dei dettagli e materiali invece di mettere or io metterei and in quanto se nella maschera non c'è uno dei due valori interviene l'asterisco.
    ℹ️ Leggi di più su Bogus ...

  8. #8
    Jocman non è in linea Scolaretto
    Quote Originariamente inviato da OsvaldoLaviosa Visualizza il messaggio
    No. Non ci siamo proprio....
    Non puoi avere.....
    Non puoi usare....
    Non puoi usare.....
    Ti invito a.....
    Lungi da me qualsivoglia intenzione di muovere critiche, ma.....
    Circa la struttura, ritengo possa essere opinabile come uno ritenga dover "creare" qualcosa seguendo una propria idea.
    Magari una struttura potrà essere macchinosa, ridondante e quant'altro, magari potrà incamerare dati inutili e crescere in dimensioni....magari tutto quello che vuoi, però, a meno che ciò non comporti un'autodistruzione del DB, del PC che lo esegue e provochi lesioni permanenti al suo utente umano, non capisco la tua presa di posizione lapidaria. Esiste una logica informatica? va benissimo. Come esiste una logica in ogni cosa su questo pianeta. Eppure non si è obbligati a seguire la logica pedissequamente per ottenere il risultato. La storia è piena di personaggi che hanno cambiato il mondo andando "contro logica" (Einstein ?!?!?!). Io non sarò un genio informatico come te nè tantomeno mi paragono ad Einstein, ma non mi va di essere trattato alla stregua di un untore.
    Posso accettare il fatto che tu non condivida la mia "creatività", ma prendersela in questo modo mi sembra veramente fuori luogo. Neanche abbia insultato il "Sig. Access" personificato.....

    Oltretutto, se non ho interpretato male io stesso il mio post iniziale, il mio problema riguardava il fatto che non riuscivo ad impostare dei criteri per una query parametrica, la quale, sempre se non sbaglio, doveva estrapolare dati da una tabella sola, cioè la Storico che non è relazionato a nulla; e infatti la ricerca doveva avvenire solo in quella tabella.
    Ho spiegato anche che il DB in sè, a meno di malfunzionamenti che non ho ancora riscontrato, fa quello che gli ho chiesto (ed è quello di cui ho bisogno: che mi faciliti il lavoro, il "come" non mi crea problemi), il problema, ripeto, è solo e unicamente, utilizzando dei parametri variabili, come estrapolare i dati che mi servono da una tabella isolata (la cui genesi funziona a dovere e non mi crea problemi il "come faccia a funzionare visto che sono un ignorante in materia di strutture di DB state-of-art")
    Così come non sono un genio informatico, forse sarò anche un idiota ad interpretare le netiquette dei forum, perchè se non erro uno dei principi fondamentali è l'evitare l'off topic: e qua mi pare che un problema su come organizzare la "struttura di una query" sia stato spostato (non da parte mia) su "struttura di DB", che non era il problema che stavo affrontando. Se poi questo significa lavorare sul mio problema non saprei, ma del resto, come detto, non sono un genio in materia.
    A questo punto, pur continuando a affermare che non voglio polemizzare, specie se qualcuno mi dedica il suo tempo, se hai la possibilità di darmi qualche consiglio su come risolvere il mio problema (la query) sarò ben lieto di starti a sentire e di ringraziarti; diversamente non credo sia il caso tu perda il tuo tempo con me.


    Quote Originariamente inviato da Bogus Visualizza il messaggio
    Aldilà della struttura del db che non condivido, per quanto riguarda la query in questione:
    1 non serve mettere in maschera due caselle di testo in maschera una per il carico e una per lo scarico, ne basta una e così anche nelle relative condizioni nella query.
    2 tra le condizioni dei dettagli e materiali invece di mettere or io metterei and in quanto se nella maschera non c'è uno dei due valori interviene l'asterisco.
    Ciao Bogus.
    Riguardo al punto 1: hai ragione, infatti già avevo proceduto a ridurre il numero delle caselle di testo
    Riguardo al punto 2: provo a fare in questo modo e poi faccio sapere.

    Scusate lo sfogo di sopra, non ce l'ho con nessuno e mi auguro che nessuno si senta offeso, a qualsivoglia titolo, ma essere messo all'angolo senza motivo non mi va.

    Andrea

  9. #9
    Jocman non è in linea Scolaretto
    Faccio un piccolo update, dopo una mattina di tentativi ed ipotesi.
    L'opzione 2 suggerita da Bogus non ha funzionato, continuo ad avere problemi di interrogazione.

    Allora, sempre spulciando nel sito, ho trovato quanto segue:

    http://forum.masterdrive.it/access-7...o-nullo-58039/

    Se ho letto bene, in teoria dovrebbe restituire tutti i valori quando la combobox (nel mio caso una textbox, ma non credo faccia differenza) ha valore nullo. Se è giusto, io l'ho interpretata così:
    Trova i records il cui valore del campo X della tabella è uguale al valore della textbox della maschera; se poi il valore della textbox è null, visualizza tutti i records

    Alla luce di ciò, sono partito da zero, per tentativi, creando la query con questa struttura:

    SELECT *
    FROM tblStorico
    WHERE
    ((tblStorico.Data) Between [Forms]![frmMaterialiStorico]![txtData1] And [Forms]![frmMaterialiStorico]![txtData2])
    AND
    (((tblStorico.[movimento])=[forms]![frmMaterialiStorico]![txtMovimento] OR ([forms]![frmMaterialiStorico]![txtMovimento]) Is Null));
    
    Quando lancio la query variando nella maschera i parametri txtMovimento, txtData1 e txtData2, la query funziona a dovere fintantochè txtMovimento assume un valore (nello specifico Carico o Scarico), discriminando anche in base alle date.
    Nel momento in cui però voglio visualizzare i record senza tenere conto del campo Movimento e quindi lo lascio in bianco(e cioè il predicato Is Null), non mi visualizza più nulla.

    Forse ho interpretato male io il senso di quanto illustrato nell'articolo di Alex? Se invece il senso è quello che ho capito io, perchè non mi restituisce tutti i record come mi aspetterei?

    Andrea

  10. #10
    Bogus non è in linea Scolaretto
    Senza nulla togliere al valido (come sempre) articolo di Alex, secondo me sbagli qualcosa perché a me funziona perfettamente con la funzione Nz e con gli AND tra le varie condizioni.
    ℹ️ Leggi di più su Bogus ...

+ Rispondi al messaggio
Pagina 1 di 2 12 ultimoultimo

Potrebbero interessarti anche ...

  1. Query parametrica - parametri da casella combinata
    Da Beppe Di Zega nel forum Microsoft Access
    Risposte: 3
    Ultimo Post: 24-08-2016, 17:14
  2. query parametrica e maschera di ricerca
    Da marsem nel forum Microsoft Access
    Risposte: 1
    Ultimo Post: 17-10-2014, 13:22
  3. Risposte: 9
    Ultimo Post: 23-01-2014, 13:21
  4. Query parametrica problemi con estrazione null value
    Da massimoqaz1971 nel forum Microsoft Access
    Risposte: 8
    Ultimo Post: 23-01-2013, 21:41
  5. Query parametrica filtrata da molti parametri
    Da ncl3 nel forum Microsoft Access
    Risposte: 12
    Ultimo Post: 31-05-2011, 09:41