PC SOFT

FORUMS PROFESSIONNELS
WINDEVWEBDEV et WINDEV Mobile

Accueil → WINDEV 2024 → Besoin de l'avis de la masse
Besoin de l'avis de la masse
Débuté par agrieco, 01 déc. 2005 11:33 - 7 réponses
Posté le 01 décembre 2005 - 11:33
En interne, pour notre application de facturation, nous utilisons une
numérotation alphanumérique pour nos factures.

J'ai donc une table Fact ou deux rubriques sont clés uniques :

IDFact (NuméroAuto)
NumeroFacture (Texte)

J'aurai souhaité avoir votre avis quand à l'utilisation d'une clef unique
sur une rubrique alphanum qui contiendra des espaces et des "-". Ma question
vient du fait que je rencontre régulièrement des problèmes de doublons pour
des valeurs qui existent pas encore !!! Exemple, une erreur de doublon pour
la valeur "TP-2005-11-9" alors que cette valeur n'existe nul part !!! Et je
rencontre ce problème aléatoirement lors de Hajoute ou Hmodifie.

Merci de me faire part de votre expérience ou votre avis sur le sujet

--
Cordialement,

GRIECO Anthony
SGTP Laclau
agrieco@laclau.fr
Posté le 01 décembre 2005 - 11:06
Quatre idées qui me viennent à l'esprit:
1. N'y a-t-il réellement que deux clés uniques ?
2. La clé unique contrôlée par programmation est-elle correctement initialisée au moment de l'ajout ou de la modification ?
3. Une réindexation du fichier remet parfois des choses en place.
4. Visionner le fichier avec WDMap permet aussi de constater certains dégâts occasionnés à des fichiers corrompus à cause de virus, de fermeture intempestive...
Posté le 01 décembre 2005 - 11:31
Bonjour,

Les fiches détruites ne sont pas détruites physiquement.

Tu peux d'ailleurs réaliser une lecture séquentielle avec affichage pour vérifier.

Elles sont seulement déclarées détruites à l'aide d'un code. Dès lors elles ne sont plus visibles mais continuent d'exister.

Bien cordialement,

Jacques De Schryver
Membre de la masse
Posté le 01 décembre 2005 - 11:38
Bonjour,
J'ai eut un problème similaire, avec des codes du style XXXXX/XX, la partie /XX etant facultative La solution fut de cocher l'option "sensible aux espaces,ponctuations et caractères spéciaux" dans les proriétés de la clé. Sinon la vérification d'unicité ne prend pas en compte les - dans ta clé, et de ce fait TP-2005-1-19 et TP-2005-11-9 sont considérés comme identiques.

Frédéric.
Posté le 01 décembre 2005 - 12:21
GRIECO Anthony a écrit :
En interne, pour notre application de facturation, nous utilisons une
numérotation alphanumérique pour nos factures.

J'ai donc une table Fact ou deux rubriques sont clés uniques :

IDFact (NuméroAuto)
NumeroFacture (Texte)

J'aurai souhaité avoir votre avis quand à l'utilisation d'une clef unique
sur une rubrique alphanum qui contiendra des espaces et des "-". Ma question
vient du fait que je rencontre régulièrement des problèmes de doublons pour
des valeurs qui existent pas encore !!! Exemple, une erreur de doublon pour
la valeur "TP-2005-11-9" alors que cette valeur n'existe nul part !!!

????
ça n'est en principe pas possible, sauf si la valeur que tu indiques
doit être complétée par la suite, et ne représente qu'une partie de la clé.
si TP-2005-11-9 devient TP-2005-11-9-000653, par exemple.
Dans ce cas, lors de ta recherche pour savoir si ta clé alpha existe ou
non, tu dois compléter ta rubrique de recherche à la longueur définie
dans l'analyse :
hlitrecherche(monfic,macle,"TP-2005-11-9") va trouver au moins un record
commençant par "TP-2005-11-9"
par contre :
hlitrecherche(monfic,macle,complete("TP-2005-11-9",30)) ne trouvera sans
doute rien.
sinon, utilises les clés composées.
PS : complete tes zones 'date' :
"TP-2005-11-09" au lieu de "TP-2005-11-9"
surtout dans des clés de longueur fixe




--
Jacques Trepp
Albygest - 81160 - St Juery
jacques-pas de spam.trepp@free.fr
(enlever '-pas de spam' pour me joindre)
http://www.albygest.com
Posté le 01 décembre 2005 - 12:22
Il n'y a en effet que deux clefs uniques, et le problème concerne bien
NumFact vu que c'est le champ qui pose problème dans la fenêtre d'erreur de
doublon.

Je ne consulte mes fichiers qu'à l'aide de WDMAP, c'est de cette manière que
j'ai pu être certain de intégrité de mon fichier et de la non présence d'une
autre valeur identique.

Et, enfin, j'ai réinsérer le fichier des centaines de fois sans résultat...
seule solution, passer la clef unique en clef multiple, ce qui m'oblige a
gérer l'absence de doublons moi même...

--
Cordialement,

GRIECO Anthony
SGTP Laclau
agrieco@laclau.fr


"Daniel C" <daniel.cavrenne@scarlet.be> a écrit dans le message de news:
438ec499$1@news.pcsoft.fr...

Quatre idées qui me viennent à l'esprit:
1. N'y a-t-il réellement que deux clés uniques ?
2. La clé unique contrôlée par programmation est-elle correctement
initialisée au moment de l'ajout ou de la modification ?
3. Une réindexation du fichier remet parfois des choses en place.
4. Visionner le fichier avec WDMap permet aussi de constater certains
dégâts occasionnés à des fichiers corrompus à cause de virus, de fermeture
intempestive...


Posté le 01 décembre 2005 - 13:04
Merci beaucoup pour toutes vos informations !!!!

Je mets le tout à profit ce week end...

--
Cordialement,

GRIECO Anthony
SGTP Laclau
agrieco@laclau.fr


"Frédéric DEMILLY" <f.demilly@pacificpeche.fr> a écrit dans le message de
news: 438ecc51$1@news.pcsoft.fr...

Bonjour,
J'ai eut un problème similaire, avec des codes du style XXXXX/XX, la
partie /XX etant facultative La solution fut de cocher l'option "sensible
aux espaces,ponctuations et caractères spéciaux" dans les proriétés de la
clé. Sinon la vérification d'unicité ne prend pas en compte les - dans ta
clé, et de ce fait TP-2005-1-19 et TP-2005-11-9 sont considérés comme
identiques.

Frédéric.
Posté le 02 décembre 2005 - 06:57
Bonjour,

Ta clé unique est un chaine de caractères.
Dans windev 9, dans l'analyse, au niveau de la description des rubriques, tu peux préciser si ta clé est : Sensible à la Casse
Sensible à l'accentuation
Sensible aux espaces, ponctuations et caractères spéciaux.

En jouant sur ces leviers tu devrais pouvoir résoudre ton problème.

AJC+