Discussion :

[traderpierre54]

Bonjour,

Dans une table Access, j'ai un champ nommé Prix/Qte
où je rentre mon prix + la quantité adossée à ce prix sous cette forme "27,60/10"

Je souhaite dans un champ calculé "nommé : Qte", extraire la chaîne de caractères après le / "cette chaîne correspondant à Quantité.

J'ai essayé ces deux expressions dans le calcul du champ Qte

=Droite( [Prix /Qte] ;NbCar(ExtracChaîne$( [Prix /Qte] ;DansChaîne( [Prix /Qte] ;"/")))-1)

=Droite( [Prix /Qte] ;NbCar(ExtracChaîne$( [Prix /Qte] ;DansChaîne( [Prix /Qte] ;[/])))-1)

Mais à chaque fois, Access me renvoit ce message "Erreur de syntaxe dans l'expression"

Pouvez-vous m'aider pour extraire cette chaîne de caractères située après le / du champ Prix/Qte ???

Merci par avance pour votre aide.

[User]

Bonjour,

Ce serait mieux de le faire dans une requête :

Qte : ExtracChaîne([Prix /Qte];DansChaîne([Prix /Qte];"/")+1)

Cdlt

[traderpierre54]

Bonjour,

Ce serait mieux de le faire dans une requête :

Qte : ExtracChaîne([Prix /Qte];DansChaîne([Prix /Qte];"/")+1)

Cdlt

Bonjour,
Merci pour votre réponse, mais
Je souhaite le faire dans un champ calculé afin que ce champ calculé se remplisse automatiquement lors de la saisie Prix/Qte

[User]

Bonjour,

Dans une table Access, j'ai un champ nommé Prix/Qte
où je rentre mon prix + la quantité adossée à ce prix sous cette forme "27,60/10"

Pourquoi ne pas saisir tout simplement le prix et la qté dans 2 champs séparés [Prix] et [Qte] ?

Cdlt

[traderpierre54]

Pourquoi ne pas saisir tout simplement le prix et la qté dans 2 champs séparés [Prix] et [Qte] ?

Cdlt

ça va plus vite pour la saisie

[User]

Ce n'est pas conseillé, vous avez un champ ou une colonne avec 2 informations (le prix et la quantité du produit) que va-t-il se passer quand par exemple vous souhaiterez effectuer des opérations sur ces données (ex. : somme(qte*prix)), sans compter les erreurs de saisie possible..

[hyperion13]

Salut @User
Cette expression Droite([Prix/Qte];NbCar(ExtracChaîne$([Prix/Qte];DansChaîne([Prix/Qte];"/")))-1),ou ExtracChaîne([Prix/Qte];DansChaîne([Prix/Qte];"/")+1),est trop complexe pour un champ de type Calculé, même si toutes les fonctions dans chacune des expressions sont disponibles dans le générateur.

Désolé, mais l'argument qu'à la saisie c'est plus rapide ne tient pas. Enfin ce n'est que mon avis ! La preuve par a+b, il faut utiliser l'une des expressions ci-dessus pour extraire la Qté !

Et pourquoi ne pas passer par TableDefs et CreateField pour créer l'expression pendant que nous y sommes ? Mais là aussi des erreurs signalées 3945/3950 !

[traderpierre54]

Salut @User
Cette expression Droite([Prix/Qte];NbCar(ExtracChaîne$([Prix/Qte];DansChaîne([Prix/Qte];"/")))-1),ou ExtracChaîne([Prix/Qte];DansChaîne([Prix/Qte];"/")+1),est trop complexe pour un champ de type Calculé, même si toutes les fonctions dans chacune des expressions sont disponibles dans le générateur.

Désolé, mais l'argument qu'à la saisie c'est plus rapide ne tient pas. Enfin ce n'est que mon avis ! La preuve par a+b, il faut utiliser l'une des expressions ci-dessus pour extraire la Qté !

Et pourquoi ne pas passer par TableDefs et CreateField pour créer l'expression pendant que nous y sommes ? Mais là aussi des erreurs signalées 3945/3950 !

J'ai essayé ces exressions mais cela ne fonctionne pas access renvoit un syntaxe erronée

[tee_grandbois]

bonsoir,

J'ai essayé ces expressions mais cela ne fonctionne pas access renvoiet un syntaxe erronée

ta seule bonne foi ne suffit pas, il faudrait nous poster le code complet utilisé pour qu'on puisse contrôler, d'autant plus si l'expression est complexe

[hyperion13]

Et c'est pour cela que @User vous oriente vers les standards de l'analyse conceptuelle et de construction des tables.
Vous devriez créer 2 champs distincts Prix et Qté.
Il faudra m'expliquer la pertinence de saisir "27,60/10" dans un champ !

[traderpierre54]

bonsoir,

ta seule bonne foi ne suffit pas, il faudrait nous poster le code complet utilisé pour qu'on puisse contrôler, d'autant plus si l'expression est complexe

Cette réponse est destinée exclusivement à tee_grandbois se prétendant Expert éminent sénior.

Trop facile de botter en touche avec ce genre de réponse !!! Ce n'est pas digne d'un développeur se prétendant Expert éminent sénior !!!!

Si vous ne me croyez pas essayez tour à tour ces deux expressions dans le champ calculé d'une table access et vous constaterez de vous même qu'ACCESS retourne "Erreur de syntaxe dans l'expression"

expression 1 / : Droite([Prix/Qte];NbCar(ExtracChaîne$([Prix/Qte];DansChaîne([Prix/Qte];"/")))-1),

expression 2 / : ExtracChaîne([Prix/Qte];DansChaîne([Prix/Qte];"/")+1)

Sur ces deux expressions, Access retourne : "Erreur de syntaxe dans l'expression"

[traderpierre54]

bonsoir,

ta seule bonne foi ne suffit pas, il faudrait nous poster le code complet utilisé pour qu'on puisse contrôler, d'autant plus si l'expression est complexe

Cette réponse est destinée exclusivement à tee_grandbois se prétendant Expert éminent sénior.

Trop facile de botter en touche avec ce genre de réponse !!! Ce n'est pas digne d'un développeur se prétendant Expert éminent sénior !!!!

Si vous ne me croyez pas essayez tour à tour ces deux expressions dans le champ calculé d'une table access et vous constaterez de vous même qu'ACCESS retourne "Erreur de syntaxe dans l'expression"

expression 1 / : Droite([Prix/Qte];NbCar(ExtracChaîne$([Prix/Qte];DansChaîne([Prix/Qte];"/")))-1),

expression 2 / : ExtracChaîne([Prix/Qte];DansChaîne([Prix/Qte];"/")+1)

Sur ces deux expressions, Access retourne : "Erreur de syntaxe dans l'expression"

[tee_grandbois]

Cette réponse est destinée exclusivement à tee_grandbois se prétendant Expert éminent sénior.

Trop facile de botter en touche avec ce genre de réponse !!! Ce n'est pas digne d'un développeur se prétendant Expert éminent sénior !!!!

je ne me prétend pas "Expert éminent sénior", c'est le système d'attribution de points du forum qui le fait.
Je rappelle que je suis bénévole et que je ne reçois rien en retour à part quelques remerciements venant des nombreuses personnes que j'ai aidé, les quelques (très rares) réflexions désobligeantes ne m'atteignent pas, tu peux donc te lâcher si tu le souhaites je n'y répondrai pas.

Si je t'ai demandé le code que tu as écrit c'est pour vérifier si ta syntaxe est correcte en pensant que tu utilisais une requête, je vois que ce n'est pas le cas.

Pour rappel, le code fonctionne très bien dans une requête ou dans une zone de texte d'état ou formulaire mais pas dans un champ calculé de table (certaines expressions semblent trop complexes pour ce type de champ) et malgré les recommandations d'Hyperion13, tu persistes à les utiliser (y compris la saisie de 2 valeurs dans un seul champ, que je ne t'ai même pas reproché. Comme quoi ...).

Il ne faut pas utiliser Access comme un tableur, une table ce n'est pas une feuille Excel. Sinon, il nous sera difficile de te donner des réponses plus pertinentes.

[hyperion13]

@User, @tee_grandbois
Volontairement, je ne traduis pas ce qui suit :

Calculated Fields
- How do you get Access to store the result of a calculation?
- For example, if you have fields named Quantity and UnitPrice, how do you get Access to write Quantity * UnitPrice to another field called Amount?
- The best answer is, "Don't!"

What about Calculated fields in Access 2010?
- Just choose Calculated in the data type, and Expression appears below it. Type the expression. Access will then calculate it each time you enter your record.
- This may seem simple, but it creates more problems that it solves. You will quickly find that the expressions are limited.
- Even more serious, the calculated results are not reliable. If you change the Expression after data has been entered into the table, the existing results may not be updated correctly (through new records are edits are updated), so you cannot rely on the results. A compact/repair does not recalculate, so there is no obvious way to repair the bad results.
- Since you cannot index calculated fields anyway, there is no performance benefit to be gained from using them. You are violating fundamental rules of data normalization for no good purpose. We recommend you use queries for calculated fields, just as in previous versions.

Et on en revient à devoir appliquer ce que l'analyse conceptuelle (MERISE 1 & 2) préconise. Les champs calculés, on les dégage de la matrice, donc non présent dans les tables. C'est pourtant si simple !

[User]

Je rappelle que je suis bénévole et que je ne reçois rien en retour à part quelques remerciements venant des nombreuses personnes que j'ai aidé

Ces remerciements sont largement mérités

Et on en revient à devoir appliquer ce que l'analyse conceptuelle (MERISE 1 & 2) préconise. Les champs calculés, on les dégage de la matrice, donc non présent dans les tables. C'est pourtant si simple !

Concernant les champs calculés, comme les champs multivalués ou pièces jointes, il faudrait mettre un avertissement bien visible sur le forum

[tee_grandbois]

bonjour tout le monde,

Ces remerciements sont largement mérités

merci, cela me rassure ...

Et on en revient à devoir appliquer ce que l'analyse conceptuelle (MERISE 1 & 2) préconise. Les champs calculés, on les dégage de la matrice, donc non présent dans les tables. C'est pourtant si simple !

d'autant plus que c'est un éditeur de logiciels qui "invente" cette aberration ... à moins que cela soit à la demande des membres du club utilisateurs (sil il en existe un) influents ?
Pourrais-tu préciser la source des textes cités ? Merci.

Concernant les champs calculés, comme les champs multivalués ou pièces jointes, il faudrait mettre un avertissement bien visible sur le forum

tout à fait d'accord, c'est une véritable plaie, sachant que de nombreux posts sont la conséquence de l'utilisation de ce type de champs, mais l'avertissement me semble inutile tant je me rend compte que beaucoup de forumeurs ne prennent pas le temps de consulter la FAQ, lire les règles du forum, les tutos... Il n'y a plus le temps pour la recherche, la réflexion, ou simplement commencer par apprendre les bases, s'entrainer ...
La plupart du temps, la réponse doit être fournie tout de suite ...

[hyperion13]

Salut toi tout seul

... Je rappelle que je suis bénévole et que je ne reçois rien en retour à part quelques remerciements venant des nombreuses personnes que j'ai aidé ...

Je te rassure, ces remerciements sont largement mérités.

... les quelques (très rares) réflexions désobligeantes ne m'atteignent pas ...

Heureusement, sinon tu serais à l'amende selon l'Ops qui suit le fil !

... Concernant les champs calculés, comme les champs multivalués ou pièces jointes, il faudrait mettre un avertissement bien visible sur le forum

On dit que les ânes sont tétus !

... d'autant plus que c'est un éditeur de logiciels qui "invente" cette aberration ...

Je suis comme toi, je ne comprends pas trop la philosophie de crosoft dans ce cas.

... à moins que cela soit à la demande des membres du club utilisateurs (sil il en existe un) influents ? ...

Crosoft doit forcément tenir compte de retours d'expérience pour proposer de nouvelles fonctionnalités, fonctions et améliorations.

... Pourrais-tu préciser la source des textes cités ? Merci. ...

le site dAllen Browne

... mais l'avertissement me semble inutile tant je me rend compte que beaucoup de forumeurs ne prennent pas le temps de consulter la FAQ, lire les règles du forum, les tutos... Il n'y a plus le temps pour la recherche, la réflexion, ou simplement commencer par apprendre les bases, s'entrainer ...
La plupart du temps, la réponse doit être fournie tout de suite ...

J'ai fait ce constat depuis un bon bout de temps ! Les générations Z, X, Y ne maitrisent pas les fondamentaux ! Alors leur demander de lire, réfléchir me parait être une mission impossible !