Clé primaire sensible à la casse

Bonjour,
A la demande de mes utilisateurs, j'ai repris une application développée il y a plus de 20 ans sous Clipper (avec fichiers DBF) pour la basculer sous Access 2010.
J'ai une table dont la clé primaire (CODE_INDEX) est sensible à la casse, ce que je ne savais pas au début (par exemple, je peux avoir deux CODE_INDEX : CA005510 et Ca005510). Je viens d'être prévenu par les utilisateurs...Or toute ma conception est déjà terminée (code VBA, requêtes, forms et reports, etc.).

Comment puis-je faire pour palier à ce problème sans que ça me fasse perdre trop de temps ?
J'ai trouvé ces 4 solutions sur le support de Microsoft mais je ne suis pas sûr de la meilleure solution à adopter. Je pensais à : Développement hexadécimal. Le champ binaire ne pouvant apparemment pas stocker de chaînes de plus de 3 caractères et car on ne peut pas faire de WHERE sur un champ binaire.

Qu'en pensez-vous ?

Merci d'avance pour vos réponses éclairées.

Salut,

la fonction StrComp me parait être la plus simple à mettre en place.

Mais tout va de toute façon dépendre de la volumétrie de requêtes qui sont déjà existantes dans ta base + le nombre de requêtes générées/utilisées dans ton code VBA...

Merci pour ta réponse. Le problème à ce moment-là qui se pose est comment dois-je paramétrer le champ CODE_INDEX de ma table ?
En effet, si je le mets en texte et en clé primaire (avec un index unique donc), il m'est impossible de saisir deux codes de type 'CA005510' et 'Ca005510'.
Suis-je obligé d'abandonner l'idée de créer un INDEX unique sur ce champ ?

Des pistes :
http://www.developpez.net/forums/d37...ensible-casse/

Mais il semblerait que le moteur JET d'Access considère par défaut que 'ABC' est comme 'abc'...

Merci JPcheck, je l'ai déjà lu ce topic ;) Je vais continuer mes recherches et faire quelques essais.
Si d'autres solutions je suis preneur. Dans tous les cas, je mettrai à jour ce topic en fonction de la solution retenue :)

Bon, finalement je pense adopter la solution suivante :
L'idée est de stocker mon CODE_INDEX en code ASCII et d'en faire la clé primaire.
Sur ma table, je supprime la clé primaire sur CODE_INDEX et je crée un autre champ CODE_INDEX_ASC (TEXT(255)) que je place en clé primaire.
Ensuite, je crée un trigger (macro de données avant modification) pour définir ce champ avec la valeur ConvertAscii([CODE_INDEX]).
La fonction ConvertAscii est définie par :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

Public Function ConvertAscii(InputString As String) As String Dim lngLoop As Long Dim strOutputString   For lngLoop = 1 To Len(InputString) strOutputString = strOutputString & Format(Asc(Mid$(InputString, lngLoop, 1)), "000") Next lngLoop   ConvertAscii = strOutputString   End Function

---

ça fonctionne nickel à l'insertion ou la mise à jour de données :)
Il me reste plus qu'à modifier les tables qui y sont liées ainsi que mes requêtes stockées ou générées en VBA....Allez je retrousse mes manches et c'est parti !

J'aurais gagné pas mal de temps à avoir cette info (CODE_INDEX case sensitive) lors de la récolte des besoins...ça me servira pour les prochaines fois :p