Newsgroup: it.comp.appl.access
Titolo: dubbi generali gestione database

vorrei porre alcune domande circa i database e la loro gestione:
-è possibile salvare lo storico delle modifiche dei database in
maniera automatica, cioè ogni volta che viene modificato un valore il
software lo rileva e lo salva nell'archivio dei movimenti?
-è possibile vincolare i valori di alcuni record a priori, oppure
ancora vincolarli secondo parametri dipendenti dai valori di altre
celle?
-è possibile leggere il numero di campi contenuti in un record?
Come avrete capito sono un neofita dell'argomento, quindi alcune
domande vi potranno sembrare strane o fuori luogo e per questo me ne
scuso anticipatamente. Grazie.

 wrote in message 
news:1133205635....@z14g2000cwz.googlegroups.com...
vorrei porre alcune domande circa i database e la loro gestione:
-è possibile salvare lo storico delle modifiche dei database in
maniera automatica, cioè ogni volta che viene modificato un valore il
software lo rileva e lo salva nell'archivio dei movimenti?
Sì, ma te la devi guadagnare tutta...
-è possibile vincolare i valori di alcuni record a priori, oppure
ancora vincolarli secondo parametri dipendenti dai valori di altre
celle?
Forse volevi dire "i valori di alcuni campi", ché non ha senso
parlare di valore di un record.
Comunque la risposta è sì, abbastanza facilmente.
-è possibile leggere il numero di campi contenuti in un record?
Sì, facilmente.
Come avrete capito sono un neofita dell'argomento, quindi alcune
domande vi potranno sembrare strane o fuori luogo e per questo me ne
scuso anticipatamente. Grazie.
Ciao
Bruno 

 scuso anticipatamente. Grazie.
Dai Access è per ogni livello di utente/sviluppatore, decidi tu a quale
livello arrivare
-- 
_ _
Ciao
MAssimiliano Amendola            
www.accessgroup.it
Cisa - Conferenza Italiana per Sviluppatori Access
Info:  
www.donkarl.com/it

 Sě, con poche righe di codice seppur da adattare a tutte le maschere
[...]
Oh perbacco!
Ma con quale diavoleria?
Per tener conto (relativamente ad una sola tabella di database)
di User, Computer, Record Nuovi, Record Modificati,
Record Eliminati, data e ora, ci ho perso il sonno per due giorni...
Ciao
Bruno

 Bruno
Creati una funzione che ti faccia il log e mettilo sugli eventi che ti
interessa monitorare
In realtà sono tutti addnew, quindi nulla di particolare


 Bruno
Forse ti interesserà il mio esempio su 
www.sitocomune.com
 sez. Modules,
5.22
Per la teoria vedi
http://www.donkarl.com/AccessFAQ.htm?/it/CISA/Download.htm
Namor
-- 
namor at inwind punto it
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 5.22
Ho esaminato il tuo esempio e relativa documentazione.
Complimenti, veramente.
Per quanto riguarda il bug,
ho sostituito la procedura Record con:
===============================
Private Function Record() As String
Dim Fld, Str As String
For Each Fld In Maschera.Controls
    On Error Resume Next
    Str = Str & Fld.Name & "=" & Fld.Value & vbCrLf
    On Error GoTo 0
Next
Record = Str
End Function
===============================
Mi pare funzioni, perņ non ho fatto un gran numero di prove.
Ciao
Bruno

 Bruno
non ti conviene usare il nome record, è una parola riservata ed Access mal
sopporta rotture del genere..


 sopporta rotture del genere..
Sono d'accordo.
Ma non dirlo a me, rivolgiti a namor.
Io ho solo sostituito in parte il contenuto
di una sua scatola...
Ciao
Bruno 

 Bruno
Si, questo risolve il bug, che era dovuto all'uso del RecordsetClone. Però
ciclando sull'insieme controls anziché sul RecordsetClone registrerà solo
i campi associati ai controlli. Se hai dei campi inclusi nella
tabella/query origine dati della maschera ma non associati ad un
controllo, questi non verranno loggati.
Un esempio potrebbe essere un contatore. Difficilmente lo si associa ad un
controllo sulle maschere, ma sarebbe utilissimo loggarlo per identificare
univocamente il record in caso di problemi. Se hai qualche caso simile ti
basta inserire nella maschera una textbox nascosta associata al campo.
Attenzione che un ciclo fatto così passa *tutti* i controlli della
maschera, comprese le etichette, le linee, ecc... quindi ti può dare
errore perchè non tutti i controlli hanno la .Value. Dovresti identificare
i controlli associati e loggare solo quelli.
Come ultima cosa ti conviene modificare la Dim: Fld as Control
Ciao.


 Come ultima cosa ti conviene modificare la Dim: Fld as Control
Consiglio disatteso.
In un ciclo For Each... Next l'indice può essere Variant
ovvero Object.
Preferisco Variant: risparmio i byte di "As Control".
E resto fuori dal gregge.
Concludendo:
Mi piacerebbe modificare la tua impostazione per riportarla
su quella che ho previsto nella mia soluzione: tutte le modifiche,
nuovi record, record cancellati in una tabella del database.
Una scheda ContinuosForm per l'esame della storia, Parent di
tre sottoschede ContinuosForm portanti rispettivamente Modifiche,
Nuovi Record, Record Annullati.
Però mi desta qualche perplessità quel ClassModule (scheda virtuale)
per la gestione di WithEvents. Non mi dà la sensazione di
grande affidabilità.
Commetti un errore che per essere stato convenientemente
gestito non ti dà problemi e nel frattempo
il ClassModule è volato via...
Ciao
Bruno

 Bruno
Il sistema è affidabile, e del resto non hai alternative se non quella di
gestire il log da ciascuna maschera. Il problema che si verificava è
dovuto all'uso del RecordsetClone, non del modulo di classe o di
withevents, e non si è ancora capito bene se è un bug di Access o
cos'altro. Con la modifica che hai fatto non dovresti avere problemi.
Piuttosto porta MOLTA cautela lavorando gli On Error Resume Next ... Goto
0, che vedo usi con leggerezza (e comunque mettilo FUORI dal ciclo For!).
La redirezione del log su tabella anziché su file si può fare facilmente,
basta creare la tabella e usare un "INSERT INTO ..." al posto delle righe
che scrivono sul file.


 che scrivono sul file.
Per operazioni di modesta entità (come nel caso in specie,
ché si deve scrivere un record alla volta) manovro il recordset
con .AddNew, .Edit etc.
Riservo il linguaggio SQL alle operazioni di massa.
Sempre da codice comunque, ché non scrivo una query
per tutto l'oro del mondo.
Quella sezione della finestra database mi piace vederla vuota.
Come quella delle macro.
Ciao
Bruno

Bruno Campanini ha scritto:
E' evidente che non hai la minima idea di cosa sia l'ottimizzazione.
Del resto, con quel che costano oggi i processori, un programma che
potrebbe girare tranquillamente su un Celeron 800Mhz lo mettiamo su un
Pentium IV 3Ghz e va lo stesso.
Se hai tempo e voglia prova a leggerti questo (in inglese):
http://msdn.microsoft.com/library/en-us/dnacbk02/html/odc_4009c15.asp


 E' evidente che non hai la minima idea di cosa sia l'ottimizzazione.
Può darsi.
Sta di fatto che non son disposto ad accettare acriticamente
alcuna verità rivelata.
Ma su questo punto non c'intendiamo e tu continui a voler
dar consigli.
Perciò tolgo gli "occhiali" al thread.
Alla prossima..
Bruno

Bruno Campanini ha scritto:



Mi spiace se ti sei offeso.
Il fatto di dare consigli è il principio che sta alla base di questo e di
tutti i newsgroup tecnici, e il 99,9% dei frequentatori li trova molto
utili per migliorare o confrontare le proprie tecniche con quelle degli
altri.
I consigli che ti ho dato non sono casuali e non sono dogmi né verità
rivelate, sono tutti basati su dei precisi motivi tecnici.
Quasi sempre in programmazione c'è più di un modo per fare una certa
operazione, e alcuni sistemi sono migliori o preferibili ad altri.
Se non capivi perchè ti era stato suggerito di operare in un certo modo
piuttosto che in un altro potevi semplicemente chiederlo, io o qualcun
altro te l'avremmo spiegato e se ne poteva discutere.
Io sono capace di spiegarti esaurientemente il perchè di ciascuno dei
consigli che ti ho dato, tu sei in grado di fare altrettanto motivando le
tue scelte?
L'importante, comunque, è che tu sia riuscito ad ottenere il risultato che
volevi e che il database funzioni.
