Pulsante annulla

di il
41 risposte

41 Risposte - Pagina 3

  • Re: Pulsante annulla

    01/03/2024 - max.riservo ha scritto:


    le società cambiano con una frequenza sicuramente maggiore il CF (magari mantenendo la stessa P.IVA). Se una ditta cambia CF ma NON PIva, fiscalmente rimane la stessa azienda … e questo cambio può avvenire in qualsiasi momento dell'anno fiscal

    Cf <> p.iva solo se si tratta di ditta individuale nel caso di società cf = p.iva.

    Sostanzialmente è cosa buona separare i dati (che posso trascrivere male o che possono cambiare nel tempo) da ciò che serve per la struttura del database (che impongo io da programma) così se domani mi chiama il sig. Cf 123 dicendomi che c'è un errore e che il cf è 456 per me il sig 123 id 1 sarà= al sig. 456 id 1.

    E non mi pronuncio in caso di transgender… da m a f o viceversa dovrebbe cambiare il cf anche per non violare la privacy del transgender… mi informerò intanto cambiano padre e madre con genitore1 e genitore2.

    Il succo del discorso (ot) è che per il funzionamento del database uso dati di cui io e solo io decido che non possono mai cambiare.

  • Re: Pulsante annulla

    01/03/2024 - sihsandrea ha scritto:


    01/03/2024 - max.riservo ha scritto:


    le società cambiano con una frequenza sicuramente maggiore il CF (magari mantenendo la stessa P.IVA). Se una ditta cambia CF ma NON PIva, fiscalmente rimane la stessa azienda … e questo cambio può avvenire in qualsiasi momento dell'anno fiscal

    Cf <> p.iva solo se si tratta di ditta individuale nel caso di società cf = p.iva.

    Andrea, fidati che è come ho scritto io ovvero esistono ditte (aziende/società non ditte individuali) che hanno il CF (numerico) diverso dalla PIva.

    Caso tipico : azienda che fa parte di un gruppo. La capogruppo ha PIva e CF uguali l'azienda che fa parte del gruppo ha la stessa PIva della capogruppo ma ha un CF diverso (che in genere è il CF che aveva prima di entrare a far parte del gruppo). E io ci lavoro quotidianamente con alcune aziende con questo assetto societario.

    Se PIva e CF fossero sempre uguali (per le aziende) che senso avrebbe lo stesso dato ?

  • Re: Pulsante annulla

    01/03/2024 - Antony73 ha scritto:


    01/03/2024 - max.riservo ha scritto:


    Il campo autoincrement aggiunge lo svantaggio che per ottenere la chiave occorre fare prima l'inserimento (svantaggio ampiamente gestito dal DBMS quindi non preoccupante).

    Questo è chiaro. Ma perché dici che questo può essere uno svantaggio?

    E' uno svantaggio quanto ti farebbe comodo avere la chiave primaria in anticipo.

    Situazione A :

    Struttura Master/Detail, vuoi copiare (cambiando solo la chiave primaria della tabella master) il record della tabella master e tutti i record ad esso legati nella tabella detail.

    In questo caso inserisci il record nella tabella master, ricevi dal DBMS la nuova chiave e poi fai la copia con una unica istruzione sql dei record detail. La copia avviene, anche per garantire l'integrità referenziale, a livello ‘orizzontale’ (ovvero prima il master e poi tutto il detail). In questa situazione conoscere in anticipo la chiave non ti cambia la vita.

    Situazione B :

    Aggiungi un livello alla struttura Master/Detail (ovvero un terza tabella legata alla tabella detail).

    In questo caso per effettuare la copia dell'intera 'struttura gerarchica' devi inserire il record master, inserire ogni singolo record detail (per ottenere la nuova chiave autoincrement) e poi per ogni singolo record detail copiare i record della terza tabella. In questa situazione, se tu avessi una chiave concatenata (composta semplificando da AABBCC dove AA è la chiave della tabella master, AABB è la chiave della tabella detail e AABBCC è la chiave della terza tabella) potresti continuare ad effettuare un copia a livello 'orizzontale' (prima il master, poi tutto il detail e poi la terza tabella) semplicemente sostituendo il valore di AA in tutte e 3 le tabelle.

    Quanto è frequente questa situazione? Credo non molto, però quando non esisteva il campo autoincrement (e così era nell'ambiente che frequentavo molti anni fa) in qualche modo si doveva pur fare.Se poi qualcuno offre un approccio diverso per la situazione B (con campi autoincrement) tanto meglio, avrò imparato qualcosa in più.

  • Re: Pulsante annulla

    01/03/2024 - max.riservo ha scritto:


    01/03/2024 - Antony73 ha scritto:


    A parte questo, operare con chiavi primarie ad auto incremento offre una maggiore efficienza nelle operazioni con le tabelle.

    Se hai la possibilità di avere una chiave univoca il beneficio del campo autoincrement si riduce al mero risparmio di spazio di archiviazione (se consideriamo i volumi di archiviazione di Access direi che alla fine il risparmio di spazio non incide in maniera così pesante).

    Il campo autoincrement aggiunge lo svantaggio che per ottenere la chiave occorre fare prima l'inserimento (svantaggio ampiamente gestito dal DBMS quindi non preoccupante).

    In merito alla scelta del CF come chiave primaria : 

    • è una chiave univoca ma NON puoi calcolarla con certezza. L'unico ente preposto a calcolare correttamente al 100% è l'ADE (Agenzia Entrate)
    • si tratta di una codice che viene utilizzato per gestire 3 ‘entità’ differenti, le persone fisiche (quindi codice alfanumerico a 16 caratteri) i liberi professionisti (alfanumerico come le PF ma in accoppiata con la partita IVA) oppure le società  con codice numerico a 11 cifre in abbinamento alla partita IVA (può coincidere con la P.IVA o può essere differente a seconda dell'assetto societario)
    • esistono casi,ancorché poco frequenti, che delle persone fisiche cambino (o siano costrette a cambiare) codice fiscale
    • le società cambiano con una frequenza sicuramente maggiore il CF (magari mantenendo la stessa P.IVA). Se una ditta cambia CF ma NON PIva, fiscalmente rimane la stessa azienda … e questo cambio può avvenire in qualsiasi momento dell'anno fiscale

    Valutando le particolarità del CF io non lo utilizzerei come PK in ambito di gestione di anagrafiche di aziende, per gestione di anagrafiche SOLO di persone fisiche potrei prenderlo in considerazione ma probabilmente utilizzerei altro (magari un autoincrement).

    Il mio caso è un caso molto particolare, tratta cf non di persone fisiche e nemmeno di aziende, sono enti senza scopo di lucro tipo associazioni culturali, per arrivare nel mio database devono essere già in possesso di cf che resterà invariato per tutta la vita dell'ente, per questo mi sono permessa di utilizzarlo.

    Detto ciò, ci siamo addentrati su questo aspetto mettendo da parte l'argomento principale del mio problema, ovvero come evitare il salvataggio automatico delle modifiche dei dati nella maschera.

    Mi hanno suggerito di usare il comando cancelUpdate, lunedì in ufficio studierò bene tutto per capire come applicarlo al mio codice

  • Re: Pulsante annulla

    02/03/2024 - fogliolina ha scritto:

    Detto ciò, ci siamo addentrati su questo aspetto mettendo da parte l'argomento principale del mio problema, ovvero come evitare il salvataggio automatico delle modifiche dei dati nella maschera.

    Concordo ….

    Tornando al tuo problema : 

    • se hai salvato il record non puoi ovviamente tornare indietro
    • se il record è in modifica (quindi non ancora salvato) puoi annullare le modifiche ai campi come ti ha suggerito Alex (Cancel = true nell'evento beforeUpdate)
    • oppure il tuo pulsante annulla potrebbe eseguire il seguente codice :
        Me.Undo
        
        DoCmd.Close acForm, Me.Name
  • Re: Pulsante annulla

    02/03/2024 - fogliolina ha scritto:


    Mi hanno suggerito di usare il comando cancelUpdate, lunedì in ufficio studierò bene tutto per capire come applicarlo al mio codice

    Il cancelupdate puoi usarlo quando hai una modifica pendente su un recordset … è da verificare se riesci ad usarlo sul recordset associato al form.

  • Re: Pulsante annulla

    02/03/2024 - max.riservo ha scritto:


    … è da verificare se riesci ad usarlo sul recordset associato al form.

    Ho fatto una prova veloce : se non fai un addnew o un edit esplicito il cancelupdate genera errore, quindi credo che non sia applicabile al recordset associato al form…

  • Re: Pulsante annulla

    02/03/2024 - max.riservo ha scritto:


    se il record è in modifica (quindi non ancora salvato) puoi annullare le modifiche ai campi come ti ha suggerito Alex (Cancel = true nell'evento beforeUpdate)

    Quindi appena lancio il comando update interviene l'evento beforeupdate e mi annulla l'inserimento? 

    Deve metterlo alla chiusura del form.

    Quale sia sia il criterio che usi per l'id.

  • Re: Pulsante annulla

    02/03/2024 - max.riservo ha scritto:


    02/03/2024 - max.riservo ha scritto:


    … è da verificare se riesci ad usarlo sul recordset associato al form.

    Ho fatto una prova veloce : se non fai un addnew o un edit esplicito il cancelupdate genera errore, quindi credo che non sia applicabile al recordset associato al form…

    Era il dubbio che avevo, ovvero che cancelupdate non funzionasse nel mio caso.

    Undo l'avevo provato ma non funzionava

    L'unico escamotage che avevo trovato è quello che ho scritto in uno dei primi post, ho riportato proprio il codice, ovvero prendo il record dalla tabella il cui codice fiscale corrisponde a quello inserito e assegno i valori dei campi della tabella ai campi della form. Sarà brutta e brutale come soluzione ma non ho trovato altro di meglio

  • Re: Pulsante annulla

    02/03/2024 - fogliolina ha scritto:

    Undo l'avevo provato ma non funzionava

    Sinceramente non so come hai fatto le prove ….

    Io ho fatto questa prova veloce :

    • creazione guidata maschera che utilizza una tabella con 3 campi
    • reso non editabile il campo chiave
    • aggiunto 2 pulsanti (Abort e Prosegui)
    • disattivato selettore record e pulsanti spostamento dalla maschera
    • aggiunto queste righe di codice sui 2 pulsanti :
    
    Private Sub Cmd_Abort_Click()
        Me.Undo
        
        DoCmd.Close acForm, Me.Name
    End Sub
    
    Private Sub Cmd_Prosegui_Click()
        DoCmd.Close acForm, Me.Name
    End Sub

    Avvio il form che si apre sul primo record disponibile :

    • modifico a piacimento i 2 campi
    • se premo su Abort il form si chiude e il record risulta NON cambiato
    • se premo su Prosegui il form si chiude e il record risulta aggiornato
    • se premo sul segno X (chiudi) il form si chiude e il record risulta aggiornato (posso comunque intercettare l'evento Unload del form per decidere cosa fare, posso disattivare il pulsante X)

    A questo punto io non ho altri suggerimenti …

    Se ancora non risolvi scrivi dettagliatamente cosa hai costruito e come l'hai provato e magari qualcuno più pratico ti saprà consigliare.

  • Re: Pulsante annulla

    Il codice fiscale delle associazioni, soprattutto di volontariato o senza scopo di lucro, cambia molto più spesso di quello delle persone fisiche, soprattutto con ,l'obbligatorietà della trasformazione ed il passaggio al terzo settore di questa tipologia di associazioni.

    La stessa agenzia delle entrate in alcune circolari si è lamentata del fatto che molte associazioni sono in ritardo di 15 anni nell'aggiornamento della loro posizione fiscale  e di attribuzione di nuovo codice ateco e di codice fiscale. Sottolienando tra parentesi che c'è molta disinformazione anche da parte dei consulenti e commercialisti.

    L'unico modo per controllare al 100 percento l'annullamento di modifiche è quello di escludere completamente access nella gestione automatica del record, usando una maschera e dei controlli non associati e gestire manualmente tramite vba, il caricamento dei dati, la modifica ed il salvataggio.

    E si fa usando tre eventi principali.

    Il change, il before update ed il form unload.

    Il change per controllare se un campo è stato modificato.

    Il beforeupdate per impedire il salvataggio

    ed il formunload per gestire la chiusura con la x.

    Ogni altra casistica dove access possa metterci lo zampino in automatico, implica la gestione di una serie di eventi e casistiche che potrebbero non essere considerate in fase di progettazione.

    Ora noi stiamo considerando azioni normali, ma se ad esempio il database va in crash e si riavvia, access, salva in automatico tutto escludendo gli eventi della maschera, quindi  ci potremmo ritrovare con il campo modificato salvato. Cosa che invece non avviene se si usa la modalità manuale completa, visto che il codice vb non verrebbe eseguito e quindi il record salvato.
    Stesso discorso per un eventuale gestione multiutente e per azioni inconsulte di utilizzatori distratti, che riescono sempre a compiere azioni e generare errori,  che ad un progrrammatore non verrebbero in mente nemmeno dopo 10 anni di progettazione.

  • Re: Pulsante annulla

    02/03/2024 - max.riservo ha scritto:


    02/03/2024 - fogliolina ha scritto:

    Undo l'avevo provato ma non funzionava

    Sinceramente non so come hai fatto le prove ….

    Io ho fatto questa prova veloce :

    • creazione guidata maschera che utilizza una tabella con 3 campi
    • reso non editabile il campo chiave
    • aggiunto 2 pulsanti (Abort e Prosegui)
    • disattivato selettore record e pulsanti spostamento dalla maschera
    • aggiunto queste righe di codice sui 2 pulsanti :
    
    Private Sub Cmd_Abort_Click()
        Me.Undo
        
        DoCmd.Close acForm, Me.Name
    End Sub
    
    Private Sub Cmd_Prosegui_Click()
        DoCmd.Close acForm, Me.Name
    End Sub

    Avvio il form che si apre sul primo record disponibile :

    • modifico a piacimento i 2 campi
    • se premo su Abort il form si chiude e il record risulta NON cambiato
    • se premo su Prosegui il form si chiude e il record risulta aggiornato
    • se premo sul segno X (chiudi) il form si chiude e il record risulta aggiornato (posso comunque intercettare l'evento Unload del form per decidere cosa fare, posso disattivare il pulsante X)

    A questo punto io non ho altri suggerimenti …

    Se ancora non risolvi scrivi dettagliatamente cosa hai costruito e come l'hai provato e magari qualcuno più pratico ti saprà consigliare.

    Undo che avevo provato io non era così. Ho creato una macro nella quale avevo selezionato tra le azioni “annulla record”, seguito dall'azione chiudi per la maschera corrente e apri per la maschera principale. ho assegnato la macro al pulsante e ho convertito in vb per avere il codice vb e poterlo modificare per altre cose.  Quindi il codice del pulsante annulla era questo

    Private Sub pulsanteAnnullaModificaDatiEnte_Click()

       DoCmd.RunCommand acCmdUndo
       DoCmd.Close acForm, "maschera_modifica_dati_ente"
       DoCmd.OpenForm "maschera_principale", acNormal, "", "", , acNormal

    End Sub

    Ora ho provato a inserire invece Me.Undo e funziona. 

    Grazie mille

Devi accedere o registrarti per scrivere nel forum
41 risposte