Discussion :

[qi130]

Bonjour,

Je viens de débarquer sur Delphi CE (je n'avais que des starter edition) et je tente de porter une petite appli initialement conçue avec les composants UIB.

J'utilise donc FIREDAC et sa reconnaissance native de Firebird.

La connexion à la base est OK, et je récupère bien la liste des tables applicatives:

Code :

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

1
2
FDConnection1.GetTableNames('', '', '', ListBox1.Items,
            [osMy], [tkTable, tkView]);

Ensuite, pour 1 table choisie dans la listbox1, je récupère ses colonnes ainsi que celles participant à la PK:

Code :

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

1
2
FDConnection1.GetFieldNames('','',TableTemp,'',ListeColonne);   // acquisition des colonnes de la table
FDConnection1.GetKeyFieldNames('','',TableTemp,'',ListePK);     // acquisition des colonnes de la PK

Tout ça est assez bien documenté

L'étape suivante consiste à connaitre pour chaque colonne:

• son type SQL (y compris la longueur pour les char/varchar)
• les contraintes éventuelles (not null, éventuel default, est référence de FK, référence 1 FK, etc.

L'idée générale étant de proposer dynamiquement le composant qui va bien pour modifier la valeur d'une colonne, en contrôlant ce qu'on peut: taille (xCHAR), le bon format numérique, etc.

Et là je commence à butter sur le manque de documentation "appliquée" (y compris chez l'éditeur)

Je dégaine le FDMetaInfoQuery:

Code :

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

1
2
FDMetaInfoQuery1.MetaInfoKind := mkTableTypeFields;
 FDMetaInfoQuery1.Open;

qui me sert ce message :

Le projet FormulaireFB.exe a déclenché la classe d'exception EFDException avec le message '[FireDAC][Phys][FB]-339. Une valeur d'argument de méta-données [table type name] doit être spécifiée'.

dont je ne sais pas quoi faire

Une idée ?

[SergioMaster]

Bonjour, à mon avis ObjectName du composant n'est pas renseigné

Code :

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

1
2
3
4
 
 FDMetaInfoQuery1.MetaInfoKind := mkTableTypeFields;
FDMetaInfoQuery1.ObjectName:='nomdelatable';
 FDMetaInfoQuery1.Open;

[qi130]

Bonjour Serge,

'fectivement, avec le nom de la table il n'y a plus d'erreur...

Etape suivante, exploiter ce qui est sensé remonter suite au Open...

Sauf qu'a priori, rien ne remonte : RecordCount à 0 (par contre, si je "requête" avec mkTableFields, j'ai le bon nb (= au nb de colonnes))

Je suppose qu'un autre ajustement est à faire ?

Et du coup, j'anticipe:
Par rapport à ce qui est dit sur cette page, faut-il comprendre qu'il y a (quand tout marche ) autant de structures [RECNO...COLUMN_LENGTH] que de champs dans la table? Et que quand on trouve le RECNO correspondant souhaité (basé sur COLUMN_NAME), on peut utiliser les autres infos, y compris via le cast évoqué (qui me parait obscur et me ramènera sûrement dans ce forum ) ?

[qi130]

En requêtant avec mkTableFields, je progresse - il doit y avoir 1 différence subtile avec mkTableTypeFields

Je ne sais pas si on peut accéder directement par 1 indice à 1 des RECNO ?
Je m'en sors par 1 pirouette qui vaut tant que la méthode Open de FDMetaInfoQuery1 n'est pas ré-appelée:

Code :

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

1
2
3
4
5
6
for j:=0 to Count-1 do begin              // 1ère passe pour les libellés
           FDMetaInfoQuery1.First;
           while not(FDMetaInfoQuery1.Eof) do begin
              if FDMetaInfoQuery1.FieldByName('COLUMN_NAME').AsString=Strings[j] then break;
              FDMetaInfoQuery1.Next;
           end;

je reste positionné sur le RECNO qui m'intéresse et je l'exploite ensuite:

Code :

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

1
2
3
4
5
6
7
8
9
with TLabel.Create(ScrollBox1)do begin
              Left:=PosX;
              Top:=PosY;
              Caption:=Strings[j];
              ShowHint:=True;
              Hint:=FDMetaInfoQuery1.FieldByName('COLUMN_TYPENAME').AsString;
              Parent:=ScrollBox1;
              MaxWidth:=Max(MaxWidth,Width);
           end;

[SergioMaster]

mea culpa, effectivement j'utilise mktablefields et non mkTableTypeFields

[Papy214]

J'ai peut-être mal compris ton problème mais à tous hasard ...

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
procedure TDataModuleDBase.AfficheStructureTable(NomTable: string);
begin
  FDMetaInfoQuery1.MetaInfoKind   := TFDPhysMetaInfoKind.mkTableTypeFields;
  FDMetaInfoQuery1.BaseObjectName := NomTable;
  FDMetaInfoQuery1.Active       := True;
  while not FDMetaInfoQuery1.Eof do
  begin
    DoLog('COLUMN_NAME = ' + FDMetaInfoQuery1.FieldByName('COLUMN_NAME').AsString);
    DoLog('COLUMN_POSITION = ' + FDMetaInfoQuery1.FieldByName('COLUMN_POSITION').AsString);
    DoLog('COLUMN_DATATYPE = ' + FDMetaInfoQuery1.FieldByName('COLUMN_DATATYPE').AsString);
    DoLog('COLUMN_TYPENAME = ' + FDMetaInfoQuery1.FieldByName('COLUMN_TYPENAME').AsString);
    DoLog('COLUMN_PRECISION = ' + FDMetaInfoQuery1.FieldByName('COLUMN_PRECISION').AsString);
    DoLog('COLUMN_SCALE = ' + FDMetaInfoQuery1.FieldByName('COLUMN_SCALE').AsString);
    DoLog('COLUMN_LENGTH = ' + FDMetaInfoQuery1.FieldByName('COLUMN_LENGTH').AsString);
    DoLog('');
    FDMetaInfoQuery1.Next;
  end;
  FDMetaInfoQuery1.Active := False;
end;

COLUMN_NAME = <le nom du champ>;
COLUMN_POSITION = 1
COLUMN_DATATYPE = 11
COLUMN_TYPENAME = Numeric
COLUMN_PRECISION = 16
COLUMN_SCALE = 0
COLUMN_LENGTH = 0

COLUMN_NAME = <le nom du champ>;
COLUMN_POSITION = 2
COLUMN_DATATYPE = 18
COLUMN_TYPENAME = Date
COLUMN_PRECISION = 0
COLUMN_SCALE = 0
COLUMN_LENGTH = 0

COLUMN_NAME = <le nom du champ>;
COLUMN_POSITION = 3
COLUMN_DATATYPE = 11
COLUMN_TYPENAME = Numeric
COLUMN_PRECISION = 16
COLUMN_SCALE = 0
COLUMN_LENGTH = 0

[qi130]

J'ai peut-être mal compris ton problème mais à tous hasard ...

Rassure toi, tu es parfaitement dans le sujet

[SergioMaster]

L'utilisation de mkTableFields ou de mkTableTypeFields dépend peut-être du SGBD

Pour ce qui est du code du post #4
j'ai du mal à comprendre.

[SergioMaster]

Par curiosité, j'ai testé sur une BDD SQLite puis sur une BDD Firebird

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
procedure TForm15.DBGrid1CellClick(Column: TColumn);
begin
GetInfos;
end;
 
procedure TForm15.FormCreate(Sender: TObject);
begin
FDMetaInfoQuery1.Open;
getinfos;
end;
 
procedure TForm15.getinfos;
begin
Label1.Caption:='mkTables #'+FDMetaInfoQuery1.RecNo.ToString;
FDMetaInfoQuery2.Active:=False;
FDMetaInfoQuery2.ObjectName:=FDMetaInfoQuery1TABLE_NAME.AsString;
FDMetaInfoQuery2.Active:=True;
FDMetaInfoQuery3.Active:=False;
FDMetaInfoQuery3.ObjectName:=FDMetaInfoQuery1TABLE_NAME.AsString;
FDMetaInfoQuery3.Active:=True;
end;

Il doit y avoir une différence subtile entre mktableFields et mkTableTypeFields car pour ces 2 SGBD le second ne renvoi rien !

[qi130]

Il doit y avoir une différence subtile entre mktableFields et mkTableTypeFields car pour ces 2 SGBD le second ne renvoi rien !

Comme précédemment pressenti

Au demeurant, je suis tombé sur ce code mettant en œuvre 2 FDMetaInfoQuery fonctionnant en maître-esclave (lignes 370 et suivantes)

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 meta.MetaInfoKind := MASTER[kind];
      meta.ObjectName := TableName;
      meta.Open;
      while not meta.Eof do begin
        indexs.MetaInfoKind := CHILD[kind];
        indexs.BaseObjectName := TableName;
        indexs.ObjectName := meta.FieldByName('INDEX_NAME').AsString;
        indexs.Open;
        F.IndexName := StringToUTF8(indexs.ObjectName);
        F.IsPrimaryKey := not kind;
        F.KeyColumns := '';
        while not indexs.Eof do begin
          ColName := StringToUTF8(indexs.FieldByName('COLUMN_NAME').AsString);
          if F.KeyColumns='' then
            F.KeyColumns := ColName else
            F.KeyColumns := F.KeyColumns+','+ColName;
          indexs.Next;
        end;
        FA.Add(F);
        indexs.Close;
        meta.Next;
      end;
      meta.Close;
    end;

Je me demande s'il ne faut pas une approche similaire pour lever cette subtilité ?

Du coup,

Table Field List (mkTableFields) and Table Type Field List (mkTableTypeFields)

serait à prendre au pied de la lettre, sans décorréler les 2 paramètres mkTable...

J'ai aussi trouvé la méthode SaveToFile qui permet d'obtenir entre autres un XML du résultat d'une requête. Ca aide à comprendre certaines choses.

[qi130]

Alors, je développe mon idée

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
FDMetaInfoQueryM.MetaInfoKind := mkForeignKeys;
           FDMetaInfoQueryM.ObjectName:=CurrentTable;
           FDMetaInfoQueryM.BaseObjectName:='';
           FDMetaInfoQueryM.Open;
           FDMetaInfoQueryM.SaveToFile('C:\FB2.17\Master.xml',sfAuto);
           while not FDMetaInfoQueryM.Eof do begin
              FDMetaInfoQueryD.MetaInfoKind:=mkForeignKeyFields;
              FDMetaInfoQueryD.BaseObjectName :=CurrentTable;
              FDMetaInfoQueryD.ObjectName:=FDMetaInfoQueryM.FieldByName('FKEY_NAME').AsString;
              FDMetaInfoQueryD.Open();
              FDMetaInfoQueryD.SaveToFile('C:\FB2.17\Detail.xml',sfAuto);
              Break;
           end;

Le "break" est là pour prendre 1 photo
On obtient les xml suivant:
Le "Master" dont la requête interroge sur l'existence de contrainte(s) de type FK portée(s) par CurrentTable:

Code :

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

1
2
3
<Row RowID="0">
   <Original RECNO="1" TABLE_NAME="TEST04" FKEY_NAME="INTEG_25" PKEY_TABLE_NAME="TEST05" DELETE_RULE="2" UPDATE_RULE="2"/>
</Row>

La table ciblée figure également ainsi que les règles découlant d'éventuels ON DELETE/UPDATE.
Je trouve au passage que le nom du champ FKEY_NAME est trompeur: il laisse espéré la Foreign KEY cherchée

Le "Detail" qui exploite la contrainte:

Code :

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

1
2
3
<Row RowID="0">
   <Original RECNO="1" TABLE_NAME="TEST04" FKEY_NAME="INTEG_25" COLUMN_NAME="MACOLONNE" PKEY_COLUMN_NAME="COLPK" COLUMN_POSITION="1"/>
</Row>

La contrainte est portée par la table TEST04 et s'applique à sa colonne MACOLONNE dont le contenu doit exister dans COLPK de TEST05 .

Du coup, il y a une dépendance "hiérarchique" qui semble interdire la recherche inverse

pour 1 table/colonne donnée, sert-elle de référence FK à une autre colonne?

d'autant que "Detail" ne ramène pas la table (TEST05), seulement la colonne ciblée (COLPK).
Bon, c'est peut-être lié à l'universalité de FireDac ?

Bref, pour un usage peu fréquent, et une fois qu'on a compris l'architecture du système, ça marche; mais pour un usage intensif, il me semblerait préférable de se constituer son référentiel MetaData pérenne à base de Listes afin d'éviter de requêter à tous bouts de champ. Par parenthèse, les UIB procèdent ainsi (y a plus qu'à piocher dedans)

[qi130]

Bon, j'ai passé la journée à tenter de comprendre pourquoi la double boucle n'amenait pas l'intégralité des éléments attendus...

A force de traces, la réponse m'est apparue à l’entame de la digestion (comme quoi )

Si la FK est déclarée par un

Code :

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

ALTER TABLE .... ADD FOREIGN KEY...

le nom de la contrainte est attribué par le serveur genre

INTEG_nnn

et FireDAC ramène correctement les infos.

Par contre, si la FK est mise en place par

Code :

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

1
2
3
4
5
ALTER TABLE ...
  ADD CONSTRAINT "RefTAB_COMPUTER9"
  FOREIGN KEY (COMPUTER_ID)
  REFERENCES TAB_COMPUTER (COMPUTER_ID)
  USING INDEX "RefTAB_COMPUTER9";

(cette syntaxe est générée par mon soft de modélisation - je vérifierai si une autre méthode de déclaration de FK est proposée)

FireDAC passe au travers

Ceci dit, comme je n'ai pas constaté que FireDAC permettait de récupérer les contraintes

Je vais néanmoins poursuivre et m'intéresser aux INDEX (j'y trouverai peut-être les FK manquantes).