[XE Berlin] Migration de MySQL vers SQLite : copier les structures de tables

**der§en** · 26/02/2017, 10h09

Bonjour,

Je maîtrise la migration des données des tables de MySQL vers SQLite en utilisant l'excellent TFDBatchMove quand les structures des tables existent dans la base SQLITE, avec un TFDQuery de chaque côté.

Mon problème est que j'aurais voulu créer de toute piéce une base Sqlite et du coup, je me trouve devant la question de comment recréer les structures.

Avez-vous une idée ?

**der§en** · 26/02/2017, 10h12

J'ai bien fait une tentative avec TFDQuery.CopyDataset mais visiblement ce n'est pas la bonne approche…

Une idée ?

**SergioMaster** · 26/02/2017, 10h16

Bonjour,

sur d'autres SGBD, je me suis déjà posé la même question sans toutefois aller trop loin (faute de temps). La clé : métadonnées

**der§en** · 26/02/2017, 10h24

J'utilise déjà GetTableNames pour lister les tables, pour recréer les structures de tables je n'ai pas trouver de méthode exploitable hélas…

**SergioMaster** · 26/02/2017, 10h41

Si tu as déjà trouvé GetTableNames alors tu as aussi trouvé GetFieldNames
ensuite (théoriquement car j'en était rendu là) on peut obtenir les informations sur la colonne.
Solution SQL :
Reste (et quand je dit reste il y a du boulot

) à établir une correspondance type de champ de la source vers type de champ de la destination (dans une liste d'objets par exemple ?) et à partir de ça reconstruire la table
Solution Code :
AMHA, dans les sources de Firedac il y a déjà cette liste, une autre solution serait peut être de créer des tables vides puis d'utiliser la création de champs (j'utilise ce nom à dessein pour distinguer des colonnes SQL) et laisser Firedac gérer les équivalence de type. en fouillant du coté de FieldDefList coté source et FieldDefs.Add coté destination. Cela ne fera pas tout il y aura encore les index, les contraintes etc... mais c'est un début

**tourlourou** · 26/02/2017, 11h05

Dans les bases SQLite, on retrouve les requêtes créant les tables. Je ne connais pas MySQL et ne suis pas sûr que la même chose, bien pratique, existe.
Pour SQLite : https://sqlite.org/fileformat2.html au 2.6 :

The sqlite_master.sql column stores SQL text that describes the object. This SQL text is a CREATE TABLE, CREATE VIRTUAL TABLE, CREATE INDEX, CREATE VIEW, or CREATE TRIGGER statement that if evaluated against the database file when it is the main database of a database connection would recreate the object. The text is usually a copy of the original statement used to create the object but with normalizations applied so that the text conforms to the following rules:

**SergioMaster** · 26/02/2017, 11h21

@Tourlourou
Bonjour,
je pense que tu n'as pas saisi le besoin : On a une base Mysql et on veut transférer son contenu dans une base créée (ou pas d'ailleurs), mais totalement vide (pas de table).
L'objectif est donc de créer les tables et donc les colonnes de celle-ci à partir des éléments de la base MySQL. Le hic c'est que la syntaxe entre les deux SGBD n'étant pas ~~forcément~~ le même on court assez vite droit dans le mur en extrayant (avec un GUI quelconque) les métadonnées de la base source pour appliquer le script obtenu avec le SGBD cible. D'où le recours à Firedac et les métadonnées obtenues grâce à ces composants.

@der§en
j'ai retrouvé mes essais pour listé les colonnes via Firedac et un FDMetaInfoQuery (fdMetaInfoQuery.ObjectName:=<nom de la table>,fdMetaInfoQuery.metainfokind:=mkTableFields)

Code :

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

1
2
3
4
5
6
7
8
9
10
 
procedure TForm8.FDMetaInfoQuery1FilterRecord(DataSet: TDataSet;
  var Accept: Boolean);
var i : Integer;
    eAttr : TFDDataAttributes;
begin
i:=FDMetaInfoQuery1.FieldByName('COLUMN_ATTRIBUTES').asInteger;
eAttr:=TFDDataAttributes(Pointer(@i)^);
Accept:=not  (caCalculated in eattr);  // ne prend pas en compte les champs calculés 
end;