Newsgroup: it.comp.appl.access
Titolo: Quanto grossi sono i vostri mdb piu' corposi ?

Parlo di procedure Access contenenti form, codice, report
Escluso i dati
Il mio piu' voluminoso arriva sui 40 Mbyte, parlo dell'mde
Circa 300 form, circa 200 report, 50 moduli e un 100 query
Inzomma, quanto ce l'avete grosso?
Chiedo questo perche' ho l'impressione che piu' grosso e' l'mdb di 
partenza e piu' fragile sia l'ambiente di lavoro
Mi accorgo che lavorando su mdb piu' grossi il pericolo di incriccamento 
e' piu' frequente e volevo capire come lavorano normalmente gli accessisti
Ciao e grazie
RobertoA
 
 
 
 
 


supero raramente i 10 mb
e lavoro solo con sqlserver come be
c'è da dire che tento sempre di usare le stesse form e report 
parametrizzandoli il più possibile e gestendoli a runtime quindi non ho 
tanti oggetti.
Per esempio ho visto gente che crea un report di articoli di magazzino 
in ordine di codice e una altro in ordine di nome articolo.
Quando basterebbe parametrizzarne uno solo e gestirne ordinamenti e 
raggruppamenti a runtime
Idem per molte form
 
ciao
BFS


Si, pure io le stampe le filtro e le ordino da codice e poi avvio la stampa
Credo comunque che quei 40 Mb siano un'esagerazione, probabilmente 
dovuta al fatto che diverse stampe hanno all'interno delle immagini
E questo appesantisce un po' tutto
Dovrei rivedere la cosa, ma "quando c'e' tempo" e quindi non si tocca mai


immagini su report e form sono letali!
 

 
"RobertoA"

La principale procedura che ho (anzi, abbiamo dato che non lavoro da solo) è 
confrontabile con la tua come dimensioni. Un pò meno a dire il vero.
Dimensione .Mde 15 MB.
Personalmente non credo che il numero di oggetti, la dimensione del FE crei 
particolari problemi, però 40 MB sono troppi.
Incidono sicuramente le immagini (che non devi incorporare) ma anche le 
queries salvate.
Noi non salviamo (quasi) mai le queries: a volte possono funzionare male.
 
Comunque, nello specifico, che tipo di problemi tu attribuisci alla 
dimensione del tuo Front-End? 
 
 

 Inzomma, quanto ce l'avete grosso?
 
AHEM ... ;-) 


 
Beh, una classica procedura aziendale che preveda Contabilità Fiscale, 
Ordini/DDT/Fatture/Magazzino/Scadenziari/Di.Ba con problematiche annesse e 
connesse (listini, scontistica, provvigioni, statistiche, etc. etc.) finisce 
giocoforza per raggiungere quelle dimensioni.
Anche se, come giustamente osserva BFS, alcune scelte di programmazione 
possono ridurre sensibilmente il numero di oggetti.
Però si rimane comunque nell'ordine di centinaia di Forms/Reports.
 
Saluti. 
 
 


Si, credo anch'io 40 Mb siano troppi, volevo appunto appurarlo con un 
confronto con altri che usano Access con progetti reali
Alla dimensione (ma forse non e' quello) attribuisco problemi di 
instabilita'
Capita sempre piu' spesso che qualche form non si apra in modalita' 
struttura
E allora via a cancellarla e reimportarla da copie di backup
Poi, durante il debug, se hai molte form aperte contemporaneamente a 
volte si pianta di brutto segnalando un laconico "memoria esaurita..." e 
via di questo passo
E ogni tanto una re-importazione generale di tutto su un mdb pulito
Non e' un bel modo di lavorare
Volevo capire se sono problemi comuni oppure no
Ciao e grazie
RobertoA


E una classica gestione aziendale, specifica per una particolare attivita'
Il numero di oggetti non mi sembra neanche tantissimo, e' la dimensione 
dell'mdb che non credo sia 'normale'
E non ho ancora ben capito se sia l'origine dei problemi di instabilita' 
che stiamo sperimentando
 
 

 Volevo capire se sono problemi comuni oppure no
 
 
No, il discorso cambia: credevo che i problemi da te denunciati 
riguardassero le copie .mde dei FE installate dai clienti.
 
Se invece mi parli di problemi durante lo sviluppo dell'applicazione 
.mdb/accdb, allora convengo che sono abbastanza normali.
Anche disattivando autocorrect, e pure su progetti piccoli ho spesso avuto 
problemi simili, sia con A '97 che A 'XP e 2003.
Per questo, da molti anni, sviluppo sempre le modifiche su una copia di 
backup dell'applicazione, e poi importo nella copia "master" solo le 
modifiche.
 
Saluti.
 
 
 
 

 modifiche.
 
 
Chiaramente i problemi si possono comunque verificare durante lo sviluppo 
sulla copia di backup!  ;-)
 
Ad ogni modo gli errori da memoria esaurita che segnali sono un pņ sospetti: 
quelli non li vedo dai tempi dei PC da 32 MB di Ram.
Che possano incidere le immagini che includi (generosamente?) in 
Forms/Reports?
Sono .bitmap almeno?
 
Saluti. 
 
 

 quelli non li vedo dai tempi dei PC da 32 MB di Ram.
 
Uhmmmm.... se non e' cambiato qualcosa c'e' un problema a livello del 
"garbage collector".
Se fai una serie di chiamate ricorsive ed il suddetto non si comporta 
correttamente puoi avere anche 10^1023 mb di ram ma nella memoria 
esaurita incappi ugualmente.
Ovviamente parlo per esperienza diretta.
E' ovvio che quello che dici e' comunque un po' vero. Quegli errori 
derivano comunque da una architettura piuttosto /approssimata/ .
-- 
ac (x=y-1)
Aborro il Killfile
(La violenza e' l'ultimo rifugio degli incapaci -Salvor Hardin-)
 
---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
http://www.avast.com
 
 

 Ovviamente parlo per esperienza diretta.
 
 
Fammi capire meglio lo scenario che invochi...
 
Tenendo conto che ho sempre resettato le variabili oggetto, nei miei ricordi 
gli errori da memoria esaurita (con Access 97 all'epoca) si verificavano:
 
- Su macchine con oltre 1 GB di memoria, se non presente SP2 di A '97
- Su macchine con poca RAM durante il desing delle applicazioni.
- Utilizzando immagini incorporate di tipo <> Bitmap durante la conversione.
- Talvolta anche a Runtime su particolari configurazioni hardware (di solito 
bastava aggiornare il Driver della scheda Video o della stampante).
 
Da molti anni, con le versioni XP e 2003, non mi capitano tali situazioni.
 
Saluti. 
 
 

 gli errori da memoria esaurita (con Access 97 all'epoca) si verificavano:
 
"Tenendo conto che ho sempre resettato le variabili oggetto"
La questione sta qui.
Si parte dal presupposto che se chiami una funzione, nel momento che 
esci da quella funzione, il tutto dovrebbe essere "cassato". Ebbene 
questo non avviene (almeno non sempre) e succedono i guai.
Ripeto, in genere per variabili "normali" questo succede.
Per variabili "anormali", nella mia esperienza "collection" (e quindi 
posso pensare per strutture assimilabili,quindi oggetto,ma questo e' 
incerto), cio' non avviene.
Detto questo non ho mai avuto problemi di memoria insufficiente in 
qualsiasi versione( E anche per situazioni "complesse").


 partenza e piu' fragile sia l'ambiente di lavoro
 
Anchio avevi lo stesso problema in misura inferiore.
 
lo ho radicalmente risolto ( a parer mio ) facendo molte miniapplicazioni specifiche.  ( metto dei nomi a casi )
- LogIn
- emissione fatture di vendita
- registrazione fatture ricevute
- magazzino con bollettazione
- protocollo posta e telefonate 
- rubrica telefonica
- gestione e caricamento commesse
- bilanci
- eccetera
- eccetera
- eccetera
 
Questo impegna un certo investimento iniziale in quanto ho preparato
una applicazione specifica per il LogIn con una maschera che contiene i collegamenti a tutte le altre miniapplicazioni
in ogni miniapplicazione satelite devi impiegare 2 o 3 mascherine e un po di codice per gestire la apertura e il ricevimento delle credenziali di Login
 
Superato questo scoglio diventa tutto molto più facile,
e non parlo solo delle possibilità di errori di Access su applicazioni grosse
ma parlo soprattutto della manutenzionabilita a livello di modifiche
nel senso che se devi modificare il LayOut della bolla di magazzino
metti mani solamente al magazzino 
 
Metti il tutto in una cartella.
gestisci i collegamenti con il CurrentProject.Path in modo da rendere portabile la applicazione ( anzi le miniapplicazioni )
L'utente finale non si accorgr di nulla
- Fa il Login
- fa un clik
- accede alla sua miniapplicazione
 
 
.
 
 
 
.
 
 
 


ma quindi se stai facendo una fattura e ti serve il numero di telefono 
del cliente..ti si apre un altro mdb della rubrica?
quindi ti trovi con N applicazioni aperti nella barra delle applicazioni 
windows O_o
 
 
 
 
 


Molto interessante questa possibilita', avrei voluto anch'io 
sperimentarla ma non l'ho ancora fatto
Quindi hai tante procedure, ognuna nel suo mdb/mde, che 'prendono' i 
dati dalla schermata iniziale di login, giusto?
Ma, per il collegamento ai dati come fai?
Cioe' se hai 20 'programmi satellite', quando modifichi il db 
sottostante, devi avviare un re-link tabelle su tutti e 20 i programmi 
satellite?
 

 che stiamo sperimentando
 
Banalmente : hai provato a comprimerlo ? E se non basta fai cosi' : 
ti crei un DB nuovo di zecca e importi tutti i contenuti in questo. 
 
Potresti avere una grossa sorpresa. Prova, e' una operazione molto 
veloce quindi anche andasse male ne vale la pena. 
 


Ah scusami non avevo letto questa parte. Quindi l' hai gia' fatto,
ok.
 


Si, una possibilita' credo possano essere le immagini direttamente su 
form e report ed il caricamento a run-time e' un lavoro che bisognera' 
fare, per il momento pero' devo tenerlo cosi
Fatto sta che anche su altri progetti, di dimensioni inferiori e quasi 
senza immagini incorporate, i problemi di instabilita' permangono, meno 
frequenti ma ci sono
Volevo capire se i problemi che verifichiamo sono connaturati 
all'ambiente di sviluppo oppure possano dipendere dal nostro particolare 
progetto
Dalla vostra esperienza mi par di capire sia entrambe le cose
 

 Però si rimane comunque nell'ordine di centinaia di Forms/Reports.
 
A quel punto (imho, s'  intende) spaccherei  l'  applicazione  in piu' 
parti ossia trasformerei l' applicazione in varie sotto - applicazioni
(se possibile). 
 
 

 miniapplicazioni specifiche.  ( metto dei nomi a casi )
 
Si anch' io proverei questa strada. 
 
Anche per me stesso : un mdb con TRECENTO maschere e TRECENTO 
MODULI ecc ecc diventa un LABIRINTO.

 windows O_o
 
No sempre e solo 1 aplicazione
Il Login ( e anche altre variabili se necessarie ) le passo direttamente dalla applicazione in chiusura alla applicazione in apertura
 
poi la apertura della applicazione B 
implica la chiusura della applicazione A 
 
L'utente finale non si accorge di nulla in quanto sono applicazioni piccole e rapide,
 
.
 

 satellite?
 
Si questa è una cosa fastidiosa.
 
c'è pero da dire che capita raramente di modificare il DB di BackEnd
per lo più si modifica la singola applicazione.
 
 
Confesso che fra le idee che non ho ancora realizzato c'e una applicazione che in automatico:
- Individua tutti gli  mdb (accdb) di una cartella
- ne faccia il relink
- ne faccia il compatta e ripristina
- ne nasconda la finestra di Access
- eccetera
- eccetera
- ne crei un mde (accde)
 
.
 


ma se per assurdo stai editando qualcosa sulla app che fa le fatture...
ti serve un qualcosa che sta nella app che fa il bilancio...
ti si chiude la app fatture???
 
non credo abbia senso questa cosa...a meno di non aver capito male
BFS
 
 

 Dalla vostra esperienza mi par di capire sia entrambe le cose
 
 
Secondo me sono problemi connaturati all'ambiente di Design, anche se ad 
alcuni capitano molto raramente.
Quindi inciderà anche l'operatività, presumo.
 
Saluti. 
 
 


 
 
Che č quello che ha fatto Mancini, leggendo il suo post nel thread.
Personalmente preferisco vedere tutto insieme, ma se il progetto diventasse 
davvero troppo grande (magari oltre le cifre riportate da RobertoA) 
certamente prenderei in considerazione lo "spacchettamento".
 
Saluti.
 
 
 
 


 
 
A proposito di riduzione oggetti, molto banalmente si potrebbe evitare di 
generare Reports (e potrebbero essere tanti) riferiti a svariate tabelline 
acessorie.
 
Nei 'miei' programmi ho molte mascherine tabellari per la manutenzione di 
Anagrafiche (Pagamenti, Aliquote, Gruppi, Categorie, etc etc etc) che non 
hanno associato alcun Report.
Se l'utente ha la necessità di stamparle (e succede di rado per Anagrafiche 
di secondaria importanza) usa un pulsantino di stampa, magari in un menù, 
che richiama lo "Stampa finestra" di Access. Quest'ultimo formatta la Form 
tabellare come fosse un Report, con ottimi risultati.
 
Chiaramente non va bene per stampe complesse e magari parametriche, pensa a 
quanto può essere impegnativa la Stampa della Rubrica Clienti o degli 
Articoli (l'utente deve poter scegliere quali campi stampare tra decine e 
decine che non starebbero tutti sul foglio), ma nei casi più semplici è una 
soluzione da prendere in considerazione.
 
Saluti. 
 
 


Giusto
Sono comunque convinto che un mdb che ha 300 maschere ecc ecc nasce 
(anche se non sempre ovvio) da una cattiva gestione del rapporto col
cliente, al netto, s' intende, delle varie razionalizzazioni tramite
parametrizzazione ecc ecc
 
Sono sicuro che capisci bene quello che intendo ;-) 
 
 
 


Eh, forse
Magari se ce lo spieghi anche a noi, come gestire un buon rapporto col 
cliente, in futuro ci potrebbe anche essere utile
 


Ho detto : *non sempre*, sia  chiaro. Talvolta  le necessita' del cliente
sono oggettivamente cosi' complesse  (e reali) che non c'e' via di uscita.
E non dubito che nel tuo caso sia andata effettivamente in questa maniera.
 
Pero'  "moltissimo  spessissimo"  se  uno  ci  sa fare  capisce che molte 
esigenze sono piu' dettate da "confusione" che  da necessita' oggettive :
il cliente va "educato". Si puo' e si deve fare e dipende dalla  abilita'
di coloro che fanno da interfaccia tra i programmatori e i clienti. 
 
Indipendentemente da quanto  sopra, poi, se si nota ad es. una ipertrofia
di  report  e  reportucci  vari suggerirei di dire al cliente piu' o meno 
questo (quando possibile) :  ti  sparo i  dati su un foglio excel e te li 
sistemi  come ti pare di volta in volta. L' esperienza mi dice che spesso 
funziona. 
 
 
 
 
 
 

 ti si chiude la app fatture???
 
Si è vero,  questo è un limite.
 
del resto non si puo avere la moglie ubriaca la botte piena e l'uva ancora sull'albero.
 
 
Pero io personalmente ho ottenuto più vantaggi che problemi dalla divisione
 
 
poi se sò che quando si fanno le fatture occorre un singolo dato di bilancio
faccio in fretta a inserirlo nella applicazione delle fatture
 
se poi la signora deve consultarsi tutto il bilancio allora interrompe le fatture e se lo va a guardare.   
la prossima volta vedrai che si ricorda prima  :)  :)
 
.

 Pero io personalmente ho ottenuto più vantaggi che problemi dalla divisione
 
 
contento tu contenti tutti :-)
personalmente vedermi chiudere una app sulla quale magari stavo editando 
solamente per visualizzare un dato che fatalità si trova in un'altra app 
lo trovo agghiacciante.
 
ma toglimi una curiosità...metti che stai facendo una scrittura 
contabile con 30 conti in dare e 30 conti in avere...
sei arrivato a compilare i 30 in dare e sei a 29 in avere, ti chiama 
tizio che vuole sapere un prezzo di un preventivo che gli avevi fatto il 
giorno prima...tu clicchi su preventivi e ti si chiude l'app di 
contabilità mandando a putt... la scrittura che stavi compilando? o 
magari salvandola sbilanciata?
 
 
 
ciao
BFS
 
 
 
 


 
 
Penso esista la possibilità tecnica di separare le applicazioni in più 
moduli, ma eseguirli all'interno di un'unica sessione: legando i moduli 
all'applicazione principale nei "Riferimenti".
 
Saluti.