Discussion :

[harpyopsis]

Bonjour tout le monde !

Dans une BD multilingue, j'ai de nombreuses tables de compta comportant un champ "PaymentModeID"

La valeur PaymentModeID vient d'une petite table-outil / lookup "tbPaymentModes" où les modes de paiement sont exprimés en cinq langues dans cinq colonnes-texte : PaymentModeFra, PaymentModeEng, PaymentModeNed,...

Dans tous les formulaires en mode continu, le changement en mode exécution par VBA du ControlSource de la zone texte "txtPaymentMode" de PaymentModeFra, PaymentModeEng, PaymentModeNed se passe nickel à chaque changement de langue.

Il n'en va pas de même avec les états. (Fallait s'en douter !)

Sur une dizaine d'états comportant ce champ "tbPaymentModes", neuf fonctionnent nickel, mais il y en a un qui cafouille, je ne comprends pas pourquoi !!!

Toutes les conditions sont absolument comparables, et le code VBA est identique !!!

Le RecordSource de l'état est soit une chaine SQL, soit le nom d'une QueryDef générée en temps réel par le bouton d'ouverture de l'état dans un formulaire.

Le ControlSource de la zone-texte est fixé dès l'ouverture de l'état, donc bien avant OnFormat, bien avant que les données soient chargées.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
Private Sub Report_Open(Cancel As Integer)
    If CrtLanguageID = 1 Then
        Me.txtPaymentMode.ControlSource = "PaymentModeFra"
    ElseIf CrtLanguageID = 2Then
        Me.txtPaymentMode.ControlSource = "PaymentModeEng"
    'etc
    End If
end sub

Eh bien dans ce foutu état, (que j’ai déjà complètement reconstruit from scratch deux fois), Access mouline quelques secondes, et plante sans aucun message d'erreur ! Idem sur plusieurs machines.

Quelqu'un a-t-il déjà vu ça ??? Je me creuse la tête pour identifier la cause, mais je ne trouve pas. Je me demande s'il ne faudrait pas passer à Access 2010 !

Merci d'avance pour vos suggestions éclairées !

phil

[Zekraoui_Jakani]

Essayez la fonction DLookUp:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Me.txtPaymentMode = DLookUp("[xyz]","[tbPaymentModes]","[PaymentModeID]=" & j)

où xyz représente le nom du champ contenant les modes de paiement
et j est la variable allant de 1 à 10, fournie par votre fonction.

[harpyopsis]

Bonsoir et merci !

Je suis en train d'essayer avec DLookUp mais ça plante toujours...

Vous dites :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
Me.txtPaymentMode = DLookUp("[xyz]","[tbPaymentModes]","[PaymentModeID]=" & j)

Voulez-vous dire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
Me.txtPaymentMode.Controlsource = DLookUp("[xyz]","[tbPaymentModes]","[PaymentModeID]=" & j)
'ou bien
Me.txtPaymentMode.value = DLookUp("[xyz]","[tbPaymentModes]","[PaymentModeID]=" & j)

...car txtPaymentMode est bien une zone texte liée, dans la section Détail, qui doit faire apparaitre les mots soit "Espèces", soit "Cash", soit "Geld", etc... selon le ControlSource que lui a attribué le code VBA OnOpen...

[Paraffine]

Puisque cet état est le seul qui pose problème avec ce code VBA : es-tu certain que le problème est lié à cette procédure ?
As-tu essayé de lancer l'état en supprimant le code VBA dans l'OpenReport, pour voir (avec une valeur "fixe" dans ControlSource) ?

[harpyopsis]

Oui, dès que je supprime

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

'Me.txtPaymentMode.ControlSource = "PaymentModeFra"

tout le reste fonctionne normalement. L'état apparait tout de suite correctement : bien filtré, les devises converties (Rupiah), dans la langue correcte, sauf naturellement cette zone texte "txtPaymentMode" qui n'aura pas changé de langue...

J'en perds mon latin...

[Paraffine]

Si je comprends bien ça ne plante pas quand txtPaymentMode conserve le ControlSource par défaut ?
Mais puisque ton état en mode création affiche déjà PaymentModeFra comme ControlSource, j'ai du mal à comprendre comment inhiber Me.txtPaymentMode.ControlSource = "PaymentModeFra" pourrait faire une différence ? Ou bien dois-tu l'afficher dans une autre langue ?
As-tu essayé en mettant dans ton état toutes les colonnes "linguistiques" des modes de paiement ? Puis en supprimant l'une après l'autre si cela plante ?
Après, quand la logique n'a plus de recours (la requête est OK avec toutes ses colonnes multilingues, le code est OK), avant le prêtre vaudou, il reste le decompile .

[Zekraoui_Jakani]

Je confirme: M

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

e.txtPaymentMode.value = DLookUp("[xyz]","[tbPaymentModes]","[PaymentModeID]=" & j)

ou

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Me.txtPaymentMode = DLookUp("[xyz]","[tbPaymentModes]","[PaymentModeID]=" & j)

Mais je me demande s'il n'y a pas conflit entre la propriété "CtrlSource" du champ et l'instruction ci-dessus.
Je m'explique: si vous forcez la valeur de CtrlSource via VBA, alors il faudra vous assurer que la propriété "CtrlSource" du champ txtPaymentMode est VIDE; autrement vba bloque l'édition du ctrlSource.
Autrement dit, VBA ne peut modifier CtrlSource que si cette même propriété du champ n'est pas définie.

[harpyopsis]

Si je comprends bien ça ne plante pas quand txtPaymentMode conserve le ControlSource par défaut ?

Exactement c'est bien ça !

Mais puisque ton état en mode création affiche déjà PaymentModeFra comme ControlSource, j'ai du mal à comprendre comment inhiber Me.txtPaymentMode.ControlSource = "PaymentModeFra" pourrait faire une différence ? Ou bien dois-tu l'afficher dans une autre langue ?

Ben oui, si l'utilisateur est néerlandophone, l'état s'ouvrira en Néerlandais, etc... et la zone texte txtPaymentMode prendra sans rechigner son nouveau ControlSource = "PaymentModeNed" au lieu de "PaymentModeFra", dès l'événement Report_Open

As-tu essayé en mettant dans ton état toutes les colonnes "linguistiques" des modes de paiement ? Puis en supprimant l'une après l'autre si cela plante ?

Oui bien sûr ! C'est d'ailleurs comme ça que j'ai commencé : avec une zone-texte pour chaque langue, que le code VBA rendait visibles ou invisibles selon la langue de l'utilisateur. Mais ça fait des empilements de zone-Textes assez lourdingues !

Puis j'ai trouvé la propriété ControlSource plus élégante et très satisfaisante avec une zone-texte unique. Mais voilà, ça marche neuf fois sur dix !!!

Je viens de réessayer en chargeant 5 zone-textes : ça marche toujours.

Après, quand la logique n'a plus de recours (la requête est OK avec toutes ses colonnes multilingues, le code est OK), avant le prêtre vaudou, il reste le decompile .

Je ne connais pas encore decompile. Je vais voir ça tout de suite ! Il n'y a rien au niveau des tables, tous les formulaires fonctionnent nickel, et tous les états sauf celui-ci. Le code est tout propre. Cela pourrait-il être une sorte de corruption dans le fichier Access ??? Je me perds en conjectures !

Un grand merci, j'espère qu'on va y arriver !!!

[Paraffine]

En fait, je voulais savoir pour quelle(s) langue(s) tu testais en priorité.
Sinon, le decompile sert à "nettoyer" des scories susceptibles de traîner dans les recoins sans qu'on puisse les voir et gripper les rouages, ce qui peut arriver à la longue.

Mais je me demande s'il n'y a pas conflit entre la propriété "CtrlSource" du champ et l'instruction ci-dessus.

As-tu essayé comme le recommande Zekraoui_Jakani en "vidant" au préalable la propriété ControlSource ou en laissant un contrôle indépendant dans le mode création du Report ?

[harpyopsis]

Je confirme: Me.txtPaymentMode.value = DLookUp("[xyz]","[tbPaymentModes]","[PaymentModeID]=" & j) ou Me.txtPaymentMode = DLookUp("[xyz]","[tbPaymentModes]","[PaymentModeID]=" & j)

Je n'ai eu aucun succès avec DLookUp. La valeur de la zone texte vient tous simplement de la requête sous-jacente, le tout est de déterminer le bon champ dans la requête...

Mais je me demande s'il n'y a pas conflit entre la propriété "CtrlSource" du champ et l'instruction ci-dessus.
Je m'explique: si vous forcez la valeur de CtrlSource via VBA, alors il faudra vous assurer que la propriété "CtrlSource" du champ txtPaymentMode est VIDE; autrement vba bloque l'édition du ctrlSource.
Autrement dit, VBA ne peut modifier CtrlSource que si cette même propriété du champ n'est pas définie.

Et bien, dans une dizaine d'états similaires qui fonctionnent parfaitement, la détermination du ControlSource durant Report_Open se passe nickel, que la zone-texte ait déjà un ControlSource par defaut ou qu'elle soit unbound (ControlSource = "").

C'est très bizarre !

[harpyopsis]

Langues : Français, Anglais, Néerlandais, Allemand et Indonésien. Heureusement aucune langue "exotique", l'Indonésien utilise l'alphabet normal et est très facile ! Le Module Dico remplit la caption des étiquettes et génère la source des combo's multilingues.

Oui effectivement : que la zone-texte possède un ControlSource de départ, ou bien qu'elle soit vide (.ControlSource ="", unbound), cela ne fait aucune différence ! Quand Access veut planter cet état particulier, il le plante dès qu'il y croise le mot "ControlSource" !

Je vais voir decompile !!!!

[harpyopsis]

Le decompile a bien fonctionné.

J'ai trouvé cette méthode assez pratique et bien décrite : https://sourcedaddy.com/ms-access/us...le-option.html

La taille du accdb est passée de 210000Ko à 99000Ko, alors qu'un simple Compact and Repair ne la ramène qu'à 140000Ko.

Mais ça plante toujours.

Je vais encore reconstruire cet état pièce par pièce. Je vous tiens au courant !

Mille fois sur le métier...

[harpyopsis]

A force de déconstruire et de reconstruire, j'ai fini par trouver !

Je n'étais pas sur la bonne piste, le ControlSource du mode de paiement en différentes langues n'était pas en cause, je l'accusais par erreur, justement parce qu'Access ne donnait AUCUN message d'erreur (pourtant sans aucun "on error resume next" dans le code).

Le bug était ailleurs dans l'état !

En fait c'était dans les Pieds de Groupes, où se trouvent des zones de textes qui font les sommes mensuelles et annuelles ainsi que le compte (nombre) des recettes.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
    Txt2.ControlSource =Sum([PaymentHT])
    Txt3.ControlSource =Sum([PaymentTVA])
    Txt4.ControlSource =Sum([PaymentTTC])

Ces trois-ci sont nickel !

Mais celle qui devait faire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

    Txt1.ControlSource =Count([RecetteID])

faisait en fait (par ma faute!)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

    Txt1.ControlSource =Count([PaymentTTC])

Ça n'a l'air de rien, et ça devrait passer... Ça passait effectivement en temps "normal", mais ça ne passait plus si dans la foulée devait s'exécuter un changement de ControlSource en section Détail... C'est cela qui faisait planter Access !

Qu'en pensez-vous ??? Je suis désolé de vous avoir emmenés sur cette mauvaise voie. Mais cette histoire de Sum et Count sur un même champ au moment ou s'exécute un ControlSource est curieuse... Il est vrai qu'Access exécute tellement d'actions pratiquement simultannées qu'il peut parfois s'emmeler les pinceaux !

Avez-vous déjà eu le cas ?

A retenir, donc :

1. Dans certaines circonstances, Access ne semble pas capable de calculer en même temps le compte et la somme des valeurs d'un même champ de type Double en pied de groupe dans un état...
2. L'usage de ControlSource est pratique et fiable, à condition d'être toujours bien déclenché sur Report_Open. Après, c'est trop tard !
3. Lorsque ça bug, qu'on ne trouve pas, qu'on n'a pas de guru vaudou, et que decompile n'améliore rien c'est que l'erreur est entre la chaise et le clavier. Il faut tout décortiquer. L'erreur n'est pas forcément très visible, mais elle doit être là, bien cachée dans un recoin !
4. Access devrait pouvoir avertir qu'une erreur se produit, au lieu de planter bêtement sans rien dire !

Un très grand merci à tous les deux, j'aurai au moins appris aussi /decompile !

Je vais mettre "résolu" dans quelques heures, sinon un modo va me taper sur les doigts !

Pensez-vous que des plantages rares de ce type aient été corrigés dans les versions plus récentes d'Access ?

phil

[Paraffine]

Je ne vois pas de raison logique.
PaymentTTC est-il alimenté directement par une colonne de table ou est-ce un champ calculé ? Et encore, ce n'est pas ta devise qui est en cause...

Si tu penses que la simultanéité peut jouer un rôle, essaie de placer des "DoEvents" ça et là pour ralentir la cadence.

Et connais-tu quelqu'un à portée de main avec une version plus récente d'Access ? Auquel cas tu pourrais faire une copie de ta base "planteuse" puis la convertir pour voir ce que cela donne.

[harpyopsis]

Je ne vois pas de raison logique.
PaymentTTC est-il alimenté directement par une colonne de table ou est-ce un champ calculé ? Et encore, ce n'est pas ta devise qui est en cause...

PaymentTTC est une colonne de table de type Double. Je sais, il aurait pu être calculé HT + TVA, mais tant pis. Et puis ça arrange très bien les affaires pour pouvoir fixer ses prix de vente soit à partir du HT soit à partir du TTC.

La devise n'est pas en cause. Je passe de l'euro aux dollars et à la roupie et autres devises sans jamais utiliser le format Currency. Il n'y a que du Double dans les tables. Et pour la Rupiah, je donne le choix à l'utilisateur de remplacer les milliers par la lettre K comme on le voit partout ici.

Si tu penses que la simultanéité peut jouer un rôle, essaie de placer des "DoEvents" ça et là pour ralentir la cadence.

Absolument, mais maintenant que ça marche !... On va laisser DoEvents se reposer un peu !

En médecine on dit que "la réussite du traitement a confirmé le diagnostic" !

En fait de simultanéité, Report_Open a terminé de fixer le ControlSource de la zone de texte txtPaymentMode AVANT que les données ne soient chargées et que les zones de texte calculées en Pieds de Groupes ne se mettent en route...! Il n'y a pas de simultanéité parfaite mais en tout cas c'est là que ça cloche !

Faut-il absolument essayer de tout comprendre ?

Et connais-tu quelqu'un à portée de main avec une version plus récente d'Access ? Auquel cas tu pourrais faire une copie de ta base "planteuse" puis la convertir pour voir ce que cela donne.

Bouuuuuh, il y a tellement peu de monde ici... Et en plus disposé à du testage... Non. La plupart des Occidentaux sont partis à cause de la pseudo-pandémie, et en général ils ne jurent que par Ruby, Java, Sketchup, Wordpress et MySQL. J'ai bien essayé d'installer Access 2010 sur une de mes machines, mais je ne suis pas encore convaincu. Il suffit de voir la lenteur de la feuille de propriété en design view quand elle se mue en liste des champs disponibles sur des tables liées. Ca prend des plombes ! Et toujours le risque de planter sa chaine SQL lorsqu'on ouvre un peu trop vite le recordsource d'un form ou report. Et puis ce ruban, quel encombrant gadget! Heureusement qu'il y a l'assistant de Arkham !

En fait, ma base n'est pas "PLANTEUSE" ! Que viens-tu donc insinuer, VILAIN!!!

Je fais Alt+D à longueur de journée. Plusieurs sauvegardes par jour. Deux corruptions accidentelles par an maximum vite récupérées par les sauvegardes. Et je n'ai plus ouvert Stellar Repair for Access depuis des années !

Ma base ne plante pas ! SNIF...

Toujours quelques petits problèmes à g et à d, et beaucoup d'améliorations. Ce qui me tracasse le plus en ce moment c'est la synchro MS SQL Server... Vraiment une autre paire de manches pour un néophyte illettré comme moi...

Encore un grand merci pour tes points de vue très éclairés et très utiles, Paraffine. Toujours très heureux d'échanger !

[Paraffine]

Absolument, mais maintenant que ça marche !... On va laisser DoEvents se reposer un peu !

Oh, c'était envisagé de façon tout à fait transitoire et dans l'intérêt de la science (selon plusieurs sites "DoEvents is EVIL" , alors...)

Tu as des tables liées sur une base SQL Server ? Ta requête portait sur des tables distantes ? (je me demande ce que ça aurait donné avec une copie en local, dans ce cas). Comment ça tu refuses les expérimentations sauvages sur une pauvre base innocente ?

J'ai travaillé au siècle dernier sur Access avec des liaisons Oracle qui étaient ma foi fort stables, mais depuis que je dois me colleter quelques tables MySQL, c'est looong ! Et certaines requêtes semblent se perdre dans la nature (dans le réseau, plutôt). J'essaie de réduire les adhérences et de faire le plus de traitements possibles dans des procédures stockées MySQL (très rapides, pour le coup) auxquelles Access envoie des paramètres.

En fait, ma base n'est pas "PLANTEUSE" !

Je voulais bien sûr parler de la version Access. Loin de moi l'idée de dénigrer une aussi magnifique base multilingue.

[harpyopsis]

Oui, ce sont des tables liées. mais elles viennent de divers fichiers accdb, pas encore de SQL Server...

Je ferme ce fil comme résolu. Je vais mettre d'autres petites questions sur d'autres fils dans ce même forum !

A+