Discussion :

[bonbino85]

Bonsoir,

Je suis entrain de développer une application sous delphi je utilise un dbedit1 pour le (code de la commande) ma question et comment je puisse faire en delphi pour que quand j'appuyer sur le bouton nouvelle commande le code de la commande (dbedit1) va prendre une valeur automatique de genre (C01.....C76). une auto-incrémentation.

Merci

[ShaiLeTroll]

Si monoposte,
Il suffit lors du Append ou Insert du DataSet Commandes, de fournir les valeurs par défaut, un petit calcul pour obtenir le plus grand numéro + 1 via du SQL n'est pas bien compliqué

Si multi-poste
Je dirais que le faire via la DB est le plus prudent !
Avec des Transactions

Imagine deux personnes qui commence une commande, il leur fait chacun un numéro différent
une SEQUENCE ou alors une table de compteur comme ce code en Sybase 10

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
CREATE TABLE SequenceCounters(NomDeTable_ChampAvecCompteur INTEGER, AutreTable_Champ INTEGER, ...);
 
CREATE FUNCTION GetCountersNextValue(@TableName sysname, @SequenceFieldName sysname) RETURNS INTEGER NOT DETERMINISTIC
BEGIN 
  DECLARE keyval INTEGER; 
  EXECUTE IMMEDIATE 'UPDATE SequenceCounters SET '||@TableName||'_'||@SequenceFieldName||' = '||@TableName||'_'||@SequenceFieldName||' + 1'; EXECUTE IMMEDIATE 'SELECT SequenceCounters.'||@TableName||'_'||@SequenceFieldName||' INTO keyval FROM SequenceCounters'; 
  RETURN keyval;
END;

Code sqm :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
INSERT INTO NomDeTable (ChampAvecCompteur, AutreChamp)
VALUES (GetCountersNextValue('NomDeTable', 'ChampAvecCompteur')), 'Truc');
INSERT INTO AutreTable (Champ, AutreChamp)
VALUES (GetCountersNextValue('AutreTable', 'Champ')), 'Bidule');

Tout ce cela géré avec une transaction
Parcontre, la valeur n'est fourni qu'après l'enregistrement
Si tu le veux AVANT durant la saisie, il faudrait le réserver et donc risquer de perdre une valeur si une autre commande est saisie par un autre utilisateur et que tu annules celle en cours

[Moez.B]

Salut,

Pour les auto-incrément de la base : ça dépend de la version du SGBD, si c'est en ORACLE par exemple c'est géré en automatique avec une séquence et un déclencheur. si en SQL SERVER, c'est un type en auto-incrément..

Dans ton cas ce n'est ni l'un ni l'autre d’après ce que je vois pas un auto-incrément au vrai sens du mot mais un seul champ (C01, C02 ..C07...CN) ou bien tu parles d'une clé composé si tu gères une table multi-nature (C=Commande, C=Vente, D=Devis ..) ...
Est ce que tu peux préciser encore la nature de l'enregistrement ?

[bonbino85]

Bonsoir

Mon application est Multi-postes. Je travaille avec SQL SERVER alors j'ai besoin de coder le code commande sur trois caractères _ _ _ (clé composée) dont le premier commence avec le caractère c et le reste est une incrémentation automatique.
Ma table et Multi-natures et c'est le premier caractère qui détermine la nature
C: commande D: devis V: vente

Merci pour vos réponses

[ShaiLeTroll]

Tu peux séparer "C: commande D: devis V: vente" dans une colonne TypeDonnee
Avoir un champ INTEGER contenant le compteur CompteurDonnee
Ensuite c'est juste l'affichage qui concatène TypeDonnee + CompteurDonnee

MySQL par exemple, en ISAM, si l'on fourni une clé primaire comme CHAR(1), INTEGER AUTO INC, il va gérer un AUTO INC différent pour chaque valeur du 1er champ !

A tenter sur SQL Server (j'ai des gros doutes, et une SEQUENCE + TRIGGER sera effectivement une bonne approche)

Sinon 3 chiffres, au bout de 999 commandes, tu retournes à zéro ?
Je suppose que tu as un numéro de commande plus complexe que cela ?
Genre C + NumeroClient + Compteur ou C + NumeroClient + Année + Compteur
Sinon, je ne vois pas à qui peut bien servir un numéro si court !

Sinon as-tu pensé à la volumétrie ?
Si tu mélanges tout dans une seule table, cela nuira aux performances !
En plus, si tu as des colonnes spécifiques aux commandes, devis et ventes, tu n'auras pas un modèle de données optimales !
Pense à faire des tables relations permettant de filtrer commande, devis et vente sans devoir vérifier TypeDonnee

Voir comment transposer l'Héritage dans son modèle DB comme dans Héritage dans une base de données Access
Qui montre comment mettre en commun les données d'une personne mais en conservant les données "spécialisées" dans des tables séparés via une relation 1-1

A lire Modélisation par héritage par SQLPro
la partie 3. Un héritage induit pour gérer COMMANDE et FACTURE sous la forme de CONTRAT (avec Nature) avec les relations COMMANDE et PAYE me semble être ton cas

Voir les principes de Normalisation que recommande Microsoft pour SQL Server 2008 R2 :

Une table ne doit stocker que les données d'un type d'entité unique.

En essayant de stocker trop d'informations dans une table, vous risquez de nuire à l'efficacité et la fiabilité de la gestion des données de cette table. Dans l'exemple de base de données AdventureWorks2008R2, les informations sur les commandes et les clients sont stockées dans des tables distinctes. Bien qu'il soit possible de disposer de colonnes contenant des informations pour la commande et le client dans une même table, une telle structure n'est pas sans poser quelques problèmes. Les informations sur le client, à savoir le nom et l'adresse, doivent être ajoutées et stockées de manière redondante pour chaque commande. La base de données exige un espace de stockage supplémentaire. Si l'adresse d'un client vient à changer, la modification devra être effectuée pour chaque commande. Et si la dernière commande d'un client est supprimée de la table Sales.SalesOrderHeader, les informations concernant ce client sont perdues.

Un modèle bien posé permet de justifier cette colonne TypeDonnee tout en respectant la normalisation par un héritage astucieux

[Moez.B]

Bonjour,

Comme mentionne @Shail , je ne sais pas le dénouement lorsque le stock des commandes atteint les 99 ou les 999 , éh bien tu auras une cassation de l'intégrité de la clé primaire , non ?

Sinon, il y a beaucoup de choix pour la conception du modèle de données dans ce genre de situation ( éh oui, les vieux merisiens ) , c'est soit on crée une table pour les OPERATIONS avec une table pour les TYPE_OPERATIONS (Commande, Devis, Vente) et un Identificateur en auto-incrément en automatique pour la table OPERATIONS avec une clé étrangère pour TYP_OP_ID.. sinon si le volume des opérations typées est grand et des transactions multi-sites, passer par trois table COMMANDES, VENTES et DEVIS et là tu gères comme tu veux les clés primaires ( auto-incrément, personnalisé ...) ... et si c'est encore plus volumineux et transactionnels , il faut penser à des VUES et des entrepôts de données.

Mais finalement, la base et tout le modèle de données ne seront pas la base de départ , des réflexions sur les vecteurs de travail, la circulation des informations et les changements qu'elle subissent , les différents intervenants sur l'application ( ou les modules de l'application ) sont incarnés dans la prise de décision pour tout développer après ...

Bonne journée.