Maintenance de camions

**fsmrel** · 13/10/2018, 23h59

Envoyé par ordigil

les INT ne seront pratiquement pas nécessaires mais plutôt tinyint. Et peut-être que nous devrions utiliser les bons Types de Données pour les colonnes car ça commence à occasionner des problèmes. J'ai des colonnes où il ne doit pas avoir de caractère mais uniquement des chiffres. Je mets toujours des VARCHAR par défaut lors de la création des tables pour la rapidité de création des tables et pour que tout passe sans problème et sans que je doive trop réfléchir à ce détail mais aussitôt que je suis fixé sur le type et la longueur, je remplace par le bon Type de Donnée. Et en plus, même les INT ne seront pratiquement pas nécessaires mais plutôt tinyint. On déterminera le meilleur choix. Je n'ai pas besoin d'un INT pour afficher un CamionNumber. les valeurs vont de 2300 à 2799 et de 23000 à 27999

Pour le CamionNumber, tinyint n’est pas un bon choix. En effet, la valeur maximale pour une CamionNumber serait égale à 255 : on est loin du compte ! Qui plus est, ce type ne fait pas partie de la norme SQL, et si un jour vous décidiez de passer à PostgreSQL, vous auriez de la misère puisqu’à bon droit il dédaigne tinyint. SMALLINT vous permet de grimper à 32767, donc en principe vous êtes dans les clous. Cela dit, si un jour la limite 27999 devait être repoussée, et manque de chance, qu’elle dépasse 32767, qui se fera du souci ? Avec INT, pas de problème, d’autant plus qu’il ne consomme que 4 octets (contre 2 octets pour SMALLINT), une misère...

**Oishiiii** · 14/10/2018, 00h15

Bonsoir ordigil, fsmrel, et tous les autres,

Je suis la conversation de loin, j'interviens juste au sujet de la sécurité.

Vous subissez des attaques parce que votre instance SQL Server est directement exposée à l'Internet et très certainement sur le port par défaut, 1433.

L'idéal serait que votre machine hébergeant SQL Server ne soit pas exposée à l'Internet.
Dans ce cas vous donneriez à fsmrel un accès VPN sur une autre machine dite "de management" (avec SSMS installé) qui elle accède à l'instance SQL.

Sans allez jusque là, essayez de changer le port d'écoute d'SQL Server pour 1437 par exemple, cela devrait réduire voir arrêter les tentatives de connexion.

Bonne continuation

**fsmrel** · 14/10/2018, 00h23

Ah ! Valeureux Oishiiii ! Heureux de votre visite. Que de souvenirs…

**fsmrel** · 14/10/2018, 00h26

Envoyé par ordigil

Vous faites ce que vous voulez avec "DZINDZIO_TRUCKS_MANAGEMENT_TEST"

A condition qu’elle existe. De toute façon, je travaille de préférence avec Temp, que je réinitialise systématiquement.

Quoi qu’il en soit, vous y trouverez la nouvelle mouture du trigger CAMION_LOCALISATION_UPDATE_TR pour la mise à jour via la vue CAMION_LOCALISATION_V.

Merci de vérifier ce que ça donne chez vous...

**ordigil** · 14/10/2018, 02h02

Je disait ça au hazard. Mes choix ne sont pas fixés, par contre il va falloir qu'il le soit bientôt

Pour les CamionNumber, en principe, les 2 premiers chiffres indiquent la province ou un regroupement de province. Alors 23 Nouveau-Brunswick, Nouvelle-Écosse, Île du Prince Édouard, Terre-Neuve. 25 Montréal, 26 Ontario, 27 Manitoba, Saskatchewan, 29 Alberta, Colombie Britannique. À l'origine les CamionsNumber ne comportaient que 4 chiffres. Pour Montréal 2500 à 2599, ce qui donnait seulement 100 Camions. Lorsqu'il y a eu plus de camions, la compagnie à tout simplement sortie des numéro à 5 chiffres. Donc de 25000 à 25999 pour Montréal. Ce qui donne 1000 Camions. Prochaine étape, peut-être des CamionNumber à 6 chiffre. 250000 à 259999. On regardera ça la semaine prochaine hahaha

Envoyé par fsmrel

Pour le CamionNumber, tinyint n’est pas un bon choix. En effet, la valeur maximale pour une CamionNumber serait égale à 255 : on est loin du compte ! Qui plus est, ce type ne fait pas partie de la norme SQL, et si un jour vous décidiez de passer à PostgreSQL, vous auriez de la misère puisqu’à bon droit il dédaigne tinyint. SMALLINT vous permet de grimper à 32767, donc en principe vous êtes dans les clous. Cela dit, si un jour la limite 27999 devait être repoussée, et manque de chance, qu’elle dépasse 32767, qui se fera du souci ? Avec INT, pas de problème, d’autant plus qu’il ne consomme que 4 octets (contre 2 octets pour SMALLINT), une misère...

**ordigil** · 14/10/2018, 02h05

"DZINDZIO_TRUCKS_MANAGEMENT_TEMP" Désolé

Donc c'est bien "DZINDZIO_TRUCKS_MANAGEMENT_TEMP" que vous avez mis à jour ????

Envoyé par fsmrel

A condition qu’elle existe. De toute façon, je travaille de préférence avec Temp, que je réinitialise systématiquement.

Quoi qu’il en soit, vous y trouverez la nouvelle mouture du trigger CAMION_LOCALISATION_UPDATE_TR pour la mise à jour via la vue CAMION_LOCALISATION_V.

Merci de vérifier ce que ça donne chez vous...

**ordigil** · 14/10/2018, 02h21

Bonjour Oishiiii, oui SQL Server est exposé directement sur internet pour l'instant ce qui ne sera pas le cas lorsque la base de données sera terminée, il ne sera plus exposé du tout. Pour l'instant 'sa' est désactivé. Pour le reste cela fait parti des tests de solidité que j'effectue sur SQL Server

Ça fait 2 mois que mon serveur est attaqué 24 heures par jour et les Chinois n'ont pas encore réussi à le hacker. Ce serveur ne sert qu'au développement, ce n'est pas un serveur de production.
Merci pour votre visite

Envoyé par Oishiiii

Bonsoir ordigil, fsmrel, et tous les autres,

Je suis la conversation de loin, j'interviens juste au sujet de la sécurité.

Vous subissez des attaques parce que votre instance SQL Server est directement exposée à l'Internet et très certainement sur le port par défaut, 1433.

L'idéal serait que votre machine hébergeant SQL Server ne soit pas exposée à l'Internet.
Dans ce cas vous donneriez à fsmrel un accès VPN sur une autre machine dite "de management" (avec SSMS installé) qui elle accède à l'instance SQL.

Sans allez jusque là, essayez de changer le port d'écoute d'SQL Server pour 1437 par exemple, cela devrait réduire voir arrêter les tentatives de connexion.

Bonne continuation

**ordigil** · 14/10/2018, 18h49

Toujours le même problème. Mes updates ne passent pas en utilisant "CAMION_LCALISATION_V. Toujours la même réponse, "Number" et "immat" existent déjà. Peut-être devrais-je concevoir mon site WEB différemment, ce qui veux dire tout recommencer….

**fsmrel** · 14/10/2018, 20h29

Envoyé par ordigil

Toujours le même problème. Mes updates ne passent pas en utilisant "CAMION_LCALISATION_V. Toujours la même réponse, "Number" et "immat" existent déjà. Peut-être devrais-je concevoir mon site WEB différemment, ce qui veux dire tout recommencer….

Comme je l’ai précisé dans mon précédent message, je n’ai mis à niveau que la base de données Temp. Je vais le faire pour DZINDZIO_TRUCKS_MANAGEMENT_TEMP (et non pas DZINDZIO_TRUCKS_MANAGEMENT_TEST...)

table CAMION : j’a remplacé le type de CamionNumber par INT et remplacé les valeurs par défaut '' par '0'.

Structure de la table CAMION :

CREATE TABLE CAMION 
(
        CamionId              INT             NOT NULL
      , CamionVIN             VARCHAR(24)     NOT NULL
      , CamionNumber          INT             NOT NULL DEFAULT 0
      , CamionImmat           VARCHAR(9)      NOT NULL DEFAULT '0'
      , CamionDateMfg         DATE            NOT NULL DEFAULT '9999-12-31'
      , CamionManufacturer    VARCHAR(15)     NOT NULL
      , CamionModel           VARCHAR(15)     NOT NULL DEFAULT '0'
      , CamionWheelBase       INT             NOT NULL DEFAULT 0 
      , CamionColor           VARCHAR(15)     NOT NULL DEFAULT 'White'
      , GVWR                  INT             NOT NULL DEFAULT 0
      , FRGAWR                INT             NOT NULL DEFAULT 0
      , [2NDGAWR]             INT             NOT NULL DEFAULT 0
      , [3RDGAWR]             INT             NOT NULL DEFAULT 0
      , [4THGAWR]             INT             NOT NULL DEFAULT 0
      , REARGAWR              INT             NOT NULL DEFAULT 0
      , USDOT                 VARCHAR(10)     NOT NULL DEFAULT '0'
      , ICCMC                 VARCHAR(10)     NOT NULL DEFAULT '0'
      , CamionDateAchat       DATE            NOT NULL DEFAULT '9999-12-31'
      , CamionDateVente       DATE            NOT NULL DEFAULT '9999-12-31'
    , CONSTRAINT CAMION_PK PRIMARY KEY (CamionId)
    , CONSTRAINT CAMION_VIN_AK UNIQUE (CamionVIN)
    , CONSTRAINT CAMION_LOCALISATION_FK FOREIGN KEY (CamionId) 
          REFERENCES  LOCALISATION (LocalisationId)
    , CONSTRAINT  CAMION_DATE_MFT_CHK CHECK (CamionDateMfg > '')
);

Je vous préviendrai dès que DZINDZIO_TRUCKS_MANAGEMENT_TEMP sera regénérée.

Je dois encore effectuer des tests de mise à jour par la vue.

**ordigil** · 14/10/2018, 21h14

Je crois que c'est une erreur de considérer CamionNumber comme un nombre, j'ai fait une erreur. Le CamionNumber est considéré comme une suite de caractères….

Désolé

Envoyé par fsmrel

Comme je l’ai précisé dans mon précédent message, je n’ai mis à niveau que la base de données Temp. Je vais le faire pour DZINDZIO_TRUCKS_MANAGEMENT_TEMP (et non pas DZINDZIO_TRUCKS_MANAGEMENT_TEST...)

table CAMION : j’a remplacé le type de CamionNumber par INT et remplacé les valeurs par défaut '' par '0'.

Structure de la table CAMION :

CREATE TABLE CAMION 
(
        CamionId              INT             NOT NULL
      , CamionVIN             VARCHAR(24)     NOT NULL
      , CamionNumber          INT             NOT NULL DEFAULT 0
      , CamionImmat           VARCHAR(9)      NOT NULL DEFAULT '0'
      , CamionDateMfg         DATE            NOT NULL DEFAULT '9999-12-31'
      , CamionManufacturer    VARCHAR(15)     NOT NULL
      , CamionModel           VARCHAR(15)     NOT NULL DEFAULT '0'
      , CamionWheelBase       INT             NOT NULL DEFAULT 0 
      , CamionColor           VARCHAR(15)     NOT NULL DEFAULT 'White'
      , GVWR                  INT             NOT NULL DEFAULT 0
      , FRGAWR                INT             NOT NULL DEFAULT 0
      , [2NDGAWR]             INT             NOT NULL DEFAULT 0
      , [3RDGAWR]             INT             NOT NULL DEFAULT 0
      , [4THGAWR]             INT             NOT NULL DEFAULT 0
      , REARGAWR              INT             NOT NULL DEFAULT 0
      , USDOT                 VARCHAR(10)     NOT NULL DEFAULT '0'
      , ICCMC                 VARCHAR(10)     NOT NULL DEFAULT '0'
      , CamionDateAchat       DATE            NOT NULL DEFAULT '9999-12-31'
      , CamionDateVente       DATE            NOT NULL DEFAULT '9999-12-31'
    , CONSTRAINT CAMION_PK PRIMARY KEY (CamionId)
    , CONSTRAINT CAMION_VIN_AK UNIQUE (CamionVIN)
    , CONSTRAINT CAMION_LOCALISATION_FK FOREIGN KEY (CamionId) 
          REFERENCES  LOCALISATION (LocalisationId)
    , CONSTRAINT  CAMION_DATE_MFT_CHK CHECK (CamionDateMfg > '')
);

Je vous préviendrai dès que DZINDZIO_TRUCKS_MANAGEMENT_TEMP sera regénérée.

Je dois encore effectuer des tests de mise à jour par la vue.

**ordigil** · 14/10/2018, 21h18

Je préfère ne pas aller dans vos bases de données car des fois je fais des erreurs

Envoyé par fsmrel

Comme je l’ai précisé dans mon précédent message,
je n’ai mis à niveau que la base de données Temp. Je vais le faire pour DZINDZIO_TRUCKS_MANAGEMENT_TEMP

**ordigil** · 14/10/2018, 22h13

J'ai endommagé "DZINDZIO_TRUCKS_TEMP". Ne perdez pas votre temps pour la mettre à jour

**ordigil** · 14/10/2018, 22h18

Vous pouvez mettre à jour directement dans "DZINDZIO_TRUCKS_MANAGEMENT"

**ordigil** · 14/10/2018, 22h44

Je viens de restaurer "DZINDZIO_TRUCKS_MANAGEMENT_TEMP" alors vous pouvez dropper votre "Temp" dedans

**fsmrel** · 14/10/2018, 23h26

Envoyé par ordigil

Je crois que c'est une erreur de considérer CamionNumber comme un nombre, j'ai fait une erreur. Le CamionNumber est considéré comme une suite de caractères... Désolé

Même pas grave, j’avais conservé la version VARCHAR(6)...

Structure de la table CAMION :

CREATE TABLE CAMION 
(
        CamionId              INT             NOT NULL
      , CamionVIN             VARCHAR(24)     NOT NULL
      , CamionNumber          VARCHAR(6)      NOT NULL DEFAULT '0'
      , CamionImmat           VARCHAR(9)      NOT NULL DEFAULT '0'
      , CamionDateMfg         DATE            NOT NULL DEFAULT '9999-12-31'
      , CamionManufacturer    VARCHAR(15)     NOT NULL
      , CamionModel           VARCHAR(15)     NOT NULL DEFAULT '0'
      , CamionWheelBase       INT             NOT NULL DEFAULT 0 
      , CamionColor           VARCHAR(15)     NOT NULL DEFAULT 'White'
      , GVWR                  INT             NOT NULL DEFAULT 0
      , FRGAWR                INT             NOT NULL DEFAULT 0
      , [2NDGAWR]             INT             NOT NULL DEFAULT 0
      , [3RDGAWR]             INT             NOT NULL DEFAULT 0
      , [4THGAWR]             INT             NOT NULL DEFAULT 0
      , REARGAWR              INT             NOT NULL DEFAULT 0
      , USDOT                 VARCHAR(10)     NOT NULL DEFAULT '0'
      , ICCMC                 VARCHAR(10)     NOT NULL DEFAULT '0'
      , CamionDateAchat       DATE            NOT NULL DEFAULT '9999-12-31'
      , CamionDateVente       DATE            NOT NULL DEFAULT '9999-12-31'
    , CONSTRAINT CAMION_PK PRIMARY KEY (CamionId)
    , CONSTRAINT CAMION_VIN_AK UNIQUE (CamionVIN)
    , CONSTRAINT CAMION_LOCALISATION_FK FOREIGN KEY (CamionId) 
          REFERENCES  LOCALISATION (LocalisationId)
    , CONSTRAINT  CAMION_DATE_MFT_CHK CHECK (CamionDateMfg > '')
);

Je vous préviens dès que DZINDZIO_TRUCKS_MANAGEMENT_TEMP est regénérée.

Comme je l’ai dit, j’effectuerai par ailleurs des tests de mise à jour par la vue CAMION_LOCALISATION_V, mais regardez ce que ça donne après regénération.

**fsmrel** · 14/10/2018, 23h57

Je viens de regénérer DZINDZIO_TRUCKS_MANAGEMENT_TEMP.

Pour un aperçu confortable des données, vous pouvez utiliser la vue CAMION_LOCALISATION_ECRAN_V.

A vous de vérifier le pertinence du résultat...

**ordigil** · 15/10/2018, 00h51

Ok je regarde. C'est triste de vous faire autant travailler.

Et en plus, il reste la partie principale à développer pour cette base de données, ce à quoi elle doit servir... hahaha

Nous y sommes allés un peu fort sur les contraintes, nous aurions dû attendre un peu.

Envoyé par fsmrel

Je viens de regénérer DZINDZIO_TRUCKS_MANAGEMENT_TEMP.

Pour un aperçu confortable des données, vous pouvez utiliser la vue CAMION_LOCALISATION_ECRAN_V.

A vous de vérifier le pertinence du résultat...

**ordigil** · 15/10/2018, 01h54

1 - À partir de la vue "CAMION_LOCALISATION_V", j'ai changé le CamionNumber 324 pour 325 et ça s'est très bien passé.

2- Ensuite, j'ai changé le immat02 pour VR2222QC et ça s'est très bien passé.

3- Par contre ça n'a pas été une bonne idée d'afficher des colonnes vides où il y a des valeurs par défaut. Je trouvais que ça faisait propre mais ça occasionne des problèmes. Là, ça ne passe pas, je dois entrer des valeurs partout où on voit des colonnes vides. PHP voit la même chose que moi, si je vois une colonne vide, PHP la voit vide aussi alors il me demande d'entrer une valeur même s'il y a déjà une valeur par défaut dans la table "CAMION"

4- Puisqu'il n'y a pas de clé primaire dans la vue "CAMION_LOCALISATION_V", je dois déclarer "CamionVIN" comme clé primaire dans ce VIEW sur mon site WEB pour que je puisse faire des "UPDATES", donc impossible de changer "CamionVIN". Ne pas changer le "CamionVIN" dans un VIEW est peut-être une bonne idée par contre. En principe, il faut vraiment avoir une bonne raison pour changer le VIN d'un camion, alors rendre la tâche plus complexe est peut-être une bonne chose… Je pourrais mettre "CamionVIN" en "Read Only" dans "CAMION_LOCALISATION_V" sur mon site WEB et je pourrais créer un formulaire pour changer uniquement les "CamionVIN" pour l'administrateur uniquement.

Envoyé par fsmrel

Je viens de regénérer DZINDZIO_TRUCKS_MANAGEMENT_TEMP.

Pour un aperçu confortable des données, vous pouvez utiliser la vue CAMION_LOCALISATION_ECRAN_V.

A vous de vérifier le pertinence du résultat...

**fsmrel** · 15/10/2018, 02h16

Envoyé par ordigil

ça n'a pas été une bonne idée d'afficher des colonnes vides

Il manquait un « GO » dans la génération. Maintenant les valeurs affichées devraient être celles par défaut, à part quelques cas tordus que je regarderai (cf. "vin07", colonne Color).

Réessayez.

**ordigil** · 15/10/2018, 02h18

Ok je réessaie

Envoyé par fsmrel

Il manquait un « GO » dans la génération. Maintenant les valeurs affichées devraient être celles par défaut, à part quelques cas tordus que je regarderai (cf. "vin07", colonne Color).

Réessayez.

Maintenance de camions

Schéma

Discussions similaires

Partager

Partager