Newsgroup: it.comp.lang.visual-basic
Titolo: "Disk or Network error" con Common Dialog e Jet (o forse ADO?)

Ho un seccante problema con Visual Basic, Windows, e il controllo
Common Dialog, ADO o Jet. Non capisco di chi sia la "colpa".
Ho realizzato un piccolo form di prova, contenente una Common Dialog e
due CommandButton eccovi il listato:
	Private Sub Command1_Click()
	   CommonDialog1.ShowSave
	End Sub
 
	Private Sub Command2_Click()
	   Dim cn As New ADODB.Connection
 
	   cn.Open "Provider=Microsoft.Jet.OLEDB.4.0;" & _
	               "Data Source=" & App.Path & "\miodb.mdb;" & _
	               "Persist Security Info=False"
	End Sub
Un codice abbastanza semplice... ovviamente miodb.mdb e' un qualsiasi
database di access (in questo esempio di prova, un database vuoto).
Se scateno il Command1_Click, e quindi seleziono un qualsiasi percorso
su Floppy Disk, e successivamente, dopo aver chiuso la Common Dialog,
rimuovo il floppy, tutte le chiamate alla cn.Open falliscono
sollevando un errore "Disk or Network Error".
Questo, nonostante il miodb.mdb sia completamente indipendente, e
risieda nello stesso percorso dell'applicativo.
In pratica, se con una Common Dialog seleziono qualcosa su un floppy,
da li' in poi ogni qual volta avvenga un qualche accesso con la
cn.Open (ma anche in altri casi), il sistema operativo (o i runtime di
visual basic? o e' colpa di Jet? o e' colpa di ADO?) controllano che
il percorso su floppy sia ancora valido, anche se non deve essere
eseguita alcuna operazione su floppy.
Come mai avviene questo insolito comportamento? E soprattutto, come
posso evitare o aggirare questo problema?
Qualsiasi suggerimento o consiglio e' ben accetto!
--
Billy Milano
Note sul sw:
Sistema Operativo: Windows 2000 5.00.2195 (Service Pack 2)
  (ma un collega mi riferisce di aver riscontrato lo stesso problema
su un pc Windows NT)
Ambiente di sviluppo: Visual Basic 6.0 sp 5
MDAC 2.6 sp1 (lo stesso problema si presenta anche con il 2.6)
Jet versione 4 sp3

 risieda nello stesso percorso dell'applicativo.
[SNIP]
Utilizzando App.Path, cosi' come hai fatto tu, il percorso del db dovrebbe
essere cablato e quindi non e' quello il problema; puo' darsi che,
implicitamente, da qualche parte la Connection acceda alla directory
"corrente", che e' stata cambiata in A:\ dall'accesso fatto al common
dialog...
Mi sembra strano che un bug del genere sia passato inosservato, comunque per
provare a tracciare il problema, prova ad inserire un semplice
ChDrive "C:"
dopo aver utilizzato il Common Dialog
Ciao
--
Luca Dormio - 
luca....@tin.it
________________________________
"Marty, non stai ragionando in maniera quadridimensionale"
Dr. Emmett L. Brown


Ho verificato sul mio PC.
Il comportamento è esattamente lo stesso.
La cosa incredibile è che ciò avviene anche dopo che ho riavviato
l'applicativo.
Ossia, se accedo al floppy col commondialog, poi cerco di aprire la
connection, ho l'errore. L'applicativo si arresta, lo riavvio, e tento di
aprire la connessione senza aver neppure toccato il commondialog, ma il
problema si ripresenta (anche peggio, visto che stavolta non mi dà errore,
ma devo usare CTRLALTCANC o reinserire il dischetto).
Purtroppo ciò avviene anche con il progetto compilato ed avviato come Exe.
Mi viene in mente il famoso bug di Word, per cui se si apriva un Doc da
dischetto, poi si toglieva il floppy col file aperto, finchè non si
formattava Word cercava sempre il dischetto, anche a mesi di distanza.
Nessuna idea per risolvere il problema.
Ciao
Alberto

 dopo aver utilizzato il Common Dialog
Perfetto, funziona.
In alternativa, ho scopero qui
[
http://groups.google.com/groups?selm=uLfQMYa7BHA.1984%40tkmsftngp05
]
un'altra possibile soluzione:
   CommonDialog1.Flags = cdlOFNNoChangeDir

 formattava Word cercava sempre il dischetto, anche a mesi di distanza.
E' la stessa cosa che fa WinZip se apri un file da una cartella
condivisa in rete; la volta successiva, già all'apertura, se non
ritrova la condivisione o non riesce ad accedere all'UNC si
pianta e non ha neanche un timeout. :-(
L'unica soluzione è pulire la MRU nel registro, e funziona >:->.
Bye, G.