Discussion :

[oliviers92]

Bonjour,

Casse tête pour un débutant comme moi.

Une table partenaires (OCRD) dont les fournisseurs sont indexés dans un champ (CardCode) sur le modèle Fxxxxx. On souhaite pouvoir réutiliser les trous de l'index (suite aux suppressions dans la table) pour réinsérer les nouveaux fournisseurs dans l'ordre alphabétique du champ nom (CardName).

Problème : l'historique est très anarchique et je ne peux pas utiliser le classement sur CardName pour positionner le CardCode.

Pou y parvenir, j'aimerai créer une sous requête qui me renvoie OCRD purgée de tous les enregistrements ne respectant pas l’ordre alphabétique.

Ce qui donne un code du genre :

Code :

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

1
2
3
4
5
6
 
SELECT T0.[CardCode], T0.[CardName]
FROM OCRD T0
WHERE (LEFT ( T0.[CardCode] , 1) = 'F')
      AND T0.CardName < (SELECT CardName FROM OCRD WHERE CardCode > @CardCode )
ORDER BY T0.[CardCode]

ou @CardCode représente le CardCode de l'enregistrement traité par le SELECT de niveau supérieur qui doit être utilisé par le SELECT du niveau le plus imbriqué pour comparaison (et éventuellement rejet) de son CardName avec tous les enregistrements qui suivent.

Désolé si je suis peu clair mais si ça l'était je n'aurai pas besoin d'aide ;-)

Je sais que mon code n'est pas conforme mais existe-t-il une solution pour ce type de comparaison des enregistrements d'une même table ?

Merci de votre aide.

[Waldar]

Une table partenaires (OCRD) dont les fournisseurs sont indexés dans un champ (CardCode) sur le modèle Fxxxxx. On souhaite pouvoir réutiliser les trous de l'index (suite aux suppressions dans la table) pour réinsérer les nouveaux fournisseurs dans l'ordre alphabétique du champ nom (CardName).

Houla, que d'énormités.
En base de données, grosso modo, on ne bouche pas les trous libres, un identifiant cramé reste cramé.
On ne trie pas ses données dans la table, on le fait à l'exécution avec une requête.

Imaginez que vous faites votre mise à jour et, puis un nouveau fournisseur "ABC" se présente. Comptez-vous redécaler tous vos codes ?

[oliviers92]

Bonjour,

Je n'ai pas dit que c'était une bonne idée. Simplement une demande utilisateur. Rien n'oblige a satisfaire les demandes farfelues me direz-vous, mais il se trouve que celle-ci n'est pas totalement injustifiée. Il n'est donc pas totalement interdit de chercher à la satisfaire dans la mesure du possible. L'objectif est bien celui-ci : réutiliser les trous disponibles pour obtenir un index le plus proche possible de l'ordre alphabétique.

Malgré mon inexpérience j'ai imaginé et argumenté vis à vis des utilisateurs l'écueil que vous pointez. Reste le besoin. Je n'ai malheureusement pas la possibilité d'intervenir au niveau d'une requête comme vous le suggérez. Il s'agit d'un état standard de l'ERP qui est trié par l'index là ou les utilisateurs le souhaiteraient trié par ordre alphabétique pour des raisons de confort de lecture évidentes. Je n'ai manifestement pas la possibilité de recréer le "grand livre" de SAP Business One par moi-même !

Même si la critique et la mise en garde a tout son intérêt didactique, il m'aurait été plus utile de profiter de votre savoir pour résoudre mon problème.

[Rei Ichido]

Une table partenaires (OCRD) dont les fournisseurs sont indexés dans un champ (CardCode) sur le modèle Fxxxxx. On souhaite pouvoir réutiliser les trous de l'index (suite aux suppressions dans la table) pour réinsérer les nouveaux fournisseurs dans l'ordre alphabétique du champ nom (CardName).

Problème : l'historique est très anarchique et je ne peux pas utiliser le classement sur CardName pour positionner le CardCode.

Je ne comprend pas le besoin. CardCode est censé représenter quoi ? Un ordre alphabétique ? Un ordre d'insertion ? Si c'est bien un ordre d'insertion, pourquoi vouloir utiliser les "trous" ? Sinon, quel est le critère qui préside à la réattribution d'une telle valeur ?
Outre le fait que c'est une mauvaise idée (cf post de Waldar) le besoin n'est pas clair, au moins pour moi. Un exemple de ce qu'il y a en base actuellement et de ce qui est désiré semble le minimum pour bien se faire comprendre dans le cas présent.

Si le besoin est uniquement lié à un ordre alphabétique, alors pour déterminer le nouveau rang il suffit de faire un select avec

Code :

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

 row_number() over (order by CardName)

[oliviers92]

Pour fixer les idées :

Code :

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

SELECT TOP (20) T0.[CardCode], T0.[CardName] FROM OCRD T0 WHERE LEFT([CardCode],1) = 'F' ORDER BY T0.[CardCode]

Renvoie :

1 F00001 AJInternational
2 F00002 CALBERSON YVELINES
3 F00003 CCIJF
4 F00004 ABOTT ARTISAN
5 F00005 STANLEY SOLUTIONS DE SECURITE
6 F00006 AGILENT TECHNOLOGIES FRANCE
7 F00007 AIGOTEC GmbH
8 F00008 ALD AUTOMOTIVE
9 F00009 ALPHA MOS
10 F00011 BSI
11 F00012 AMT Emballages
12 F00013 ANA SALES FRANCE SA
13 F00014 APS Int
14 F00015 CHATEAU D'EAU
15 F00016 ARC EN CIEL
16 F00017 ARVAL
17 F00018 ASC Privée
18 F00021 Autradet
19 F00022 AVIS LOCATION DE VOITURES
20 F00023 AXANTIS

L'ensemble des partenaires sont dans la table OCRD. L'index est donc alpha numérique avec la lettre F pour discriminer les Fournisseurs des autres Partenaires.

On voit que le CardName suit dans la mesures des aberrations historiques et des éventuelles impossibilités évoquées par Waldar l'ordre alphabétique de l'index.

Cet index est généré automatiquement par une "Recherche formatée" s"appuyant sur une requête SQL dont je simplifie le code ici pour n'en donner que la partie correspondante à la génération de l'index dans le cas des fournisseurs :

Code :

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

1
2
3
4
set @max = (select max(substring(cardcode, 2, 5)) from ocrd where cardcode like 'F0%%')
set @temp = cast(@max as integer)
set @temp = @temp + 1
set @res = 'F' + right('00000'+cast(@temp as varchar(5)), 5)

soit le dernier enregistrement + 1. Pour réutiliser les trous, l'objectif est de modifier la définition de la variable @max par une requête qui renvoie le premier CardCode disponible dont le CardName est inférieur à celui de l'enregistrement en cours de création.

Problème : un trou est défini par l’enregistrement qui le précède. Comme ces enregistrements ne sont déjà pas dans l'ordre alphabétique (voir extrait de la table) cette information n'est pas fiable. Je souhaite donc me baser non pas sur OCRD brute mais sur une requête sur OCRD qui n'en renvoie que les enregistrements qui respectent l'ordre alphabétique.

Compliqué sans aucun doute, mais je suis ouvert à toute solution dans cette voie ou dans une voie alternative.

Merci d'avance pour vos suggestions et commentaires

[SQLpro]

C'est une usine à gaz dû à un modèle pourri ne respectant pas les formes normales, ni ce qu'est une table relationnelle...
Ainsi :
1) avoir deux informations dans une même colonne viole la 1ere forme normal (carcode composé d'une lettre et un n°)
2) les bases de données relationnelles reposent sur la théorie des ensembles pour lesquelles la notion d'ordre (et donc elle des lignes dans une table) n'existe pas.

Comme vous modélisez mal et partez d'un postulat faux vous obtenez une usine à gaz !

En sus votre méthode d'auto incrémentation en faisant max + 1 est non seulement catastrophique pour les performances (nécessité d'utiliser un verrou exclusif sur toute la table) mais ne garantit en aucune manière l'unicité !
À me lire : http://sqlpro.developpez.com/cours/clefs/

Renvoyez de A à Z votre conception.

A +

[oliviers92]

Bonjour,

Nous créons, tous partenaires confondus, environ 6 Partenaires par mois. Mon pragmatisme me conseil de considérer l'aspect catastrophique sur les performances comme très mineur. Serais-je pardonné ?
Je vais de ce pas consulter attentivement l'article conseillé sur les clefs, sujet un peu plus inquiétant quant-au risque de conflit suggéré. Je ferai par ailleurs un test sur jeu d'essai pour le confirmer mais je pense que ce problème est géré au niveau du moteur de SBO.

Je suis bien conscient de mes lacunes, je suis justement actuellement en train de lire avec application votre cours en ligne riche d'enseignements.

Seulement il faut toujours distinguer la théorie et la pratique. Il n'est pas question de revoir la conception d'un ERP qui est en production depuis plusieurs années. Votre remarque sur la duplicité d'information au sein de CardCode tombe sous le sens d'un analyste mais a malheureusement échappé au Consultant, avant tout un comptable, qui a mis en place SAP Business One dans notre Entreprise.

je ne suis qu'un administrateur réseau d'une PME touche-à-tout qui doit faire face à l'ensemble des problématiques en "tique" qui se présentent de l'achat à l'entretien du parc matériel et logiciel en passant par les smartphones, de la protection Antivirus et autres sujets liés à la sécurité jusqu'à la gestion du projet ERP. J'essaie donc dans la mesure de mes compétences d'apporter des réponses pratiques à des problèmes pratiques.

Mon problème concret est donc le suivant :
- SAP regroupe l'ensemble des ses partenaires (Clients, Fournisseurs, Prospects) dans la table OCRD (Il les distingue par un champ CardType)
- une règle de génération automatique du champ CardCode a été mise en place selon le principe déjà décrit : Tnnnnn ou T est le type (CardType) de partenaire et nnnnn un incrément automatique sur le principe max + 1
- le Grand Livre (état comptable que j'aurai bien du mal à vous définir) est présenté dans l'ordre alphanumérique de CardCode. Cet état comporte de nombreuses pages et les comptables souhaiteraient vivement pouvoir le consulter dans l'ordre alphabétique de CardName.
- Historiquement CardCode et CardName avaient été créés en "correspondance" mais la lisibilité du Grand Livre se dégrade au fur et à mesure de la création des nouveaux partenaires.
- D'ou l'idée d'utiliser les trous de CardCode ce que les comptables ont déjà commencé à faire à la main en contournant son automatisme de génération, ce qui me semble la pire des solutions.

Maintenant que l'aspect pratique est clairement posé, je salue toutes les mises en garde et critiques qui me sont faites sur le manque d'académisme de la solution. Elles sont formatrices pour moi et surtout d'autres néophytes qui viendraient à consulter cette discussion. Reste que j'en suis toujours au même point. Il ne s'agit plus là de conception mais d'une adaptation pratique pour laquelle je ne vois guère d'autre solution que celle basée sur l'utilisation des trous si décriée. Puis-je espérer un peu d'aide ?

PS : Si tout comme moi d'autres lecteurs de cette discussion entendent parler d'une "forme normale" pour la première fois sachez qu'il ne s'agit pas d'une simple expression mais d'un concept bien défini dans le contexte des BDR. Si j'en crois le rédacteur de l'article de Wikipedia dans le cadre de l'exemple qui nous intéresse l'utilisation du modèle Tnnnnn n'est peut-être pas si mauvais sachant que l'on travaille quasi exclusivement en lecture sur cette table et surtout sur ce champ. L’utilisateur en retire une grande facilité d'usage particulièrement lorsque l'on considère qu'une même Entreprise à la fois cliente et fournisseur donne lieu à deux Partenaires distincts. Vaut-il mieux éviter les erreurs de saisie ou respecter l'orthodoxie des normes de programmation ?

[Rei Ichido]

Ce qu'il y a c'est que le besoin que vous semblez vouloir exprimer ne correspond pas du tout à ce que vous demandez.

Vous dites vouloir utiliser "les trous" : dans l'exemple que vous donnez, il n'y en a qu'un : 19. Et je ne vois pas en quoi mettre une quelconque valeur à "cet endroit" (au sens tri sur cette valeur) changerait le fait que les comptables n'ont pas du tout de tri par ordre alphabétique. Complétez votre exemple : à quoi devrait ressembler la table d'arrivée ???

À mon avis, le besoin c'est une réindexation complète, sans aucun rapport avec les éventuels trous, non ? Et pour ça il n'y a qu'un update massif avec un tri sur CardName qui pourra le faire. En espérant que CardCode n'est pas la clé primaire (référencée par des clés étrangères) de votre table ... Donnez-nous la définition de la table et le SGBDR que vous utilisez.