Newsgroup: it.comp.lang.visual-basic
Titolo: [VB6][?] FileCopy da locale a PC in rete.

E' possibile che un'istruzione di FileCopy dal disco locale ad un disco in
rete non restituisca alcun errore nel caso in cui, per ipotetici problemi di
rete, non venga portata a termine correttamente?
Grazie!

"Rogis" ha scritto...

Non è possiBBoli :P
Nel senso che la funzione ritorna sempre un errore, che però può essere
'intercettato' e gestito nei modi più consoni alle funzionalità che
l'applicativo richiede.
L'errore è un oggetto (err) con un certo numero di proprietà (number,
description ed altre); la gestione di queste ultime consente di fare, a
fronte di un errore, praticamente qualsiasi cosa.
Ecco un esempio:
sub myCopyFILE(srcPATH as string, srcFILE as string, dstPATH as string,
optional dstFILE as string = "")
    dim A as string 'e non rompete, dichiaro quello che voglio
    dim B as string
if  srcPATH = "" or srcFILE = "" or dstPATH = "" then
    MsgBox "GaLina! Indica i dati necessari a copiare un file",
vbinformation, "uffi"
    exit sub
end if
if dstFILE = "" then dstFILE = srcFILE
A = srcPATH
if right(A,1) <> "\" then A = A & "\"
B = dstPATH
if right(B,1) <> "\" then B = B & "\"
on local error goto erroreDiCopia
filecopy srcPATH & srcFILE, dstPATH & dstFILE
erroreDiCopia:
    if err then
        MsgBox "Si è verificata una condizione imprevista." & vbnewline & _
                    "Errore: " & err.number & " - " & Err.description , _
                    vbcritical,  "Così non va proprio!"
    end if
end sub
Scrivere On Error nella finestra del codice e premere F1 per ulteriori
approfondimenti.
Il codice l'ho scritto 'on the fly' e non l'ho provato, quindi se ho fatto
errori di stUmpa non lo so.
Hola
-> GbC|
www.gbcweb.com

Rogis ha scritto:

A me è successo all'interno di un dominio: la causa era una
impostazione errata degli utenti e del server che impediva
di scrivere sulla cartella in questione.
Per l'appunto, MOLTO grave il fatto che non desse alcun errore.
Ciao.
Mauro



Hai provato con lAPI CopyFile?
Declare Function CopyFile Lib "kernel32" Alias "CopyFileA" (ByVal
lpExistingFileName As String, ByVal lpNewFileName As String, ByVal bFailIfExists
As Long) As Long
Io ho smesso di usare FileCopy tanto tempo fa, proprio perchè faceva casini con
gli errori.
--
ciao
  Stefano

gh.... non avevo proprio capito :-)
però a me non è mai successo...
-> GbC|
www.gbcweb.com

 gli errori.
Sto provando ad usare FileSystemObject, ovvero la libreria "MS Scripting
Runtime".
Ovviamente utilizzo la gestione degli errori in tutto il codice, anzi è
centralizzata, dotata di log e altri ammenicoli per distinguere anche il
punto specifico all'interno della procedura che ha generato l'errore.
Il problema è che un paio di volte non sono stati copiati diversi files e
non c'è stato alcun evento per l'oggetto ERR.
Buon lavoro!



Io non uso il fso perchè non mi piace molto e soprattutto gli antivirus non lo
digeriscono.
Comunque se vuoi avere la certezza della copia avvenuta, oltre che usare
CopyFile dovresti anche verificare la copia dopo un pò magari con l'API
GetFileInformationByHandle usando ad esempio le info ritornate dal Type
BY_HANDLE_FILE_INFORMATION.ftLastWriteTime 
es:
http://www.mentalis.org/apilist/F843140335623EA020B6033D8F65DF40.html
--
ciao
  Stefano

 ovvero la libreria "MS Scripting Runtime".
FileSystemObject e' MALE!
hth,
Lokar 

 FileSystemObject e' MALE!
asserire qualcosa con eccessiva decisione e' _sempre_ SBAGLIATO!
:)
ciao, a.

 :)
LOL!
Comunque, ci sono millemila modi per supplire al FSO e quasi tutti portano 
meno "rogne".
Lokar
P.S. FSO = Male   =) 

 meno "rogne".
E quali ROGNE porta FSO??

 E quali ROGNE porta FSO??
http://groups.google.it/groups/search?hl=it&q=problemi+filesystemobject
Per farla breve:
- L'utente piu' inesperto teneterà di installare la dll dello scripting 
runtime (scrrun.dll) direttamente in fase di installazione del programma 
provocando, su alcuni sistemi operativi, reboot infiniti;
- E' infatti necessario _rimuovere_ la dll dal pacchetto di installazione e 
porre come requisito di sistema (per far funzionare il proprio software) 
l'installazione di IE almeno versione 4 (si, lo Scripting Runtime fa parte 
di IE);
- Essendo per l'appunto una DLL che esegue "script" viene riconosciuta dal 
90% degli antivirus (e in particolare dal piu' diffuso Norton) come 
"potenzialmente dannosa", e nelle impostazioni di default viene bloccata, 
salvo diverse indicazioni;
- E' una DLL esterna. Perche' portarsi appresso qualcosa per facilitare 
operazioni che si fanno _tranquillamente_ con funzioni base di Visual Basic 
o con API multipiattaforma _sicuramente_ presenti nel S.O.?
Da cui, la mia considerazione iniziale: FSO = Male.
Lokar

 >> e quasi tutti portano meno "rogne".
Sono perfettamente d'accordo con Lokar. E' sempre meglio evitare
l'utilizzo di qualsiasi componente esterno quando si puo' perfettamente
evitare. Perche' dobbiamo scrivere programmi che hanno per forza
bisogno di decine di DLL per funzionare?
Io per conto mio per fare una copia preferirei un bel
            numf1 = FreeFile
            Open SourceFile For Binary Access Read Shared As #numf1
            numf2 = FreeFile
            Open DestFile For Binary Access Write As #numf2
E poi via di GET e PUT.

 E poi via di GET e PUT.
Addirittura 8)
IMHO la strada migliore per la copia e' l'API CopyFile. Del resto il 
filesystem e' del sistema operativo... chi meglio di lui per copiare un 
file? =)
Lokar