Newsgroup: it.comp.appl.access
Titolo: Riferimenti access

Ciao a tutti, avrei da porvi un quesito: come posso fare per creare un
pacchetto di installazione che mi installi sull'hd sia il file mdb, sia
alcuni file (che trovo nei riferimenti) per evitare di controllare tutti i
pc sui quali dovrà andare l'mdb? E se è possibile, come mi auguro, quanto
conta o influisce la versione diversa di access anche se compatibile (es.
acecss 2000 e xp)?
Grazie Stefano
PS
Non ho bisogno del runtime perchè tutti i pc hanno access...

 ha scritto nel messaggio
news:Eqzob.81365$vO5.2...@twister1.libero.it...

I riferimenti cosa intendi.....????
Se sono le librerie alle quali accedi non c'è problema perchè
ti basta distribuire la versione MDE.
Se invece hai degli OCX o DLL allora li devi oltre che installare
registrare.
Per installarli hai la possibilità di includerli in un Pacchetto
d'installazione
che poi provvede anche a registrarli AUTOMATICAMENTE.
Prova a cercare "Inno Setup 3.0" è Ottimo e FREE....!!!
@Alex.


Prova con l'MDE, se ti ho consigliato questo sistema prova a fidarti...., ma
fai
una prova così da capire meglio la cosa.....!!!!!!
Nel pacchetto d'installazione non mettere cose delle quali non hai LICENZA.
Limitati ad inserire il tuo applicativo e le eventuali Immagini, non avrai
problemi
di Reference se hai la versione MDE....!(Entro certi limiti di
compatibilità)
Ciao.
@Alex.

 compatibilità)
Magari fosse sempre così come dici.
Purtroppo non basta. Io ed il mio collega Gionata siamo riusciti a capire
che, per esempio, per risolvere i problemi di reference in maniera un po'
più sicura, bisogna fare un decompile e poi di nuovo ricompilare il file
MDB. Successivamente puoi farti l'MDE.
-- 
Gabriele Bertolucci
PBsoft 
www.pbsoft.it

Gabriele Bertolucci wrote:
||| Prova con l'MDE, se ti ho consigliato questo sistema prova a
||| fidarti...., ma fai una prova così da capire meglio la
||| cosa.....!!!!!!
||
|| Io mi fiderei volentieri.
OK
||
||| non avrai problemi di Reference se hai la versione MDE....!(Entro
||| certi limiti di compatibilità)
||
|| Magari fosse sempre così come dici.
||
|| Purtroppo non basta. Io ed il mio collega Gionata siamo riusciti a
|| capire che, per esempio, per risolvere i problemi di reference in
|| maniera un po' più sicura, bisogna fare un decompile e poi di nuovo
|| ricompilare il file MDB. Successivamente puoi farti l'MDE.
||
Come si fa il "decompile"?
grazie
Stefano

 MDB. Successivamente puoi farti l'MDE.
MS consiglia di utilizzare il /Decompile solo per riparare .mdb danneggiati.
Meglio reimportare tutto in un nuovo .mdb.
Tuttavia, le cause dei broken references dovrebbero essere altre.
Anzitutto il mediocre installer (lo stesso fornito col vecchio VB) che
registra correttamente un .OCX su tre.
Per questo molti developers evitano scrupolosamente l'utilizzo di controlli
ActiveX, peraltro di scarsa utilitŕ con l'ambiente FE di Access.
Oltre a ciň a mio avviso esistono problemi di registrazione legati alle
librerie ADO.
Sarŕ un caso ma le installazioni runtime basate su DAO e prive di controlli
aggiuntivi vanno sempre a buon fine.
Bye

 Bye
Come mi piace quando parli così....!!
Gli OCX sono "ROBA" da usare solo in casi Eccezionali.
Per quanto i riguarda MAI, se trovo info sulle API cerco sempre
di sfruttare direttamente le dll dedicate e ricrearmi io il controllo via
codice.
Purtroppo questo non è sempre possibile, ma con ProgressBar e StatusBar
e altri controlli che si appoggiano alla ComCtl32.dll è stupido affidarsi
a INGOMBRANTI accessori che con 10righe di codice si rifanno....!!!!
Ciao.
@Alex.

 a INGOMBRANTI accessori che con 10righe di codice si rifanno....!!!!
E si potrebbe continuare: Toolbar control, Calendar, CommonDialog, MsComm,
etc., etc. sono tutti controlli facilmente sostituibili, il più delle volte
addirittura senza ricorrere ad API.
Con un pò di pazienza anche il problema del disegno dei BarCode nella
reportistica si risolve a codice Visual Basic ... l'unico controllo
difficilmente sostituibile è il TreeView: controllo la cui utilità pratica è
per la verità scarsa (è funzionale per rappresentare una distinta base a n
livelli, non certo per i menù come fanno molti).
Ciao!

> Come si fa il "decompile"?
<percorso installazione office>\MSACCESS.EXE <nomefile.mdb> /decompile


 librerie ADO.
Su questo mi piacerebbe sentire voci un po' più ufficiali da Microsoft,
visto che continuiamo a scaricare MDAC sempre più aggiornati ma i problemi
sembrano non diminuire :-)


 l'unico controllo difficilmente sostituibile è il TreeView
Aggiungiamo poi che la documentazione che lo accompagna è praticamente
inestistente.


 sembrano non diminuire :-)
Non c'hai ancora detto quali siano i riferimenti che vi creano problemi :-)
Comunque anche in passato, non solo su questo ng., si è parlato parecchio di
problemi relativi alla corretta installazione di ADO.
Ripeto: con le librerie standard + DAO non rilevo problemi.
Bye

 Come fai a non ricorrere alle API e nemmeno ai controlli che hai nominato?
Il Toolbar te lo fai con pulsanti di comando e opzione.
Il calendar ... trovi un mucchio di calendari in puro Access, anche free,
sul web.
Il CommonDialog: ne riparliamo appena ho tempo d'approfondire del codice che
puoi trovare nel .mdb di setup di ODE '97 (ne riportava uno stralcio Giorgio
PRX pochi giorni fa sul ng.)
MsComm: solo con API.
Bye

 ha scritto nel messaggio
news:NNwpb.87839$vO5.3...@twister1.libero.it...

Ricodo che le prime installazioni di pacchetti fatti con VB6 e ADO
mi facevano impazzire....!
Sai come ho risolto....?
Con Access, non sviluppo quasi più nulla con VB, se non giochini(io li
chiamo così)
privati per amici.......!
@Alex.

 privati per amici.......!
Alessandro, Alessandro ... parla (anzi scrivi) a basso voce: se ti sentono
quei due o tre invasati da iclvb si apre un megathread da far tremare le
vene ai polsi  :-)
Bye

 ha scritto nel messaggio
news:gJxpb.89345$e6.32...@twister2.libero.it...

Già, ma non è per dire che Access è meglio, è per sottolineare
che io sono TONTO con VB....!!
;-)
Ho messo una pezza....??
Ciao.
@Alex.

 ha scritto nel messaggio
news:bo6cgd$7qm$1...@lacerta.tiscalinet.it...

Io ancora spero di poter usare VB come Access.
Il fatto che ancora non ho ben chiaro è questo,  sono io che sono
di coccio oppure Access per programmare gestionali per basi dati
è una spanna più su rispetto a VB?Per esenpio quello che non ho mai
capito è perchè Access ha una reportistica da paura e VB c'ha delle cagate
pazzesche ( leggi CR e Data Report).E dire che VBA e VB sono praticamente
identici soprattutto VB6 e Access 2000 sembrano uguali.Per non dire delle
maschere continue
che per farle in VB devi crearti un ocx con DataRepeater ed impazzire
letteralmente per
agganciarci i dati oppure usare i DataGrid che Dio ce ne scampi.Resta il
fatto che dire che programmi in VB
fa più fico di dire che programmi in Access anche se uno magari si appoggia
a SQL Server 2000 e con Access
ci fa solo il FE.
Sunrex

 Ho messo una pezza....??
Eh, eh, eh.

 fatto che dire che programmi in VB
La verità è che molti (anche software house piene di gente) scelsero VB
pensando che fosse un "compilatore" ... nel senso DOS del termine.
La qual cosa sarebbe stata tecnicamente vantaggiosa poter distribuire .exe
privi di componenti di Runtime, come fanno i Delphisti.
La verità è molto diversa, come ben sai (ocx, crystal reports, etc. stanno
fuori) ... eppure anche il Faqqone di icaa ha le idee nebulose sulla
faccenda!
... la forza del marketing  :-)
Bye

 problemi relativi alla corretta installazione di ADO.
I problemi che abbiamo avuto riguardavano ADO.



Complimenti, sei stato un artista, te ne sei uscito alla grande. Clap
MAssimiliano