On Error GoTo ne fonctionne pas; Code des pauses

Je suis en train d'écrire une fonction VBA pour importer des données d'une table à l'autre dans l'Accès. La table, je suis à l'importation en a plus strict des contraintes des données (c'est à dire les types, la taille etc.), donc je m'attends à beaucoup d'erreurs.

Plutôt que de passer au crible tous les VBA erreur qui arrive, je veux que mon jeu d'enregistrements en boucle pour passer la totalité de l'enregistrement courant et de faire une note de celui-ci dans un tableau distinct chaque fois qu'il rencontre une erreur. De sorte que chaque ligne, j'ai inséré On Error GoTo RecordError. Mais pour quelque raison il n'est pas de la manipulation de toutes les erreurs. Mon code est juste casse et me dit quelle est l'erreur. J'ai la "Rupture" sur les Exceptions Non gérées" option est déjà cochée.

Voici une capture d'écran qu'il faut expliquer.
On Error GoTo ne fonctionne pas; Code des pauses

Pourquoi en serait-il la rupture sur la ligne immédiatement à la suite d'un gestionnaire d'Erreur?

Pouvez-vous fournir un exemple de message d'erreur, vous voyez?
Le message d'erreur n'est pas pertinente. L'erreur est liée à la mise en forme de mon champs de base de données et c'est un message d'erreur que je m'attends à obtenir si n'ont pas établi de On Error GoTo.... C'est le fait que mon code est la rupture plutôt que d'aller à l'étiquette que j'programme d'installation.
La raison que je demande, c'est parce qu'il y a quelques messages d'erreur déclenchée dans l'Accès ne peut pas être pris au piège à l'aide de VBA.
On Error Resume Next résout tous vos problèmes.

OriginalL'auteur rdevitt | 2011-04-28

3

Je pense que vous n'êtes pas à comprendre comment VB(A) erreur de manipulation fonctionne. Suivez ces principes:
- Un On Error... déclaration s'applique uniquement à la routine (Sub ou Function) dans lequel il apparaît (bien qu'il sera aussi attraper les erreurs que la "bulle" de routines qui sont appelés à partir à l'intérieur de la routine dans laquelle vous l'utilisez).
- On Error définit un état. C'est, une Fois que vous émettez un On Error... il reste en vigueur pour le reste de la routine, sauf remplacé par un nouveau On Error....
- Il y a quatre formes de On Error...:
  1. On Error GoTo <label>: <label> doit être défini dans le même routine, en écrivant le nom de l'étiquette immédiatement suivie de deux-points (:) sur une ligne.
  2. On Error Resume: immédiatement tentatives de l'erreur des jets de déclaration. Presque jamais utilisé, car il est potentiellement infini.
  3. On Error Resume Next: ignore l'erreur, & continue. Parfois utiles à la fin des routines de nettoyage (par exemple, si vous souhaitez Fermer un jeu d'enregistrements qui peut ou ne peut pas être ouvert). Sinon, ce formulaire peut également être utilisé si vous cochez la Err objet immédiatement après éventuelle erreur-lance la ligne (si Err.Number est de zéro (0), l'état a réussi, sans jeter une erreur). C'est façon trop de travail pour la plupart des situations.
  4. On Error GoTo 0: désactive la gestion des erreurs.
Compte tenu de cela, il est d'usage de placer les On Error... instruction suivant immédiatement la routine de la déclaration (la Sub ou Function déclaration), bien que certaines personnes mettent leur Dim déclarations entre les deux. Si vous voulez changer temporairement les modalités de gestion des erreurs à l'intérieur d'une routine, mettre la "nouvelle" une à droite avant le code auquel il s'applique, et (si utilisé), le "revert" (réédition de l'original), juste après.

Même compte tenu de tout cela, je n'ai aucune idée de pourquoi elle allait se briser sur l'erreur-lance la ligne lors de la "Pause" sur les Erreurs Non gérées" est sélectionné, sauf si vous avez réussi à les confondre, si bien qu'il pense qu'il y a aucune gestion d'erreur (et je serais surpris si elle compilé si c'était le cas).

Noter que David Heffernan vous a donné l'essentiel de ce, dans sa réponse, et il a été ici avant le mien....

OriginalL'auteur RolandTumble
2

La raison pour laquelle il n'est pas le travail, c'est parce que vous ne pouvez pas utiliser on Error Goto ... au sein d'un gestionnaire d'erreurs.

voir http://www.cpearson.com/excel/errorhandling.htm

vous ne pouvez pas utiliser en cas d'Erreur de sauter quelques lignes, plutôt que sur l'erreur doit aller à un gestionnaire d'erreur qui puis reprendre à l'souhaité ligne suivante (dans votre exemple, vous pouvez probablement vous en sortir avec un gestionnaire d'erreur qui contient un resume next qui vous ramènera au champ suivant).

grâce à Tim Williams sur cette question: La seconde de 2 'on Error goto' états est ignorée

et BTW ParseInt sur un ZIP va détruire les codes postaux commençant par un 0, zipcodes devrait probablement être traités comme du texte.

C'est LA réponse, dans mon cas, au moins: j'ai utilisé On Error GoTo _label_ de sauter quelques lignes de code à l'intérieur d'un For cycle. Merci!

OriginalL'auteur mendel
1

Vous devez placer le On Error ligne avant le code dont les erreurs que vous souhaitez gérer.

Qui plus est, vous n'avez besoin que d'un On Error ligne. Le gestionnaire d'erreur alors qu'il reste actif jusqu'à ce que le sous-programme se termine ou que vous exécutez une autre On Error déclaration.

C'était mon hypothèse, mais il ne semble pas y avoir de travail. J'ai commenté tous mes On Error GoTo RecordError états à l'exception de la première, et je suis toujours obtenir le même résultat. Dès que j'ai mis On Error GoTo..., mon code ne doit pas jamais tomber en panne n'importe où dans la suite de cette sous-routine. Le droit?? À moins que je change d' On Error à autre chose.

OriginalL'auteur David Heffernan
1

Gestion des erreurs avec VBA est un véritable pain PITA. J'aimerais vous proposer de regarder cette réponse à la " MS-Access, VBA et d'erreur de manipulation de la question de l', et l'ont adapté à votre situation. Vous pouvez facilement écrire du code qui permettra de stocker tous vos messages d'erreur dans un tableau, la construction d'une de facto rapport d'erreur système.

OriginalL'auteur Philippe Grondier
1

Réglage du mode de débogage à " arrêt sur toutes les erreurs se l'exécution du programme s'arrête à la ligne qui provoque une erreur, même lorsque le gestionnaire d'erreur a été correctement écrit. Cela peut être source de confusion, car il apparaît que la gestion d'erreur n'est pas de travail.

OriginalL'auteur Andoriyu

Personne n'a vraiment répondu à votre question.

Que votre code est quelque chose comme ça (un squelette):

Public Sub MySub()
On Error GoTo errHandler
  Dim rs As DAO.Recordset

  Set rs = CurrentDB.OpenRecords([SQL SELECT])
  If rs.RecordCount >0 Then
     rs.MoveFirst
     Do Until rs.EOF
       [do whatever that produces the error]
errSkipToNext:
       rs.MoveNext
     Loop
  End If

exitRoutine:
  If Not (rs Is Nothing) Then
     rs.Close
     Set rs = Nothing
  Exit Sub

errHandler:
  Select Case Err.Number
    Case X, Y, Z ' where these are error numbers you want to ignore
      Err.Clear
      ' do whatever it is you need to do in order to record the offending row
      Call RecordError(rs!PK, Err.Number) ' PK is a field that identifies the bad record
      GoTo errSkipToNext
    Case Else
      MsgBox Err.Number & ": " & Err.Description, vbExclamation, _
         "Error!"
      Resume exitRoutine
  End Select
End Sub

Dans ce code, vous pouvez utiliser un SELECT case dans votre gestionnaire d'erreur pour décider quelles erreurs vous voulez ignorer. Dans mon code cadre ci-dessus, j'ai listé les numéros d'erreur comme X, Y, Z, mais vous devez la remplacer par de la vraie erreur de numéros que vous voulez ignorer, à la place.

Vous ne voulez pas ignorer chaque erreur, car vous pourriez finir en ignorant les erreurs importantes ailleurs dans votre sous-routine. Si vous ne voulez pas comprendre ce que le nombre limité d'erreurs que vous voulez ignorer arrive d'être, je voudrais vous suggérer de définir un indicateur au début du bloc de code qui génère les erreurs que vous voulez ignorer, puis utiliser un " Si bolErrorInCodeBlockToIgnore Ensuite de décider si vous êtes ignorant toutes les erreurs ou pas. Quelque chose comme ceci:

Public Sub MySub()
On Error GoTo errHandler
  Dim rs As DAO.Recordset
  Dim bolErrorInCodeBlockToIgnore As Boolean

  Set rs = CurrentDB.OpenRecords([SQL SELECT])
  If rs.RecordCount >0 Then
     rs.MoveFirst
     Do Until rs.EOF
       bolErrorInCodeBlockToIgnore = True
       [do whatever that produces the error]
errSkipToNext:
       rs.MoveNext
     Loop
  End If

exitRoutine:
  If Not (rs Is Nothing) Then
     rs.Close
     Set rs = Nothing
  Exit Sub

errHandler:
  If bolErrorInCodeBlockToIgnore Then
     Err.Clear
     ' do whatever it is you need to do in order to record the offending row
     Call RecordError(rs!PK, Err.Number) ' PK is a field that identifies the bad record
     bolErrorInCodeBlockToIgnore = False
     GoTo errSkipToNext
  Else
     MsgBox Err.Number & ": " & Err.Description, vbExclamation, _
        "Error!"
     Resume exitRoutine
  End If
End Sub

Je préfère de beaucoup le premier, comme je suis un croyant ferme en seulement en ignorant les erreurs connues, pas une vieille erreur qui se produit. Mais il peut être très difficile de trouver des tests qui permettront de produire toutes les erreurs possibles que vous souhaitez ignorer.

OriginalL'auteur David-W-Fenton

0

J'ai vu d'erreur de manipulation aussi échouer. En voici un exemple.
```
Public Function Have(ByVal item As Variant) As Boolean
'Have = Have data.  Simplifies handling nulls and empty strings in validation code

    On Error GoTo Procerr

    If IsNull(item) Then
        Have = False
    **ElseIf Len(Trim(item)) = 0 Then  'Faster than Item <> ""**
        Have = False
    ElseIf item = 0 Then
        Have = False
    Else
        Have = True
    End If

exitproc:
    Exit Function

Procerr:
    'Errors sometimes occur if an unbound control is referenced
    Have = False

End Function
```
Le code échoue parfois sur la ligne marqués avec **. Voici le message d'erreur.

Noter que le gestionnaire d'erreur a échoué. Dans ce cas, la forme qui a appelé le code retourné a sa source mis à la volée à un jeu d'enregistrements vide, d'où les champs de l'écran ne sont pas visibles. Le formulaire est un formulaire continu, de sorte que les enregistrements et les champs ne sont pas visibles lorsque le formulaire est chargé avec un jeu d'enregistrements vide. L'() la fonction n'est pas directement appelé par mon code, mais de toute façon semble être déclenchée par le moi.la méthode requery. L'() a été appelé des centaines de millions de fois dans mon code, mais c'est la seule instance qui provoque l'échec et le gestionnaire d'erreur n'est pas involked.

Lance Roberts re question d'origine. utf-8 unicode peut parfois jouer des ravages avec ms-access, comme il semble être de permettre aux données d'être confondu pour les codes d'instruction (je suppose). utf-8 peuvent entrer dans vos données, si les données ont été initialement chargé à partir d'un fichier texte. utf-8 avec une marque d'ordre des octets (BoM) est particulièrement désagréable. Lorsque vous exécutez une procédure qui fonctionne avec les données, d'étranges erreurs peuvent se produire et cela peut ressembler votre fichier est endommagé. Dans d'autres cas, le traitement de texte fonctions de donner de mauvaises réponses, par exemple, Mid() voir la NOMENCLATURE et si vous spécifiez un point de départ qui débutera à la NOMENCLATURE, mais Len() ignore la NOMENCLATURE. Je suis à envisager que si vous avez ce problème, puis ms-access ne peut pas gérer les erreurs correctement. J'ai eu des problèmes similaires de l'importation de données et de l'importation de l'utf-8 comme ANSI a été la cause. Notez que l'utf-8 et ANSI sont identiques, la plupart du temps pour les anglais de données afin que vos erreurs ne peuvent pas être sur chaque ligne. Mes erreurs étaient pour la plupart avec le temps-les champs de date. Essayez d'exporter les données en premier puis le forçant à la norme ANSI et de supprimer toute Nomenclature et la et la réimportation.

Grâce Andoriyu, Mon système a été mis à l'arrêt sur toutes les erreurs et c'était la question.

OriginalL'auteur AndrewM

Vous devez vous connecter pour publier un commentaire.