Newsgroup: it.comp.appl.access
Titolo: Meglio tutto associato o tutto codice?

Ho un quesito che mi sembra un pò da dilettante, che però mi è necessario
porre.
Mi trovo intrapolato dal fatto di essere passato quasi subito al VBA, perché
le macro e le tabelle associate mi hanno sempre creato tanti problemi. Ora
per poter fare una maschera contenente varie decine (più di 50) di controlli
vari da riempire uno a uno da parte dell'utente, forse nella speranza di una
soluzione rapida e facile, ho tentato la via del "tutto associato". Questa
maschera contiene sotto e sotto-sotto maschere (sono necessarie!), il tutto
collegato alla tabella principale alla quale la maschera è associata, più
quasi una decina di altre tabelle che gli "ronzano" intorno.
Adesso ho appena cominciato a verificare la possibilità di riempire i
controlli (quindi i campi uno dopo l'altro), con aggiornamento automatico, e
già cominciano i problemi di logica con le relazioni 1 a molti, perché un
record non accetta valori nulli, perché viola l'integrità referenziale,
ecc...
Volevo quindi sapere, secondo voi, se vale la pena di perderci del tempo,
oppure è meglio prendere coraggio e affrontare il tutto con VBA puro e duro!
Preciso che quasi tutti i controlli possono essere riempiti nel disordine, e
non ci sono operazioni speciali, con date, numeri, ecc... E' solo la
quantità di controlli che mi scoraggia un pò.
Grazie
Thierry

 quantità di controlli che mi scoraggia un pò.
IMHO.
Relazioni, integrita` referenzale, controlli associati sono tutte forme
assoggettate
al rigido rispetto delle regole, rendono forse la vita piu` difficile in
fase di
partenza ma poi ti ritrovi un database "coi fiocchi", almeno credo.
Io, dopo aver varie volte tentato questa strada, ho abbandonato l`idea
affrontando il tutto con VBA. Sicuramente non e` la scelta migliore.
Eviti pero` di doverti redigere una esaustiva e perfetta analisi a priori,
lavoro non da poco perche` dovresti prevedere tutto in anticipo.
Di solito quando io parto con un progetto, alla fine, l'avro` ritoccato
e rimestolato una decina di volte, per questo motivo evito la prima
soluzione. E' questione di competenza, bravura e anche pazienza,
doti che io , purtroppo, non posseggo.
    Paolo

 doti che io , purtroppo, non posseggo.
Ti ringrazio per la risposta, e vedo che la pensi come me. Poi a dire che
manchi di competenza e bravura per certi aspetti di Access, non mi sembra,
visto la partecipazione che hai su questo NG :-)
Piů che altro mi sembra una questione di carattere: chi puň resistere al
fascino della programmazione?
Ciao
Thierry

 fascino della programmazione?
Io ne son rimasto sedotto.
    Paolo

 Io ne son rimasto sedotto.
Capisco, capisco... Ti seduce come una donna...
Thierry


Secondo me il metodo da seguire cambia a seconda della situazione: se devi
rimettere le mani su un DB già esistente e funzionante (e magari neppure
creato all'origine da te) mi sembra chiaro che è inopportuno ripartire da
zero, e quasi sempre intervenire con VBA (specie se sai programmare) è
conveniente e più veloce.
Ma se stai progettando un nuovo DB, per me è assolutamente opportuno
dedicare il tempo necessario ad una macroanalisi dalla quale emerga
chiaramente le informazioni che vuoi ottenere dal DB e i dati che il DB
dovrà contenere
nelle sue tabelle. A questo punto è necessario anche determinare le corrette
relazioni tra le tabelle: non per niente Access è un DB relazionale e mette
per questo a disposizione, per facilitare la fase progettuale, il comando
Anlizza sotto il menù Strumenti; perchè non farsi suggerire direttamente da
Access cosa c'è da ottimizzare come architettura del DB?
Sono sicuramente dell'avviso che in Access la definizione di un progetto e
la giusta determinazione dell'architettura del DB risolvono almeno l'80% dei
problemi: lo dimostra il fatto che nelle risposte che vengono date in questo
NG ai neofiti si suggerisce spesso di cambiare proprio il modo di
definizione delle tabelle e la loro interrelazione.
Se invece sei preso più dalla voglia di programmare che di progettare,
allora forse e meglio che abbandoni Access e ti sposti su altri applicativi
(ad esempio FoxBase) dove la fase progettuale  del DB è meno importante nel
raggiungimento dei risultati, però così rinunci a tutti i vantaggi che ti
offre un DB relazionale, all'utilizzo di linguaggi standard quali SQL e alla
trasportabilità in altri ambienti operativi del tuo DB, visto che i DB
relazionali (al momento) rappresentano appunto lo standard di riferimente.
Roberto

 relazionali (al momento) rappresentano appunto lo standard di riferimente.
Concordo pienamente sulle tue asserzioni, che ritengo
teoriche e perseguibili quando la concezione del database
e' chiara e definitiva.
Purtroppo la quotidianita` e` ben diversa, generalmente vaga.
Fosse un programma di contabilita` o paghe, le regole sarebbero
chiare (buffonate delle insane menti di chi legifera a parte),
in questo caso l'analisi diventa semplice perche` regolamentata.
Access si presta molto bene a soddisfare le esigenze di piccole
aziende dove il committente non ha per niente in testa quello
che vuole. Parti con un'idea ed arrivi alla fine con tutt`altra.
Questo scenario mi fa preferire la totale programmazione in
VBA evitando a priori l'integrita` referenziale che 'governo'
direttamente da codice.
Agendo in questo modo riesco a ben gestire database
sull'ordine di una trentina di tabelle senza alcun bisogno di
un'analisi del progetto che verra` definito durante il cammino.
Sono ben conscio che una giusta analisi  a priori ti porterebbe
all'80% dell'opera e ad un proficuo uso delle relazioni ma
con la clientela che mi ritrovo non ci riesco, sara` perche` non
sa esattamente quello che vuole o sara` per la mia personale
inettitudine ad interpretarlo o ad intuirlo quando non espresso.
Non lo so.
    Paolo

 relazionali (al momento) rappresentano appunto lo standard di riferimente.
Non c'è tempo per cambiare, lì va bene in teoria, ma quando hai un lavoro da
finire, devi finirlo, senza perdere tempo a "giocare" con altri applicativi!
Comunque a parte la voglia di programmare, il nocciolo del problema è la
paura che arrivato a un certo punto, ti ritrovi in un vicolo cieco che ti
obbliga a rendere il DB pesante e contorto. Questa "paura" è dovuta al fatto
che non ho mai affrontato un DB con 200 campi sparsi in 30 tabelle e non ho
idea della mole di lavoro necessaria per collegare tutti i controlli con
tutti questi campi!
Ciao
Thierry

 inettitudine ad interpretarlo o ad intuirlo quando non espresso.
A questo punto un DB di una trentina di tabelle per quante ore ti impegna?
Fai usare le stesse maschere per leggere, modificare, aggiungere ed
eliminare i record, oppure crei varie serie di maschere con codice diverso
per ogni esigenza?
Poi, fai modificare i record manualmente da l'utente, tramite un tasto di
commando, oppure li salvi in automatico quando l'utente passa da un
controllo all'altro?
Scusa se ti faccio il "terzo grado", ma č soprattutto in questo che risiede
il mio problema "decisionale"!
Io avrei la preferenza a fare una sola serie di maschere che fa tutto (dalla
lettura alle modifiche ai record), perň mi sembra piů laborioso.
Ciao
Thierry


L'esperienza mi insegna (ed ho i capelli bianchi) che il tempo speso a
progettare non è mai tempo perso, specie se si ha a che fare con un DB
relazionale; nell'economia di un progetto il tempo che si perde di più è
quello che si spende non tanto a progettare e a scrivere codice VBA ma a
fare il debug di quest'ultimo.
Quanto alla "paura" di avere 200 campi sparsi su 30 tabelle, se hai
tracciato l'architettura del DB prima su un foglio di carta, con Access non
è difficile realizzare il collegamento delle tabelle e dei controlli in esse
contenuti.
Infatti nel 90% dei casi in cui ci sono relazioni uno-a-molti sul lato uno
ti trovi con una casella combinata; ebbene quando ti dichiari questi
controlli nelle tabelle, se usi l'Autocomposizione Ricerca.. il collegamenti
trai campi e le relazioni tra le tabelle vengono fatti automaticamente da
Access e senza creare conflitti.
E poi non credo tu voglia rinunciare all'uso di quelle tabelle virtuali che
sono i recordset delle query, ed immagino che tu voglia farlo con una certa
facilità e velocità, visto che mi sembra di capire che il tempo non ti
avanza mai. Questo lo potrai fare solo se hai dedicato il giusto tempo alla
fase progettuale.
Quanto poi a creare maschere o report personalizzabili con del codice VBA,
non è certo un problema; per un  programmatore scrivere codice VBA che cambi
alcune proprietà di certi oggetti del DB affinché questi risultino
polivalenti non dovrebbe essere difficile.
Non ti è mai venuto il dubbio che il fatto di trovarsi sempre a lavorare in
maniera così convulsa possa dipendere anche e soprattutto dal fatto che non
si cerchi di lavorare in maniera strutturata e pianificata? Sono convinto
che lavorando bene a monte si ottengano più risultati e con minor sforzo ed
assillo e nessuno può convincermi del contrario.
Credimi la mia non è sola teoria, ho 55 anni e sono dirigente d'azienda.
Ciao Roberto :-))))))

 Credimi la mia non è sola teoria, ho 55 anni e sono dirigente d'azienda.
Ti credo, ti credo, anche perché tutto questo l'ho già sperimentato e
appliccato, anche se da molto meno tempo di te, e quindi comunque l'opinione
di chi ha molta più esperienza è sempre interessante.:-)
Come ho risposto a Paolo Beltrame, il nocciolo del problema è che vorrei
fare la serie di maschere, che riempono tutte queste tabelle, come unica
soluzione che fa vedere, modificare, aggiungere ed eliminare. Codificando
solo con VBA, ci si riesce perché controlli ogni movimento. Ma con le
associazioni fra tabelle e campi, con maschere e controlli, forse sarò
ancora troppo dilettante, ma ho l'impressione che la cosa diventa molto più
intricata il che mi ricorda l'incubo quando lavoravo ancora con le macro!
Lì mi sono accorto, se non erro, che in funzione di come associ i campi con
i controlli, li puoi vedere ma non modificare, e vice e versa, e quindi
dovrei cambiare il modo di associazione in funzione di quello che vuol fare
l'utente. e questo mi sembra un pò pazzesco!
Per ovviare a questo intreccio diabolico, ho cominciato a fare una maschera
che mi permette di creare una tabella contenente la lista delle
corrispondenze fra controlli e campi, con possibilità di mettere delle
condizioni, applicabili tramite eval(). Poi per ogni controllo, ci sarebbe
una chiamata a una sub, sempre la stessa, che andrebbe a frugare in questa
tabbella per sapere subito cosa fare per tale controllo e tale campo. In
questo modo a secondo della modalità scelta (lettura, modifica, ecc...) la
sub in questione sà subito cosa fare a quale controllo per quale campo,
ecc...
Il vantaggio è che una volta fatto il codice della sub, essa sarebbe la
stessa per qualunque db presente e futuro, e con la maschera
"CreaTabellaCorrispondenze", maneggi le corrispondenze in una volta sola  e
dopo (teoricamente!) il gioco è fatto!
Adesso, secondo me, mi sembra un'idea attraente perché evita di dover fare
del codice personalizzato per ogni controllo, o quasi, poi permette, in modo
semplice (tramite quella maschera) di strutturare e ordinare tutta la
problematica del controllo sulle tabelle. E quindi quello che non
funzionerebbe sarebbe contenuto solo in quella tabella delle corrispondenze
fra campi e controlli. Quindi l'ultimo vantaggio sarebbe anche di dover
cercare gli errori solo in un posto e non nel db intero... secondo me...
Preciso che sono ancora un pò dilettante in fatto di DB e quindi non mi
rendo conto se faccio ridere, se sembro masochista, se mi complico
inutilmente la vita, o semplicemente pur di evitare il problema degli
intrecci di sincronizzazione fra controlli e campi sono pronto a inventarmi
qualsiasi trucco :-))
Infatti quello che mi fa esitare ancora a prendere questa strada appena
descritta, è che poche settimane fà avevo descritto questa idea nel post:
"Corrispondenza fra campi e controlli." del 16/05/00. Dalle risposte, mi è
sembrato capire che nessuno faccesse così e l'idea non ha perturbato molto
gli spiriti. Quindi cosa vuol dire?
Ti lascio con questa domanda, e grazie ancora per avermi risposto.
Ciao
Thierry

[CUT]

Sono convinto che per raggiungere facilmente i propri obbiettivi bisogna
essere consci delle proprie attitudini ed assecondarle; ciò non significa
affatto che da questo possa venir fuori una rgola universale o che comunque
sia più congeniale alla magioranza delle persone: potrebbe per assurdo
essere solo congeniale a te.
Quanto alla sensazione che hai ricevuto dalle risposte alla tua e-mail del
16/05/00, potresti anche essere un piccolo genio, ed allora sarebbe normale
che tu abbia pensato a soluzioni che non hanno sfiorato gli altri neppure
lontanamente.
Permettimi di dirti (dall'alto dei miei 55 anni) che sei un perfezionista ed
hai troppa poca fiducia in te stesso;  in fin dei conti non credo che in
vita tua realizzerai un solo progetto di informattizzazione: per il prossimo
progetto scegli la strada che ritieni dal tuo punto di vista  più giusta, e
se poi ti accorgerai che non è quella giusta, cambiala per il progetto
successivo: nel mondo d'oggi essere pragmatici è fondamentale, evita lo
stress di vivere in mezzo ai dubbi.
Ciao, Roberto

 vedendo.
Aaah, ecco un'altra risposta che mi volevo sentire :-)
E su questo volevo approfittare per chiederti alcune precisazioni, senza
voler essere troppo pignolo.
1) Il salvattaggio all'uscita della maschera non è troppo rischioso, e
quindi non sarebbe meglio farlo quando l'utente passa da un controllo
all'altro?
2) Poi quando un campo viene modificato, il computer non sa se è stato
modificato volontariamente o no, se non viene in qualche modo avvertito.
Penso alla situazione dove l'utente percorre un record solo per guardarlo,
ma su decine di campi, magari ne modifica uno senza accorggesene. Quindi non
ci vorrebbe un tasto specifico che conferma che la modifica è voluta?
3) Senza voler apprire un dibattito che esula dalla domanda posta in
oggetto, capita spesso che dobbiate restringere gli accessi ad alcuni record
in funzione dell'utente. Cioè per esempio, solo l'utente che ha compilato il
proprio record lo può modificare, e/o solo il suo superiore, ecc...? E in
che modo gestite queste autorizzazioni, con altre tabelle che contengono le
informazioni sulle autorizzazioni? Oppure gestite da codice le
autorizzazioni degli user di Access? Quale dei due metodi è migliore?
Grazie
Thierry

 autorizzazioni degli user di Access? Quale dei due metodi è migliore?
Lavorando per ziende di piccole dimensioni, non uso mai le password.
Ho usato in alcune occasioni, su richiesta, un database ad albero e da
codice attribuisco i permessi alle cartelle e subcartelle.
In pratica chi ha il permesso "in radice" puo` tutto, gli altri hanno
la loro lista di cartelle, tutto rigosamente archiviato in una tabella.
    Paolo


Grazie per le informazioni, erano molto interessanti.
Ciao
Thierry