Newsgroup: it.comp.appl.access
Titolo: dirty...

Qualcuno mi sa dire come posso memorizzare in un campo memo solo i campi di
una Form che hanno subito delle modifiche ai dati.
Fino all'utilizzo della proprietą Dirty ci sono arrivato, ma da li in poi
proprio le ho tentate tutte.....   :o(((
Grazie
Luca

 ha scritto nel messaggio
news:wcaob.79455$e6.28...@twister2.libero.it...

Cosa devi ottenere....???
Forse se spieghi il fine ultimo....!
Se la tua intenzione e quella di tener traccia, io ti consiglierei
di creare un File.Txt e poi Linkarlo come fosse una fonte esterna
o Tabella Collegata.
@Alex.

 ha scritto nel messaggio
news:bnrigu$hnq$1...@lacerta.tiscalinet.it...

Si vorrei, come dici giustamente tu, tenere traccia solo del nome dei campi
modificati con i relativi dati aggiunti.
Fondamentalmente lo scopo č quello di avere uno storico dei soli campi
modificati.
Gią ora riesco ad accodare in un'altra tabella i record presenti in una
maschera, ma dato che nella tabella di origine vi sono tanti campi, diventa
piuttosto faticoso individuare quale campo ha subito una variazione nei
dati.
Grazie
Luca

 Luca
Innanzitutto non va bene la proprietà o l'Evento Dirty....., poichè sono
riferiti alla Form e non ai controlli associati.
E visto che devi tener traccia delle modifiche dei singoli Campi associati
ai controlli io ti consiglierei di sfruttare l'Evento DopoAggiornamento
di ogni singolo Controllo.
Puoi fare una Funzione Generale in un Modulo in cui trasterisci il Nome
del Controllo e magari della Maschera, in questo modo capisci su quali dati
l'utente stava lavorando....!
Poi ti cinsiglio di sfruttare il Modulo di Classe che trovi sul SitoComune
per generare un File di LOG e dalla Funzione Public spedisci al ClsLog
i dati per aggiungere una Riga al File esistente.
Se fai in modo di strutturare il File correttamente poi puoi Lincarlo e
farlo
diventare l'Origine Record di una Form in Visualizzazione Continua, ogni
Riga del File sarà una Riga della Form.
Per semplicità io la farei MonoCampo, ma nulla ti vieta di migliorarla nel
tempo e strutturare il File in modo da essere letto come Tabella vera e
propria.
Ciao.
@Alex.

 Ti ringrazio per i consigli, stasera provo il tutto, poi semmai mi faccio
vivo.
Ciao.
Luca.

 Luca
Io non ho mai provato a fare un log delle modifiche a livello di campo,
quindi non ti so indicare una soluzione certa, però mi è venuta un'idea,
se vuoi la provi e se funziona ci avvisi.
Sull'evento BeforeUpdate della form (quindi quando hai già modificato i
campi ma PRIMA che le modifiche siano salvate in tabella) controlli la
proprietà dirty e se è True (quindi ci sono state delle modifiche), apri
un recordset di un unico record sulla stessa origine dati della form e
confronti uno per uno i valori dei controlli della form con quelli
contenuti nel recordset (che, essendo all'interno della sub BeforeUpdate,
non saranno ancora stati aggiornati). Così dovresti riuscire a capire
quali campi sono cambiati, e a scriverli su un file o in un'altra tabella.
Namor
-- 
 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 ha scritto nel messaggio
news:wcaob.79455$e6.28...@twister2.libero.it...

1) inserisci nella proprieta' -tag- dei controlli che vuoi analizzare un
carattere ad es.: "@"
2) nell'evento before update inserisci:
    for i=1 to me.controls.count -1
        if me.controls(i).tag="@" then
            if me.controls(i).oldvalue <> me.controls(i).value then
                   ' ....... qui inserisci il codice che piu' ti aggrada
                   '  ....... tieni conto che l'insieme controls ha varie
proprieta' da cui puoi ricavare tutto
                   ' ........ sia il nome del controllo stesso che quello
del campo a cui e' legato
                    'per esempio potresti fare :
                    me.campomemo=me.campomemo & me.controls(i).controlSource
& ":" & me.controls(i).oldvalue & vbcrlf
            endif
        endif
    next i
N.b.: non ho controllato la sintassi ma il nocciolo e' questo.
bye :o)

 2) nell'evento before update inserisci:
[CUT]
Meglio After Update, supponi un errore e non salva nulla..!
Avresti una situazione non reale nell'Event Log.
@Alex.
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 Namor
Non è corretto poichè nel Salvataggio potresti incorrere in
Errori che altererebbero la veridicità dell'EVENT LOG.
EVENTO After_Update.
Poi Dirty (Evento solo per Versioni >A97) è attribuito alla
Form non al Controllo, di conseguenza non controlleresti nulla.


 ha scritto nel messaggio
news:bb52b3a0aab749d0e5...@mygate.mailgate.org...

Ragazzi siete splendidi...
Funzionano entrambe le soluzioni da voi propostemi, anche se quella di
sfruttare i -tag- dei controlli mi sempra più pratica ed efficace.
Grazie mille a tutti!
Luca

 @Alex.
Non puoi usarla nell'after perke se non ricordo male,
il valore di oldvalue lo perdi dopo upadate
e poi se il campo dove memorizzi la variazione fa parte del record
nn rischi nulla perke o salvi tutto o salvi niente.
Bye :o))

 ha scritto nel messaggio
news:1daf4d22245f4cd510...@mygate.mailgate.org...

[CUT]


No, io mi riferivo alla proprietà dirty, non all'evento. Ma ripensansoci, se
ti trovi nelle routine before_update o after_update vuol dire che ci sono
state modifiche ai dati, quindi non ha senso testare la proprietà dirty.
In che tipo di errori potresti incorrere? L'unica cosa che mi viene in mente
è che ci possa essere qualche dato non valido, ma se fai tutti i test in
before_update risolvi il problema perchè scriverai sui log solo quando i
dati avranno passato i controlli, e quindi saranno sicuramente validi.
Se scrivi il codice in after_update i nuovi valori sono già salvati in
tabella, quindi non hai più la possibilità di fare il confronto dei dati
presenti in tabella con quelli che hai nella maschera per sapere quali dei
campi sono cambiati e quali no (lui voleva il log a livello di campo, non di
record).
Namor

 ha scritto nel messaggio
news:oQ8pb.86217$e6.31...@twister2.libero.it...

Lui non vuole salvare il contenuto precedente alla modifica, ma solo
il Nome del Campo interessato alla modifica.....!!!
Almeno io ho inteso così nel Post originale.
Di conseguenza ho risposto......................!
@Alex.

"Enrico T.S." <WlaRom...@Hotmail.com> ha scritto nel messaggio
news:tCCob.83168$e6.29...@twister2.libero.it...

Lui non vuole salvare il contenuto precedente alla modifica, ma solo
il Nome del Campo interessato alla modifica.....!!!
Almeno io ho inteso cosě nel Post originale.
Di conseguenza ho risposto......................!
@ALex.

ALESSANDRO Baraldi ha scritto:

[CUT]




Credevo volesse salvare anche i dati, dalla richiesta non si capisce bene.
Allora tu dici di fare il log nelle after_update di ciascun controllo,
pensavo che parlassi dell'after_update della form. Ma così se modifichi un
campo più volte prima di salvare il record ti troverai più righe di log
nel file.
Io lo mettevo nel before_update della form per gestire tutto con un'unica
routine, senza aggiungere codice se aggiungi controlli alla maschera.


 Namor
Da quando in Form Associate non salvi direttamente digitando nel
controllo...!!
Quando hai modificato il valore della TxtBox hai già salvato.
Se vuoi dare un senso alla cosa come hai giustamente evidenziato
devi lavorare con Form non associate, oppure impostare un Flag
per ogni controllo e su evento After_Update di Form leggi i Flag
e salvi.
In ogni caso secondo me se serve una gestione in questo senso DEVE
essere fatto con Form non associate, poi ognuno lo fa funzionare
come peggio crede.....! ;-)


Alessandro Baraldi ha scritto:

[CUT]


No. I dati vengono scritti nella tabella quando ti sposti su un altro
record, quando chiudi la form o quando forzi il salvataggio, ma non
vengono salvati quando ti sposti da un controllo all'altro all'interno
dello stesso record. Fino ad allora avrai i nuovi dati solo all'interno
dei controlli ma non nella tabella. E' per questo che proponevo il
confronto su before_update tra i controlli della form e i valori presenti
in tabella, così si può capire quali campi sono stati cambiati. Basta
controllare la proprietà .OldValue di ciascun controllo e vedere dove
differisce da .Value.
Su after_update non si può più confrontare, perchè i nuovi dati saranno
già stati scritti nella tabella e la propietà .OldValue sarà uguale a
Value.
Tutta l'operazione di log si riduce ad un ciclo for in Form_BeforeUpdate
ed una sub "log" che scrive sul file:
private sub Form_BeforeUpdate()
dim ctl as control
  <...eventuali controlli di validità dei dati...>
  for each ctl in me.controls
    if ctl.value<>ctl.oldvalue then log (
ctl.name
, ctl.oldvalue, ctl.value)
  next
End sub


 
Si hai perfettamente ragione ho detto una cazzata con la C maiuscola..!
Allora è corretta la tua procedura, basterebbe usare il DefaultValue
per memorizzare il valore Su Corrente di Form e su Before_Update
salvare nel LOG solo quelli in cui Value<>DefaultValue.
La cosa è semplicissima, si fà con lo stesso ciclo da te suggerito
basta implementare nel For..Each..Next la modifica del DefaultValue
su Current, in modo da aggiornarlo allo spostamento.
Scusa di nuovo ma sono abituato a lavorare su Form sconnesse.
10 frustate e 10 sedute sui ceci(inginocchiate mi sembrava troppo).
Ciao.


 ha scritto nel messaggio
news:ba63f3b7aa7f29ce7d...@mygate.mailgate.org...

Ciao a tutti.
mumble mumble...usando il codice quì sotto, postatomi da Enrico 
T.S.il
 il 31
ottobre, va tutto
bene tranne quando nella Form ho due controlli che provengono da un'altra
tabella, ovvero la query origine della Form è formata da due tabelle
correlate da un join.
Mi restituisce l'errore di run-time 3251: operazione non supportata per
questo tipo di oggetto.
Come posso fare?
Ciao
Luca

bye :o)
Luca