Discussion :

[Hanyf]

D'abord merci pour cette classe MELA.
Mais j'ai un petit souci: lorsque la colonne ID de la table adossée au formulaire est de type texte, après la mise à jour de "LmRechercher" (liste déroulante)
j'obtiens un message d'erreur : "Erreur 3077: Erreur de Syntaxe (opérateur absent) dans l'expression".

Comment y remédier ? Merci.

[loufab]

Bonjour,

La classe est basée sur des règles communes du SGBDR.

Un champ ID sert :

• à identifier un enregistrement de manière unique.
• de clefs dans les relations.

Un champ ID ne sert jamais à stocker des informations utilisateurs.

Par définition un ID est toujours au format numérique entier long. Par commodité on choisi le NumeroAuto parce qu'il génère seul l'incrémentation d'un entier long unique et que le null n'est pas admis. Ce sont 2 des conditions qui permettent des performances optimales du moteur de base de données (cf mon tuto sur les performances).

Pour régler rapidement le problème :

• Ouvrir la table,
• créer un champ NumeroAuto,
• le nommer Id_nomtable.
• Utiliser ce champ à la place de l'autre ID

En espérant que cette classe donne toute satisfaction.

Pour mon info, tu l'as monté (ou tu la monte) sur quel type d'application ?

Cordialement,

[Hanyf]

Tout d'abord je dois préciser que je suis entièrement d'accord avec toi sur les caractéristiques que doit posséder d'un champ ID. Mais cela est de la théorie qui doit affronter le monde réel: celui de l'entreprise. Je m'explique : il est évident qu'une table doit posséder de préférence une clé primaire de type numérique; Cela est valable "ex ante" lorsqu'on conçoit son modèle de base de données sous Merise, par exemple. Mais lorsque tu as une application sous Access qui est déjà en PRODUCTION, et que ton chef t'interdit de modifier les colonnes des tables, tu n'a pas d'autre choix que de t'adapter à la situation et d'agir "in vivo". De ce fait tu fait fi de la théorie qui veut qu'une colonne ID soit de type numérique et tu dois trouver une solution très rapidement, sans bousculer l'existant.
Donc tu "dénormalise" (sic) et tu conserve ta clé primaire de type alphanumérique.
La clé primaire de type texte, en question, s'intitule: "PN" : pour Part Number (Explications ici :https://en.wikipedia.org/wiki/Part_number).
Voici à quoi ressemble ce champ PN, qui est donc une clé primaire:

Comme la solution que tu me proposes est inapplicable vu les contraintes de production; Je vais adapter le code de la liste déroulante "LmRechercher" pour l'évènement AfterUpdate et tenir compte de la contrainte d'une clé primaire (PN) de type texte.
Ah oui une précision cette application traite des données du secteur des télécoms.

Cordialement...

[tee_grandbois]

Mais lorsque tu as une application sous Access qui est déjà en PRODUCTION, et que ton chef t'interdit de modifier les colonnes des tables, tu n'a pas d'autre choix que de t'adapter à la situation et d'agir "in vivo".

Bonjour,
je me permet d'intervenir sur la discussion concernant cette théorie de "la toute puissance du chef qui a toujours raison" même contre ce qui semble être une évidence et contre laquelle je me suis toujours battu.
Ne peux-tu pas démontrer que cette modification (somme toute mineure) n'a aucune incidence sur l'existant ?
Il serait temps de combattre la suprématie des petits chefs bornés et incompétents ...

[loufab]

Vu le ton du message, Ranyf semble avoir un problème avec ma dernière intervention donc pour lever toute ambiguïté voici ma réponse.

Comme le dit tee-Grandbois, ajouter une colonne NumeroAuto ne va pas mettre en péril l'intégrité des données. Mais qu'importe ! Si un petit chef obtus l'a dit c'est que quelque part il doit avoir raison et dans ce cas un "J'ai glissé chef..." ne sera d'aucune utilité.

Sur le fond :
Cette classe est livrée en l'état, son code est GRACIEUSEMENT mis à la disposition de tous, sans contrepartie, sans garantie, mais surtout sans OBLIGATION. Je suis conscient qu'elle ne peut pas s'adapter à tous les cas vu l'étendu du "Quick and Dirty" qui existe en "PRODUCTION". Cependant à moins d'avoir fait un copier/coller rapide, le tuto indique bien les prérequis (cf https://fr.wiktionary.org/wiki/pr%C3%A9requis ).
Et dans ce cas, l'utilisateur a le loisir de l'adapter à son cas, aussi affreux qu'il soit.

Je ne reviendrais pas sur le bon sens d'utiliser une clef numérique, qui va bien au delà du théorique. Je ne peux que renvoyer le lecteur à mon tuto sur les performances.

Sur la forme :
Inutile de mettre un formule de politesse si celle-ci n'est pas sincère. Ici, par exemple elle n'y est pas.

[Hanyf]

Bonjour,
je me permet d'intervenir sur la discussion concernant cette théorie de "la toute puissance du chef qui a toujours raison" même contre ce qui semble être une évidence et contre laquelle je me suis toujours battu.
Ne peux-tu pas démontrer que cette modification (somme toute mineure) n'a aucune incidence sur l'existant ?
Il serait temps de combattre la suprématie des petits chefs bornés et incompétents ...

Bonjour Tee_grandbois, Loufab

Eh oui, pourtant c'est un cas vécu : tu as un chef qui manage une BDD mais qui ne sait pas (par exemple):

1. ce qu'est une clé étrangère
2. comment compacter une BDD
3. ce qu'est un gestionnaire d'erreurs

De plus lorsqu'il t'impose d'importer des données de TYPE DATE et de les insérer dans une colonne Access de TYPE TEXTE (SIC !); Là tu commences vraiment à te poser de sérieuses questions métaphysiques
Et là tu commences à réfléchir sérieusement sur la suite à donner à de ton travail...

Cordialement.

[Hanyf]

Bonjour Loufab,

Re-Merci (sincèrement) pour ta classe MELA.
Je me suis permis d'adapter le code à mon cas vécu (quasi "existentiel").
Mais avant d'entrer dans le vif du sujet, un petit détour par un rappel METHODOLOGIQUE (c'est mon dada), s'impose.

En effet, il est vrai, comme le veut la théorie, qu'il vaut mieux préférer une clé primaire de type numérique à une autre de type texte.
Si l'on approfondi plus le sujet, on s'aperçoit que ce qui se cache derrière cette démarche, c'est une conception normative de la réalité.
Cela signifie que l'on cherche à plier la réalité au modèle. C'est une démarche purement déductive.
Ce n'est pas ma conception du développement informatique, qui certes a besoin de règles, mais qui doivent s'adapter à des cas concrets.

Je suis partisan de la méthode hypothético-déductive (Explications). En résumé, cette approche consiste en une confrontation de la théorie à la réalité par le biais de tests, par exemple. C'est un va-et- vient entre démarche déductive et approche inductive, pour essayer de trouver la meilleure solution, pour faire en sorte que le modèle colle bien à la réalité.

Cette précision apportée, passons à notre cas réel, à savoir : adapter le code VBA de la combobox "LmRechercher" au cas d'une clé primaire de type TEXTE, toujours dans la classe "cBoutonNav".

Précisons d'abord la nature des données:
toutes les colonnes de la table "tAdherent" sont de type texte, y compris la clé primaire, donc .



Voici maintenant le code de Loufab, revisité :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
 
Private Sub LmRechercher_AfterUpdate()
'Hanyf 2017_03_27
On Error GoTo errHandle
 
  Dim oRst As DAO.Recordset
 
    If Not IsNull(oForm.LmRechercher) Then
        'Save before move.
        If oForm.Dirty Then
            oForm.Dirty = False
        End If
        'Search in the clone set.
        Set oRst = oForm.RecordsetClone
        'Cas numérique:
        'oRst.FindFirst "[Nom] = " & oForm.LmRechercher
        'Cas texte, qui est notre cas réel
        oRst.FindFirst "[Nom] ='" & oForm.LmRechercher & "'"
        If oRst.NoMatch Then
            MsgBox "Non trouvé ! ", vbExclamation
        Else
            'Afficher l'enregistrement recherché dans le formulaire
            oForm.Bookmark = oRst.Bookmark
        End If
        oRst.Close
    End If
 
    'Synchronisation des contrôles Nom et de LmRechercher
    oForm.Controls("Nom").Value = oForm.LmRechercher.Value
 
exitError:
    Set oRst = Nothing
    Exit Sub
 
errHandle:
    MsgBox "Une exception est survenue dans le programme: " & vbCrLf & _
        "Numéro de l'erreur: " & Err.Number & vbCrLf & "Nature de l'erreur: " & Err.Description, vbCritical
    Resume exitError
 
End Sub

Les 3 principales adaptations/améliorations que j'ai effectuées sont:

1. la gestion d'erreurs
2. l'adaptation de la combobox au cas de la clé primaire de type texte
3. la synchronisation de la combobox avec la textbox ("Nom").

J'ai, évidemment, testé ce code sur les versions 2003 à 2010 d'Access et ça fonctionne très bien.

Evidemment ce code n'est qu'un exemple d'implantation d'une clé primaire de type texte dans une combobox; il est (certainement) possible qu'il puisse exister d'autres solutions, qui seront les bien-venues...

[loufab]

Sauf qu'avec une clef de type texte les performances de beaucoup de moteurs de base de données sont dégradées. On s'en aperçoit vite sur des tables volumineuses et/ou des requêtes complexes. Le Moteur Jet n'y déroge pas même si c'est un moteur très performant.

Sinon rien n'interdit l'utilisation d'autres types dans cette classe.