Bonjour la Communauté,
Migré depuis peu de Office XP vers Office 2007 SP2, j'ai quelques
soucis avec mes applis Access et Excel.
Celles-ci fonctionnent trés bien sous XP, mais sous 2007, j'obtiens
des codes erreur dans l'objet Err, alors que le code ne se plante pas
même en désactivant le contrôle d'erreur!!
Or donc, le code listé ci-dessous est là pour:
- Créer un RecordSet basé sur le contenu d'une table attachée
contenant un seul enregistrement.
Cette table attachée peut ne plus être valide, ce qui est normal
dans le cadre de l'exploitation de cette base.
Donc
- Si la création du RecordSet génère une erreur, il est probable que
la table attachée ne soit plus valide (lien rompu), dans ce cas,
j'alerte l'utilisateur et le dirige vers un formulaire permettant de
rétablir tous les liens de la base de données
- Si la création du RecordSet ne génère pas d'erreur, je traite
l'enregistrement.
D'où le code suivant.
01 Function InitCodeCentraleTraitée() As Boolean
02 ' Initialiser le Code Centrale exécutant l'application
03 ' Initialiser les variables globales
04 Dim frd As Recordset
05 Dim Fnct As Boolean
06 InitCodeCentraleTraitée = False
07 On Error Resume Next
08 Err.Clear
09 Set frd = CurrentDb.OpenRecordset("SELECT * FROM Centrales WHERE
[Centrale traitée] = True", dbOpenSnapshot)
10 If Err <> 0 Then
11 MsgBox "Impossible de trouver la table 'Centrales'. L'attache de
table est certainement incorrecte." & Chr$(10) & Chr$(13) &
Err.Description, vbCritical + vbOKOnly, SMT_NOMAPPLICATION
12 DoCmd.OpenForm "Menu Attacher Tables", acNormal, , , ,
acWindowNormal
13 GoTo InitCodeCentraleTraitée_Fin
14 End If
15 On Error GoTo 0
16 If frd.BOF Then
17 CodeCentraleTraitée = 0 'Non défini
18 MsgBox "Le Code Centrale Traitée n'est pas défini." & Chr$(10) &
Chr$(13) & "Veuillez modifier ce paramètre dans la table
'Centrales'.", vbCritical + vbOKOnly, SMT_NOMAPPLICATION
19 GoTo InitCodeCentraleTraitée_Fin
20 End If
21 Fnct = InitVariablesGlobales()
22 InitCodeCentraleTraitée = True
23 CodeCentraleTraitée = frd.Fields("Code_centrale")
24 InitCodeCentraleTraitée_Fin:
25 frd.Close
26 Set frd = Nothing
27 End Function
Mon problème se situe en ligne 09.
La variable frd est bien initialisée, je l'ai vérifié par des ?
frd.fields(1).value dans la fenêtre Exécution de VBA.
Or l'objet Err prend la valeur 91 - Variable objet ou variable de bloc
With non définie!!!!
Si je place un point d'arrêt sur la ligne 09, exécutant le Set, et que
je continue en pas à pas, je n'obtiens pas l'erreur!
Si je place mon point d'arrêt sur la ligne 10, soit après l'exécution
du Set, j'obtiens l'erreur.
Un Debug.Print Err.Number, Err.Description juste avant le Set donne
comme résultat "0".
C'est donc bien le Set qui déclenche l'erreur, mais il ne plante pas.
J'ai un comportement similaire dans Excel.
Je me suis tourné vers nos amis Excelliens mais je n'ai pas obtenu de
réponse expliquant le problème.
On Error Resume Next
For intL = 3 To 15 Step 3
Err.Clear
.Cells(RngFind.Row, 33 + intL) = CDbl(Me.Controls ("TbxProPvc1" &
Format(CStr(intL), "00"))) <<--- Génère l'erreur
If Err.Number <> 0 Then
MsgBox "Donnée incorrecte.", vbExclamation + vbOKOnly,
ETPP_NomApplication
Me.Controls("TbxProPvc1" & Format(CStr(intL),"00")).SetFocus
GoTo Restituer_Fin
End If
Next intL
L'interception d'erreur n'est la que au cas où!
En effet, sans le On Error Resume Next, le code se déroule sans
problème, du fait que je réalise le maximum de vérification en amont.
Pas de plantage et cependant, l'objet Err prend la valeur 9 - L'indice
n'appartient pas à la sélection.
Ma question: Pourquoi le code ne plante alors que l'objet Err restitue
un code erreur?
Si vous avez des idées je suis preneur.
D'avance merci et bon code.
Cordialement.
Bonjour la Communauté,
Migré depuis peu de Office XP vers Office 2007 SP2, j'ai quelques
soucis avec mes applis Access et Excel.
Celles-ci fonctionnent trés bien sous XP, mais sous 2007, j'obtiens
des codes erreur dans l'objet Err, alors que le code ne se plante pas
même en désactivant le contrôle d'erreur!!
Or donc, le code listé ci-dessous est là pour:
- Créer un RecordSet basé sur le contenu d'une table attachée
contenant un seul enregistrement.
Cette table attachée peut ne plus être valide, ce qui est normal
dans le cadre de l'exploitation de cette base.
Donc
- Si la création du RecordSet génère une erreur, il est probable que
la table attachée ne soit plus valide (lien rompu), dans ce cas,
j'alerte l'utilisateur et le dirige vers un formulaire permettant de
rétablir tous les liens de la base de données
- Si la création du RecordSet ne génère pas d'erreur, je traite
l'enregistrement.
D'où le code suivant.
01 Function InitCodeCentraleTraitée() As Boolean
02 ' Initialiser le Code Centrale exécutant l'application
03 ' Initialiser les variables globales
04 Dim frd As Recordset
05 Dim Fnct As Boolean
06 InitCodeCentraleTraitée = False
07 On Error Resume Next
08 Err.Clear
09 Set frd = CurrentDb.OpenRecordset("SELECT * FROM Centrales WHERE
[Centrale traitée] = True", dbOpenSnapshot)
10 If Err <> 0 Then
11 MsgBox "Impossible de trouver la table 'Centrales'. L'attache de
table est certainement incorrecte." & Chr$(10) & Chr$(13) &
Err.Description, vbCritical + vbOKOnly, SMT_NOMAPPLICATION
12 DoCmd.OpenForm "Menu Attacher Tables", acNormal, , , ,
acWindowNormal
13 GoTo InitCodeCentraleTraitée_Fin
14 End If
15 On Error GoTo 0
16 If frd.BOF Then
17 CodeCentraleTraitée = 0 'Non défini
18 MsgBox "Le Code Centrale Traitée n'est pas défini." & Chr$(10) &
Chr$(13) & "Veuillez modifier ce paramètre dans la table
'Centrales'.", vbCritical + vbOKOnly, SMT_NOMAPPLICATION
19 GoTo InitCodeCentraleTraitée_Fin
20 End If
21 Fnct = InitVariablesGlobales()
22 InitCodeCentraleTraitée = True
23 CodeCentraleTraitée = frd.Fields("Code_centrale")
24 InitCodeCentraleTraitée_Fin:
25 frd.Close
26 Set frd = Nothing
27 End Function
Mon problème se situe en ligne 09.
La variable frd est bien initialisée, je l'ai vérifié par des ?
frd.fields(1).value dans la fenêtre Exécution de VBA.
Or l'objet Err prend la valeur 91 - Variable objet ou variable de bloc
With non définie!!!!
Si je place un point d'arrêt sur la ligne 09, exécutant le Set, et que
je continue en pas à pas, je n'obtiens pas l'erreur!
Si je place mon point d'arrêt sur la ligne 10, soit après l'exécution
du Set, j'obtiens l'erreur.
Un Debug.Print Err.Number, Err.Description juste avant le Set donne
comme résultat "0".
C'est donc bien le Set qui déclenche l'erreur, mais il ne plante pas.
J'ai un comportement similaire dans Excel.
Je me suis tourné vers nos amis Excelliens mais je n'ai pas obtenu de
réponse expliquant le problème.
On Error Resume Next
For intL = 3 To 15 Step 3
Err.Clear
.Cells(RngFind.Row, 33 + intL) = CDbl(Me.Controls ("TbxProPvc1" &
Format(CStr(intL), "00"))) <<--- Génère l'erreur
If Err.Number <> 0 Then
MsgBox "Donnée incorrecte.", vbExclamation + vbOKOnly,
ETPP_NomApplication
Me.Controls("TbxProPvc1" & Format(CStr(intL),"00")).SetFocus
GoTo Restituer_Fin
End If
Next intL
L'interception d'erreur n'est la que au cas où!
En effet, sans le On Error Resume Next, le code se déroule sans
problème, du fait que je réalise le maximum de vérification en amont.
Pas de plantage et cependant, l'objet Err prend la valeur 9 - L'indice
n'appartient pas à la sélection.
Ma question: Pourquoi le code ne plante alors que l'objet Err restitue
un code erreur?
Si vous avez des idées je suis preneur.
D'avance merci et bon code.
Cordialement.
Bonjour la Communauté,
Migré depuis peu de Office XP vers Office 2007 SP2, j'ai quelques
soucis avec mes applis Access et Excel.
Celles-ci fonctionnent trés bien sous XP, mais sous 2007, j'obtiens
des codes erreur dans l'objet Err, alors que le code ne se plante pas
même en désactivant le contrôle d'erreur!!
Or donc, le code listé ci-dessous est là pour:
- Créer un RecordSet basé sur le contenu d'une table attachée
contenant un seul enregistrement.
Cette table attachée peut ne plus être valide, ce qui est normal
dans le cadre de l'exploitation de cette base.
Donc
- Si la création du RecordSet génère une erreur, il est probable que
la table attachée ne soit plus valide (lien rompu), dans ce cas,
j'alerte l'utilisateur et le dirige vers un formulaire permettant de
rétablir tous les liens de la base de données
- Si la création du RecordSet ne génère pas d'erreur, je traite
l'enregistrement.
D'où le code suivant.
01 Function InitCodeCentraleTraitée() As Boolean
02 ' Initialiser le Code Centrale exécutant l'application
03 ' Initialiser les variables globales
04 Dim frd As Recordset
05 Dim Fnct As Boolean
06 InitCodeCentraleTraitée = False
07 On Error Resume Next
08 Err.Clear
09 Set frd = CurrentDb.OpenRecordset("SELECT * FROM Centrales WHERE
[Centrale traitée] = True", dbOpenSnapshot)
10 If Err <> 0 Then
11 MsgBox "Impossible de trouver la table 'Centrales'. L'attache de
table est certainement incorrecte." & Chr$(10) & Chr$(13) &
Err.Description, vbCritical + vbOKOnly, SMT_NOMAPPLICATION
12 DoCmd.OpenForm "Menu Attacher Tables", acNormal, , , ,
acWindowNormal
13 GoTo InitCodeCentraleTraitée_Fin
14 End If
15 On Error GoTo 0
16 If frd.BOF Then
17 CodeCentraleTraitée = 0 'Non défini
18 MsgBox "Le Code Centrale Traitée n'est pas défini." & Chr$(10) &
Chr$(13) & "Veuillez modifier ce paramètre dans la table
'Centrales'.", vbCritical + vbOKOnly, SMT_NOMAPPLICATION
19 GoTo InitCodeCentraleTraitée_Fin
20 End If
21 Fnct = InitVariablesGlobales()
22 InitCodeCentraleTraitée = True
23 CodeCentraleTraitée = frd.Fields("Code_centrale")
24 InitCodeCentraleTraitée_Fin:
25 frd.Close
26 Set frd = Nothing
27 End Function
Mon problème se situe en ligne 09.
La variable frd est bien initialisée, je l'ai vérifié par des ?
frd.fields(1).value dans la fenêtre Exécution de VBA.
Or l'objet Err prend la valeur 91 - Variable objet ou variable de bloc
With non définie!!!!
Si je place un point d'arrêt sur la ligne 09, exécutant le Set, et que
je continue en pas à pas, je n'obtiens pas l'erreur!
Si je place mon point d'arrêt sur la ligne 10, soit après l'exécution
du Set, j'obtiens l'erreur.
Un Debug.Print Err.Number, Err.Description juste avant le Set donne
comme résultat "0".
C'est donc bien le Set qui déclenche l'erreur, mais il ne plante pas.
J'ai un comportement similaire dans Excel.
Je me suis tourné vers nos amis Excelliens mais je n'ai pas obtenu de
réponse expliquant le problème.
On Error Resume Next
For intL = 3 To 15 Step 3
Err.Clear
.Cells(RngFind.Row, 33 + intL) = CDbl(Me.Controls ("TbxProPvc1" &
Format(CStr(intL), "00"))) <<--- Génère l'erreur
If Err.Number <> 0 Then
MsgBox "Donnée incorrecte.", vbExclamation + vbOKOnly,
ETPP_NomApplication
Me.Controls("TbxProPvc1" & Format(CStr(intL),"00")).SetFocus
GoTo Restituer_Fin
End If
Next intL
L'interception d'erreur n'est la que au cas où!
En effet, sans le On Error Resume Next, le code se déroule sans
problème, du fait que je réalise le maximum de vérification en amont.
Pas de plantage et cependant, l'objet Err prend la valeur 9 - L'indice
n'appartient pas à la sélection.
Ma question: Pourquoi le code ne plante alors que l'objet Err restitue
un code erreur?
Si vous avez des idées je suis preneur.
D'avance merci et bon code.
Cordialement.
Bonjour.
Es-tu sûr d'avoir un textbox nommé TbxProPvc115 ?
Daniel
> Bonjour la Communauté,
> Migré depuis peu de Office XP vers Office 2007 SP2, j'ai quelques
> soucis avec mes applis Access et Excel.
> Celles-ci fonctionnent trés bien sous XP, mais sous 2007, j'obtiens
> des codes erreur dans l'objet Err, alors que le code ne se plante pas
> même en désactivant le contrôle d'erreur!!
> Or donc, le code listé ci-dessous est là pour:
> - Créer un RecordSet basé sur le contenu d'une table attachée
> contenant un seul enregistrement.
> Cette table attachée peut ne plus être valide, ce qui est n ormal
> dans le cadre de l'exploitation de cette base.
> Donc
> - Si la création du RecordSet génère une erreur, il est proba ble que
> la table attachée ne soit plus valide (lien rompu), dans ce cas,
> j'alerte l'utilisateur et le dirige vers un formulaire permettant de
> rétablir tous les liens de la base de données
> - Si la création du RecordSet ne génère pas d'erreur, je trai te
> l'enregistrement.
> D'où le code suivant.
> 01 Function InitCodeCentraleTraitée() As Boolean
> 02 ' Initialiser le Code Centrale exécutant l'application
> 03 ' Initialiser les variables globales
> 04 Dim frd As Recordset
> 05 Dim Fnct As Boolean
> 06 InitCodeCentraleTraitée = False
> 07 On Error Resume Next
> 08 Err.Clear
> 09 Set frd = CurrentDb.OpenRecordset("SELECT * FROM Centrales WHER E
> [Centrale traitée] = True", dbOpenSnapshot)
> 10 If Err <> 0 Then
> 11 MsgBox "Impossible de trouver la table 'Centrales'. L'attache de
> table est certainement incorrecte." & Chr$(10) & Chr$(13) &
> Err.Description, vbCritical + vbOKOnly, SMT_NOMAPPLICATION
> 12 DoCmd.OpenForm "Menu Attacher Tables", acNormal, , , ,
> acWindowNormal
> 13 GoTo InitCodeCentraleTraitée_Fin
> 14 End If
> 15 On Error GoTo 0
> 16 If frd.BOF Then
> 17 CodeCentraleTraitée = 0 'Non défini
> 18 MsgBox "Le Code Centrale Traitée n'est pas défini." & Chr $(10) &
> Chr$(13) & "Veuillez modifier ce paramètre dans la table
> 'Centrales'.", vbCritical + vbOKOnly, SMT_NOMAPPLICATION
> 19 GoTo InitCodeCentraleTraitée_Fin
> 20 End If
> 21 Fnct = InitVariablesGlobales()
> 22 InitCodeCentraleTraitée = True
> 23 CodeCentraleTraitée = frd.Fields("Code_centrale")
> 24 InitCodeCentraleTraitée_Fin:
> 25 frd.Close
> 26 Set frd = Nothing
> 27 End Function
> Mon problème se situe en ligne 09.
> La variable frd est bien initialisée, je l'ai vérifié par des ?
> frd.fields(1).value dans la fenêtre Exécution de VBA.
> Or l'objet Err prend la valeur 91 - Variable objet ou variable de bloc
> With non définie!!!!
> Si je place un point d'arrêt sur la ligne 09, exécutant le Set, et que
> je continue en pas à pas, je n'obtiens pas l'erreur!
> Si je place mon point d'arrêt sur la ligne 10, soit après l'exécu tion
> du Set, j'obtiens l'erreur.
> Un Debug.Print Err.Number, Err.Description juste avant le Set donne
> comme résultat "0".
> C'est donc bien le Set qui déclenche l'erreur, mais il ne plante pas.
> J'ai un comportement similaire dans Excel.
> Je me suis tourné vers nos amis Excelliens mais je n'ai pas obtenu de
> réponse expliquant le problème.
> On Error Resume Next
> For intL = 3 To 15 Step 3
> Err.Clear
> .Cells(RngFind.Row, 33 + intL) = CDbl(Me.Controls ("TbxProPvc1 " &
> Format(CStr(intL), "00"))) <<--- Génère l'erreur
> If Err.Number <> 0 Then
> MsgBox "Donnée incorrecte.", vbExclamation + vbOKOnly,
> ETPP_NomApplication
> Me.Controls("TbxProPvc1" & Format(CStr(intL),"00")).SetFocus
> GoTo Restituer_Fin
> End If
> Next intL
> L'interception d'erreur n'est la que au cas où!
> En effet, sans le On Error Resume Next, le code se déroule sans
> problème, du fait que je réalise le maximum de vérification en am ont.
> Pas de plantage et cependant, l'objet Err prend la valeur 9 - L'indice
> n'appartient pas à la sélection.
> Ma question: Pourquoi le code ne plante alors que l'objet Err restitue
> un code erreur?
> Si vous avez des idées je suis preneur.
> D'avance merci et bon code.
> Cordialement.- Masquer le texte des messages précédents -
- Afficher le texte des messages précédents -
Bonjour.
Es-tu sûr d'avoir un textbox nommé TbxProPvc115 ?
Daniel
> Bonjour la Communauté,
> Migré depuis peu de Office XP vers Office 2007 SP2, j'ai quelques
> soucis avec mes applis Access et Excel.
> Celles-ci fonctionnent trés bien sous XP, mais sous 2007, j'obtiens
> des codes erreur dans l'objet Err, alors que le code ne se plante pas
> même en désactivant le contrôle d'erreur!!
> Or donc, le code listé ci-dessous est là pour:
> - Créer un RecordSet basé sur le contenu d'une table attachée
> contenant un seul enregistrement.
> Cette table attachée peut ne plus être valide, ce qui est n ormal
> dans le cadre de l'exploitation de cette base.
> Donc
> - Si la création du RecordSet génère une erreur, il est proba ble que
> la table attachée ne soit plus valide (lien rompu), dans ce cas,
> j'alerte l'utilisateur et le dirige vers un formulaire permettant de
> rétablir tous les liens de la base de données
> - Si la création du RecordSet ne génère pas d'erreur, je trai te
> l'enregistrement.
> D'où le code suivant.
> 01 Function InitCodeCentraleTraitée() As Boolean
> 02 ' Initialiser le Code Centrale exécutant l'application
> 03 ' Initialiser les variables globales
> 04 Dim frd As Recordset
> 05 Dim Fnct As Boolean
> 06 InitCodeCentraleTraitée = False
> 07 On Error Resume Next
> 08 Err.Clear
> 09 Set frd = CurrentDb.OpenRecordset("SELECT * FROM Centrales WHER E
> [Centrale traitée] = True", dbOpenSnapshot)
> 10 If Err <> 0 Then
> 11 MsgBox "Impossible de trouver la table 'Centrales'. L'attache de
> table est certainement incorrecte." & Chr$(10) & Chr$(13) &
> Err.Description, vbCritical + vbOKOnly, SMT_NOMAPPLICATION
> 12 DoCmd.OpenForm "Menu Attacher Tables", acNormal, , , ,
> acWindowNormal
> 13 GoTo InitCodeCentraleTraitée_Fin
> 14 End If
> 15 On Error GoTo 0
> 16 If frd.BOF Then
> 17 CodeCentraleTraitée = 0 'Non défini
> 18 MsgBox "Le Code Centrale Traitée n'est pas défini." & Chr $(10) &
> Chr$(13) & "Veuillez modifier ce paramètre dans la table
> 'Centrales'.", vbCritical + vbOKOnly, SMT_NOMAPPLICATION
> 19 GoTo InitCodeCentraleTraitée_Fin
> 20 End If
> 21 Fnct = InitVariablesGlobales()
> 22 InitCodeCentraleTraitée = True
> 23 CodeCentraleTraitée = frd.Fields("Code_centrale")
> 24 InitCodeCentraleTraitée_Fin:
> 25 frd.Close
> 26 Set frd = Nothing
> 27 End Function
> Mon problème se situe en ligne 09.
> La variable frd est bien initialisée, je l'ai vérifié par des ?
> frd.fields(1).value dans la fenêtre Exécution de VBA.
> Or l'objet Err prend la valeur 91 - Variable objet ou variable de bloc
> With non définie!!!!
> Si je place un point d'arrêt sur la ligne 09, exécutant le Set, et que
> je continue en pas à pas, je n'obtiens pas l'erreur!
> Si je place mon point d'arrêt sur la ligne 10, soit après l'exécu tion
> du Set, j'obtiens l'erreur.
> Un Debug.Print Err.Number, Err.Description juste avant le Set donne
> comme résultat "0".
> C'est donc bien le Set qui déclenche l'erreur, mais il ne plante pas.
> J'ai un comportement similaire dans Excel.
> Je me suis tourné vers nos amis Excelliens mais je n'ai pas obtenu de
> réponse expliquant le problème.
> On Error Resume Next
> For intL = 3 To 15 Step 3
> Err.Clear
> .Cells(RngFind.Row, 33 + intL) = CDbl(Me.Controls ("TbxProPvc1 " &
> Format(CStr(intL), "00"))) <<--- Génère l'erreur
> If Err.Number <> 0 Then
> MsgBox "Donnée incorrecte.", vbExclamation + vbOKOnly,
> ETPP_NomApplication
> Me.Controls("TbxProPvc1" & Format(CStr(intL),"00")).SetFocus
> GoTo Restituer_Fin
> End If
> Next intL
> L'interception d'erreur n'est la que au cas où!
> En effet, sans le On Error Resume Next, le code se déroule sans
> problème, du fait que je réalise le maximum de vérification en am ont.
> Pas de plantage et cependant, l'objet Err prend la valeur 9 - L'indice
> n'appartient pas à la sélection.
> Ma question: Pourquoi le code ne plante alors que l'objet Err restitue
> un code erreur?
> Si vous avez des idées je suis preneur.
> D'avance merci et bon code.
> Cordialement.- Masquer le texte des messages précédents -
- Afficher le texte des messages précédents -
Bonjour.
Es-tu sûr d'avoir un textbox nommé TbxProPvc115 ?
Daniel
> Bonjour la Communauté,
> Migré depuis peu de Office XP vers Office 2007 SP2, j'ai quelques
> soucis avec mes applis Access et Excel.
> Celles-ci fonctionnent trés bien sous XP, mais sous 2007, j'obtiens
> des codes erreur dans l'objet Err, alors que le code ne se plante pas
> même en désactivant le contrôle d'erreur!!
> Or donc, le code listé ci-dessous est là pour:
> - Créer un RecordSet basé sur le contenu d'une table attachée
> contenant un seul enregistrement.
> Cette table attachée peut ne plus être valide, ce qui est n ormal
> dans le cadre de l'exploitation de cette base.
> Donc
> - Si la création du RecordSet génère une erreur, il est proba ble que
> la table attachée ne soit plus valide (lien rompu), dans ce cas,
> j'alerte l'utilisateur et le dirige vers un formulaire permettant de
> rétablir tous les liens de la base de données
> - Si la création du RecordSet ne génère pas d'erreur, je trai te
> l'enregistrement.
> D'où le code suivant.
> 01 Function InitCodeCentraleTraitée() As Boolean
> 02 ' Initialiser le Code Centrale exécutant l'application
> 03 ' Initialiser les variables globales
> 04 Dim frd As Recordset
> 05 Dim Fnct As Boolean
> 06 InitCodeCentraleTraitée = False
> 07 On Error Resume Next
> 08 Err.Clear
> 09 Set frd = CurrentDb.OpenRecordset("SELECT * FROM Centrales WHER E
> [Centrale traitée] = True", dbOpenSnapshot)
> 10 If Err <> 0 Then
> 11 MsgBox "Impossible de trouver la table 'Centrales'. L'attache de
> table est certainement incorrecte." & Chr$(10) & Chr$(13) &
> Err.Description, vbCritical + vbOKOnly, SMT_NOMAPPLICATION
> 12 DoCmd.OpenForm "Menu Attacher Tables", acNormal, , , ,
> acWindowNormal
> 13 GoTo InitCodeCentraleTraitée_Fin
> 14 End If
> 15 On Error GoTo 0
> 16 If frd.BOF Then
> 17 CodeCentraleTraitée = 0 'Non défini
> 18 MsgBox "Le Code Centrale Traitée n'est pas défini." & Chr $(10) &
> Chr$(13) & "Veuillez modifier ce paramètre dans la table
> 'Centrales'.", vbCritical + vbOKOnly, SMT_NOMAPPLICATION
> 19 GoTo InitCodeCentraleTraitée_Fin
> 20 End If
> 21 Fnct = InitVariablesGlobales()
> 22 InitCodeCentraleTraitée = True
> 23 CodeCentraleTraitée = frd.Fields("Code_centrale")
> 24 InitCodeCentraleTraitée_Fin:
> 25 frd.Close
> 26 Set frd = Nothing
> 27 End Function
> Mon problème se situe en ligne 09.
> La variable frd est bien initialisée, je l'ai vérifié par des ?
> frd.fields(1).value dans la fenêtre Exécution de VBA.
> Or l'objet Err prend la valeur 91 - Variable objet ou variable de bloc
> With non définie!!!!
> Si je place un point d'arrêt sur la ligne 09, exécutant le Set, et que
> je continue en pas à pas, je n'obtiens pas l'erreur!
> Si je place mon point d'arrêt sur la ligne 10, soit après l'exécu tion
> du Set, j'obtiens l'erreur.
> Un Debug.Print Err.Number, Err.Description juste avant le Set donne
> comme résultat "0".
> C'est donc bien le Set qui déclenche l'erreur, mais il ne plante pas.
> J'ai un comportement similaire dans Excel.
> Je me suis tourné vers nos amis Excelliens mais je n'ai pas obtenu de
> réponse expliquant le problème.
> On Error Resume Next
> For intL = 3 To 15 Step 3
> Err.Clear
> .Cells(RngFind.Row, 33 + intL) = CDbl(Me.Controls ("TbxProPvc1 " &
> Format(CStr(intL), "00"))) <<--- Génère l'erreur
> If Err.Number <> 0 Then
> MsgBox "Donnée incorrecte.", vbExclamation + vbOKOnly,
> ETPP_NomApplication
> Me.Controls("TbxProPvc1" & Format(CStr(intL),"00")).SetFocus
> GoTo Restituer_Fin
> End If
> Next intL
> L'interception d'erreur n'est la que au cas où!
> En effet, sans le On Error Resume Next, le code se déroule sans
> problème, du fait que je réalise le maximum de vérification en am ont.
> Pas de plantage et cependant, l'objet Err prend la valeur 9 - L'indice
> n'appartient pas à la sélection.
> Ma question: Pourquoi le code ne plante alors que l'objet Err restitue
> un code erreur?
> Si vous avez des idées je suis preneur.
> D'avance merci et bon code.
> Cordialement.- Masquer le texte des messages précédents -
- Afficher le texte des messages précédents -
Bonjour.
Es-tu sûr d'avoir un textbox nommé TbxProPvc115 ?
Daniel
> Bonjour la Communauté,
> Migré depuis peu de Office XP vers Office 2007 SP2, j'ai quelques
> soucis avec mes applis Access et Excel.
> Celles-ci fonctionnent trés bien sous XP, mais sous 2007, j'obtiens
> des codes erreur dans l'objet Err, alors que le code ne se plante pas
> même en désactivant le contrôle d'erreur!!
> Or donc, le code listé ci-dessous est là pour:
> - Créer un RecordSet basé sur le contenu d'une table attachée
> contenant un seul enregistrement.
> Cette table attachée peut ne plus être valide, ce qui est normal
> dans le cadre de l'exploitation de cette base.
> Donc
> - Si la création du RecordSet génère une erreur, il est probable que
> la table attachée ne soit plus valide (lien rompu), dans ce cas,
> j'alerte l'utilisateur et le dirige vers un formulaire permettant de
> rétablir tous les liens de la base de données
> - Si la création du RecordSet ne génère pas d'erreur, je traite
> l'enregistrement.
> D'où le code suivant.
> 01 Function InitCodeCentraleTraitée() As Boolean
> 02 ' Initialiser le Code Centrale exécutant l'application
> 03 ' Initialiser les variables globales
> 04 Dim frd As Recordset
> 05 Dim Fnct As Boolean
> 06 InitCodeCentraleTraitée = False
> 07 On Error Resume Next
> 08 Err.Clear
> 09 Set frd = CurrentDb.OpenRecordset("SELECT * FROM Centrales WHERE
> [Centrale traitée] = True", dbOpenSnapshot)
> 10 If Err <> 0 Then
> 11 MsgBox "Impossible de trouver la table 'Centrales'. L'attache de
> table est certainement incorrecte." & Chr$(10) & Chr$(13) &
> Err.Description, vbCritical + vbOKOnly, SMT_NOMAPPLICATION
> 12 DoCmd.OpenForm "Menu Attacher Tables", acNormal, , , ,
> acWindowNormal
> 13 GoTo InitCodeCentraleTraitée_Fin
> 14 End If
> 15 On Error GoTo 0
> 16 If frd.BOF Then
> 17 CodeCentraleTraitée = 0 'Non défini
> 18 MsgBox "Le Code Centrale Traitée n'est pas défini." & Chr$(10) &
> Chr$(13) & "Veuillez modifier ce paramètre dans la table
> 'Centrales'.", vbCritical + vbOKOnly, SMT_NOMAPPLICATION
> 19 GoTo InitCodeCentraleTraitée_Fin
> 20 End If
> 21 Fnct = InitVariablesGlobales()
> 22 InitCodeCentraleTraitée = True
> 23 CodeCentraleTraitée = frd.Fields("Code_centrale")
> 24 InitCodeCentraleTraitée_Fin:
> 25 frd.Close
> 26 Set frd = Nothing
> 27 End Function
> Mon problème se situe en ligne 09.
> La variable frd est bien initialisée, je l'ai vérifié par des ?
> frd.fields(1).value dans la fenêtre Exécution de VBA.
> Or l'objet Err prend la valeur 91 - Variable objet ou variable de bloc
> With non définie!!!!
> Si je place un point d'arrêt sur la ligne 09, exécutant le Set, et que
> je continue en pas à pas, je n'obtiens pas l'erreur!
> Si je place mon point d'arrêt sur la ligne 10, soit après l'exécution
> du Set, j'obtiens l'erreur.
> Un Debug.Print Err.Number, Err.Description juste avant le Set donne
> comme résultat "0".
> C'est donc bien le Set qui déclenche l'erreur, mais il ne plante pas.
> J'ai un comportement similaire dans Excel.
> Je me suis tourné vers nos amis Excelliens mais je n'ai pas obtenu de
> réponse expliquant le problème.
> On Error Resume Next
> For intL = 3 To 15 Step 3
> Err.Clear
> .Cells(RngFind.Row, 33 + intL) = CDbl(Me.Controls ("TbxProPvc1" &
> Format(CStr(intL), "00"))) <<--- Génère l'erreur
> If Err.Number <> 0 Then
> MsgBox "Donnée incorrecte.", vbExclamation + vbOKOnly,
> ETPP_NomApplication
> Me.Controls("TbxProPvc1" & Format(CStr(intL),"00")).SetFocus
> GoTo Restituer_Fin
> End If
> Next intL
> L'interception d'erreur n'est la que au cas où!
> En effet, sans le On Error Resume Next, le code se déroule sans
> problème, du fait que je réalise le maximum de vérification en amont.
> Pas de plantage et cependant, l'objet Err prend la valeur 9 - L'indice
> n'appartient pas à la sélection.
> Ma question: Pourquoi le code ne plante alors que l'objet Err restitue
> un code erreur?
> Si vous avez des idées je suis preneur.
> D'avance merci et bon code.
> Cordialement.- Masquer le texte des messages précédents -
- Afficher le texte des messages précédents -
Bonjour.
Es-tu sûr d'avoir un textbox nommé TbxProPvc115 ?
Daniel
> Bonjour la Communauté,
> Migré depuis peu de Office XP vers Office 2007 SP2, j'ai quelques
> soucis avec mes applis Access et Excel.
> Celles-ci fonctionnent trés bien sous XP, mais sous 2007, j'obtiens
> des codes erreur dans l'objet Err, alors que le code ne se plante pas
> même en désactivant le contrôle d'erreur!!
> Or donc, le code listé ci-dessous est là pour:
> - Créer un RecordSet basé sur le contenu d'une table attachée
> contenant un seul enregistrement.
> Cette table attachée peut ne plus être valide, ce qui est normal
> dans le cadre de l'exploitation de cette base.
> Donc
> - Si la création du RecordSet génère une erreur, il est probable que
> la table attachée ne soit plus valide (lien rompu), dans ce cas,
> j'alerte l'utilisateur et le dirige vers un formulaire permettant de
> rétablir tous les liens de la base de données
> - Si la création du RecordSet ne génère pas d'erreur, je traite
> l'enregistrement.
> D'où le code suivant.
> 01 Function InitCodeCentraleTraitée() As Boolean
> 02 ' Initialiser le Code Centrale exécutant l'application
> 03 ' Initialiser les variables globales
> 04 Dim frd As Recordset
> 05 Dim Fnct As Boolean
> 06 InitCodeCentraleTraitée = False
> 07 On Error Resume Next
> 08 Err.Clear
> 09 Set frd = CurrentDb.OpenRecordset("SELECT * FROM Centrales WHERE
> [Centrale traitée] = True", dbOpenSnapshot)
> 10 If Err <> 0 Then
> 11 MsgBox "Impossible de trouver la table 'Centrales'. L'attache de
> table est certainement incorrecte." & Chr$(10) & Chr$(13) &
> Err.Description, vbCritical + vbOKOnly, SMT_NOMAPPLICATION
> 12 DoCmd.OpenForm "Menu Attacher Tables", acNormal, , , ,
> acWindowNormal
> 13 GoTo InitCodeCentraleTraitée_Fin
> 14 End If
> 15 On Error GoTo 0
> 16 If frd.BOF Then
> 17 CodeCentraleTraitée = 0 'Non défini
> 18 MsgBox "Le Code Centrale Traitée n'est pas défini." & Chr$(10) &
> Chr$(13) & "Veuillez modifier ce paramètre dans la table
> 'Centrales'.", vbCritical + vbOKOnly, SMT_NOMAPPLICATION
> 19 GoTo InitCodeCentraleTraitée_Fin
> 20 End If
> 21 Fnct = InitVariablesGlobales()
> 22 InitCodeCentraleTraitée = True
> 23 CodeCentraleTraitée = frd.Fields("Code_centrale")
> 24 InitCodeCentraleTraitée_Fin:
> 25 frd.Close
> 26 Set frd = Nothing
> 27 End Function
> Mon problème se situe en ligne 09.
> La variable frd est bien initialisée, je l'ai vérifié par des ?
> frd.fields(1).value dans la fenêtre Exécution de VBA.
> Or l'objet Err prend la valeur 91 - Variable objet ou variable de bloc
> With non définie!!!!
> Si je place un point d'arrêt sur la ligne 09, exécutant le Set, et que
> je continue en pas à pas, je n'obtiens pas l'erreur!
> Si je place mon point d'arrêt sur la ligne 10, soit après l'exécution
> du Set, j'obtiens l'erreur.
> Un Debug.Print Err.Number, Err.Description juste avant le Set donne
> comme résultat "0".
> C'est donc bien le Set qui déclenche l'erreur, mais il ne plante pas.
> J'ai un comportement similaire dans Excel.
> Je me suis tourné vers nos amis Excelliens mais je n'ai pas obtenu de
> réponse expliquant le problème.
> On Error Resume Next
> For intL = 3 To 15 Step 3
> Err.Clear
> .Cells(RngFind.Row, 33 + intL) = CDbl(Me.Controls ("TbxProPvc1" &
> Format(CStr(intL), "00"))) <<--- Génère l'erreur
> If Err.Number <> 0 Then
> MsgBox "Donnée incorrecte.", vbExclamation + vbOKOnly,
> ETPP_NomApplication
> Me.Controls("TbxProPvc1" & Format(CStr(intL),"00")).SetFocus
> GoTo Restituer_Fin
> End If
> Next intL
> L'interception d'erreur n'est la que au cas où!
> En effet, sans le On Error Resume Next, le code se déroule sans
> problème, du fait que je réalise le maximum de vérification en amont.
> Pas de plantage et cependant, l'objet Err prend la valeur 9 - L'indice
> n'appartient pas à la sélection.
> Ma question: Pourquoi le code ne plante alors que l'objet Err restitue
> un code erreur?
> Si vous avez des idées je suis preneur.
> D'avance merci et bon code.
> Cordialement.- Masquer le texte des messages précédents -
- Afficher le texte des messages précédents -
Bonjour.
Es-tu sûr d'avoir un textbox nommé TbxProPvc115 ?
Daniel
> Bonjour la Communauté,
> Migré depuis peu de Office XP vers Office 2007 SP2, j'ai quelques
> soucis avec mes applis Access et Excel.
> Celles-ci fonctionnent trés bien sous XP, mais sous 2007, j'obtiens
> des codes erreur dans l'objet Err, alors que le code ne se plante pas
> même en désactivant le contrôle d'erreur!!
> Or donc, le code listé ci-dessous est là pour:
> - Créer un RecordSet basé sur le contenu d'une table attachée
> contenant un seul enregistrement.
> Cette table attachée peut ne plus être valide, ce qui est normal
> dans le cadre de l'exploitation de cette base.
> Donc
> - Si la création du RecordSet génère une erreur, il est probable que
> la table attachée ne soit plus valide (lien rompu), dans ce cas,
> j'alerte l'utilisateur et le dirige vers un formulaire permettant de
> rétablir tous les liens de la base de données
> - Si la création du RecordSet ne génère pas d'erreur, je traite
> l'enregistrement.
> D'où le code suivant.
> 01 Function InitCodeCentraleTraitée() As Boolean
> 02 ' Initialiser le Code Centrale exécutant l'application
> 03 ' Initialiser les variables globales
> 04 Dim frd As Recordset
> 05 Dim Fnct As Boolean
> 06 InitCodeCentraleTraitée = False
> 07 On Error Resume Next
> 08 Err.Clear
> 09 Set frd = CurrentDb.OpenRecordset("SELECT * FROM Centrales WHERE
> [Centrale traitée] = True", dbOpenSnapshot)
> 10 If Err <> 0 Then
> 11 MsgBox "Impossible de trouver la table 'Centrales'. L'attache de
> table est certainement incorrecte." & Chr$(10) & Chr$(13) &
> Err.Description, vbCritical + vbOKOnly, SMT_NOMAPPLICATION
> 12 DoCmd.OpenForm "Menu Attacher Tables", acNormal, , , ,
> acWindowNormal
> 13 GoTo InitCodeCentraleTraitée_Fin
> 14 End If
> 15 On Error GoTo 0
> 16 If frd.BOF Then
> 17 CodeCentraleTraitée = 0 'Non défini
> 18 MsgBox "Le Code Centrale Traitée n'est pas défini." & Chr$(10) &
> Chr$(13) & "Veuillez modifier ce paramètre dans la table
> 'Centrales'.", vbCritical + vbOKOnly, SMT_NOMAPPLICATION
> 19 GoTo InitCodeCentraleTraitée_Fin
> 20 End If
> 21 Fnct = InitVariablesGlobales()
> 22 InitCodeCentraleTraitée = True
> 23 CodeCentraleTraitée = frd.Fields("Code_centrale")
> 24 InitCodeCentraleTraitée_Fin:
> 25 frd.Close
> 26 Set frd = Nothing
> 27 End Function
> Mon problème se situe en ligne 09.
> La variable frd est bien initialisée, je l'ai vérifié par des ?
> frd.fields(1).value dans la fenêtre Exécution de VBA.
> Or l'objet Err prend la valeur 91 - Variable objet ou variable de bloc
> With non définie!!!!
> Si je place un point d'arrêt sur la ligne 09, exécutant le Set, et que
> je continue en pas à pas, je n'obtiens pas l'erreur!
> Si je place mon point d'arrêt sur la ligne 10, soit après l'exécution
> du Set, j'obtiens l'erreur.
> Un Debug.Print Err.Number, Err.Description juste avant le Set donne
> comme résultat "0".
> C'est donc bien le Set qui déclenche l'erreur, mais il ne plante pas.
> J'ai un comportement similaire dans Excel.
> Je me suis tourné vers nos amis Excelliens mais je n'ai pas obtenu de
> réponse expliquant le problème.
> On Error Resume Next
> For intL = 3 To 15 Step 3
> Err.Clear
> .Cells(RngFind.Row, 33 + intL) = CDbl(Me.Controls ("TbxProPvc1" &
> Format(CStr(intL), "00"))) <<--- Génère l'erreur
> If Err.Number <> 0 Then
> MsgBox "Donnée incorrecte.", vbExclamation + vbOKOnly,
> ETPP_NomApplication
> Me.Controls("TbxProPvc1" & Format(CStr(intL),"00")).SetFocus
> GoTo Restituer_Fin
> End If
> Next intL
> L'interception d'erreur n'est la que au cas où!
> En effet, sans le On Error Resume Next, le code se déroule sans
> problème, du fait que je réalise le maximum de vérification en amont.
> Pas de plantage et cependant, l'objet Err prend la valeur 9 - L'indice
> n'appartient pas à la sélection.
> Ma question: Pourquoi le code ne plante alors que l'objet Err restitue
> un code erreur?
> Si vous avez des idées je suis preneur.
> D'avance merci et bon code.
> Cordialement.- Masquer le texte des messages précédents -
- Afficher le texte des messages précédents -
Bonjour,
Je n'ai pas l'environnement pour tester ta procédure, mais c'est
toujours une bonne idée d'être précis lorsqu'il s'agit de déclare r
les variables
Je modifierais volontiers ceci
Dim frd As Recordset
Pour
Dim frd As Dao.Recordset
Juste pour éviter une méprise possible si tu as aussi dans ton projet
la bibliothèque ADO de déclarer.
"ElXav" a écrit dans le message de groupe de discussion :
Bonjour Daniel,
Ooops, je n'ai pas posté dans le bon forum.
J'ai déjà posé la question ici, concernant la partie Excel, et oui,
tout le code Excel est bon, les textbox cible existent.
http://groups.google.com/group/microsoft.public.fr.excel/browse_threa...
A tel point, comme je l'explique, en retirant l'interception d'erreur,
le code ne plante pas, et l'objet Err prend la valeur indiquée dans
mon post.
Si tu as des idées...
Merci.
Cordialement.
On 8 avr, 16:08, Daniel.C wrote:
> Bonjour.
> Es-tu sûr d'avoir un textbox nommé TbxProPvc115 ?
> Daniel
> > Bonjour la Communauté,
> > Migré depuis peu de Office XP vers Office 2007 SP2, j'ai quelques
> > soucis avec mes applis Access et Excel.
> > Celles-ci fonctionnent trés bien sous XP, mais sous 2007, j'obtiens
> > des codes erreur dans l'objet Err, alors que le code ne se plante pas
> > même en désactivant le contrôle d'erreur!!
> > Or donc, le code listé ci-dessous est là pour:
> > - Créer un RecordSet basé sur le contenu d'une table attach ée
> > contenant un seul enregistrement.
> > Cette table attachée peut ne plus être valide, ce qui est normal
> > dans le cadre de l'exploitation de cette base.
> > Donc
> > - Si la création du RecordSet génère une erreur, il est pro bable que
> > la table attachée ne soit plus valide (lien rompu), dans ce cas,
> > j'alerte l'utilisateur et le dirige vers un formulaire permettant de
> > rétablir tous les liens de la base de données
> > - Si la création du RecordSet ne génère pas d'erreur, je tr aite
> > l'enregistrement.
> > D'où le code suivant.
> > 01 Function InitCodeCentraleTraitée() As Boolean
> > 02 ' Initialiser le Code Centrale exécutant l'application
> > 03 ' Initialiser les variables globales
> > 04 Dim frd As Recordset
> > 05 Dim Fnct As Boolean
> > 06 InitCodeCentraleTraitée = False
> > 07 On Error Resume Next
> > 08 Err.Clear
> > 09 Set frd = CurrentDb.OpenRecordset("SELECT * FROM Centrales WH ERE
> > [Centrale traitée] = True", dbOpenSnapshot)
> > 10 If Err <> 0 Then
> > 11 MsgBox "Impossible de trouver la table 'Centrales'. L'attac he de
> > table est certainement incorrecte." & Chr$(10) & Chr$(13) &
> > Err.Description, vbCritical + vbOKOnly, SMT_NOMAPPLICATION
> > 12 DoCmd.OpenForm "Menu Attacher Tables", acNormal, , , ,
> > acWindowNormal
> > 13 GoTo InitCodeCentraleTraitée_Fin
> > 14 End If
> > 15 On Error GoTo 0
> > 16 If frd.BOF Then
> > 17 CodeCentraleTraitée = 0 'Non défini
> > 18 MsgBox "Le Code Centrale Traitée n'est pas défini." & C hr$(10) &
> > Chr$(13) & "Veuillez modifier ce paramètre dans la table
> > 'Centrales'.", vbCritical + vbOKOnly, SMT_NOMAPPLICATION
> > 19 GoTo InitCodeCentraleTraitée_Fin
> > 20 End If
> > 21 Fnct = InitVariablesGlobales()
> > 22 InitCodeCentraleTraitée = True
> > 23 CodeCentraleTraitée = frd.Fields("Code_centrale")
> > 24 InitCodeCentraleTraitée_Fin:
> > 25 frd.Close
> > 26 Set frd = Nothing
> > 27 End Function
> > Mon problème se situe en ligne 09.
> > La variable frd est bien initialisée, je l'ai vérifié par des ?
> > frd.fields(1).value dans la fenêtre Exécution de VBA.
> > Or l'objet Err prend la valeur 91 - Variable objet ou variable de blo c
> > With non définie!!!!
> > Si je place un point d'arrêt sur la ligne 09, exécutant le Set, e t que
> > je continue en pas à pas, je n'obtiens pas l'erreur!
> > Si je place mon point d'arrêt sur la ligne 10, soit après l'exé cution
> > du Set, j'obtiens l'erreur.
> > Un Debug.Print Err.Number, Err.Description juste avant le Set donne
> > comme résultat "0".
> > C'est donc bien le Set qui déclenche l'erreur, mais il ne plante pa s.
> > J'ai un comportement similaire dans Excel.
> > Je me suis tourné vers nos amis Excelliens mais je n'ai pas obtenu de
> > réponse expliquant le problème.
> > On Error Resume Next
> > For intL = 3 To 15 Step 3
> > Err.Clear
> > .Cells(RngFind.Row, 33 + intL) = CDbl(Me.Controls ("TbxProPv c1" &
> > Format(CStr(intL), "00"))) <<--- Génère l'erreur
> > If Err.Number <> 0 Then
> > MsgBox "Donnée incorrecte.", vbExclamation + vbOKOnly,
> > ETPP_NomApplication
> > Me.Controls("TbxProPvc1" & Format(CStr(intL),"00")).SetFoc us
> > GoTo Restituer_Fin
> > End If
> > Next intL
> > L'interception d'erreur n'est la que au cas où!
> > En effet, sans le On Error Resume Next, le code se déroule sans
> > problème, du fait que je réalise le maximum de vérification en amont.
> > Pas de plantage et cependant, l'objet Err prend la valeur 9 - L'indic e
> > n'appartient pas à la sélection.
> > Ma question: Pourquoi le code ne plante alors que l'objet Err restitu e
> > un code erreur?
> > Si vous avez des idées je suis preneur.
> > D'avance merci et bon code.
> > Cordialement.- Masquer le texte des messages précédents -
> - Afficher le texte des messages précédents -
Bonjour,
Je n'ai pas l'environnement pour tester ta procédure, mais c'est
toujours une bonne idée d'être précis lorsqu'il s'agit de déclare r
les variables
Je modifierais volontiers ceci
Dim frd As Recordset
Pour
Dim frd As Dao.Recordset
Juste pour éviter une méprise possible si tu as aussi dans ton projet
la bibliothèque ADO de déclarer.
"ElXav" <el...@free.fr> a écrit dans le message de groupe de discussion :
839c29df-5594-4d03-9db4-6522e1dc8...@e7g2000yqf.googlegroups.com...
Bonjour Daniel,
Ooops, je n'ai pas posté dans le bon forum.
J'ai déjà posé la question ici, concernant la partie Excel, et oui,
tout le code Excel est bon, les textbox cible existent.
http://groups.google.com/group/microsoft.public.fr.excel/browse_threa...
A tel point, comme je l'explique, en retirant l'interception d'erreur,
le code ne plante pas, et l'objet Err prend la valeur indiquée dans
mon post.
Si tu as des idées...
Merci.
Cordialement.
On 8 avr, 16:08, Daniel.C <dcolardelle...@gmail.com> wrote:
> Bonjour.
> Es-tu sûr d'avoir un textbox nommé TbxProPvc115 ?
> Daniel
> > Bonjour la Communauté,
> > Migré depuis peu de Office XP vers Office 2007 SP2, j'ai quelques
> > soucis avec mes applis Access et Excel.
> > Celles-ci fonctionnent trés bien sous XP, mais sous 2007, j'obtiens
> > des codes erreur dans l'objet Err, alors que le code ne se plante pas
> > même en désactivant le contrôle d'erreur!!
> > Or donc, le code listé ci-dessous est là pour:
> > - Créer un RecordSet basé sur le contenu d'une table attach ée
> > contenant un seul enregistrement.
> > Cette table attachée peut ne plus être valide, ce qui est normal
> > dans le cadre de l'exploitation de cette base.
> > Donc
> > - Si la création du RecordSet génère une erreur, il est pro bable que
> > la table attachée ne soit plus valide (lien rompu), dans ce cas,
> > j'alerte l'utilisateur et le dirige vers un formulaire permettant de
> > rétablir tous les liens de la base de données
> > - Si la création du RecordSet ne génère pas d'erreur, je tr aite
> > l'enregistrement.
> > D'où le code suivant.
> > 01 Function InitCodeCentraleTraitée() As Boolean
> > 02 ' Initialiser le Code Centrale exécutant l'application
> > 03 ' Initialiser les variables globales
> > 04 Dim frd As Recordset
> > 05 Dim Fnct As Boolean
> > 06 InitCodeCentraleTraitée = False
> > 07 On Error Resume Next
> > 08 Err.Clear
> > 09 Set frd = CurrentDb.OpenRecordset("SELECT * FROM Centrales WH ERE
> > [Centrale traitée] = True", dbOpenSnapshot)
> > 10 If Err <> 0 Then
> > 11 MsgBox "Impossible de trouver la table 'Centrales'. L'attac he de
> > table est certainement incorrecte." & Chr$(10) & Chr$(13) &
> > Err.Description, vbCritical + vbOKOnly, SMT_NOMAPPLICATION
> > 12 DoCmd.OpenForm "Menu Attacher Tables", acNormal, , , ,
> > acWindowNormal
> > 13 GoTo InitCodeCentraleTraitée_Fin
> > 14 End If
> > 15 On Error GoTo 0
> > 16 If frd.BOF Then
> > 17 CodeCentraleTraitée = 0 'Non défini
> > 18 MsgBox "Le Code Centrale Traitée n'est pas défini." & C hr$(10) &
> > Chr$(13) & "Veuillez modifier ce paramètre dans la table
> > 'Centrales'.", vbCritical + vbOKOnly, SMT_NOMAPPLICATION
> > 19 GoTo InitCodeCentraleTraitée_Fin
> > 20 End If
> > 21 Fnct = InitVariablesGlobales()
> > 22 InitCodeCentraleTraitée = True
> > 23 CodeCentraleTraitée = frd.Fields("Code_centrale")
> > 24 InitCodeCentraleTraitée_Fin:
> > 25 frd.Close
> > 26 Set frd = Nothing
> > 27 End Function
> > Mon problème se situe en ligne 09.
> > La variable frd est bien initialisée, je l'ai vérifié par des ?
> > frd.fields(1).value dans la fenêtre Exécution de VBA.
> > Or l'objet Err prend la valeur 91 - Variable objet ou variable de blo c
> > With non définie!!!!
> > Si je place un point d'arrêt sur la ligne 09, exécutant le Set, e t que
> > je continue en pas à pas, je n'obtiens pas l'erreur!
> > Si je place mon point d'arrêt sur la ligne 10, soit après l'exé cution
> > du Set, j'obtiens l'erreur.
> > Un Debug.Print Err.Number, Err.Description juste avant le Set donne
> > comme résultat "0".
> > C'est donc bien le Set qui déclenche l'erreur, mais il ne plante pa s.
> > J'ai un comportement similaire dans Excel.
> > Je me suis tourné vers nos amis Excelliens mais je n'ai pas obtenu de
> > réponse expliquant le problème.
> > On Error Resume Next
> > For intL = 3 To 15 Step 3
> > Err.Clear
> > .Cells(RngFind.Row, 33 + intL) = CDbl(Me.Controls ("TbxProPv c1" &
> > Format(CStr(intL), "00"))) <<--- Génère l'erreur
> > If Err.Number <> 0 Then
> > MsgBox "Donnée incorrecte.", vbExclamation + vbOKOnly,
> > ETPP_NomApplication
> > Me.Controls("TbxProPvc1" & Format(CStr(intL),"00")).SetFoc us
> > GoTo Restituer_Fin
> > End If
> > Next intL
> > L'interception d'erreur n'est la que au cas où!
> > En effet, sans le On Error Resume Next, le code se déroule sans
> > problème, du fait que je réalise le maximum de vérification en amont.
> > Pas de plantage et cependant, l'objet Err prend la valeur 9 - L'indic e
> > n'appartient pas à la sélection.
> > Ma question: Pourquoi le code ne plante alors que l'objet Err restitu e
> > un code erreur?
> > Si vous avez des idées je suis preneur.
> > D'avance merci et bon code.
> > Cordialement.- Masquer le texte des messages précédents -
> - Afficher le texte des messages précédents -
Bonjour,
Je n'ai pas l'environnement pour tester ta procédure, mais c'est
toujours une bonne idée d'être précis lorsqu'il s'agit de déclare r
les variables
Je modifierais volontiers ceci
Dim frd As Recordset
Pour
Dim frd As Dao.Recordset
Juste pour éviter une méprise possible si tu as aussi dans ton projet
la bibliothèque ADO de déclarer.
"ElXav" a écrit dans le message de groupe de discussion :
Bonjour Daniel,
Ooops, je n'ai pas posté dans le bon forum.
J'ai déjà posé la question ici, concernant la partie Excel, et oui,
tout le code Excel est bon, les textbox cible existent.
http://groups.google.com/group/microsoft.public.fr.excel/browse_threa...
A tel point, comme je l'explique, en retirant l'interception d'erreur,
le code ne plante pas, et l'objet Err prend la valeur indiquée dans
mon post.
Si tu as des idées...
Merci.
Cordialement.
On 8 avr, 16:08, Daniel.C wrote:
> Bonjour.
> Es-tu sûr d'avoir un textbox nommé TbxProPvc115 ?
> Daniel
> > Bonjour la Communauté,
> > Migré depuis peu de Office XP vers Office 2007 SP2, j'ai quelques
> > soucis avec mes applis Access et Excel.
> > Celles-ci fonctionnent trés bien sous XP, mais sous 2007, j'obtiens
> > des codes erreur dans l'objet Err, alors que le code ne se plante pas
> > même en désactivant le contrôle d'erreur!!
> > Or donc, le code listé ci-dessous est là pour:
> > - Créer un RecordSet basé sur le contenu d'une table attach ée
> > contenant un seul enregistrement.
> > Cette table attachée peut ne plus être valide, ce qui est normal
> > dans le cadre de l'exploitation de cette base.
> > Donc
> > - Si la création du RecordSet génère une erreur, il est pro bable que
> > la table attachée ne soit plus valide (lien rompu), dans ce cas,
> > j'alerte l'utilisateur et le dirige vers un formulaire permettant de
> > rétablir tous les liens de la base de données
> > - Si la création du RecordSet ne génère pas d'erreur, je tr aite
> > l'enregistrement.
> > D'où le code suivant.
> > 01 Function InitCodeCentraleTraitée() As Boolean
> > 02 ' Initialiser le Code Centrale exécutant l'application
> > 03 ' Initialiser les variables globales
> > 04 Dim frd As Recordset
> > 05 Dim Fnct As Boolean
> > 06 InitCodeCentraleTraitée = False
> > 07 On Error Resume Next
> > 08 Err.Clear
> > 09 Set frd = CurrentDb.OpenRecordset("SELECT * FROM Centrales WH ERE
> > [Centrale traitée] = True", dbOpenSnapshot)
> > 10 If Err <> 0 Then
> > 11 MsgBox "Impossible de trouver la table 'Centrales'. L'attac he de
> > table est certainement incorrecte." & Chr$(10) & Chr$(13) &
> > Err.Description, vbCritical + vbOKOnly, SMT_NOMAPPLICATION
> > 12 DoCmd.OpenForm "Menu Attacher Tables", acNormal, , , ,
> > acWindowNormal
> > 13 GoTo InitCodeCentraleTraitée_Fin
> > 14 End If
> > 15 On Error GoTo 0
> > 16 If frd.BOF Then
> > 17 CodeCentraleTraitée = 0 'Non défini
> > 18 MsgBox "Le Code Centrale Traitée n'est pas défini." & C hr$(10) &
> > Chr$(13) & "Veuillez modifier ce paramètre dans la table
> > 'Centrales'.", vbCritical + vbOKOnly, SMT_NOMAPPLICATION
> > 19 GoTo InitCodeCentraleTraitée_Fin
> > 20 End If
> > 21 Fnct = InitVariablesGlobales()
> > 22 InitCodeCentraleTraitée = True
> > 23 CodeCentraleTraitée = frd.Fields("Code_centrale")
> > 24 InitCodeCentraleTraitée_Fin:
> > 25 frd.Close
> > 26 Set frd = Nothing
> > 27 End Function
> > Mon problème se situe en ligne 09.
> > La variable frd est bien initialisée, je l'ai vérifié par des ?
> > frd.fields(1).value dans la fenêtre Exécution de VBA.
> > Or l'objet Err prend la valeur 91 - Variable objet ou variable de blo c
> > With non définie!!!!
> > Si je place un point d'arrêt sur la ligne 09, exécutant le Set, e t que
> > je continue en pas à pas, je n'obtiens pas l'erreur!
> > Si je place mon point d'arrêt sur la ligne 10, soit après l'exé cution
> > du Set, j'obtiens l'erreur.
> > Un Debug.Print Err.Number, Err.Description juste avant le Set donne
> > comme résultat "0".
> > C'est donc bien le Set qui déclenche l'erreur, mais il ne plante pa s.
> > J'ai un comportement similaire dans Excel.
> > Je me suis tourné vers nos amis Excelliens mais je n'ai pas obtenu de
> > réponse expliquant le problème.
> > On Error Resume Next
> > For intL = 3 To 15 Step 3
> > Err.Clear
> > .Cells(RngFind.Row, 33 + intL) = CDbl(Me.Controls ("TbxProPv c1" &
> > Format(CStr(intL), "00"))) <<--- Génère l'erreur
> > If Err.Number <> 0 Then
> > MsgBox "Donnée incorrecte.", vbExclamation + vbOKOnly,
> > ETPP_NomApplication
> > Me.Controls("TbxProPvc1" & Format(CStr(intL),"00")).SetFoc us
> > GoTo Restituer_Fin
> > End If
> > Next intL
> > L'interception d'erreur n'est la que au cas où!
> > En effet, sans le On Error Resume Next, le code se déroule sans
> > problème, du fait que je réalise le maximum de vérification en amont.
> > Pas de plantage et cependant, l'objet Err prend la valeur 9 - L'indic e
> > n'appartient pas à la sélection.
> > Ma question: Pourquoi le code ne plante alors que l'objet Err restitu e
> > un code erreur?
> > Si vous avez des idées je suis preneur.
> > D'avance merci et bon code.
> > Cordialement.- Masquer le texte des messages précédents -
> - Afficher le texte des messages précédents -
Bonjour,
Tout à fait d'accord avec michdenis, il vaut mieux préfixer ce type d e
variable (recordset) par le nom de la bibliothèque.
Sinon, il faut vérifier que toutes les bibliothèques du projet soient
présentes, aussi bien en Excel qu'en Access.
Dans Excel : Outils / Références.
Si un objet est marqué comme MANQUANT, il faut le décocher.
D'autre part, il se peut que la bibliothèque des objets de
l'application ne soit pas présente (DAO ou Microsoft Office xxx), il
faut alors la rajouter.
Bonne suite.
On 8 avr, 19:42, "michdenis" wrote:
> Bonjour,
> Je n'ai pas l'environnement pour tester ta procédure, mais c'est
> toujours une bonne idée d'être précis lorsqu'il s'agit de décla rer
> les variables
> Je modifierais volontiers ceci
> Dim frd As Recordset
> Pour
> Dim frd As Dao.Recordset
> Juste pour éviter une méprise possible si tu as aussi dans ton proj et
> la bibliothèque ADO de déclarer.
> "ElXav" a écrit dans le message de groupe de discussi on :
>
> Bonjour Daniel,
> Ooops, je n'ai pas posté dans le bon forum.
> J'ai déjà posé la question ici, concernant la partie Excel, et ou i,
> tout le code Excel est bon, les textbox cible existent.
>http://groups.google.com/group/microsoft.public.fr.excel/browse_threa...
> A tel point, comme je l'explique, en retirant l'interception d'erreur,
> le code ne plante pas, et l'objet Err prend la valeur indiquée dans
> mon post.
> Si tu as des idées...
> Merci.
> Cordialement.
> On 8 avr, 16:08, Daniel.C wrote:
> > Bonjour.
> > Es-tu sûr d'avoir un textbox nommé TbxProPvc115 ?
> > Daniel
> > > Bonjour la Communauté,
> > > Migré depuis peu de Office XP vers Office 2007 SP2, j'ai quelques
> > > soucis avec mes applis Access et Excel.
> > > Celles-ci fonctionnent trés bien sous XP, mais sous 2007, j'obtie ns
> > > des codes erreur dans l'objet Err, alors que le code ne se plante p as
> > > même en désactivant le contrôle d'erreur!!
> > > Or donc, le code listé ci-dessous est là pour:
> > > - Créer un RecordSet basé sur le contenu d'une table attach ée
> > > contenant un seul enregistrement.
> > > Cette table attachée peut ne plus être valide, ce qui e st normal
> > > dans le cadre de l'exploitation de cette base.
> > > Donc
> > > - Si la création du RecordSet génère une erreur, il est p robable que
> > > la table attachée ne soit plus valide (lien rompu), dans ce cas,
> > > j'alerte l'utilisateur et le dirige vers un formulaire permettant d e
> > > rétablir tous les liens de la base de données
> > > - Si la création du RecordSet ne génère pas d'erreur, je traite
> > > l'enregistrement.
> > > D'où le code suivant.
> > > 01 Function InitCodeCentraleTraitée() As Boolean
> > > 02 ' Initialiser le Code Centrale exécutant l'application
> > > 03 ' Initialiser les variables globales
> > > 04 Dim frd As Recordset
> > > 05 Dim Fnct As Boolean
> > > 06 InitCodeCentraleTraitée = False
> > > 07 On Error Resume Next
> > > 08 Err.Clear
> > > 09 Set frd = CurrentDb.OpenRecordset("SELECT * FROM Centrales WHERE
> > > [Centrale traitée] = True", dbOpenSnapshot)
> > > 10 If Err <> 0 Then
> > > 11 MsgBox "Impossible de trouver la table 'Centrales'. L'att ache de
> > > table est certainement incorrecte." & Chr$(10) & Chr$(13) &
> > > Err.Description, vbCritical + vbOKOnly, SMT_NOMAPPLICATION
> > > 12 DoCmd.OpenForm "Menu Attacher Tables", acNormal, , , ,
> > > acWindowNormal
> > > 13 GoTo InitCodeCentraleTraitée_Fin
> > > 14 End If
> > > 15 On Error GoTo 0
> > > 16 If frd.BOF Then
> > > 17 CodeCentraleTraitée = 0 'Non défini
> > > 18 MsgBox "Le Code Centrale Traitée n'est pas défini." & Chr$(10) &
> > > Chr$(13) & "Veuillez modifier ce paramètre dans la table
> > > 'Centrales'.", vbCritical + vbOKOnly, SMT_NOMAPPLICATION
> > > 19 GoTo InitCodeCentraleTraitée_Fin
> > > 20 End If
> > > 21 Fnct = InitVariablesGlobales()
> > > 22 InitCodeCentraleTraitée = True
> > > 23 CodeCentraleTraitée = frd.Fields("Code_centrale")
> > > 24 InitCodeCentraleTraitée_Fin:
> > > 25 frd.Close
> > > 26 Set frd = Nothing
> > > 27 End Function
> > > Mon problème se situe en ligne 09.
> > > La variable frd est bien initialisée, je l'ai vérifié par des ?
> > > frd.fields(1).value dans la fenêtre Exécution de VBA.
> > > Or l'objet Err prend la valeur 91 - Variable objet ou variable de b loc
> > > With non définie!!!!
> > > Si je place un point d'arrêt sur la ligne 09, exécutant le Set, et que
> > > je continue en pas à pas, je n'obtiens pas l'erreur!
> > > Si je place mon point d'arrêt sur la ligne 10, soit après l'ex écution
> > > du Set, j'obtiens l'erreur.
> > > Un Debug.Print Err.Number, Err.Description juste avant le Set donne
> > > comme résultat "0".
> > > C'est donc bien le Set qui déclenche l'erreur, mais il ne plante pas.
> > > J'ai un comportement similaire dans Excel.
> > > Je me suis tourné vers nos amis Excelliens mais je n'ai pas obten u de
> > > réponse expliquant le problème.
> > > On Error Resume Next
> > > For intL = 3 To 15 Step 3
> > > Err.Clear
> > > .Cells(RngFind.Row, 33 + intL) = CDbl(Me.Controls ("TbxPro Pvc1" &
> > > Format(CStr(intL), "00"))) <<--- Génère l'erreur
> > > If Err.Number <> 0 Then
> > > MsgBox "Donnée incorrecte.", vbExclamation + vbOKOnly,
> > > ETPP_NomApplication
> > > Me.Controls("TbxProPvc1" & Format(CStr(intL),"00")).SetF ocus
> > > GoTo Restituer_Fin
> > > End If
> > > Next intL
> > > L'interception d'erreur n'est la que au cas où!
> > > En effet, sans le On Error Resume Next, le code se déroule sans
> > > problème, du fait que je réalise le maximum de vérification e n amont.
> > > Pas de plantage et cependant, l'objet Err prend la valeur 9 - L'ind ice
> > > n'appartient pas à la sélection.
> > > Ma question: Pourquoi le code ne plante alors que l'objet Err resti tue
> > > un code erreur?
> > > Si vous avez des idées je suis preneur.
> > > D'avance merci et bon code.
> > > Cordialement.- Masquer le texte des messages précédents -
> > - Afficher le texte des messages précédents -- Masquer le texte d es messages précédents -
- Afficher le texte des messages précédents -
Bonjour,
Tout à fait d'accord avec michdenis, il vaut mieux préfixer ce type d e
variable (recordset) par le nom de la bibliothèque.
Sinon, il faut vérifier que toutes les bibliothèques du projet soient
présentes, aussi bien en Excel qu'en Access.
Dans Excel : Outils / Références.
Si un objet est marqué comme MANQUANT, il faut le décocher.
D'autre part, il se peut que la bibliothèque des objets de
l'application ne soit pas présente (DAO ou Microsoft Office xxx), il
faut alors la rajouter.
Bonne suite.
On 8 avr, 19:42, "michdenis" <michde...@hotmail.com> wrote:
> Bonjour,
> Je n'ai pas l'environnement pour tester ta procédure, mais c'est
> toujours une bonne idée d'être précis lorsqu'il s'agit de décla rer
> les variables
> Je modifierais volontiers ceci
> Dim frd As Recordset
> Pour
> Dim frd As Dao.Recordset
> Juste pour éviter une méprise possible si tu as aussi dans ton proj et
> la bibliothèque ADO de déclarer.
> "ElXav" <el...@free.fr> a écrit dans le message de groupe de discussi on :
> 839c29df-5594-4d03-9db4-6522e1dc8...@e7g2000yqf.googlegroups.com...
> Bonjour Daniel,
> Ooops, je n'ai pas posté dans le bon forum.
> J'ai déjà posé la question ici, concernant la partie Excel, et ou i,
> tout le code Excel est bon, les textbox cible existent.
>http://groups.google.com/group/microsoft.public.fr.excel/browse_threa...
> A tel point, comme je l'explique, en retirant l'interception d'erreur,
> le code ne plante pas, et l'objet Err prend la valeur indiquée dans
> mon post.
> Si tu as des idées...
> Merci.
> Cordialement.
> On 8 avr, 16:08, Daniel.C <dcolardelle...@gmail.com> wrote:
> > Bonjour.
> > Es-tu sûr d'avoir un textbox nommé TbxProPvc115 ?
> > Daniel
> > > Bonjour la Communauté,
> > > Migré depuis peu de Office XP vers Office 2007 SP2, j'ai quelques
> > > soucis avec mes applis Access et Excel.
> > > Celles-ci fonctionnent trés bien sous XP, mais sous 2007, j'obtie ns
> > > des codes erreur dans l'objet Err, alors que le code ne se plante p as
> > > même en désactivant le contrôle d'erreur!!
> > > Or donc, le code listé ci-dessous est là pour:
> > > - Créer un RecordSet basé sur le contenu d'une table attach ée
> > > contenant un seul enregistrement.
> > > Cette table attachée peut ne plus être valide, ce qui e st normal
> > > dans le cadre de l'exploitation de cette base.
> > > Donc
> > > - Si la création du RecordSet génère une erreur, il est p robable que
> > > la table attachée ne soit plus valide (lien rompu), dans ce cas,
> > > j'alerte l'utilisateur et le dirige vers un formulaire permettant d e
> > > rétablir tous les liens de la base de données
> > > - Si la création du RecordSet ne génère pas d'erreur, je traite
> > > l'enregistrement.
> > > D'où le code suivant.
> > > 01 Function InitCodeCentraleTraitée() As Boolean
> > > 02 ' Initialiser le Code Centrale exécutant l'application
> > > 03 ' Initialiser les variables globales
> > > 04 Dim frd As Recordset
> > > 05 Dim Fnct As Boolean
> > > 06 InitCodeCentraleTraitée = False
> > > 07 On Error Resume Next
> > > 08 Err.Clear
> > > 09 Set frd = CurrentDb.OpenRecordset("SELECT * FROM Centrales WHERE
> > > [Centrale traitée] = True", dbOpenSnapshot)
> > > 10 If Err <> 0 Then
> > > 11 MsgBox "Impossible de trouver la table 'Centrales'. L'att ache de
> > > table est certainement incorrecte." & Chr$(10) & Chr$(13) &
> > > Err.Description, vbCritical + vbOKOnly, SMT_NOMAPPLICATION
> > > 12 DoCmd.OpenForm "Menu Attacher Tables", acNormal, , , ,
> > > acWindowNormal
> > > 13 GoTo InitCodeCentraleTraitée_Fin
> > > 14 End If
> > > 15 On Error GoTo 0
> > > 16 If frd.BOF Then
> > > 17 CodeCentraleTraitée = 0 'Non défini
> > > 18 MsgBox "Le Code Centrale Traitée n'est pas défini." & Chr$(10) &
> > > Chr$(13) & "Veuillez modifier ce paramètre dans la table
> > > 'Centrales'.", vbCritical + vbOKOnly, SMT_NOMAPPLICATION
> > > 19 GoTo InitCodeCentraleTraitée_Fin
> > > 20 End If
> > > 21 Fnct = InitVariablesGlobales()
> > > 22 InitCodeCentraleTraitée = True
> > > 23 CodeCentraleTraitée = frd.Fields("Code_centrale")
> > > 24 InitCodeCentraleTraitée_Fin:
> > > 25 frd.Close
> > > 26 Set frd = Nothing
> > > 27 End Function
> > > Mon problème se situe en ligne 09.
> > > La variable frd est bien initialisée, je l'ai vérifié par des ?
> > > frd.fields(1).value dans la fenêtre Exécution de VBA.
> > > Or l'objet Err prend la valeur 91 - Variable objet ou variable de b loc
> > > With non définie!!!!
> > > Si je place un point d'arrêt sur la ligne 09, exécutant le Set, et que
> > > je continue en pas à pas, je n'obtiens pas l'erreur!
> > > Si je place mon point d'arrêt sur la ligne 10, soit après l'ex écution
> > > du Set, j'obtiens l'erreur.
> > > Un Debug.Print Err.Number, Err.Description juste avant le Set donne
> > > comme résultat "0".
> > > C'est donc bien le Set qui déclenche l'erreur, mais il ne plante pas.
> > > J'ai un comportement similaire dans Excel.
> > > Je me suis tourné vers nos amis Excelliens mais je n'ai pas obten u de
> > > réponse expliquant le problème.
> > > On Error Resume Next
> > > For intL = 3 To 15 Step 3
> > > Err.Clear
> > > .Cells(RngFind.Row, 33 + intL) = CDbl(Me.Controls ("TbxPro Pvc1" &
> > > Format(CStr(intL), "00"))) <<--- Génère l'erreur
> > > If Err.Number <> 0 Then
> > > MsgBox "Donnée incorrecte.", vbExclamation + vbOKOnly,
> > > ETPP_NomApplication
> > > Me.Controls("TbxProPvc1" & Format(CStr(intL),"00")).SetF ocus
> > > GoTo Restituer_Fin
> > > End If
> > > Next intL
> > > L'interception d'erreur n'est la que au cas où!
> > > En effet, sans le On Error Resume Next, le code se déroule sans
> > > problème, du fait que je réalise le maximum de vérification e n amont.
> > > Pas de plantage et cependant, l'objet Err prend la valeur 9 - L'ind ice
> > > n'appartient pas à la sélection.
> > > Ma question: Pourquoi le code ne plante alors que l'objet Err resti tue
> > > un code erreur?
> > > Si vous avez des idées je suis preneur.
> > > D'avance merci et bon code.
> > > Cordialement.- Masquer le texte des messages précédents -
> > - Afficher le texte des messages précédents -- Masquer le texte d es messages précédents -
- Afficher le texte des messages précédents -
Bonjour,
Tout à fait d'accord avec michdenis, il vaut mieux préfixer ce type d e
variable (recordset) par le nom de la bibliothèque.
Sinon, il faut vérifier que toutes les bibliothèques du projet soient
présentes, aussi bien en Excel qu'en Access.
Dans Excel : Outils / Références.
Si un objet est marqué comme MANQUANT, il faut le décocher.
D'autre part, il se peut que la bibliothèque des objets de
l'application ne soit pas présente (DAO ou Microsoft Office xxx), il
faut alors la rajouter.
Bonne suite.
On 8 avr, 19:42, "michdenis" wrote:
> Bonjour,
> Je n'ai pas l'environnement pour tester ta procédure, mais c'est
> toujours une bonne idée d'être précis lorsqu'il s'agit de décla rer
> les variables
> Je modifierais volontiers ceci
> Dim frd As Recordset
> Pour
> Dim frd As Dao.Recordset
> Juste pour éviter une méprise possible si tu as aussi dans ton proj et
> la bibliothèque ADO de déclarer.
> "ElXav" a écrit dans le message de groupe de discussi on :
>
> Bonjour Daniel,
> Ooops, je n'ai pas posté dans le bon forum.
> J'ai déjà posé la question ici, concernant la partie Excel, et ou i,
> tout le code Excel est bon, les textbox cible existent.
>http://groups.google.com/group/microsoft.public.fr.excel/browse_threa...
> A tel point, comme je l'explique, en retirant l'interception d'erreur,
> le code ne plante pas, et l'objet Err prend la valeur indiquée dans
> mon post.
> Si tu as des idées...
> Merci.
> Cordialement.
> On 8 avr, 16:08, Daniel.C wrote:
> > Bonjour.
> > Es-tu sûr d'avoir un textbox nommé TbxProPvc115 ?
> > Daniel
> > > Bonjour la Communauté,
> > > Migré depuis peu de Office XP vers Office 2007 SP2, j'ai quelques
> > > soucis avec mes applis Access et Excel.
> > > Celles-ci fonctionnent trés bien sous XP, mais sous 2007, j'obtie ns
> > > des codes erreur dans l'objet Err, alors que le code ne se plante p as
> > > même en désactivant le contrôle d'erreur!!
> > > Or donc, le code listé ci-dessous est là pour:
> > > - Créer un RecordSet basé sur le contenu d'une table attach ée
> > > contenant un seul enregistrement.
> > > Cette table attachée peut ne plus être valide, ce qui e st normal
> > > dans le cadre de l'exploitation de cette base.
> > > Donc
> > > - Si la création du RecordSet génère une erreur, il est p robable que
> > > la table attachée ne soit plus valide (lien rompu), dans ce cas,
> > > j'alerte l'utilisateur et le dirige vers un formulaire permettant d e
> > > rétablir tous les liens de la base de données
> > > - Si la création du RecordSet ne génère pas d'erreur, je traite
> > > l'enregistrement.
> > > D'où le code suivant.
> > > 01 Function InitCodeCentraleTraitée() As Boolean
> > > 02 ' Initialiser le Code Centrale exécutant l'application
> > > 03 ' Initialiser les variables globales
> > > 04 Dim frd As Recordset
> > > 05 Dim Fnct As Boolean
> > > 06 InitCodeCentraleTraitée = False
> > > 07 On Error Resume Next
> > > 08 Err.Clear
> > > 09 Set frd = CurrentDb.OpenRecordset("SELECT * FROM Centrales WHERE
> > > [Centrale traitée] = True", dbOpenSnapshot)
> > > 10 If Err <> 0 Then
> > > 11 MsgBox "Impossible de trouver la table 'Centrales'. L'att ache de
> > > table est certainement incorrecte." & Chr$(10) & Chr$(13) &
> > > Err.Description, vbCritical + vbOKOnly, SMT_NOMAPPLICATION
> > > 12 DoCmd.OpenForm "Menu Attacher Tables", acNormal, , , ,
> > > acWindowNormal
> > > 13 GoTo InitCodeCentraleTraitée_Fin
> > > 14 End If
> > > 15 On Error GoTo 0
> > > 16 If frd.BOF Then
> > > 17 CodeCentraleTraitée = 0 'Non défini
> > > 18 MsgBox "Le Code Centrale Traitée n'est pas défini." & Chr$(10) &
> > > Chr$(13) & "Veuillez modifier ce paramètre dans la table
> > > 'Centrales'.", vbCritical + vbOKOnly, SMT_NOMAPPLICATION
> > > 19 GoTo InitCodeCentraleTraitée_Fin
> > > 20 End If
> > > 21 Fnct = InitVariablesGlobales()
> > > 22 InitCodeCentraleTraitée = True
> > > 23 CodeCentraleTraitée = frd.Fields("Code_centrale")
> > > 24 InitCodeCentraleTraitée_Fin:
> > > 25 frd.Close
> > > 26 Set frd = Nothing
> > > 27 End Function
> > > Mon problème se situe en ligne 09.
> > > La variable frd est bien initialisée, je l'ai vérifié par des ?
> > > frd.fields(1).value dans la fenêtre Exécution de VBA.
> > > Or l'objet Err prend la valeur 91 - Variable objet ou variable de b loc
> > > With non définie!!!!
> > > Si je place un point d'arrêt sur la ligne 09, exécutant le Set, et que
> > > je continue en pas à pas, je n'obtiens pas l'erreur!
> > > Si je place mon point d'arrêt sur la ligne 10, soit après l'ex écution
> > > du Set, j'obtiens l'erreur.
> > > Un Debug.Print Err.Number, Err.Description juste avant le Set donne
> > > comme résultat "0".
> > > C'est donc bien le Set qui déclenche l'erreur, mais il ne plante pas.
> > > J'ai un comportement similaire dans Excel.
> > > Je me suis tourné vers nos amis Excelliens mais je n'ai pas obten u de
> > > réponse expliquant le problème.
> > > On Error Resume Next
> > > For intL = 3 To 15 Step 3
> > > Err.Clear
> > > .Cells(RngFind.Row, 33 + intL) = CDbl(Me.Controls ("TbxPro Pvc1" &
> > > Format(CStr(intL), "00"))) <<--- Génère l'erreur
> > > If Err.Number <> 0 Then
> > > MsgBox "Donnée incorrecte.", vbExclamation + vbOKOnly,
> > > ETPP_NomApplication
> > > Me.Controls("TbxProPvc1" & Format(CStr(intL),"00")).SetF ocus
> > > GoTo Restituer_Fin
> > > End If
> > > Next intL
> > > L'interception d'erreur n'est la que au cas où!
> > > En effet, sans le On Error Resume Next, le code se déroule sans
> > > problème, du fait que je réalise le maximum de vérification e n amont.
> > > Pas de plantage et cependant, l'objet Err prend la valeur 9 - L'ind ice
> > > n'appartient pas à la sélection.
> > > Ma question: Pourquoi le code ne plante alors que l'objet Err resti tue
> > > un code erreur?
> > > Si vous avez des idées je suis preneur.
> > > D'avance merci et bon code.
> > > Cordialement.- Masquer le texte des messages précédents -
> > - Afficher le texte des messages précédents -- Masquer le texte d es messages précédents -
- Afficher le texte des messages précédents -
Bonjour,
Tout à fait d'accord avec michdenis, il vaut mieux préfixer ce type de
variable (recordset) par le nom de la bibliothèque.
Sinon, il faut vérifier que toutes les bibliothèques du projet soient
présentes, aussi bien en Excel qu'en Access.
Dans Excel : Outils / Références.
Si un objet est marqué comme MANQUANT, il faut le décocher.
D'autre part, il se peut que la bibliothèque des objets de
l'application ne soit pas présente (DAO ou Microsoft Office xxx), il
faut alors la rajouter.
Bonne suite.
On 8 avr, 19:42, "michdenis" wrote:
> Bonjour,
> Je n'ai pas l'environnement pour tester ta procédure, mais c'est
> toujours une bonne idée d'être précis lorsqu'il s'agit de déclarer
> les variables
> Je modifierais volontiers ceci
> Dim frd As Recordset
> Pour
> Dim frd As Dao.Recordset
> Juste pour éviter une méprise possible si tu as aussi dans ton projet
> la bibliothèque ADO de déclarer.
> "ElXav" a écrit dans le message de groupe de discussion :
>
> Bonjour Daniel,
> Ooops, je n'ai pas posté dans le bon forum.
> J'ai déjà posé la question ici, concernant la partie Excel, et oui,
> tout le code Excel est bon, les textbox cible existent.
>http://groups.google.com/group/microsoft.public.fr.excel/browse_threa...
> A tel point, comme je l'explique, en retirant l'interception d'erreur,
> le code ne plante pas, et l'objet Err prend la valeur indiquée dans
> mon post.
> Si tu as des idées...
> Merci.
> Cordialement.
> On 8 avr, 16:08, Daniel.C wrote:
> > Bonjour.
> > Es-tu sûr d'avoir un textbox nommé TbxProPvc115 ?
> > Daniel
> > > Bonjour la Communauté,
> > > Migré depuis peu de Office XP vers Office 2007 SP2, j'ai quelques
> > > soucis avec mes applis Access et Excel.
> > > Celles-ci fonctionnent trés bien sous XP, mais sous 2007, j'obtiens
> > > des codes erreur dans l'objet Err, alors que le code ne se plante pas
> > > même en désactivant le contrôle d'erreur!!
> > > Or donc, le code listé ci-dessous est là pour:
> > > - Créer un RecordSet basé sur le contenu d'une table attachée
> > > contenant un seul enregistrement.
> > > Cette table attachée peut ne plus être valide, ce qui est normal
> > > dans le cadre de l'exploitation de cette base.
> > > Donc
> > > - Si la création du RecordSet génère une erreur, il est probable que
> > > la table attachée ne soit plus valide (lien rompu), dans ce cas,
> > > j'alerte l'utilisateur et le dirige vers un formulaire permettant de
> > > rétablir tous les liens de la base de données
> > > - Si la création du RecordSet ne génère pas d'erreur, je traite
> > > l'enregistrement.
> > > D'où le code suivant.
> > > 01 Function InitCodeCentraleTraitée() As Boolean
> > > 02 ' Initialiser le Code Centrale exécutant l'application
> > > 03 ' Initialiser les variables globales
> > > 04 Dim frd As Recordset
> > > 05 Dim Fnct As Boolean
> > > 06 InitCodeCentraleTraitée = False
> > > 07 On Error Resume Next
> > > 08 Err.Clear
> > > 09 Set frd = CurrentDb.OpenRecordset("SELECT * FROM Centrales WHERE
> > > [Centrale traitée] = True", dbOpenSnapshot)
> > > 10 If Err <> 0 Then
> > > 11 MsgBox "Impossible de trouver la table 'Centrales'. L'attache de
> > > table est certainement incorrecte." & Chr$(10) & Chr$(13) &
> > > Err.Description, vbCritical + vbOKOnly, SMT_NOMAPPLICATION
> > > 12 DoCmd.OpenForm "Menu Attacher Tables", acNormal, , , ,
> > > acWindowNormal
> > > 13 GoTo InitCodeCentraleTraitée_Fin
> > > 14 End If
> > > 15 On Error GoTo 0
> > > 16 If frd.BOF Then
> > > 17 CodeCentraleTraitée = 0 'Non défini
> > > 18 MsgBox "Le Code Centrale Traitée n'est pas défini." & Chr$(10) &
> > > Chr$(13) & "Veuillez modifier ce paramètre dans la table
> > > 'Centrales'.", vbCritical + vbOKOnly, SMT_NOMAPPLICATION
> > > 19 GoTo InitCodeCentraleTraitée_Fin
> > > 20 End If
> > > 21 Fnct = InitVariablesGlobales()
> > > 22 InitCodeCentraleTraitée = True
> > > 23 CodeCentraleTraitée = frd.Fields("Code_centrale")
> > > 24 InitCodeCentraleTraitée_Fin:
> > > 25 frd.Close
> > > 26 Set frd = Nothing
> > > 27 End Function
> > > Mon problème se situe en ligne 09.
> > > La variable frd est bien initialisée, je l'ai vérifié par des ?
> > > frd.fields(1).value dans la fenêtre Exécution de VBA.
> > > Or l'objet Err prend la valeur 91 - Variable objet ou variable de bloc
> > > With non définie!!!!
> > > Si je place un point d'arrêt sur la ligne 09, exécutant le Set, et que
> > > je continue en pas à pas, je n'obtiens pas l'erreur!
> > > Si je place mon point d'arrêt sur la ligne 10, soit après l'exécution
> > > du Set, j'obtiens l'erreur.
> > > Un Debug.Print Err.Number, Err.Description juste avant le Set donne
> > > comme résultat "0".
> > > C'est donc bien le Set qui déclenche l'erreur, mais il ne plante pas.
> > > J'ai un comportement similaire dans Excel.
> > > Je me suis tourné vers nos amis Excelliens mais je n'ai pas obtenu de
> > > réponse expliquant le problème.
> > > On Error Resume Next
> > > For intL = 3 To 15 Step 3
> > > Err.Clear
> > > .Cells(RngFind.Row, 33 + intL) = CDbl(Me.Controls ("TbxProPvc1" &
> > > Format(CStr(intL), "00"))) <<--- Génère l'erreur
> > > If Err.Number <> 0 Then
> > > MsgBox "Donnée incorrecte.", vbExclamation + vbOKOnly,
> > > ETPP_NomApplication
> > > Me.Controls("TbxProPvc1" & Format(CStr(intL),"00")).SetFocus
> > > GoTo Restituer_Fin
> > > End If
> > > Next intL
> > > L'interception d'erreur n'est la que au cas où!
> > > En effet, sans le On Error Resume Next, le code se déroule sans
> > > problème, du fait que je réalise le maximum de vérification en amont.
> > > Pas de plantage et cependant, l'objet Err prend la valeur 9 - L'indice
> > > n'appartient pas à la sélection.
> > > Ma question: Pourquoi le code ne plante alors que l'objet Err restitue
> > > un code erreur?
> > > Si vous avez des idées je suis preneur.
> > > D'avance merci et bon code.
> > > Cordialement.- Masquer le texte des messages précédents -
> > - Afficher le texte des messages précédents -- Masquer le texte des messages
> > précédents -
- Afficher le texte des messages précédents -
Bonjour,
Tout à fait d'accord avec michdenis, il vaut mieux préfixer ce type de
variable (recordset) par le nom de la bibliothèque.
Sinon, il faut vérifier que toutes les bibliothèques du projet soient
présentes, aussi bien en Excel qu'en Access.
Dans Excel : Outils / Références.
Si un objet est marqué comme MANQUANT, il faut le décocher.
D'autre part, il se peut que la bibliothèque des objets de
l'application ne soit pas présente (DAO ou Microsoft Office xxx), il
faut alors la rajouter.
Bonne suite.
On 8 avr, 19:42, "michdenis" <michde...@hotmail.com> wrote:
> Bonjour,
> Je n'ai pas l'environnement pour tester ta procédure, mais c'est
> toujours une bonne idée d'être précis lorsqu'il s'agit de déclarer
> les variables
> Je modifierais volontiers ceci
> Dim frd As Recordset
> Pour
> Dim frd As Dao.Recordset
> Juste pour éviter une méprise possible si tu as aussi dans ton projet
> la bibliothèque ADO de déclarer.
> "ElXav" <el...@free.fr> a écrit dans le message de groupe de discussion :
> 839c29df-5594-4d03-9db4-6522e1dc8...@e7g2000yqf.googlegroups.com...
> Bonjour Daniel,
> Ooops, je n'ai pas posté dans le bon forum.
> J'ai déjà posé la question ici, concernant la partie Excel, et oui,
> tout le code Excel est bon, les textbox cible existent.
>http://groups.google.com/group/microsoft.public.fr.excel/browse_threa...
> A tel point, comme je l'explique, en retirant l'interception d'erreur,
> le code ne plante pas, et l'objet Err prend la valeur indiquée dans
> mon post.
> Si tu as des idées...
> Merci.
> Cordialement.
> On 8 avr, 16:08, Daniel.C <dcolardelle...@gmail.com> wrote:
> > Bonjour.
> > Es-tu sûr d'avoir un textbox nommé TbxProPvc115 ?
> > Daniel
> > > Bonjour la Communauté,
> > > Migré depuis peu de Office XP vers Office 2007 SP2, j'ai quelques
> > > soucis avec mes applis Access et Excel.
> > > Celles-ci fonctionnent trés bien sous XP, mais sous 2007, j'obtiens
> > > des codes erreur dans l'objet Err, alors que le code ne se plante pas
> > > même en désactivant le contrôle d'erreur!!
> > > Or donc, le code listé ci-dessous est là pour:
> > > - Créer un RecordSet basé sur le contenu d'une table attachée
> > > contenant un seul enregistrement.
> > > Cette table attachée peut ne plus être valide, ce qui est normal
> > > dans le cadre de l'exploitation de cette base.
> > > Donc
> > > - Si la création du RecordSet génère une erreur, il est probable que
> > > la table attachée ne soit plus valide (lien rompu), dans ce cas,
> > > j'alerte l'utilisateur et le dirige vers un formulaire permettant de
> > > rétablir tous les liens de la base de données
> > > - Si la création du RecordSet ne génère pas d'erreur, je traite
> > > l'enregistrement.
> > > D'où le code suivant.
> > > 01 Function InitCodeCentraleTraitée() As Boolean
> > > 02 ' Initialiser le Code Centrale exécutant l'application
> > > 03 ' Initialiser les variables globales
> > > 04 Dim frd As Recordset
> > > 05 Dim Fnct As Boolean
> > > 06 InitCodeCentraleTraitée = False
> > > 07 On Error Resume Next
> > > 08 Err.Clear
> > > 09 Set frd = CurrentDb.OpenRecordset("SELECT * FROM Centrales WHERE
> > > [Centrale traitée] = True", dbOpenSnapshot)
> > > 10 If Err <> 0 Then
> > > 11 MsgBox "Impossible de trouver la table 'Centrales'. L'attache de
> > > table est certainement incorrecte." & Chr$(10) & Chr$(13) &
> > > Err.Description, vbCritical + vbOKOnly, SMT_NOMAPPLICATION
> > > 12 DoCmd.OpenForm "Menu Attacher Tables", acNormal, , , ,
> > > acWindowNormal
> > > 13 GoTo InitCodeCentraleTraitée_Fin
> > > 14 End If
> > > 15 On Error GoTo 0
> > > 16 If frd.BOF Then
> > > 17 CodeCentraleTraitée = 0 'Non défini
> > > 18 MsgBox "Le Code Centrale Traitée n'est pas défini." & Chr$(10) &
> > > Chr$(13) & "Veuillez modifier ce paramètre dans la table
> > > 'Centrales'.", vbCritical + vbOKOnly, SMT_NOMAPPLICATION
> > > 19 GoTo InitCodeCentraleTraitée_Fin
> > > 20 End If
> > > 21 Fnct = InitVariablesGlobales()
> > > 22 InitCodeCentraleTraitée = True
> > > 23 CodeCentraleTraitée = frd.Fields("Code_centrale")
> > > 24 InitCodeCentraleTraitée_Fin:
> > > 25 frd.Close
> > > 26 Set frd = Nothing
> > > 27 End Function
> > > Mon problème se situe en ligne 09.
> > > La variable frd est bien initialisée, je l'ai vérifié par des ?
> > > frd.fields(1).value dans la fenêtre Exécution de VBA.
> > > Or l'objet Err prend la valeur 91 - Variable objet ou variable de bloc
> > > With non définie!!!!
> > > Si je place un point d'arrêt sur la ligne 09, exécutant le Set, et que
> > > je continue en pas à pas, je n'obtiens pas l'erreur!
> > > Si je place mon point d'arrêt sur la ligne 10, soit après l'exécution
> > > du Set, j'obtiens l'erreur.
> > > Un Debug.Print Err.Number, Err.Description juste avant le Set donne
> > > comme résultat "0".
> > > C'est donc bien le Set qui déclenche l'erreur, mais il ne plante pas.
> > > J'ai un comportement similaire dans Excel.
> > > Je me suis tourné vers nos amis Excelliens mais je n'ai pas obtenu de
> > > réponse expliquant le problème.
> > > On Error Resume Next
> > > For intL = 3 To 15 Step 3
> > > Err.Clear
> > > .Cells(RngFind.Row, 33 + intL) = CDbl(Me.Controls ("TbxProPvc1" &
> > > Format(CStr(intL), "00"))) <<--- Génère l'erreur
> > > If Err.Number <> 0 Then
> > > MsgBox "Donnée incorrecte.", vbExclamation + vbOKOnly,
> > > ETPP_NomApplication
> > > Me.Controls("TbxProPvc1" & Format(CStr(intL),"00")).SetFocus
> > > GoTo Restituer_Fin
> > > End If
> > > Next intL
> > > L'interception d'erreur n'est la que au cas où!
> > > En effet, sans le On Error Resume Next, le code se déroule sans
> > > problème, du fait que je réalise le maximum de vérification en amont.
> > > Pas de plantage et cependant, l'objet Err prend la valeur 9 - L'indice
> > > n'appartient pas à la sélection.
> > > Ma question: Pourquoi le code ne plante alors que l'objet Err restitue
> > > un code erreur?
> > > Si vous avez des idées je suis preneur.
> > > D'avance merci et bon code.
> > > Cordialement.- Masquer le texte des messages précédents -
> > - Afficher le texte des messages précédents -- Masquer le texte des messages
> > précédents -
- Afficher le texte des messages précédents -
Bonjour,
Tout à fait d'accord avec michdenis, il vaut mieux préfixer ce type de
variable (recordset) par le nom de la bibliothèque.
Sinon, il faut vérifier que toutes les bibliothèques du projet soient
présentes, aussi bien en Excel qu'en Access.
Dans Excel : Outils / Références.
Si un objet est marqué comme MANQUANT, il faut le décocher.
D'autre part, il se peut que la bibliothèque des objets de
l'application ne soit pas présente (DAO ou Microsoft Office xxx), il
faut alors la rajouter.
Bonne suite.
On 8 avr, 19:42, "michdenis" wrote:
> Bonjour,
> Je n'ai pas l'environnement pour tester ta procédure, mais c'est
> toujours une bonne idée d'être précis lorsqu'il s'agit de déclarer
> les variables
> Je modifierais volontiers ceci
> Dim frd As Recordset
> Pour
> Dim frd As Dao.Recordset
> Juste pour éviter une méprise possible si tu as aussi dans ton projet
> la bibliothèque ADO de déclarer.
> "ElXav" a écrit dans le message de groupe de discussion :
>
> Bonjour Daniel,
> Ooops, je n'ai pas posté dans le bon forum.
> J'ai déjà posé la question ici, concernant la partie Excel, et oui,
> tout le code Excel est bon, les textbox cible existent.
>http://groups.google.com/group/microsoft.public.fr.excel/browse_threa...
> A tel point, comme je l'explique, en retirant l'interception d'erreur,
> le code ne plante pas, et l'objet Err prend la valeur indiquée dans
> mon post.
> Si tu as des idées...
> Merci.
> Cordialement.
> On 8 avr, 16:08, Daniel.C wrote:
> > Bonjour.
> > Es-tu sûr d'avoir un textbox nommé TbxProPvc115 ?
> > Daniel
> > > Bonjour la Communauté,
> > > Migré depuis peu de Office XP vers Office 2007 SP2, j'ai quelques
> > > soucis avec mes applis Access et Excel.
> > > Celles-ci fonctionnent trés bien sous XP, mais sous 2007, j'obtiens
> > > des codes erreur dans l'objet Err, alors que le code ne se plante pas
> > > même en désactivant le contrôle d'erreur!!
> > > Or donc, le code listé ci-dessous est là pour:
> > > - Créer un RecordSet basé sur le contenu d'une table attachée
> > > contenant un seul enregistrement.
> > > Cette table attachée peut ne plus être valide, ce qui est normal
> > > dans le cadre de l'exploitation de cette base.
> > > Donc
> > > - Si la création du RecordSet génère une erreur, il est probable que
> > > la table attachée ne soit plus valide (lien rompu), dans ce cas,
> > > j'alerte l'utilisateur et le dirige vers un formulaire permettant de
> > > rétablir tous les liens de la base de données
> > > - Si la création du RecordSet ne génère pas d'erreur, je traite
> > > l'enregistrement.
> > > D'où le code suivant.
> > > 01 Function InitCodeCentraleTraitée() As Boolean
> > > 02 ' Initialiser le Code Centrale exécutant l'application
> > > 03 ' Initialiser les variables globales
> > > 04 Dim frd As Recordset
> > > 05 Dim Fnct As Boolean
> > > 06 InitCodeCentraleTraitée = False
> > > 07 On Error Resume Next
> > > 08 Err.Clear
> > > 09 Set frd = CurrentDb.OpenRecordset("SELECT * FROM Centrales WHERE
> > > [Centrale traitée] = True", dbOpenSnapshot)
> > > 10 If Err <> 0 Then
> > > 11 MsgBox "Impossible de trouver la table 'Centrales'. L'attache de
> > > table est certainement incorrecte." & Chr$(10) & Chr$(13) &
> > > Err.Description, vbCritical + vbOKOnly, SMT_NOMAPPLICATION
> > > 12 DoCmd.OpenForm "Menu Attacher Tables", acNormal, , , ,
> > > acWindowNormal
> > > 13 GoTo InitCodeCentraleTraitée_Fin
> > > 14 End If
> > > 15 On Error GoTo 0
> > > 16 If frd.BOF Then
> > > 17 CodeCentraleTraitée = 0 'Non défini
> > > 18 MsgBox "Le Code Centrale Traitée n'est pas défini." & Chr$(10) &
> > > Chr$(13) & "Veuillez modifier ce paramètre dans la table
> > > 'Centrales'.", vbCritical + vbOKOnly, SMT_NOMAPPLICATION
> > > 19 GoTo InitCodeCentraleTraitée_Fin
> > > 20 End If
> > > 21 Fnct = InitVariablesGlobales()
> > > 22 InitCodeCentraleTraitée = True
> > > 23 CodeCentraleTraitée = frd.Fields("Code_centrale")
> > > 24 InitCodeCentraleTraitée_Fin:
> > > 25 frd.Close
> > > 26 Set frd = Nothing
> > > 27 End Function
> > > Mon problème se situe en ligne 09.
> > > La variable frd est bien initialisée, je l'ai vérifié par des ?
> > > frd.fields(1).value dans la fenêtre Exécution de VBA.
> > > Or l'objet Err prend la valeur 91 - Variable objet ou variable de bloc
> > > With non définie!!!!
> > > Si je place un point d'arrêt sur la ligne 09, exécutant le Set, et que
> > > je continue en pas à pas, je n'obtiens pas l'erreur!
> > > Si je place mon point d'arrêt sur la ligne 10, soit après l'exécution
> > > du Set, j'obtiens l'erreur.
> > > Un Debug.Print Err.Number, Err.Description juste avant le Set donne
> > > comme résultat "0".
> > > C'est donc bien le Set qui déclenche l'erreur, mais il ne plante pas.
> > > J'ai un comportement similaire dans Excel.
> > > Je me suis tourné vers nos amis Excelliens mais je n'ai pas obtenu de
> > > réponse expliquant le problème.
> > > On Error Resume Next
> > > For intL = 3 To 15 Step 3
> > > Err.Clear
> > > .Cells(RngFind.Row, 33 + intL) = CDbl(Me.Controls ("TbxProPvc1" &
> > > Format(CStr(intL), "00"))) <<--- Génère l'erreur
> > > If Err.Number <> 0 Then
> > > MsgBox "Donnée incorrecte.", vbExclamation + vbOKOnly,
> > > ETPP_NomApplication
> > > Me.Controls("TbxProPvc1" & Format(CStr(intL),"00")).SetFocus
> > > GoTo Restituer_Fin
> > > End If
> > > Next intL
> > > L'interception d'erreur n'est la que au cas où!
> > > En effet, sans le On Error Resume Next, le code se déroule sans
> > > problème, du fait que je réalise le maximum de vérification en amont.
> > > Pas de plantage et cependant, l'objet Err prend la valeur 9 - L'indice
> > > n'appartient pas à la sélection.
> > > Ma question: Pourquoi le code ne plante alors que l'objet Err restitue
> > > un code erreur?
> > > Si vous avez des idées je suis preneur.
> > > D'avance merci et bon code.
> > > Cordialement.- Masquer le texte des messages précédents -
> > - Afficher le texte des messages précédents -- Masquer le texte des messages
> > précédents -
- Afficher le texte des messages précédents -
Si tu veux faire une gestion d'erreur efficace :
'-----------------------------------
Sub MaProcédure()
Dim Gestion_Erreur As String
On Error Goto Gestion_Erreur
Ton code
Exit sub
Gestion_Erreur:
Msgbox Err.Number & ", " & Err.Description
'pour reprendre à la ligne suivante de code où
'l'erreur s'est produite.
Resume next
End Sub
'-----------------------------------
Si tu sais les numéros d'erreur que ta procédure peut provoquer
tu peux faire : (numéro d'erreur pris au hasard.
Gestion_Erreur:
Select case Err.Number
Case 91
'ce que tu veux faire si ça se produit
Case 125
'ce que tu veux faire si ça se produit
Case else
End Select
Il faut utiliser son jugement si on doit ajouter la ligne "Resume next"
Certains types d'erreur peut rendre le cheminement de la macro
impossible ou provoquer un résultat erroné. Il faut mieux afficher
un message et mettre fin à la procédure.
"ElXav" a écrit dans le message de groupe de discussion :
Bonjour Jex, Michdenis,
D'accord avec vous, je m'y astreins depuis un moment déjà.
J'ai pour l'instant 2 problèmes similaires.
L'un dans un classeur Excel développé l'année dernière, l'autre d ans
une base Access qui est passé par les versions 2, 95, 97, et
maintenant 2007.
A chaque migration, il m'aura fallu mettre quelques verrues afin de
contourner divers problèmes.
Pour l'heure, j'aimerais comprendre pourquoi l'objet Err se trouve
affecté par une erreur alors que le code ne plante pas si l'on enlève
l'interception d'erreur.
Pour la partie Access, en pas à pas, depuis le clic qui ferme un
formulaire, et jusqu'à ma fonction, aucune interception d'erreur n'est
activée.
Si je supprime le On Error Resume Next, je n'obtiens pas de plantage,
mon test Err.Number <> 0 est positif avec le code 91, et le recordset
se trouve bien chargé!!
Le tout résolu par un DoEvents en amont de ma fonction...
Dans Excel, j'ai entrepris la même démarche, pas à pas, et je ne pa sse
pas par des procédures évènementiels inopinées.
Sans le On Error, le code se déroule parfaitement bien, le résultat
est correctn et pourtant Err.Number récupère une valeur différente de
zéro.
Comme d'hab, face a ce type de problème, je perds la boule ;-/
Je ne comprends pas pourquoi Err rescense une erreur, surtout une
erreur entrainant normalement l'arrêt du code, alors que celui-ci
fonctionne.
Question subsidiaire afin de valider ou non le fonctionnement du On
Error que j'ai en tête, après une relecture de l'aide en ligne.
Lorsqu'un On Error Goto est exécuté, on est bien d'accord qu'il est
actif le temps que tous le code devant être déroulé le soit?
Soit:
1) Si clic sur un bouton, la procédure évènementielle déma rre.
2) On peut imaginer un ou plusieurs On Error Goto/Resume dans
différentes procédures et fonction appelées.
3) Lorsque la procédure évènementielle liée au clic se ter mine,
tous les On Error Goto/Resume devienne "caduque".
4) Si on lance une nouvelle procédure ou fonction dans laquelle
aucun On Error n'est présent, et qu'une ligne génère une erreur 91 ou
9 (variable / objet non défini, et indice hors limite), le code doit
planter, et Err.Number retourne cette valeur.
Si le 4 est vrai, pourquoi n'ai-j pas ce comportement?? :-/
Merci quand même pour vos conseils.
Si vous entrevoyez une explication...
Cordialement.
Xavier.
On 9 avr, 11:03, Jex wrote:
> Bonjour,
> Tout à fait d'accord avec michdenis, il vaut mieux préfixer ce type de
> variable (recordset) par le nom de la bibliothèque.
> Sinon, il faut vérifier que toutes les bibliothèques du projet soie nt
> présentes, aussi bien en Excel qu'en Access.
> Dans Excel : Outils / Références.
> Si un objet est marqué comme MANQUANT, il faut le décocher.
> D'autre part, il se peut que la bibliothèque des objets de
> l'application ne soit pas présente (DAO ou Microsoft Office xxx), il
> faut alors la rajouter.
> Bonne suite.
> On 8 avr, 19:42, "michdenis" wrote:
> > Bonjour,
> > Je n'ai pas l'environnement pour tester ta procédure, mais c'est
> > toujours une bonne idée d'être précis lorsqu'il s'agit de déc larer
> > les variables
> > Je modifierais volontiers ceci
> > Dim frd As Recordset
> > Pour
> > Dim frd As Dao.Recordset
> > Juste pour éviter une méprise possible si tu as aussi dans ton pr ojet
> > la bibliothèque ADO de déclarer.
> > "ElXav" a écrit dans le message de groupe de discus sion :
> >
> > Bonjour Daniel,
> > Ooops, je n'ai pas posté dans le bon forum.
> > J'ai déjà posé la question ici, concernant la partie Excel, et oui,
> > tout le code Excel est bon, les textbox cible existent.
> >http://groups.google.com/group/microsoft.public.fr.excel/browse_threa. ..
> > A tel point, comme je l'explique, en retirant l'interception d'erreur ,
> > le code ne plante pas, et l'objet Err prend la valeur indiquée dans
> > mon post.
> > Si tu as des idées...
> > Merci.
> > Cordialement.
> > On 8 avr, 16:08, Daniel.C wrote:
> > > Bonjour.
> > > Es-tu sûr d'avoir un textbox nommé TbxProPvc115 ?
> > > Daniel
> > > > Bonjour la Communauté,
> > > > Migré depuis peu de Office XP vers Office 2007 SP2, j'ai quelqu es
> > > > soucis avec mes applis Access et Excel.
> > > > Celles-ci fonctionnent trés bien sous XP, mais sous 2007, j'obt iens
> > > > des codes erreur dans l'objet Err, alors que le code ne se plante pas
> > > > même en désactivant le contrôle d'erreur!!
> > > > Or donc, le code listé ci-dessous est là pour:
> > > > - Créer un RecordSet basé sur le contenu d'une table atta chée
> > > > contenant un seul enregistrement.
> > > > Cette table attachée peut ne plus être valide, ce qui est normal
> > > > dans le cadre de l'exploitation de cette base.
> > > > Donc
> > > > - Si la création du RecordSet génère une erreur, il est probable que
> > > > la table attachée ne soit plus valide (lien rompu), dans ce cas ,
> > > > j'alerte l'utilisateur et le dirige vers un formulaire permettant de
> > > > rétablir tous les liens de la base de données
> > > > - Si la création du RecordSet ne génère pas d'erreur, j e traite
> > > > l'enregistrement.
> > > > D'où le code suivant.
> > > > 01 Function InitCodeCentraleTraitée() As Boolean
> > > > 02 ' Initialiser le Code Centrale exécutant l'application
> > > > 03 ' Initialiser les variables globales
> > > > 04 Dim frd As Recordset
> > > > 05 Dim Fnct As Boolean
> > > > 06 InitCodeCentraleTraitée = False
> > > > 07 On Error Resume Next
> > > > 08 Err.Clear
> > > > 09 Set frd = CurrentDb.OpenRecordset("SELECT * FROM Centrale s WHERE
> > > > [Centrale traitée] = True", dbOpenSnapshot)
> > > > 10 If Err <> 0 Then
> > > > 11 MsgBox "Impossible de trouver la table 'Centrales'. L'a ttache de
> > > > table est certainement incorrecte." & Chr$(10) & Chr$(13) &
> > > > Err.Description, vbCritical + vbOKOnly, SMT_NOMAPPLICATION
> > > > 12 DoCmd.OpenForm "Menu Attacher Tables", acNormal, , , ,
> > > > acWindowNormal
> > > > 13 GoTo InitCodeCentraleTraitée_Fin
> > > > 14 End If
> > > > 15 On Error GoTo 0
> > > > 16 If frd.BOF Then
> > > > 17 CodeCentraleTraitée = 0 'Non défini
> > > > 18 MsgBox "Le Code Centrale Traitée n'est pas défini." & Chr$(10) &
> > > > Chr$(13) & "Veuillez modifier ce paramètre dans la table
> > > > 'Centrales'.", vbCritical + vbOKOnly, SMT_NOMAPPLICATION
> > > > 19 GoTo InitCodeCentraleTraitée_Fin
> > > > 20 End If
> > > > 21 Fnct = InitVariablesGlobales()
> > > > 22 InitCodeCentraleTraitée = True
> > > > 23 CodeCentraleTraitée = frd.Fields("Code_centrale")
> > > > 24 InitCodeCentraleTraitée_Fin:
> > > > 25 frd.Close
> > > > 26 Set frd = Nothing
> > > > 27 End Function
> > > > Mon problème se situe en ligne 09.
> > > > La variable frd est bien initialisée, je l'ai vérifié par d es ?
> > > > frd.fields(1).value dans la fenêtre Exécution de VBA.
> > > > Or l'objet Err prend la valeur 91 - Variable objet ou variable de bloc
> > > > With non définie!!!!
> > > > Si je place un point d'arrêt sur la ligne 09, exécutant le Se t, et que
> > > > je continue en pas à pas, je n'obtiens pas l'erreur!
> > > > Si je place mon point d'arrêt sur la ligne 10, soit après l'e xécution
> > > > du Set, j'obtiens l'erreur.
> > > > Un Debug.Print Err.Number, Err.Description juste avant le Set don ne
> > > > comme résultat "0".
> > > > C'est donc bien le Set qui déclenche l'erreur, mais il ne plant e pas.
> > > > J'ai un comportement similaire dans Excel.
> > > > Je me suis tourné vers nos amis Excelliens mais je n'ai pas obt enu de
> > > > réponse expliquant le problème.
> > > > On Error Resume Next
> > > > For intL = 3 To 15 Step 3
> > > > Err.Clear
> > > > .Cells(RngFind.Row, 33 + intL) = CDbl(Me.Controls ("TbxP roPvc1" &
> > > > Format(CStr(intL), "00"))) <<--- Génère l'erreur
> > > > If Err.Number <> 0 Then
> > > > MsgBox "Donnée incorrecte.", vbExclamation + vbOKOnl y,
> > > > ETPP_NomApplication
> > > > Me.Controls("TbxProPvc1" & Format(CStr(intL),"00")).Se tFocus
> > > > GoTo Restituer_Fin
> > > > End If
> > > > Next intL
> > > > L'interception d'erreur n'est la que au cas où!
> > > > En effet, sans le On Error Resume Next, le code se déroule sans
> > > > problème, du fait que je réalise le maximum de vérification en amont.
> > > > Pas de plantage et cependant, l'objet Err prend la valeur 9 - L'i ndice
> > > > n'appartient pas à la sélection.
> > > > Ma question: Pourquoi le code ne plante alors que l'objet Err res titue
> > > > un code erreur?
> > > > Si vous avez des idées je suis preneur.
> > > > D'avance merci et bon
...
plus de détails »- Masquer le texte des messages précédents -
- Afficher le texte des messages précédents -
Si tu veux faire une gestion d'erreur efficace :
'-----------------------------------
Sub MaProcédure()
Dim Gestion_Erreur As String
On Error Goto Gestion_Erreur
Ton code
Exit sub
Gestion_Erreur:
Msgbox Err.Number & ", " & Err.Description
'pour reprendre à la ligne suivante de code où
'l'erreur s'est produite.
Resume next
End Sub
'-----------------------------------
Si tu sais les numéros d'erreur que ta procédure peut provoquer
tu peux faire : (numéro d'erreur pris au hasard.
Gestion_Erreur:
Select case Err.Number
Case 91
'ce que tu veux faire si ça se produit
Case 125
'ce que tu veux faire si ça se produit
Case else
End Select
Il faut utiliser son jugement si on doit ajouter la ligne "Resume next"
Certains types d'erreur peut rendre le cheminement de la macro
impossible ou provoquer un résultat erroné. Il faut mieux afficher
un message et mettre fin à la procédure.
"ElXav" <el...@free.fr> a écrit dans le message de groupe de discussion :
c6baea8f-2043-4389-99ab-355687bc8...@b23g2000yqn.googlegroups.com...
Bonjour Jex, Michdenis,
D'accord avec vous, je m'y astreins depuis un moment déjà.
J'ai pour l'instant 2 problèmes similaires.
L'un dans un classeur Excel développé l'année dernière, l'autre d ans
une base Access qui est passé par les versions 2, 95, 97, et
maintenant 2007.
A chaque migration, il m'aura fallu mettre quelques verrues afin de
contourner divers problèmes.
Pour l'heure, j'aimerais comprendre pourquoi l'objet Err se trouve
affecté par une erreur alors que le code ne plante pas si l'on enlève
l'interception d'erreur.
Pour la partie Access, en pas à pas, depuis le clic qui ferme un
formulaire, et jusqu'à ma fonction, aucune interception d'erreur n'est
activée.
Si je supprime le On Error Resume Next, je n'obtiens pas de plantage,
mon test Err.Number <> 0 est positif avec le code 91, et le recordset
se trouve bien chargé!!
Le tout résolu par un DoEvents en amont de ma fonction...
Dans Excel, j'ai entrepris la même démarche, pas à pas, et je ne pa sse
pas par des procédures évènementiels inopinées.
Sans le On Error, le code se déroule parfaitement bien, le résultat
est correctn et pourtant Err.Number récupère une valeur différente de
zéro.
Comme d'hab, face a ce type de problème, je perds la boule ;-/
Je ne comprends pas pourquoi Err rescense une erreur, surtout une
erreur entrainant normalement l'arrêt du code, alors que celui-ci
fonctionne.
Question subsidiaire afin de valider ou non le fonctionnement du On
Error que j'ai en tête, après une relecture de l'aide en ligne.
Lorsqu'un On Error Goto est exécuté, on est bien d'accord qu'il est
actif le temps que tous le code devant être déroulé le soit?
Soit:
1) Si clic sur un bouton, la procédure évènementielle déma rre.
2) On peut imaginer un ou plusieurs On Error Goto/Resume dans
différentes procédures et fonction appelées.
3) Lorsque la procédure évènementielle liée au clic se ter mine,
tous les On Error Goto/Resume devienne "caduque".
4) Si on lance une nouvelle procédure ou fonction dans laquelle
aucun On Error n'est présent, et qu'une ligne génère une erreur 91 ou
9 (variable / objet non défini, et indice hors limite), le code doit
planter, et Err.Number retourne cette valeur.
Si le 4 est vrai, pourquoi n'ai-j pas ce comportement?? :-/
Merci quand même pour vos conseils.
Si vous entrevoyez une explication...
Cordialement.
Xavier.
On 9 avr, 11:03, Jex <jacques_ast...@hotmail.com> wrote:
> Bonjour,
> Tout à fait d'accord avec michdenis, il vaut mieux préfixer ce type de
> variable (recordset) par le nom de la bibliothèque.
> Sinon, il faut vérifier que toutes les bibliothèques du projet soie nt
> présentes, aussi bien en Excel qu'en Access.
> Dans Excel : Outils / Références.
> Si un objet est marqué comme MANQUANT, il faut le décocher.
> D'autre part, il se peut que la bibliothèque des objets de
> l'application ne soit pas présente (DAO ou Microsoft Office xxx), il
> faut alors la rajouter.
> Bonne suite.
> On 8 avr, 19:42, "michdenis" <michde...@hotmail.com> wrote:
> > Bonjour,
> > Je n'ai pas l'environnement pour tester ta procédure, mais c'est
> > toujours une bonne idée d'être précis lorsqu'il s'agit de déc larer
> > les variables
> > Je modifierais volontiers ceci
> > Dim frd As Recordset
> > Pour
> > Dim frd As Dao.Recordset
> > Juste pour éviter une méprise possible si tu as aussi dans ton pr ojet
> > la bibliothèque ADO de déclarer.
> > "ElXav" <el...@free.fr> a écrit dans le message de groupe de discus sion :
> > 839c29df-5594-4d03-9db4-6522e1dc8...@e7g2000yqf.googlegroups.com...
> > Bonjour Daniel,
> > Ooops, je n'ai pas posté dans le bon forum.
> > J'ai déjà posé la question ici, concernant la partie Excel, et oui,
> > tout le code Excel est bon, les textbox cible existent.
> >http://groups.google.com/group/microsoft.public.fr.excel/browse_threa. ..
> > A tel point, comme je l'explique, en retirant l'interception d'erreur ,
> > le code ne plante pas, et l'objet Err prend la valeur indiquée dans
> > mon post.
> > Si tu as des idées...
> > Merci.
> > Cordialement.
> > On 8 avr, 16:08, Daniel.C <dcolardelle...@gmail.com> wrote:
> > > Bonjour.
> > > Es-tu sûr d'avoir un textbox nommé TbxProPvc115 ?
> > > Daniel
> > > > Bonjour la Communauté,
> > > > Migré depuis peu de Office XP vers Office 2007 SP2, j'ai quelqu es
> > > > soucis avec mes applis Access et Excel.
> > > > Celles-ci fonctionnent trés bien sous XP, mais sous 2007, j'obt iens
> > > > des codes erreur dans l'objet Err, alors que le code ne se plante pas
> > > > même en désactivant le contrôle d'erreur!!
> > > > Or donc, le code listé ci-dessous est là pour:
> > > > - Créer un RecordSet basé sur le contenu d'une table atta chée
> > > > contenant un seul enregistrement.
> > > > Cette table attachée peut ne plus être valide, ce qui est normal
> > > > dans le cadre de l'exploitation de cette base.
> > > > Donc
> > > > - Si la création du RecordSet génère une erreur, il est probable que
> > > > la table attachée ne soit plus valide (lien rompu), dans ce cas ,
> > > > j'alerte l'utilisateur et le dirige vers un formulaire permettant de
> > > > rétablir tous les liens de la base de données
> > > > - Si la création du RecordSet ne génère pas d'erreur, j e traite
> > > > l'enregistrement.
> > > > D'où le code suivant.
> > > > 01 Function InitCodeCentraleTraitée() As Boolean
> > > > 02 ' Initialiser le Code Centrale exécutant l'application
> > > > 03 ' Initialiser les variables globales
> > > > 04 Dim frd As Recordset
> > > > 05 Dim Fnct As Boolean
> > > > 06 InitCodeCentraleTraitée = False
> > > > 07 On Error Resume Next
> > > > 08 Err.Clear
> > > > 09 Set frd = CurrentDb.OpenRecordset("SELECT * FROM Centrale s WHERE
> > > > [Centrale traitée] = True", dbOpenSnapshot)
> > > > 10 If Err <> 0 Then
> > > > 11 MsgBox "Impossible de trouver la table 'Centrales'. L'a ttache de
> > > > table est certainement incorrecte." & Chr$(10) & Chr$(13) &
> > > > Err.Description, vbCritical + vbOKOnly, SMT_NOMAPPLICATION
> > > > 12 DoCmd.OpenForm "Menu Attacher Tables", acNormal, , , ,
> > > > acWindowNormal
> > > > 13 GoTo InitCodeCentraleTraitée_Fin
> > > > 14 End If
> > > > 15 On Error GoTo 0
> > > > 16 If frd.BOF Then
> > > > 17 CodeCentraleTraitée = 0 'Non défini
> > > > 18 MsgBox "Le Code Centrale Traitée n'est pas défini." & Chr$(10) &
> > > > Chr$(13) & "Veuillez modifier ce paramètre dans la table
> > > > 'Centrales'.", vbCritical + vbOKOnly, SMT_NOMAPPLICATION
> > > > 19 GoTo InitCodeCentraleTraitée_Fin
> > > > 20 End If
> > > > 21 Fnct = InitVariablesGlobales()
> > > > 22 InitCodeCentraleTraitée = True
> > > > 23 CodeCentraleTraitée = frd.Fields("Code_centrale")
> > > > 24 InitCodeCentraleTraitée_Fin:
> > > > 25 frd.Close
> > > > 26 Set frd = Nothing
> > > > 27 End Function
> > > > Mon problème se situe en ligne 09.
> > > > La variable frd est bien initialisée, je l'ai vérifié par d es ?
> > > > frd.fields(1).value dans la fenêtre Exécution de VBA.
> > > > Or l'objet Err prend la valeur 91 - Variable objet ou variable de bloc
> > > > With non définie!!!!
> > > > Si je place un point d'arrêt sur la ligne 09, exécutant le Se t, et que
> > > > je continue en pas à pas, je n'obtiens pas l'erreur!
> > > > Si je place mon point d'arrêt sur la ligne 10, soit après l'e xécution
> > > > du Set, j'obtiens l'erreur.
> > > > Un Debug.Print Err.Number, Err.Description juste avant le Set don ne
> > > > comme résultat "0".
> > > > C'est donc bien le Set qui déclenche l'erreur, mais il ne plant e pas.
> > > > J'ai un comportement similaire dans Excel.
> > > > Je me suis tourné vers nos amis Excelliens mais je n'ai pas obt enu de
> > > > réponse expliquant le problème.
> > > > On Error Resume Next
> > > > For intL = 3 To 15 Step 3
> > > > Err.Clear
> > > > .Cells(RngFind.Row, 33 + intL) = CDbl(Me.Controls ("TbxP roPvc1" &
> > > > Format(CStr(intL), "00"))) <<--- Génère l'erreur
> > > > If Err.Number <> 0 Then
> > > > MsgBox "Donnée incorrecte.", vbExclamation + vbOKOnl y,
> > > > ETPP_NomApplication
> > > > Me.Controls("TbxProPvc1" & Format(CStr(intL),"00")).Se tFocus
> > > > GoTo Restituer_Fin
> > > > End If
> > > > Next intL
> > > > L'interception d'erreur n'est la que au cas où!
> > > > En effet, sans le On Error Resume Next, le code se déroule sans
> > > > problème, du fait que je réalise le maximum de vérification en amont.
> > > > Pas de plantage et cependant, l'objet Err prend la valeur 9 - L'i ndice
> > > > n'appartient pas à la sélection.
> > > > Ma question: Pourquoi le code ne plante alors que l'objet Err res titue
> > > > un code erreur?
> > > > Si vous avez des idées je suis preneur.
> > > > D'avance merci et bon
...
plus de détails »- Masquer le texte des messages précédents -
- Afficher le texte des messages précédents -
Si tu veux faire une gestion d'erreur efficace :
'-----------------------------------
Sub MaProcédure()
Dim Gestion_Erreur As String
On Error Goto Gestion_Erreur
Ton code
Exit sub
Gestion_Erreur:
Msgbox Err.Number & ", " & Err.Description
'pour reprendre à la ligne suivante de code où
'l'erreur s'est produite.
Resume next
End Sub
'-----------------------------------
Si tu sais les numéros d'erreur que ta procédure peut provoquer
tu peux faire : (numéro d'erreur pris au hasard.
Gestion_Erreur:
Select case Err.Number
Case 91
'ce que tu veux faire si ça se produit
Case 125
'ce que tu veux faire si ça se produit
Case else
End Select
Il faut utiliser son jugement si on doit ajouter la ligne "Resume next"
Certains types d'erreur peut rendre le cheminement de la macro
impossible ou provoquer un résultat erroné. Il faut mieux afficher
un message et mettre fin à la procédure.
"ElXav" a écrit dans le message de groupe de discussion :
Bonjour Jex, Michdenis,
D'accord avec vous, je m'y astreins depuis un moment déjà.
J'ai pour l'instant 2 problèmes similaires.
L'un dans un classeur Excel développé l'année dernière, l'autre d ans
une base Access qui est passé par les versions 2, 95, 97, et
maintenant 2007.
A chaque migration, il m'aura fallu mettre quelques verrues afin de
contourner divers problèmes.
Pour l'heure, j'aimerais comprendre pourquoi l'objet Err se trouve
affecté par une erreur alors que le code ne plante pas si l'on enlève
l'interception d'erreur.
Pour la partie Access, en pas à pas, depuis le clic qui ferme un
formulaire, et jusqu'à ma fonction, aucune interception d'erreur n'est
activée.
Si je supprime le On Error Resume Next, je n'obtiens pas de plantage,
mon test Err.Number <> 0 est positif avec le code 91, et le recordset
se trouve bien chargé!!
Le tout résolu par un DoEvents en amont de ma fonction...
Dans Excel, j'ai entrepris la même démarche, pas à pas, et je ne pa sse
pas par des procédures évènementiels inopinées.
Sans le On Error, le code se déroule parfaitement bien, le résultat
est correctn et pourtant Err.Number récupère une valeur différente de
zéro.
Comme d'hab, face a ce type de problème, je perds la boule ;-/
Je ne comprends pas pourquoi Err rescense une erreur, surtout une
erreur entrainant normalement l'arrêt du code, alors que celui-ci
fonctionne.
Question subsidiaire afin de valider ou non le fonctionnement du On
Error que j'ai en tête, après une relecture de l'aide en ligne.
Lorsqu'un On Error Goto est exécuté, on est bien d'accord qu'il est
actif le temps que tous le code devant être déroulé le soit?
Soit:
1) Si clic sur un bouton, la procédure évènementielle déma rre.
2) On peut imaginer un ou plusieurs On Error Goto/Resume dans
différentes procédures et fonction appelées.
3) Lorsque la procédure évènementielle liée au clic se ter mine,
tous les On Error Goto/Resume devienne "caduque".
4) Si on lance une nouvelle procédure ou fonction dans laquelle
aucun On Error n'est présent, et qu'une ligne génère une erreur 91 ou
9 (variable / objet non défini, et indice hors limite), le code doit
planter, et Err.Number retourne cette valeur.
Si le 4 est vrai, pourquoi n'ai-j pas ce comportement?? :-/
Merci quand même pour vos conseils.
Si vous entrevoyez une explication...
Cordialement.
Xavier.
On 9 avr, 11:03, Jex wrote:
> Bonjour,
> Tout à fait d'accord avec michdenis, il vaut mieux préfixer ce type de
> variable (recordset) par le nom de la bibliothèque.
> Sinon, il faut vérifier que toutes les bibliothèques du projet soie nt
> présentes, aussi bien en Excel qu'en Access.
> Dans Excel : Outils / Références.
> Si un objet est marqué comme MANQUANT, il faut le décocher.
> D'autre part, il se peut que la bibliothèque des objets de
> l'application ne soit pas présente (DAO ou Microsoft Office xxx), il
> faut alors la rajouter.
> Bonne suite.
> On 8 avr, 19:42, "michdenis" wrote:
> > Bonjour,
> > Je n'ai pas l'environnement pour tester ta procédure, mais c'est
> > toujours une bonne idée d'être précis lorsqu'il s'agit de déc larer
> > les variables
> > Je modifierais volontiers ceci
> > Dim frd As Recordset
> > Pour
> > Dim frd As Dao.Recordset
> > Juste pour éviter une méprise possible si tu as aussi dans ton pr ojet
> > la bibliothèque ADO de déclarer.
> > "ElXav" a écrit dans le message de groupe de discus sion :
> >
> > Bonjour Daniel,
> > Ooops, je n'ai pas posté dans le bon forum.
> > J'ai déjà posé la question ici, concernant la partie Excel, et oui,
> > tout le code Excel est bon, les textbox cible existent.
> >http://groups.google.com/group/microsoft.public.fr.excel/browse_threa. ..
> > A tel point, comme je l'explique, en retirant l'interception d'erreur ,
> > le code ne plante pas, et l'objet Err prend la valeur indiquée dans
> > mon post.
> > Si tu as des idées...
> > Merci.
> > Cordialement.
> > On 8 avr, 16:08, Daniel.C wrote:
> > > Bonjour.
> > > Es-tu sûr d'avoir un textbox nommé TbxProPvc115 ?
> > > Daniel
> > > > Bonjour la Communauté,
> > > > Migré depuis peu de Office XP vers Office 2007 SP2, j'ai quelqu es
> > > > soucis avec mes applis Access et Excel.
> > > > Celles-ci fonctionnent trés bien sous XP, mais sous 2007, j'obt iens
> > > > des codes erreur dans l'objet Err, alors que le code ne se plante pas
> > > > même en désactivant le contrôle d'erreur!!
> > > > Or donc, le code listé ci-dessous est là pour:
> > > > - Créer un RecordSet basé sur le contenu d'une table atta chée
> > > > contenant un seul enregistrement.
> > > > Cette table attachée peut ne plus être valide, ce qui est normal
> > > > dans le cadre de l'exploitation de cette base.
> > > > Donc
> > > > - Si la création du RecordSet génère une erreur, il est probable que
> > > > la table attachée ne soit plus valide (lien rompu), dans ce cas ,
> > > > j'alerte l'utilisateur et le dirige vers un formulaire permettant de
> > > > rétablir tous les liens de la base de données
> > > > - Si la création du RecordSet ne génère pas d'erreur, j e traite
> > > > l'enregistrement.
> > > > D'où le code suivant.
> > > > 01 Function InitCodeCentraleTraitée() As Boolean
> > > > 02 ' Initialiser le Code Centrale exécutant l'application
> > > > 03 ' Initialiser les variables globales
> > > > 04 Dim frd As Recordset
> > > > 05 Dim Fnct As Boolean
> > > > 06 InitCodeCentraleTraitée = False
> > > > 07 On Error Resume Next
> > > > 08 Err.Clear
> > > > 09 Set frd = CurrentDb.OpenRecordset("SELECT * FROM Centrale s WHERE
> > > > [Centrale traitée] = True", dbOpenSnapshot)
> > > > 10 If Err <> 0 Then
> > > > 11 MsgBox "Impossible de trouver la table 'Centrales'. L'a ttache de
> > > > table est certainement incorrecte." & Chr$(10) & Chr$(13) &
> > > > Err.Description, vbCritical + vbOKOnly, SMT_NOMAPPLICATION
> > > > 12 DoCmd.OpenForm "Menu Attacher Tables", acNormal, , , ,
> > > > acWindowNormal
> > > > 13 GoTo InitCodeCentraleTraitée_Fin
> > > > 14 End If
> > > > 15 On Error GoTo 0
> > > > 16 If frd.BOF Then
> > > > 17 CodeCentraleTraitée = 0 'Non défini
> > > > 18 MsgBox "Le Code Centrale Traitée n'est pas défini." & Chr$(10) &
> > > > Chr$(13) & "Veuillez modifier ce paramètre dans la table
> > > > 'Centrales'.", vbCritical + vbOKOnly, SMT_NOMAPPLICATION
> > > > 19 GoTo InitCodeCentraleTraitée_Fin
> > > > 20 End If
> > > > 21 Fnct = InitVariablesGlobales()
> > > > 22 InitCodeCentraleTraitée = True
> > > > 23 CodeCentraleTraitée = frd.Fields("Code_centrale")
> > > > 24 InitCodeCentraleTraitée_Fin:
> > > > 25 frd.Close
> > > > 26 Set frd = Nothing
> > > > 27 End Function
> > > > Mon problème se situe en ligne 09.
> > > > La variable frd est bien initialisée, je l'ai vérifié par d es ?
> > > > frd.fields(1).value dans la fenêtre Exécution de VBA.
> > > > Or l'objet Err prend la valeur 91 - Variable objet ou variable de bloc
> > > > With non définie!!!!
> > > > Si je place un point d'arrêt sur la ligne 09, exécutant le Se t, et que
> > > > je continue en pas à pas, je n'obtiens pas l'erreur!
> > > > Si je place mon point d'arrêt sur la ligne 10, soit après l'e xécution
> > > > du Set, j'obtiens l'erreur.
> > > > Un Debug.Print Err.Number, Err.Description juste avant le Set don ne
> > > > comme résultat "0".
> > > > C'est donc bien le Set qui déclenche l'erreur, mais il ne plant e pas.
> > > > J'ai un comportement similaire dans Excel.
> > > > Je me suis tourné vers nos amis Excelliens mais je n'ai pas obt enu de
> > > > réponse expliquant le problème.
> > > > On Error Resume Next
> > > > For intL = 3 To 15 Step 3
> > > > Err.Clear
> > > > .Cells(RngFind.Row, 33 + intL) = CDbl(Me.Controls ("TbxP roPvc1" &
> > > > Format(CStr(intL), "00"))) <<--- Génère l'erreur
> > > > If Err.Number <> 0 Then
> > > > MsgBox "Donnée incorrecte.", vbExclamation + vbOKOnl y,
> > > > ETPP_NomApplication
> > > > Me.Controls("TbxProPvc1" & Format(CStr(intL),"00")).Se tFocus
> > > > GoTo Restituer_Fin
> > > > End If
> > > > Next intL
> > > > L'interception d'erreur n'est la que au cas où!
> > > > En effet, sans le On Error Resume Next, le code se déroule sans
> > > > problème, du fait que je réalise le maximum de vérification en amont.
> > > > Pas de plantage et cependant, l'objet Err prend la valeur 9 - L'i ndice
> > > > n'appartient pas à la sélection.
> > > > Ma question: Pourquoi le code ne plante alors que l'objet Err res titue
> > > > un code erreur?
> > > > Si vous avez des idées je suis preneur.
> > > > D'avance merci et bon
...
plus de détails »- Masquer le texte des messages précédents -
- Afficher le texte des messages précédents -
Si tu veux faire une gestion d'erreur efficace :
'-----------------------------------
Sub MaProcédure()
Dim Gestion_Erreur As String
On Error Goto Gestion_Erreur
Ton code
Exit sub
Gestion_Erreur:
Msgbox Err.Number & ", " & Err.Description
'pour reprendre à la ligne suivante de code où
'l'erreur s'est produite.
Resume next
End Sub
'-----------------------------------
Si tu sais les numéros d'erreur que ta procédure peut provoquer
tu peux faire : (numéro d'erreur pris au hasard.
Gestion_Erreur:
Select case Err.Number
Case 91
'ce que tu veux faire si ça se produit
Case 125
'ce que tu veux faire si ça se produit
Case else
End Select
Il faut utiliser son jugement si on doit ajouter la ligne "Resume next"
Certains types d'erreur peut rendre le cheminement de la macro
impossible ou provoquer un résultat erroné. Il faut mieux afficher
un message et mettre fin à la procédure.
"ElXav" a écrit dans le message de groupe de discussion :
Bonjour Jex, Michdenis,
D'accord avec vous, je m'y astreins depuis un moment déjà.
J'ai pour l'instant 2 problèmes similaires.
L'un dans un classeur Excel développé l'année dernière, l'autre dans
une base Access qui est passé par les versions 2, 95, 97, et
maintenant 2007.
A chaque migration, il m'aura fallu mettre quelques verrues afin de
contourner divers problèmes.
Pour l'heure, j'aimerais comprendre pourquoi l'objet Err se trouve
affecté par une erreur alors que le code ne plante pas si l'on enlève
l'interception d'erreur.
Pour la partie Access, en pas à pas, depuis le clic qui ferme un
formulaire, et jusqu'à ma fonction, aucune interception d'erreur n'est
activée.
Si je supprime le On Error Resume Next, je n'obtiens pas de plantage,
mon test Err.Number <> 0 est positif avec le code 91, et le recordset
se trouve bien chargé!!
Le tout résolu par un DoEvents en amont de ma fonction...
Dans Excel, j'ai entrepris la même démarche, pas à pas, et je ne passe
pas par des procédures évènementiels inopinées.
Sans le On Error, le code se déroule parfaitement bien, le résultat
est correctn et pourtant Err.Number récupère une valeur différente de
zéro.
Comme d'hab, face a ce type de problème, je perds la boule ;-/
Je ne comprends pas pourquoi Err rescense une erreur, surtout une
erreur entrainant normalement l'arrêt du code, alors que celui-ci
fonctionne.
Question subsidiaire afin de valider ou non le fonctionnement du On
Error que j'ai en tête, après une relecture de l'aide en ligne.
Lorsqu'un On Error Goto est exécuté, on est bien d'accord qu'il est
actif le temps que tous le code devant être déroulé le soit?
Soit:
1) Si clic sur un bouton, la procédure évènementielle démarre.
2) On peut imaginer un ou plusieurs On Error Goto/Resume dans
différentes procédures et fonction appelées.
3) Lorsque la procédure évènementielle liée au clic se termine,
tous les On Error Goto/Resume devienne "caduque".
4) Si on lance une nouvelle procédure ou fonction dans laquelle
aucun On Error n'est présent, et qu'une ligne génère une erreur 91 ou
9 (variable / objet non défini, et indice hors limite), le code doit
planter, et Err.Number retourne cette valeur.
Si le 4 est vrai, pourquoi n'ai-j pas ce comportement?? :-/
Merci quand même pour vos conseils.
Si vous entrevoyez une explication...
Cordialement.
Xavier.
On 9 avr, 11:03, Jex wrote:
> Bonjour,
> Tout à fait d'accord avec michdenis, il vaut mieux préfixer ce type de
> variable (recordset) par le nom de la bibliothèque.
> Sinon, il faut vérifier que toutes les bibliothèques du projet soient
> présentes, aussi bien en Excel qu'en Access.
> Dans Excel : Outils / Références.
> Si un objet est marqué comme MANQUANT, il faut le décocher.
> D'autre part, il se peut que la bibliothèque des objets de
> l'application ne soit pas présente (DAO ou Microsoft Office xxx), il
> faut alors la rajouter.
> Bonne suite.
> On 8 avr, 19:42, "michdenis" wrote:
> > Bonjour,
> > Je n'ai pas l'environnement pour tester ta procédure, mais c'est
> > toujours une bonne idée d'être précis lorsqu'il s'agit de déclarer
> > les variables
> > Je modifierais volontiers ceci
> > Dim frd As Recordset
> > Pour
> > Dim frd As Dao.Recordset
> > Juste pour éviter une méprise possible si tu as aussi dans ton projet
> > la bibliothèque ADO de déclarer.
> > "ElXav" a écrit dans le message de groupe de discussion :
> >
> > Bonjour Daniel,
> > Ooops, je n'ai pas posté dans le bon forum.
> > J'ai déjà posé la question ici, concernant la partie Excel, et oui,
> > tout le code Excel est bon, les textbox cible existent.
> >http://groups.google.com/group/microsoft.public.fr.excel/browse_threa...
> > A tel point, comme je l'explique, en retirant l'interception d'erreur,
> > le code ne plante pas, et l'objet Err prend la valeur indiquée dans
> > mon post.
> > Si tu as des idées...
> > Merci.
> > Cordialement.
> > On 8 avr, 16:08, Daniel.C wrote:
> > > Bonjour.
> > > Es-tu sûr d'avoir un textbox nommé TbxProPvc115 ?
> > > Daniel
> > > > Bonjour la Communauté,
> > > > Migré depuis peu de Office XP vers Office 2007 SP2, j'ai quelques
> > > > soucis avec mes applis Access et Excel.
> > > > Celles-ci fonctionnent trés bien sous XP, mais sous 2007, j'obtiens
> > > > des codes erreur dans l'objet Err, alors que le code ne se plante pas
> > > > même en désactivant le contrôle d'erreur!!
> > > > Or donc, le code listé ci-dessous est là pour:
> > > > - Créer un RecordSet basé sur le contenu d'une table attachée
> > > > contenant un seul enregistrement.
> > > > Cette table attachée peut ne plus être valide, ce qui est normal
> > > > dans le cadre de l'exploitation de cette base.
> > > > Donc
> > > > - Si la création du RecordSet génère une erreur, il est probable que
> > > > la table attachée ne soit plus valide (lien rompu), dans ce cas,
> > > > j'alerte l'utilisateur et le dirige vers un formulaire permettant de
> > > > rétablir tous les liens de la base de données
> > > > - Si la création du RecordSet ne génère pas d'erreur, je traite
> > > > l'enregistrement.
> > > > D'où le code suivant.
> > > > 01 Function InitCodeCentraleTraitée() As Boolean
> > > > 02 ' Initialiser le Code Centrale exécutant l'application
> > > > 03 ' Initialiser les variables globales
> > > > 04 Dim frd As Recordset
> > > > 05 Dim Fnct As Boolean
> > > > 06 InitCodeCentraleTraitée = False
> > > > 07 On Error Resume Next
> > > > 08 Err.Clear
> > > > 09 Set frd = CurrentDb.OpenRecordset("SELECT * FROM Centrales WHERE
> > > > [Centrale traitée] = True", dbOpenSnapshot)
> > > > 10 If Err <> 0 Then
> > > > 11 MsgBox "Impossible de trouver la table 'Centrales'. L'attache de
> > > > table est certainement incorrecte." & Chr$(10) & Chr$(13) &
> > > > Err.Description, vbCritical + vbOKOnly, SMT_NOMAPPLICATION
> > > > 12 DoCmd.OpenForm "Menu Attacher Tables", acNormal, , , ,
> > > > acWindowNormal
> > > > 13 GoTo InitCodeCentraleTraitée_Fin
> > > > 14 End If
> > > > 15 On Error GoTo 0
> > > > 16 If frd.BOF Then
> > > > 17 CodeCentraleTraitée = 0 'Non défini
> > > > 18 MsgBox "Le Code Centrale Traitée n'est pas défini." & Chr$(10) &
> > > > Chr$(13) & "Veuillez modifier ce paramètre dans la table
> > > > 'Centrales'.", vbCritical + vbOKOnly, SMT_NOMAPPLICATION
> > > > 19 GoTo InitCodeCentraleTraitée_Fin
> > > > 20 End If
> > > > 21 Fnct = InitVariablesGlobales()
> > > > 22 InitCodeCentraleTraitée = True
> > > > 23 CodeCentraleTraitée = frd.Fields("Code_centrale")
> > > > 24 InitCodeCentraleTraitée_Fin:
> > > > 25 frd.Close
> > > > 26 Set frd = Nothing
> > > > 27 End Function
> > > > Mon problème se situe en ligne 09.
> > > > La variable frd est bien initialisée, je l'ai vérifié par des ?
> > > > frd.fields(1).value dans la fenêtre Exécution de VBA.
> > > > Or l'objet Err prend la valeur 91 - Variable objet ou variable de bloc
> > > > With non définie!!!!
> > > > Si je place un point d'arrêt sur la ligne 09, exécutant le Set, et que
> > > > je continue en pas à pas, je n'obtiens pas l'erreur!
> > > > Si je place mon point d'arrêt sur la ligne 10, soit après l'exécution
> > > > du Set, j'obtiens l'erreur.
> > > > Un Debug.Print Err.Number, Err.Description juste avant le Set donne
> > > > comme résultat "0".
> > > > C'est donc bien le Set qui déclenche l'erreur, mais il ne plante pas.
> > > > J'ai un comportement similaire dans Excel.
> > > > Je me suis tourné vers nos amis Excelliens mais je n'ai pas obtenu de
> > > > réponse expliquant le problème.
> > > > On Error Resume Next
> > > > For intL = 3 To 15 Step 3
> > > > Err.Clear
> > > > .Cells(RngFind.Row, 33 + intL) = CDbl(Me.Controls ("TbxProPvc1" &
> > > > Format(CStr(intL), "00"))) <<--- Génère l'erreur
> > > > If Err.Number <> 0 Then
> > > > MsgBox "Donnée incorrecte.", vbExclamation + vbOKOnly,
> > > > ETPP_NomApplication
> > > > Me.Controls("TbxProPvc1" & Format(CStr(intL),"00")).SetFocus
> > > > GoTo Restituer_Fin
> > > > End If
> > > > Next intL
> > > > L'interception d'erreur n'est la que au cas où!
> > > > En effet, sans le On Error Resume Next, le code se déroule sans
> > > > problème, du fait que je réalise le maximum de vérification en amont.
> > > > Pas de plantage et cependant, l'objet Err prend la valeur 9 - L'indice
> > > > n'appartient pas à la sélection.
> > > > Ma question: Pourquoi le code ne plante alors que l'objet Err restitue
> > > > un code erreur?
> > > > Si vous avez des idées je suis preneur.
> > > > D'avance merci et bon
...
plus de détails »- Masquer le texte des messages précédents -
- Afficher le texte des messages précédents -
Si tu veux faire une gestion d'erreur efficace :
'-----------------------------------
Sub MaProcédure()
Dim Gestion_Erreur As String
On Error Goto Gestion_Erreur
Ton code
Exit sub
Gestion_Erreur:
Msgbox Err.Number & ", " & Err.Description
'pour reprendre à la ligne suivante de code où
'l'erreur s'est produite.
Resume next
End Sub
'-----------------------------------
Si tu sais les numéros d'erreur que ta procédure peut provoquer
tu peux faire : (numéro d'erreur pris au hasard.
Gestion_Erreur:
Select case Err.Number
Case 91
'ce que tu veux faire si ça se produit
Case 125
'ce que tu veux faire si ça se produit
Case else
End Select
Il faut utiliser son jugement si on doit ajouter la ligne "Resume next"
Certains types d'erreur peut rendre le cheminement de la macro
impossible ou provoquer un résultat erroné. Il faut mieux afficher
un message et mettre fin à la procédure.
"ElXav" <el...@free.fr> a écrit dans le message de groupe de discussion :
c6baea8f-2043-4389-99ab-355687bc8...@b23g2000yqn.googlegroups.com...
Bonjour Jex, Michdenis,
D'accord avec vous, je m'y astreins depuis un moment déjà.
J'ai pour l'instant 2 problèmes similaires.
L'un dans un classeur Excel développé l'année dernière, l'autre dans
une base Access qui est passé par les versions 2, 95, 97, et
maintenant 2007.
A chaque migration, il m'aura fallu mettre quelques verrues afin de
contourner divers problèmes.
Pour l'heure, j'aimerais comprendre pourquoi l'objet Err se trouve
affecté par une erreur alors que le code ne plante pas si l'on enlève
l'interception d'erreur.
Pour la partie Access, en pas à pas, depuis le clic qui ferme un
formulaire, et jusqu'à ma fonction, aucune interception d'erreur n'est
activée.
Si je supprime le On Error Resume Next, je n'obtiens pas de plantage,
mon test Err.Number <> 0 est positif avec le code 91, et le recordset
se trouve bien chargé!!
Le tout résolu par un DoEvents en amont de ma fonction...
Dans Excel, j'ai entrepris la même démarche, pas à pas, et je ne passe
pas par des procédures évènementiels inopinées.
Sans le On Error, le code se déroule parfaitement bien, le résultat
est correctn et pourtant Err.Number récupère une valeur différente de
zéro.
Comme d'hab, face a ce type de problème, je perds la boule ;-/
Je ne comprends pas pourquoi Err rescense une erreur, surtout une
erreur entrainant normalement l'arrêt du code, alors que celui-ci
fonctionne.
Question subsidiaire afin de valider ou non le fonctionnement du On
Error que j'ai en tête, après une relecture de l'aide en ligne.
Lorsqu'un On Error Goto est exécuté, on est bien d'accord qu'il est
actif le temps que tous le code devant être déroulé le soit?
Soit:
1) Si clic sur un bouton, la procédure évènementielle démarre.
2) On peut imaginer un ou plusieurs On Error Goto/Resume dans
différentes procédures et fonction appelées.
3) Lorsque la procédure évènementielle liée au clic se termine,
tous les On Error Goto/Resume devienne "caduque".
4) Si on lance une nouvelle procédure ou fonction dans laquelle
aucun On Error n'est présent, et qu'une ligne génère une erreur 91 ou
9 (variable / objet non défini, et indice hors limite), le code doit
planter, et Err.Number retourne cette valeur.
Si le 4 est vrai, pourquoi n'ai-j pas ce comportement?? :-/
Merci quand même pour vos conseils.
Si vous entrevoyez une explication...
Cordialement.
Xavier.
On 9 avr, 11:03, Jex <jacques_ast...@hotmail.com> wrote:
> Bonjour,
> Tout à fait d'accord avec michdenis, il vaut mieux préfixer ce type de
> variable (recordset) par le nom de la bibliothèque.
> Sinon, il faut vérifier que toutes les bibliothèques du projet soient
> présentes, aussi bien en Excel qu'en Access.
> Dans Excel : Outils / Références.
> Si un objet est marqué comme MANQUANT, il faut le décocher.
> D'autre part, il se peut que la bibliothèque des objets de
> l'application ne soit pas présente (DAO ou Microsoft Office xxx), il
> faut alors la rajouter.
> Bonne suite.
> On 8 avr, 19:42, "michdenis" <michde...@hotmail.com> wrote:
> > Bonjour,
> > Je n'ai pas l'environnement pour tester ta procédure, mais c'est
> > toujours une bonne idée d'être précis lorsqu'il s'agit de déclarer
> > les variables
> > Je modifierais volontiers ceci
> > Dim frd As Recordset
> > Pour
> > Dim frd As Dao.Recordset
> > Juste pour éviter une méprise possible si tu as aussi dans ton projet
> > la bibliothèque ADO de déclarer.
> > "ElXav" <el...@free.fr> a écrit dans le message de groupe de discussion :
> > 839c29df-5594-4d03-9db4-6522e1dc8...@e7g2000yqf.googlegroups.com...
> > Bonjour Daniel,
> > Ooops, je n'ai pas posté dans le bon forum.
> > J'ai déjà posé la question ici, concernant la partie Excel, et oui,
> > tout le code Excel est bon, les textbox cible existent.
> >http://groups.google.com/group/microsoft.public.fr.excel/browse_threa...
> > A tel point, comme je l'explique, en retirant l'interception d'erreur,
> > le code ne plante pas, et l'objet Err prend la valeur indiquée dans
> > mon post.
> > Si tu as des idées...
> > Merci.
> > Cordialement.
> > On 8 avr, 16:08, Daniel.C <dcolardelle...@gmail.com> wrote:
> > > Bonjour.
> > > Es-tu sûr d'avoir un textbox nommé TbxProPvc115 ?
> > > Daniel
> > > > Bonjour la Communauté,
> > > > Migré depuis peu de Office XP vers Office 2007 SP2, j'ai quelques
> > > > soucis avec mes applis Access et Excel.
> > > > Celles-ci fonctionnent trés bien sous XP, mais sous 2007, j'obtiens
> > > > des codes erreur dans l'objet Err, alors que le code ne se plante pas
> > > > même en désactivant le contrôle d'erreur!!
> > > > Or donc, le code listé ci-dessous est là pour:
> > > > - Créer un RecordSet basé sur le contenu d'une table attachée
> > > > contenant un seul enregistrement.
> > > > Cette table attachée peut ne plus être valide, ce qui est normal
> > > > dans le cadre de l'exploitation de cette base.
> > > > Donc
> > > > - Si la création du RecordSet génère une erreur, il est probable que
> > > > la table attachée ne soit plus valide (lien rompu), dans ce cas,
> > > > j'alerte l'utilisateur et le dirige vers un formulaire permettant de
> > > > rétablir tous les liens de la base de données
> > > > - Si la création du RecordSet ne génère pas d'erreur, je traite
> > > > l'enregistrement.
> > > > D'où le code suivant.
> > > > 01 Function InitCodeCentraleTraitée() As Boolean
> > > > 02 ' Initialiser le Code Centrale exécutant l'application
> > > > 03 ' Initialiser les variables globales
> > > > 04 Dim frd As Recordset
> > > > 05 Dim Fnct As Boolean
> > > > 06 InitCodeCentraleTraitée = False
> > > > 07 On Error Resume Next
> > > > 08 Err.Clear
> > > > 09 Set frd = CurrentDb.OpenRecordset("SELECT * FROM Centrales WHERE
> > > > [Centrale traitée] = True", dbOpenSnapshot)
> > > > 10 If Err <> 0 Then
> > > > 11 MsgBox "Impossible de trouver la table 'Centrales'. L'attache de
> > > > table est certainement incorrecte." & Chr$(10) & Chr$(13) &
> > > > Err.Description, vbCritical + vbOKOnly, SMT_NOMAPPLICATION
> > > > 12 DoCmd.OpenForm "Menu Attacher Tables", acNormal, , , ,
> > > > acWindowNormal
> > > > 13 GoTo InitCodeCentraleTraitée_Fin
> > > > 14 End If
> > > > 15 On Error GoTo 0
> > > > 16 If frd.BOF Then
> > > > 17 CodeCentraleTraitée = 0 'Non défini
> > > > 18 MsgBox "Le Code Centrale Traitée n'est pas défini." & Chr$(10) &
> > > > Chr$(13) & "Veuillez modifier ce paramètre dans la table
> > > > 'Centrales'.", vbCritical + vbOKOnly, SMT_NOMAPPLICATION
> > > > 19 GoTo InitCodeCentraleTraitée_Fin
> > > > 20 End If
> > > > 21 Fnct = InitVariablesGlobales()
> > > > 22 InitCodeCentraleTraitée = True
> > > > 23 CodeCentraleTraitée = frd.Fields("Code_centrale")
> > > > 24 InitCodeCentraleTraitée_Fin:
> > > > 25 frd.Close
> > > > 26 Set frd = Nothing
> > > > 27 End Function
> > > > Mon problème se situe en ligne 09.
> > > > La variable frd est bien initialisée, je l'ai vérifié par des ?
> > > > frd.fields(1).value dans la fenêtre Exécution de VBA.
> > > > Or l'objet Err prend la valeur 91 - Variable objet ou variable de bloc
> > > > With non définie!!!!
> > > > Si je place un point d'arrêt sur la ligne 09, exécutant le Set, et que
> > > > je continue en pas à pas, je n'obtiens pas l'erreur!
> > > > Si je place mon point d'arrêt sur la ligne 10, soit après l'exécution
> > > > du Set, j'obtiens l'erreur.
> > > > Un Debug.Print Err.Number, Err.Description juste avant le Set donne
> > > > comme résultat "0".
> > > > C'est donc bien le Set qui déclenche l'erreur, mais il ne plante pas.
> > > > J'ai un comportement similaire dans Excel.
> > > > Je me suis tourné vers nos amis Excelliens mais je n'ai pas obtenu de
> > > > réponse expliquant le problème.
> > > > On Error Resume Next
> > > > For intL = 3 To 15 Step 3
> > > > Err.Clear
> > > > .Cells(RngFind.Row, 33 + intL) = CDbl(Me.Controls ("TbxProPvc1" &
> > > > Format(CStr(intL), "00"))) <<--- Génère l'erreur
> > > > If Err.Number <> 0 Then
> > > > MsgBox "Donnée incorrecte.", vbExclamation + vbOKOnly,
> > > > ETPP_NomApplication
> > > > Me.Controls("TbxProPvc1" & Format(CStr(intL),"00")).SetFocus
> > > > GoTo Restituer_Fin
> > > > End If
> > > > Next intL
> > > > L'interception d'erreur n'est la que au cas où!
> > > > En effet, sans le On Error Resume Next, le code se déroule sans
> > > > problème, du fait que je réalise le maximum de vérification en amont.
> > > > Pas de plantage et cependant, l'objet Err prend la valeur 9 - L'indice
> > > > n'appartient pas à la sélection.
> > > > Ma question: Pourquoi le code ne plante alors que l'objet Err restitue
> > > > un code erreur?
> > > > Si vous avez des idées je suis preneur.
> > > > D'avance merci et bon
...
plus de détails »- Masquer le texte des messages précédents -
- Afficher le texte des messages précédents -
Si tu veux faire une gestion d'erreur efficace :
'-----------------------------------
Sub MaProcédure()
Dim Gestion_Erreur As String
On Error Goto Gestion_Erreur
Ton code
Exit sub
Gestion_Erreur:
Msgbox Err.Number & ", " & Err.Description
'pour reprendre à la ligne suivante de code où
'l'erreur s'est produite.
Resume next
End Sub
'-----------------------------------
Si tu sais les numéros d'erreur que ta procédure peut provoquer
tu peux faire : (numéro d'erreur pris au hasard.
Gestion_Erreur:
Select case Err.Number
Case 91
'ce que tu veux faire si ça se produit
Case 125
'ce que tu veux faire si ça se produit
Case else
End Select
Il faut utiliser son jugement si on doit ajouter la ligne "Resume next"
Certains types d'erreur peut rendre le cheminement de la macro
impossible ou provoquer un résultat erroné. Il faut mieux afficher
un message et mettre fin à la procédure.
"ElXav" a écrit dans le message de groupe de discussion :
Bonjour Jex, Michdenis,
D'accord avec vous, je m'y astreins depuis un moment déjà.
J'ai pour l'instant 2 problèmes similaires.
L'un dans un classeur Excel développé l'année dernière, l'autre dans
une base Access qui est passé par les versions 2, 95, 97, et
maintenant 2007.
A chaque migration, il m'aura fallu mettre quelques verrues afin de
contourner divers problèmes.
Pour l'heure, j'aimerais comprendre pourquoi l'objet Err se trouve
affecté par une erreur alors que le code ne plante pas si l'on enlève
l'interception d'erreur.
Pour la partie Access, en pas à pas, depuis le clic qui ferme un
formulaire, et jusqu'à ma fonction, aucune interception d'erreur n'est
activée.
Si je supprime le On Error Resume Next, je n'obtiens pas de plantage,
mon test Err.Number <> 0 est positif avec le code 91, et le recordset
se trouve bien chargé!!
Le tout résolu par un DoEvents en amont de ma fonction...
Dans Excel, j'ai entrepris la même démarche, pas à pas, et je ne passe
pas par des procédures évènementiels inopinées.
Sans le On Error, le code se déroule parfaitement bien, le résultat
est correctn et pourtant Err.Number récupère une valeur différente de
zéro.
Comme d'hab, face a ce type de problème, je perds la boule ;-/
Je ne comprends pas pourquoi Err rescense une erreur, surtout une
erreur entrainant normalement l'arrêt du code, alors que celui-ci
fonctionne.
Question subsidiaire afin de valider ou non le fonctionnement du On
Error que j'ai en tête, après une relecture de l'aide en ligne.
Lorsqu'un On Error Goto est exécuté, on est bien d'accord qu'il est
actif le temps que tous le code devant être déroulé le soit?
Soit:
1) Si clic sur un bouton, la procédure évènementielle démarre.
2) On peut imaginer un ou plusieurs On Error Goto/Resume dans
différentes procédures et fonction appelées.
3) Lorsque la procédure évènementielle liée au clic se termine,
tous les On Error Goto/Resume devienne "caduque".
4) Si on lance une nouvelle procédure ou fonction dans laquelle
aucun On Error n'est présent, et qu'une ligne génère une erreur 91 ou
9 (variable / objet non défini, et indice hors limite), le code doit
planter, et Err.Number retourne cette valeur.
Si le 4 est vrai, pourquoi n'ai-j pas ce comportement?? :-/
Merci quand même pour vos conseils.
Si vous entrevoyez une explication...
Cordialement.
Xavier.
On 9 avr, 11:03, Jex wrote:
> Bonjour,
> Tout à fait d'accord avec michdenis, il vaut mieux préfixer ce type de
> variable (recordset) par le nom de la bibliothèque.
> Sinon, il faut vérifier que toutes les bibliothèques du projet soient
> présentes, aussi bien en Excel qu'en Access.
> Dans Excel : Outils / Références.
> Si un objet est marqué comme MANQUANT, il faut le décocher.
> D'autre part, il se peut que la bibliothèque des objets de
> l'application ne soit pas présente (DAO ou Microsoft Office xxx), il
> faut alors la rajouter.
> Bonne suite.
> On 8 avr, 19:42, "michdenis" wrote:
> > Bonjour,
> > Je n'ai pas l'environnement pour tester ta procédure, mais c'est
> > toujours une bonne idée d'être précis lorsqu'il s'agit de déclarer
> > les variables
> > Je modifierais volontiers ceci
> > Dim frd As Recordset
> > Pour
> > Dim frd As Dao.Recordset
> > Juste pour éviter une méprise possible si tu as aussi dans ton projet
> > la bibliothèque ADO de déclarer.
> > "ElXav" a écrit dans le message de groupe de discussion :
> >
> > Bonjour Daniel,
> > Ooops, je n'ai pas posté dans le bon forum.
> > J'ai déjà posé la question ici, concernant la partie Excel, et oui,
> > tout le code Excel est bon, les textbox cible existent.
> >http://groups.google.com/group/microsoft.public.fr.excel/browse_threa...
> > A tel point, comme je l'explique, en retirant l'interception d'erreur,
> > le code ne plante pas, et l'objet Err prend la valeur indiquée dans
> > mon post.
> > Si tu as des idées...
> > Merci.
> > Cordialement.
> > On 8 avr, 16:08, Daniel.C wrote:
> > > Bonjour.
> > > Es-tu sûr d'avoir un textbox nommé TbxProPvc115 ?
> > > Daniel
> > > > Bonjour la Communauté,
> > > > Migré depuis peu de Office XP vers Office 2007 SP2, j'ai quelques
> > > > soucis avec mes applis Access et Excel.
> > > > Celles-ci fonctionnent trés bien sous XP, mais sous 2007, j'obtiens
> > > > des codes erreur dans l'objet Err, alors que le code ne se plante pas
> > > > même en désactivant le contrôle d'erreur!!
> > > > Or donc, le code listé ci-dessous est là pour:
> > > > - Créer un RecordSet basé sur le contenu d'une table attachée
> > > > contenant un seul enregistrement.
> > > > Cette table attachée peut ne plus être valide, ce qui est normal
> > > > dans le cadre de l'exploitation de cette base.
> > > > Donc
> > > > - Si la création du RecordSet génère une erreur, il est probable que
> > > > la table attachée ne soit plus valide (lien rompu), dans ce cas,
> > > > j'alerte l'utilisateur et le dirige vers un formulaire permettant de
> > > > rétablir tous les liens de la base de données
> > > > - Si la création du RecordSet ne génère pas d'erreur, je traite
> > > > l'enregistrement.
> > > > D'où le code suivant.
> > > > 01 Function InitCodeCentraleTraitée() As Boolean
> > > > 02 ' Initialiser le Code Centrale exécutant l'application
> > > > 03 ' Initialiser les variables globales
> > > > 04 Dim frd As Recordset
> > > > 05 Dim Fnct As Boolean
> > > > 06 InitCodeCentraleTraitée = False
> > > > 07 On Error Resume Next
> > > > 08 Err.Clear
> > > > 09 Set frd = CurrentDb.OpenRecordset("SELECT * FROM Centrales WHERE
> > > > [Centrale traitée] = True", dbOpenSnapshot)
> > > > 10 If Err <> 0 Then
> > > > 11 MsgBox "Impossible de trouver la table 'Centrales'. L'attache de
> > > > table est certainement incorrecte." & Chr$(10) & Chr$(13) &
> > > > Err.Description, vbCritical + vbOKOnly, SMT_NOMAPPLICATION
> > > > 12 DoCmd.OpenForm "Menu Attacher Tables", acNormal, , , ,
> > > > acWindowNormal
> > > > 13 GoTo InitCodeCentraleTraitée_Fin
> > > > 14 End If
> > > > 15 On Error GoTo 0
> > > > 16 If frd.BOF Then
> > > > 17 CodeCentraleTraitée = 0 'Non défini
> > > > 18 MsgBox "Le Code Centrale Traitée n'est pas défini." & Chr$(10) &
> > > > Chr$(13) & "Veuillez modifier ce paramètre dans la table
> > > > 'Centrales'.", vbCritical + vbOKOnly, SMT_NOMAPPLICATION
> > > > 19 GoTo InitCodeCentraleTraitée_Fin
> > > > 20 End If
> > > > 21 Fnct = InitVariablesGlobales()
> > > > 22 InitCodeCentraleTraitée = True
> > > > 23 CodeCentraleTraitée = frd.Fields("Code_centrale")
> > > > 24 InitCodeCentraleTraitée_Fin:
> > > > 25 frd.Close
> > > > 26 Set frd = Nothing
> > > > 27 End Function
> > > > Mon problème se situe en ligne 09.
> > > > La variable frd est bien initialisée, je l'ai vérifié par des ?
> > > > frd.fields(1).value dans la fenêtre Exécution de VBA.
> > > > Or l'objet Err prend la valeur 91 - Variable objet ou variable de bloc
> > > > With non définie!!!!
> > > > Si je place un point d'arrêt sur la ligne 09, exécutant le Set, et que
> > > > je continue en pas à pas, je n'obtiens pas l'erreur!
> > > > Si je place mon point d'arrêt sur la ligne 10, soit après l'exécution
> > > > du Set, j'obtiens l'erreur.
> > > > Un Debug.Print Err.Number, Err.Description juste avant le Set donne
> > > > comme résultat "0".
> > > > C'est donc bien le Set qui déclenche l'erreur, mais il ne plante pas.
> > > > J'ai un comportement similaire dans Excel.
> > > > Je me suis tourné vers nos amis Excelliens mais je n'ai pas obtenu de
> > > > réponse expliquant le problème.
> > > > On Error Resume Next
> > > > For intL = 3 To 15 Step 3
> > > > Err.Clear
> > > > .Cells(RngFind.Row, 33 + intL) = CDbl(Me.Controls ("TbxProPvc1" &
> > > > Format(CStr(intL), "00"))) <<--- Génère l'erreur
> > > > If Err.Number <> 0 Then
> > > > MsgBox "Donnée incorrecte.", vbExclamation + vbOKOnly,
> > > > ETPP_NomApplication
> > > > Me.Controls("TbxProPvc1" & Format(CStr(intL),"00")).SetFocus
> > > > GoTo Restituer_Fin
> > > > End If
> > > > Next intL
> > > > L'interception d'erreur n'est la que au cas où!
> > > > En effet, sans le On Error Resume Next, le code se déroule sans
> > > > problème, du fait que je réalise le maximum de vérification en amont.
> > > > Pas de plantage et cependant, l'objet Err prend la valeur 9 - L'indice
> > > > n'appartient pas à la sélection.
> > > > Ma question: Pourquoi le code ne plante alors que l'objet Err restitue
> > > > un code erreur?
> > > > Si vous avez des idées je suis preneur.
> > > > D'avance merci et bon
...
plus de détails »- Masquer le texte des messages précédents -
- Afficher le texte des messages précédents -
utilise la commande DoEvents après la commande de chargement
Deuxièmement, il faut faire attention d'appeler une commande
avant de lancer la fermeture d'un formulaire. Inverser ces 2 lignes
de code n'est pas une bonne idée...;-)
Tu peux utiliser des variables dans tes procédures à des endroits cri tiques
Ton cheminement est en Access...
Mais à chaque fois que tu t'amuses à ouvrir et fermer des formulaires
utilise la commande DoEvents après la commande de chargement
d'un formulaire ou après la libération du formulaire...afin de
t'assurer que toutes les opérations seront exécutées.
Deuxièmement, il faut faire attention d'appeler une commande
avant de lancer la fermeture d'un formulaire. Inverser ces 2 lignes
de code n'est pas une bonne idée...;-)
Tu peux utiliser des variables dans tes procédures à des endroits cri tiques
que tu fais afficher dans la boîte "Exécution" de la fenêtre de l' éditeur de code.
Tu utilises la commande Debug.Print MaVariable
"ElXav" a écrit dans le message de groupe de discussion :
Voui, merci, j'ai connaissance des différentes techniques :-)
Ceci étant, bingo comme disent certains.
J'ai trouvé.
En ré-analysant plus précisément l'enchainement des traitements, j' ai
de nouveau confirmation qu'en mode pas à pas, certains évènements n e
sont pas tracés, on n'y saute pas... Totalement transparent... Super
simple pour pister des anomalies.
Je l'avais constaté sous XP, et même jusqu'à l'ordre des évènem ents
qui n'était pas identique en debug et en exécution normale.
Or donc, voici le cheminement:
Ouverture Form1 (qui est un menu principal)
Form_Activate
Appel à ma fonction InitCodeCentraleTraitée() dans laquelle
j'ai mon problème et retour Ok
Clique sur un bouton pour ouvrir Form2
Form2_OnLoad
Call Routine1
Dans Routine1
Set FrmAttenteTrait (Variable public déclaré dans un module) = New
Form_AttenteTraitements
et plus loin mais conditionné par certains paramètre
Set Frd = ... Initialisation d'un recordset. Cette ligne à ce
moment là n'est pas exécuté. Frd est donc non initialisé
Clique sur un bouton pour fermer Form2 (par un Docmd.Close...)
Form_Close de Form2
Call Routine2
Dans Routine2
Set FrmAttenteTrait = Nothing ce qui provoque la fermeture du
formulaire AttenteTraitements
Dans Form_Close de AttenteTraitements
On Error Resume Next
Frd.Close
Set Frd = Nothing
C'est ici que l'erreur 91 est généré si Frd n'est pas initialisé (dans
le cas présent, c'est le cas).
Continuons....
Les formulaire AttenteTraitements et Form2 étant fermé, Form1 reçoi t
le focus, et relance l'appel à ma fonction.
Jusque là rien d'anormal.
Ce qui est curieux, c'est que cette fameuse erreur déclenchant à la
fermeture de AttenteTraitements est sensée être effacé par Err.Clea r
juste avant le Set dans ma fonction, laquelle fonction est appelée
lorsque mon formulaire principal reprend le focus, donc à ce stade,
les deux autres formulaires sont fermés, et leur code devrait être
terminé.
Je sais difficile à suivre. :-/
Se peut-il que pendant l'exécution du code Form_Close de mon
formulaire AttenteTraitements sous encore en cours alors que mon
formulaire reçoit le focus et déclenche dont son propre évènement
Activate?
En tout cas, encore merci pour vos suggestions.
Cordialement.
On 9 avr, 15:40, "michdenis" wrote:
> Si tu veux faire une gestion d'erreur efficace :
> '-----------------------------------
> Sub MaProcédure()
> Dim Gestion_Erreur As String
> On Error Goto Gestion_Erreur
> Ton code
> Exit sub
> Gestion_Erreur:
> Msgbox Err.Number & ", " & Err.Description
> 'pour reprendre à la ligne suivante de code où
> 'l'erreur s'est produite.
> Resume next
> End Sub
> '-----------------------------------
> Si tu sais les numéros d'erreur que ta procédure peut provoquer
> tu peux faire : (numéro d'erreur pris au hasard.
> Gestion_Erreur:
> Select case Err.Number
> Case 91
> 'ce que tu veux faire si ça se produit
> Case 125
> 'ce que tu veux faire si ça se produit
> Case else
> End Select
> Il faut utiliser son jugement si on doit ajouter la ligne "Resume next"
> Certains types d'erreur peut rendre le cheminement de la macro
> impossible ou provoquer un résultat erroné. Il faut mieux afficher
> un message et mettre fin à la procédure.
> "ElXav" a écrit dans le message de groupe de discussi on :
>
> Bonjour Jex, Michdenis,
> D'accord avec vous, je m'y astreins depuis un moment déjà.
> J'ai pour l'instant 2 problèmes similaires.
> L'un dans un classeur Excel développé l'année dernière, l'autre dans
> une base Access qui est passé par les versions 2, 95, 97, et
> maintenant 2007.
> A chaque migration, il m'aura fallu mettre quelques verrues afin de
> contourner divers problèmes.
> Pour l'heure, j'aimerais comprendre pourquoi l'objet Err se trouve
> affecté par une erreur alors que le code ne plante pas si l'on enlè ve
> l'interception d'erreur.
> Pour la partie Access, en pas à pas, depuis le clic qui ferme un
> formulaire, et jusqu'à ma fonction, aucune interception d'erreur n'es t
> activée.
> Si je supprime le On Error Resume Next, je n'obtiens pas de plantage,
> mon test Err.Number <> 0 est positif avec le code 91, et le recordset
> se trouve bien chargé!!
> Le tout résolu par un DoEvents en amont de ma fonction...
> Dans Excel, j'ai entrepris la même démarche, pas à pas, et je ne passe
> pas par des procédures évènementiels inopinées.
> Sans le On Error, le code se déroule parfaitement bien, le résultat
> est correctn et pourtant Err.Number récupère une valeur différent e de
> zéro.
> Comme d'hab, face a ce type de problème, je perds la boule ;-/
> Je ne comprends pas pourquoi Err rescense une erreur, surtout une
> erreur entrainant normalement l'arrêt du code, alors que celui-ci
> fonctionne.
> Question subsidiaire afin de valider ou non le fonctionnement du On
> Error que j'ai en tête, après une relecture de l'aide en ligne.
> Lorsqu'un On Error Goto est exécuté, on est bien d'accord qu'il est
> actif le temps que tous le code devant être déroulé le soit?
> Soit:
> 1) Si clic sur un bouton, la procédure évènementielle dé marre.
> 2) On peut imaginer un ou plusieurs On Error Goto/Resume dans
> différentes procédures et fonction appelées.
> 3) Lorsque la procédure évènementielle liée au clic se t ermine,
> tous les On Error Goto/Resume devienne "caduque".
> 4) Si on lance une nouvelle procédure ou fonction dans laquell e
> aucun On Error n'est présent, et qu'une ligne génère une erreur 9 1 ou
> 9 (variable / objet non défini, et indice hors limite), le code doit
> planter, et Err.Number retourne cette valeur.
> Si le 4 est vrai, pourquoi n'ai-j pas ce comportement?? :-/
> Merci quand même pour vos conseils.
> Si vous entrevoyez une explication...
> Cordialement.
> Xavier.
> On 9 avr, 11:03, Jex wrote:
> > Bonjour,
> > Tout à fait d'accord avec michdenis, il vaut mieux préfixer ce ty pe de
> > variable (recordset) par le nom de la bibliothèque.
> > Sinon, il faut vérifier que toutes les bibliothèques du projet so ient
> > présentes, aussi bien en Excel qu'en Access.
> > Dans Excel : Outils / Références.
> > Si un objet est marqué comme MANQUANT, il faut le décocher.
> > D'autre part, il se peut que la bibliothèque des objets de
> > l'application ne soit pas présente (DAO ou Microsoft Office xxx), i l
> > faut alors la rajouter.
> > Bonne suite.
> > On 8 avr, 19:42, "michdenis" wrote:
> > > Bonjour,
> > > Je n'ai pas l'environnement pour tester ta procédure, mais c'est
> > > toujours une bonne idée d'être précis lorsqu'il s'agit de d éclarer
> > > les variables
> > > Je modifierais volontiers ceci
> > > Dim frd As Recordset
> > > Pour
> > > Dim frd As Dao.Recordset
> > > Juste pour éviter une méprise possible si tu as aussi dans ton projet
> > > la bibliothèque ADO de déclarer.
> > > "ElXav" a écrit dans le message de groupe de disc ussion :
> > >
> > > Bonjour Daniel,
> > > Ooops, je n'ai pas posté dans le bon forum.
> > > J'ai déjà posé la question ici, concernant la partie Excel, e t oui,
> > > tout le code Excel est bon, les textbox cible existent.
> > >http://groups.google.com/group/microsoft.public.fr.excel/browse_thre a...
> > > A tel point, comme je l'explique, en retirant l'interception d'erre ur,
> > > le code ne plante pas, et l'objet Err prend la valeur indiquée da ns
> > > mon post.
> > > Si tu as des idées...
> > > Merci.
> > > Cordialement.
> > > On 8 avr, 16:08, Daniel.C wrote:
> > > > Bonjour.
> > > > Es-tu sûr d'avoir un textbox nommé TbxProPvc115 ?
> > > > Daniel
> > > > > Bonjour la Communauté,
> > > > > Migré depuis peu de Office XP vers Office 2007 SP2, j'ai quel ques
> > > > > soucis avec mes applis Access et Excel.
> > > > > Celles-ci fonctionnent trés bien sous XP, mais sous 2007, j'o btiens
> > > > > des codes erreur dans l'objet Err, alors que le code ne se plan te pas
> > > > > même en désactivant le contrôle d'erreur!!
> > > > > Or donc, le code listé ci-dessous est là pour:
> > > > > - Créer un RecordSet basé sur le contenu d'une table at tachée
> > > > > contenant un seul enregistrement.
> > > > > Cette table attachée peut ne plus être valide, ce q ui est normal
> > > > > dans le cadre de l'exploitation de cette base.
> > > > > Donc
> > > > > - Si la création du RecordSet génère une erreur, il e st probable que
> > > > > la table attachée ne soit plus valide (lien rompu), dans ce c as,
> > > > > j'alerte l'utilisateur et le dirige vers un formulaire permetta nt de
> > > > > rétablir tous les liens de la base de données
> > > > > - Si la création du RecordSet ne génère pas d'erreur, je traite
> > > > > l'enregistrement.
> > > > > D'où le code
...
plus de détails »- Masquer le texte des messages précédents -
- Afficher le texte des messages précédents -
utilise la commande DoEvents après la commande de chargement
Deuxièmement, il faut faire attention d'appeler une commande
avant de lancer la fermeture d'un formulaire. Inverser ces 2 lignes
de code n'est pas une bonne idée...;-)
Tu peux utiliser des variables dans tes procédures à des endroits cri tiques
Ton cheminement est en Access...
Mais à chaque fois que tu t'amuses à ouvrir et fermer des formulaires
utilise la commande DoEvents après la commande de chargement
d'un formulaire ou après la libération du formulaire...afin de
t'assurer que toutes les opérations seront exécutées.
Deuxièmement, il faut faire attention d'appeler une commande
avant de lancer la fermeture d'un formulaire. Inverser ces 2 lignes
de code n'est pas une bonne idée...;-)
Tu peux utiliser des variables dans tes procédures à des endroits cri tiques
que tu fais afficher dans la boîte "Exécution" de la fenêtre de l' éditeur de code.
Tu utilises la commande Debug.Print MaVariable
"ElXav" <el...@free.fr> a écrit dans le message de groupe de discussion :
c478ebd0-5d4a-4a5a-b8ac-b0d58ef83...@z11g2000yqz.googlegroups.com...
Voui, merci, j'ai connaissance des différentes techniques :-)
Ceci étant, bingo comme disent certains.
J'ai trouvé.
En ré-analysant plus précisément l'enchainement des traitements, j' ai
de nouveau confirmation qu'en mode pas à pas, certains évènements n e
sont pas tracés, on n'y saute pas... Totalement transparent... Super
simple pour pister des anomalies.
Je l'avais constaté sous XP, et même jusqu'à l'ordre des évènem ents
qui n'était pas identique en debug et en exécution normale.
Or donc, voici le cheminement:
Ouverture Form1 (qui est un menu principal)
Form_Activate
Appel à ma fonction InitCodeCentraleTraitée() dans laquelle
j'ai mon problème et retour Ok
Clique sur un bouton pour ouvrir Form2
Form2_OnLoad
Call Routine1
Dans Routine1
Set FrmAttenteTrait (Variable public déclaré dans un module) = New
Form_AttenteTraitements
et plus loin mais conditionné par certains paramètre
Set Frd = ... Initialisation d'un recordset. Cette ligne à ce
moment là n'est pas exécuté. Frd est donc non initialisé
Clique sur un bouton pour fermer Form2 (par un Docmd.Close...)
Form_Close de Form2
Call Routine2
Dans Routine2
Set FrmAttenteTrait = Nothing ce qui provoque la fermeture du
formulaire AttenteTraitements
Dans Form_Close de AttenteTraitements
On Error Resume Next
Frd.Close
Set Frd = Nothing
C'est ici que l'erreur 91 est généré si Frd n'est pas initialisé (dans
le cas présent, c'est le cas).
Continuons....
Les formulaire AttenteTraitements et Form2 étant fermé, Form1 reçoi t
le focus, et relance l'appel à ma fonction.
Jusque là rien d'anormal.
Ce qui est curieux, c'est que cette fameuse erreur déclenchant à la
fermeture de AttenteTraitements est sensée être effacé par Err.Clea r
juste avant le Set dans ma fonction, laquelle fonction est appelée
lorsque mon formulaire principal reprend le focus, donc à ce stade,
les deux autres formulaires sont fermés, et leur code devrait être
terminé.
Je sais difficile à suivre. :-/
Se peut-il que pendant l'exécution du code Form_Close de mon
formulaire AttenteTraitements sous encore en cours alors que mon
formulaire reçoit le focus et déclenche dont son propre évènement
Activate?
En tout cas, encore merci pour vos suggestions.
Cordialement.
On 9 avr, 15:40, "michdenis" <michde...@hotmail.com> wrote:
> Si tu veux faire une gestion d'erreur efficace :
> '-----------------------------------
> Sub MaProcédure()
> Dim Gestion_Erreur As String
> On Error Goto Gestion_Erreur
> Ton code
> Exit sub
> Gestion_Erreur:
> Msgbox Err.Number & ", " & Err.Description
> 'pour reprendre à la ligne suivante de code où
> 'l'erreur s'est produite.
> Resume next
> End Sub
> '-----------------------------------
> Si tu sais les numéros d'erreur que ta procédure peut provoquer
> tu peux faire : (numéro d'erreur pris au hasard.
> Gestion_Erreur:
> Select case Err.Number
> Case 91
> 'ce que tu veux faire si ça se produit
> Case 125
> 'ce que tu veux faire si ça se produit
> Case else
> End Select
> Il faut utiliser son jugement si on doit ajouter la ligne "Resume next"
> Certains types d'erreur peut rendre le cheminement de la macro
> impossible ou provoquer un résultat erroné. Il faut mieux afficher
> un message et mettre fin à la procédure.
> "ElXav" <el...@free.fr> a écrit dans le message de groupe de discussi on :
> c6baea8f-2043-4389-99ab-355687bc8...@b23g2000yqn.googlegroups.com...
> Bonjour Jex, Michdenis,
> D'accord avec vous, je m'y astreins depuis un moment déjà.
> J'ai pour l'instant 2 problèmes similaires.
> L'un dans un classeur Excel développé l'année dernière, l'autre dans
> une base Access qui est passé par les versions 2, 95, 97, et
> maintenant 2007.
> A chaque migration, il m'aura fallu mettre quelques verrues afin de
> contourner divers problèmes.
> Pour l'heure, j'aimerais comprendre pourquoi l'objet Err se trouve
> affecté par une erreur alors que le code ne plante pas si l'on enlè ve
> l'interception d'erreur.
> Pour la partie Access, en pas à pas, depuis le clic qui ferme un
> formulaire, et jusqu'à ma fonction, aucune interception d'erreur n'es t
> activée.
> Si je supprime le On Error Resume Next, je n'obtiens pas de plantage,
> mon test Err.Number <> 0 est positif avec le code 91, et le recordset
> se trouve bien chargé!!
> Le tout résolu par un DoEvents en amont de ma fonction...
> Dans Excel, j'ai entrepris la même démarche, pas à pas, et je ne passe
> pas par des procédures évènementiels inopinées.
> Sans le On Error, le code se déroule parfaitement bien, le résultat
> est correctn et pourtant Err.Number récupère une valeur différent e de
> zéro.
> Comme d'hab, face a ce type de problème, je perds la boule ;-/
> Je ne comprends pas pourquoi Err rescense une erreur, surtout une
> erreur entrainant normalement l'arrêt du code, alors que celui-ci
> fonctionne.
> Question subsidiaire afin de valider ou non le fonctionnement du On
> Error que j'ai en tête, après une relecture de l'aide en ligne.
> Lorsqu'un On Error Goto est exécuté, on est bien d'accord qu'il est
> actif le temps que tous le code devant être déroulé le soit?
> Soit:
> 1) Si clic sur un bouton, la procédure évènementielle dé marre.
> 2) On peut imaginer un ou plusieurs On Error Goto/Resume dans
> différentes procédures et fonction appelées.
> 3) Lorsque la procédure évènementielle liée au clic se t ermine,
> tous les On Error Goto/Resume devienne "caduque".
> 4) Si on lance une nouvelle procédure ou fonction dans laquell e
> aucun On Error n'est présent, et qu'une ligne génère une erreur 9 1 ou
> 9 (variable / objet non défini, et indice hors limite), le code doit
> planter, et Err.Number retourne cette valeur.
> Si le 4 est vrai, pourquoi n'ai-j pas ce comportement?? :-/
> Merci quand même pour vos conseils.
> Si vous entrevoyez une explication...
> Cordialement.
> Xavier.
> On 9 avr, 11:03, Jex <jacques_ast...@hotmail.com> wrote:
> > Bonjour,
> > Tout à fait d'accord avec michdenis, il vaut mieux préfixer ce ty pe de
> > variable (recordset) par le nom de la bibliothèque.
> > Sinon, il faut vérifier que toutes les bibliothèques du projet so ient
> > présentes, aussi bien en Excel qu'en Access.
> > Dans Excel : Outils / Références.
> > Si un objet est marqué comme MANQUANT, il faut le décocher.
> > D'autre part, il se peut que la bibliothèque des objets de
> > l'application ne soit pas présente (DAO ou Microsoft Office xxx), i l
> > faut alors la rajouter.
> > Bonne suite.
> > On 8 avr, 19:42, "michdenis" <michde...@hotmail.com> wrote:
> > > Bonjour,
> > > Je n'ai pas l'environnement pour tester ta procédure, mais c'est
> > > toujours une bonne idée d'être précis lorsqu'il s'agit de d éclarer
> > > les variables
> > > Je modifierais volontiers ceci
> > > Dim frd As Recordset
> > > Pour
> > > Dim frd As Dao.Recordset
> > > Juste pour éviter une méprise possible si tu as aussi dans ton projet
> > > la bibliothèque ADO de déclarer.
> > > "ElXav" <el...@free.fr> a écrit dans le message de groupe de disc ussion :
> > > 839c29df-5594-4d03-9db4-6522e1dc8...@e7g2000yqf.googlegroups.com...
> > > Bonjour Daniel,
> > > Ooops, je n'ai pas posté dans le bon forum.
> > > J'ai déjà posé la question ici, concernant la partie Excel, e t oui,
> > > tout le code Excel est bon, les textbox cible existent.
> > >http://groups.google.com/group/microsoft.public.fr.excel/browse_thre a...
> > > A tel point, comme je l'explique, en retirant l'interception d'erre ur,
> > > le code ne plante pas, et l'objet Err prend la valeur indiquée da ns
> > > mon post.
> > > Si tu as des idées...
> > > Merci.
> > > Cordialement.
> > > On 8 avr, 16:08, Daniel.C <dcolardelle...@gmail.com> wrote:
> > > > Bonjour.
> > > > Es-tu sûr d'avoir un textbox nommé TbxProPvc115 ?
> > > > Daniel
> > > > > Bonjour la Communauté,
> > > > > Migré depuis peu de Office XP vers Office 2007 SP2, j'ai quel ques
> > > > > soucis avec mes applis Access et Excel.
> > > > > Celles-ci fonctionnent trés bien sous XP, mais sous 2007, j'o btiens
> > > > > des codes erreur dans l'objet Err, alors que le code ne se plan te pas
> > > > > même en désactivant le contrôle d'erreur!!
> > > > > Or donc, le code listé ci-dessous est là pour:
> > > > > - Créer un RecordSet basé sur le contenu d'une table at tachée
> > > > > contenant un seul enregistrement.
> > > > > Cette table attachée peut ne plus être valide, ce q ui est normal
> > > > > dans le cadre de l'exploitation de cette base.
> > > > > Donc
> > > > > - Si la création du RecordSet génère une erreur, il e st probable que
> > > > > la table attachée ne soit plus valide (lien rompu), dans ce c as,
> > > > > j'alerte l'utilisateur et le dirige vers un formulaire permetta nt de
> > > > > rétablir tous les liens de la base de données
> > > > > - Si la création du RecordSet ne génère pas d'erreur, je traite
> > > > > l'enregistrement.
> > > > > D'où le code
...
plus de détails »- Masquer le texte des messages précédents -
- Afficher le texte des messages précédents -
utilise la commande DoEvents après la commande de chargement
Deuxièmement, il faut faire attention d'appeler une commande
avant de lancer la fermeture d'un formulaire. Inverser ces 2 lignes
de code n'est pas une bonne idée...;-)
Tu peux utiliser des variables dans tes procédures à des endroits cri tiques
Ton cheminement est en Access...
Mais à chaque fois que tu t'amuses à ouvrir et fermer des formulaires
utilise la commande DoEvents après la commande de chargement
d'un formulaire ou après la libération du formulaire...afin de
t'assurer que toutes les opérations seront exécutées.
Deuxièmement, il faut faire attention d'appeler une commande
avant de lancer la fermeture d'un formulaire. Inverser ces 2 lignes
de code n'est pas une bonne idée...;-)
Tu peux utiliser des variables dans tes procédures à des endroits cri tiques
que tu fais afficher dans la boîte "Exécution" de la fenêtre de l' éditeur de code.
Tu utilises la commande Debug.Print MaVariable
"ElXav" a écrit dans le message de groupe de discussion :
Voui, merci, j'ai connaissance des différentes techniques :-)
Ceci étant, bingo comme disent certains.
J'ai trouvé.
En ré-analysant plus précisément l'enchainement des traitements, j' ai
de nouveau confirmation qu'en mode pas à pas, certains évènements n e
sont pas tracés, on n'y saute pas... Totalement transparent... Super
simple pour pister des anomalies.
Je l'avais constaté sous XP, et même jusqu'à l'ordre des évènem ents
qui n'était pas identique en debug et en exécution normale.
Or donc, voici le cheminement:
Ouverture Form1 (qui est un menu principal)
Form_Activate
Appel à ma fonction InitCodeCentraleTraitée() dans laquelle
j'ai mon problème et retour Ok
Clique sur un bouton pour ouvrir Form2
Form2_OnLoad
Call Routine1
Dans Routine1
Set FrmAttenteTrait (Variable public déclaré dans un module) = New
Form_AttenteTraitements
et plus loin mais conditionné par certains paramètre
Set Frd = ... Initialisation d'un recordset. Cette ligne à ce
moment là n'est pas exécuté. Frd est donc non initialisé
Clique sur un bouton pour fermer Form2 (par un Docmd.Close...)
Form_Close de Form2
Call Routine2
Dans Routine2
Set FrmAttenteTrait = Nothing ce qui provoque la fermeture du
formulaire AttenteTraitements
Dans Form_Close de AttenteTraitements
On Error Resume Next
Frd.Close
Set Frd = Nothing
C'est ici que l'erreur 91 est généré si Frd n'est pas initialisé (dans
le cas présent, c'est le cas).
Continuons....
Les formulaire AttenteTraitements et Form2 étant fermé, Form1 reçoi t
le focus, et relance l'appel à ma fonction.
Jusque là rien d'anormal.
Ce qui est curieux, c'est que cette fameuse erreur déclenchant à la
fermeture de AttenteTraitements est sensée être effacé par Err.Clea r
juste avant le Set dans ma fonction, laquelle fonction est appelée
lorsque mon formulaire principal reprend le focus, donc à ce stade,
les deux autres formulaires sont fermés, et leur code devrait être
terminé.
Je sais difficile à suivre. :-/
Se peut-il que pendant l'exécution du code Form_Close de mon
formulaire AttenteTraitements sous encore en cours alors que mon
formulaire reçoit le focus et déclenche dont son propre évènement
Activate?
En tout cas, encore merci pour vos suggestions.
Cordialement.
On 9 avr, 15:40, "michdenis" wrote:
> Si tu veux faire une gestion d'erreur efficace :
> '-----------------------------------
> Sub MaProcédure()
> Dim Gestion_Erreur As String
> On Error Goto Gestion_Erreur
> Ton code
> Exit sub
> Gestion_Erreur:
> Msgbox Err.Number & ", " & Err.Description
> 'pour reprendre à la ligne suivante de code où
> 'l'erreur s'est produite.
> Resume next
> End Sub
> '-----------------------------------
> Si tu sais les numéros d'erreur que ta procédure peut provoquer
> tu peux faire : (numéro d'erreur pris au hasard.
> Gestion_Erreur:
> Select case Err.Number
> Case 91
> 'ce que tu veux faire si ça se produit
> Case 125
> 'ce que tu veux faire si ça se produit
> Case else
> End Select
> Il faut utiliser son jugement si on doit ajouter la ligne "Resume next"
> Certains types d'erreur peut rendre le cheminement de la macro
> impossible ou provoquer un résultat erroné. Il faut mieux afficher
> un message et mettre fin à la procédure.
> "ElXav" a écrit dans le message de groupe de discussi on :
>
> Bonjour Jex, Michdenis,
> D'accord avec vous, je m'y astreins depuis un moment déjà.
> J'ai pour l'instant 2 problèmes similaires.
> L'un dans un classeur Excel développé l'année dernière, l'autre dans
> une base Access qui est passé par les versions 2, 95, 97, et
> maintenant 2007.
> A chaque migration, il m'aura fallu mettre quelques verrues afin de
> contourner divers problèmes.
> Pour l'heure, j'aimerais comprendre pourquoi l'objet Err se trouve
> affecté par une erreur alors que le code ne plante pas si l'on enlè ve
> l'interception d'erreur.
> Pour la partie Access, en pas à pas, depuis le clic qui ferme un
> formulaire, et jusqu'à ma fonction, aucune interception d'erreur n'es t
> activée.
> Si je supprime le On Error Resume Next, je n'obtiens pas de plantage,
> mon test Err.Number <> 0 est positif avec le code 91, et le recordset
> se trouve bien chargé!!
> Le tout résolu par un DoEvents en amont de ma fonction...
> Dans Excel, j'ai entrepris la même démarche, pas à pas, et je ne passe
> pas par des procédures évènementiels inopinées.
> Sans le On Error, le code se déroule parfaitement bien, le résultat
> est correctn et pourtant Err.Number récupère une valeur différent e de
> zéro.
> Comme d'hab, face a ce type de problème, je perds la boule ;-/
> Je ne comprends pas pourquoi Err rescense une erreur, surtout une
> erreur entrainant normalement l'arrêt du code, alors que celui-ci
> fonctionne.
> Question subsidiaire afin de valider ou non le fonctionnement du On
> Error que j'ai en tête, après une relecture de l'aide en ligne.
> Lorsqu'un On Error Goto est exécuté, on est bien d'accord qu'il est
> actif le temps que tous le code devant être déroulé le soit?
> Soit:
> 1) Si clic sur un bouton, la procédure évènementielle dé marre.
> 2) On peut imaginer un ou plusieurs On Error Goto/Resume dans
> différentes procédures et fonction appelées.
> 3) Lorsque la procédure évènementielle liée au clic se t ermine,
> tous les On Error Goto/Resume devienne "caduque".
> 4) Si on lance une nouvelle procédure ou fonction dans laquell e
> aucun On Error n'est présent, et qu'une ligne génère une erreur 9 1 ou
> 9 (variable / objet non défini, et indice hors limite), le code doit
> planter, et Err.Number retourne cette valeur.
> Si le 4 est vrai, pourquoi n'ai-j pas ce comportement?? :-/
> Merci quand même pour vos conseils.
> Si vous entrevoyez une explication...
> Cordialement.
> Xavier.
> On 9 avr, 11:03, Jex wrote:
> > Bonjour,
> > Tout à fait d'accord avec michdenis, il vaut mieux préfixer ce ty pe de
> > variable (recordset) par le nom de la bibliothèque.
> > Sinon, il faut vérifier que toutes les bibliothèques du projet so ient
> > présentes, aussi bien en Excel qu'en Access.
> > Dans Excel : Outils / Références.
> > Si un objet est marqué comme MANQUANT, il faut le décocher.
> > D'autre part, il se peut que la bibliothèque des objets de
> > l'application ne soit pas présente (DAO ou Microsoft Office xxx), i l
> > faut alors la rajouter.
> > Bonne suite.
> > On 8 avr, 19:42, "michdenis" wrote:
> > > Bonjour,
> > > Je n'ai pas l'environnement pour tester ta procédure, mais c'est
> > > toujours une bonne idée d'être précis lorsqu'il s'agit de d éclarer
> > > les variables
> > > Je modifierais volontiers ceci
> > > Dim frd As Recordset
> > > Pour
> > > Dim frd As Dao.Recordset
> > > Juste pour éviter une méprise possible si tu as aussi dans ton projet
> > > la bibliothèque ADO de déclarer.
> > > "ElXav" a écrit dans le message de groupe de disc ussion :
> > >
> > > Bonjour Daniel,
> > > Ooops, je n'ai pas posté dans le bon forum.
> > > J'ai déjà posé la question ici, concernant la partie Excel, e t oui,
> > > tout le code Excel est bon, les textbox cible existent.
> > >http://groups.google.com/group/microsoft.public.fr.excel/browse_thre a...
> > > A tel point, comme je l'explique, en retirant l'interception d'erre ur,
> > > le code ne plante pas, et l'objet Err prend la valeur indiquée da ns
> > > mon post.
> > > Si tu as des idées...
> > > Merci.
> > > Cordialement.
> > > On 8 avr, 16:08, Daniel.C wrote:
> > > > Bonjour.
> > > > Es-tu sûr d'avoir un textbox nommé TbxProPvc115 ?
> > > > Daniel
> > > > > Bonjour la Communauté,
> > > > > Migré depuis peu de Office XP vers Office 2007 SP2, j'ai quel ques
> > > > > soucis avec mes applis Access et Excel.
> > > > > Celles-ci fonctionnent trés bien sous XP, mais sous 2007, j'o btiens
> > > > > des codes erreur dans l'objet Err, alors que le code ne se plan te pas
> > > > > même en désactivant le contrôle d'erreur!!
> > > > > Or donc, le code listé ci-dessous est là pour:
> > > > > - Créer un RecordSet basé sur le contenu d'une table at tachée
> > > > > contenant un seul enregistrement.
> > > > > Cette table attachée peut ne plus être valide, ce q ui est normal
> > > > > dans le cadre de l'exploitation de cette base.
> > > > > Donc
> > > > > - Si la création du RecordSet génère une erreur, il e st probable que
> > > > > la table attachée ne soit plus valide (lien rompu), dans ce c as,
> > > > > j'alerte l'utilisateur et le dirige vers un formulaire permetta nt de
> > > > > rétablir tous les liens de la base de données
> > > > > - Si la création du RecordSet ne génère pas d'erreur, je traite
> > > > > l'enregistrement.
> > > > > D'où le code
...
plus de détails »- Masquer le texte des messages précédents -
- Afficher le texte des messages précédents -
Deuxièmement, il faut faire attention d'appeler une commande
avant de lancer la fermeture d'un formulaire. Inverser ces 2 lignes
de code n'est pas une bonne idée...;-)
Deuxièmement, il faut faire attention d'appeler une commande
avant de lancer la fermeture d'un formulaire. Inverser ces 2 lignes
de code n'est pas une bonne idée...;-)
Deuxièmement, il faut faire attention d'appeler une commande
avant de lancer la fermeture d'un formulaire. Inverser ces 2 lignes
de code n'est pas une bonne idée...;-)