Discussion :

[_alx_]

Je développe actuellement un logiciel (Delphi Alexandria) qui doit remplir une table Firebird à partir de fichiers CSV lus depuis un serveur REST.
J'ai pensé à utiliser un composant FDBatchMove pour effectuer facilement la conversion avec les "reader" et "writer" qui vont bien.
Comme le résultat n'était pas satisfaisant (seule la première colonne de données était transférée), j'ai simplifié le problème en écrivant le petit test suivant qui lit un CSV et en fabrique un autre, juste en changeant les séparateurs :

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
25
26
27
28
29
30
31
procedure TForm16.FormCreate(Sender: TObject);
var fTest: TFileStream; fCopy: TMemoryStream;
begin
  fTest := TFileStream.Create(ExtractFilePath(Application.ExeName) + 'test.txt', fmOpenRead);
  Original.Lines.LoadFromStream(fTest);
  fCopy := TMemoryStream.Create;
  try
    FDBatchMove.Mode := dmAlwaysInsert;
    with TFDBatchMoveTextReader.Create(FDBatchMove) do begin
     Stream := fTest;
      DataDef.Separator := ',';
      DataDef.Delimiter := ',';
      DataDef.WithFieldNames := true;
    end;
    with TFDBatchMoveTextWriter.Create(FDBatchMove) do begin
      Stream := fCopy;
      DataDef.Separator := ';';
      DataDef.Delimiter := '/';
      DataDef.WithFieldNames := false;
    end;
    FDBatchMove.GuessFormat();
    FDBatchMove.Execute;
    fCopy.Position := 0;
    Copy.Lines.LoadFromStream(fCopy);
  finally
    fTest.Free;
    fCopy.Free;
  end;
  with FDBatchMove do StatusBar.SimpleText := 'Read: ' + IntToStr(ReadCount)
    + '   Inserted: ' + IntToStr(InsertCount) + '   Written: ' + IntToStr(WriteCount);
end;

Pour le fichier initial suivant (stream fTest):

nom,date,ville
Dupont,2000-01-01,Fouilly-les-Oies
Durand,2000-02-02,Lons-le-Saunier
Martin,2000-03-03,Paris

J'obtiens (stream fCopy):

/nom/;//;//
/Dupont/;//;//
/Durand/;//;//
/Martin/;//;//

Le format a bien été changé, mais seule la première colonne est renseignée et l'intitulé des champs semble ne pas avoir été compris.
Merci d'avance si vous pouvez m'aider à trouver mon erreur !

[tourlourou]

Bonjour,
Le 1er séparateur semble OK puisqu'il reconnaît 3 champs.
Mais avoir fixé le délimiteur à la même valeur ( ',' ) alors qu'il n'y en a pas semble le perturber !

[_alx_]

Bonjour,
Le 1er séparateur semble OK puisqu'il reconnaît 3 champs.
Mais avoir fixé le délimiteur à la même valeur ( ',' ) alors qu'il n'y en a pas semble le perturber !

Merci, mais malheureusement ce n'est pas cela, car l'erreur (de frappe) avait déjà été corrigée et ne change pas le résultat.
Dans les données originales, il y a en effet un délimiteur ("), en principe à spécifier, mais il n'y en a pas dans les données du test.

[SergioMaster]

Bonjour,

le delimiter du TFDBatchMoveTextReader me parait étrange.

Je me suis amusé à le faire au runtime en posant les composants et j'obtiens
"Dupont";01/01/2000;"Fouilly-les-Oies"
"Durand";02/02/2000;"Lons-le-Saunier"
"Martin";03/03/2000;"Paris"
à remarquer que guessformat change de format des dates

[_alx_]

Bonjour,

le delimiter du TFDBatchMoveTextReader me parait étrange.

Je me suis amusé à le faire au runtime en posant les composants et j'obtiens
"Dupont";01/01/2000;"Fouilly-les-Oies"
"Durand";02/02/2000;"Lons-le-Saunier"
"Martin";03/03/2000;"Paris"
à remarquer que guessformat change de format des dates

Bonsoir,
Je suis étonné par votre résultat.
D'une part, parce que je n'arrive pas à le retrouver !
D'autrepart, parce que ça m'étonnerait que le GuessFormat cherche à reconnaître les types (en l'occurrence un TDate).
C'est le BatchMove qui va s'en occuper si la sortie est un DataSet ou s'il y a un Mapping défini ? Ici la sortie est du texte.

[SergioMaster]

Je suis étonné par votre résultat.

Et pourtant, je n'ai fait, comme d'habitude avec du Batchmove, une simple exécution au designtime
J'ai posé sur une fiche un FDBatchmove, un FDBatchmoveTextReader pointant sur le petit fichier CSV , un FDBatchmoveTextReader pointant sur un fichier à créer, j'ai tout laissé par défaut et utilisé le menu contextuel du fdbatchmove : fait un guessformat puis un execute.

Rien de plus

à remarquer que guessformat change de format des dates

je ne vois que cette instruction qui ait pu changer le format de la date de yyyy-mm-dd à dd/mm/yyyy

[_alx_]

Et pourtant, je n'ai fait, comme d'habitude avec du Batchmove, une simple exécution au designtime
J'ai posé sur une fiche un FDBatchmove, un FDBatchmoveTextReader pointant sur le petit fichier CSV , un FDBatchmoveTextReader pointant sur un fichier à créer, j'ai tout laissé par défaut et utilisé le menu contextuel du fdbatchmove : fait un guessformat puis un execute.

Rien de plus


je ne vois que cette instruction qui ait pu changer le format de la date de yyyy-mm-dd à dd/mm/yyyy

J'ai fait exactement la même chose, mais j'obtiens l'erreur "correspondance non définie entre les champs source et destination", qui est cohérente avec le comportement que j'observe de mon côté. Rien ne change si j'ajoute l'option de "mappage".
D'autre part votre changement de format de date me semble louche, puisqu'il ne devrait pas avoir lieu entre de simples chaînes de texte. J'ai aussi remarqué que le comportement du BatchMove était différent (au runtime) suivant que le texte provenait d'un fichier ou d'un composant memo pre-rempli (après avoir ajouté des caractères non-Ansi).
Je pense qu'il y a une interaction avec le ''Formatsettings" qui est utilisateur-dépendant et avec l'encodage par défaut.

Pour aller un peu plus loin, j'ai traqué (au debugger) le fonctionnement du "guessformat" : si on ne paramètre rien, le choix possible de séparateur est restreint et le délimiteur par exemple est forcé à ". Au delà, au cours de l'analyse (AnalyseSample = 10), l'option "WithFieldNames=true" est forcée à "false", ce qui explique aussi ce que je trouve.

Tout cela n'est pas clair et je me demande si nous utilisons tous les deux le même logiciel ? Pour moi c'est Delphi Alexandria à jour, et Firedac 28.0.42600.6491.
La documentation en ligne (Wiki, etc...) est insuffisante, c'est pour cela que je me suis permis de lancer cette discussion.
Merci d'avance pour votre perspicacité.

[SergioMaster]

Je pense que la seule chose qui puisse différer est mon habitude de créer des applications FMX plutôt que VCL
sinon, aucun mappings de déclaré


PS. une chose que je n'avais pas indiqué, j'ai coché le withfieldnames pour le reader (sinon ça plante)

[_alx_]

Je pense que la seule chose qui puisse différer est mon habitude de créer des applications FMX plutôt que VCL
sinon, aucun mappings de déclaré

PS. une chose que je n'avais pas indiqué, j'ai coché le withfieldnames pour le reader (sinon ça plante)

Merci, je n'avais pas pensé à une différence VCL/FMX.
Hélas, un essai FMX en design (à la Sergiomaster !) donne chez moi le même résultat qu'en VCL.
Chose curieuse, qui confirmerait mon "debuggage": après avoir coché le "withfieldnames" dans l'inspecteur d'objet (champ Reader.DataDef du FDBatchMove), puis exécution du GuessFormat (en design, et sans exécution du Execute), la case se trouve décochée au bout d'une fraction de seconde ...
Je serais curieux de connaître le résultat de la même manipe chez vous.

[Andnotor]

Le format date de sortie est défini au niveau du Writer et est par défaut le format du système, idem pour le Reader. Sergio, le format ne change pas tout seul

Ensuite il y a une incompréhension au niveau de GuessFormat. Cette méthode va écrasé les réglages du Reader en fonction du paramètre qu'on lui passe :

• taDelimSep agit sur Separator et Delimiter ;
• taHeader sur WithFieldsNames ;
• taFields sur Fields ;
• taFormatSet sur FormatSettings.

_alx_, définir manuellement Separator, Delimiter et WithFieldNames n'a aucun intérêt si tu appelles GuessFormat avec le paramètre par défaut qui est [taDelimSep, taHeader, taFields].
Et si Analyze est renseigné (non vide), il est même inutile d'appeler cette méthode manuellement puisque Execute va le faire de toute façon et écraser le résultat de ton propre appel.

Cette analyse n'est cependant pas infaillible et passer par GuessFormat est obligatoire si certains champs doivent être ajustés après coup. Elle aura par exemple déterminé une chaîne de 20 caractères d'après l'échantillon testé (AnalyzeSample) alors qu'il en faut 50.

En bref et à moins d'un csv vraiment mal foutu, le code se résume à :

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
begin
  var BatchMove := TFDBatchMove.Create(nil);
  var Reader    := TFDBatchMoveTextReader.Create(BatchMove);
  var Writer    := TFDBatchMoveTextWriter.Create(BatchMove);
 
  try
    Reader.FileName := 'd:\in.csv';
    Writer.FileName := 'd:\out.csv';
    Writer.DataDef.Separator := ';';
    Writer.DataDef.Delimiter := '/';
 
    BatchMove.Analyze := [taDelimSep, taHeader, taFields, taFormatSet];
    // ou
    // BatchMove.GuessFormat([taDelimSep, taHeader, taFields, taFormatSet]);
 
    BatchMove.Execute;
  finally
    BatchMove.Free;
  end;
end;

Après bien sûr il faudra jouer sur le Mappings pour remplir une base de données si les noms des champs ne correspondent pas.

[_alx_]

Le format date de sortie est défini au niveau du Writer et est par défaut le format du système, idem pour le Reader. Sergio, le format ne change pas tout seul

Ensuite il y a une incompréhension au niveau de GuessFormat. Cette méthode va écrasé les réglages du Reader en fonction du paramètre qu'on lui passe :

• taDelimSep agit sur Separator et Delimiter ;
• taHeader sur WithFieldsNames ;
• taFields sur Fields ;
• taFormatSet sur FormatSettings.

_alx_, définir manuellement Separator, Delimiter et WithFieldNames n'a aucun intérêt si tu appelles GuessFormat avec le paramètre par défaut qui est [taDelimSep, taHeader, taFields].
Et si Analyze est renseigné (non vide), il est même inutile d'appeler cette méthode manuellement puisque Execute va le faire de toute façon et écraser le résultat de ton propre appel.

Cette analyse n'est cependant pas infaillible et passer par GuessFormat est obligatoire si certains champs doivent être ajustés après coup. Elle aura par exemple déterminé une chaîne de 20 caractères d'après l'échantillon testé (AnalyzeSample) alors qu'il en faut 50.

Après bien sûr il faudra jouer sur le Mappings pour remplir une base de données si les noms des champs ne correspondent pas.

Merci Andnotor.
Cela confirme ce que j'avais déduit de mes investigations: GuessFormat est une facilité trompeuse et Analyze peut conduire à un résultat déconcertant.
Néanmoins, le code suivant, qui est juste le tien mis dans un projet FMX, donne toujours chez moi l'erreur 617, ce qui laisse entendre que la structure du CSV est mal décodée.


*************** Démarrer le journal 15/12/2021 13:37:20 ***************
[FireDAC][Comp][DM]-617. Correspondance non définie entre les champs source et destination
*************** Fin du journal 15/12/2021 13:37:20 ***************

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
25
26
27
28
29
const
  csvIn = 'test.txt';
(* contenu du csv de test :
  nom,date,ville
  Dupont,2000-jan-01,Fouilly-les-Oies
  Durand,"2000-fév-02",Lons-le-Saunier
  Martin,2000-mar-03,Paris
*)
  csvOut =  'Data.txt';
 
procedure TForm19.FormCreate(Sender: TObject);
begin
  var BatchMove := TFDBatchMove.Create(nil);
  var Reader    := TFDBatchMoveTextReader.Create(BatchMove);
  var Writer    := TFDBatchMoveTextWriter.Create(BatchMove);
 
  try
    Reader.FileName := csvIn;
    Writer.FileName := csvOut;
    Writer.DataDef.Separator := ';';
    Writer.DataDef.Delimiter := '/';
 
    BatchMove.Analyze := [taDelimSep, taHeader, taFields, taFormatSet];
 
    BatchMove.Execute;
  finally
    BatchMove.Free;
  end;
end;

[_alx_]

En regardant plus avant le code de Firedac, je crois que j'ai compris ce qui se passe, et pourquoi SergioMaster obtient un résultat différent du mien.

Andnotor a raison en disant que GuessFormat et la propriété Analyze remplie peuvent être appelés indifféremment: il suffit pour s'en convaincre de regarder le code de la procedure TFDBatchMoveTextReader.Open de l'unité Firedac.comp.BatchMove.Text.

Mais on voit aussi (ligne 1406&ff de la procedure GuessFormat de l'unité en question):

Code :

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

1
2
3
4
5
6
7
8
9
// When next AnalyzeSample lines contain only atString values, then
// probably first line contains also string values and not field names
    if lFieldNames then begin
       {...}
       {ici, code pour valider ou non l'hypothèse ci-dessus => lAllStrings = true / false}
       {...}
    end;
// Final guess about first line
    DataDef.WithFieldNames := lFieldNames and (not lAllStrings or lFieldNamesUC);

qu'un csv constitué uniquement de texte n'aura aucune chance de voir sa description de champ décodée correctement, puisque le code de validation cherche des chaînes (nombres décimaux, représentation de dates, etc...) qui contiennent les caractères spéciaux ('.', '/', etc...) mentionnés dans le FormatSettings du système.
Très vraisemblablement, la machine de SergioMaster est configurée avec un format contenant le '-' comme élément de codage (existant dans l'exemple que j'ai donné), d'où l'identification correcte de la 1ère ligne des 4 lignes, la sortie des trois lignes de données et la conversion de la date.

Je me demande même comment tout ça peut fonctionner sur Android ou Ios.

Si vous êtes d'accord avec ma conclusion, je marque la discussion comme résolue.

[Andnotor]

D'où proviennent ces csv, les formats date entre tes deux exemples ne correspondent pas ?

Pour que l'analyse réussisse sur le deuxième exemple il faudrait modifier les ShortMonthNames (janv. => jan, févr. => fév, etc.) et définir ShortDateFormat := 'yyyy/mmm/dd' mais je ne vois aucune méthode permettant cela au niveau du Reader. Perso je n'ai pas les sources Firedac...

Cela dit si tu ne veux que du texte, pourquoi lancer une analyse ? A mon sens elle est plutôt utile pour gérer des csv de sources différentes en utilisant toujours le même reader et évidemment en préservant les types.

[SergioMaster]

D'où proviennent ces csv, les formats date entre tes deux exemples ne correspondent pas ?

j'ai, moi aussi, vu cette différence avec celui du premier post

Très vraisemblablement, la machine de SergioMaster est configurée avec un format contenant le '-' comme élément de codage (existant dans l'exemple que j'ai donné), d'où l'identification correcte de la 1ère ligne des 4 lignes, la sortie des trois lignes de données et la conversion de la date.

ben non, rien de spécial de défini à ma connaissance à part peut-être que j'ai la possibilité de changer le clavier FRA/ENG

Si vous êtes d'accord avec ma conclusion, je marque la discussion comme résolue.

D'accord avec la conclusion non pas vraiment mais cela n'empêche pas de mettre en résolu

[_alx_]

D'où proviennent ces csv, les formats date entre tes deux exemples ne correspondent pas ?

Pour que l'analyse réussisse sur le deuxième exemple il faudrait modifier les ShortMonthNames (janv. => jan, févr. => fév, etc.) et définir ShortDateFormat := 'yyyy/mmm/dd' mais je ne vois aucune méthode permettant cela au niveau du Reader. Perso je n'ai pas les sources Firedac...

Cela dit si tu ne veux que du texte, pourquoi lancer une analyse ? A mon sens elle est plutôt utile pour gérer des csv de sources différentes en utilisant toujours le même reader et évidemment en préservant les types.

L'exemple donné était juste un test modifié pour voir l'effet des délimiteurs et des accents.

Les "vrais" csv sont des listes de mots ou groupes de mots (donc des chaînes de caractères sans interprétation) rangés par colonnes dont l'ordre et le nombre sont inconnus d'une interrogation à l'autre (d'où l'importance d'un traitement correct de la 1ère ligne).
Je pensais qu'un FDBatchMove pouvait insérer automatiquement ce type de données dans une table d'un SBGD (pourvu des procédures stockées adéquates pour les dispatcher au niveau du serveur).
Comme le FDBatchMove oblige à une analyse du Reader et que celle-ci semble ne pas fonctionner dans ce cas, je vais utiliser une autre solution.

Merci en tous cas des aides apportées, qui m'ont été très utiles.