Forum - Questions sur Access - DLookup avec variable pour la champ
le 30/01/2018 : 19:12
par jfs
Bonjour Pierre Encore un problème de variable J’ai une table TblCompte ‘Pas de soucis pour récupérer une valeur avec DLooKup
DejaAchete = Nz(DLookup("[24TAchat]", "[TblCompte]", "[N°client]= " & Me![N°client]))
‘Je traite ma valeur
DejaAchete = DejaAchete + Me.nb_seance
‘ Je vais sauver cette nouvelle valeur J’utilise une variable String pour enregistrer ma nouvelle valeur dans le champ concerné LeChamps= « 24TA »
sSQL = "UPDATE TblCompte SET " & LeChamps & "=" & DejaAchete & " WHERE [N°Client]=" & Me![N°client] & ";" CurrentDb.Execute sSQL
Mon soucis est que le nom du champ dans la table TblCompte peut changer à chaque enregistrement et je voudrais l’introduire dans de DLookup sous forme de variable (comme pour le UPDATE)
DejaAchete = Nz(DLookup( ??LeChamps ?? , "[TblCompte]", "[N°client]= " & Me![N°client]))
Mais ca ne fonctionne pas Cette valeur doit être en String ce qui est le cas Je suppose que le problème est dans la formulation mais je ne trouve pas. J’ai bien sur la possibilité de faire un recordset mais je trouve le DLookup plus rapide Comment puis-je faire Cordialement JFS
--------
le 30/01/2018 : 19:14
par 3Stone
Administrateur
Bonjour,
DejaAchete = Nz(DLookup( ??LeChamps ?? , "[TblCompte]", "[N°client]= " & Me![N°client]))
Comme ceci :
DejaAchete = Nz(DLookup("[ " & LaVariable & "]", "TblCompte", ...
Mais le vrai problème n'est pas là
Tu as un gros problème de conception !
Avoir des "noms de champs qui changent" devrait t'alerter!
Ce que tu appelles "traiter la valeur" pour ensuite écrire la nouvelle valeur par une mise à jour et une erreur grossière de méthode.
On fait une mise à jour lorsque par exemple il y a changement d'adresse, l'ancienne adresse n'est plus utile.
Mais faire des mises à jour de présences ou autre ne doit pas se faire de cette manière.
La bonne méthode est d'avoir une table "T_Presences" avec les champs suivants :
ID => numéroauto
NoClient => numéro du client - clé externe de la table T_CLients
DatePresence => pour la date de présence
ou selon ton exemple...
NombreAchat => qui recoit le nombre acheté
Pour chaque mouvement, on y inscrit un enregistrement, soit positif, soit négatif.
Ensuite, pour connaitre la valeur résultante, on fait la somme...
DSum("NombreAchat","LaTable", "NoClient=" & Me.NumClient)
En fait, tu semble t'inspirer d'Excel pour tes traitements, ce qui est une (très) mauvaise idée.
Cordialement,
Pierre (3Stone)
--------
le 30/01/2018 : 19:18
par jfs
visiteur
Bonjour Pierre
Merci pour ta réponse
Tu as entièrement raison je suis très inspiré par Excel qui était ce que j’utilisais avant de passer à Access.
Autodidacte 100% j’ai au départ, un peu par nécessité d’avoir un résultat rapide, un peu parce que je ne pensais pas utiliser Access énormément et un peu par manque de courage, privilégié le résultat aux principes de conception d’une base de données.
Comme tu me le fais remarquer ceci entraine des mauvais choix de ma part et parfois m’impose un travail plus long que nécessaire.
A plus de 70 ans c’est très difficile de tout remettre à plat et de repartir à zéro et de changer des années de mauvaises habitudes.
Merci pour ton aide
Cordialement
jfs
--------
le 30/01/2018 : 19:41
par 3Stone
Administrateur
Bonjour,
privilégié le résultat aux principes de conception d’une base de données
C'est bien plus que des principes
Lorsque tu as un problème, quel qu'il soit avec ta méthode, tu ne peux rien retracer, ni corriger. Tu manques d'une trace de ce qui a déjà été fait...
Par contre, en créant un enregistrement pour chaque mouvement, tu a tout l'historique sous les yeux.
Cela a l'avantage de voir et de pouvoir corriger une erreur éventuelle, mais de plus les résultats d'une interrogation de la base est autrement plus performante.
A plus de 70 ans
Alors on ne se doit rien
Cordialement,
Pierre (3Stone)
Rectifier message Clôturer sujet Remonter