Newsgroup: it.comp.appl.access
Titolo: MDAC 2.8 e Windows 98: uno strano divorzio (lunghetto)

Recentemente, abbiamo terminato lo sviluppo di un prodotto con Access XP, 
utilizzando Office XP Developer per distribuirlo con il runtime. Lo abbiamo 
installato al secondo cliente dei nostri (potenziali) svariati clienti. Il 
cliente in questione ha cominciato a chiamare riferendoci di errori per noi 
atipici. Dopo diverse indagini infruttuose, ci siamo rivolti al supporto 
tecnico di Microsoft, che ha cominciato a lavorare sul caso. Nel frattempo, 
abbiamo portato avanti le nostre prove, che ci hanno condotto 
all'individuazione precisa del problema.
Windows 98, in combinazione con alcune stampanti, se l'MDAC 2.8 è installato 
e se viene utilizzato il VBA, produce svariati errori. Precisiamo che le 
informazioni che troverete in questo articolo sono frutto di nostri studi, 
poiché di documentazione ne esiste veramente poca, quindi potrebbero 
contenere inesattezze: i nostri due lettori non ce ne vogliano! Vediamo i 
fatti in dettaglio.
==> I passi per riprodurre il problema
Il problema è stato rilevato sia su macchine fisiche che su macchine 
virtuali, create sotto Microsoft Virtual PC. Per riprodurlo, seguire i passi 
successivi:
- Installare Windows 98 (su un pc o su una Virtual Machine)
- Installare Office XP con Access o soltanto Access XP (non abbiamo provato 
con Office 2000 o 2003)
- Installare l'MDAC 2.8
- Installare la stampante Xerox DocuPrint N17 PS3 o Brother HL 1450 o 
Samsung ML-1520 (solo su un pc reale, poiché è USB); i driver relativi sono 
reperibili sui siti dei produttori.
Avviare Access e seguire i passi:
- Creare un nuovo database
- Creare un report ed aggiungervi un'etichetta con scritto qualsiasi cosa; 
salvarlo con il nome "Report1".
- Creare un modulo con il codice
Function StampaReport()
    DoCmd.OpenReport "Report1", acViewNormal
End Function
- Creare un nuovo pannello comandi da Strumenti \ Utilità Database \ 
Gestione pannello comandi
- Creare un sottomenu con una voce che riporti al menu principale
- Creare nel menu principale, una voce che esegua il codice StampaReport
- Creare nel menu principale un richiamo per il sottomenu
Adesso, aprite il pannello dei comandi. Premendo in sequenza il pulsante di 
stampa e poi quello per il cambio di menu, compariranno i primi errori. In 
ordine di probabilità, il primo errore a verificarsi dovrebbe essere un 
Errore eseguendo il comando; inserendo nella switchboard un gestore di 
errori, si vede che l'errore reale è un Error -
2147417848
: metodo 'Value' 
dell'oggetto '_Textbox' non riuscito. Cercando sui newsgroup si trova molto 
poco. Chiudendo e riaprendo il pannello dei comandi, potreste ottenere un 
Errore di run-time '-
2147417848
 (80010108): Metodo 'Open' dell'oggetto 
'_Recordset' non riuscito. Insistendo con le prove, in alcuni casi si 
verificano errori che chiudono brutalmente Access o, addirittura, schermate 
blu. Se adesso installate un'altra stampante, con driver forniti insieme a 
Windows 98, la impostate come predefinita e riprovate ad utilizzare il 
database, tutto dovrebbe funzionare regolarmente.
Sul sito 
www.aladinoinformatica.com/download/crashtestII.zip
 potete reperire 
un file già pronto per effettuare le stesse prove.
==> Analisi del problema
Quando ci si trova in una situazione in cui la documentazione scarseggia e 
non si hanno punti di riferimento per procedere, una tecnica utile è il 
divide et impera. Si comincia ad eliminare tutto ciò che si può; quando il 
problema non si presenta più, forse si ha qualcosa su cui lavorare. Con 
questo approccio siamo arrivati ad isolare i componenti minimi che scatenano 
il problema.
Purtroppo non siamo riusciti a trovare nessun fattore comune tra i driver 
che causano problemi e nessun fattore comune tra quelli che invece 
funzionano. Infatti, alcuni driver scaricati da internet scatenano il 
problema, altri no, mentre tutti quelli forniti con Windows 98 che abbiamo 
provato, sembrano funzionare regolarmente. Avendo ristretto il problema 
all'MDAC 2.8, abbiamo ricontattato il supporto tecnico. Purtroppo, quando 
anche loro hanno riprodotto il problema, al momento di scalare al supporto 
di livello superiore, sono stati fermati poiché Windows 98 non è più 
supportato. Tra le varie prove, abbiamo condotto un test anche su Windows ME 
e sembra che il problema non si presenti.
==> Soluzione del problema
Ovviamente la soluzione banale è quella di aggiornare il sistema operativo. 
La realtà è che molti clienti non digeriscono questo fatto. Quindi abbiamo 
provato con l'MDAC 2.7 e questa strada sembra funzionare. Vediamo i passi da 
seguire:
1. Se su un PC è già installato l'MDAC 2.8, dobbiamo procedere alla sua 
disinstallazione. Leggendo [1] scopriamo che il fatto che questa operazione 
vada a buon fine, è tutt'altro che scontato. Per disinstallare, dopo aver 
aperto un prompt,  passiamo nella cartella C:\Programmi\File 
comuni\Microsoft Shared\dasetup e lanciamo il comando dasetup /q. Per 
eventuali problemi di disinstallazione, consultare [1]
2. Scaricare ed eseguire l'installazione dell'MDAC 2.7, reperibile su [2]
Sviluppare e distribuire con diverse versioni di MDAC
Si pone però un problema. Se, per sviluppare, si utilizza l'ultima versione 
di MDAC, la 2.8, si ha il problema di doverla cambiare prima di distribuire 
il pacchetto. Infatti, copiando un file .mdb che ha riferimenti all'MDAC 2.8 
in un ambiente dove sia installata la versione 2.7, otterremo l'errore Il 
database o il progetto di Microsoft Access include un riferimento mancante o 
errato al file 'msado15.dll' versione 2.8. Vediamo le strade percorribili.
Se utilizzo solo l'ADO e non l'ADOX, posso, nel sistema di sviluppo, 
selezionare l'ADO 2.7 al posto del 2.8. Il database portato sotto Windows 98 
sembra funzionare correttamente.
Se, oltre all'ADO utilizzo anche l'ADOX, il problema è più complesso. 
Infatti, quando inserisco un riferimento all'ADOX, non potendone selezionare 
la versione, il VBA prende la più recente. Ossia: se ho installato l'MDAC 
2.8, seleziono l'ADO 2.7 e l'ADOX relativo, chiudendo e riaprendo la dialog 
dei riferimenti, scoprirò che la versione in uso è la 2.7 per l'ADO ma la 
2.8 per l'ADOX. Questo fatto può essere verificato anche tramite un ciclo 
sulll'insieme References, con la routine
Sub StampaVersioniRiferimenti()
    Dim i As Integer
    For i = 1 To References.Count
        Debug.Print References(i).Name & "=" & References(i).Major & "." & 
References(i).Minor
    Next
End Sub
Compilando il database e spostandolo sotto Windows 98, non otterremo errori 
per l'ADO ma otterremo l'errore Il database o il progetto di Microsoft 
Access include un riferimento mancante o errato al file 'msadox.dll' 
versione 2.8. In effetti, il riferimento è corretto, solo la versione è 
errata.
La soluzione migliore sembra essere di sviluppare con ADO 2.8 e poi copiare 
il file in un pc con Windows 98 e MDAC 2.7, seguendo i passi:
- Copio il file sotto Windows 98
- Nell'apposita finestra tolgo i riferimenti all'ADO e all'ADOX; la chiudo
- Riapro la finestra ed aggiungo i riferimenti all'ADO 2.7 e all'ADOX 2.7
- Compilo il database
- Riporto l'MDB sul pc di sviluppo per la distribuzione.
==> Problemi di riferimenti errati
Purtroppo, agendo nel modo anzidetto, si può verificare un ulteriore 
problema. Access, ogni volta che compila un oggetto, si memorizza il codice 
compilato. In alcuni casi è possibile che quel codice abbia dei riferimenti 
non validi. A quel punto si possono ottenere gli errori più disparati. Uno 
classico e visibile è vedere una casella di testo di una maschera o di un 
report, alla quale è associata un'espressione tipo =Date(), che visualizza, 
invece del valore, la scritta #Nome?. Cercando sui gruppi con "decompile 
access problemi" o "decompile access problems" troverete comunque molta 
documentazione. Ovviamente, più il database è complesso, più è facile che si 
verifichi il problema. Ad esempio, noi sviluppiamo utilizzando una libreria 
.mde aggiuntiva e notiamo con una certa frequenza problemi del genere.
Le soluzioni, sono ancora una volta, molteplici: si può provare ad ovviare 
con il comando
C:\...\MSACCESS.EXE <nomefile>.mdb /decompile
che decompila il file. Ossia, mette tutti i moduli in stato di non 
compilato. A questo punto si ricompila il tutto. Purtroppo anche questo 
approccio può causare problemi. In alcuni casi, ma non siamo mai riusciti a 
riprodurre un procedimento, abbiamo perso alcune modifiche fatte al codice. 
Per altri problemi conosciuti, vedere [3]
Un approccio che pare funzionare, se si utilizza Visual Source Safe, è 
quello di rigenerare completamente il database. In pratica, una volta 
effettuate tutte le modifiche, si archivia il file in Visual Source Safe, si 
cancella il file in locale e, tramite il comando Strumenti \ SourceSafe \ 
Create Database From SourceSafe Project... si ricrea il file ex-novo. A 
questo punto, senza compilarlo, lo si sposta sotto Windows 98 e si procede 
come già detto. Il file così creato sembra che abbia tutto il codice in 
stato di decompilato.
Il problema non si pone, infine, se utilizzate un file MDE. Infatti, in 
questo caso, nel nuovo file che viene creato, il codice viene ricompilato 
per intero.
==> Collaudi finali
La nostra applicazione è formata da un file di dati, dall'applicazione e 
dalla libreria in formato .mde. Abbiamo ricompilato libreria ed applicazione 
sotto Windows 98 e MDAC 2.7. Il risultato lo abbiamo riportato sotto Windows 
XP, nel pacchetto creato in precedenza. Il compilatore, pur sfruttando ADO 
2.7 e ADOX 2.8, pare tollerare la situazione. (A tal proposito, se a 
qualcuno fosse sfuggito, esiste un aggiornamento non automatico per Office 
XP Dev che risolve tra l'altro alcuni problemi di installazione sotto 
Windows 98 - vedi [4] e l'SP1 per Office XP - vedi [5]).
Abbiamo poi provato ad installare il pacchetto sotto una macchina virtuale 
con Windows 98 appena installato, avendo cura di installarvi prima l'MDAC 
2.7. Lo abbiamo anche provato sotto Windows ME e XP. I collaudi non hanno 
fatto rilevare alcun problema anche se, si sa, che il testing può solo 
mostrare la presenza di errori, non la loro assenza.
==> Riferimenti
[1] 311720 PRB: Il rollback di MDAC potrebbe non riuscire in Windows 95, 
Windows 98 e Windows Millennium Edition
http://support.microsoft.com/kb/311720/
[2]  Download MDAC 2.7
http://tinyurl.com/fyzg
 oppure 
http://msdn.microsoft.com/data/downloads/
 e 
cercare MDAC 2.7
[3] Subject: INFO: The real deal on the /Decompile switch
http://trigeminal.com/usenet/usenet004.asp
[4] OFFXPDEV: Microsoft Office XP Developer Packaging Wizard Patch Available 
on MSDN
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q305003
[5] OFFXPDEV: Download e installazione di Office XP Developer Service Pack 1 
(SP-1)
http://support.microsoft.com/kb/313166/it
-- 
Jonathan Canova
infoCHIOCCIOLAaladinoinformatica.com
www.aladinoinformatica.com
 


Mega cut
Una soluzione è avere una macchina server e tanti client anche obsoleti (95 
o 98) che accedono via terminal server.
Ti assicuro che quando il cliente saprà di non dover spendere una lira per 
aggiornare i suoi vecchi pc ma anzi che deve tenerseli, il successo è 
garantito.
Il costo di una lic. terminal server è ridicolo.
In questo modo salti a piè pari tutti i problemi.
Ciao, Carlo

 e sembra che il problema non si presenti.
(cut)
Anzitutto complimenti per il lavoro di ricerca intrapreso  :-)
Tuttavia non hai chiarito un aspetto importante: il problema si verifica
anche se l'applicazione NON ha nei riferimenti le librerie ADO?
Immagino che tu stia parlando di files .ADP/E ... con gli .mdb č poco
razionale usare ADO invece che DAO 3.60.
Ciao.

 anche se l'applicazione NON ha nei riferimenti le librerie ADO?
Si. Fai un database e non ci metti nulla, il problema esiste lo stesso.
Il db è MDB; con gli ADP non ho provato, ma credo che non cambi nulla: il 
problema non è legato all'uso dell'ADO, ma al fatto che sia installato 
l'MDAC.
Ciao