1. #1
    Membre à l'essai
    Profil pro
    Inscrit en
    mai 2005
    Messages
    26
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mai 2005
    Messages : 26
    Points : 21
    Points
    21

    Par défaut 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 ?

  2. #2
    Rédacteur/Modérateur

    Avatar de SergioMaster
    Homme Profil pro
    Développeur informatique
    Inscrit en
    janvier 2007
    Messages
    8 442
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 61
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Industrie

    Informations forums :
    Inscription : janvier 2007
    Messages : 8 442
    Points : 19 720
    Points
    19 720
    Billets dans le blog
    4

    Par défaut

    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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)
    La seule chose absolue dans un monde comme le nôtre, c'est l'humour. » Albert Einstein
    J'entends et j'oublie. Je vois et je me souviens. Je fais et je comprends . Confucius
    Si votre seul outil est un marteau, vous aurez tendance a ne voir que des clous

  3. #3
    Membre à l'essai
    Profil pro
    Inscrit en
    mai 2005
    Messages
    26
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mai 2005
    Messages : 26
    Points : 21
    Points
    21

    Par défaut

    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:

    Nom : Capture.PNG
Affichages : 21
Taille : 1,1 Ko

    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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:

    Nom : Capture.PNG
Affichages : 20
Taille : 1,0 Ko

    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    FDConnection.ExecSQL('INSERT INTO TABLETEST VALUES(:lacle,:lelibelle)',['bb','minuscules2']);
    et j'obtiens cette fois:

    Nom : Capture.PNG
Affichages : 21
Taille : 1,3 Ko

    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.

  4. #4
    Membre à l'essai
    Profil pro
    Inscrit en
    mai 2005
    Messages
    26
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mai 2005
    Messages : 26
    Points : 21
    Points
    21

    Par défaut Résolu

    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).

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. [Débutant] Oracle et tri sur colonnes
    Par TheReturnOfMuton dans le forum ASP.NET
    Réponses: 0
    Dernier message: 27/08/2012, 10h25
  2. partition sur colonne date en Oracle 10.2.0.4
    Par debdba dans le forum Oracle
    Réponses: 4
    Dernier message: 13/10/2011, 19h49
  3. Jointure sur un index à deux colonnes
    Par hbellahc dans le forum Adaptive Server Enterprise
    Réponses: 5
    Dernier message: 10/03/2011, 20h15

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo