Newsgroup: it.comp.lang.visual-basic
Titolo: help su errori "strani" in database

ciao!
mi trovo a dover risolvere un problema di righe che "spariscono" da un db
(access, DAO, VB6). il programma č stato quasi completato da un altro
programmatore che si č occupato anche della gestione errori e della
struttura del db. ora lui non č piě disponibile e devo continuare io...
sicuramente č un problema che si verifica piů o meno normalmente perciň
chiedo a voi quale strada seguire per capire la causa, intercettare il punto
e correggere il problema.
in sintesi, il db č costituito da diverse tabelle non relazionate
fisicamente tra loro, le relazioni vengono cioč fatte via codice. in
particolare ci sono due tabelle, ordini e bolle che danno problemi. capita -
raramente - che senza dare alcun messaggio d'errore una riga della tabella
bolle sparisca. il problema č che non si č riusciti per ovvi motivi a
relazionare la "sparizione" con eventi o situazioni contingenti. l'ipotesi č
che ci sia un bug nel programma per cui data una determinata sequenza di
azioni nel riempimento dati da parte dell'utente in un form si verifichi
qualche errore gestito malamente che porta quindi alla cancellazione di una
riga. non č detto perň (o meglio, non č stato provato il contrario) che la
scomparsa interessi la riga in qualche modo legata ai dati inseriti. per il
resto il programma permette di visualizzare dati e apportare modifiche
sempre via codice, senza oggetti data quindi.
so che č un po' poco, ma potreste suggerirmi come muovermi ? pensavo di
realizzare un programmino che controllasse continuamente lo stato del db e
se una riga viene cancellata avverte l'utente (in modo da distiguere un
elimina reale dall'errore) ma non so se e come č possibile realizzarlo.
grazie!
Marco

 possibile realizzarlo.
Ipotizzo due situazioni, entrambe logiche:
1) La riga non scompare affatto, ma viene "coperta" da una successiva
(oppure va ad occuparne una precedente). Questo può avvenire solo se non c'è
un indice sulla tabella righe con chiave univoca o, se l'indice esiste e la
sua chiave univoca tiene conto di ciò che identifica logicamente (quindi un
ID non basta) una riga, il programma sbaglia ad assegnare le caratteristiche
alla nuova riga (per esempio le assegna un numero già esistente e quindi
copre una riga già depositata)
2) Da qualche parte, banalmente, c'è qualche istruzione di cancellazione che
cancella la riga sbagliata.
Io creerei un file di testo/log prima di _ogni_ istruzione di cancellazione
riga (in effetti la terza ipotesi è che l'utente cancelli la riga, ma, come
si sa, l'utente che pur lavora 8 ore al giorno sul PC, quando succede
qualcosa non hai mai fatto niente...). In tal modo puoi scoprire se e dove è
avvenuta la cancellazione, con comando umano o con qualche chiamata interna.
Alla prima "riga scomparsa" ci si ferma (annotando la riga stessa) e si
quarda il file di log. Se è menzionata, ci si ragiona sopra. Se no ...
scommetto sul punto 1.

 scommetto sul punto 1.
la cosa può funzionare, solo che c'è un problema. spesso ci si accorge che
manca una riga dopo mesi!
magari viene cancellata la riga di un ordine di due mesi fa (non ancora
archiviato) ma che non viene visualizzato quotidianamente. se per caso ci si
capita sopra allora ci si accorge altrimenti nisba!
ad ogni modo ho fatto un controllo per vedere se a ogni riga di una tabella
corrisponde una nell'altra (in modo da scoprire quante sono state
cancellate) e su oltre 6000 righe siamo a 3 o 4... quindi il problema è
fortunatamente - da una parte - ridotto, ma pur presente. dall'altra rende
statisticamente più arduo trovare l'errore.
ad ogni modo il log prima di ogni cancellazione lo vado a fare subito...
grazie ancora,
Marco

 dall'altra rende statisticamente più arduo trovare l'errore.
Una o centomila, non fa differenza.
La differenza fra un centesimo di euro e un miliardo di euro in un bilancio
contabile è nulla. Il bilancio non quadra.
Ragionerei sulla logica di come le righe vengono archiviate e gestite,
catalogate e riconosciute (specialmente in ambiente di multiutenza e
pseudo-contemporaneità). Ho la sensazione che ci sia un errore di
progettazione. In questi casi, la casualità fa la sua (complice) parte e,
come dicevo, 3/4 volte non sono molto diverse da 6000... A volte è
preferibile un errore brutale ed istantaneo piuttosto che andari avanti
"purchè sia"...

 "purchè sia"...
capisco perfettamente cosa intendi dire! vedrò di capirci qualcosa di più e
di provare le soluzioni che mi hai proposto.
grazie ancora,
Marco

 50-60 Mb...
Ho capito. Questo però vuol anche dire (almeno presumere) che non posso
riaprire un ordine... ovvero che quanto è nello storico non viene più messo
nell'archivio di lavoro. Può andare, ma io lascio più libertà e, certo,
rischio. In altre parole, non ho uno storico, tutto è sempre in linea. Ovvio
che ho i segnali di evaso/chiuso, ma l'operatore li può gestire liberamente,
con tutti gli adeguamenti del caso.

 con tutti gli adeguamenti del caso.
esatto, ma questa è stata una richiesta esplicita del cliente (ovviamente
all'epoca dell'altro tizio). per cui hanno chiesto di spostare
definitivamente in archivio gli ordini chiusi (e qui ho aggiunto almeno
un'età di qualche mese proprio per far sì che se nel breve periodo ci fosse
qualcosa da sistemare si era in tempo) sapendo che non possono riaprirli.
ultima domanda: dici che tieni tutto in linea ma per quanto tempo ? cioè a
fine anno cambi db oppure no ? perchè altrimenti diventa davvero enorme,
perlomeno con un'attività come quella cui sto lavorando.
grazie,
Marco

 contingenti.
c'era una cosa, tempo fa, che mi aveva abbastanza sconvolto. ero un niubbio
(lo sono ancora, ma adesso faccio più fatica ad ammetterlo ;-) ) per cui
magari riporto l'esperienza in modo erroneo, ma...
se io facevo un recordset (ADO) partendo da un join tra due tabelle (master
e detail) e cancellavo una riga di questo recordset, io pensavo di
cancellare solo la riga del detail... e invece cancellavo anche la riga del
master. per essere precisi, la cancellavo solo se non c'erano altri "detail"
associati a quel master, perchè la relazione uno a molti tra le due tabelle
mi impediva di eliminare i master che avevano ancora detail.
se questo mio sproloquio ha un fondo di verità, non è che tra le pieghe del
codice su cui stai lavorando c'è un pezzettino che lavora in questo modo?
hth
--
Salutoni
Sergio
per rispondere... togli il group dall'indirizzo

 cioč a fine anno cambi db oppure no ?
Sě. A fine anno (anzi, periodo di gestione) genero (ovviamente
automaticamente, anche se su esplicita richiesta dell'operatore) un nuovo
database che "corrisponde" al nuovo "periodo di gestione". Ovviamente
esistono delle procedure che duplicano i documenti/movimenti aperti (ordini
non totalmente evasi, scadenzari contabili, etc.) nel nuovo periodo di
gestione. E (non so se altrettanto ovviamente) in ogni periodo consento di
visionare (e basta!) l'intero "storico" precedente.

 visionare (e basta!) l'intero "storico" precedente.
ah, beh... ok. la differenza principale allora tra questo sistema e il tuo č
il fatto di spostare parzialmente nell'archivio anche durante l'anno anizchč
tutto una sola volta alla fine. per quanto riguarda il read-only nello
"storico" siamo d'accordo anche se qui lo "storico" raccoglie tutti gli anni
passati (2 al momento....).
grazie mille per le informazioni!
Marco