Newsgroup: it.comp.lang.visual-basic
Titolo: Ado & Mdb su lan che va down: come intercetto errore?

Ciao a tutti.
VB6 con Ado 2.6 + DB Access 2000
Su 1 pc ho un prg che 24/24h legge la seriale e scrive dati su un DB
in locale, come se fosse un terminale stand-alone; ogni 5min (con
timer) scarico i dati su un altro DB che risiede in un disco di rete
(per non sovraccaricare la rete e xchè tanto non mi serve + frequente)
Il passaggio lo faccio così:
- controllo se la rete è up e il file DB è accessibile con DIR
- apro la Connection
- preparo la transazione MyConn.BeginTrans
- faccio le aggiunte
- inserisco controllo errore (vedi dopo)
- MyConn.CommitTrans
- chiudo tutto
Come controllo errore:
- ho inserito l'on error
- ho implementato tutti i controlli ConnectionsEvents
- ho implementato tutti i controlli RecordsetEvents
Il problema è che se la rete va down mentre sto già accodando i dati
(prima o poi capita sicuro), l'on error 1 volta su 3 non reagisce, di
tutti gli events l'unico che da errore è il RecordChangeComplete, e
comunque anche se l'intercetto non riesco a bloccare i chili di msg di
errore di Windows, e sono obbligato a riavviare il pc, cosa che vorrei
evitare a tutti i costi.
Avete suggerimenti?
Grazie

 Avete suggerimenti?
Ciò che fai è corretto.
Tuttavia presumo ci sia qualche errore nel tuo codice, perchè se si genera
un errore, tu dovresti avere il controllo (dopo l'On Error), tenti un
rollback se la connection non è AdStateClosed, e poi ritenti al giro
successivo.
Se devi riavviare, probabilmente hai qualche loop (tipo errori dentro alla
gestione errori, ad esempio).
Come consiglio, valuta se non ti convenga utilizzare, come database remoto,
un dbms 'vivo', tipo MSDE, Sql-Server, MySql, Oracle, ecc..., perchè in caso
di caduta di rete il rollback su Access non funziona e lo stato risultante
del db può non essere funzionante.
Altro consiglio, anzichè fare un .AddNew su un recordset e poi farne
l'update, è molto più pratico (e, quantomeno, ti consente di gestire gli
errori in modo lineare) eseguire una serie di insert in remoto e di update
in locale. Purtroppo con Access non riesci a gestire le transazioni
distribuite (vedi la documentazione su DTC di Sql-Server, per i dettagli),
per cui la certezza di non avere problemi non puoi averla. Teoricamente,
potresti trovarti con record non arrivati sul server, ma marcati come
'inviati' in locale, o viceversa.
Ciao
Alberto

... per cui la certezza di non avere problemi non puoi averla....
Io ho fatto questo ragionamento:
- faccio accodamenti poco frequenti e più veloci possibili per
limitare statisticamente la possibilità che capiti il problema
- se capita il problema, e in un modo o nell'altro lo riesco
quantomeno ad identificare, la sicurezza me la faccio da solo, in
quanto non è un problema quando la rete torna up fare un controllo
record per record (è una palla, lo so, ma tant'è....)
Il vero problema è che con Connection e Recordset aperti, se manca il
file mdb, il mio prg in un modo o nell'altro rimane funzionante, ma
si incacchia Windows, che da una serie di msg  "Disco di rete non
trovato" o qualcosa di simile, che richiedono l'ok da tastiera che non
voglio dare perchè il pc è come se fosse un terminale.
Ho provato anche a mettere l'mdb sul floppy, e li è proprio da ridere,
continua a friggere per 20 minuti anche dopo averlo reinfilato....
Ciao e grazie
Se hai altri suggerimenti sono sempre bene accetti

 continua a friggere per 20 minuti anche dopo averlo reinfilato....
Non è che usi il CommonDialog, vero?
Ciao
Alberto

Oppure, può capitare se non esegui un test dello stato della connection...
Come ti dicevo i test li ho fatti tutti, figurati.
Comunque ho appena ricontrollato col floppy (sono a casa....):
- con la connection aperta ma senza scrivere, tolgo il floppy e non da
errore
- accodo un record e comincia a friggere
- usce un msg di Xp dalla taskbar "Scrittura rimandata non riuscita",
che non richiede l'ok
- il mio prg intercetta l'errore
- faccio il rollback senza problemi apparenti
    (se uso updatebatch chiudo il rst, idem senza problemi)
- vado a chiudere la connection, lo esegue correttamente, ma parte il
msg di Windows "Disco non presente" che richiedo l'ok da tastiera
Quindi il problema è chiudere la connection, xchè anche se ha ricevuto
il rollback e la chiusura della connection correttamente (e quindi non
dovrebbe scrivere niente), si vede che jet ha bisogno lo stesso del
file mdb.
Forse il problema è tutto qui.
Ciao e rigrazie

 Forse il problema è tutto qui.
Il floppy è una prova 'fasulla'.
Se non c'è il disco, il S.O. chiede all'utente il suo inserimento, prima di
rispondere al sw che il disco non c'è e scatenare l'errore.
In rete, avviene la stessa cosa (ossia un tentativo di stabilire una
connessione di rete), ma senza alcuna segnalazione all'utente.
A parte questo, usando gli insert anzichè l'aggiunta di record al recordset,
hai la gestione di ciò che accade. Quel "Scrittura rimandata" nasce proprio
da questo. Se tu testi lo stato della connection, esegui un insert (e a
questo punto non serve neppure che sia transazionale in quanto è già
atomico), al massimo la connection era caduta fra il test e l'insert. Tu
intercetti l'errore, e ritenti (comprendendo anche una riapertura della
connection se il suo stato non è AdStateClosed).
Mi sembra molto strano che ti esegua un rollback a connection chiusa...
Alberto