Newsgroup: it.comp.appl.access
Titolo: dio maledica la M$

ho sviluppato un applicativo in access, č piuttosto tirato: uso il jro per
tenere sincronizzate le repliche del database centrale con quelli sui
portatili dei rappresentanti, uso una dll esterna in C++ per scompattare il
file mdb che funge da file di scambio (deve stare su un floppy) uso la
classe makecab della dll catsrvut.dll per creare il file cab, uso adox per
far puntare il FE su diversi db (master, replica, etc) e cosě via... sul mio
win 2k funziona perfettamente, quando vado a creare il file di installazione
con il runtime di access 2k, a installarlo su altri pc (w98 e w2000 server)
e a eseguire il tutto... il runtime non riesce a trovare alcune funzioni di
vb, eppure i famigerati "office 2k development tools" riconoscono e
inseriscono automaticamente nel pacchetto la vb6it.dll, sembra perň che non
venga registrata.... infatti mě da "oggetto o libreria non trovati" persino
su funzioni come trim.
Qualcuno ha idee?


Il problma non è vb6. E' il registro dei riferimenti che da PC a PC cambia
ad ogni compilazione. Infatti Access, talvolta non riconosce l'ordine delle
librerie caricate e ha bisogno di una mano per ricostruire le registrazioni.
Sui FE per risolvere il problema dei togliere tutti i riferimenti a librerie
inutili ove ce ne siano.
Togliere tutti i riferimenti possibili e ricompilare.
Ricompilare ogni volta che reinserisci i riferimenti (ad uno ad uno) alle
varie librerire.
Non so se con gli aggiornamenti as SR1 e SP3 il problema è stato risolto.
Di tanto in tanto capita anche a me... anche su WinXP.
Ciao

 Di tanto in tanto capita anche a me... anche su WinXP.
su winXP i devtools non funzionanano proprio...

 Di tanto in tanto capita anche a me... anche su WinXP.
su winXP i devtools non funzionanano proprio...


Prova a fare l'upgrade a SP3.
Ciao

 librerie caricate e ha bisogno di una mano per ricostruire le
registrazioni.
E' no: non è colpa sua se non trova le librerie settate nei riferimenti dove
s'aspetterebbe di trovarle.
Si deve fare attenzione quando si creano i pacchetti d'installazione...
Ciao.

 ha scritto nel messaggio
news:jkt2b.264842$Ny5.8...@twister2.libero.it...

Ti assicuro che nel momento in cui aggiorno i FE con piccole variazioni (a
volte solo di tipo grafico) Access si impappina.
Ciao

 volte solo di tipo grafico) Access si impappina.
A me non capita.
Ciao.

 Prova a fare l'upgrade a SP3.
grazie per la dritta, proverò oggi
PS: ho fatto alcune prove ieri, se installo access e copio manualmente i
file sulla macchina target non ho problemi, invece se uso il runtime oppure
access+pacchetto installazione generato da ODETools và tutto a puttane...
stò considerando NSIS come pacchetto per generare istallazioni, ma si deve
creare tutto a colpi di script...

 creare tutto a colpi di script...
Premetto che non ho mai avuto necessità di settare una montagna di
riferimenti in un .mdb (i soliti cinque o sei) sia perchè non utilizzo
controlli .OCX, sia perchè mi guardo bene da usare sia DAO che ADO
all'interno dello stesso progetto.
Comunque, mai avuto problemi di questo genere.
Una domanda: il FE che installi è un .MDB o .MDE?
Ciao.

 Una domanda: il FE che installi è un .MDB o .MDE?
per ora .mdb, una volta finita la fase di testing .mde

un grazie grande come una casa una prova preventiva ha risolto gran parte
dei problemi, ho imparato pure una cosa nuova, non credevo fosse possibile
"compilare" (di che tipo di compilazione si tratti poi lo ignoro) senza
creare un file .mde, è veramente una funzione molto comoda per scoprire
errori che altrimenti verrebbero fuori solo a runtime.
la prossima prova la faro con un pacchetto di installazione utilizzando gli
ODETools

 Si deve fare attenzione quando si creano i pacchetti d'installazione...
io credo che sia la M$ che dovrebbe fare attenzione a non vendere cagate a
prezzi esorbitanti (anni fà office 2k dev costava 3 milioni... io l'ho fatto
comprare a 2 ma non sono pochi...) specialmente perchè i pacchetti di
installazione creati fanno schifo, sono lenti, graficamente sgradevoli, e
non funzionano con windows XP, cosa che è comune anche ai devtools di office
xp dev... infatti con la prossima versione di office la m$ corre ai ripari
riscrivendo il package wizard da zero (
http://www.microsoft.com/italy/office/preview/editions/accessdav.asp
 ), ma
io mi guarderò bene dal dargli nuovamente fiducia...
credo che passerò a qualcosa mi molto più consistente...

 per ora .mdb, una volta finita la fase di testing .mde
Negli .MDE i riferimenti sono a sola lettura, di conseguenza sulla macchina
di destinazione non possono essere diversi da come li avevi creati tu.
Non esiste che possano cambiare d'ordine o roba del genere.
Saluti.

 credo che passerò a qualcosa mi molto più consistente...
In bocca al lupo.
Ciao.

 xp dev
Ah, dimenticavo: non funzionano i TUOI  pacchetti d'installazione con win
'XP...
Saluti.

 ha scritto nel messaggio
news:7Z43b.269338$lK4.8...@twister1.libero.it...


probabilmente perchč TU da buon mangiatore di quiche non usi nessuna
libreria esterna ma ti limiti ad usare magari le macro, altrimenti ti
comparirebbe il classico messaggio "impossibile trovare msdart.dll",
problema comune ad altri tools per il packaging non aggiornati.

 problema comune ad altri tools per il packaging non aggiornati.
Mai visto nulla del genere ... e di Setup (dal '97 in su) ne abbiamo
installati decine su qualunque tiop di configurazione.
Comunque sei stato parco di dettagli: difficile aiutarti sul serio.
Per esempio: dici di usare ADOX.
Ma non è che utilizzi la versione 2.7 senza aver aggiornato il PC di
destinazione con analoga versione di MDAC?
Saluti.

 il risultato comunque è che si incasina fortemente...
Ok, abbiamo capito che è un problema di registrazione librerie.
Che versione di ADO usi sulla macchina di sviluppo?
Se diversa dalla 2.1 che propone l'installer, aggiorna manualmente MDAC XX
sulla macchina dell'utente.
Ciao.

2.5 su ado, jro e adox

2.5, il problema *non è* sul quelle librerie ma su vb6it.dll che è
registrata, ma non trovata... ma sembra che OneEDP m'abbia dato proprio la
dritta giusta per risolvere il problema...

 ha scritto nel messaggio
news:biijad$joh$1...@lacerta.tiscalinet.it...

VBA è un linguaggio interpretato. Access permette di ottimizzare il processo
di interpretazione precompilando il modulo in modo da velocizzare
l'esecuzione del codice alla chiamata successiva.
In effetti mde contiene una compilazione grezza del codice, infatti in
realtà non viene generato un codice oggetto e poi un eseguibile...
Prima di distribuire i front-end è consigliabile che tu esegua una
compattazione, una compilazione del progetto (non inteso adp), poi in teoria
ogni maschera con modulo, ogni query (per mettere in moto l'ottimizzatore
Jet di Access ed eventualmente alcune oggetti che fanno uso di ODBC)...
Le cose si complicano se i client non hanno upgrade omogenee delle SR1-A o
SP3 di office... perché vb6 è responsabile di altre porcherie... tipo
"errore di acesso al file, connessione o unità rete persa... (o una cosa del
genere)".
MDAC 2.8 non risolve questi problemi... è un'altra storia.
Tenere sempre tutto aggiornato è la regola... ma un backup prima di ogni
upgrade non guasta.
Ciao
Daniele