Qui impose la présence d’une clé "primaire" pour faire des updates ?
Version imprimable
Merveilleux, maintenant PHP voit les valeurs par défaut et les "UPDATES" fonctionnent :chin::chin::chin::chin::chin:
C'est la façon dont j'ai conçu le site WEB :ptdr::ptdr::ptdr: puisque je peux cacher les clés primaires à l'utilisateur :(:(:(
:ptdr::ptdr::ptdr::ptdr::ptdr:
Citation:
Envoyé par fsmrel
Nous avons surement créé le plus long forum sur ce site, j'espère que nous aurons un trophée LoL hahaha :P:P:P:P
En réalité voyez-vous un problème à ce que j'utilise "CamionVIN" comme clé primaire pour "CAMION_LOCALISATION_V" sur le site WEB ? Ça ne change rien à SQL Server mais ça me simplifie grandement le développement du site WEB. "CamionVIN" est uniquement considérer comme clé primaire dans le formulaire.
Concernant les clés :
Vu de SQL, {CamionVIN} n’est pas clé primaire, mais clé alternative. Par ailleurs, toujours avec SQL, qu’elle soit primaire ou alternative une clé peut être modifiée. Comment vous avez-vous goupillé votre affaire pour empêcher la modification de CamionVIN ?
Vu de SQL, Que je prenne n'importe quelle colonne comme clé primaire dans mes formulaires, ça ne change rien car ça reste uniquement à l'intérieur du formulaire. Pour empêcher la modification de "CamionVIN" je mets simplement la colonne "Read Only" dans le formulaire… Est-ce que vous trouvez encore mes méthodes bizarres ? :ptdr::ptdr::ptdr:
Dans le post #76, vous émettiez l’idée qu’un utilisateur pourrait modifier le VIN suite à erreur de saisie :
C’est pour cette raison que j’ai finalement levé la contrainte. Si aujourd’hui vous estimez qu’après tout l’utilisateur ne doit jamais modifier le VIN, d’accord, mettez la colonne en read only, puisque c’est simplement une affaire de méthode.
L'utilisateur doit avoir une façon de modifier le VIN mais pas dans le VIEW "CAMION_LOCALISATION_V". Il peut faire une erreur à la création d'un nouveau Camion alors je dois lui donner une façon de corriger mais il pourrait aussi faire une erreur dans "CAMION_LOCALISATION_V" et changer le VIN d'un autre camion. Alors je lui interdis de le changer dans "CAMION_LOCALISATION_V". Je lui fournirai une autre façon de le changer.
Vous pensez vraiment à tout. Tous les numéros de série devraient être considérés comme le VIN. Un numéro de série ne se change pas … à l'exception d'une correction dû à une erreur de saisie par l'utilisateur lors de la création du composant dans la base de données.... 8O8O8O
Je ne suis pas foutu de faire un Trigger qui fonctionne :(:(:(:calim2::calim2::calim2:
J'ai été très occupé et vous ai laissé tomber...
Quel rôle doit remplir ce trigger ?
Met-il à jour une seule table ?
Mais non vous ne m'avez pas laisser tomber héhéhé Ça me laisse du temps pour expérimenter :P:P:P:P Déjà que je me considère chanceux de vous avoir connu sur ce site et que vous m'aider encore :mouarf::mouarf::mouarf:
Je voudrais que le Trigger mettre à jour des Colonnes d'une Table à partir de ce que j'insère dans une Colonne de cette table.
Pouvez-vous vous logger dans ma nouvelle BD "SERIAL_NUMBER_AUTOFILL" ???
Le but de cette base de données est d'expérimenter le remplissage automatiquement de certaines colonnes à partir de la colonne FullSerialNumber. . Si vous regarder pour la colonne EngineSerie, les 3 premiers chiffres de FullSerialNumber représente le EngineSerie. '471' = 'DD13', '472' = 'DD15', '473' = 'DD16'. Le But est évidemment d'afficher DD13, DD15 ou DD16 (Et il y en aura d'autres) dans EngineSerie.
Pour l'instant j'ai entrer un LEFT(FullSerialNumber, 3) dans la spécification de la colonne calculée de EngineSerie car mon Trigger ne fonctionnait pas.
Donc LEFT(FullSerialNumber, 3) = EngineSerie, SUBSTRING ( FullSerialNumber , 4 , 3 ) = VehicleApplication , SUBSTRING ( FullSerialNumber , 7 , 1 ) = AssemblyPlant, RIGHT(FullSerialNumber, 7) SerialNumber
Ceci est valide uniquement si Manufacturer = Detroit. Si Manufacturer = Autre Chose, le FullSerialNumber représentera autre chose.
Donc pour un Moteur Detroit :
471 = DD13
472 = DD15
473 = DD16
À partir des DD nous avons une colonne "Displacement"
DD13 = 12.8 L
DD15 = 14.8 L
DD16 = 15.8 L
900 =WesternStar
901 = Freightliner
902 = Sterling
903 = Freightliner
904 = WesternStar
907 = Export Australia
908 = Export Chili, Mexico
909 = TurboCompound
910 = Sterling
915 = Export Australia
S = Detroit
XXXXXXX = EngineSerialNumber
Donc pour un FullSerialNumber d'un Moteur Detroit : 472909S0314133DD15
FullSerialNumber EngineSerie Displacement Application AssemblyPlant EngineSerialNumber ______________________________________________________________________________________________________________ 472909S0314133 DD15 14,8 L TurboCompound Detroit 0314133
À noter que la Table "ENGINE_SPECS" de "SERIAL_NUMBER_AUTOFILL" ne représente pas fidèlement mes explications car je dois la refaire d'après les explications que je vous donnes ici. De plus je ne veux pas de colonne auto-calculée si je peux tout réglé dans un Trigger car lorsque j'aurai un autre 'Manufacturer', le FullSerialNumber représentera autre chose.
Donc If X = Detroit Then 'Ça fonctionne que je viens d'expliquer'
If X = Caterpillar Then 'FullSerialNumber représente d'autre chose"
If X = Mack Then Then 'FullSerialNumber représente d'autre chose"
Et ainsi de suite … 8O8O8O
Salve Ordigil,
Tentative de SELECT :
« L'autorisation SELECT a été refusée sur l'objet 'ENGINE_SPECS', base de données 'SERIAL_NUMBER_AUTOFILL', schéma 'dbo'. »
Maintenant j'ai accès à la table ENGINE_SPECS.
Pourriez-vous donner deux ou trois exemples d'autres manufacturiers ?
Pour l'instant je n'ai rien. Il faudrait que je sois capable d'entrer toutes les informations manuellement si le Manufacturier n'est pas 'Detroit'. Pour Caterpillar le numero de serie fonctionne vraiment différemment de Detroit. Ce n'est pas un pré-requis pour ''DZINDZIO_TRUCKS_MANAGEMENT" pour l'instant, c'est quelque chose que je développe en parallèle car il y a beaucoup de recherche à faire.
Disons que pour l'instant dans "SERIAL_NUMBER_AUTOFILL" Si [Manufacturer] <> 'Detroit' alors on entre toutes les valeurs manuellement…. :ptdr::ptdr::ptdr:
D'accord. Bon courage !
Pendant ce temps, je vais essayer de supprimer la table COMPOSANT_TYPE...
J’ai supprimé la table COMPOSANT_TYPE.
La structure de la table COMPOSANT est donc modifiée. La colonne ComposantTypeId disparaît, tandis qu’est mise en oeuvre la colonne ComposantType, pouvant prendre les seules valeurs 'e', 't', 'a', 'd' (comme 'engine', 'transmission', 'axle', 'differential’') :
En conséquence, sont légèrement modifiés les triggers :CREATE TABLE COMPOSANT ( ComposantId INT IDENTITY NOT NULL , ComposantDateAchat DATE NOT NULL DEFAULT '9999-12-31' , Fabriquant VARCHAR(48) NOT NULL DEFAULT '0' , Modele VARCHAR(48) NOT NULL DEFAULT '0' , ComposantType CHAR(1) NOT NULL , CONSTRAINT COMPOSANT_PK PRIMARY KEY (ComposantId) , CONSTRAINT COMPOSANT_TYPE_CHK CHECK (LOWER(ComposantType) IN ('e', 't', 'a', 'd')) );
— MOTEUR_COMPOSANT_INSERT_TR
— TRANSMISSION_COMPOSANT_INSERT_TR
— DIFFERENTIEL_COMPOSANT_INSERT_TR
— COMPOSANT_RECOUVREMENT_TR
— COMPOSANT_RECOUVREMENT_UPDATE_TR
Sont aussi modifiées les vues :
— AFFECTATION_ADMIN
— AFFECTATION_USER
J’ai mis à jour Temp en conséquence, mais je n’ai pas touché aux autres bases de données.
J’espère pouvoir attaquer la mise en oeuvre de la table AXLE, mais demain j’ai des soins et après-demain l’ophtalmo : je serai donc hors-service pendant ce temps...