Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Elément de liste à usage unique

9 réponses
Avatar
Ziggy
Bonjour,

Dans un formulaire, j'ai une liste déroulante de noms d'utilisateurs
provenant d'une requête.
Le but de ce formualire est d'attribuer un n° à un utilisateur.
J'aimerai que cette liste ne propose plus les utilisateurs déjà utilisés.
Dans ma table, les utilisateurs sont indéxés sans doublons.
Si quelqu'un peut m'expliquer comment modifier ma requête. Je l'en remercie
par avance.

SELECT TabUsers.UserIndex, TabUsers!UserPrenom & " " & TabUsers!UserNom AS
[Nom complet]
FROM TabUsers
ORDER BY TabUsers!UserPrenom & " " & TabUsers!UserNom;

Thierry

9 réponses

Avatar
Philippe [MS]
Je suppose que cela correspond aux utilisateurs dont l'index est NULL ???

SELECT TabUsers.UserIndex, TabUsers!UserPrenom & " " & AS
[Nom complet]
FROM TabUsers
WHERE TabUsers!UserIndex IS NULL
ORDER BY TabUsers!UserPrenom & " " & TabUsers!UserNom;

Sinon une clause du genre

WHERE UserNom NOT IN (SELECT UserNom FROM TabUsers WHERE UserIndex IS NOT
NULL)

Phil.

"Ziggy" wrote in message
news:#X5H3w$
Bonjour,

Dans un formulaire, j'ai une liste déroulante de noms d'utilisateurs
provenant d'une requête.
Le but de ce formualire est d'attribuer un n° à un utilisateur.
J'aimerai que cette liste ne propose plus les utilisateurs déjà utilisés.
Dans ma table, les utilisateurs sont indéxés sans doublons.
Si quelqu'un peut m'expliquer comment modifier ma requête. Je l'en
remercie

par avance.

SELECT TabUsers.UserIndex, TabUsers!UserPrenom & " " & TabUsers!UserNom AS
[Nom complet]
FROM TabUsers
ORDER BY TabUsers!UserPrenom & " " & TabUsers!UserNom;

Thierry




Avatar
Evaro
Bonjour,

"Ziggy" a écrit dans le message de news:
%23X5H3w$
Bonjour,
SELECT TabUsers.UserIndex, TabUsers!UserPrenom & " " & TabUsers!UserNom
AS [Nom complet]
FROM TabUsers
ORDER BY TabUsers!UserPrenom & " " & TabUsers!UserNom;



SELECT TabUsers.UserIndex, TabUsers!UserPrenom & " " & TabUsers!UserNom
AS
[Nom complet]
FROM TabUsers
WHERE Tabusers.Numero Is Null
ORDER BY TabUsers!UserPrenom & " " & TabUsers!UserNom;

Avatar
Ziggy
Merci Phil et Evaro

Bon, j'ai essayé mais ma requête est vide.
Voici un peu plus de détails.
Mon formulaire FrmDeploy renseigne la table TblDeploy contenant les champs
DeployIndex, DeployHostNumSerial, DeployUserName
DeployHostNumSerial et DeployUserName sont respectivement en relation un à
un avec TblHosts et TblUsers
Un exemple de mes essais qui m semble se rapprocher le plus :

SELECT TabUsers.UserIndex, TabUsers!UserPrenom & " " & TabUsers!UserNom AS
[Nom complet]
FROM TabUsers INNER JOIN TabDeploy ON TabUsers.UserIndex =
TabDeploy.DeployUserName
WHERE (((TabUsers.UserIndex)<>[TabDeploy]![DeployUserName]))
ORDER BY TabUsers!UserPrenom & " " & TabUsers!UserNom;

Je m'égare non ?



"Philippe [MS]" a écrit dans le message de
news: uUdqL$$
Je suppose que cela correspond aux utilisateurs dont l'index est NULL ???

SELECT TabUsers.UserIndex, TabUsers!UserPrenom & " " & AS
[Nom complet]
FROM TabUsers
WHERE TabUsers!UserIndex IS NULL
ORDER BY TabUsers!UserPrenom & " " & TabUsers!UserNom;

Sinon une clause du genre

WHERE UserNom NOT IN (SELECT UserNom FROM TabUsers WHERE UserIndex IS NOT
NULL)

Phil.

"Ziggy" wrote in message
news:#X5H3w$
Bonjour,

Dans un formulaire, j'ai une liste déroulante de noms d'utilisateurs
provenant d'une requête.
Le but de ce formualire est d'attribuer un n° à un utilisateur.
J'aimerai que cette liste ne propose plus les utilisateurs déjà utilisés.
Dans ma table, les utilisateurs sont indéxés sans doublons.
Si quelqu'un peut m'expliquer comment modifier ma requête. Je l'en
remercie

par avance.

SELECT TabUsers.UserIndex, TabUsers!UserPrenom & " " & TabUsers!UserNom
AS
[Nom complet]
FROM TabUsers
ORDER BY TabUsers!UserPrenom & " " & TabUsers!UserNom;

Thierry








Avatar
Evaro
"Ziggy" a écrit dans le message de news:

Merci Phil et Evaro

Bon, j'ai essayé mais ma requête est vide.
Voici un peu plus de détails.
Mon formulaire FrmDeploy renseigne la table TblDeploy contenant les
champs DeployIndex, DeployHostNumSerial, DeployUserName
DeployHostNumSerial et DeployUserName sont respectivement en relation un
à un avec TblHosts et TblUsers
Un exemple de mes essais qui m semble se rapprocher le plus :

SELECT TabUsers.UserIndex, TabUsers!UserPrenom & " " & TabUsers!UserNom
AS [Nom complet]
FROM TabUsers INNER JOIN TabDeploy ON TabUsers.UserIndex =
TabDeploy.DeployUserName
WHERE (((TabUsers.UserIndex)<>[TabDeploy]![DeployUserName]))
ORDER BY TabUsers!UserPrenom & " " & TabUsers!UserNom;

Je m'égare non ?



J'ai surtout l'impression que tu essayes d'additionner des choux-fleurs
et des poulets ;
tu écris :

" DeployHostNumSerial et DeployUserName sont respectivement en relation "
Si j'en crois les noms des champs, un numéro de série en relation avec un
nom d'utilisateur ???

" INNER JOIN TabDeploy ON TabUsers.UserIndex = TabDeploy.DeployUserName
La tu établis une autre relation, mais toujours avec mariage de la carpe
"userindex" avec le lapin "Deployusername"... ce qui explique que ta
requête soit vide, car il n'y a aucune concordance.

" WHERE (((TabUsers.UserIndex)<>[TabDeploy]![DeployUserName]))"
Instruction contradictoire avec la jointure ci-dessus !

@+

Etienne.

Avatar
Ziggy
Non Etienne, je ne pense pas confondre coco et abricot.
Tous mes champs sont de types numériques.
Elles ont toute l'index en NumAuto et les relations sont indéxées sans
doublon car un seul utilisateur peu avoir un seul numéro.
Peut-être que ma requête "Nom Complet" sème la sisanie .... mais mon
explication voulait dire :
* que TblHosts.HostIndex est en relation un à un avec avec le champ
TblDeploy.DeployHostNumSerial
* que TblUsers.UserIndex est en relation un à un avec avec le champ
TblDeploy.DeployUserName
Donc pour reprendre plus précisemment,
Dans mon formulaire FrmDeploy, ma liste lstDeployUser doit contenir tous les
utilisateurs qui non jamais été choisi préalablement.
Il me semble que c'est une soustraction mais en SQL, je ne sais pas
l'exprimer.
Merci de ton attention

Thierry


"Evaro" a écrit dans le message de news:


"Ziggy" a écrit dans le message de news:

Merci Phil et Evaro

Bon, j'ai essayé mais ma requête est vide.
Voici un peu plus de détails.
Mon formulaire FrmDeploy renseigne la table TblDeploy contenant les
champs DeployIndex, DeployHostNumSerial, DeployUserName
DeployHostNumSerial et DeployUserName sont respectivement en relation un
à un avec TblHosts et TblUsers
Un exemple de mes essais qui m semble se rapprocher le plus :

SELECT TabUsers.UserIndex, TabUsers!UserPrenom & " " & TabUsers!UserNom
AS [Nom complet]
FROM TabUsers INNER JOIN TabDeploy ON TabUsers.UserIndex =
TabDeploy.DeployUserName
WHERE (((TabUsers.UserIndex)<>[TabDeploy]![DeployUserName]))
ORDER BY TabUsers!UserPrenom & " " & TabUsers!UserNom;

Je m'égare non ?



J'ai surtout l'impression que tu essayes d'additionner des choux-fleurs et
des poulets ;
tu écris :

" DeployHostNumSerial et DeployUserName sont respectivement en relation "
Si j'en crois les noms des champs, un numéro de série en relation avec un
nom d'utilisateur ???

" INNER JOIN TabDeploy ON TabUsers.UserIndex = TabDeploy.DeployUserName
La tu établis une autre relation, mais toujours avec mariage de la carpe
"userindex" avec le lapin "Deployusername"... ce qui explique que ta
requête soit vide, car il n'y a aucune concordance.

" WHERE (((TabUsers.UserIndex)<>[TabDeploy]![DeployUserName]))"
Instruction contradictoire avec la jointure ci-dessus !

@+

Etienne.







Avatar
Evaro
Je voudrais bien t'aider mais j'ai beaucoup de mal à te suivre ;
Je crains que tu ne sois parti sur de mauvaises bases.
Reprenons du début :
Le but de ce formualire est d'attribuer un n° à un utilisateur.


Pourquoi ne pas avoir mis un champ NuméroAuto ?

Pourquoi trois tables :
- TblUsers
- TblDeploy
- TblHosts ?
Nom, Type des Clefs Primaires et Clefs Externes ?

Tous mes champs sont de types numériques.
Elles ont toute l'index en NumAuto


Tu ne peux pas faire de relation entre deux tables sur deux champs NumAuto ;

Le Type NumAuto convient à la clef primaire, pas à la clef externe qui doit
avoir le type numérique, Entier long s'il veut établir une relation avec un
Champ NumAuto.

les relations sont indéxées sans doublon car un seul utilisateur peu avoir
un seul numéro.


Pas besoin de relation pour ça, la clef primaire fait très bien l'affaire.
Une relation établit un lien entre une table et une autre, par
l'intermédiaire d'un champ clé primaire (donc forcément indexé et sans
doublon) de l'une et un champ clef externe (indexé ou non, si oui avec (1 à
plusieurs) ou sans (1 à 1, mais pourquoi ?) doublons, mais pas en NumAuto)
de l'autre table ; à part ça, je ne vois pas ce qu'est une relation
indexée...

* que TblHosts.HostIndex est en relation un à un avec avec le champ
TblDeploy.DeployHostNumSerial


Bon, admettons, mais si ce n'est que pour faire de la relation un-à-un,
pourquoi ne pas mettre tous les champs dans une même table ?

* que TblUsers.UserIndex est en relation un à un avec avec le champ
TblDeploy.DeployUserName


Je maintiens que si TblUsers.UserIndex contient "007" et
TblDeploy.DeployUserName contient "James Bond", tu ne peux pas retrouver
ton agent secret par une relation, fût-elle indexée ;-)))

Peut-être que ma requête "Nom Complet" sème la sisanie


Non ce n'est pas de là que ça vient, mais de la conception de tes tables,
avec leurs clefs et leurs relations.

Quant au formulaire, ce n'est que la face émergée de l'iceberg...

@+

Etienne

Avatar
Ziggy
Merci de te donner tous ce mal pour m'aider.

Pour reprendre au début j'efface tout (le fil servira d'historique)
Le but :
Il y a des machines, des utilisateurs, et chaque machine est attribuée à un
utilisateur.
Il ne peut exister qu'un utilisateur pour une seule machine.

Les tables :
1 - Tbl Users
UserIndex NumAuto
UserName Texte
2 - Tbl Hosts
HostIndex NumAuto
HostNumSerial Texte
3 - TblDeploy
DeployIndex NumAuto
DeployUser Numérique (indéxé sans doublon)
DeployHost Numérique (indéxé sans doublon)

Relations :
TblUsers.UserIndex 1à1 TblDeploy.DeployUser
TblHosts.HostIndex 1à1 TblDeploy.DeployHost

Formulaire:
FrmDeploy
lstUserName
Affichage du nom de l'utilisateur UserName et récupération du numéro d'index
UserIndex dans TblDeploy.DeployUser
SELECT TblUsers.UserIndex, TblUsers.UserName

FROM TblUsers

ORDER BY TblUsers.UserName;

lstHostNumSerial
Affichage du numéro de série HostNumSerila et récupération du numéro d'index
HostIndex dans TblDeploy.DeployNumSerial
SELECT TblHosts.HostIndex, TblHosts.HostNumSerial

FROM TblHosts

ORDER BY TblHosts.HostNumSerial;



Ceci fonctioonne trés bien mais pour affiner, j'aimerai que dans les listes,
si l'élément a déjà été choisi, qu'il ne fasse plus parti de la liste.



Celà me parait une structure standard mais je suis autodidacte. Alors je
suis ouvert à tout commentaire.



Thierry
Avatar
Evaro
Ok, je vois un peu mieux.

Mais dans la série "Pourquoi faire simple quand on peut faire compliqué",
si un utilisateur n'utilise qu'une machine et qu'une machine ne peut être
attribuée qu'à un seul utilisateur, je maintiens qu'une seule table
suffisait, appelons la TblDeploy avec les champs DeployIndex , DeployUser,
DeployHost, HostNumSerial, Username, ....
Même une feuille Excel ferait l'affaire, s'il n'y a que cela.
Tu pourrais rechercher les utilisateurs sans machine avec

SELECT DeployUser , UsernameHost FROM TblDeploy WHERE
TblDeploy.DeployHost is Null


et les machines sans utilisateurs avec

SELECT DeployHost, HostNumSerial FROM TblDeploy WHERE
TblDeploy.DeployUser is Null.

Sinon ta construction est parfaite pour le cas d'une relation de plusieurs à
plusieurs
(un Utilisateur peut utiliser plusieurs machines et une machine peut être
utilisée par plusieurs utilisateurs), la table tblDeploy servant de table
intermédiaire, puisque la relation directe de plusieurs à plusieurs entre
deux tables n'est pas possible ; il suffirait que les champs
tblDeploy.DeployHost et tblDeploy.DeployUser soient indexées avec doublons
(ou pas indexées du tout, l'index ne servant en l'occurence qu'à accélérer
les requêtes, mais ça ne serait justifié qu'à partir de plusieurs dizaines
de milliers d'enregistrements).

Quoiqu'il en soit, relation un à un ou un à plusieurs, les utilisateurs sans
machine te seront donnés avec :

SELECT tblUsers.UserIndex, tblUsers.UserName, tblDeploy.DeployIndex
FROM tblUsers LEFT JOIN tblDeploy ON tblUsers.UserIndex =
tblDeploy.DeployUser
WHERE (((tblDeploy.DeployIndex) Is Null))
ORDER BY tblUsers.UserName;
Avatar
Ziggy
Super Etienne !
C'est de cette requête que j'avais besoin.
SELECT tblUsers.UserIndex, tblUsers.UserName, tblDeploy.DeployIndex
FROM tblUsers LEFT JOIN tblDeploy ON tblUsers.UserIndex =
tblDeploy.DeployUser
WHERE (((tblDeploy.DeployIndex) Is Null))
ORDER BY tblUsers.UserName;
Il est vrai qu'une feuille Excel suffirait mais les utilisateurs sont saisis

par une autre personne et sont dans une autre base.
Les machines sont extraites de la gestion commerciale lors de leurs
livraisons.
Il ne me restait plus qu'à les attribuées lors du déploiement.

Encore merci


"Evaro" a écrit dans le message de news:
%
Ok, je vois un peu mieux.

Mais dans la série "Pourquoi faire simple quand on peut faire compliqué",
si un utilisateur n'utilise qu'une machine et qu'une machine ne peut être
attribuée qu'à un seul utilisateur, je maintiens qu'une seule table
suffisait, appelons la TblDeploy avec les champs DeployIndex ,
DeployUser, DeployHost, HostNumSerial, Username, ....
Même une feuille Excel ferait l'affaire, s'il n'y a que cela.
Tu pourrais rechercher les utilisateurs sans machine avec

SELECT DeployUser , UsernameHost FROM TblDeploy WHERE
TblDeploy.DeployHost is Null


et les machines sans utilisateurs avec

SELECT DeployHost, HostNumSerial FROM TblDeploy WHERE
TblDeploy.DeployUser is Null.

Sinon ta construction est parfaite pour le cas d'une relation de plusieurs
à plusieurs
(un Utilisateur peut utiliser plusieurs machines et une machine peut être
utilisée par plusieurs utilisateurs), la table tblDeploy servant de table
intermédiaire, puisque la relation directe de plusieurs à plusieurs entre
deux tables n'est pas possible ; il suffirait que les champs
tblDeploy.DeployHost et tblDeploy.DeployUser soient indexées avec doublons
(ou pas indexées du tout, l'index ne servant en l'occurence qu'à accélérer
les requêtes, mais ça ne serait justifié qu'à partir de plusieurs dizaines
de milliers d'enregistrements).

Quoiqu'il en soit, relation un à un ou un à plusieurs, les utilisateurs
sans machine te seront donnés avec :