Discussion :

[essence-ciel]

Bonjour,
Environnement Windows 8/10, SQLite 32 bits, Radstudio 10.3.3

J'ai paramétré une relation maître/détail entre un fichier maître : Produits et un fichier détail: AutreNoms. Les 2 fichiers possèdent une clé commune NumM.

Je parcoure la table avec un DBGRid et je souhaite récupérer le nom latin (AutreNoms.NomLatin) de la plante via une relation Maître/Détail entre les deux tables via un DBEdit.

Le FDTable.
MasterSource pointe sur Produits (indexé sur sa PK Nom Unique Not Null)
MasterField pointe sur Produits.NumM (commun aux deux fichiers)
IndexField pointe sur AutreNoms.NumM (fichier AutreNoms NumM)
DetailField pointe sur AutreNoms.NumM

Pour le FDTable.Active, point de problème et les champs sont bien inscrits dans l'éditeur de champs.

Lors du test avec l'éditeur de requête, j'obtiens le résultat souhaité mais pas en dynamique (CTRL-F9) car les noms bouclent sur les 2 premières lignes indépendamment du Produit.Nom... or NumM est unique dans la table Produits.

J'ai paramétré les FetchOptions de FireDac (conformément aux suggestions de Cary Jensen Delphi In Depth : FireDac), notamment les DetailCascade, DetailDelay et autre DetailOptimize, résultat sans changement. J'ai testé avec un FDQuery tout en rencontrant les mêmes soucis et le FDConnection est testé "Connection établie"...

J'ai testé avec un Id_Produits PK UNIQUE UNIQUE NOT NULL AUTOINCREMENT, même problème...

Suggestions bienvenues.

Bonne fin de journée, cordialement,

[SergioMaster]

Bonjour au caillou,

Perso, je n'ai jamais utilisé la fonctionnalité maitre-détail de Firedac, même si j'aime les nouveautés celle-ci ne fait pas partie de mes choix de pistes à suivre.
J'utiliserai donc plutôt une requête avec jointure à la place d'une table avec détail

Code SQL :

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

Select <Listes des colonnes nécessaires de p>,a.NOMLATIN from Produits p left join AutresNoms a where p.NumM=a.NumM

[essence-ciel]

Bonsoir SergioMaster,
Ici, c'est l'heure qui va bien, à ta santé...

J'ai testé avec un FDQuery, même problème... pourtant les tests tant sous RadStudio que sous SQLiteStudio fonctionnent...

[essence-ciel]

De plus, l'affichage du nom latin n'est qu'un des affichage de la page, j'en ai un bonne quarantaine d'autres... et c'est assez fantaisiste.

[SergioMaster]

Bonjour, pour moi c'est le matin

les tests tant sous RadStudio que sous SQLiteStudio fonctionnent...

Donc si la requête est bonne ...

avec un FDQuery, même problème...

là je ne comprends pas, une grille ou un TDBEdit ou plusieurs ne peuvent qu'afficher les données obtenues

De plus, l'affichage du nom latin n'est qu'un des affichage de la page, j'en ai un bonne quarantaine d'autres... et c'est assez fantaisiste.

A force de faire des essais une erreur de datasource ?

[essence-ciel]

A priori non, mes DataSources pointent bien chacun sur leurs tables respectives. Certes, une bonne trentaine pointent sur la table Produits mais normalement, cela ne pose pas de souci.

J'ai fait une requête style

Code sql :

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

1
2
3
4
SELECT COUNT(*) AS DOUBLON, NUMM, NOMLATIN, AUTRENOM, CHINOIS, AYURVEDA
FROM AUTRENOMS
GROUP BY NOMLATIN
HAVING COUNT(*) > 1

sur chacune des tables pour trouver des doublons, tout est propre.

Tous les index sont UNIQUE et incluent tous l'ID_ de leur table pour en préserver l'unicité.

Je me pose la question d'une erreur logicielle car ce n'est pas la seule table avec laquelle je rencontre des soucis... ce qui me fait dire cela, ce sont les clignotements intempestifs du RadStudio à l'occasion de la sélection d'un onglet, d'une méthode ou d'une propriété.

[essence-ciel]

Parti trop vite...

Ce sont les FDTables.MasterSource qui pointent sur Produits...

[SergioMaster]

Du coup je suis totalement dans le brouillard (ce qui n'est pas le cas si je regarde par la fenêtre)

tu peux me fournir les propriétés des deux FDtables ? (un extrait du DFM par exemple)

i.e voici une relation maitre-detail entre l'entete d'une expédition et ses lignes

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
 
  object FDTableMaster: TFDTable
    Active = True
    AfterOpen = FDTableMasterAfterOpen
    BeforeClose = FDTableMasterBeforeClose
    IndexFieldNames = 'NUMERO'
    Connection = FDConnection1
    UpdateOptions.UpdateTableName = 'EXPEDITION_ENTETE'
    TableName = 'EXPEDITION_ENTETE'
    Left = 160
    Top = 48
  end
  object DataSource1: TDataSource
    DataSet = FDTableMaster
    Left = 240
    Top = 48
  end
  object FDTableDetail: TFDTable
    Active = True
    IndexFieldNames = 'NUMERO;LIGNE'
    MasterSource = DataSource1
    MasterFields = 'NUMERO'
    Connection = FDConnection1
    UpdateOptions.UpdateTableName = 'EXPEDITION_LIGNES'
    TableName = 'EXPEDITION_LIGNES'
    Left = 312
    Top = 48
  end

[essence-ciel]

Bonjour SergioMaster,

Si tu n'as pas de brouillard, viens ici ! Avec les forces de l'ordre qui pourchassent les canaques qui bloquent, pillent et incendient la ville (cela ne sera pas dit à Radio ou à TV PenséeUnique style BFM-WC ou TF-Daube), l'atmosphère est électrique et l'air a des relents de (2)-chlorobenzylidène-malonitrile (ou CS) et de chloro-acétophénone (petit nom Cr) et je ne te dis pas comment cela pique les yeux (et ne me dit pas que c'est toujours comme ça la première fois !). Les gaz dacryogènes (et non pas lacrymogènes... pour respecter les racines grecques, ceci dit on pleure quand même...) ont envahi la ville et impossible d'aller bosser... la ville est bloquée, les institutions et les commerces sont bloqués, le port est bloqué, l'aéroport est bloqué... à 3 semaines de noël, c'est le pied quoi...
Mais on a quand même cocotiers, mer turquoise, ciel bleu et soleil radieux avec un petit 32° à l'ombre et un léger alizé de S-SE mais on n'est pas obligés de rester à l'ombre, heureusement...

Revenons à nos moutons, voici le DFM du DBEdit :

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
    object DBEdit1: TDBEdit
        Left = 75
        Top = 5
        Width = 470
        Height = 21
        DataField = 'NOMLATIN'
        DataSource = DataModule2.DAutreNoms
        Font.Charset = DEFAULT_CHARSET
        Font.Color = clWindowText
        Font.Height = -11
        Font.Name = 'MS Sans Serif'
        Font.Style = [fsBold, fsItalic]
        ParentFont = False
        TabOrder = 0
      end

et celui du DataModule :

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
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
object QAutreNoms: TFDQuery
    Active = True
    IndexFieldNames = 'NUMM'
    MasterSource = DProduits
    MasterFields = 'NUMM'
    DetailFields = 'NUMM'
    Connection = WConnex
    SQL.Strings = (      
        'SELECT p.nom, p.numm, a.numm, a.nomlatin, a.autrenom, a.chinois,' ' a.ayurveda'
      'FROM autrenoms a'
      'LEFT JOIN produits p ON a.numm=p.numm')
    Left = 1080
    Top = 275
    object QAutreNomsNOM: TStringField
      FieldName = 'NOM'
      Origin = 'NOM'
      ProviderFlags = [pfInUpdate, pfInWhere, pfInKey]
      Required = True
      Size = 75
    end
    object QAutreNomsNUMM: TIntegerField
      FieldName = 'NUMM'
      Origin = 'NUMM'
      Required = True
    end
    object QAutreNomsNUMM_1: TIntegerField
      FieldName = 'NUMM_1'
      Origin = 'NUMM'
      Required = True
    end
    object QAutreNomsNOMLATIN: TStringField
      FieldName = 'NOMLATIN'
      Origin = 'NOMLATIN'
      Required = True
      Size = 75
    end
    object QAutreNomsAUTRENOM: TStringField
      FieldName = 'AUTRENOM'
      Origin = 'AUTRENOM'
      Required = True
      Size = 75
    end
    object QAutreNomsCHINOIS: TStringField
      FieldName = 'CHINOIS'
      Origin = 'CHINOIS'
      Required = True
      Size = 75
    end
    object QAutreNomsAYURVEDA: TStringField
      FieldName = 'AYURVEDA'
      Origin = 'AYURVEDA'
      Required = True
      Size = 75
    end
  end
end

Pour une fois que j'ai inclus les deux "NUMM" dans le SELECT et non pas fais un SELECT * (cela m'apprendra à faire du zèle) voici le résultat :


ce qui m'étonne, c'est que les colonnes NUMM et NUMM-1 ne reprennent pas le numéro NUMM intégral d'origine mais seulement un seul caractère d'icelui. Ceci expliquerait-il cela... มันไม่ได้เป็น ? (prononcer -man /maï \daï -pen, avec les intonations). En Thaï (c'est ma 5° langue) : n'est-il pas ?

J'avoue ne pas voir d'autre explication à ces errements, mais question, pourquoi l'éditeur de requête n'affiche-t-il que le premier chiffre de la colonne NUMM et non pas la totalité ?

De mon côté, je me penche sur une différenciation et une déclinaison des NUMM en fonction du fichier d'origine pour voir si cela provient de cette homonymie qui ne me posait pas de problème sous Paradox/BDE.

CDLT,

[SergioMaster]

Bonjour,

C'est vrai que l'on n'est pas au courant de ces évènements, le caillou est aux antipodes (ou peu s'en faut), rien n'a filtré sauf, peut-être la météo. D'ailleurs de cette dernière, je suis jaloux, elle ressemble trop à celle de mes années vénézuelliennes. Le froid humide accompagné d'une pression faible n'est pas vraiment bon pour ma pathologie.

Maintenant, cet objet

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
object QAutreNoms: TFDQuery
    Active = True
    IndexFieldNames = 'NUMM'
    MasterSource = DProduits
    MasterFields = 'NUMM'
    DetailFields = 'NUMM'
    Connection = WConnex
    SQL.Strings = (      
        'SELECT p.nom, p.numm, a.numm, a.nomlatin, a.autrenom, a.chinois,' ' a.ayurveda'
      'FROM autrenoms a'
      'LEFT JOIN produits p ON a.numm=p.numm')
    Left = 1080
    Top = 275

si tu veux en faire une relation maitre-détail il y a un problème, il manque un paramètre

Code SQL :

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

1
2
3
4
5
 
SELECT p.nom, p.numm, a.numm, a.nomlatin, a.autrenom, a.chinois,a.ayurveda
FROM autrenoms a
LEFT JOIN produits p ON a.numm=p.numm
WHERE a.Numm=:numm

j'aurais d'ailleurs eu tendance à ne faire que

Code SQL :

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

SELECT a.nomlatin, a.autrenom, a.chinois,a.ayurveda  FROM autrenoms a where a.NUMM=:NUMM

Je pense donc que ton problème
pour reprendre mon exemple sur les expéditions (qui ne produit rien de "bizarre") cela donnerait dans le dfm

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
32
33
34
35
  object FDTable1: TFDTable
    AfterOpen = FDTable1AfterOpen
    BeforeClose = FDTable1BeforeClose
    IndexFieldNames = 'NUMERO'
    Connection = FDConnection1
    UpdateOptions.UpdateTableName = 'EXPEDITION_ENTETE'
    TableName = 'EXPEDITION_ENTETE'
    Left = 160
    Top = 48
  end
  object DataSource1: TDataSource
    DataSet = FDTable1
    Left = 240
    Top = 48
  end
  object FDQuery1: TFDQuery
    MasterSource = DataSource1
    MasterFields = 'NUMERO'
    DetailFields = 'NUMERO'
    Connection = FDConnection1
    FetchOptions.AssignedValues = [evCache]
    FetchOptions.Cache = [fiBlobs, fiMeta]
    SQL.Strings = (
      'SELECT * FROM EXPEDITION_LIGNES '
      'WHERE NUMERO=:NUMERO')
    Left = 312
    Top = 48
    ParamData = <
      item
        Name = 'NUMERO'
        DataType = ftInteger
        ParamType = ptInput
        Value = 20280006             // ça c'est juste au design ;)
      end>
  end

Je pense donc que ton problème vient uniquement de ce paramètre manquant

[essence-ciel]

Bonjour SergioMaster,
A 6h30, nous n'avons que 25°, avalanche de ciel bleu et alizés 0... C'est pour fuir froid et grisaille que j'ai installé mon cabinet de soin à Nouméa. Pour la proximité de la Thaïlande aussi, nous y allons aussi souvent que possible...

Si je t'ai bien compris, le simple ON A.NUMM=P.NUMM ne suffit pas à assurer complètement la liaison, il convient de rajouter la clause Where. Je ne saisis pas toute la logique du SQL, certainement parce que je cherche à construire ce que je veux obtenir au lieu de l'indiquer au SGBD.

Ceci étant, utilisant un FDTAble, la liaison ne se fait pas non plus. Pourtant :
- NomTable remplace l'instruction SQL, quelle qu'elle soit et,
- dans les deux cas le mastersource, le masterfield et le detailfield doivent être renseignés.

Donc, la logique est la même, ce n'est que la façon d'accéder à l'information qui diffère...

Encore merci pour ta réponse, je me replonge dans les subtilités du FireDAc.

[essence-ciel]

Re-SergioMaster,

Comme indiqué dans mon post précédent, j'ai testé...

Sqlite avec clause WHERE :
Pièce jointe 586097

SQLite sans clause WHERE :
Pièce jointe 586096

Même chose avec l'éditeur de requête avec clause WHERE :
Pièce jointe 586098

Et éditeur de requête sans clause WHERE :
Pièce jointe 586099

Si dans SQLiteStudio, les numéros apparaissent bien, avec ou sans clause WHERE, dans l'éditeur de requête, ils n'apparaissent pas... ce sont pourtant la même base de données et les mêmes fichiers et les mêmes requêtes... Cela reste une énigme pour moi...

Autre bizarrerie...


et



Où l'on s'aperçoit que la colonne NUMP avec l'éditeur de requête ne retiens que le premier chiffre...

Si tu as une idée...

[SergioMaster]

Bonjour ou plutôt bonsoir.

Je trouve bizarre que SQLStudio montre un séparateur de milliers

Comme j'avais toujours ta base j'ai revérifié et effectivement il me l'affiche. Étonné je suis donc allé vérifier la seconde table HEINDIC, elle aussi à des entiers mais pas de séparateur. Tiens donc y aurait-il quelque chose de pourri au royaume du Danemark cher à Hamlet ? Ou plus exactement dans les données !

un test rapide (après avoir supprimé relations et index dans la table HEINDIC)

Code SQL :

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

update produits set numm=cast(numm as integer) where num=1

me confirme que seule la partie millier est prise en compte dans ce code
j'aurais aussi pu écrire mais je n'y ai pensé qu'après le test d'essai de transformation

cela me rapelle beaucoup ton problème avec SQLite et le pourquoi tu n'arrivais pas à avoir de relation.

Une fois de plus GIGO s'applique, ce n'est ni Firedac, ni SQLite (enfin pas complètement) le coupable

une suggestion de correction tirée par les cheveux numm doit être compris entre 1 000 et 9 999

Code :

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

UPDATE produits set numm=CAST(substr(numm,1,1)||substr(numm,3,3) as INTEGER)

Il doit certainement y avoir plus "propre" mais je ne maitrise pas suffisament SQLite pour comprendre la subtilité de ce séparateur de millier dans une colonne sensée être un entier (à demander dans le forum ad hoc)

[essence-ciel]

Bonjour SergioMaster,

Un grand merci pour la suggestion et le code, cela provenait effectivement du format de NUMM et grâce à l'intégrité référentielle, tout a été mis à jour en une seule requête. Cela fonctionne aussi sous FireDac, la requête m'affiche bien le numéro et les noms latin, vernaculaire, chinois et ayurvédique. Malgré les difficultés, je ne regrette pas de passer au SQL même si Paradox offrait cette facilité, je trouve SQL beaucoup souple et surtout plus puissant, je dois juste changer de paradigme...

Je me replonge donc dans la finalisation de cette migration qui aura été plus que laborieuse. Pour l'heure, je m'intéresse, livre de Cary Jensen en main, aux Transaction et aux Update...

Tu as peut-être suivi les événements des jours derniers sur le Caillou, ici, c'est un peu l'état de siège et les exactions vont bon train... la répression policière aussi, il y a déjà 49 prévenus en GAV et une bonne dizaine de comparutions immédiates assorties de séjour au camp Est (la prison) en attendant le procès... les Caldoches ont fini de râler et sortent les fusils... cela me rappelle 1983 et les événements... Les fêtes du bout d'an vont être joyeuses...

Encore merci et bonne journée.

[SergioMaster]

Bonjour,

Malgré les difficultés, je ne regrette pas de passer au SQL même si Paradox offrait cette facilité, je trouve SQL beaucoup souple et surtout plus puissant, Paradox aussi supportait le SQL, basique certes mais c'était un début.
Je me replonge donc dans la finalisation de cette migration qui aura été plus que laborieuse.

le problème vient surtout de la façon dont les tables ont été remplies. FDBatchMove (mais aussi un autre utilitaire dont je n'ai plus le nom en tête) t'eut été d'une grande aide pour le faire.

Pour l'heure, je m'intéresse, livre de Cary Jensen en main, aux Transaction et aux Update...

pour du monoposte, les transactions ce n'est pas vraiment forcé (sauf grosses opérations) pour les Updates ...
Il faut surtout s'intéresser au Query et Update SQL associé.

Tu as peut-être suivi les événements des jours derniers sur le Caillou,

Ne sont qu'un petit entrefilet dans notre lorgnette sur le monde. Les antipodes sont loin (aux antipodes) des préoccupations de l'hexagone. Ce qui nous obnubile ad nauseam
: la Covid, la police (tiens on se rejoint)

Encore merci et bonne journée.

De rien, n'oublie pas le

[essence-ciel]

Bonjour SergioMaster,
Merci pour le tuyau sur les transactions. Je n'ai pas encore fini le livre de Cary Jensen, c'est très dense !
La BDD ne fait que 250000 lignes toutes tables confondues. Je comprends donc que je peux faire l'impasse sur les transactions, par contre que le UpDateSQL s'imposerait...

J'avoue que cela me laisse perplexe car à l'usage, comme indiqué dans le livre ci-dessus, FireDac réagit comme le BDE et l'emploi du UpDateSQL ne m'apparaît pas comme une nécessité. Ceci étant, je continue la lecture mais il faudra que je m'y replonge plusieurs fois avant de tout assimiler.

Cela dit, je profite de cela pour tester des requêtes diverses et variées dans SQLiteStudio et me penche sur les vues qui m'ont l'air particulièrement puissantes. Je pense en incorporer dans mon petit applicatif, au moins quand je n'ai que de la consultation à faire.

Encore merci pour les infos, je t'avoue que je galérais depuis quelques jours sans comprendre le comment du pourquoi.

Pour la situation ici, bilan 1 station service brûlée, des affrontements durant 2 jours entre indépendantistes "cannabissés" et alcoolisés à outrance et FDO, jets de pierre, tirs de fusil, ville sous lacrymogène, routes bloquées, contre-barrages des loyalistes et on a même vu des inconscients monter à l'assaut d'une usine SEVESO. Les FDO ont dû tirer à balles réelles... pour l'heure le calme est revenu mais le fossé se creuse un peu plus entre les 2 tendances politiques et se ressent au quotidien.

Ceci étant, cela ne nous empêchera pas, comme tous les ans, le 25 matin, d'aller se faire la plongée de Noël avec bonnet et houppelande du Père Noël à poste.

[SergioMaster]

Bonjour,

Ceci étant, cela ne nous empêchera pas, comme tous les ans, le 25 matin, d'aller se faire la plongée de Noël avec bonnet et houppelande du Père Noël à poste.

J'ai pu apprécier une fois un noël ou plutôt premier de l'an sous les cocotiers, mais j'avais évité la tenue rouge à l'époque Navidad au Vénézuela était une affaire très sériuse un mois de réjouissances et feux d'artifices suavages dans toute la ville. Je doute que cela soit encore le cas !

FireDac réagit comme le BDE

Je confirme, Firedac est un BDE like.

et l'emploi du UpDateSQL ne m'apparaît pas comme une nécessité.

UpdateSQL entre en jeu dès que tu utilises des requêtes en lieu et place des tables, d'ailleurs quand tu utilises un FDTable il y a en fait des clauses SQL implicites (et donc une sorte d'UPdateSQL caché)
d'où la bonne idée de vérifier les options comme updatewhereall, updatewherekey etc... (ce qui était déjà le cas avec BDE d'ailleurs). UpdateSQL est très pratique en cas de SQL avec jointures de tables.
Chose que je n'ai toujours pas tester par contre, la possibilité de mettre deux SQL dans un même Update.

Pour ce qui est de ce qui se passe sur le caillou, peu filtre. Ici nous avons la loi "sécurité" avec cohorte casseurs, gilets jaunes black blocks ; la Covid avec ses anti vax, ses restrictions qui bien évidemment ne plaisent pas; et même les futures présidentielles et ce ad nauseam. Voeux pour Noël si tous ces nombrilistes regardaient ce qui se passe ailleurs

P.S. je n'ai jamais été très chaud pour les vues ce ne sont que des SQL préparés, on y gagne un peu en temps d'exécution en client serveur sinon ...

[essence-ciel]

Bonjour SergioMaster,
A force d'avoir des message d'erreurs ([FireDAC][DApt]-400. Update command updated [0] instead of [1] record) pour la mise à jour de certaines tables, même si je n'ai des jointures (6) que dans les vues pour la consultation d'informations synthétiques (par exemple quelles plantes contiennent du 1.8-cinéole ou sont anti-infectieuses), j'ai inclus un UpDateSQL. Je me suis replongé dans le livre de Jensen pour essayer d'en comprendre les subtilités.

Nonobstant, mon applicatif est opérationnel à 80% et je peux l'utiliser au quotidien à mon cabinet de soin. Ne me restent plus à travailler que les statistiques et les éditions.

En ce qui concerne les troubles, tout cela provient de la vente d'une usine de nickel entre 2 groupes industriels. En fait des meneurs (chefs coutumiers et hommes politiques), qui ont créé une instance de concertation pour intervenir dans la vente de l'usine, ont été plus que grassement payés par le patron de l'usine du Nord (dont l'usine est endettée à hauteur de 1100 milliards de CFP, soit 9 milliards d'€) pour déstabiliser la province Sud (par le saccage d'une usine et par le blocage des mines) où se situent 2 usines d'extraction et de traitement de nickel. Mais les grouillots de base ont été manipulés par les coutumiers et les politiques sans recevoir le moindre franc... Plus de 50 sont en prison pour des peines allant de 4 à 18 mois fermes. Mais, l'île étant petite, tout se sait... et il est maintenant de notoriété publique que les meneurs avaient d'autres intérêts que ceux invoqués et surtout qu'ils ont perçu de grosses sommes. Cela va certainement se terminer comme pour Tjibaou, Yéwéné et Machoro, c'est à dire par une exécution, à moins que l'on revive Ouvéa 1988... Pour l'heure, tout est revenu au calme et la période est à la préparation des fêtes du bout d'an.

Je te remercie encore pour tes précieux conseils et te souhaite de joyeuses fêtes du bout d'an.