Dati "scomparsi"

[roberto]

Ciao a tutti, volevo sottoporre alla vostra attenzione quanto è accaduto ad un mio cliente a cui non riesco ancora a dare una spiegazione e che potrebbe essere oggetto di una contesa. Premetto che il cliente, un'associazione di categoria, usa da più di un'anno senza problemi una procedura di archiviazione dati che opera su una rete realiazzata e manutenuta da altre persone. La rete è una semplice peer-to-peer sotto windows xp professional con un server che viene solamente usato per effettuare il backup periodico delle cartelle documenti degli altri pc ( così hanno pensato di fare ! ). Solamente la procedura realizzata da me in effetti opera condividendo gli archivi ( dbf/ntx ) memorizzati su server.
Qualche giorno fa ho ricevuto una telefonata da parte del cliente allarmato perchè erano scomparsi i dati inseriti nell'ultimo mese di lavoro, pensando ad un semplice disallineamento degli indici sono intervenuto in loco e quì la sorpresa i dbf sul server erano retrodatati ed il contenuto era quello di un mese prima ! I responsabili del server, dopo aver appurato che la batteria dell'orologio del server era esaurita, se ne sono lavati le mani addossando la colpa, come al solito, alla procedura !
Morale della favola mi ritrovo ora a dover giustificare quanto successo, consapevole che la cosa non dipende dalla procedura e non avendo idea di cosa possa essere successo sul server. Cosa ne pensate voi ? Di primo acchitto io addebiterei il fatto al sistema di backup, cioè come se avesse sovrascitto i dbf più recenti con una copia precedente ma non saprei come giustificarlo.
Ciao a un grazie anticipato a quanto potranno aiutarmi a districare questo "imbroglio".
Roberto Lotronto.

[Enrico Maria Giordano]

Difficile fare ipotesi senza conoscere tutti i dettagli del sistema. Tu sei assolutamente sicuro che nel tuo programma non si faccia mai alcun riferimento, diretto o indiretto, alla data dei DBF? Sei altresì sicuro che la tua applicazione non possa aver scritto i dati in un altro percorso?

Altra cosa: gli indici erano allineati come data/ora rispetto ai DBF retrodatati che hai trovato (ma forse questo non lo puoi sapere più)?

Per finire, dovresti cercare di individuare chi possa aver copiato nella cartella dei DBF del tuo programma quei files vecchi.

Altro non mi viene in mente, al momento.

EMG

[Marco Turco]

Roberto,
hai disattivato l'op lock nel registro di Windows del Server ?
L'utilizzo di archivi ISAM (DBF, basso livello ecc) in rete su sistemi XP/2000 può comportare la perdita di dati per mancata registrazione(verificato personalmente) se non viene disattivato l'op lock e (secondariamente) se non vengono effettuati i corretti settaggi sulla configurazione della rete.

Con xHarbour viene fornito adesso un piccolo prg (wincheck mi sembra) sviluppato da Rees Software che effettua automaticamente questi settaggi.

Ti allego anche knowledge Microsoft a proposito di questo problema.

Maintaining Transactional Integrity with OPLOCKS
Article ID : 224992
Revision : 1.0
This article was previously published under Q224992
On this page
SYMPTOMS
CAUSE
RESOLUTION

SYMPTOMS
Under extreme conditions, some multiuser database applications that use a common data store over a network connection on a file server may experience transactional integrity issues or corruption of the database files and/or indexes stored on the server. This typically applies to some so-called "ISAM style", or "record oriented" multiuser database applications, not to a client/server relational system like SQL Server.
CAUSE
If a multiuser or single user database application accesses a common data store on a Windows NT file server using opportunistic locks (or OPLOCKS), it is possible for a given user to cache partial transactions on the client systems hard drive. This is a performance enhancement to the Windows client redirector to reduce network file I/O between the client and server. The data being cached on the client redirector is later written back to the server. However, in some cases, a client system may stop responding (hang), do a hard reboot, lose its network connection to the server, or experience any number of other technical difficulties. In such cases, the content of the local cache that has not yet been written to the server can be lost. As a result, the transaction integrity of the database structures on the server is compromised and the data on the file server can become corrupted.
RESOLUTION
To work around this problem, developers writing database applications that access a network data store should flush file buffers at any time that represents delineation of a transaction; for example, after a bulk operation, or prior to closing a file handle, or any time a transaction log is written to. This can be done by calling the Win32 FlushFileBuffers API Call.

--------------------------------------------------------------------------------
Saluti

Marco

[roberto]

Grazie per le tempestive risposte.
Per quanto riguarda l'ipotesi di Marco mi sembra di capire che l'inconveniente nasca in caso di registrazioni non fisicamente scritti sul server limitatamente ad una sessione di lavoro. Un flushing forzato da un commit obbliga i dati nella cache ad essere scricati fisicamente. Nel mio caso, a prescindere dal fatto che dopo ogni "append" prevedo un "commit" i dati persi non si sono limitati ad una sessione ma ad un intero mese !.
Invece per le ipotesi di E.M.G. ti posso assicurare che la procedura non prevede operazioni particolari sulle date di registrazione. Mi chiedo però : che cosa succede se il client opera con una data aggiornata rispetto a quella del server dove la batteria scarica la teneva arretrata, a livello di scrittura fisica dei dati ?

[Enrico Maria Giordano]

Mi chiedo però : che cosa succede se il client opera con una data aggiornata rispetto a quella del server dove la batteria scarica la teneva arretrata, a livello di scrittura fisica dei dati ?

Niente, che io sappia.

EMG