Firedac, BatchMove, ajout d'un champ à la table de destination

Version imprimable

Voir 40 message(s) de cette discussion en une page

26/07/2021, 14h13
GrPtj

oui dans le code de création j'ai les champs à créer : ID Integer ...
mais je voudrais créer tous les champs de ma table existante sans les écrire un par un.
J'ai mis 'select * from MATABLE' pour montrer le genre de code que je suppose exister pour la création ?
Peut-être y a-t-il un moyen avec les tables Rdb$relations de récupérer les champs comme la DLL dans IBExpert ?
26/07/2021, 16h15
ShaiLeTroll

La table MATABLE change-t-elle de structure ?
Est-elle différente selon le client pour ne pas savoir les colonnes ?
Il est assez facile de récupérer le FieldDefs à partir du SELECT vide pour générer à la volée le CREATE TABLE (un petit template, format, %s, un case et le tour est joué)
Les INSERT pourront être aussi généré en Delphi, je l'ai fait pour passer de Paradox à Oracle par exemple, le programme Delphi génère un SQL executable avec ADOQuery, je l'ai fait aussi pour MySQL mais cette fois c'était MySQL ADmin qui pouvait l'injecter.

Sur ORACLE, c'est ce que je faisais, CREATE GLOBAL TEMPORAY TABLE
en ON COMMIT DELETE ROWS d'ailleurs car c'était juste des tables de travail dont je n'avais pas l'utilité de conserver le contenu qui était agrégé dans des tables d'archive.
26/07/2021, 16h31
GrPtj

Citation:

La table MATABLE change-t-elle de structure

NON

Citation:

Il est assez facile de récupérer le FieldDefs

Je sais lire MATABLE dans une FDTable et récupérer FDTable.Fieddefs.
Faut-il donc récupérer les champ de fielddefs dans une variable ListeChamp(string) et ensuite l'insérer dans la requête de création ?
CREATE GLOBAL TEMPORARY TABLE TEST ListeChamp ON COMMIT PRESERVE ROWS

Si c'est bien l'idée, je vais chercher comment construire la variable ListeChamp.
26/07/2021, 17h31
tourlourou

SQLite stocke pour chaque table une procédure (actualisée en cas de modification) qui correspond à son CREATE. Est-ce le cas avec Firebird ?
26/07/2021, 18h36
tourlourou

Sinon, quid d'un DESCRIBE ?

Citation:

Envoyé par GrPtj

Peut-être y a-t-il un moyen avec les tables Rdb$relations de récupérer les champs comme la DLL dans IBExpert ?

Quelque chose comme ça

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
SELECT
  RF.RDB$FIELD_NAME FIELD_NAME,
  CASE F.RDB$FIELD_TYPE
    WHEN 7 THEN
      CASE F.RDB$FIELD_SUB_TYPE
        WHEN 0 THEN 'SMALLINT'
        WHEN 1 THEN 'NUMERIC(' || F.RDB$FIELD_PRECISION || ', ' || (-F.RDB$FIELD_SCALE) || ')'
        WHEN 2 THEN 'DECIMAL'
      END
    WHEN 8 THEN
      CASE F.RDB$FIELD_SUB_TYPE
        WHEN 0 THEN 'INTEGER'
        WHEN 1 THEN 'NUMERIC('  || F.RDB$FIELD_PRECISION || ', ' || (-F.RDB$FIELD_SCALE) || ')'
        WHEN 2 THEN 'DECIMAL'
      END
    WHEN 9 THEN 'QUAD'
    WHEN 10 THEN 'FLOAT'
    WHEN 12 THEN 'DATE'
    WHEN 13 THEN 'TIME'
    WHEN 14 THEN 'CHAR(' || (TRUNC(F.RDB$FIELD_LENGTH / CH.RDB$BYTES_PER_CHARACTER)) || ') '
    WHEN 16 THEN
      CASE F.RDB$FIELD_SUB_TYPE
        WHEN 0 THEN 'BIGINT'
        WHEN 1 THEN 'NUMERIC(' || F.RDB$FIELD_PRECISION || ', ' || (-F.RDB$FIELD_SCALE) || ')'
        WHEN 2 THEN 'DECIMAL'
      END
    WHEN 27 THEN 'DOUBLE'
    WHEN 35 THEN 'TIMESTAMP'
    WHEN 37 THEN
     IIF (COALESCE(f.RDB$COMPUTED_SOURCE,'')<>'',
      'COMPUTED BY ' || CAST(f.RDB$COMPUTED_SOURCE AS VARCHAR(250)),
      'VARCHAR(' || (TRUNC(F.RDB$FIELD_LENGTH / CH.RDB$BYTES_PER_CHARACTER)) || ')')
    WHEN 40 THEN 'CSTRING' || (TRUNC(F.RDB$FIELD_LENGTH / CH.RDB$BYTES_PER_CHARACTER)) || ')'
    WHEN 45 THEN 'BLOB_ID'
    WHEN 261 THEN 'BLOB SUB_TYPE ' || F.RDB$FIELD_SUB_TYPE
    ELSE 'RDB$FIELD_TYPE: ' || F.RDB$FIELD_TYPE || '?'
  END FIELD_TYPE,
  IIF(COALESCE(RF.RDB$NULL_FLAG, 0) = 0, NULL, 'NOT NULL') FIELD_NULL,
  CH.RDB$CHARACTER_SET_NAME FIELD_CHARSET,
  DCO.RDB$COLLATION_NAME FIELD_COLLATION,
  COALESCE(RF.RDB$DEFAULT_SOURCE, F.RDB$DEFAULT_SOURCE) FIELD_DEFAULT,
  F.RDB$VALIDATION_SOURCE FIELD_CHECK,
  RF.RDB$DESCRIPTION FIELD_DESCRIPTION
FROM RDB$RELATION_FIELDS RF
JOIN RDB$FIELDS F ON (F.RDB$FIELD_NAME = RF.RDB$FIELD_SOURCE)
LEFT OUTER JOIN RDB$CHARACTER_SETS CH ON (CH.RDB$CHARACTER_SET_ID = F.RDB$CHARACTER_SET_ID)
LEFT OUTER JOIN RDB$COLLATIONS DCO ON ((DCO.RDB$COLLATION_ID = F.RDB$COLLATION_ID) AND (DCO.RDB$CHARACTER_SET_ID = F.RDB$CHARACTER_SET_ID))
WHERE  RF.RDB$RELATION_NAME=:nomdelatable
ORDER BY RF.RDB$FIELD_POSITION

Mais, encore une fois je ne comprends pas le pourquoi

27/07/2021, 08h30
GrPtj

Merci,
je ne connais pas bien le langage pour les tables système, c'est ce que je cherchais.

Citation:

Mais, encore une fois je ne comprends pas le pourquoi

J'ai une table avec les données des commandes client
Un utilisateur veut modifier une commande
1/ Il charge les données dans une table temporaire et les modifie
2/ les lignes modifiées dans la table temporaire sont reportées dans la table de départ (données des commandes client).

- plusieurs personnes peuvent modifier la même commande ce qui explique ma recherche sur les 'verrous'
- une personne peut être dérangée et laisser la commande ouverte ce qui explique que le client ne doit pas travailler directement sur la table des données des commandes client pour ne pas bloquer les autres accès potentiels.
- j'étais partie sur des MemTables avec batchmove, j'essaie les tables globales que je ne connaissais pas.

Apparemment je ne prends pas le plus simple pour ce faire de ton point de vue ?
merci de ton attention et de ton aide.
27/07/2021, 08h57
SergioMaster

Bonjour,

Je parlais du pourquoi de la création par programmation de la table GTT. La table GTT est une structure de table à ne créé q'une fois dans la base de données d'où cette interrogation.

Citation:

Envoyé par GrPtj

- plusieurs personnes peuvent modifier la même commande ce qui explique ma recherche sur les 'verrous'
- une personne peut être dérangée et laisser la commande ouverte ce qui explique que le client ne doit pas travailler directement sur la table des données des commandes client pour ne pas bloquer les autres accès potentiels.

Apparemment je ne prends pas le plus simple pour ce faire de ton point de vue ?

La même commande peut-être, mais pas la même ligne donc un LOCK sur la ligne en cours d'édition devrait faire une bonne partie du travail
Des EVENTs (et donc le suivi des Events dans les programmes) notifieront aux utilisateurs sur la même commande (en "interrogation") que la ligne est en cours de modification
Fait comme ça, il n'y a même pas besoin de GTT ou de FDMemTables.
Bien sûr, cela dépend de l'interface utilisateur si vous utilisez des grilles (DBGrid) pour faire les modifications cela ne peut pas fonctionner
27/07/2021, 09h11
GrPtj

encore merci pour ton aide

Voir 40 message(s) de cette discussion en une page