Discussion :

[fsmrel]

Merci fsmrel de documenter aussi bien vos triggers comme vous le faites, maintenant j'arrive à comprendre C'est tellement instructif ;-)

Un jour c’est vous instruirez les plus jeunes ;-)

Mais que cela ne vous empêche pas de rattraper votre retard quant aux votes : )

[ordigil]

Plus on se rapproche du but fixé, plus ça devient intéressant de jouer avec cette base de données et plus on comprend votre raisonnement au tout début de la création de cette base de données… Merci encore de ne pas m'avoir laisser tomber fsmrel, je vous suis vraiment reconnaissant pour tout ce que vous faites…

[fsmrel]

Bonjour Ordigil,


Bon, finalement je contrôle via les triggers DIFF_AFFECTATION_AXLE_INSERT_TR et DIFF_AFFECTATION_AXLE_UPDATE_TR que la date d’installation d’un différentiel est antérieure à sa date de désinstallation : le message signalant l’erreur est moins abscons que celui de SQL Server...

Pourriez-vous vérifier que ça fonctionne ?

Il faudra que j’en fasse autant concernant la table COMPOSANT_AFFECTATION.

[ordigil]

Bonjour fsmrel Ok je vais vérifier sur le champs

Bonjour Ordigil,


Bon, finalement je contrôle via les triggers DIFF_AFFECTATION_AXLE_INSERT_TR et DIFF_AFFECTATION_AXLE_UPDATE_TR que la date d’installation d’un différentiel est antérieure à sa date de désinstallation : le message signalant l’erreur est moins abscons que celui de SQL Server...

Pourriez-vous vérifier que ça fonctionne ?

Il faudra que j’en fasse autant concernant la table COMPOSANT_AFFECTATION.

[ordigil]

J'ai fait une petite retouche maison. LoL C'est joli hahaha. C'est très clair maintenant hahaha

IF @InstallationDate < @AxleDateAchat
    BEGIN
         SET @OkDateAchatAxle = 'N'
         SET @Engueulade = 'Update - Affectation de différentiel(s) : la date d''installation ''' + CAST(@InstallationDate AS VARCHAR)  + ''' du différentiel ''' + @DiffSerialNumber + ''' est < à la date d''achat ''' + CAST(@axleDateAchat AS VARCHAR) + ''' de son axle ''' + @AxleSerialNumber +'''.'
         SELECT @Engueulade AS Engueulons_l, * FROM INSERTED
--         RAISERROR (@Engueulade,16,1)  -- state = 16 pour bloquer  
         RAISERROR (@Engueulade,0,1)  -- state = 0 pour les tests 
         --------- RETURN différé 
    END

Engueulons_l
Update - Affectation de différentiel(s) : la date d'installation '2014-04-02' du différentiel 'D-FOR03144562' est < à la date d'achat '2015-04-02' de son axle 'A-FOR03144562'.

Bonjour Ordigil,


Bon, finalement je contrôle via les triggers DIFF_AFFECTATION_AXLE_INSERT_TR et DIFF_AFFECTATION_AXLE_UPDATE_TR que la date d’installation d’un différentiel est antérieure à sa date de désinstallation : le message signalant l’erreur est moins abscons que celui de SQL Server...

Pourriez-vous vérifier que ça fonctionne ?

Il faudra que j’en fasse autant concernant la table COMPOSANT_AFFECTATION.

[ordigil]

J'ai repassé toutes les pages depuis le début pour les votes J'espère que je n'ai rien oublié Y a-t-il autre chose que je peux faire car vous le méritez vraiment :-) Je ne suis pas un habitué des Forums alors il y a plein de choses que j'ignore…

Un jour c’est vous instruirez les plus jeunes ;-)

Mais que cela ne vous empêche pas de rattraper votre retard quant aux votes : )

[fsmrel]

Bonjour Ordigil,

Merci pour les votes !

J’ai cherché dans la Toile s’il existait une instruction permettant de pondre autre chose que '1900-01-01', mais en vain.

Et ça sera manifestement toujours vain car, c’est un diktat, ce 1er janvier 1900 est la valeur par défaut en dur pour le type date, cf. la fonction DATENAME et autres fonctions du genre DATEDIFF...

[ordigil]

Wowwwww merci de partager avec moi


Je pensais qu'on pouvais faire quelque chose avec ça :::

Ah je pensais qu'une contrainte voyait les valeurs avant SQL Server..... Disons une contrainte du genre if Date = '' THEN Date = 9999-12-31

Mais ce n'est pas grave puisque je ne demanderai pas d'entrer les dates sur les formulaires à la création d'un nouveau Camion et des Composants…. L'utilisateur devra les mettre à jour avec les Updates....

Je ne pense pas que ce soit un détail important dans notre cas…

Dans mes formulaires, si j'entre autre chose que Y-M-J PHP me retourne : Cannot execute SQL statement: [Microsoft][ODBC Driver 17 for SQL Server][SQL Server]La conversion d'un type de données varchar en type de données datetime a créé une valeur hors limites.
[Microsoft][ODBC Driver 17 for SQL Server][SQL Server]L'instruction a été arrêtée.

Bonjour Ordigil,

Merci pour les votes !




Et ça sera manifestement toujours vain car, c’est un diktat, ce 1er janvier 1900 est la valeur par défaut en dur pour le type date, cf. la fonction DATENAME et autres fonctions du genre DATEDIFF...

[fsmrel]

En attendant :


Table COMPOSANT_AFFECTATION, trigger COMPOSANT_RECOUVREMENT_TR (INSERT).

Affectation d’un composant à un camion (ou à un local) : pour rendre moins abscons le message d’erreur transmis par SQL Server, lors des inserts violant la règle Date de désinstallation > Date d’installation, avec le trigger on intercepte la tentative d’insert et si infraction, on rouspète tout en squeezant SQL Server (en l’occurrence la contrainte COMPOSANT_AFFECTATION_CHECK01).

---------------------------------------------------------------------------
-- 2e partie - interception des checks, histoire d'afficher des messages
-- d'erreur moins abscons que ceux du SGBD...
---------------------------------------------------------------------------

SET @ComposantDesinstallationDate = (SELECT ComposantDesInstallationDate FROM @inserted) 
SET @ComposantInstallationDate = (SELECT ComposantInstallationDate FROM @inserted) 

--- rappel : pour une date d'installation, '9999-12-31' correspond en fait à la date < à toute  date signicative...

IF NOT (@ComposantDesInstallationDate > @ComposantInstallationDate OR @ComposantInstallationDate = '9999-12-31')
   BEGIN
         DECLARE @VarcharI AS VARCHAR(20)
         DECLARE @VarcharD AS VARCHAR(20)
         SET @VarcharI = CAST(@ComposantInstallationDate AS VARCHAR)
         SET @VarcharD = CAST(@ComposantDesInstallationDate AS VARCHAR) 
         SET @Engueulade ='Affectation de composant(s) : La date de désinstallation ''' + @VarcharD + ''' doit être postérieure à la date d''installation ''' + @VarcharI + ''' .'
         SELECT @Engueulade AS Engueulons, * FROM INSERTED
 --------        RAISERROR (@Engueulade,16,1)  -- state = 16 pour bloquer  
         RAISERROR (@Engueulade,0,1)  -- state = 0 pour les tests 
         RETURN
   END

Base DZINDZIO_TRUCKS_MANAGEMENT_TEMP : j’ai seulement modifié le trigger, mais il serait bon que vous vérifiassiez quand même que je n'ai pas fichu la zoubia...

[fsmrel]

Dans la foulée, pour les updates, j’ai mis à niveau le trigger COMPOSANT_RECOUVREMENT_UPDATE_TR.

Là encore, si vous pouviez vérifier que ça fonctionne dans DZINDZIO_TRUCKS_MANAGEMENT_TEMP.

[ordigil]

fsmrel, vous avez vraiment une patience et un soucis du détail exemplaire

En attendant :


Table COMPOSANT_AFFECTATION, trigger COMPOSANT_RECOUVREMENT_TR (INSERT).

Affectation d’un composant à un camion (ou à un local) : pour rendre moins abscons le message d’erreur transmis par SQL Server, lors des inserts violant la règle Date de désinstallation > Date d’installation, avec le trigger on intercepte la tentative d’insert et si infraction, on rouspète tout en squeezant SQL Server (en l’occurrence la contrainte COMPOSANT_AFFECTATION_CHECK01).

---------------------------------------------------------------------------
-- 2e partie - interception des checks, histoire d'afficher des messages
-- d'erreur moins abscons que ceux du SGBD...
---------------------------------------------------------------------------

SET @ComposantDesinstallationDate = (SELECT ComposantDesInstallationDate FROM @inserted) 
SET @ComposantInstallationDate = (SELECT ComposantInstallationDate FROM @inserted) 

--- rappel : pour une date d'installation, '9999-12-31' correspond en fait à la date < à toute  date signicative...

IF NOT (@ComposantDesInstallationDate > @ComposantInstallationDate OR @ComposantInstallationDate = '9999-12-31')
   BEGIN
         DECLARE @VarcharI AS VARCHAR(20)
         DECLARE @VarcharD AS VARCHAR(20)
         SET @VarcharI = CAST(@ComposantInstallationDate AS VARCHAR)
         SET @VarcharD = CAST(@ComposantDesInstallationDate AS VARCHAR) 
         SET @Engueulade ='Affectation de composant(s) : La date de désinstallation ''' + @VarcharD + ''' doit être postérieure à la date d''installation ''' + @VarcharI + ''' .'
         SELECT @Engueulade AS Engueulons, * FROM INSERTED
 --------        RAISERROR (@Engueulade,16,1)  -- state = 16 pour bloquer  
         RAISERROR (@Engueulade,0,1)  -- state = 0 pour les tests 
         RETURN
   END

Base DZINDZIO_TRUCKS_MANAGEMENT_TEMP : j’ai seulement modifié le trigger, mais il serait bon que vous vérifiassiez quand même que je n'ai pas fichu la zoubia...

[ordigil]

Ok, j'essaie immédiatement…

Chose étrange, je suis incapable d'ajouter un moteur sur le site Web alors que je peux ajouter transmission, Axle et Differential..... J'essaie de trouver si j'ai une erreur dans mon code mais je ne trouve pas

Dans la foulée, pour les updates, j’ai mis à niveau le trigger COMPOSANT_RECOUVREMENT_UPDATE_TR.

Là encore, si vous pouviez vérifier que ça fonctionne dans DZINDZIO_TRUCKS_MANAGEMENT_TEMP.

[fsmrel]

je suis incapable d'ajouter un moteur sur le site Web alors que je peux ajouter transmission, Axle et Differential

On transformera le camion pour en faire un gros char à voiles (genre 3 mâts)…


Sinon pouvez-vous me transmettre les données correspondantes : camion, moteur, affectation, que j'essaie chez moi, des fois que...

[ordigil]

Je crois que j'ai réussi….. Mais le formulaire des affectations ce n'est pas très jolie ni très pratique pour l'usager… Il doit utiliser le Vin du Camion et le Numéro de Série du composant…. Je vais essayer de faire en sorte que lorsqu'il créera un nouveau camion, lorsqu'il créera les composants, ils s'affecteront tous seuls au nouveau Camion.... Je n'ai pas encore testé en profondeur les création des camions et des composants mais je vous envois en privé les coordonnés et vos logins pour le site WEB....

On transformera le camion pour en faire un gros char à voiles (genre 3 mâts)…


Sinon pouvez-vous me transmettre les données correspondantes : camion, moteur, affectation, que j'essaie chez moi, des fois que...

[ordigil]

Êtes-vous parvenu à vous brancher fsmrel ??? Il n'y a pas votre dernier update de SQL Server sur le Site Web.... Et je n'ai pas terminé de cacher les dates pour l'ajout des nouveaux composants…. Je vais remettre le site WEB à jour un peu plus tard et j'ajouterai CAMION_COMPOSITION_V2.... Et j'ajouterai les vue pour mettre à jour les colonne manquantes lors de la création des nouveaux camions et des nouveaux composants...

[fsmrel]

J’ai réussi à me connecter.

Avant la prise de contrôle par les triggers, SQL Server prend des initiatives malheureuses. Par exemple, si je saisis une date d’achat avec la valeur '1790-01-01', il ne bronche pas : tant mieux, puisque les triggers feront leur boulot. Mais il se cabre si je saisis la valeur '1750-01-01' (époque à laquelle les camions étaient tirés par des chevaux pas vapeur, il est vrai) :

Pauvre utilisateur

A cette occasion, je vois que dans les triggers xxxx_COMPOSANT_INSERT_TR j’ai mis en place une instruction qui force à '9999-31-12' les dates d’achat antérieures à D0 = ‘1940-01-01’. Bien que vous forciez les dates d’achat au moment de la création d’un camion, on peut conserver D0 telle quelle dans les triggers pour les nouveaux achats, ou choisir une autre valeur, vous me direz. Il serait opportun que l’on en fasse autant pour les triggers xxxx_COMPOSANT_UPDATE_TR. Avez-vous la possibilité au stade du WEB de transmettre une date, disons '9999-31-12' ou bien la date D0 évoquée, afin que SQL Server ne se cabre pas ?

En passant, j’ai perdu en cours de route la possibilité de créer des composants (bouton « New »).

[ordigil]

Désolé je me suis endormi hahaha Bon j'ai réparé les insert mais on a plus de dates pour l'instant

J’ai réussi à me connecter.

Avant la prise de contrôle par les triggers, SQL Server prend des initiatives malheureuses. Par exemple, si je saisis une date d’achat avec la valeur '1790-01-01', il ne bronche pas : tant mieux, puisque les triggers feront leur boulot. Mais il se cabre si je saisis la valeur '1750-01-01' (époque à laquelle les camions étaient tirés par des chevaux pas vapeur, il est vrai) :

Pauvre utilisateur

A cette occasion, je vois que dans les triggers xxxx_COMPOSANT_INSERT_TR j’ai mis en place une instruction qui force à '9999-31-12' les dates d’achat antérieures à D0 = ‘1940-01-01’. Bien que vous forciez les dates d’achat au moment de la création d’un camion, on peut conserver D0 telle quelle dans les triggers pour les nouveaux achats, ou choisir une autre valeur, vous me direz. Il serait opportun que l’on en fasse autant pour les triggers xxxx_COMPOSANT_UPDATE_TR. Avez-vous la possibilité au stade du WEB de transmettre une date, disons '9999-31-12' ou bien la date D0 évoquée, afin que SQL Server ne se cabre pas ?

En passant, j’ai perdu en cours de route la possibilité de créer des composants (bouton « New »).

[ordigil]

Bonjour fsmrel… Vous êtes un lapin, je n'ai pas encore eu le temps d'aborder cette question ni de mettre à jour le site WEB avec la mise à jour des triggers… Le site WEB est développé avec 'dzindzio_trucks_management_gil_test' et non avec 'dzindzio_trucks_management_temp'...

J’ai réussi à me connecter.

Avant la prise de contrôle par les triggers, SQL Server prend des initiatives malheureuses. Par exemple, si je saisis une date d’achat avec la valeur '1790-01-01', il ne bronche pas : tant mieux, puisque les triggers feront leur boulot. Mais il se cabre si je saisis la valeur '1750-01-01' (époque à laquelle les camions étaient tirés par des chevaux pas vapeur, il est vrai) :

Pauvre utilisateur

A cette occasion, je vois que dans les triggers xxxx_COMPOSANT_INSERT_TR j’ai mis en place une instruction qui force à '9999-31-12' les dates d’achat antérieures à D0 = ‘1940-01-01’. Bien que vous forciez les dates d’achat au moment de la création d’un camion, on peut conserver D0 telle quelle dans les triggers pour les nouveaux achats, ou choisir une autre valeur, vous me direz. Il serait opportun que l’on en fasse autant pour les triggers xxxx_COMPOSANT_UPDATE_TR. Avez-vous la possibilité au stade du WEB de transmettre une date, disons '9999-31-12' ou bien la date D0 évoquée, afin que SQL Server ne se cabre pas ?

En passant, j’ai perdu en cours de route la possibilité de créer des composants (bouton « New »).

[fsmrel]

Le timestamp c'est un nombre de secondes écoulées depuis le 1er janvier 1970.

Ben voyons, c’est quoi cette ânerie ? Pourquoi seulement des secondes ? Pourquoi cette limite inférieure parfaitement arbitraire et 10 fois trop restrictive ?... Pour ma part, certes je ne connais strictement rien à PHP, mais je rappelle que dans nos travaux nous nous appuyons quand même sur la norme SQL, laquelle est parfaitement logique.

Le timestamp selon la norme :

YEAR   :    0001 à 9999
MONTH  :    01 à 12
DAY    :    01 à 31
HOUR   :    00 à 23
MINUTE :    00 à 59
SECOND :    00.000... à 61.999...

Bref je ferme illico la page PHP.

Pour les dates j'ai ça….. Je verrai plus tard ce que je peux faire

Quoi qu’il en soit, faisons en sorte de ne jamais laisser PHP prendre des initiatives stupides et se mêler de ce qui ne le regarde pas.

[ordigil]

timestand découle du monde UNIX pas de PHP…. Par contre PHP a été un peu en retard pour se mettre à jour LoL Aujourd'hui PHP gère les dates de la même façon que SQL. Par contre il me semble avoir déjà vu que SQL server peut gérer les dates à la façon UNIX...

Ben voyons, c’est quoi cette ânerie ? Pourquoi seulement des secondes ? Pourquoi cette limite inférieure parfaitement arbitraire et 10 fois trop restrictive ?... Pour ma part, certes je ne connais strictement rien à PHP, mais je rappelle que dans nos travaux nous nous appuyons quand même sur la norme SQL, laquelle est parfaitement logique.

Le timestamp selon la norme :

YEAR   :    0001 à 9999
MONTH  :    01 à 12
DAY    :    01 à 31
HOUR   :    00 à 23
MINUTE :    00 à 59
SECOND :    00.000... à 61.999...

Bref je ferme illico la page PHP.




Quoi qu’il en soit, faisons en sorte de ne jamais laisser PHP prendre des initiatives stupides et se mêler de ce qui ne le regarde pas.