Requête sur deux tables avec incrément de champ

Bonjour,

Table1 avec les champs Nom et Nombre
Table2 avec le champ Nom

J'espérais que:

Code:

---

1 2 3

UPDATE Table1, Table2 SET Table1.Nombre = Table1.Nombre + 1 WHERE Table1.Nom = Table2.Nom

---

incrémenterait le champ Nombre chaque fois que les champs Nom seraient égaux dans Table1 et Table2.
A priori, c'eut été trop facile...

Merci pour les conseils que vous voudrez bien m'apporter.

Hum... Ça ne respecte pas la norme SQL. Vous utilisez MySQL ?


Bref, avec MySQL quelque chose comme ça devrait quand même aller :

Code:

---

1 2 3

update t1, t2 set t1.nombre = t1.nombre + 1, t2.nombre = t2.nombre + 1 where t1.nom = t2.nom ;

---

Merci fsmrel de vous pencher sur mon problème.

Il n'y a pas de champ Nombre dans Table2.

Je souhaite simplement incrémenter chaque champ Nombre de Table1 chaque fois que les champs Nom de Table1 et Table2 sont identiques.

J'utilise SQL via C++Builder pour gérer des tables Access.

Merci.

En SQL classique :

Code:

---

1 2 3 4 5

update t1 set nombre = nombre + 1 where exists (select * from t2 where t1.nom = t2.nom) ;

---

Je n'ai pas de message d'erreur mais mes champs Nombre ne sont pas alimentés.

J'ai testé en ACCESS natif : ça marche parfaitement.

Je vous joins mes quelques lignes

Code:

---

1 2 3 4 5

ADOQuery->SQL->Clear(); ADOQuery->SQL->Add("UPDATE TableCumul"); ADOQuery->SQL->Add("SET Nombre = Nombre + 1"); ADOQuery->SQL->Add("WHERE EXISTS(SELECT * FROM MesAgences WHERE TableCumul.Agence = MesAgences.Agence)"); ADOQuery->ExecSQL();

---

ou
TableCumul a pour champs Agence et Nombre
MesAgences a pour champs Agence et Nombre

Merci.

Rectificatif, il fallait lire

"ou
TableCumul a pour champs Agence et Nombre
MesAgences a pour champ Agence"

Avez-vous essayé en ACCESS natif ? Si en l'occurrence Nombre n'évolue pas c'est que l'intersection des deux tables sur l'attrbut Agence est vide...

Bonjour,

après moult tentatives, il s'avère que mon champ Nombre, issu d'une table créée "à la volée" et défini en integer était vide.
En l'initialisant à 0 lors de la création de la table, je n'ai plus de problème pour l'incrémenter.

Si qqu'un peut me dire pourquoi.

Encore merci fsmrel.

Bonjour,


"vide" est en fait "null".

Null représente l’absence de valeur, contrairement par exemple à 0 qui est la valeur 0.

Du coup quand on fait absence de valeur + 1 ... ca donne ..pas grand chose ! => absence de valeur

Merci punkoff.

Je trouve tout de même bizarre qu'en créant un champ sous forme d'entier, celui-ci ressorte Null et non vide.

Bonjour,

Citation:

---

Envoyé par LB

Je trouve tout de même bizarre qu'en créant un champ sous forme d'entier, celui-ci ressorte Null et non vide.

---

Le fait que vous trouviez bizarre qu'en créant un champ sous forme d'entier, celui-ci ressorte Null et non vide, est la conséquence que vous vous en tenez à la logique binaire traditionnelle (en passant, « vide » n’est pas un entier).

En fait, Null impose la mise en oeuvre d’une logique ternaire.

L’équipe de Don Chamberlin (IBM Research Laboratory, San Jose, CA) a défini le langage SQL, d’abord baptisé SEQUEL en 1974, puis SEQUEL 2 en 1976. A cette occasion, le marqueur Null (que j’ai surnommé bonhomme Null) a fait l’objet d’un soin particulier dans l’article de 1976 (SEQUEL 2: A Unified Approach to Data Definition, Manipulation, and Control), car y figurent les tables de vérité dont on a besoin pour connaître le comportement des opérations auxquelles participe le bonhomme Null : ces tables de vérité sont celles d’une logique ternaire.

Rappelons-nous d’abord des tables de vérité de la bonne vieille logique binaire, exprimant le comportement des opérateurs logiques ET, OU, NON :

Code:

---

1 2 3 4 5

ET | vrai | faux —————|——————|—————— vrai | vrai | faux faux | faux | faux

---

Code:

---

1 2 3 4 5

OU | vrai | faux —————|——————|—————— vrai | vrai | vrai faux | vrai | faux

---

Code:

---

1 2 3 4 5

NON | vrai —————|—————— vrai | faux faux | vrai

---

La présence du bonhomme Null exige désormais la mise en œuvre d’une logique ternaire (et les soucis commencent...)

Selon cette logique, les valeurs de vérité ne sont plus seulement vrai et faux, il faut leur adjoindre une troisième, symbolisée ci-dessous par « ?? ». Les tables de vérité évoluent donc, et je reprends celles de l’article de 1976 (et toujours en vigueur quel que soit le SGBD SQL, du moins peut-on l’espérer !) :

Code:

---

1 2 3 4 5 6

ET | vrai | faux | ?? —————|——————|——————|—————— vrai | vrai | faux | ?? faux | faux | faux | faux ?? | ?? | faux | ??

---

Code:

---

1 2 3 4 5 6

OU | vrai | faux | ?? —————|——————|——————|—————— vrai | vrai | vrai | vrai faux | vrai | faux | ?? ?? | vrai | ?? | ??

---

Code:

---

1 2 3 4 5 6

NON | vrai —————|—————— vrai | faux faux | vrai ?? | ??

---

Avec cette logique trivaluée, il y a des tautologies qui n’en sont plus, telle celle-ci : SI p ALORS p au cas où p est inconnu. Par exemple : « Si je chante alors je chante » n’est plus une évidence. Même chose pour une contradiction telle que p ET NON p : « Je chante et je ne chante pas » n’est plus une contradiction. De la même façon, dans le cas du biconditionnel, p SI ET SEULEMENT SI p, on retrouve les mêmes problèmes : « Je chante si et seulement si je chante » n’est plus une tautologie.

La référence en en ce qui concerne les logiques multivaluées, Nicholas Rescher in Many-Valued Logic rappelle que l’équivalence doit être réflexive, c'est-à-dire que p SI ET SEULEMENT SI p est nécessairement vrai, pour toutes les valeurs de p, contrainte qui est violée si la valeur de vérité de p est i (inconnue). On peut toujours s’essayer a utiliser d’autres tables de vérité : on débouche sur de nouveaux problèmes de tautologies.

=> L’optimiseur de votre SGBD peut fournir des résultats faux, à tout le moins vous faire commettre des erreurs.

Pour approfondir le sujet, je vous renvoie à l’ouvrage de Chris Date : Date on Database: Writings 2000-2006, au chapitre 18 « Why three - And four-valued logic don’t work ».

A leur tour, les résultats des opérations arithmétiques sont influencés par la présence du bonhomme Null. Si z symbolise un nombre et @ symbolise un opérateur tel que +, -, X, /, la situation est inévitablement la suivante :

Code:

---

1 2 3

z @ Null = Null ; Null @ z = Null ; Null @ Null = Null;

---

Ainsi, si l’on ne connaît pas la TVA à appliquer à un montant hors taxe, on ne sait pas calculer le montant TTC correspondant et le résultat du calcul doit être marqué Null, sous peine de mentir. Moralité, dans nos bases de données on doit tout faire pour ne pas se trouver dans cette situation, la TVA à appliquer doit toujours être connue, c’est un problème de modélisation. Plus généralement, lors de la codification d’une instruction CREATE TABLE, si pour tout attribut d’une table vous ne codez pas « NOT NULL », c’est à vos risques et périls (ou plutôt ceux de la base de données...)


:!: De la même façon, les opérateurs d’agrégation, SUM, AVG, MAX, etc. donnent lieu à des résultats pouvant surprendre, mais dans lesquels le bonhomme Null à son rôle à jouer...

Etc.