Discussion :

[fsmrel]

Avez-vous essayez de n'entrer aucune date d'achat ni d'installation ni de désinstallation ???? Je me suis ramassé avec un 1900-xx-xx LoL

Pour ma part, j’obtiens le '9999-12-31' comme date d’achat par défaut : c’est conforme à ce qui est prévu dans le trigger TRANSMISSION_COMPOSANT_INSERT_TR. C’est ce qui se passe par exemple avec l’insert :

INSERT INTO TRANSMISSION_COMPOSANT_V (NumeroSerie, Fabriquant, Modele, TransmissionVitesses)
    SELECT 'Série tr01', 'Charlebois', 'modèle ch01', 12
;

Et c’est ce qui est répercuté pour la date d’installation de la transmission.

Utilisez-vous bien la vue TRANSMISSION_COMPOSANT_V pour créer les transmissions ?

En passant, comme date d’achat par défaut, on peut préférer recopier la date d’achat du camion, cela vous convient-il ?

[fsmrel]

C'est triste que Microsoft enlève ''Database Diagrams" de SSMS à partir de la version 18

Je ne savais pas.

Il y a la possibilité de faire de la rétro-conception avec MySQL Workbench, voyez ici. Bon, il faut virer les mots propres à SQL Server, tels que IDENTITY, mais ça ne va pas bien loin, et le résultat est quand même là.

[ordigil]

Oui, j'ai bien utilisé 'TRANSMISSION_COMPOSANT_V ' alors je ne comprend pas pourquoi. Je vais réessayer tout à l'heure….. Je mets à jours SSMS vers la version 17.9 pour l'instant….
Oui je trouve que c'est bien d'utiliser la date d'achat du camion. Et pour la date d'installation il serait bien d'utiliser la date de fabrication du camion lors de la création d'un nouveau camion….. Le moteur, la transmission, les essieux et les différentiels devraient tous avoir la date de fabrication du nouveau camion créé. Si j'achète un camion fabriqué le 2017-02-12, normalement la date d'installation de tous les composants est le 2017-02-12.... Mais on peut régler ce détail plus tard…. Ces petites choses pourront être mises à jour lorsque nous aurons enfin une version bêta complète de la BD LOL

Pour ma part, j’obtiens le '9999-12-31' comme date d’achat par défaut : c’est conforme à ce qui est prévu dans le trigger TRANSMISSION_COMPOSANT_INSERT_TR. C’est ce qui se passe par exemple avec l’insert :

INSERT INTO TRANSMISSION_COMPOSANT_V (NumeroSerie, Fabriquant, Modele, TransmissionVitesses)
    SELECT 'Série tr01', 'Charlebois', 'modèle ch01', 12
;

Et c’est ce qui est répercuté pour la date d’installation de la transmission.

Utilisez-vous bien la vue TRANSMISSION_COMPOSANT_V pour créer les transmissions ?

En passant, comme date d’achat par défaut, on peut préférer recopier la date d’achat du camion, cela vous convient-il ?

[ordigil]

Oh vraiment ??? Il y a tellement de gens de déçus….Il n'y a que les puristes qui sont contents…. Je regarderai plus tard, de toute façon la version 18 est encore en version Bêta….

Je ne savais pas.

Il y a la possibilité de faire de la rétro-conception avec MySQL Workbench, voyez ici. Bon, il faut virer les mots propres à SQL Server, tels que IDENTITY, mais ça ne va pas bien loin, et le résultat est quand même là.

[ordigil]

ahhhhhh c'est si je fais ça que j'obtiens 1900-01-01 LoL

INSERT INTO TRANSMISSION_COMPOSANT_V (NumeroSerie, DateAchat, Fabriquant, Modele, TransmissionVitesses)
    SELECT 'MERIT001','', 'MERITOR', 'RTLO-16918A', 18
;

    NumeroSerie         DateAchat       Fabriquant      Modele          TransmissionVitesses
    Série tr01          2012-07-01      Charlebois      modèle ch01     12
    S0784828            2012-07-02      Eaton Fuller    RTLO-16913A     13
    tr018               2012-07-02      Charlebois      modèle 18       3
    MERITT938475UT      2017-01-01      Meritor         RTLO-16918A     18
    S1128413            9999-12-31      FULLER          RTLO-16918B     18
    MERIT001            1900-01-01      MERITOR         RTLO-16918A     18

[ordigil]

Dans la Table 'Differential' nous avons un petit problème. Le GVWR d'un 'AXLE' et de son 'DIFFERENTIAL' est le poids que peut tirer l'AXLE et son 'DIFFERENTIAL' alors que le GVWR du 'CAMION' est le poids que peut supporter le 'CAMION' sur ses essieux. Ce n'est pas tout à fait exact mais dans notre base de données c'est un compromis que nous faisons pour se rapprocher de la réalité….. Je peux avoir un Camion avec un GVWR de 52 000 LBS qui a tandem avec un GAWR de 40 000 LBS et un GVWR de 135 000 LBS.... Donc ce Camion peut supporter un poids de 52 000 LBS ( qui inclus le poids du chargement, le poids du chauffeur, le poids des passagers, le poids du gasoil dans ses réservoirs) au total réparti sur tous ses essieux mais qui peut supporter un poids maximal de 40 000 LBS sur le tandem et tirer un poids total de 135 000 LBS.... Un exemple est un camion qui tire une remorque… Le camion a un GVWR de 52000 LBS mais il tire 2 remorques qui ont chacune un chargement de 45 000 LBS…. Le grand total se nomme 'GROSS VEHICLE WEIGHT' et serait d'environ 135 000 LBS donc le camion ne supporte pas 135 000 LBS sur ses essieux mais le tandem doit être capable de tirer 135 000 LBS… Donc 'smallint' n'est pas un bon choix pour le GVWR des AXLE et DIFFERENTIAL


Devinez le GVWR du Camion sur cette photo et le GVWR de ses AXLE/DIFFERENTIAL

Pièce jointe 426804

[fsmrel]

Bonjour Ordigil,

c'est si je fais ça que j'obtiens 1900-01-01 LoL

INSERT INTO TRANSMISSION_COMPOSANT_V (NumeroSerie, DateAchat, Fabriquant, Modele, TransmissionVitesses)
    SELECT 'MERIT001','', 'MERITOR', 'RTLO-16918A', 18
;

    NumeroSerie         DateAchat       Fabriquant      Modele          TransmissionVitesses
    Série tr01          2012-07-01      Charlebois      modèle ch01     12
    S0784828            2012-07-02      Eaton Fuller    RTLO-16913A     13
    tr018               2012-07-02      Charlebois      modèle 18       3
    MERITT938475UT      2017-01-01      Meritor         RTLO-16918A     18
    S1128413            9999-12-31      FULLER          RTLO-16918B     18
    MERIT001            1900-01-01      MERITOR         RTLO-16918A     18

D’accord. Ce crétin de SGBD remplace tout de suite '' par '1900-01-01', donc je rattrape le coup dans le trigger : si on a ça une date d’achat antérieure à 1940, je force à '9999-12-31'. Même chose pour les autres types de composants.

Il faudra que je vérifie de ce qu’il en est des autres dates (notamment dates d’installation), mais chaque chose en son temps, il y a des priorités...

Je mets à jour les bases de données Temp et DZINDZIO_TRUCKS_MANAGEMENT_TEMP.

[ordigil]

Bonjour fsmrel

Je vais avoir un problème pour entrer les Différentiels si je ne connais pas le GVWR et le Torque leur création dans la BD parce que dans 'DIFFERENTIAL_GVWR_CHK', GVWR > 0 ….

Lors de la création des AXLE si je ne connais le GVWR et le Torque, je mets 0 dans ces deux colonnes…..
Lors de la création des DIFFERENTIAL, 0 est refusé comme valeur….

[ordigil]

Pas un DROP Table avant un BACKUP n'est-ce pas ????

Bonjour Ordigil,




D’accord. Ce crétin de SGBD remplace tout de suite '' par '1900-01-01', donc je rattrape le coup dans le trigger : si on a ça une date d’achat antérieure à 1940, je force à '9999-12-31'. Même chose pour les autres types de composants.

Il faudra que je vérifie de ce qu’il en est des autres dates (notamment dates d’installation), mais chaque chose en son temps, il y a des priorités...

Je mets à jour les bases de données Temp et DZINDZIO_TRUCKS_MANAGEMENT_TEMP.

[ordigil]

Je suis au travail alors je ne peut pas rester :-(( On se parle plus tard…

[fsmrel]

Pas un DROP Table avant un BACKUP n'est-ce pas ?

J’en suis resté à :

Ok je vous donne 'DZINDZIO_TRUCKS_MANAGEMENT_TEMP', vous n'aurez pas besoin de mon feu vert pour en faire ce que vous voulez.

Donc j'ai mis à jour.

Comment savoir que vous avez en réalité encore besoin de faire un backup avant que je ne mette à jour ?

Je vais essayer de trouver un moyen de faire les mises à jour sans impacter les tables.

[fsmrel]

Lors de la création des AXLE si je ne connais le GVWR et le Torque, je mets 0 dans ces deux colonnes…..
Lors de la création des DIFFERENTIAL, 0 est refusé comme valeur….

Bon, dans la déclaration de la table DIFFERENTIAL je supprime les contraintes :

DIFFERENTIAL_GVWR_CHK CHECK (DiffGVWR > 0)

DIFFERENTIAL_TORQUE_CHK CHECK (DiffTorque > 0)

Attention aux divisions par zéro

[ordigil]

Ah vous aviez pensez à prendre la Vue 'TRANSMISSION_AFFECTATION_CAMION'

J’en suis resté à :
Donc j'ai mis à jour.

Comment savoir que vous avez en réalité encore besoin de faire un backup avant que je ne mette à jour ?

Je vais essayer de trouver un moyen de faire les mises à jour sans impacter les tables.

[ordigil]

C'est vrai qu'il serait plus logique de mettre des 1 partout au lieu des 0 mais bon on est partie avec des 0....

Bon, dans la déclaration de la table DIFFERENTIAL je supprime les contraintes :

DIFFERENTIAL_GVWR_CHK CHECK (DiffGVWR > 0)

DIFFERENTIAL_TORQUE_CHK CHECK (DiffTorque > 0)

Attention aux divisions par zéro

[fsmrel]

Devinez le GVWR du Camion sur cette photo et le GVWR de ses AXLE/DIFFERENTIAL

Selon la méthode papoue, la réponse est : beaucoup ! Mais je note que ce camion roule à l’anglaise, à gauche, donc pas chez nous, mais peut-être chez la perfide Albion...

[ordigil]

En effet ce camion traverse le desert en Australie

Celui-ci est canadien

Pièce jointe 427032

Selon la méthode papoue, la réponse est : beaucoup ! Mais je note que ce camion roule à l’anglaise, à gauche, donc pas chez nous, mais peut-être chez la perfide Albion...

[fsmrel]

Bonsoir Ordigil,


Base DZINDZIO_TRUCKS_MANAGEMENT_TEMP : normalement, j’ai remplacé SMALLINT par INT pour les colonnes DiffGVWR (table DIFFERENTIAL) et AxleGVWR (table AXLE), sans toucher au reste...

Pouvez-vous vérifier que c’est bon ?

[ordigil]

Bonjour fsmrel

Ok, je regarde

Bonsoir Ordigil,


Base DZINDZIO_TRUCKS_MANAGEMENT_TEMP : normalement, j’ai remplacé SMALLINT par INT pour les colonnes DiffGVWR (table DIFFERENTIAL) et AxleGVWR (table AXLE), sans toucher au reste...

Pouvez-vous vérifier que c’est bon ?

[fsmrel]

J’ai mis à jour le trigger DIFF_AFFECTATION_AXLE_INSERT_TR branché sur la vue DIFF_AFFECTATION_AXLE.

Je rappelle les fonctionnalités (outre la simplification de la saisie...) :

-- Ce trigger a pour objet de contrôler la bilocation :
-- Un seul essieu par différentiel
-- Un seul différentiel par essieu
--
-- Il permet aussi de s'assurer que le type du différentiel
-- et celui de l'essieu sont compatibles ;
--
-- Il permet aussi de s'assurer que l'essieu et le différentiel
-- viennent de chez le même manufacturier.

-- Il permet de s'assurer que les dates d'installation ne
-- sont pas < aux dates d'achat des différentiels et des essieux. 

Pourriez vous le secouer au moyen de mises à jour de la vue ?

Dans la foulée, j’ai installé le trigger DIFF_AFFECTATION_AXLE_UPDATE_TR qui contrôle les mises à jour de type UPDATE. Pas évident, vous me direz...

[fsmrel]

Ach ! J’ai oublié le trigger DIFF_AFFECTATION_AXLE_DELETE_TR...

Ça sera pour plus tard, car arrive l’heure de la musique...