Newsgroup: it.comp.appl.access
Titolo: Corrispondenza fra campi e controlli.

Ho una piccola domanda da fare a tutti i professionisti ( o semi) di Access.
Quando in un database ci sono un bel pò di maschere con tanto di controlli e
varie centinaia di campi di tabelle da riempire di cui "sorvegliare" quello
ci si mette. Che i controlli, o sono numerati, e quindi perdono di
significato in relazione al campo che devono riempire, o hanno un nome
mnemotecnico e quindi perdono della loro facilità a usarli "in massa" quando
viene il momento di salvare 50, 100, 200 campi alla volta. Il tutto sotto la
stretta sorveglianza del VB che in funzione dei Sì e dei No e di vari valori
sparsi in vari controlli, deve decidere se salvare cosa e dove!!
Lo so, lo so, qualcuno mi sta già preparando la risposta che è una questione
di filosofia di ogni programmatore :-)
Però davanti all'ingrandirsi di un problema si converge sempre verso poche
soluzioni risolutive.
Quindi su due piedi vengono due soluzioni:
1) Si mettono tutti i controlli che aggiornano le tabelle, come associati
però si perde in flessibilità e si è ridotti a maschere un pò passive che
servono solo a riempire le tabelle (grosso modo).
2) Si controlla il tutto con VB e la gestione degli eventi come Su Clic,
Invio, Attivato, ecc... e si guadagna enormemente in capacità di controllo
della situazione. Però dopo con il codice ti devi "appioppare" tutte le
corrispondenze fra controlli e campi.
Visto che la seconda soluzione mi sembra nettamente più vantaggiosa, ho
pensato di fare lo sforzo di creare una maschera che permetta di creare una
tabella delle corrispondenze fra controlli e campi di tutto un database. In
questo modo il codice dovrebbe solo pescare le corrispondenze senza che io
debba scriverle manualmente una a una per il salvataggio dei dati.
E lì è la mia domanda: supponendo che ogni professionista serio l'abbia
fatta, volevo sapere se ci sono dei dettagli importanti da mettere per
rendere questa tabella veramente efficace.
Per esempio, per il momento mi sono limitato a metterci in questa tabella
per ogni record, il nome della maschera, del controllo, della tabella e del
campo, e fra poco anche un test eventuale già pronto a l'uso (con Eval())
che permetta al codice di vedere se ci sono delle condizioni per salvare
certi dati, della serie salvare il valore del controllo solo se uno ha
premuto su un pulsante di opzione, ecc...
Secondo voi è sufficiente oppure dovrei metterci altre informazioni?
Grazie per la pazienza
Thierry

 [cut]
non so se sono un professionista "serio"  ma questa mi sembra la strada
per cominciare a riscrivere un DBMS. Quella tabella secondo le regole
mi sembra gia' che siano almeni 4 tabelle comunque per dirla con
R.A. Heinlein "...Every man is entitled to elect the time and manner of is own
destruction..." (Double star)
:<))))))))
Alessandro Cara

 Alessandro Cara
Se ho capito bene alla fine diventano 4 tabelle da creare? Se non sono
indiscreto, cosa contengono di preciso e come sono organizzate? Scusa ancora
ma DBMS sta per cosa? DataBase M... S...?
Grazie
Thierry
P.S.: e chi sarebbe Heinlein?

 P.S.: e chi sarebbe Heinlein?
 [OT] e' uno scrittore di fantascienza comunque se sei proprio curioso prova
a porre la stessa domanda  a it.cultura.fantascienza e prova a vedere
che succede
ciao :<)
A. Cara

:<))))))))
a te ti devo prestare Requiem, se non l'hai letto... e se non lo
conosci ordina pure Expanded Universe la prossima volta che vai su
amazon...  arrivederci su it.cultura.fantascienza... :-)
--
il sito comune di it.comp.appl.access:
http://members.xoom.it/it_db_access/

>P.S.: e chi sarebbe Heinlein?
il piu' grande filosofo politico mai esistito, forse dopo Karl Popper.
come hobby era il piu' grande scrittore di fantascienza forse dopo
Asimov.


>viene il momento di salvare 50, 100, 200 campi alla volta. Il tutto sotto la
Thierry, quando in una tabella ci sono 50 (ancora ancora), 100, 200
campi, forse c'e' qualcosa che non va nel disegno del db...


 campi, forse c'e' qualcosa che non va nel disegno del db...
Prima di tutto vi ringrazio per la parentesi OT, ma senza volervi deludere
ormai di fantascienza non ne leggo più, non che non m'interessi, anzi, ma
sono in un periodo della mia vita dove mi interessa solo il lavoro che
faccio.
Detto questo, ritornando al db di dimensioni "grotesche", ancora una volta
mi dispiace deludere, questa volta però solo lbo, ma ti posso garantire che
dei 201 campi che mi sono ritrovato, forse al massimo 30 vengono ripetuti
(28 tabelle tutte in relazione fra loro). Cioè in altre parole, l'utente
riempirà una e una sola volta i campi di ogni tabella!! E per questo c'è uno
e un solo controllo per ogni campo da riempire!!!
Quando l'utente deve riempire un db con qualche cosa come almeno 150
informazioni diverse fra loro (per es. nome, cognome, indirizzo, città, CAP
sono 5 informazioni diverse e quindi 5 campi diversi) uno cosa può fare
d'altro?
Ciao
Thierry

 "forma di normalizzazione")
Ti supplico! In due parole (va beh, diciamo tre), tanto per farmi
indovinare:
1) normalizzazione/denormalizzazione: che cosa viene normalizzato e in che
senso?
2) 1NF; 2NF; 3NF: è un sistema su quante maschere creare per un dato db, e
cosa vuol dire normal form per una maschera?
Grazie
Thierry

d'altro?
quei cinque sono senz'altro campi diversi, ma potresti fare un esempio
di come arrivi a 201 campi in una tabella?


 di come arrivi a 201 campi in una tabella?
No, forse questa volta sei tu che non hai letto bene :-))
I 201 campi sono sparsi in 28 tabelle!
Thierry