gestionale con Microsoft Access

[Guido Benzi]

sto facendo un lavoro su un database Access preesistente.

Praticamente è un database Access 97 "acconciato" a mo di applicativo
gestionale per organizzare il lavoro di un freelancer che lo ha
commissionato (clienti, trattative, appuntamenti, eccetera).
I menu sono fatti con le maschere del database e ai vari eventi di
quando si cliccano i pulsanti sono associate delle routine Visual
Basic.

Adesso ho convertito il databae in formato Access 2003 e dovrò fare
delle modifiche, tra cui una rivisitazione completa dell'interfaccia.
Siccome il codice Visual Basic tende a incasinare tutto, volevo sapere
se posso farne a meno.

Ad esempio, c'è un opzione che mi permette di dire "quando clicchi sto
pulsante la maschera attualmente aperta deve chiudersi e deve invece
aprirsi la maschera tal dei tali"?
Attualmente questo meccanismo, che in pratica permette di navigare da
un menu all'altro, è implementato col codice Visual Basic.

Consigli?

[Andrea B.]

Post by Guido Benzi
Ad esempio, c'è un opzione che mi permette di dire "quando clicchi sto
pulsante la maschera attualmente aperta deve chiudersi e deve invece
aprirsi la maschera tal dei tali"?
Attualmente questo meccanismo, che in pratica permette di navigare da
un menu all'altro, è implementato col codice Visual Basic.

Esiste la possibilità di gestire alcune cose tramite le macro collegate
agli eventi degli elementi di interfaccia ma francamente, avendo
sviluppato in Access fino a qualche tempo fa, non credo che potrai
eliminare del tutto il codice VB che molto più flessibile e potente
delle macro, poi sai dipende da come si scrive il codice comunque non ti
invidio: mettere le mani dentro il codice scritto da altri è quasi
sempre un problema, particolarmente quando si tratta di sviluppo fatto
un po' alla buona. Qualche giorno fa, tanto per fare un esempio, mi
hanno mandato un applicativo da correggere ("perché dà errore") scritto
in Access in cui le query si chiamavano query1, query2, query3, copia di
query3... sigh :(

[Guido Benzi]

Esiste la possibilit di gestire alcune cose tramite le macro collegate
agli eventi degli elementi di interfaccia ma francamente, avendo
sviluppato in Access fino a qualche tempo fa, non credo che potrai
eliminare del tutto il codice VB che molto pi flessibile e potente
delle macro, poi sai dipende da come si scrive il codice comunque non ti
invidio: mettere le mani dentro il codice scritto da altri quasi
sempre un problema, particolarmente quando si tratta di sviluppo fatto
un po' alla buona. Qualche giorno fa, tanto per fare un esempio, mi
hanno mandato un applicativo da correggere ("perch d errore") scritto
in Access in cui le query si chiamavano query1, query2, query3, copia di
query3... sigh :(

hehe beh nel mio caso la situazione non è così tragica ma anch'io ho
un discreto numero di maschere e query dal nome criptico, e comunque
il codice visual basic con cui ho a che fare lo ritengo un classico
esempio di codice spaghetti, è un casino.
Comunque a sto punto dovendo rifare l'interfaccia cercherò
semplicemente di tenere il codice il più pulito possibile e buttare
via la roba inutile.

BTW, all'inizio ho ammirato i 2 vecchi sviluppatori (due ragionieri
programmatori diplomati da poco, 12 anni fa) guardando il loro immenso
programma, poi vedendo come hanno lasciato a metà certe cose, mi sono
reso conto che sono partiti in quarta facendo routine varie e nuove
maschere query ecc ogni volta che dovevano aggiungere features, senza
mai reingegnerizzare, senza mai preoccuparsi della coerenza
complessiva del progetto, finché hanno perso il controllo della
situazione, così le modifiche sono diventate troppo macchinose da
apportare per i soldi che il committente era disposto a esborsare, e
gli hanno detto "ormai siamo occupati a fare altro e non abbiam più
tempo" e hanno piantato lì.

Questo per dire che l'ingegnerizzazione del software è sì per i
software complessi, ma neanche poi così tanto complessi. Spesso la
questione è sottovalutata.

[Andrea B.]

Post by Guido Benzi
Questo per dire che l'ingegnerizzazione del software è sì per i
software complessi, ma neanche poi così tanto complessi. Spesso la
questione è sottovalutata.

Verissimo, purtroppo ho dovuto verificare di persona che spesso nelle
piccole realtà di comincia con un applicativo con obiettivi limitati per
poi aggiungere funzionalità su funzionalità finché, come dici
giustamente tu, si perde la bussola e il costo di manutenzione cresce
esponenzialmente con la quantità di codice. Purtroppo ho visto codice
pessimo e tirato via anche dove le risorse ci sarebbero state in
abbondanza, ma sai quando c'é l'ingordigia...