FireDAC / Oracle : pb casse sur colonne indexée

Bonjour à tous,

Ayant migré une application Oracle développée avec Delphi 7 et utilisant le BDE, vers XE10 utilisant FireDAC , je suis confronté au problème suivant (qui ne se produisait pas avec le BDE) avec une table ayant la clé primaire égale à une colonne : la casse minuscules/majuscules semble ignorée et, ayant inséré un premier enregistrement comportant (par exemple) "AA" comme valeur de la clé, l'insertion d'un enregistrement ayant "aa" comme valeur de la clé échoue pour cause de clé dupliquée.

Quelqu'un aurait-il une idée ?

Bonjour,

face à un problème de ce genre, j'ai cette approche :
- soit il s'agit d'un problème de BDD par exemple de version supportée par Firedac (version 8.0.3 et ultérieure)
- soit il s'agit d'un problème de connexion (Firedac propose beaucoup d'options à la connexion) vérifier entre autre CharacterSet http://docwiki.embarcadero.com/RADSt...rver_(FireDAC)
- soit il s'agit d'un problème de Catalogue (ne connaissant Oracle que de nom je ne sais pas s'il y a lieu de s'en occuper)
- soit il s'agit d'un problème relatif à la mise à jour sensu stricto (il n'est pas dit s'il s'agit d'une mise à jour en cache par exemple)

pour isoler, je ferai le test suivant
Dans une table vierge TABLETEST avec deux colonnes LACLE (PRIMARY KEY) , LELIBELLE
uniquement avec la connexion FDConnection et après avoir vérifier la compatibilité de version
je tenterai

Code:

---

1 2 3 4 5 6

try FDConnection.ExecSQL('INSERT INTO TABLETEST VALUES(:lacle,:lelibelle)',['aa','minuscules']); FDConnection.ExecSQL('INSERT INTO TABLETEST VALUES(:lacle,:lelibelle)',['AA','majuscules']); FDConnection.ExecSQL('INSERT INTO TABLETEST VALUES(:lacle,:lelibelle)',['aA','mixed']); except end;

---

et vérifierai me contenu de ma table via un GUI indépendant (P.S. je profiterai également de ce GUI pour tester une insertion du même type directement, il y a pas mal d'option de transaction qui peuvent jouer)

Si cette partie là fonctionne, alors il s'agit d'un problème de table ou requête (qui peuvent avoir elles aussi des options de connexion différentes)

Bonjour SergioMaster,

Merci d'avoir pris le temps de me répondre et de me fournir des pistes.

J'ai effectué la manipulation suggérée, à savoir insérer ces 3 enregistrements avec ExecSQL. Ils se sont bien insérés, sans exception, et une requête SELECT les visualise bien:

Pièce jointe 327291

Donc je rectifie ma formulation initiale, il n'y a pas à ce stade de refus d'insertion pour cause pour clé dupliquée.

En revanche, et c'est finalement ça mon problème, en utilisant un composant FDTable associé à un TDbGrid pour les visualiser, j'ai voulu parcourir la table avec les instructions suivantes:

Code:

---

1 2 3 4 5 6 7 8

with LaTable do begin Open; First; while not Eof do Next; end;

---

La boucle s'effectue bien 3 fois, mais le résultat affiché est:

Pièce jointe 327289

comme si le NEXT ne s'effectuait pas sans entraîner EOF=vrai

Pour aller plus loin, j'ai fait une 4ème insertion:

Code:

---

FDConnection.ExecSQL('INSERT INTO TABLETEST VALUES(:lacle,:lelibelle)',['bb','minuscules2']);

---

et j'obtiens cette fois:

Pièce jointe 327294

Donc, le problème ne provient pas des minuscules en tant que telles, mais de la non distinction de la casse au niveau de la clé.

J'ai bien cherché au niveau des (très) nombreuses options, que ce soit des TFDConnection que des TFDTable, je n'en ai pas trouvé une qui semble pouvoir agir là-dessus.

Une précision: ce problème se produit avec une base Oracle, pas avec une base PostGreSQL.

Bonjour,

J'ai résolu mon problème. Pour information, voici résumé le problème et l'explication qui m'a fourni une solution.

Dans mon application, je lis les enregistrements des tables au moyen d'un TFDTable et ses méthodes: First, Next, Eof et non au moyen d'un TFDQuery. Sur une table dont la clé primaire de type varchar pouvait contenir des minuscules et majuscules, le Next parcourait bien les enregistrements jusqu'au dernier mais ensuite Eof restait faux et le Next me renvoyait des enregistrements qu'il m'avait déjà donnés.

Ce problème était bien lié au fait que la clé pouvait contenir des minuscules et des majuscules, car il ne se produisait pas sur celles n'ayant pas cette caractéristique.

J'ai fini par découvrir, par encadrement successif, que ce phénomène était dû à l'emploi de la méthode RecNo du TFDTable à l'intérieur de la boucle du Next. En retirant cette ligne (ça tombe bien: j'ai constaté qu'elle ne servait en fait à rien !), le problème a disparu. Il semble que RecNo et Next ne fassent pas bon ménage dans ce cas précis, le premier perturbe alors manifestement le second (précision: problème constaté uniquement avec Oracle).