Newsgroup: it.comp.lang.visual-basic
Titolo: File txt contemporaneamente aperti

una domandina veloce:
č possibile avere un file .txt aperto contemporaneamente da due o piů
applicazioni (una in scrittura) e le altre in lettura, senza danni di sorta?
grazie.  roby

[Roberto Cortiana = 
circa_r...@libero.it
 in
c77nru$kt6s$
1...@ID-216244.news.uni-berlin.de
] ha scritto:

Che succede se uno scrive mentre l'altro sta leggendo?
Occorre capire se scrivi sempre accodando oppure anche
"sostituendo/ricostruendo".
Nel primo caso chi legge non dovrebbe avere altro fastidio che non quello di
non leggere tutto, nel secondo possono essere guai.
Consiglio: cambia strategia, pensandoci bene.

 > è possibile avere un file .txt aperto contemporaneamente da due o più


 altrimenti, che strategia mi suggerisci?
Un database.
Oppure leggere sempre la riga in coda (chi scrive accoda sempre)
Oppure denominare il file con "Pippo_AAAAMMGG_HHMMSS.TXT" in fase di
scrittura e chi legge legge sempre (e solo) quello con nome alfabeticamente
più alto.
Oppure un altro file che crea (prima di scrivere) chi scrive e lo cancella
dopo aver scritto. La sua presenza, per chi legge, indica che non si può
leggere.

 leggere.
Uno dei due prog per qualche motivo non cancella il semaforo  e tu non 
leggi più un tubo.
Con un semplice lock in lettura/scrittura risolvi il problema:
Private Function OpenLockWrite(ByVal FileName As String) As Long
     On Error GoTo Errore:
     OpenLockWrite = FreeFile
     Open FileName For Append Lock Write As OpenLockWrite
     Exit Function
Errore:
     OpenLockWrite = 0
End Function
Private Function OpenLockRead(ByVal FileName As String) As Long
     On Error GoTo Errore:
     OpenLockRead = FreeFile
     Open FileName For Input Lock Read As OpenLockRead
     Exit Function
Errore:
     OpenLockRead = 0
End Function
Dim f as long
f = OpenLockWrite
if f > 0 then
	...scrittura sul file
	close f
end if
Dim f as long
f = OpenLockRead
if f > 0 then
	...lettura del file
	close f
end if
Se non ce la si fa sulle Open si ritenta dopo un po' (qualche decimo di 
secondo o qualche secondo... dipende dal tipo di app).
Ciao

 Con un semplice lock in lettura/scrittura risolvi il problema...
Sarà, ma io non mi sono mai fidato dei lock di sistema e/o di linguaggio.

 leggere.
queste potrebbero essere belle idee.
comunque ho fatto alcune prove:
APPLICAZIONE 1: (scrive il file)
ho queste righe praticamente dentro un timer con interval = 10
  numFile = FreeFile
  Open PercorsoAggLavorazione & NomeMacchina & "\" & "Produzione.txt" For
Output As #numFile
  Write #numFile, ComboOperatore.Text, TextCommessa.Text,
LabelOraInizio.Caption, _
                           LabelTempoTrascorso.Caption & "-" & Timer,
LabelMaterialeAvviamento.Caption, _
                          LabelMaterialeLavorato.Caption
  Close #numFile
APPLICAZIONE 2 : (legge il file)
dentro un timer con interval=1
    Open PathProduzione For Input As #numFile
    If Not EOF(numFile) Then
       Input #numFile, Operatore, Commessa, OraInizio, TempoTrascorso,
MetriAvviamento, MetriLavorati
    End If
   Close #numFile
il file di testo risiede sul server, in rete!
il tutto sembra funzionare , ho fatto girare le applcazioni per mezz'ora
senza intoppi.
(P.S. : ovviamente è solo una prova, poi i cicli di lettura/scrittura
verranno fatti ogni circa 5 secondi....)

 verranno fatti ogni circa 5 secondi....)
T'è andata di culo. Continua con le prove, ma alza (sensibilmente) i tempi.
Ma se va via corrente ti si spegnerà anche il video...

 ha scritto nel messaggio
news:c781iv$mu7j$1...@ID-174464.news.uni-berlin.de...


 applicazioni girare per quache ora....
Questa mi sembra una soluzione "per grandi numeri" come il test a 
campione dei profilattici...
Ciao

 ha scritto

li fanno girare per qualche ora ? capperi ! :)
ciao, j.

 li fanno girare per qualche ora ? capperi ! :)
In effetti è un po' un test del c@//o
Ciao

 ha scritto nel messaggio
news:c78ag1$rlsh$7...@ID-184808.news.uni-berlin.de...

proverò anche la soluzione che mi hai suggerito tu!
mi sembra una buona idea
ciao!

 mi sembra una buona idea
Non è questo che intendevo.
Non credo si possano provare gli algoritmi con il principio dello 
"speriamo che tengano".
Prima lo si studia in modo che in almeno in linea teorica funzionino, 
poi li si testano e se c'è qualche errore sarà un errore di 
implementazione non di "sfiga".
Ciao

 ha scritto nel messaggio
news:c78bht$rlsh$8...@ID-184808.news.uni-berlin.de...


 aggiornamento di dati, non è la fine del mondo.
Spero per te che non ti stia leggendo! E spero per lui che la gestione degli
errori sia _veramente_ discreta come dici.
Lokar
-- 
Sito Comune: 
http://www.it-lang-vb.net/
Manifesto: 
http://www.it-lang-vb.net/docs/Manifesto.txt
Statuto: 
http://www.it-lang-vb.net/docs/Statuto.txt
UGIdotNET - 
http://www.ugidotnet.org

 ha scritto nel messaggio
news:c78c6m$rm8e$1...@ID-158338.news.uni-berlin.de...


 ha scritto nel messaggio
news:c78c6m$rm8e$1...@ID-158338.news.uni-berlin.de...


 comunque tranquillo. non mi sta leggendo!
Io _ero_ tranquillo, prima di vedere il tuo quoting selvaggio reiterato =)
Ti prego fa qualcosa =)


 aggiornamento di dati, non è la fine del mondo.
Ah, ok.
Comunque il problema non è la gestione degli errori, ma la 
contemporaneità degli accessi.
Se leggi mentre l'altro sta scivendo rischi di leggere dati incompleti 
(che è forse peggo del non leggere del tutto) perchè poi le elaborazioni 
le fai con tronconi di dati e quindi errati solo per metà.
Ciao