Relazioni database

di il
23 risposte

Relazioni database

Scusatemi spero di non infrangere il regolamento, ma ho la necessità di avere le tracce per quanto riguarda le relazioni, del database su cui mi sta aiutando @By65Franco e il mio post è stato chiuso prima che me l'avesse passate le informazioni necessarie. 

Sono informazioni molto importanti per me e non so cosa si intendeva per “flames”  il moderatore che mi ha chiuso il post, io spero che non sia riferito all'aiuto che mi sta dando perché perché è veramente importante visto che mi mancano delle basi per portare avanti mio progetto e non saprei dove reperirle. 

Vi scongiuro, ho veramente bisogno di queste informazioni, non chiudete mio post prima di averle, grazie per la comprensione! 

23 Risposte

  • Re: Relazioni database

    Ciao, il thread è stato chiuso perché il livello della discussione stava degradando. In questo forum viene fatto il possibile per mantenere un livello comunicativo basato sulla cordialità.

    Tu non c'entri nulla.

    Riporto il link alla discussione di partenza per chi volesse continuare a dare il suo contributo:

    https://www.iprogrammatori.it/forum-programmazione/access/aggiornamento-campi-da-tabella-a-alla-sottomaschera-di-una-tabella-b-t52232.html

    Invito gli eventuali partecipanti a dialogare in maniera cordiale. Chi non è interessato al thread o non gli piace, può semplicemente non partecipare. 

  • Re: Relazioni database

    09/08/2023 - Toki ha scritto:


    Ciao, il thread è stato chiuso perché il livello della discussione stava degradando. In questo forum viene fatto il possibile per mantenere un livello comunicativo basato sulla cordialità.

    Tu non c'entri nulla.

    Riporto il link alla discussione di partenza per chi volesse continuare a dare il suo contributo:

    https://www.iprogrammatori.it/forum-programmazione/access/aggiornamento-campi-da-tabella-a-alla-sottomaschera-di-una-tabella-b-t52232.html

    Invito gli eventuali partecipanti a dialogare in maniera cordiale. Chi non è interessato al thread o non gli piace, può semplicemente non partecipare. 

    Innanzitutto ti ringrazio! 

    Ma non avevo letto, nulla di particolare o offensivo a riguardo, o forse perché non sono italiana e non ho capito?? 

    Comunque ringrazio ancora perche ho veramente bisogno di queste informazioni, sono preziose per me! 

  • Re: Relazioni database

    09/08/2023 - Pattygirl ha scritto:


    Comunque ringrazio ancora perche ho veramente bisogno di queste informazioni, sono preziose per me! 

    Ciao,
    ho trovato l'inghippo, anzi i tanti inghippi ;-)  che come ti accennavo in precedenza, ti creeranno sempre dei problemi nel proseguo del progetto.

    Ti preparo una documentazione della traccia di come approcciare l'argomento con più info possibili in modo tu possa approfondire, capire e migliorarti ancora di più.

    Se posso, ti scrivo il post quanto prima possibile… tempo di scrivere la documentazione a supporto.

  • Re: Relazioni database

    09/08/2023 - By65Franco ha scritto:


    09/08/2023 - Pattygirl ha scritto:


    Comunque ringrazio ancora perche ho veramente bisogno di queste informazioni, sono preziose per me! 

    Ciao,
    ho trovato l'inghippo, anzi i tanti inghippi ;-)  che come ti accennavo in precedenza, ti creeranno sempre dei problemi nel proseguo del progetto.

    Ti preparo una documentazione della traccia di come approcciare l'argomento con più info possibili in modo tu possa approfondire, capire e migliorarti ancora di più.

    Se posso, ti scrivo il post quanto prima possibile… tempo di scrivere la documentazione a supporto.

    Io veramente non saprei come ringraziarti! 

    Io ho veramente bisogno di qualcuno che mi indichi dove ho sbagliato e cosa posso fare per migliorare. 

    Per quanto riguarda i commenti di cui avevi parlato poc'anzi, non li ho proprio visti. Forse perché mi sono concentrata sulle tue risposte perché hai deciso di tenermi per mano e aiutarmi veramente, dedicando tempo e sforzi ad una sconosciuta in un forum. Questo tuo gesto rende insignificante qualsiasi commento di cattivo gusto abbiano scritto e una cosa che ho imparato è che non si deve dare l'importanza e mandare in estinzione questo genere di comportamento. Più si dà importanza, più lo fortifichi… ignorare questo genere di persone è la più grande punizione. 

    Comunque davvero, grazie di cuore per quello che stai facendo per me, la vita gira e il bene che si fa torna sempre indietro con interesse! 

    Grazie!!!! 

  • Re: Relazioni database

    Il problema principale è la cattiva strutturazione del database:

    • poca Normalizzazione delle tabelle :
      • vedi T_Anagrafiche i campi:
        • Dip-Int
        • inquadramento
        • area
        • Reparto
        • SottoReparto
        • Turni
        • IDMansione
        • ecc…
    • mancata gestione di alcune proprietà fondamentali dei campi:
      • Obbligatorio (se impostato su Sì non consente di salvare il record se non sono stati inseriti i dati richiesti)
      • Consenti lunghezza zero (da impostare su No se i dati sono sempre richiesti)
      • Indicizzato (impostato a "Sì (non sono consentiti duplicati)" quando si vuole che in un campo un valore non venga inserito più di una volta e quindi sia univoco (vedi Matricola)  (se è necessario utilizzare due o più campi per evitare la duplicazione)

    per questo ho postato un file con una minima struttura di esempio

    https://www.dropbox.com/scl/fi/9i5704kh868y262jfak2g/GestionePianoSanitario.zip?rlkey=scj5wositw7e3to71outeikv2&dl=0

    vedi la finestra delle relazioni per avere un'idea più chiara.

  • Re: Relazioni database

    Come accennato in precedenza i tuoi problemi nascono per una errata progettazione del database, tabelle e relazioni. Ma sicuramente migliorerai sotto questo aspetto.

    Riepilogando:

    1. Stai lavorando con campi descrittivi e non con gli Id Chiave e questo ti crea il problema nel reperire la corretta corrispondenza tra Accertamento e Tabella Accertamenti/Anagrafica/etc…
    2. Non ti scombussolo nulla di quello che hai già realizzato e pur sapendo che non va bene ti propongo una soluzione molto criticabile e non ortodossa visto la natura delle colonne definite nelle tabelle e loro relazioni

    Nel particolare:

    • quando crei l'appuntamento non hai una chiave nella combo box accertamenti che tu possa successivamente utilizzare per implementare la tabella Piano Sanitario
    • hai solo una descrizione dell' Accertamento e questo dato in modo ridontante lo porti dietro su altre tabelle (questo non si fa)
    • vista la natura della tabella Appuntamenti e della tabella Piano Sanitario, le due non si legano tramite degli Id ma solo in modo descrittivo (questo non si fa)
    • per andare avanti con questo approccio devi continuare ad utilizzare tali descrizioni (anche questo non si fa)  ;-)
      • da Appuntamenti per passare il record al Piano Sanitario devi simulare ciò che faresti manualmente nel Piano Sanitario
        • per simulare tali inserimenti è necessario reperire le informazioni che ti occorrono passando nuovamente dall'Anagrafica  dalla tabella Rischi e attraverso le Mansioni alla tabella Accertamenti. Per fare questo devi crearti una query (stringa sql nel nostro caso) per poter risalire al Numero Mesi legato a tale accertamento. Per esempio:
    strSql = "SELECT T_Anagrafica.ID, Accertamenti_T.Accertamenti, Accertamenti_T.Periodicità " & _
             "FROM (T_Rischio INNER JOIN T_Anagrafica ON T_Rischio.ID = T_Anagrafica.IDMansione.Value) INNER JOIN Accertamenti_T ON T_Rischio.ID = Accertamenti_T.IDRischio " & _
             "WHERE T_Anagrafica.ID=" & Me.IDAnagrafica & " AND Accertamenti_T.Accertamenti='" & Me.Accertamento & "';"
    • se va a buon fine tale istruzione sql, otterrai il Numero Mesi che dovrai controllare se per quel Tipo di Accertamento è ammasso dal quell'Id Anagrafica… pertanto se non esiste tale legame il Numero Mesi sarà = 0
      • questa ipotesi devi intercettarla e gestire il da farsi. Per Esempio:
    If intMesi = 0 Then
        MsgBox "Type of assessment not foreseen", vbCritical, "Error"
        Me.Eseguito = "NO"
        Exit Sub
    End If
    • se invece il Tipo di Accertamento è legato a quella Anagrafica, allora puoi procedere all'inserimento del nuovo record nel Piano Sanitari. Il mio approccio è quello che ti presentavo nei post precedenti utilizzando l'Execute di DBEngine (sempre di Dao si parla, vedi documentazione che ti avevo passato). Pertanto dovrai controllare di avere tutte le informazioni e che siano corrette per procedere all'inserimento del record. Per esempio una traccia sarà di questo tipo:
    ' insert new records in the PianoSanitarioT table
    DBEngine(0)(0).Execute "INSERT INTO PianoSanitarioT (IdAnagrafica, Accertamenti, Periodicità, DataUltima, ProssimaVisita) " & _
                           "VALUES (" & _
                           Me.IDAnagrafica & ", '" & _
                           Me.Accertamento & "', " & _
                           intMesi & ", " & _
                           CStr(CLng(Me.SelData)) & ", " & _
                           CStr(CLng(DateAdd("m", intMesi, Me.SelData))) & ");"
    • dovranno essere anche eseguiti dei controlli preliminari prima di procedere. A tal fine ti lascio un esempio di questo tipo:
    Private Sub Eseguito_Click()
    ' check only selected = "SI"
    If Me.Eseguito = "NO" Then Exit Sub
    ' confirm message
    If MsgBox("Confirming the inclusion in the Health Plan?", vbExclamation + vbYesNo, "Confirm") = vbNo Then
        Me.Eseguito = "NO"
        Exit Sub
    End If
    • Come giustamente avevi segnalato userai la ComboBox  Eseguito 
      • una correzione che dovrai fare è quella di impostare il valore di Default per tale colonna della tabella e la imposterai con il valore “NO” altrimenti hai un valore null che a tale scopo non ti serve. Quindi i valori possibili saranno esclusivamente NO oppure SI
      • Per esempio su evento Click della combo box puoi creare "Routine Evento" e da codice Vba ti ritrovi la Sub dove inserire i tuoi controlli e esecuzione dell'Inserimento new record
      • Se sulla combo box scegli NO allora non esegui il codice e esci subito dalla Routine
      • Se hai scelto SI puoi per esempio far apparire un messaggio di conferma se si vuole effettivamente passare le informazioni al Piano Sanitario
        • se al messaggio di conferma selezioni NO allora devi impostare a NO la combo box Esegito e esci direttamente dalla Routine

    Se adesso provi a mettere insieme questi passsaggi otterrai una cosa di questo tipo:

    Esempio:

    ' INSERT PIANO SANITARIO
    Private Sub Eseguito_Click()
    ' check only selected = "SI"
    If Me.Eseguito = "NO" Then Exit Sub
    ' confirm message
    If MsgBox("Confirming the inclusion in the Health Plan?", vbExclamation + vbYesNo, "Confirm") = vbNo Then
        Me.Eseguito = "NO"
        Exit Sub
    End If
    
    ' set sql string
    Dim strSql As String
    strSql = "SELECT T_Anagrafica.ID, Accertamenti_T.Accertamenti, Accertamenti_T.Periodicità " & _
             "FROM (T_Rischio INNER JOIN T_Anagrafica ON T_Rischio.ID = T_Anagrafica.IDMansione.Value) INNER JOIN Accertamenti_T ON T_Rischio.ID = Accertamenti_T.IDRischio " & _
             "WHERE T_Anagrafica.ID=" & Me.IDAnagrafica & " AND Accertamenti_T.Accertamenti='" & Me.Accertamento & "';"
    ' open recordset
    Dim rs As DAO.Recordset
    Set rs = DBEngine(0)(0).OpenRecordset(strSql, dbOpenSnapshot)
    ' if exist - value save
    Dim intMesi As Integer
    If Not rs.EOF Then intMesi = rs.Fields("Accertamenti_T.Periodicità").Value Else intMesi = 0
    ' close
    rs.Close
    Set rs = Nothing
    
    ' check Accertmento type
    If intMesi = 0 Then
        MsgBox "Type of assessment not foreseen", vbCritical, "Error"
        Me.Eseguito = "NO"
        Exit Sub
    End If
    
    ' insert new records in the PianoSanitarioT table
    DBEngine(0)(0).Execute "INSERT INTO PianoSanitarioT (IdAnagrafica, Accertamenti, Periodicità, DataUltima, ProssimaVisita) " & _
                           "VALUES (" & _
                           Me.IDAnagrafica & ", '" & _
                           Me.Accertamento & "', " & _
                           intMesi & ", " & _
                           CStr(CLng(Me.SelData)) & ", " & _
                           CStr(CLng(DateAdd("m", intMesi, Me.SelData))) & ");"
    End Sub
    

    Se noti possiamo utilizzare lo stesso metodo, DBEngine per aprire un recordset della Query di cui si parlava all'inizio, quella che permetterà di risalire ai mesi di quell'Accertamento per quella Mazione di quel Rischio legato all'Anagrafica dove hai aperto un appuntamento da accodare al Piano Sanitario.

    E' solo una traccia in quanto non sappiamo se e come vorrai agire in caso di ripetuti invii al Piano Sanitario dello stesso Appuntamento… qui dovrai decider,  per esempio se quell'Appuntamento viene Eseguito (combo box Eseguito = SI) , potresti bloccare la ComboBox in modo che non possa più essere scelto un valore diverso. Quindi una volta Impostato Eseguito = SI a quel punto blocchi o la combobox oppure inserisci un ulteriore controllo nell' evento click dove puoi risalire al valore precedente della combo box (old value), confrontarlo con il valore attualmente modificato e se era già stato impostato SI eseguirai direttamente un Exit Sub per uscire subito dalla Routine.

    Valuta se può essere la soluzione che cercavi e se l'approccio risulta corretto.

    A disposizione per qualsiasi ed ulteriori chiarimenti.
    Fai sapere…  ;-)) 

  • Re: Relazioni database

    09/08/2023 - Stifone ha scritto:


    Il problema principale è la cattiva strutturazione del database:

    • poca Normalizzazione delle tabelle :
      • vedi T_Anagrafiche i campi:
        • Dip-Int
        • inquadramento
        • area
        • Reparto
        • SottoReparto
        • Turni
        • IDMansione
        • ecc…
    • mancata gestione di alcune proprietà fondamentali dei campi:
      • Obbligatorio (se impostato su Sì non consente di salvare il record se non sono stati inseriti i dati richiesti)
      • Consenti lunghezza zero (da impostare su No se i dati sono sempre richiesti)
      • Indicizzato (impostato a "Sì (non sono consentiti duplicati)" quando si vuole che in un campo un valore non venga inserito più di una volta e quindi sia univoco (vedi Matricola)  (se è necessario utilizzare due o più campi per evitare la duplicazione)

    per questo ho postato un file con una minima struttura di esempio

    https://www.dropbox.com/scl/fi/9i5704kh868y262jfak2g/GestionePianoSanitario.zip?rlkey=scj5wositw7e3to71outeikv2&dl=0

    vedi la finestra delle relazioni per avere un'idea più chiara.

    Gentilissimo! Grazie mille lo scarico e controllo. 

    Allora, per quanto riguarda la matricola, pur essendo un dato univoco, avevo pensato quando ho creato che me lo facesse L'id della tabella. Nella gestione del mio database, avevo dato importanza appunto al cuore, ovvero la definizione del piano sanitario, che è data da quel campo IDmansione. 

    Dato che si tratta di un campo multivalore e che è su cui gira tutto, è un cuore con una cardiopatia abbastanza importante :D. 

    Adesso scarico il file che mi hai mandato e do una occhiata, grazie per avermi dedicato del tempo 

  • Re: Relazioni database

    09/08/2023 - Stifone ha scritto:


    Il problema principale è la cattiva strutturazione del database:

    Ciao,

    purtroppo si, sarebbe da rifare da zero… 

    Vabbè ha iniziato adesso e quindi gli servirà come banco di prova, studio e approfondimenti. (la perdoniamo)

    Io per trovare una possibile soluzione ho fatto i salti mortali con giravolta e carpiature…. ;-)

    Non gli ho elencato tutti gli errori perchè ci vorrebbe una giornata intera… come fare un corso ;-))

    Però… che dire, penso che tra di noi ci siam capiti e non servono altre parole…  Lei è consapevole, forse non del tutto, ma già con questa impostazione ha trovato subito un ostacolo che demarca i limiti della progettazione del Db a cui hai accennato.

    Pensa che se cambia per puro caso la descrizione di un Accertamento, va tutto a farsi benedire… non funziona più nulla.

    ….vabbè sono poche settimane che ha iniziato… sicuramente tanta volontà e dedizione da apprezzare.
    Ma lo sappiamo molto bene, per entrare in questi argomenti, database/tabelle/relazioni/chiavi/indici/query/sql/etc etc,  ci vuole tempo ed esperienze da accumulare con un continuo studio.

    ;-)) ma le relazioni con campi descrittivi non se possono fa'  ;-))

  • Re: Relazioni database

    09/08/2023 - Stifone ha scritto:


    https://www.dropbox.com/scl/fi/9i5704kh868y262jfak2g/GestionePianoSanitario.zip?rlkey=scj5wositw7e3to71outeikv2&dl=0

    vedi la finestra delle relazioni per avere un'idea più chiara.

    Ottimo Esempio !!!

  • Re: Relazioni database

    09/08/2023 - By65Franco ha scritto:


    Come accennato in precedenza i tuoi problemi nascono per una errata progettazione del database, tabelle e relazioni. Ma sicuramente migliorerai sotto questo aspetto.

    Riepilogando:

    1. Stai lavorando con campi descrittivi e non con gli Id Chiave e questo ti crea il problema nel reperire la corretta corrispondenza tra Accertamento e Tabella Accertamenti/Anagrafica/etc…
    2. Non ti scombussolo nulla di quello che hai già realizzato e pur sapendo che non va bene ti propongo una soluzione molto criticabile e non ortodossa visto la natura delle colonne definite nelle tabelle e loro relazioni

    Nel particolare:

    • quando crei l'appuntamento non hai una chiave nella combo box accertamenti che tu possa successivamente utilizzare per implementare la tabella Piano Sanitario
    • hai solo una descrizione dell' Accertamento e questo dato in modo ridontante lo porti dietro su altre tabelle (questo non si fa)
    • vista la natura della tabella Appuntamenti e della tabella Piano Sanitario, le due non si legano tramite degli Id ma solo in modo descrittivo (questo non si fa)
    • per andare avanti con questo approccio devi continuare ad utilizzare tali descrizioni (anche questo non si fa)  ;-)
      • da Appuntamenti per passare il record al Piano Sanitario devi simulare ciò che faresti manualmente nel Piano Sanitario
        • per simulare tali inserimenti è necessario reperire le informazioni che ti occorrono passando nuovamente dall'Anagrafica  dalla tabella Rischi e attraverso le Mansioni alla tabella Accertamenti. Per fare questo devi crearti una query (stringa sql nel nostro caso) per poter risalire al Numero Mesi legato a tale accertamento. Per esempio:
    strSql = "SELECT T_Anagrafica.ID, Accertamenti_T.Accertamenti, Accertamenti_T.Periodicità " & _
             "FROM (T_Rischio INNER JOIN T_Anagrafica ON T_Rischio.ID = T_Anagrafica.IDMansione.Value) INNER JOIN Accertamenti_T ON T_Rischio.ID = Accertamenti_T.IDRischio " & _
             "WHERE T_Anagrafica.ID=" & Me.IDAnagrafica & " AND Accertamenti_T.Accertamenti='" & Me.Accertamento & "';"
    • se va a buon fine tale istruzione sql, otterrai il Numero Mesi che dovrai controllare se per quel Tipo di Accertamento è ammasso dal quell'Id Anagrafica… pertanto se non esiste tale legame il Numero Mesi sarà = 0
      • questa ipotesi devi intercettarla e gestire il da farsi. Per Esempio:
    If intMesi = 0 Then
        MsgBox "Type of assessment not foreseen", vbCritical, "Error"
        Me.Eseguito = "NO"
        Exit Sub
    End If
    • se invece il Tipo di Accertamento è legato a quella Anagrafica, allora puoi procedere all'inserimento del nuovo record nel Piano Sanitari. Il mio approccio è quello che ti presentavo nei post precedenti utilizzando l'Execute di DBEngine (sempre di Dao si parla, vedi documentazione che ti avevo passato). Pertanto dovrai controllare di avere tutte le informazioni e che siano corrette per procedere all'inserimento del record. Per esempio una traccia sarà di questo tipo:
    ' insert new records in the PianoSanitarioT table
    DBEngine(0)(0).Execute "INSERT INTO PianoSanitarioT (IdAnagrafica, Accertamenti, Periodicità, DataUltima, ProssimaVisita) " & _
                           "VALUES (" & _
                           Me.IDAnagrafica & ", '" & _
                           Me.Accertamento & "', " & _
                           intMesi & ", " & _
                           CStr(CLng(Me.SelData)) & ", " & _
                           CStr(CLng(DateAdd("m", intMesi, Me.SelData))) & ");"
    • dovranno essere anche eseguiti dei controlli preliminari prima di procedere. A tal fine ti lascio un esempio di questo tipo:
    Private Sub Eseguito_Click()
    ' check only selected = "SI"
    If Me.Eseguito = "NO" Then Exit Sub
    ' confirm message
    If MsgBox("Confirming the inclusion in the Health Plan?", vbExclamation + vbYesNo, "Confirm") = vbNo Then
        Me.Eseguito = "NO"
        Exit Sub
    End If
    • Come giustamente avevi segnalato userai la ComboBox  Eseguito 
      • una correzione che dovrai fare è quella di impostare il valore di Default per tale colonna della tabella e la imposterai con il valore “NO” altrimenti hai un valore null che a tale scopo non ti serve. Quindi i valori possibili saranno esclusivamente NO oppure SI
      • Per esempio su evento Click della combo box puoi creare "Routine Evento" e da codice Vba ti ritrovi la Sub dove inserire i tuoi controlli e esecuzione dell'Inserimento new record
      • Se sulla combo box scegli NO allora non esegui il codice e esci subito dalla Routine
      • Se hai scelto SI puoi per esempio far apparire un messaggio di conferma se si vuole effettivamente passare le informazioni al Piano Sanitario
        • se al messaggio di conferma selezioni NO allora devi impostare a NO la combo box Esegito e esci direttamente dalla Routine

    Se adesso provi a mettere insieme questi passsaggi otterrai una cosa di questo tipo:

    Esempio:

    ' INSERT PIANO SANITARIO
    Private Sub Eseguito_Click()
    ' check only selected = "SI"
    If Me.Eseguito = "NO" Then Exit Sub
    ' confirm message
    If MsgBox("Confirming the inclusion in the Health Plan?", vbExclamation + vbYesNo, "Confirm") = vbNo Then
        Me.Eseguito = "NO"
        Exit Sub
    End If
    
    ' set sql string
    Dim strSql As String
    strSql = "SELECT T_Anagrafica.ID, Accertamenti_T.Accertamenti, Accertamenti_T.Periodicità " & _
             "FROM (T_Rischio INNER JOIN T_Anagrafica ON T_Rischio.ID = T_Anagrafica.IDMansione.Value) INNER JOIN Accertamenti_T ON T_Rischio.ID = Accertamenti_T.IDRischio " & _
             "WHERE T_Anagrafica.ID=" & Me.IDAnagrafica & " AND Accertamenti_T.Accertamenti='" & Me.Accertamento & "';"
    ' open recordset
    Dim rs As DAO.Recordset
    Set rs = DBEngine(0)(0).OpenRecordset(strSql, dbOpenSnapshot)
    ' if exist - value save
    Dim intMesi As Integer
    If Not rs.EOF Then intMesi = rs.Fields("Accertamenti_T.Periodicità").Value Else intMesi = 0
    ' close
    rs.Close
    Set rs = Nothing
    
    ' check Accertmento type
    If intMesi = 0 Then
        MsgBox "Type of assessment not foreseen", vbCritical, "Error"
        Me.Eseguito = "NO"
        Exit Sub
    End If
    
    ' insert new records in the PianoSanitarioT table
    DBEngine(0)(0).Execute "INSERT INTO PianoSanitarioT (IdAnagrafica, Accertamenti, Periodicità, DataUltima, ProssimaVisita) " & _
                           "VALUES (" & _
                           Me.IDAnagrafica & ", '" & _
                           Me.Accertamento & "', " & _
                           intMesi & ", " & _
                           CStr(CLng(Me.SelData)) & ", " & _
                           CStr(CLng(DateAdd("m", intMesi, Me.SelData))) & ");"
    End Sub
    

    Se noti possiamo utilizzare lo stesso metodo, DBEngine per aprire un recordset della Query di cui si parlava all'inizio, quella che permetterà di risalire ai mesi di quell'Accertamento per quella Mazione di quel Rischio legato all'Anagrafica dove hai aperto un appuntamento da accodare al Piano Sanitario.

    E' solo una traccia in quanto non sappiamo se e come vorrai agire in caso di ripetuti invii al Piano Sanitario dello stesso Appuntamento… qui dovrai decider,  per esempio se quell'Appuntamento viene Eseguito (combo box Eseguito = SI) , potresti bloccare la ComboBox in modo che non possa più essere scelto un valore diverso. Quindi una volta Impostato Eseguito = SI a quel punto blocchi o la combobox oppure inserisci un ulteriore controllo nell' evento click dove puoi risalire al valore precedente della combo box (old value), confrontarlo con il valore attualmente modificato e se era già stato impostato SI eseguirai direttamente un Exit Sub per uscire subito dalla Routine.

    Valuta se può essere la soluzione che cercavi e se l'approccio risulta corretto.

    A disposizione per qualsiasi ed ulteriori chiarimenti.
    Fai sapere…  ;-)) 

    Super! 

    Grazie mille, ho letto tutto e domani mi metto a studiare tutto quello che mi hai girato. E lo faccio funzionare con le indicazioni 

    Però volevo fare una domanda sulla progettazione, se dovessi creare un programma parallelo, questa volta, come mi stai consigliando, ho avuto questo problema che magari se avessi conosciuto il forum prima avrei risparmiato guai :) 

    Praticamente, ogni dipendente ha un rischio, che viene definita dalla manzione (praticamente è il campo multi IDmanzione) da cui parte il piano sanitario. 

    Perciò es. 

    Io dipendente lavoro al 50% su officina mecanica e 50% in ufficio (sono i valori che vengono definiti dalla tabella rischio e caricato nella maschera sorveglianza sanitaria) 

    Questo, che può sembrare una caz..ta, ma non riuscivo a individuare la relazione giusta per poter far saltar fuori gli accertamenti (che è la globalizzazione di tutti i rischi possibili delle varie mansioni svolte da un dipendente , con la minima tempistica, ovvero, se una mansione prevede la visita optometrica a 24 mesi e l'altra a 12 mesi, nel piano sanitario mi deve riportare che la visita optometrica la dovrà fare a 12 mesi) 

    In questo caso, se mi posso approfittare ancora della tua esperienza, come potrei ripartire da zero? 

    Io avevo trovato la risposta nel multifunzione, ma mi ha riportato tutta la carrellata di errori e errorini che mi hai fatto notare 

  • Re: Relazioni database

    09/08/2023 - By65Franco ha scritto:


    09/08/2023 - Stifone ha scritto:


    Il problema principale è la cattiva strutturazione del database:

    Ciao,

    purtroppo si, sarebbe da rifare da zero… 

    Vabbè ha iniziato adesso e quindi gli servirà come banco di prova, studio e approfondimenti. (la perdoniamo)

    Io per trovare una possibile soluzione ho fatto i salti mortali con giravolta e carpiature…. ;-)

    Non gli ho elencato tutti gli errori perchè ci vorrebbe una giornata intera… come fare un corso ;-))

    Però… che dire, penso che tra di noi ci siam capiti e non servono altre parole…  Lei è consapevole, forse non del tutto, ma già con questa impostazione ha trovato subito un ostacolo che demarca i limiti della progettazione del Db a cui hai accennato.

    Pensa che se cambia per puro caso la descrizione di un Accertamento, va tutto a farsi benedire… non funziona più nulla.

    ….vabbè sono poche settimane che ha iniziato… sicuramente tanta volontà e dedizione da apprezzare.
    Ma lo sappiamo molto bene, per entrare in questi argomenti, database/tabelle/relazioni/chiavi/indici/query/sql/etc etc,  ci vuole tempo ed esperienze da accumulare con un continuo studio.

    ;-)) ma le relazioni con campi descrittivi non se possono fa'  ;-))

    Si, perdonatemi!! Hhhahaha io ce la sto mettendo tutta davvero… Dal nulla a quello che ho fatto senza mai fare un corso seguendo i tutorial da YouTube 

  • Re: Relazioni database

    09/08/2023 - Stifone ha scritto:


    Il problema principale è la cattiva strutturazione del database:

    • poca Normalizzazione delle tabelle :
      • vedi T_Anagrafiche i campi:
        • Dip-Int
        • inquadramento
        • area
        • Reparto
        • SottoReparto
        • Turni
        • IDMansione
        • ecc…
    • mancata gestione di alcune proprietà fondamentali dei campi:
      • Obbligatorio (se impostato su Sì non consente di salvare il record se non sono stati inseriti i dati richiesti)
      • Consenti lunghezza zero (da impostare su No se i dati sono sempre richiesti)
      • Indicizzato (impostato a "Sì (non sono consentiti duplicati)" quando si vuole che in un campo un valore non venga inserito più di una volta e quindi sia univoco (vedi Matricola)  (se è necessario utilizzare due o più campi per evitare la duplicazione)

    per questo ho postato un file con una minima struttura di esempio

    https://www.dropbox.com/scl/fi/9i5704kh868y262jfak2g/GestionePianoSanitario.zip?rlkey=scj5wositw7e3to71outeikv2&dl=0

    vedi la finestra delle relazioni per avere un'idea più chiara.

    Lo devo aprire dal mio pc al lavoro, domani controllo perché non ho access su mio pc personale 

  • Re: Relazioni database

    10/08/2023 - Pattygirl ha scritto:


    Io avevo trovato la risposta nel multifunzione, ma mi ha riportato tutta la carrellata di errori e errorini che mi hai fatto notare

    Di primo acchito mi verrebbe da pensare di costruire degli algoritmi che via via mixati tra di loro possano coprire tutta la casistica.

    Direi che parallelamente con un altro progetto potresti seguire come prima cosa i consigli di Stifone per progettare bene il database. Prima di procedere però, come in questo caso che hai segnalato, dovresti cercare di mettere sul tavolo tutte le varie necessità in modo da non rimettere nuovamente in discussione l'intero progetto

    Pertanto come prima cosa devi realizzare un analisi completa ed esaustiva
    Come seconda cosa progettare il database che terrà conto dell'analisi con tutte le sfaccettature e necessità evidenziate
    A quel punto passi alla realizzazione.

    Ma un analisi fatta bene e completa il più possibile, ti porta ad avere il 99% del progetto già eseguito…. il resto è solo una formalità dove utilizzerai i vari oggetti messi a disposizione dall'ambiente Access. 

    La Programmazione, il Vba, etc… sono importanti ma senza una analisi ben fatta, risultano essere degli strumenti del tutto inutili.

    Comunque segui la traccia di Stifone … è un ottimo punto di partenza. Fai una Analisi il più dettagliata e completa possibile. E solo alla fine apri Access e inizi a programmare.

    Secondo me ce la fai alla grande, sei brava nel dedicarti a questi argomenti.

    10/08/2023 - Pattygirl ha scritto:


    Si, perdonatemi!! Hhhahaha io ce la sto mettendo tutta davvero… Dal nulla a quello che ho fatto senza mai fare un corso seguendo i tutorial da YouTube 

    Secondo me non c'è nulla da perdonare fatta eccezione della relazione tra tabelle con colonne descrittive ;-))  (non se fa)
    Ma traspare tanto impegno e questo ti fa onore al di là degli errori… quindi per me sei perdonata alla grande. ;-D

    Alcuni consigli:

    • usare sempre Option Explicit nel Vba … quindi all'inizio di ogni modulo usa sempre questo metodo:
    Option Compare Database
    Option Explicit
    • eseguire sempre la compilazione da Debug una volta impostato Option Explicit. ti segnalerà gli eventuali errori di sintassi o di utilizzo con parametri errati o mancanti delle funtion e delle istruzioni che userai.  Poi quando la compilazione non ti restituisce errore allora avvii il programma.

    • commentare sempre il codice che scrivi e di non lasciare in giro routine Sub o Funtion che non utilizzi
    • usare le funzioni già esistenti per eseguire i calcoli sulle date… mi ero dimenticato di documentarlo nel post precedente: usare per esempio il DateAdd("m", intMesi, Me.SelData) pe aggiungere un certo numero di mesi ad una data DateAdd function (Visual Basic for Applications) | Microsoft Learn … ma quando calcoli la data prossimo accertamento dovrai anche controllare che non sia un giorno festivo?  mica gli vorrai far fare una visita di domenica oppure il giorno di Pasqua, di Ferragosto, di Natale o di Capodanno etc… ;-)  Come ti dicevo prima, una analisi ben fatta vuol dire aver già realizzato il 99% del progetto. 
    • in ultimo ti consiglio di non usare le macro… le odio !!!  ;-)) , se poi hai bisogno di mettere sotto debug il programma per intercettare possibili errori e quant'altro, con le maledette macro non cavi un ragno dal buco.

    Insomma ….  solo piccoli consigli pratici ;))

  • Re: Relazioni database

    10/08/2023 - By65Franco ha scritto:


    10/08/2023 - Pattygirl ha scritto:


    Io avevo trovato la risposta nel multifunzione, ma mi ha riportato tutta la carrellata di errori e errorini che mi hai fatto notare

    Di primo acchito mi verrebbe da pensare di costruire degli algoritmi che via via mixati tra di loro possano coprire tutta la casistica.

    Direi che parallelamente con un altro progetto potresti seguire come prima cosa i consigli di Stifone per progettare bene il database. Prima di procedere però, come in questo caso che hai segnalato, dovresti cercare di mettere sul tavolo tutte le varie necessità in modo da non rimettere nuovamente in discussione l'intero progetto

    Pertanto come prima cosa devi realizzare un analisi completa ed esaustiva
    Come seconda cosa progettare il database che terrà conto dell'analisi con tutte le sfaccettature e necessità evidenziate
    A quel punto passi alla realizzazione.

    Ma un analisi fatta bene e completa il più possibile, ti porta ad avere il 99% del progetto già eseguito…. il resto è solo una formalità dove utilizzerai i vari oggetti messi a disposizione dall'ambiente Access. 

    La Programmazione, il Vba, etc… sono importanti ma senza una analisi ben fatta, risultano essere degli strumenti del tutto inutili.

    Comunque segui la traccia di Stifone … è un ottimo punto di partenza. Fai una Analisi il più dettagliata e completa possibile. E solo alla fine apri Access e inizi a programmare.

    Secondo me ce la fai alla grande, sei brava nel dedicarti a questi argomenti.

    10/08/2023 - Pattygirl ha scritto:


    Si, perdonatemi!! Hhhahaha io ce la sto mettendo tutta davvero… Dal nulla a quello che ho fatto senza mai fare un corso seguendo i tutorial da YouTube 

    Secondo me non c'è nulla da perdonare fatta eccezione della relazione tra tabelle con colonne descrittive ;-))  (non se fa)
    Ma traspare tanto impegno e questo ti fa onore al di là degli errori… quindi per me sei perdonata alla grande. ;-D

    Alcuni consigli:

    • usare sempre Option Explicit nel Vba … quindi all'inizio di ogni modulo usa sempre questo metodo:
    Option Compare Database
    Option Explicit
    • eseguire sempre la compilazione da Debug una volta impostato Option Explicit. ti segnalerà gli eventuali errori di sintassi o di utilizzo con parametri errati o mancanti delle funtion e delle istruzioni che userai.  Poi quando la compilazione non ti restituisce errore allora avvii il programma.

    • commentare sempre il codice che scrivi e di non lasciare in giro routine Sub o Funtion che non utilizzi
    • usare le funzioni già esistenti per eseguire i calcoli sulle date… mi ero dimenticato di documentarlo nel post precedente: usare per esempio il DateAdd("m", intMesi, Me.SelData) pe aggiungere un certo numero di mesi ad una data DateAdd function (Visual Basic for Applications) | Microsoft Learn … ma quando calcoli la data prossimo accertamento dovrai anche controllare che non sia un giorno festivo?  mica gli vorrai far fare una visita di domenica oppure il giorno di Pasqua, di Ferragosto, di Natale o di Capodanno etc… ;-)  Come ti dicevo prima, una analisi ben fatta vuol dire aver già realizzato il 99% del progetto. 
    • in ultimo ti consiglio di non usare le macro… le odio !!!  ;-)) , se poi hai bisogno di mettere sotto debug il programma per intercettare possibili errori e quant'altro, con le maledette macro non cavi un ragno dal buco.

    Insomma ….  solo piccoli consigli pratici ;))

    Altro che consigli, sto facendo scuola :))) 

    Domani, apro la traccia che mi ha gentilmente preparata @Stifoni, perché dal pc del lavoro ho bloccato Dropbox e su mio pc personale non ho Access, allora ho già scaricato e domani al lavoro mi dedico a studiare tutto il quanto. 

    Intanto vi auguro a tutti un serena notte e ringrazio a tutti i quanti per questi preziosi consigli 

Devi accedere o registrarti per scrivere nel forum
23 risposte