GESTIONE ERRORI DI ACCESS TRAMITE UN MODULO

Question

Buongiorno a tutti

Ho creato un modulo dove ho previsto la gestione e il riconoscimento di alcuni errori di Access . In questo modulo inserisco il codice numerico di ogni errore che mi capita evitando così il blocco del codice con la conseguente apertura della pagina vba. 

Ho notato che non riesco a gestire l'errore 2110 che si verifica quando il controllo non riceve lo stato attivo.

Perchè alcuni errori vengono intercettati e altri no? Cosa ho sbagliato?

Grazie

In tutte le maschere sull'evento errore ho inserito il seguente codice che richiama la routine.

Call ErroriAccess(Me, DataErr, Response)  

MODULO GESTIONE ERRORI

Case Else

    'Response = acDataErrContinue

    'MessaggioErrore "Errore altri non con conosciuti! routine errori nella maschera"

End Select

Public Sub ErroriAccess(ByRef Frm As Access.Form, ByRef DataErr As Integer, ByRef Response As Integer)

    'gestione errori maschera

    'Select case (variabile)

    'seleziona i casi di alla variabile che in questo caso DataErr=errore)

    'per sapere il codice errore mettere l'appice davanti alle prime  2 righe  in modo da far uscire il messaggio di access con il codice errore

Select Case DataErr

Case 3162 'Errore casella combinata quando si tenta di cancellare il contenuto

    MessaggioErrore "Attenzione : non si possono ricercare campi vuoti 3162!!"

    Response = acDataErrContinue

    Dim ind As Integer

    For ind = 0 To Frm.Controls.Count - 1

        If Frm.Controls(ind).ControlType = 111 Then    'combo

            Frm.Controls(ind).Undo

        End If

   Next

Case 3058

    MessaggioErrore "Errore routine errori nella maschera cod.3058 in una sottomaschera manca l'id della maschera principale"

    Response = acDataErrContinue

    Frm.Undo

Case 2110 'Errore un controllo non riceve lo stato attivo perchè e disabilitato o inesistente"

MessaggioErrore "Un controllo non riceve lo stato attivo perchè e disabilitato o inesistente !! 2110"

Response = acDataErrContinue

Frm.Undo

Case Else

    Response = acDataErrContinue

    MessaggioErrore "Errore altri non con conosciuti! routine errori nella maschera"

End Select

Answer 1

ciao Cristian_boy,

[...]

Infatti volevo chiedere cosa faceva "errHanlder"

[...]

la gestione classica degli errori si imposta con on error goto + etichetta.

errHandler è l'etichetta a fronte della quale nel momento in cui si genera l'errore viene effettuato un salto incondizionato del codice e questo "salto" permette di gestire l'errore.

Goto è bene utilizzarlo per la gestione degli errori solamente, per evitare quello che in gergo viene identificato come "spaghetti code". Generlamente quanto di pensa al goto, per fare eseguire una parte del codice c'è sempre un'alternativa, tranne per la gestione errori.

[...]

Cosa si intende per popolamento ?

[...]

semplicemente la fase di immissione dati nella tabella.

[...]

sono compresi tutti gli errori del controllo?

[...]

nella fase di popolamento? beh no la gestione errori è un'altra cosa...

[...]

Spesso mi capita errore sul focus o del blocca controlli che sono situati all'interno della routine.

Secondo te è sufficiente inserire "errHanlder" nel modulo?

[...]

come detto errHandler è un'etichetta che ti permette di gestire l'errore, per il tuo scenario specifico bisognerebbe vedere cosa fa la routine nel dettaglio...da come dici credo che la tua gestione errori o la mancanza di essa o ti crea confusione o non gestisce l'errore come ti aspetteresti.

[...]

Ho dimenticato di chiederti cosa serve DBEngine.Rollback. Nelle prove noto che si blocca in questo punto.

[...]

Nel momento in cui devi effettuare inserimenti multipli tipo quello gestito nell'altro post è bene wrappare l'action queries in una transazione in modo tale da permettere con il commit della transazione stessa di rendere effettive le n action queries nel loop.

Questo si riflette positivamente sulle performance. Ora...con poche righe da inserire  non si nota la differenza, qualora il numero dovesse aumentare a qualche decina di migliaia si.

la transazione si instanzia con il begintrans si rende effettiva con il commitTrans ed il rollback della transazione è utile per ripristinare la situazione originale dei dati prima di rendere effettive le action queries.

Il rollback infatti è impostato all'interno della gestione errori.

Stiamo andando OT!!!

ciao, Sandro.

Answer 2

Ciao Sandro

ti ringrazio del consiglio. Purtroppo sono un pessimo programmatore.

Il tuo consiglio è molto utile , anche se ti confesso, che a db fatto è una vera seccatura andare ad inserire il codice di errore in ogni codice di ogni controllo , pulsante ecc .Però essendo pignolo lo andrò ad inserire.

grazie ancora del consiglio

Answer 3

ciao Cristian_boy,

da buon sviluppatore quale sei, credo che tu possa guidare lo user della tua applicazione con messaggi customizzati al fine di evitare inserimento/compilazione non corrette di form nei controlli...

ad esempio date incongruenti che potrebbero generare un errore ed aprire il VBE cosa che non dovrebbe mai accadere comunque perché la gestione errori dovrebbe impedirlo.

Oppure inserimenti di numeri al posto di caratteri, oppure ancora, nel caso di inserimenti di duplicati, senza ricorrere all'indice univoco in una tabella controllare l'evento before update con Dcount.

Tutto questo in modo da limitare la gestione errori al massimo, ma in ogni caso è da implementare.

Intendo dire, perché sono certo che mi sono spiegato male, che una cosa sono gli errori dovuti alla logica di programmazione che tu hai utilizzato che devono essere intrappolati nella gestione degli errori...( ti potrà sempre scappare qualcosa no?) altro invece sono errori dovuti alla mala interpretazione dello user circa il dato da inserire.

Onestamente, non ho mai pensato a una gestione errori univoca, certamente perché sviluppatore non sono, ma anche perché credo sia meglio impostarla di caso in caso...

In ogni caso onde evitare OT, la risposta qualificata al tuo quesito è contenuta a mio avviso nel precedente post ed il link MSFT è chiarificatore.

ciao, Sandro.

Answer 4

Ciao Sandro

il motivo è per riuscire a prevedere tutti gli errori che mi possono capitare. Quando un utente commette un errore che io non avevo previsto,  inserisco il codice nel modulo. In questo modo quando lo stesso errore avviene su un'altra maschera ,fa proseguire l'utente.

L'altro motivo è perchè il codice del mio db è tanto e dovrei anteporre per ogni evento la parte riferita agli errori per far proseguire l'utente.

Mi basterebbe avere una notifica con il nr dell'errore e dando ok l'utente possa proseguire senza far aprire il codice il modulo evidenziato in giallo.

grazie

Answer 5

ciao Christian_boy.

se vedi quanto riporta MSFT qui :

https://msdn.microsoft.com/en-us/library/office/ff836345(v=office.15).aspx?tduid=(a232353c1212f86cd11ddca54d04d00e)(256380)(2459594)(TnL5HPStwNw-ADTkVClQMZp3p0QW\_by51w)()

solo gli errori non Runtime possono essere intrappolati nell'evento formError per quelli di runTime, è necessaria la gestione on error goto ....ect....

Sono un po' perplesso circa la scelta di gestire in un modulo standard per la gestione degli errori...quali sono le ragioni che ti hanno spinto verso questa direzione...? solo per curiosità :-).

ciao, Sandro.