Newsgroup: it.comp.appl.access
Titolo: Riferimenti nel codice VBA e lentezza apertura mde

Salve a tutti.
I riferimenti VBA: la storia infinita ...
Per comodità e manutenibilità ho raggruppato tutto il codice VBA di interesse generale in un file Util.mdb che ho poi
convertito in mde.
Util.mde è inserito fra i riferimenti VBA delle varie applicazioni e distribuito insieme ai corrispondenti mde.
Fino a qualche settimana fa tutto ha funzionato egregiamente.
Poi ho avuto la bella idea di ristrutturare l'ambiente di sviluppo facendo uso intensivo delle macchine virtuali.
Ho creato quattro VM dedicate ciascuna ad una versione di Office dalla 97 alla 2003, ma i sorgenti li ho lasciati
esattamente dov'erano nella macchina host.
La macchina host viene vista da ciascuna VM come un server e le cartelle di sviluppo su di essa vengono viste come unità
di rete mappate.
Ho verificato che nel file mdb di ogni applicazione il riferimento ad Util.mde fosse corretto, ed infatti Access l'ha
aggiornato per rispecchiare la nuova posizione relativa: \\192.168.0.1\Sviluppo\Access\Util.mde
L'unica cosa che non mi piaceva era il puntamento all'unità di rete non tramite la mappatura, ma non ci ho dato peso più
di tanto.
Quindi ho continuato a lavorare come niente fosse distribuendo gli aggiornamenti delle varie applicazioni.
Poi qualcuno ha telefonato:
Cliente: "Ho lanciato il programma ma non parte"
Io:	"Hai messaggi di errore ?"
Cliente:	"No: c'è una schermata grigia ..."
Io:	"Vedi la clessidra ?"
Cliente:	"Sì"
Io:	"Prova ad aspettare ancora un po' "
	...
Cliente: "Ora è partito"
Io:	"Bene, se dovesse rifarlo indagherò"
Il tempo di avvio è stato dell'ordine di un paio di minuti, mentre lo stesso programma apriva la schemata iniziale di
login in pochi secondi.
Ma nei giorni successivi è stato necessario aspettare anche quattro minuti (!) per avviare il programma.
Dopo lunghe elucubrazioni e per esclusione, alla fine mi si è accesa la lampadina: saranno mica i riferimenti ?
Ho copiato il file Util.mde nella VM in c:\programmi, ho aggiornato i riferimenti nel file mdb dell'applicazione e ne ho
ricreato il file mde: l'apertura ha richiesto meno di cinque secondi.
Bingo !
Dunque è chiaro che all'avvio del programma, se i riferimenti puntano ad un'unità remota, Access perde una valanga di
tempo a tentare di risolverli (forse addirittura interroga il DNS ?!?!).
Poi, una volta concluso che non riesce a trovarli, li cerca in locale, dove effettivamente si trovano (fra parentesi,
nella medesima cartella del file mde dell'applicazione !).
Qualcuno ha qualche brillante idea per continuare ad avere una sola copia di Util.mde residente sul "server" riferita
dalle varie applicazioni, senza che si presentino gli effetti collaterali descritti ?
Grazie
Vincenzo Turturro
Certificato Eucip Core Level
ITA 0000-002299 del 14/05/2007
---------------------------------------------
il sito comune di it.comp.appl.access:
http://www.sitocomune.com
---------------------------------------------
risorse Access:
http://www.accessgroup.it
---------------------------------------------
Il sito comune di it.comp.as400
http://www.faq400.com
---------------------------------------------

 Grazie
mmm...
potresti controllare/ricollegare i riferimenti all'avvio del programma
Application.References.AddFromFile "c:\Documents and Settings\Max\Desktop\test.mde"
ovviamente il problema è che il riferimento esiste già. Per cui lo dovresti rimuovere e riallegare.
sul SC (6.204) c'è una funzione di Alex per estrarre la lista dei riferimenti.
Butto due idee, in entrambe usi la funzione in avvio
prima idea... vedi che valore ha .IsBroken e magari puoi "ragionare" su quello.
seconda, chiamando il riferimento "pippo", lo puoi rimuovere e ricollegare, puntando al file che si trova nella posizione c:\...
Ciao,
Max

 nella medesima cartella del file mde dell'applicazione !).
Se l'indirizzo e' composto cosi' come l'hai descritto, non credo che 
intervengano i dns tramite i quali solitamente il pc client risolve 
l'indirizzo
Hai provato a eliminare completamente le informazioni relative ai dns ?
Sarebbe la prova per capire se sono quelli o no
Se senza non si riuscisse ad aprire il programma, allora vuol dire che 
qualcosa c'entrano di sicuro
Ciao
RobertoA

 nella medesima cartella del file mde dell'applicazione !).
Vincenzo, fammi capire, cosa significa il periodo che ho quotato?
Che sulla rete l'accesso a certe risorse sia piu' lento e' un fatto.
Il problema sta nel "se non riesce a trovarli". Perche' non li trova?
Mettiamola cosi'. Se l'indirizzo di rete non viene trovato qualsiasi 
programma ci mette tra i 30 ed i 60 sec a capirlo perche' quel tempo e' 
gestito dai driver di rete. A suo tempo con una applicazione vb mi 
accorgevo se mi avevano "taroccato" la macchina remota  proprio dai 
tempi di risposta che si allungavano.
Anche esplora risorse, se hai un collegamento ad un'altra macchina e 
quella e' irragiungibile, ci mette una vita a rispondere.
-- 
ac
y-1=x


wrote:

Bisognerebbe verificare che il server con i DNS sia configurato
correttamente, e al limite fare dei test anche sulll'antivirus, che
non sia quello...


Vincenzo Turturro


quella e' irragiungibile, ci mette una vita a rispondere.
Infatti non ho chiesto aiuto per capire cosa sta succedendo, ma come fare per aggirare il problema.



Vincenzo Turturro


 presenta questo comportamento.
Ciao Vincenzo,
perdonami ma non ho ben capito,
prima parli di aver fatto macchine virtuali, su una macchina hai 4
macchine virtuali + il server con indirizzi ip differenti, macchine
differenti.
Ora dici che presso il cliente il file util.mde sta in c:\ della
macchina... mi sono persa...
Hai 5 macchine virtuali, di cui una è il server e le altre quattro
contengono i file frontend mdb dell'applicazione da te in laboratorio.
Dal clientehai che cosa? La stessa configurazione? Oppure in remoto si
connettono in vpn da te?


 presenta questo comportamento.
A non ti interessa sapere se i dns c'entrano o meno ?
E come speri di risolvere il problema se non sai qual'e' a causa ?
Ciao
RobertoA

 Infatti non ho chiesto aiuto per capire cosa sta succedendo, ma come fare per aggirare il problema.
vevo capito un'altra cosa. Che "ancora" il motivo non fosse chiaro.
Se il motivo e' chiaro non dovrebbe essere un problema aggirarlo. Nel 
caso di indirizzo fasullo credo che sia sufficente fare un "ping".
-- 
ac
y-1=x

>>Hai provato a eliminare completamente le informazioni relative ai dns ?

Come ho già detto ad altri, la causa l'ho già individuata: il problema dipende dalla collocazione di un file nei
riferimenti che nell'ambiente di sviluppo sta su un server (virtuale o fisico non è importante) mentre dal cliente sta
sulla medesima macchina dell'applicazione.
Che poi questa situazione coinvolga i DNS, la LAN o l'FBI che controlla il mio cliente non mi interessa niente: non
posso (e non voglio) alterare la configurazione di rete del cliente.
Quindi devo intervenire a monte, cioè nel'ambiente di sviluppo.


3824
Sul pc di sviluppo utilizzo n macchine virtuali
Da ogni macchina virtuale accedo alla macchina fisica considerandola a tutti gli effetti come se fosse un server in
rete.
Nella macchina virtuale x il file mdb dell'applicazione ha un riferimento al file \\192.168.0.1\sviluppo\access\util.mde
(che sta sul server, cioè sulla macchina fisica).
Tale riferimento ovviamente viene mantenuto anche all'interno del file mde dell'applicazione.
Il file mde dell'applicazione viene distribuito al cliente su una macchina fisica insieme al file util.mde e tutti e due
vengono posizionati nella medesima cartella c:\programmi\sml .
Il problema è che all'avvio dell'appicazione questa prima di tutto cerca di rintracciare util.mde nel percorso che ha
specificato al suo interno, percorso che presso il cliente non esiste.
Quando finalmente capisce che non lo trova, allora lo cerca in c:\programmi\sml, lo trova e parte.


caso di indirizzo fasullo credo che sia sufficente fare un "ping".
Purtroppo no.
Infatti la "ricerca dei riferimenti" parte prima di qualsiasi altra cosa e, tutto sommato, è giusto che sia così visto
che fra i riferimenti ci sono anche componenti fondamentali per l'esecuzione.
In ogni caso ho provato a mettere un msgbox come prima istruzione nella routine associata alla open della form che viene
aperta automaticamente all'avvio del programma, ma ho aspettato alcuni minuti prima di vederla comparire.
Quindi non posso fare niente prima dei tentativi di Access di risolvere i riferimenti.
E dunque devo per forza agire al momento della creazione del file mde.
Ed è qui che chiedo aiuto.


 Ed è qui che chiedo aiuto.
Perche' non fai il contrario?
Colleghi prima sul percorso locale e poi sul percorso di rete.
-- 
ac
y-1=x



Non capisco ...


 y-1=x
Ciao.
-- 
Sergio MAZZA 

 Non capisco ...
Ed hai ragione. Mi ci e' voluto un po' ma forse ora ho capito dov'e' la 
difficolta'.
Immagino tu abbia gia' visto questi due articoli:
http://www.accessmvp.com/djsteele/AccessReferenceErrors.html
http://www.mvps.org/access/modules/mdl0022.htm
-- 
ac
y-1=x

 percorso di rete)...
Ciao Serginho. Sono un po' "tardo" effettivamente qualche problema c'e'.
Non puo' farlo perche'
1) Quando potrebbe intervenire il danno e' gia' avvenuto (e questo 
sarebbe, forse, superabile)
2) E' un MDE (e questo e' un vincolo, credo, non facilmente superabile)
-- 
ac
y-1=x

 Quando finalmente capisce che non lo trova, allora lo cerca in c:\programmi\sml, lo trova e parte.
Ciao Vincenzo,
tu al cliente dai il qualcosa.mde + util.mde
Facciamo un passo indietro, tu hai un qualcosa.mdb da trasformare in
mde, per distribuirlo al tuo cliente
A questo punto, tu puoi ancora intervenire nel qualcosa.mdb. Perchè
non fai una macro, oppure una routine, dove gli dici di sostituire
l'indirizzo
192.168.01. con
c:\programmi\sml   ?
:)
Oppure puoi fare il contrario, nel tuo ambiente di sviluppo nel file
inverti, metti prima il riferimento c:\programmi\sml\util.mde. Lui nel
tuo ambiente di sviluppo non lo trova, passa alla riga successiva e va
sul 192.168.0.1...  Prova a vedere se da te è tanto lento, ma almeno
quando lo distribuisci non hai problemi con i clienti.
Samantha
3824

3824


 e là fra le varie macchine virtuali ed i vari clienti: un incubo !
Quanto dici è vero.  Ma allora, prima della compilazione,  da te in
laboratorio potresti:
1) Fare la copia di util.mde in c:\programmi\sml
2) Sostituire l'indirizzo 192.168.0.1 con c:\programmi\sml
3) Compilare l'mde (ora non si arresta)
4) Eliminare  c:\programmi\sml\util.mde
5) Risostituire nel tuo .mdb l'indirizzo da c:\programmi\sml a
192.168.0.1
E' vero che è macchinoso, ma se ti studi un file batch che fa la copia
del file util.mde e poi te lo elimina, e cambiare nel tuo mdb da ip-
rete a cartella locale, e il contrario, otteresti un file.mde con
tutti i riferimenti corretti
Le copie di util.mde vengono eliminate una volta che hai finito di
fare la compilazione
è macchinoso, ma visto che puoi avere un'unica referenza x lo stesso
componente...

 quando lo distribuisci non hai problemi con i clienti.
La situazione di VT mi sembra a parti invertite ma la sostanza non cambia.
Questa potrebbe essere una furbata anche se, a lume di naso,
credo che il sistema tenta di risolvere "tutti" i riferimenti
e quindi il tentativo di collegare sulla rete lo faccia comunque.
-- 
ac
y-1=x

> Settings\Max\Desktop\test.mde" 
Lo temevo infatti... ma non ho testato la cosa...
purtroppo non ho altre idee
Ciao,
Max

 2) E' un MDE (e questo e' un vincolo, credo, non facilmente superabile)
Ciao Alessandro;
ma se lavora con le VM perché non crea lo stesso ambiente dal cliente?


 Sergio MAZZA
Perchè dal cliente non può lavorare con le macchine virtuali.
Altrimenti lo obbliga ad acquistare le licenze...
Situazione VT LAB:
1 macchina fisica
5 macchine virtuali
 - 1 server
 - 4 client
 Il lato front-end si trova sui client virtuali. Il file util.mde che
gli crea problemi è sul server virtuale, e lo interroga con indirizzo
192.168.0.1
Situazione VT Cliente
1 macchina fisica
Il lato frontend si trova sulla macchina fisica. Il file util.mde si
trova sulla stessa macchina fisica, su c:\programmi\sml\...
Lui ha standardizzato il suo laboratorio,  x tutti i clienti con cui
lavora.
Almeno così mi sembra di avere capito.
Ciao,
Samantha
3824


Al di la del fatto specifico, un "refresh" dinamico dei riferimenti 
sarebbe comunque una buona cosa in generale. Ci toglierebbe da un sacco 
di problemi. Faccio il tifo per VT. I clienti come i figli "so piezze e 
core", li devi lasciar fare altrimenti si incazzano (nel loro piccolo 
come le formiche [cit]). Com'e' il mare d'inverno? e' una vita che non 
lo vedo.
-- 
ac
y-1=x

Ciao.


3824


 una vita che non lo vedo.
Ancora più bello che d'estate.. poi se ti affacci su Napoli, Capri e Sorrento.. beh
-- 
-- 
MAssimiliano Amendola
www.accessgroup.it
Cisa - Conferenza Italiana Sviluppatori Access

 ---------------------------------------------
-- 


 ha scritto nel messaggio 
news:fee8089a-1013-4b64...@e10g2000prf.googlegroups.com...
Perchč dal cliente non puň lavorare con le macchine virtuali.
Altrimenti lo obbliga ad acquistare le licenze...
Situazione VT LAB:
1 macchina fisica
5 macchine virtuali
 - 1 server
 - 4 client
 Il lato front-end si trova sui client virtuali. Il file util.mde che
gli crea problemi č sul server virtuale, e lo interroga con indirizzo
192.168.0.1
Situazione VT Cliente
1 macchina fisica
Il lato frontend si trova sulla macchina fisica. Il file util.mde si
trova sulla stessa macchina fisica, su c:\programmi\sml\...
Lui ha standardizzato il suo laboratorio,  x tutti i clienti con cui
lavora.
Almeno cosě mi sembra di avere capito.
Ciao,
Samantha
3824
[risposta]
Un attimo; ora sono io il tardo (un po' per uno...).
Se il cliente ha un solo pc con FE e BE, VT deve crearsi la VM con lo stesso 
SO del cliente. O no?
Ciao.
-- 
Sergio MAZZA 

Com'e' il mare d'inverno? e' una vita che non lo vedo.
E' come il Krapfen (cioccolato/crema/semplice)... E' una vita che non lo 
vedi, ed č buonissimo!


 ---------------------------------------------
Ciao.
-- 
Sergio MAZZA 

 Sergio MAZZA
Ciao Sergio,
ma Vincenzo non vuole riprodurre la situazione del cliente.
Lui da lui, ha un server virtuale, dove mette le varie utility. Ha 4
client virtuali, con diversi s.o. e diverse versioni di access.
A questo punto, penso che testi tutti i suoi mde dai vari client
virtuali.
Quindi mille situazioni dai clienti, una sola nel suo laboratorio.  Ed
è questo il problema, che se da una parte la sua procedura è
standardizzata in laboratorio, quando la distribuisce al cliente, la
procedura standardizzata non si aggiorna dinamicamente difronte alla
situazione aggiornata del cliente.
:D La sua metodologia ha un'unica falla: quando distribuisce
l'applicativo dal cliente, la ricerca del file util.mde si "inceppa"
nella ricerca del server  virtuale che in laboratorio c'era, ma dal
cliente no.
Tipo da me ho il problema simile:
Database diviso in front end e back end
Il mio back end si trova su z:\
Dal mio cliente si trova su n:\
Prima di distribuire la nuova versione di frontend, devo collegare le
tabelle collegate. Perciò, ogni volta devo:
1) inviare la versione con macro con nome autoexecsav (quella che
disabilita lo shift)
2) Collegarmi dal cliente
3) aprire il frontend, e collegare le tabelle da z:\ a n:\
4) salvare il nuovo frontend
5) ne faccio una copia
6) entro sulla copia come amministratore, rinomino la macro come
autoexec. chiudo e riapro senza shift. chiudo.
7) distribuisco il frontend.
Avete qualche idea migliore?
Samantha

 ha scritto nel messaggio 
news:b49b5073-ed16-4c0d...@e25g2000prg.googlegroups.com...
Ciao Sergio,
ma Vincenzo non vuole riprodurre la situazione del cliente.
Lui da lui, ha un server virtuale, dove mette le varie utility. Ha 4
client virtuali, con diversi s.o. e diverse versioni di access.
A questo punto, penso che testi tutti i suoi mde dai vari client
virtuali.
Quindi mille situazioni dai clienti, una sola nel suo laboratorio.  Ed
č questo il problema, che se da una parte la sua procedura č
standardizzata in laboratorio, quando la distribuisce al cliente, la
procedura standardizzata non si aggiorna dinamicamente difronte alla
situazione aggiornata del cliente.
:D La sua metodologia ha un'unica falla: quando distribuisce
l'applicativo dal cliente, la ricerca del file util.mde si "inceppa"
nella ricerca del server  virtuale che in laboratorio c'era, ma dal
cliente no.
Tipo da me ho il problema simile:
Database diviso in front end e back end
Il mio back end si trova su z:\
Dal mio cliente si trova su n:\
Prima di distribuire la nuova versione di frontend, devo collegare le
tabelle collegate. Perciň, ogni volta devo:
1) inviare la versione con macro con nome autoexecsav (quella che
disabilita lo shift)
2) Collegarmi dal cliente
3) aprire il frontend, e collegare le tabelle da z:\ a n:\
4) salvare il nuovo frontend
5) ne faccio una copia
6) entro sulla copia come amministratore, rinomino la macro come
autoexec. chiudo e riapro senza shift. chiudo.
7) distribuisco il frontend.
Avete qualche idea migliore?
[risposta]
Far diventare il tuo z: l'n:; altrimenti di che standardizzazione stiamo 
parlando?
Samantha
[risposta]
Ciao.
-- 
Sergio MAZZA 

 3824
E neanche il comando DOS Subst:
es.
subst n: z:\nomeCartella
Ciao.
-- 
Sergio MAZZA 

 Sergio MAZZA
Hai ragione, semplicemente non ci ho mai pensato! Ora ho mappato una
nuova unità direte come n:\nomecartella...
Aggiungo questo accorgimento al mio manuale del piccolo chimico :D
Ciao,
Samantha
3824

 
Al contrario di quello che potresti pensare (visto la mia natura 
bradipesca) la "zona" da te citata mi e' capitato di vederla anche 
d'inverno. Recentemente, come si fa/faceva con le figurine, ho fatto il 
ce l'ho/"me amanca" delle regioni italiane. Ho l'album completo compresi 
i territori extracomunitari di SCV e SNM.
-- 
ac
y-1=x

 compresi i territori extracomunitari di SCV e SNM.
extracomunitari?
SNM?....
ecchevordě?
non avrai, mica, esagerato con il novello?
^__^
Ciao Alex
Daniele

 
-- 
ac
y-1=x

 y-1=x
Ciao Alessievich.
Io penso che sarebbe superabile il problema visto che lavora con le VM, non 
credo ci sia problema a ricreare l'ambiente del cliente...
Ciao.
-- 
Sergio MAZZA 

 Daniele
-- 



Daniele 

 cmq grazie MA :<))
oh vedi che avevo sbagliato sigla. Vado all'angolo che e' gia' 
tappezzato di ceci.
-- 
ac
y-1=x

 y-1=x
Daniele 

 non avrai, mica, esagerato con il novello?
Ciao Daniele.
Non non ha esagerato con il novello.
A parte l'errore sulla sigla (quella corretta è RSM), la Repubblica di San
Marino e lo Stato della Città del Vaticano non sono membri dell'Unione
Europea, anche se entrambi hanno adottato l'euro come moneta corrente.
-- 
PBsoft di Gabriele Bertolucci
www.pbsoft.it
skype:pbsoftsolution


Ciao Gabriele
premesso che era una battuta.... quindi avevo ragione al 50%.
ma questo non vuol dire che ad Alex il novello non piace al 50% ;)
ma, credo, che nessun italiano pensa che i due stati siano 
"extracomunitari",
come sarebbe giusto nella definizione internazionale, ma tuttalpiù li
considera come "extraterritoriali".
:D
buon WE
Daniele

 considera come "extraterritoriali".
"extracomunitari", so' "extracomunitari"
ciao Daniele  ;<)
-- 
ac
y-1=x

 ciao Daniele  ;<)
Ciao Alex
Buon WE
Daniele