Newsgroup: it.comp.appl.access
Titolo: Mde come libreria esterna

Creo un MDE e lo metto come riferimento di un altro MDE (diventa quindi una
libreria esterna di quest'ultimo) tutto funziona. Se però modifico il primo
MDB, creo il suo MDE e lo sovrascrivo nella cartella dove c'era la
precedente versione, questo non viene più riconosciuto dall'MDE principale,
come se l'MDE principale riconosca solo l'MDE-Libreria che viene messo come
riferimento nel momento in cui viene creato.
Se così fosse, questo metodo perderebbe ogni utilità con gli MDE e tanto
varrebbe tenere un database unico.
C'è un modo per evitare questo?
Ciao
Sandrobi

"Sandrobi" <

Per quale ragione non sarebbe utile?
O meglio, magari non lo sarà nel caso tuo, ma non generalizzerei.
Io uso un file .mde esterno di libreria come contenitore delle tante
routines globali d'utilità che possono servire in ogni progetto.
E' meglio settare un riferimento a un file piuttosto che importare tutti i
moduli ogni volta, no?
Ciao.

"Oscar Manfredini" <XX...@Nospam.it> ha scritto nel messaggio
news:lvaCd.12896$H%6.56...@twister1.libero.it...

Ok, ma ne deduco che quindi non ci sono alternative: un MDE-Libreria deve
preesistere agli MDE che lo hanno come riferimento e non può essere
sostituito in un momento successivo perché non lo riconosce dal nome ma da
qualche algoritmo calcolato al momento della creazione dell'MDE principale.
Dico bene?
Ciao
Sandrobi

 Sandrobi
Non ho mai provato, ma mi pare ovvio, in fondo ti perdi probabilmente
il vero riferimento alla Libreria che se non sbaglio è il numero GUID
univoco.
E se gli sostituisci all'mde la lib(Mde) potrebbe avere problemi.
E' da verificare quanto ho detto...!!!
@Alex
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 Dico bene?
Dici bene.
Però in ogni caso non risolverebbe il tuo problema:
1) Personalizzare i Reports negli .MDE è comunque impossibile
2) Dare all'utente il sorgente del file "Report" da personalizzare e fargli
poi creare l'MDE relativo (Se anche non ci fosse il problema oggetto di
questo th) sarebbe comunque inaccettabile
3) L'esigenza di ridurre le dimensioni del Front-End esisterebbero se
l'applicativo avesse dimensioni stratosferiche (diciamo oltre i 700 moduli
di codice), avvicinando alcuni limitazioni di Access ... non credo sia il
caso tuo.
http://support.microsoft.com/default.aspx?scid=kb;en-us;289686
Ciao.

 @Alex
ciao a voi,
siccome sono interessato alla cosa, mi dareste maggiori info su come
richiamare le funzioni collocate nella lib(mde)?
grazie anticipatamente
melo
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 melo
Ti basta mettere le funzioni Public in un MDB e creare un MDE.
Dall'MDB/MDE inserisci nei riferimenti il file MDE come
fosse una Libreria.
Per i moduli di classe la cosa è un pò più complessa, li devi
prima esportare in TXT modificare(per A97 solo EXPOSED=True) alcuni
attrubuti(per A_XP anche CREATABLE=True), quindi reimportarlo 
inserendolo da File......!!
Ciao


"Oscar Manfredini" <XX...@Nospam.it> ha scritto nel messaggio
news:HXsCd.13669$_E5.3...@twister2.libero.it...

Il mio scopo in questo th non è personalizzare i report ma suddividere il
database in più moduli in modo di:
1) installare solo quelli di cui il cliente ha bisogno
2) permettere aggiornamenti possibili via email (un conto è inviare 1 MB
zippato di roba e ben diverso se 10MB e oltre, praticamente impossibile per
la maggior parte degli utenti normali)
Dalle prove che ho fatto, se uso MDB come database libreria non ci sono
problemi perché vengono riconosciuti automaticamente anche se vengo
aggiornati e sovrascritti in seguito.
In pratica un MDB funziona come un OCX o DLL che posso aggiornarli quando
voglio e vengono immediatamente riconosciuti dal programma che li utilizza.
Però distribuire gli MDB, credo, non è molto consigliabile anche adottando
tutte le sicurezze possibili.
Saluti.
Sandrobi

Sandrobi ha scritto:




Prova a togliere dal FE il riferimento fisso all'mde, e a impostarlo da
codice ad ogni apertura.
Namor
-- 
namor at inwind punto it


 la maggior parte degli utenti normali)
Premesso che quanto vuoi fare non è praticabile con un .MDE, ci sono altre
vie per raggiungere l'obiettivo: non incapponirti su questa soluzione.
Anzitutto potresti predisporre un'area web per il download degli
aggiornamenti: spedire e-mail oltre i 2 MB è problematico (e poco
professionale), far scaricare da internet un file, anche corposo, è
accettabilissimo.
A parte questo stento a credere che i tuoi programmi, compressi con WinZip o
WinRar, occupino 10 MB o più (inglobi forse MB d'immagini nelle forms?).
Comunque sia, nessuno t'impedisce di dividere il Front-End in vari moduli
separati, ognuno con una sua barra dei menù.
I diversi moduli avranno chiaramente degli oggetti comuni (per ex. codice
globale con le API di windows) che dovrai sdoppiare, ma è comunque
accettabile se per te è così importante distribuire le applicazioni a
"mosaico".
Peraltro ho visto diversi gestionali operare in tal modo anche per ragioni
filosofiche: gli utenti che lavorano sui D.D.T, per esempio, generalmente
non vogliono manco vedere il menù con i programmi di contabilità (usati da
altri colleghi/e).
Ciao.

 codice ad ogni apertura.
Non è possibile impostare riferimenti a Run-Time in un .MDE.
Ciao.

Sandrobi ha scritto:




Ho fatto una prova con access 2000:
due mde, il primo richiama all'avvio una funzione residente nel secondo
che fa una msgbox.
Modificando nell'mdb libreria la funzione, ricreando l'mde e sostituendolo
al precedente, il mde principale riconosce la nuova libreria e funziona.
Il contenuto della msgbox richiamata dalla macro autoexec cambia e mostra
il nuovo messaggio.


 il nuovo messaggio.
Con Access XP non funziona: è necessario rigenerare l'.mde principale.
Ciao.

 il nuovo messaggio.
Ho provato col 2000: non funziona.
La funzione MSGBOX dev'essere invocata dal .mde principale, non avviata da
autoexec.
Ciao.

"Oscar Manfredini" <XX...@Nospam.it> ha scritto nel messaggio
news:SoWCd.16730$H%6.69...@twister1.libero.it...

Mi inchino ai saggi consigli di Oscar e lo dico seriamente!
Ti chiedo allora un'altra cosa:
quale soluzione adotteresti per le particolarità? Se ad esempio un cliente
ha una form leggermente diversa per  i D.D.T. e/o ha una form in più
rispetto allo standard, come evitare di dargli un FE tutto suo?
Ciao

 rispetto allo standard, come evitare di dargli un FE tutto suo?
In generale, nonostante i proclami, anche i gestionali standard più grossi
del panorama nazionale risolvono solo una parte dei problemi: e i
rivenditori sanno bene che senza poter personalizzare i sorgenti avranno
sempre le mani legate.
Questo è in assoluto il problema più complesso che devono affrontare i
developers impegnati su un mercato eterogeneo.
E non esiste una facile soluzione ... esclusivamente tecnica.
E'  possibile adottare filosofie di lavoro che consentano di risolvere un
buon 80% delle esigenze mantenendo invariato il Core dei programmi, ma la
bacchetta magica non c'è.
1) Form DDT con particolarità
Una parte significativa di questi problemi si risolve costruendo un sistema
di causali magazzino/documenti flessibile: le problematiche di magazzino e
fatturazione sono varie ma non infinite.
Però la flessibilità del suddetto sistema dipende sempre dall'esperienza
maturata sul campo, quindi non è oggettivizzabile.
E' un dato di fatto che i sistemi di causali adottati dai gestionali più
completi impressionano per completezza e varietà di soluzioni.
Un sistema di causali Documento può prevedere opzioni per la
visualizzazione/stampa di campi particolari: multiquantità per ortomercati,
esposizione di anidi/idrati, Cauzioni, fatture solo totali, totale peso
Documento, Ritenuta acconto, etc.
Chiaro, lo sforzo di analisi/programmazione è elevato ma operando in tal
modo si finisce per coprire la gran parte delle problematiche gestionali.
Restano i problemi di layout Report: se il Cliente è così coglione da
chiederti di spostare la ragione sociale del Cliente a piede stampa ... beh,
lascialo perdere!
Ma per richieste logiche e ragionevoli mi pare che il lavoro di
Savoldi/Baraldi (o Baraldi/Savoldi) sulla personalizzazione Runtime dei
tracciati di stampa sia ottimo.
2) Aggiungere Maschere o Reports allo standard
In molti casi può essere risolto in maniera semplice.
Puoi creare nella base dati una tabella contenente i percorsi di .mde
aggiuntivi da avviare in Shell.
Nel programma principale avrai un'opzione ben visibile chiamata "plugins" o
come ti pare: dopo averla selezionata apparirà una Form tabellare:
Nome programma esterno, Descrizione,  (percorso)
L'utente clicca il Programma desiderato e questo viene avviato con una
shell.
Il programma aggiuntivo richiamato in questo modo magari è semplicemente un
Report particolare utile solo al cliente in oggetto...
Concludendo: problema rognoso, soluzioni comode non esistono (anche se il
discorso di .mde concatenati funzionasse come desideravi): col tempo si
possono costruire programmi abbastanza parametrizzati da risolvere la
maggioranza delle esigenze senza modificare il core degli applicativi.
Ciao.


Grazie dei consigli. Mi hai dato molto materiale su cui meditare....
Ciao
Sandrobi

 "namor"



L'autoexec dell'mde principale non richiama direttamente l'msgbox,
richiama una public function messaggia() che è contenuta nella libreria.
Sostituendo la libreria mde il messaggio cambia senza dover reimpostare il
riferimento. Ho fatto anche un'altra prova: oltre a modificare la funzione
messaggia() già esistente ho aggiunto alla libreria una nuova funzione,
anche questa viene riconosciuta senza problemi.
Ho ancora sull'HD gli esempi, se vuoi te li mando.


 anche questa viene riconosciuta senza problemi.
Questa è la prova da fare, più realistica:
Crei una Form nel .mdb/e  principale e un pulsante di comando.
Su click del pulsante invochi la funzione inclusa nel file di libreria.
In questa situazione non funziona.
Ciao.

"Oscar Manfredini" <XX...@Nospam.it> ha scritto nel messaggio
news:WxxDd.18998$_E5.4...@twister2.libero.it...



Ok, lunedì provo poi ti faccio sapere.
Ciao.
Namor

namor ha scritto:





Provato. Non funziona.
Anche senza modificare la libreria mde, semplicemente eliminandola e
ricreandola, da vba non va e dalla macro sì.
Dall'mdb invece nessun problema, la libreria mde viene riconosciuta anche
dopo essere stata modificata e sostituita.
Mi piacerebbe capire come mai la funzione richiamata dalla macro viene
eseguita, e invece se richiamata dal codice vba della maschera dà errore.
Il fatto che la macro funzioni indica che il riferimento è presente e
funzionante, ci dev'essere qualche altro inghippo legato alla compilazione
del codice vba negli mde.
