Discussion :

[Papy214]

Bonjour

Je continue dans mes problèmes de base.

Pour transférer les données de DBase à Firebird, j'utilise un TFDBatchmove + TFDBatchMoveSQLReader et writer.

Après avoir ajouté un mapping entre booléen DBase et Smallint Firebird, je lance ma conversion.

Première table : réussi

Seconde table: je tombe sur violation de clé unique (la clé que j'ai définie comme clé primaire dans ma base cible Firebird.
Pourtant, le même type de clé existe sur la table précédent et ne pose aucun problème.
Je laisse tourner le programme et sur une autre table, idem.

On dirait que parfois, le trigger de firebird ne fait pas son boulot correctement.
Est-ce possible ??

Autre piste : les tables DBase n'ont pas de clé primaire et j'ai complété chaque table cible par ajout dune clé primaire + trigger + generator.

La différence de nombre de colonnes peut-elle justifier ce problème ?

[Papy214]

Ah,un fait intéressant !

Il y a une colonne source (la première de la table) qui a une valeur qui devrait être unique mais qui ne l'est malheureusement pas.
Bizarrement, pour renseigner la clé primaire de la table Firebird, le TBatchmove prend cette valeur et forcément, quand on retrouve une valeur déjà utilisée, ça ne passe pas.

Mais alors, question : Pourquoi le trigger n'est-il pas utilisé et pourquoi c'est la valeur de la première colonne source qui est prise à la place ?

Exemple:
Source DBase, Table A1,
A = 2
B = 3
C = 8

Destination Firebird, Table A1
P = 2 <<<<-----
A = 2
B = 3
C = 8

[SergioMaster]

Bonjour,

Je continue dans mes problèmes de base.

je vois ça

Après avoir ajouté un mapping entre booléen DBase et Smallint Firebird, je lance ma conversion.

un domaine %BOOL% aurait peut-être fait l'affaire ? et Firebird 3 connait le BOOLEAN

On dirait que parfois, le trigger de firebird ne fait pas son boulot correctement.
Est-ce possible ??
2°Post Pourquoi le trigger n'est-il pas utilisé et pourquoi c'est la valeur de la première colonne source qui est prise à la place ?

Gros doute, mais il faudrait encore voir le trigger

La différence de nombre de colonnes peut-elle justifier ce problème ?

Faudrait voir côté Writer, est-ce que les colonnes sont déclarées pour la Table Firebird ?

[Papy214]

Je suis resté sur un Firebird 2.5 pour ce projet.

Alors, j'ai résolu le problème en utilisant une requête dans le ReadSQL de TFDBatchMoveSQLReader1.
J'ai ajouté un une valeur bidon en premier et au moment de l'écriture, si le champ source porte ce nom, j'utilise un entier que j'incrémente à chaque ligne lue.

La base source est très grosse et l'import tourne depuis plus d'une heure sans planter. Je pense en être au 3/4 environ.

[SergioMaster]

Je suis resté sur un Firebird 2.5 pour ce projet.

il n'empêche qu'avec un nom de domaine contenant BOOL on peut "simuler" un booléen

Alors, j'ai résolu le problème en utilisant une requête dans le ReadSQL de TFDBatchMoveSQLReader1.

marrant, j'ai fait un test très rapide mais j'ai modifié un SQLWriter , en gros j'y ai mis un INSERT INTO (tous les champs sauf l'auto-généré) VALUES(...)
le seul truc qui me gêne comment ça se comporte avec les blobs ?
tu pouvais aussi faire la table Firebird sans clé, puis faire une procédure ou execute block pour créé et remplir ensuite la "clé"

[Papy214]

tu pouvais aussi faire la table Firebird sans clé, puis faire une procédure ou execute block pour créé et remplir ensuite la "clé"

J'avoue que l'idée ne m'a pas traversé. J'aurais pu vu que j'ai 2 scripts, 1 qui crée les structures de tables et les index, et un second qui ajoute les clés primaires et les trigger. C'est pourtant un très bonne idée.

Tu parles d'un insert into dans le SQLWriter. Je ne suis pas habitué à ce composant et je pensais qu'il fallait seulement un ensemble de données et non une commande dml.

[Papy214]

Je viens de trouver ça dans l'aide du writer:

Facultativement, définissez GeneratorName pour fournir un nom de générateur/séquence de base de données afin de renseigner les champs auto-incrémentés.

Il faudra que je teste ça. Si ça se trouve ça réglerait le problème

[SergioMaster]

GeneratorName : Il faudra que je teste ça. Si ça se trouve ça réglerait le problème

j'ai pas testé mais utiliser GeneratorName + un Trigger ç afait en général pas bon ménage (de 2 en 2 au lieu de 1 en 1)