VB6 close dei file

[ggallotti]

Sto notando da qualche tempo un problema su una piccola rete aziendale (7 PC con WIN XP) su cui girano diversi programmi in VB6 SP6: succede di tanto in tanto che un file (generalmente random) venga regolarmente aggiornato sul disco di rete ma che l'aggiornamento non risulti sul computer che l'ha effettuato mentre risulta su tutti gli altri computer.
Mi spiego meglio con un esempio.
Il computer "A" aggiorna un record del FileX che prima dell'aggiornamento conteneva il valore 10 che dopo l'aggiornamento è diventato 20.
I computer "B,C" ecc .... vedono tutti 20 mentre il computer A spesso continua a vedere 10 fino a che o si chiude il programma o si utilizza qualche altra routine del medesimo programma senza una logica precisa e ripetitiva.
Il mio dubbio è che dopo la close del file non si realizzi il flush del buffer (come dichiarato da Micrososft nel maniale VB6) e che quindi il computer A riapra in pratica il file nel medesimo buffer con i dati ancora presenti senza andare a rileggerli.
E' possibile questo? Esiste un modo per obbligare il flush dei buffer in VB6? Qualcuno ha per caso avuto il mesimo problema?
Grazie

[optime]

se parli di file di testo, l'istruzione RESET dovrebbe forzare il flushing dei dati.

Reset Statement


Closes all disk files opened using the Open statement.

Syntax

Reset

Remarks

The Reset statement closes all active files opened by the Open statement and writes the contents of all file buffers to disk.

[Grumpy]

L'istruzione Reset provoca la chiusura di tutti i file aperti esattamente come una Close senza l'indicazione del numero specifico che identifica il file. Però mi pare strano che 7 PC in rete utilizzino un file di testo per scambiarsi informazioni.

[gibra]

Aggiornamento di Cosa? Come? Programma? File?
Fin che si parla in modo così generico è come parlare del sesso degli angeli

[ggallotti]

Grazie a OPTIME E GRUMPY.
GIBRA invece poteva tranquillamente astenersi e mi farà cosa gradita se lo farà in seguito visto che invece di fare sterili polemiche avrebbe potuto leggere con più attenzione quanto scritto e forse (?) avrebbe capito il problema.

Cerco comunque di essere più chiaro.
1 - Non posso allegare il programma perché si tratta di migliaia di righe .....
2 - Immaginate un file random che viene aperto con una normale open, un record, a richiesta dell'operatore, viene caricato in memoria(GET), modificato e riscritto sul file (PUT). Al termine della routine una normale close chiude il file.
3 - La riscrittura del record su disco avviene senza problemi e senza errori.
4 - Non sempre, ma ogni tanto, senza una regola fissa, se l'operatore che ha modificato quel record lo richiama, ritrova il valore iniziale invece del valore che aveva modificato. Andando a verificare lo stesso record su un altro computer si ottiene invece il valore modificato.
E' evidente che il flush del buffer non ha funzionato con la close.
Mentre in altri linguaggi e ed anche nel .NET esiste l'istruzione FLUSH, in VB6 non esiste ed è affidata alla CLOSE che evidentemente funziona malamente in certe situazioni.
Rimane giustamente, come avete sottolineato, l'istruzione RESET che però chiude impietosamente tutti i files aperti e quindi non può essere utilizzata in tutte le situazioni.
Grazie
Grazie

[Grumpy]

Confesso che la tua diagnosi mi lascia piuttosto perplesso. Ti consiglierei, visto che il programma è corposo, di cercare di isolare il problena e riprodurlo in poche linee di codice per poterlo studiare meglio.
L'altra cosa che mi lascia perplesso, ma questo l'avevo già detto, è l'uso di un file di questo tipo per condividere informazioni in una LAN.

[gibra]

Originariamente inviato da ggallotti
GIBRA invece poteva tranquillamente astenersi e mi farà cosa gradita se lo farà in seguito visto che invece di fare sterili polemiche avrebbe potuto leggere con più attenzione quanto scritto e forse (?) avrebbe capito il problema.
[CUT]
Cerco comunque di essere più chiaro.

Il TUO problema era talmente chiaro che non ci ha capito niente nessuno, ed è per quello che hai dovuto rispiegare (male) una seconda volta.
Se fosse stato chiaro (come affermi) non avresti dovuto farlo ancora.
Quindi ti contraddici da solo.

Certo che mi asterrò, da ora in poi.
Non certo per fare cosa gradita a te, ma piuttosto per non perdere tempo a discutere con gente maleducata come te.

[ggallotti]

Grumpy,
il problema purtroppo non si manifesta in una sola routine del programma ma lo si scopre casualmente un po' dappertutto. Ecco il perché di una mia disagnosi che forzatamente va a cercare un problema che sia esterno al programma in quanto il programma stesso non dà alcuna anomalia.
Per quanto riguarda la gestione concordo con te che non è delle migliori per una LAN ma quel programma è una eredità e per ora non è aria di metterci le mani. Così, ad occhio e croce, direi che sono almeno 2.5-3 mesi di lavoro..... se tutto va bene!
Quello che posso provare a fare è modificare qualche routine in modo da poter chiudere tutti i files e quindi dare un RESET. Se quelle modificate non daranno più fastidi mentre le altre continueranno a farlo, evidentemente il problema è proprio il flush del buffer.
Siccome il problema è casuale ci vorrà molto tempo per le verifiche.
Ti farò sapere.
Comunque grazie.

[ggallotti]

GIBRA,
Bravo! I tuoi messaggi sono inutilmente passati da 704 a 705.

[optime]

stai quindi trattando dei file di tipo accesso random, non sequenziali. prova molto semplicemente a spostarti su un altro record prima di ri-accedere a quello incriminato (ad esempio, se devi fare una GET del record N, fai prima una get del record 1, poi una GET del record N); oppure a chiudere e riaprire il file subito prima di ogni lettura (anche se così ammazzi il server).

facce sape'