Da notare che il mio esempio, conteneva una semplice ma efficace logica, appunto per il discorso dell multivariazioni.
In fondo, il problema qual'è?
Io ho un dato consolidato nel database che voglio modificare, apro la form di modifica, mi imposto i valori nei controlli e li imposto anche nei rispettivi Tag, in modo da avere come riferimento il dato contenuto nel database. Durante l'editing, puoi fare tutte le modifiche che vuoi, ma il Tag rimane nello stato originario; alla chiusura, non fai altro che confrontare il valore del controllo con il valore del Tag, e il gioco è fatto! Qualsiasi modifica avvenuta nel tempo, dall'apertura, fino alla chiusura dell'editing, non ha alcuna importanza; alla fine confronti tutto e sei a posto.
Unico neo di questo discorso, che comunque non è oggetto di discussione, è la gestione della multiutenza, ovvero quella logica che dice che, mentre tu modifichi un dato caricato da una tabella, e qualcun'altro te lo varia da un'altra applicazione, il contenuto del Tag se ne và a farsi benedire... In questo caso, la cosa si complica, costringendo il programmatore, se ne ha necessità, di operare delle richieste in backgroung, verificando che i dati originari non siano stati variati nel frattempo, ed effettuando un'aggiornamento dei Tag se qualcosa è cambiato.
Il concetto che ho descritto in parole molto povere, è un'indicazione di massima di cosa può accadere in questi casi, ma ci sono ulteriori implicazioni che possono complicare ulteriormente il discorso.
Comunque non mi sembra questa la discussione adatta...
Un'altra idea che mi è venuta mentre scrivo questa risposta, è la possibilità di analizzare il database prima di salvare direttamente le tue modifiche, analizzando se è il caso di farlo o meno, e magari decidere pure se aggiornare i soli campi modificati...
