[..] Requêtes SQL
Règles du forum
- Merci de consulter la section "Règles du forum" et plus particulièrement "Règles et Mentions Légales du site autoitscript.fr" avant d'écrire un message.
Re: [..] Requêtes SQL
J'ai parlé trop vite, je viens de réussir à l'instant...
-
jchd
- AutoIt MVPs (MVP)
- Messages : 2282
- Enregistré le : lun. 30 mars 2009 22:57
- Localisation : Sud-Ouest de la France (43.622788,-1.260864)
- Status : Hors ligne
Re: [..] Requêtes SQL
Très bien. Je te laisse mariner un moment dans tout ça, il te faut un petit temps pour t'y faire et c'est normal.
Au passage, Expert décore les noms de schéma (tables, colonnes, vues, ...) avec soit des doubles quotes "abc" soit des crochets droits [abc]. Tu peux aller dans les options pour choisir plutôt "abc" qui est je trouve plus standard et plus facile à lire et éventuellement à composer si espace(s) dans le nom, par exemple "Un nom de table sacrément compliqué contenant ∌↻╩ựຣփЊЖ est un nom de table comme un autre". Ces doubles quotes (ou crochets) ne sont pas nécessaires si le nom ne comporte pas d'espace.
(Je n'avais pas osé mettre des mots anglais de mon propre chef...)
Si tu veux voir (par simple curiosité) du SQL qui perfore, jette un oeil à cet ancien post : https://www.autoitscript.com/forum/topi ... nt=1232364
Un poil moins complexe, mais demande un bon fauteuil quand même : https://www.autoitscript.com/forum/topi ... nt=1233132
Ces deux trucs sont un peu extrêmes, je te l'accorde, mais même un simple petit moteur comme SQLite permet bien plus de choses que tu ne vois implémentées dans la base que j'ai proposé comme maquette. Tu ne le sais certainement pas, mais tu es environné de SQLite : dans ta télé connectée, ton smartphone, ta box, ton GPS, ton routeur (souvent), toute copie de FireFox et de plein de softs Adobe et autres, Windows 8+, ... Et en plus, toute base est portable telle quelle sur toute plate-forme existante,c'est magique !
Au passage, Expert décore les noms de schéma (tables, colonnes, vues, ...) avec soit des doubles quotes "abc" soit des crochets droits [abc]. Tu peux aller dans les options pour choisir plutôt "abc" qui est je trouve plus standard et plus facile à lire et éventuellement à composer si espace(s) dans le nom, par exemple "Un nom de table sacrément compliqué contenant ∌↻╩ựຣփЊЖ est un nom de table comme un autre". Ces doubles quotes (ou crochets) ne sont pas nécessaires si le nom ne comporte pas d'espace.
(Je n'avais pas osé mettre des mots anglais de mon propre chef...)
Si tu veux voir (par simple curiosité) du SQL qui perfore, jette un oeil à cet ancien post : https://www.autoitscript.com/forum/topi ... nt=1232364
Un poil moins complexe, mais demande un bon fauteuil quand même : https://www.autoitscript.com/forum/topi ... nt=1233132
Ces deux trucs sont un peu extrêmes, je te l'accorde, mais même un simple petit moteur comme SQLite permet bien plus de choses que tu ne vois implémentées dans la base que j'ai proposé comme maquette. Tu ne le sais certainement pas, mais tu es environné de SQLite : dans ta télé connectée, ton smartphone, ta box, ton GPS, ton routeur (souvent), toute copie de FireFox et de plein de softs Adobe et autres, Windows 8+, ... Et en plus, toute base est portable telle quelle sur toute plate-forme existante,c'est magique !
La cryptographie d'aujourd'hui c'est le taquin plus l'électricité.
Re: [..] Requêtes SQL
C'est encore moi 
, j'ai entrevu tes posts et je dois dire que... bin c'est bien compliqué ^^
Pour la gestion de mon "parc", je dois dire que je me suis franchement inspiré de tes bases et je pense que je vais statuer sur cette partie (elle évoluera sûrement avec la suite...
) .
Maintenant, il faut que je sache à l'instant "t", quels équipements sont montés sur quelles stations, quels équipements sont en stock, quels équipements sont en réparation au sein de l'entreprise, quels équipements sont en réparation à l'extérieur, et évidemment leur historique de réparation (ce qui a été remplacé), et enfin si par réparable, la mise au rebut de l'équipement.
Voilà, en fait je me répète souvent dans mes postes
Donc, je vais me pencher sur cette douloureuse deuxième partie...
Bref, je vais aller acheter du café et du doliprane...
, j'ai entrevu tes posts et je dois dire que... bin c'est bien compliqué ^^Pour la gestion de mon "parc", je dois dire que je me suis franchement inspiré de tes bases et je pense que je vais statuer sur cette partie (elle évoluera sûrement avec la suite...
) .Maintenant, il faut que je sache à l'instant "t", quels équipements sont montés sur quelles stations, quels équipements sont en stock, quels équipements sont en réparation au sein de l'entreprise, quels équipements sont en réparation à l'extérieur, et évidemment leur historique de réparation (ce qui a été remplacé), et enfin si par réparable, la mise au rebut de l'équipement.
Voilà, en fait je me répète souvent dans mes postes
Donc, je vais me pencher sur cette douloureuse deuxième partie...
Bref, je vais aller acheter du café et du doliprane...
-
jchd
- AutoIt MVPs (MVP)
- Messages : 2282
- Enregistré le : lun. 30 mars 2009 22:57
- Localisation : Sud-Ouest de la France (43.622788,-1.260864)
- Status : Hors ligne
Re: [..] Requêtes SQL
Bonsoir,
Je ne me suis pas trop lancé dans la gestion de la maintenance car tu me disais avoir dû modifier pas mal de choses, outre les noms du schéma.
L'idée sur laquelle je suis parti est que la mintenance regroupe tout l'historique, idéalement : entrée en stock, installation sur un poste, retrait car panne ou autre, installation d'un autre équipement en remplacement, mise en atelier de réparation ou retour fournisseur (ou déchetterie) de l'équipement retiré. Comme tout doit être daté, on devrait pouvoir retracer tout l'historique du parc complet (une fois renseigné) à n'importe quelle date et même à la seconde près si on veut gérer ça au chrono.
Des requêtes plus spécialisées permettent de voir tout ce qui est en stock, en atelier mécanique, etc. Ca ou, pourquoi pas, tout le parc Staübli connu dans la boutique et où il est, dans quel état, etc. De la même façon, extraire l'historique des maintenances sur un poste, sur un type d'équipement, sur une ligne ou bien encore comparer les taux de panne des poignets de robot sur les derniers 18 mois, en fonction des outils qu'ils emploient(*). Les possibilités là sont énormes et flexibles si on met en place ce qu'il convient.
En fait, là-dedans il n'y a rien de vraiment compliqué en soi. La complexité résulte de la juxtaposition ou plutôt la mise en relation de choses simples et mieux elles sont délimitées et leurs relation claires, plus facile en est l'articulation.
La transcription dans un paradigme calculatoire (un langage de programmation si tu préfères) est d'autant facilitée par le fait que ce langage permet facilement la manipulation de données ayant des relations entre elles et, de ce point de vue, SQL est très fort. Il te permet de lui demander ce que tu souhaites obtenir alors qu'avec un langage procédural tu es contraint de décrire dans tous les détails la façon d'obtenir ce que tu souhaites. La nuance est importante dès que les informations manipulées sont non triviales en volume et/ou en diversité. Ainsi, si le moteur SQL (son "query planner") estime qu'il doit créer une table intermédiaire (ou plusieurs) avec des index temporaires pour réaliser l'opération que tu demandes, cela restera transparent pour toi, ce qui n'est pas du tout le cas avec un langage de programmation procédural ou même fonctionnel, où l'on doit tout se cogner à la mimine.
(*) Si tu devais coder en AutoIt un truc pareil, tu pourrais y passer un certain temps ! Et si ton boss ajoute "un rapport par ligne et un autre toutes lignes confondues", ton algo procédural est par terre alors qu'il suffit d'ajuster un peu la requête SQL pour faire les deux.
Après il ne faut pas tomber dans un dogmatisme imbécile : il y a des choses qu'il convient de faire en code, d'autres en regexp, d'autres en SQL, etc.
Donc, montre-moi où tu es es quand tu estimeras que les briques élémentaires sont en place (ou dis-moi où ça coince) et on pourra avancer vers des points plus concrets. N'oublie pas que je t'ai passé mes coordonnées et qu'on peut se prendre un moment au téléphone pour progresser plus vite.
Over.
Je ne me suis pas trop lancé dans la gestion de la maintenance car tu me disais avoir dû modifier pas mal de choses, outre les noms du schéma.
L'idée sur laquelle je suis parti est que la mintenance regroupe tout l'historique, idéalement : entrée en stock, installation sur un poste, retrait car panne ou autre, installation d'un autre équipement en remplacement, mise en atelier de réparation ou retour fournisseur (ou déchetterie) de l'équipement retiré. Comme tout doit être daté, on devrait pouvoir retracer tout l'historique du parc complet (une fois renseigné) à n'importe quelle date et même à la seconde près si on veut gérer ça au chrono.
Des requêtes plus spécialisées permettent de voir tout ce qui est en stock, en atelier mécanique, etc. Ca ou, pourquoi pas, tout le parc Staübli connu dans la boutique et où il est, dans quel état, etc. De la même façon, extraire l'historique des maintenances sur un poste, sur un type d'équipement, sur une ligne ou bien encore comparer les taux de panne des poignets de robot sur les derniers 18 mois, en fonction des outils qu'ils emploient(*). Les possibilités là sont énormes et flexibles si on met en place ce qu'il convient.
En fait, là-dedans il n'y a rien de vraiment compliqué en soi. La complexité résulte de la juxtaposition ou plutôt la mise en relation de choses simples et mieux elles sont délimitées et leurs relation claires, plus facile en est l'articulation.
La transcription dans un paradigme calculatoire (un langage de programmation si tu préfères) est d'autant facilitée par le fait que ce langage permet facilement la manipulation de données ayant des relations entre elles et, de ce point de vue, SQL est très fort. Il te permet de lui demander ce que tu souhaites obtenir alors qu'avec un langage procédural tu es contraint de décrire dans tous les détails la façon d'obtenir ce que tu souhaites. La nuance est importante dès que les informations manipulées sont non triviales en volume et/ou en diversité. Ainsi, si le moteur SQL (son "query planner") estime qu'il doit créer une table intermédiaire (ou plusieurs) avec des index temporaires pour réaliser l'opération que tu demandes, cela restera transparent pour toi, ce qui n'est pas du tout le cas avec un langage de programmation procédural ou même fonctionnel, où l'on doit tout se cogner à la mimine.
(*) Si tu devais coder en AutoIt un truc pareil, tu pourrais y passer un certain temps ! Et si ton boss ajoute "un rapport par ligne et un autre toutes lignes confondues", ton algo procédural est par terre alors qu'il suffit d'ajuster un peu la requête SQL pour faire les deux.
Après il ne faut pas tomber dans un dogmatisme imbécile : il y a des choses qu'il convient de faire en code, d'autres en regexp, d'autres en SQL, etc.
Donc, montre-moi où tu es es quand tu estimeras que les briques élémentaires sont en place (ou dis-moi où ça coince) et on pourra avancer vers des points plus concrets. N'oublie pas que je t'ai passé mes coordonnées et qu'on peut se prendre un moment au téléphone pour progresser plus vite.
Over.
La cryptographie d'aujourd'hui c'est le taquin plus l'électricité.
Re: [..] Requêtes SQL
Une problématique vient subitement de me "sauter au visage".
Je veux savoir à l'intant "t" où se trouve mon matériel, oui mais...
Hypothèse:
J'ai un équipement qui me génère des défauts, je ne le remplace pas par un autre qui est en stock, mais je l'inverse avec celui d'une autre station. Plus de défauts...
La personne qui est intervenue ne pensera pas à modifier (pour "x" raisons ou par flemmardise ) l'emplacement des équipements, donc pas de mise à jour, donc la configuration est faussée... .
Donc après réflexion pour simplifier les choses (enfin je pense), pour l'emplacement des équipements:
-Faire un inventaire de l'emplacement des équipements avant diffusion de mon application, cela me donnera un aperçu + ou - fiable.
-Mon équipement est soit en ligne, soit hors ligne.
S'il est en ligne alors:
Je galère à trouver le lien entre les tables pour faire cette structure et me créer une vue "où sont mes équipements"...
EDIT (16:00) je sais récupérer l'ensemble uniquement avec 1 seule valeur de location mais je ne parviens ni à récupérer le nom de la location, ni faire une requête "globale" sans avoir à faire WHERE [Location] = x
Je ne me lance sûrement pas dans la partie maintenance tant que je ne pars pas avec une structure des équipements "nickel".
Si tu pouvais me conseiller stp
Ci-joint ma base:
DemoSQLite_hugues
Merci par avance.
Je veux savoir à l'intant "t" où se trouve mon matériel, oui mais...
Hypothèse:
J'ai un équipement qui me génère des défauts, je ne le remplace pas par un autre qui est en stock, mais je l'inverse avec celui d'une autre station. Plus de défauts...
La personne qui est intervenue ne pensera pas à modifier (pour "x" raisons ou par flemmardise
) l'emplacement des équipements, donc pas de mise à jour, donc la configuration est faussée... .Donc après réflexion pour simplifier les choses (enfin je pense), pour l'emplacement des équipements:
-Faire un inventaire de l'emplacement des équipements avant diffusion de mon application, cela me donnera un aperçu + ou - fiable.
-Mon équipement est soit en ligne, soit hors ligne.
S'il est en ligne alors:
- -Sur quelle station?
- 1./Est-il en stock?
- 2./Est-il en réparation interne?
- 3./Est-il en réparation fournisseur?
- 4./Est-il en prêt pour un autre site?
- 5./Est-il rebuté?
Je galère à trouver le lien entre les tables pour faire cette structure et me créer une vue "où sont mes équipements"...
EDIT (16:00) je sais récupérer l'ensemble uniquement avec 1 seule valeur de location mais je ne parviens ni à récupérer le nom de la location, ni faire une requête "globale" sans avoir à faire WHERE [Location] = x
SELECT [Description],
[Reference],
[Version],
[Location],
[LineName] || '_' || [CellNumber] || ' ' || [CellName] [Emplacement]
FROM [Arch_Equipment]
LEFT JOIN [Architecture] ON [Architecture_ArchitectureId] = [ArchitectureId]
NATURAL JOIN [Line]
NATURAL JOIN [Cells]
JOIN [Equipments] [E] ON [E].[EquipmentId] = [Arch_EquipId]
WHERE [Location] = - 4
[Reference],
[Version],
[Location],
[LineName] || '_' || [CellNumber] || ' ' || [CellName] [Emplacement]
FROM [Arch_Equipment]
LEFT JOIN [Architecture] ON [Architecture_ArchitectureId] = [ArchitectureId]
NATURAL JOIN [Line]
NATURAL JOIN [Cells]
JOIN [Equipments] [E] ON [E].[EquipmentId] = [Arch_EquipId]
WHERE [Location] = - 4
Si tu pouvais me conseiller stp
Ci-joint ma base:
DemoSQLite_hugues
Merci par avance.
Modifié en dernier par Hugues le ven. 25 nov. 2016 18:58, modifié 3 fois.
-
walkson
- Modérateur
- Messages : 1037
- Enregistré le : ven. 12 août 2011 19:49
- Localisation : Hurepoix
- Status : Hors ligne
Re: [..] Requêtes SQL
A tout hasard (j'ai pas tout suivi)
De renommer la base en xls, comme j'ai fait, permet de l'avoir sur le forum et de ne pas la perdre dans le temps pour ceux que le sujet intéresse
SELECT [Description],
[Reference],
[Version],
[LocationId],
[LineName] || '_' || [CellNumber] || ' ' || [CellName] [Emplacement]
FROM [Arch_Equipment]
LEFT JOIN [Architecture] ON [Architecture_ArchitectureId] = [ArchitectureId]
NATURAL JOIN [Line]
NATURAL JOIN [Cells]
JOIN [Equipments] [E] ON [E].[EquipmentId] = [Arch_EquipId]
WHERE [LocationId] = - 4
[Reference],
[Version],
[LocationId],
[LineName] || '_' || [CellNumber] || ' ' || [CellName] [Emplacement]
FROM [Arch_Equipment]
LEFT JOIN [Architecture] ON [Architecture_ArchitectureId] = [ArchitectureId]
NATURAL JOIN [Line]
NATURAL JOIN [Cells]
JOIN [Equipments] [E] ON [E].[EquipmentId] = [Arch_EquipId]
WHERE [LocationId] = - 4
De renommer la base en xls, comme j'ai fait, permet de l'avoir sur le forum et de ne pas la perdre dans le temps pour ceux que le sujet intéresse
- Fichiers joints
-
- FKznIUULjdI_Demo.SQLite.xls
- (480 Kio) Téléchargé 132 fois
Cordialement,
Walkson
"Horas non numero nisi serenas " Le canon de midi
(Je ne compte que les heures heureuses)
Walkson
"Horas non numero nisi serenas " Le canon de midi
(Je ne compte que les heures heureuses)
-
jchd
- AutoIt MVPs (MVP)
- Messages : 2282
- Enregistré le : lun. 30 mars 2009 22:57
- Localisation : Sud-Ouest de la France (43.622788,-1.260864)
- Status : Hors ligne
Re: [..] Requêtes SQL
Hugues,
Tu as remplacé une table qui te donnait, dans mon schéma, l'information que tu souhaites maintenant : "Parc" et sa vue associée (pour la lisibilité seulement) "LeParc".
Dans ta version au lieu de considérer "ce qui n'est pas installé sur une ligne" comme "installé sur une lligne virtuelle disposant de stations virtuelles ou non (réparation, stock, ...)" tu as dissocié ces notions, donc tu vas te compliquer la vie avec une indirection supplémentaire qui n'a pas de bonne raison d'être.
Dans "Parc" ou son équivalent sous un autre nom, tu dois insérer les équipements physiques et leur emplacement individuel au moment où tu saisis cette information. Pour un échange (en vue essai) de deux équipements interchangeables entre deux stations (virutelles ou réelles), tu fais une maintenance (deux évènements en fait) pour retirer les deux et une installation (deux, en fait) en les croisant. Ainsi ton parc est à jour.
Maintenant si tout le monde peut jouer avec la base au travers d'applis en libre-service et sans contrôle strict de la régularité des mouvements ou sans effectuer les modifications qui s'imposent, ta base sera très vite complètement déconnectée du réel et absolument inutile.
Autre point : dans ta demo, tu n'as mis aucun type et aucune clé étrangère, si bien qu'on peut lier des entités qui n'existent pas. Compare avec le schéma que j'avais pondu et tu verras ce que je veux dire : il te manque les types de données et au moins les CONSTRAINT ... REFERENCES ...
Tu as remplacé une table qui te donnait, dans mon schéma, l'information que tu souhaites maintenant : "Parc" et sa vue associée (pour la lisibilité seulement) "LeParc".
Dans ta version au lieu de considérer "ce qui n'est pas installé sur une ligne" comme "installé sur une lligne virtuelle disposant de stations virtuelles ou non (réparation, stock, ...)" tu as dissocié ces notions, donc tu vas te compliquer la vie avec une indirection supplémentaire qui n'a pas de bonne raison d'être.
Dans "Parc" ou son équivalent sous un autre nom, tu dois insérer les équipements physiques et leur emplacement individuel au moment où tu saisis cette information. Pour un échange (en vue essai) de deux équipements interchangeables entre deux stations (virutelles ou réelles), tu fais une maintenance (deux évènements en fait) pour retirer les deux et une installation (deux, en fait) en les croisant. Ainsi ton parc est à jour.
Maintenant si tout le monde peut jouer avec la base au travers d'applis en libre-service et sans contrôle strict de la régularité des mouvements ou sans effectuer les modifications qui s'imposent, ta base sera très vite complètement déconnectée du réel et absolument inutile.
Autre point : dans ta demo, tu n'as mis aucun type et aucune clé étrangère, si bien qu'on peut lier des entités qui n'existent pas. Compare avec le schéma que j'avais pondu et tu verras ce que je veux dire : il te manque les types de données et au moins les CONSTRAINT ... REFERENCES ...
La cryptographie d'aujourd'hui c'est le taquin plus l'électricité.
Re: [..] Requêtes SQL
Re,
Il est vrai qu'en prenant du recul, j'ai clairement mal analysé la base que tu as créé...
Finalement j'ai fait un copier/coller de ta base (rajout d'une colonne ou deux, et renommer le nom des tables/colonnes en anglais, je ne sais pas si le nom est percutant pour quelqu'un d'autre que moi... ne pas hésiter à faire des remarques, ce qui est naturel pour moi ne l'ai pas pour les autres).
Ci-joint ma nouvelle base:
DemoRelease.
De plus, tout le monde n'aura pas "accès libre" à la base. Dans le concept de base j'aurai une interface graphique avec niveau d'accès bien sûr.
Le but de l'application est tu l'as tout de suite compris; j'ai un équipement défectueux sur une station x, ligne x, je le remplace par un autre. La personne qui a effectué l'opération de "maintenance", saisie son intervention via une application "Autoit" qui va renseigner dans ma base:
-Quelle ligne, quelle station, quand, quel équipement enlevé, quel equipement mis en place, son emplacement physique dans la station, son numéro de série, qui est intervenu, est un commentaire...(j'espère ne rien avoir oublié)
Une fois tout ces champs saisis, j'enregistre tout ça dans ma base ^^, ensuite dans la foulée je génère une page HTML pour être imprimée et jointe à l'équipement déféctueux et part pour réparation (soit interne ou externe) et mise à jour de mon parc bien sûr.
Si l'équipement est réparable alors, je saisi les opérations effectuées sur mon matériel pour avoir un historique (un peu le but du jeu...) et remise à jour du parc (passage de réparation à Stock), sinon mise au rebut direct (dans les 2 cas, saisie uniquement par la maintenance).
Voilà le concept, maintenant il faut que je me m'améliore sur les liaisons entre tables sinon, comme tu le dis cela va vite être une cacophonie de données...
Merci pour votre patience ^^
Il est vrai qu'en prenant du recul, j'ai clairement mal analysé la base que tu as créé...
Finalement j'ai fait un copier/coller de ta base (rajout d'une colonne ou deux, et renommer le nom des tables/colonnes en anglais, je ne sais pas si le nom est percutant pour quelqu'un d'autre que moi... ne pas hésiter à faire des remarques
, ce qui est naturel pour moi ne l'ai pas pour les autres).Ci-joint ma nouvelle base:
DemoRelease.
De plus, tout le monde n'aura pas "accès libre" à la base. Dans le concept de base j'aurai une interface graphique avec niveau d'accès bien sûr.
Le but de l'application est tu l'as tout de suite compris; j'ai un équipement défectueux sur une station x, ligne x, je le remplace par un autre. La personne qui a effectué l'opération de "maintenance", saisie son intervention via une application "Autoit" qui va renseigner dans ma base:
-Quelle ligne, quelle station, quand, quel équipement enlevé, quel equipement mis en place, son emplacement physique dans la station, son numéro de série, qui est intervenu, est un commentaire...(j'espère ne rien avoir oublié)
Une fois tout ces champs saisis, j'enregistre tout ça dans ma base ^^, ensuite dans la foulée je génère une page HTML pour être imprimée et jointe à l'équipement déféctueux et part pour réparation (soit interne ou externe) et mise à jour de mon parc bien sûr.
Si l'équipement est réparable alors, je saisi les opérations effectuées sur mon matériel pour avoir un historique (un peu le but du jeu...) et remise à jour du parc (passage de réparation à Stock), sinon mise au rebut direct (dans les 2 cas, saisie uniquement par la maintenance).
Voilà le concept, maintenant il faut que je me m'améliore sur les liaisons entre tables sinon, comme tu le dis cela va vite être une cacophonie de données...
Merci pour votre patience ^^
Re: [..] Requêtes SQL
Bon j'avance à petit pas, je pense que pour la structure de la base de données pour mes besoins va rester comme ça (presque celle initiale )
DemoFinal
J'ai ma table "maintenance" dans laquelle chaque retrait d'équipement d'une station sera saisie.
J'ai une table "_Interventions" dans laquelle seront renseignés les interventions effectués sur cet équipement.
A moins que j'eu omis les oeufs de cailles, la base est pas mal...
En parrallèle, j'ai commencé l'interface graphique pour l'affichage de la ligne, de la station. Pour ça j'ai pas trop de soucis, par contre je voudrais qu'une fois que l'on ai sélectionné la ligne et la station, une combobox soit remplit avec les équipements qui lui sont "attribués".
Par SQL OK, mais par AutoIt pas OK du tout...
Je trouve pas la logique entre les tables... Je sais qu'il faut jouer sur les Id... Il faut que je récupère
Je remplis ma combo ligne comme ça:
Ensuite ma combo station:
Et je voudrais alimenter ma combo equipment associés:
Merci par avance pour votre aide.
)DemoFinal
J'ai ma table "maintenance" dans laquelle chaque retrait d'équipement d'une station sera saisie.
J'ai une table "_Interventions" dans laquelle seront renseignés les interventions effectués sur cet équipement.
A moins que j'eu omis les oeufs de cailles, la base est pas mal...
En parrallèle, j'ai commencé l'interface graphique pour l'affichage de la ligne, de la station. Pour ça j'ai pas trop de soucis, par contre je voudrais qu'une fois que l'on ai sélectionné la ligne et la station, une combobox soit remplit avec les équipements qui lui sont "attribués".
Par SQL OK, mais par AutoIt pas OK du tout...
Je trouve pas la logique entre les tables... Je sais qu'il faut jouer sur les Id... Il faut que je récupère
Je remplis ma combo ligne comme ça:
$iRval = _SQLite_GetTable2d(-1, "SELECT * FROM Lines WHERE LineId BETWEEN '0' And '3' ;", $aLoadLine, $iRows, $iColumns)
If $iRval = $SQLITE_OK Then
For $i=1 To UBound($aLoadLine)-1
GUICtrlSetData($ComboBoxLine, $aLoadLine[$i][1])
Next
EndIf
If $iRval = $SQLITE_OK Then
For $i=1 To UBound($aLoadLine)-1
GUICtrlSetData($ComboBoxLine, $aLoadLine[$i][1])
Next
EndIf
_SQLite_QuerySingleRow(-1, "SELECT LineId FROM Lines WHERE LineName = '" & GUICtrlRead($ComboBoxLine) & "';", $aRowSearch)
;_ArrayDisplay($aRowSearch)
$_iRval = _SQLite_GetTable2d(-1, "SELECT LineName, Number, Name FROM LineConfig NATURAL JOIN Lines NATURAL JOIN Cells WHERE LineId='" & $aRowSearch[0] & "' ORDER BY LineId" & ";", $aCells, $_iRows, $_iColumns)
If $_iRval = $SQLITE_OK Then
;_ArrayDisplay($aCells)
For $i=1 To UBound($aCells)-1
GUICtrlSetData($ComboBoxCell, $aCells[$i][1] & " " & $aCells[$i][2])
Next
EndIf
;_ArrayDisplay($aRowSearch)
$_iRval = _SQLite_GetTable2d(-1, "SELECT LineName, Number, Name FROM LineConfig NATURAL JOIN Lines NATURAL JOIN Cells WHERE LineId='" & $aRowSearch[0] & "' ORDER BY LineId" & ";", $aCells, $_iRows, $_iColumns)
If $_iRval = $SQLITE_OK Then
;_ArrayDisplay($aCells)
For $i=1 To UBound($aCells)-1
GUICtrlSetData($ComboBoxCell, $aCells[$i][1] & " " & $aCells[$i][2])
Next
EndIf
Func _SQLSearchAssociatedEquipment()
$__iRval = _SQLite_GetTable2d(-1, "SELECT LineName, ConfigId, CASE WHEN ParcPosteId > 0 THEN Number ||' '|| Name ELSE Name END LineConfig, Description, Reference, parcserial FROM Parc LEFT JOIN LineConfig ON ParcPosteId = ConfigId NATURAL JOIN Lines NATURAL JOIN Cells JOIN Equipments E ON E.EquipId = ParcEquipId ORDER BY LineConfig;", $__aResult, $__iRows, $__iColumns)
If $__iRval = $SQLITE_OK Then
_ArrayDisplay($__aResult)
EndIf
EndFunc
$__iRval = _SQLite_GetTable2d(-1, "SELECT LineName, ConfigId, CASE WHEN ParcPosteId > 0 THEN Number ||' '|| Name ELSE Name END LineConfig, Description, Reference, parcserial FROM Parc LEFT JOIN LineConfig ON ParcPosteId = ConfigId NATURAL JOIN Lines NATURAL JOIN Cells JOIN Equipments E ON E.EquipId = ParcEquipId ORDER BY LineConfig;", $__aResult, $__iRows, $__iColumns)
If $__iRval = $SQLITE_OK Then
_ArrayDisplay($__aResult)
EndIf
EndFunc