IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Candidat au Club
    Homme Profil pro
    Étudiant
    Inscrit en
    novembre 2020
    Messages
    4
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Algérie

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : novembre 2020
    Messages : 4
    Points : 4
    Points
    4
    Par défaut Comment personnaliser une codification d'une clé primaire ?
    Bonjour chère développeurs, je me tourne vers vous pour un la résolution d'un problème,
    j'aimerais avoir une codification spéciale pour une clé primaire , elle doit commencer par "A" suivi par un nombre qui s'auto incrémente sur Cinque position "00001" a chaque foi i+1 => "A00001" "A00002" ainsi de suite ...pouvez vous m'aider ?
    Merci. Nom : ax.JPG
Affichages : 55
Taille : 52,3 Ko

  2. #2
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    20 466
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 20 466
    Points : 48 290
    Points
    48 290
    Par défaut
    Non, parce que c'est d'une haute stupidité ! En effet une clé primaire ne devrait avoir AUCUNE sémantique et donc être totalement arbitraire ! En faisant tout le contraire vous serez tôt au tard dans la merde.

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  3. #3
    Candidat au Club
    Homme Profil pro
    Étudiant
    Inscrit en
    novembre 2020
    Messages
    4
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Algérie

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : novembre 2020
    Messages : 4
    Points : 4
    Points
    4
    Par défaut
    Merci de m'avoir répondu, cela dit vous auriez pu éviter ce type d'argument, et me proposer une autre solution, si je suis ici, c'est bien pour apprendre...
    "الحبقْ من عندنا سْبَقْ"
    A+.

  4. #4
    Expert éminent sénior
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    6 484
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 6 484
    Points : 20 109
    Points
    20 109
    Billets dans le blog
    2
    Par défaut
    Bonjour,

    Il ne faut pas polluer la clef primaire mais simplement construire votre identifiant par concaténation des éléments qui vous intéressent lors de la restitution.
    Construire la clef primaire en l'affublant d'un préfixe ou d'un suffixe de type char ou varchar ne présente aucun intérêt et pénalise les perfs.

    Pour la clef primaire utilisez une IDENTITY (AUTO_INCREMMENT pour MySQL)

    Attention toutefois :
    • une colonne de type IDENTITY peut présenter des trous de numérotation (lignes non commitées, incrément/décrément supérieur à 1, valeur de départ différente de un...)
    • il ne faut pas déduire une chronologie à partir de ce type de colonnes, il n'y a pas de garantie que les valeurs d'IDENTITY soient insérées dans l'ordre chronologique, même si c'est le plus souvent le cas


    Exemple :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    create table TAB0(  IDENT integer not null auto_increment primary key
                      , TXT1  char(10))
                      engine=innodb ;
    insert into TAB0 (TXT1) values ('abcdef');
    insert into TAB0 (TXT1) values ('TOTO');
    insert into TAB0 (TXT1) values ('coucou');
    insert into TAB0 (TXT1) values ('ça va ?');  
    select concat('A', repeat('0', 5-length(char(IDENT))), IDENT) as machin
         , TXT1
    from TAB0 ;
    Résultat :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    machin	TXT1
    A00001	abcdef
    A00002	TOTO
    A00003	coucou
    A00004	ça va ?

  5. #5
    Membre à l'essai
    Femme Profil pro
    Administrateur de base de données
    Inscrit en
    décembre 2019
    Messages
    1
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 63
    Localisation : France, Côtes d'Armor (Bretagne)

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : décembre 2019
    Messages : 1
    Points : 15
    Points
    15
    Par défaut
    @Artemus24 : ça répond à la demande mais c'est une mauvaise idée : pk polluée par une constante alpha ==> plus couteux qu'une pk integer et sans intéret

  6. #6
    Membre averti
    Profil pro
    Administrateur
    Inscrit en
    mai 2008
    Messages
    195
    Détails du profil
    Informations personnelles :
    Localisation : Canada

    Informations professionnelles :
    Activité : Administrateur
    Secteur : Industrie

    Informations forums :
    Inscription : mai 2008
    Messages : 195
    Points : 376
    Points
    376
    Par défaut
    Utilisez une cléf primaire numérique.
    Maîtriser les bases de la normalisation des bases de données, cela vous évitera bien des désagréments.
    Inutile de postfixer ou préfixer les noms des colonnes par le nom de table (_Empl...)
    Écrivez simplement vos tables et rendez le tout lisible.

    Vu qu'un employé peut avoir plus d'un numéro de téléphone, alors créez une table telephones.

    Table employés
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
     
    CREATE TABLE employes (
    	employe_id integer auto_increment primary key,
    	inscription DATETIME DEFAULT CURRENT_TIMESTAMP,
    	matricule varchar(50),
    	sexe ENUM('m', 'f')
    	nom varchar(50),
    	prenom varchar(50),
    	naissance date,
    	naissance_lieu varchar(50),
    	fonction varchar(256),
    	email varchar(50),
    	addresse varchar(256),
    );
    Table téléphones
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
     
    CREATE TABLE telephones (
    	telephone_id integer auto_increment primary key,
    	employe_id integer references employes(employe_id),
    	telephone varchar(20);
    );

  7. #7
    Expert éminent sénior
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    6 484
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 6 484
    Points : 20 109
    Points
    20 109
    Billets dans le blog
    2
    Par défaut
    Bonjour Manzeki

    Citation Envoyé par manzeki Voir le message
    Utilisez une cléf primaire numérique.
    Sur ce point, tout le monde sera d'accord, je l'espère, à l'orthographe près : soit clef avec un "f" terminal et sans accent (pour rappel de sa racine latine Clava) soit clé, mais pas cléf


    Citation Envoyé par manzeki Voir le message
    Maîtriser les bases de la normalisation des bases de données, cela vous évitera bien des désagréments.
    La aussi, pas de débat


    Citation Envoyé par manzeki Voir le message
    Inutile de postfixer ou préfixer les noms des colonnes par le nom de table (_Empl...)
    Pas d'accord, sous réserve d'avoir toute latitude pour nommer les objets bases de données (c'est rarement le cas en entreprise), utiliser un préfixe ou suffixe court est bigrement pratique, car ça évite les homonymes.
    Par exemple, dans une BDD, il y a pléthore de dates de début et de fin dans les différentes tables. Si un préfixe ou suffixe permet de les distinguer d'emblée, c'est pratique à l'usage.
    Avantage supplémentaire : pas de risque de percussion avec un mot réservé SQL grâce à cet ajout.
    Encore un avantage : on sait d'emblée de quelle table provient une FK sans même besoin de consulter le DDL CREATE TABLE .
    Bref, quand on a le choix, chacun fait comme il veut, mais pour mon usage personnel, j'applique systématiquement un préfixe court (un par table) à chaque attribut.


    Citation Envoyé par manzeki Voir le message
    Vu qu'un employé peut avoir plus d'un numéro de téléphone, alors créez une table telephones.
    En général oui, mais sous réserve que les règles de gestion le stipulent, peut être que dans ce contexte particulier, tout employé n'a qu'un et un seul téléphone
    La remarque vaut aussi si un employé peut ne pas avoir de numéro de téléphone : externaliser le numéro évite d'avoir des attributs nullables dans la table employé.


    Pour le reste, s'il s'agit d'améliorer le script, il faut aller jusqu'au bout de la démarche en notant également que :
    • une adresse courriel peut aller jusqu'à 255 caractères, donc du varchar(50) est inadapté
    • on pourrait faire la même remarque que pour les téléphones : selon les règles de gestion, un employé peut avoir ou pas zéro à plusieurs courriel, auquel cas il faut également externaliser les adresses courriel.
    • le lieu de naissance ne dépend pas fonctionnellement de l'identifiant de l'employé, c'est un viol de la 3e forme normale. Il doit donc être externalisé par un lien FK vers les communes pour éviter les erreurs et les redondances.
    • idem pour les fonctions
    • les adresses françaises et étrangères sont normalisées. Une seule ligne de type varchar(255) est complètement inadapté
    • selon le contexte (règles de gestion), il est possible d'avoir plusieurs adresses (de livraison, de facturation...), en ce cas, il faut également les externaliser.

  8. #8
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    20 466
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 20 466
    Points : 48 290
    Points
    48 290
    Par défaut
    En ce qui concerne le préfixage des colonnes, il y a un autre avantages, extrêmement important et non négligeable... Retrouver ou, dans les multiples objets de la base (tables, vues, fonctions, procédures déclencheurs, synonymes, contraintes....), figure cette colonne parce que l'on doit pouvoir connaitre l'impact par exemple d'un changement de type !

    Comme je pratique l'audit de base de données régulièrement, depuis plusieurs décennies, voici un cas concret que j'ai systématiquement :
    Passer les dates du type DATETIME (quasi obsolète) au type DATETIME2 dans SQL Server...
    Bon courage pour faire cela s'il ne vous est pas possible de faire une sorte de GREP pour trouver, d'un coup, tous les objets concernés et les requêtes applicatives !!!
    Un de mes client y a passé plus d'un an...

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  9. #9
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    20 466
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 20 466
    Points : 48 290
    Points
    48 290
    Par défaut
    Pour le reste je rappelle le modèle pour les personnes :

    https://blog.developpez.com/exercice...n_de_personnes

    et les adresses :

    https://blog.developpez.com/exercice..._d_une_adresse

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  10. #10
    Expert éminent sénior
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    6 484
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 6 484
    Points : 20 109
    Points
    20 109
    Billets dans le blog
    2
    Par défaut
    Frédéric,

    Il me semble que je t'en avais déjà parlé, quand j'ouvre le lien adresse, voici ce qui s'affiche :

    Nom : Sans titre.png
Affichages : 16
Taille : 137,7 Ko

    C'est illisible

    Même combat avec firefox ou chrome, peu importe le zoom, c'est pareil

  11. #11
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    20 466
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 20 466
    Points : 48 290
    Points
    48 290
    Par défaut
    Clic droit, ouvrir l'image

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  12. #12
    Membre averti
    Profil pro
    Administrateur
    Inscrit en
    mai 2008
    Messages
    195
    Détails du profil
    Informations personnelles :
    Localisation : Canada

    Informations professionnelles :
    Activité : Administrateur
    Secteur : Industrie

    Informations forums :
    Inscription : mai 2008
    Messages : 195
    Points : 376
    Points
    376
    Par défaut
    Citation Envoyé par escartefigue Voir le message
    Bonjour Manzeki
    Sur ce point, tout le monde sera d'accord, je l'espère, à l'orthographe près : soit clef avec un "f" terminal et sans accent (pour rappel de sa racine latine Clava) soit clé, mais pas cléf

    La aussi, pas de débat

    Pas d'accord, sous réserve d'avoir toute latitude pour nommer les objets bases de données (c'est rarement le cas en entreprise), utiliser un préfixe ou suffixe court est bigrement pratique, car ça évite les homonymes.
    Par exemple, dans une BDD, il y a pléthore de dates de début et de fin dans les différentes tables. Si un préfixe ou suffixe permet de les distinguer d'emblée, c'est pratique à l'usage.
    Avantage supplémentaire : pas de risque de percussion avec un mot réservé SQL grâce à cet ajout.
    Encore un avantage : on sait d'emblée de quelle table provient une FK sans même besoin de consulter le DDL CREATE TABLE .
    Bref, quand on a le choix, chacun fait comme il veut, mais pour mon usage personnel, j'applique systématiquement un préfixe court (un par table) à chaque attribut.

    En général oui, mais sous réserve que les règles de gestion le stipulent, peut être que dans ce contexte particulier, tout employé n'a qu'un et un seul téléphone
    La remarque vaut aussi si un employé peut ne pas avoir de numéro de téléphone : externaliser le numéro évite d'avoir des attributs nullables dans la table employé.


    Pour le reste, s'il s'agit d'améliorer le script, il faut aller jusqu'au bout de la démarche en notant également que :
    • une adresse courriel peut aller jusqu'à 255 caractères, donc du varchar(50) est inadapté
    • on pourrait faire la même remarque que pour les téléphones : selon les règles de gestion, un employé peut avoir ou pas zéro à plusieurs courriel, auquel cas il faut également externaliser les adresses courriel.
    • le lieu de naissance ne dépend pas fonctionnellement de l'identifiant de l'employé, c'est un viol de la 3e forme normale. Il doit donc être externalisé par un lien FK vers les communes pour éviter les erreurs et les redondances.
    • idem pour les fonctions
    • les adresses françaises et étrangères sont normalisées. Une seule ligne de type varchar(255) est complètement inadapté
    • selon le contexte (règles de gestion), il est possible d'avoir plusieurs adresses (de livraison, de facturation...), en ce cas, il faut également les externaliser.
    Vous inventez ou vous confirmez que clef signifie ou a pour racine clava ?

    Je suis désolé, je ne me plais pas à faire des antithèses sur les reponses des gens.
    Je préfère contribuer et aider les personnes qui posent les questions.
    Je m'abtiens aussi de ne pas importuner ou insulter des inconnus sur des forums, par prudence.
    Qu'à cela ne tienne chacun assume ce qu'il débite sur internet.

    Donc vos antithèses, débats et votre latin, gardez les pour vous.

    Pour ce qui est du sujet proprement dit :
    Çela fait plus de 15 ans que je travaille sur les bases de données.
    Sachez lire entre les lignes, vos commentaires sur la taille des varchar ou sur la taille des emails ne sont pas pertinents à mes yeux.
    Expliquez correctement au concerné pourquoi on choisit une taille et pas une autre pour un varchar.

    Je suis sûr qu'à votre premier post, vous n'avez pas contasté qu'il utilisait deux colonnes pour stocker ses numéros de téléphone.
    Une personne peut avoir 0, 1, 2, 3.. numéros de téléphone. C'est trivial de mettre le tout dans une table à part.
    Quid des emails, lieu ou ville de naissance, adresse (tout dépendra de comment est structurée l'adresse du pays).

    C'est une piste que j'ai émise pour alerter le concerné, vous pouvez compléter le script pour lui et non pour moi.

    Pour ce qui est de préfixer les noms des tables ou vues avec des tbl_, ou des noms colonnes avec le nom de la table, je ne le fais jamais, c'est une abbération pour moi. En plus c'est pas une norme. C'est comme si on préfixait les méthodes d'une classe Java avec des fn_.....

    Quand on écrit correctement les noms de ses objets, je me demande comment on peut confondre les noms des tables avec ceux des fonctions.
    Sinon à quoi sert de créer des bases de données, des alias, les schemas .... ?
    A partir d'un certain niveau d'expertise, je pense qu'il est rare de confondre un mot réservé avec autre chose. Et sinon, à quoi servent les tests unitaires.
    Même un éditeur comme NotePad++ avec de bons plugins nous évite de commettre ce genre d'erreurs.

  13. #13
    Expert éminent sénior
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    6 484
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 6 484
    Points : 20 109
    Points
    20 109
    Billets dans le blog
    2
    Par défaut
    Bonjour Manzeki

    Citation Envoyé par manzeki Voir le message
    Vous inventez ou vous confirmez que clef signifie ou a pour racine clava ?
    Clef, clavier, clavecin, claviforme, clavicule... ont la même racine latine : clavem, clavis (selon les différentes déclinaisons)
    Cf. https://cnrtl.fr/definition/academie9/clef
    et dans wiki ici https://fr.wiktionary.org/wiki/clava
    Nom : Sans titre.png
Affichages : 7
Taille : 6,5 Ko


    Citation Envoyé par manzeki Voir le message
    Je m'abtiens aussi de ne pas importuner ou insulter des inconnus sur des forums, par prudence.
    Où vous-ai je insulté ?


    Citation Envoyé par manzeki Voir le message
    Donc vos antithèses, débats et votre latin, gardez les pour vous.
    Si vous ne supportez pas la contradiction, évitez les débats et donc notamment les forums
    Vous recommandez, fort justement, de respecter les formes normales, or, vous proposez un script qui viole la 3e forme normale (attribut non dépendant de l'identifiant)
    Il est donc tout à fait normal que j'en fasse mention.


    Citation Envoyé par manzeki Voir le message
    vos commentaires sur la taille des varchar ou sur la taille des emails ne sont pas pertinents à mes yeux.
    Mentionner que vous proposez une longueur insuffisante pour recevoir une donnée n'est pas pertinent ?
    Mentionner que vous proposez de stocker une adresse sur une seule ligne de 255 caractères n'est pas pertinent, alors que vous pouvez en quelques clics trouver les normes d'adresses françaises et étrangères sur le web?


    Citation Envoyé par manzeki Voir le message
    Je suis sûr qu'à votre premier post, vous n'avez pas contasté qu'il utilisait deux colonnes pour stocker ses numéros de téléphone.
    Une personne peut avoir 0, 1, 2, 3.. numéros de téléphone. C'est trivial de mettre le tout dans une table à part.
    Quid des emails, lieu ou ville de naissance, adresse (tout dépendra de comment est structurée l'adresse du pays).
    Vous m'avez décidément très mal lu ! Je propose justement d'externaliser non seulement les téléphones si requis, mais aussi les adresses puisqu'elles peuvent elles aussi être multiples...


    Citation Envoyé par manzeki Voir le message
    Pour ce qui est de préfixer les noms des tables ou vues avec des tbl_, ou des noms colonnes avec le nom de la table, je ne le fais jamais, c'est une abbération pour moi. En plus c'est pas une norme. C'est comme si on préfixait les méthodes d'une classe Java avec des fn_.....
    C'est une abération pour vous, j'en prends bonne note, cela étant j'ai apporté des arguments, d'autres contributeurs ont surenchéri dans le même sens, libre à vous de faire ce qui vous convient.


    Citation Envoyé par manzeki Voir le message
    Quand on écrit correctement les noms de ses objets, je me demande comment on peut confondre les noms des tables avec ceux des fonctions.
    Sinon à quoi sert de créer des bases de données, des alias, les schemas .... ?
    A partir d'un certain niveau d'expertise, je pense qu'il est rare de confondre un mot réservé avec autre chose. Et sinon, à quoi servent les tests unitaires.
    Même un éditeur comme NotePad++ avec de bons plugins nous évite de commettre ce genre d'erreurs.
    Faites quelques recherches dans ce forum et vous trouverez de nombreux sujets dans lequels on trouve des requêtes avec des crochets autour des noms des tables et des colonnes justement à cause de l'utilisation de noms réservés.

Discussions similaires

  1. [AC-2010] Comment Personnaliser une Clé Primaire d'une Table Access 2010.
    Par sbou288 dans le forum VBA Access
    Réponses: 8
    Dernier message: 15/04/2019, 08h15
  2. Comment reconnaitre une clé primaire sans Syscolumn
    Par Raton dans le forum MS SQL Server
    Réponses: 7
    Dernier message: 26/10/2006, 13h07
  3. comment supprimer une clé primaire d'une table ?
    Par polianita dans le forum Access
    Réponses: 10
    Dernier message: 03/08/2006, 16h34
  4. Comment personnaliser une ColorBox
    Par manplum dans le forum C++Builder
    Réponses: 1
    Dernier message: 05/02/2006, 12h33
  5. Comment comment définir une clef primaire dans une table??
    Par nek_kro_kvlt dans le forum Bases de données
    Réponses: 4
    Dernier message: 07/02/2005, 22h06

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo