TADODataSet chps statiques / MySQL charset collation

**wstboss71** · 02/02/2010, 16h18

Bonjour,

J'ai un petit soucis que je ne sais toujours pas résoudre malgré pas mal d'essais et de recherches sur le Web.
J'ai dans mon appli (fait avec Delphi 2010) une dbgrid accédant à ma base MySQL grâce:
TADOConnection (drivers MySQL ODBC) -> TADODataSet -> TDataSetProvider -> TClientDataSet -> TDataSource
J'ai défini les champs en statique dans le TADODataSet et le TClientDataSet afin de pouvoir faire certains traitement dessus.
Tout marche bien quand je pointe sur ma base MySql défini pour fonctionner dans un environnement français (les tables ont un charset Latin1) mais quand je pointe sur une base tchéque (les tables ont un charset utf8 collate utf8_czech_ci). Dans ce dernier cas j'obtiens un beau message d'erreur:

Type inadéquat pour le champ 'code': attendu String actuel PWidechar.

Si je laisse les champs se géré dynamiquement, je n'ai pas le problème mais je ne peut plus faire certains traitements sur l'événement OnValidate de certains champs.

Quelqu'un aurait il une solution à me proposer ?

merci d'avance car là je tourne en rond !

**ShaiLeTroll** · 02/02/2010, 16h29

Tu peux affecter tes OnValidate à la volée

Code :

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

Query.FieldByName('Champ').OnValidate := Validator.ChampValidator;

Validator serait une classe qui regroupe tous les OnValidate ...

Essaye de lancer cette requête à la 1ere connexion, pour forcer le charset de la connexion qui est par défaut en latin1_swedish_ci et non en utf-8

Code :

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

SET collation_connection=latin1_swedish_ci

ou

Code :

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

SET collation_connection=utf8_czech_ci

**wstboss71** · 02/02/2010, 16h48

Merci ShaiLeTroll.

Pour les OnValidate, j'étais entrain d'y penser...mais je viens de me rendre compte que j'ai aussi des champs fkLookup dans ma liste de champs de mon ADODataSet...donc je ne peux pas les mettre en dynamique.

Je vais essayer d'exécuter la requête que tu m'indiqu pour forcer le charset de la connexion cependant je me pose des questions sur ce que cela peut impliquer...
Je test ça de suite...

**wstboss71** · 02/02/2010, 17h00

Après test les 2 requêtes SET ne changent rien du tout, l'une comme l'autre...

Comment faire pour laisser la création des champs en dynamique mais avec des champs de type fkLookup ?

C'est mal parti, non ?

J'ai regarder sur les champs du TClientDataSet la propiété Transliterate mais malgré quelle soit à True, il n'y a aucun effet...

merci

**ShaiLeTroll** · 02/02/2010, 18h17

es-tu obligé de passer par un TClientDataSet ?
ADO est bidirectionnel, normalement, tu n'en as pas besoin, surtout que cela nuit au performances des SELECT

**wstboss71** · 02/02/2010, 23h22

Même si je supprime le TClientDataSet, cela n'arrangera rien, puisque le problème intervient dans le TADODataSet. Et je suis passé par un TClientDataSet parce que j'avias des problème de mise à jour de la base en mode batchoptimistic.

**wstboss71** · 03/02/2010, 09h47

Ok, voilà une solution qui me semble répondre à mon problème, je sais pas si c'est la meilleur (à vous de me le dire) mais en tout cas, ça à l'air de fonctionner.
Je vais regarder le type de mon champs avec une première requête et je construit mon TField de mon ADODataSet à l'execution. Les autres champs qui ne sont pas concernés par le problème String / WideString sont créés dans le design.
Voici des exemples de mon code:

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
57
58
59
60
61
62
63
64
function TForm2.GetFieldType():TFieldType;
var
  DSet:     TADODataSet;
begin
  DSet:=TADODataSet.Create(Owner);
  DSet.Connection:=ADOConnection1;
  DSet.CommandText:='SELECT code FROM app_info LIMIT 1;';
  DSet.Open;
  RESULT:=DSet.FieldDefs.Items[0].DataType;
  DSet.Close;
end;
 
Procedure CreateTStringField(DSet: TADODataSet; FieldName: String);
var
  T: TStringField;
begin
  T := TStringField.Create(nil);
  T.FieldName := FieldName;
  T.Name := DSet.Name + T.FieldName;
  T.Index := DSet.FieldCount;
  T.DataSet := DSet;
  DSet.FieldDefs.UpDate;
end;
 
Procedure CreateTWideStringField(DSet: TADODataSet; FieldName: String);
var
  TW: TWideStringField;
begin
  TW := TWideStringField.Create(nil);
  TW.FieldName := FieldName;
  TW.Name := DSet.Name + TW.FieldName;
  TW.Index := DSet.FieldCount;
  TW.DataSet := DSet;
  DSet.FieldDefs.UpDate;
end;
 
procedure TForm2.Button1Click(Sender: TObject);
var
  FieldType:  TFieldType;
begin
  if ClientDataSet1.Active then ClientDataSet1.Close;
 
  FieldType:=GetFieldType();
 
  Case FieldType of
    ftString,ftFixedChar:CreateTStringField(ADODataSet1,'code');
    ftWideString,ftFixedWideChar:CreateTWideStringField(ADODataSet1,'code');
  End;
 
  ClientDataSet1.Open;
end;
 
procedure TForm2.FormDestroy(Sender: TObject);
var
  TC: TComponent;
begin
  if ClientDataSet1.Active then ClientDataSet1.Close;
 
  TC := FindComponent(ADODataSet1.Name + 'code');
  if not (TC = nil) then
  begin
    TC.Free;
  end;
end;

Il faut encore que je l'arrange un peu, mais le principe est posé. Qu'en pensez vous ? Y'a t'il plus simple ?

merci

**ShaiLeTroll** · 03/02/2010, 10h58

Euh, pour créer des champs tu te prends la tête !!!
tu as la méthode AddFieldDef qui fait ça très bien

**wstboss71** · 03/02/2010, 11h29

J'ai regardé AddFieldDef, c'est vrai que c'est plus simple mais comme la doc l'indique:

Remarque : AddFieldDef n'est valable que dans le contexte de la création de définitions de champ pour une table à créer avec un appel ultérieur à la méthode CreateTable ou CreateDataSet. Il ne peut pas être utilisé pour ajouter des champs à une table déjà existante.

donc dans ce cas il faudrait que je crée tous mes champs au runtime alors que je veux aussi pourvoir en créer dans le design (cf mes champs fkLookup).

**wstboss71** · 03/02/2010, 11h48

voici une version "améliorée" pour ceux que ça pourraient intéresser :

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
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
 
type
  RFieldDef=Record
    FieldName:    String;
    FieldType:    TFieldType;
    FieldSize:    Integer;
  end;
 
type
  AFieldDef=     Array of RFieldDef;
 
function TForm2.GetFieldType(sSelect:WideString):AFieldDef;
var
  DSet:           TADODataSet;
  MyAFieldDef:    AFieldDef;
  i:              Integer;
begin
  SetLength(MyAFieldDef,0);
  DSet:=TADODataSet.Create(Owner);
  DSet.Connection:=ADOConnection1;
  DSet.CommandText:=sSelect;
  DSet.Open;
 
  SetLength(MyAFieldDef,DSet.FieldCount);
  for i := 0 to DSet.FieldCount- 1 do
  begin
    MyAFieldDef[i].FieldName:=DSet.Fields.Fields[i].FieldName;
    MyAFieldDef[i].FieldType:=DSet.FieldDefs.Items[i].DataType;
    MyAFieldDef[i].FieldSize:=DSet.FieldDefs.Items[i].Size;
  end;
  DSet.Close;
 
  RESULT:=MyAFieldDef; {RESULT}
 
  SetLength(MyAFieldDef,0);
end;
 
procedure AddMyField2(DSet: TADODataSet; MyFieldDef: RFieldDef); overload;
var
  T: TStringField;
  TW: TWideStringField;
begin
  case MyFieldDef.FieldType of
    ftString, ftFixedChar:
      begin
        T :=TStringField.Create(nil);
        T.FieldName := MyFieldDef.FieldName;
        T.Size:=MyFieldDef.FieldSize;
        T.Name := DSet.Name + T.FieldName;
        T.Index := DSet.FieldCount;
        T.DataSet := DSet;
        DSet.FieldDefs.UpDate;
      end;
    ftWideString, ftFixedWideChar:
      begin
        TW := TWideStringField.Create(nil);
        TW.FieldName := MyFieldDef.FieldName;
        TW.Size:=MyFieldDef.FieldSize;
        TW.Name := DSet.Name + TW.FieldName;
        TW.Index := DSet.FieldCount;
        TW.DataSet := DSet;
        DSet.FieldDefs.UpDate;
      end;
  end;
end;
 
procedure AddMyField2(DSet: TADODataSet; CSet: TClientDataSet; MyFieldDef: RFieldDef); overload;
var
  T:    TStringField;
  TC:   TStringField;
  TW:   TWideStringField;
  TWC:  TWideStringField;
begin
  case MyFieldDef.FieldType of
    ftString, ftFixedChar:
      begin
        T:=TStringField.Create(nil);
        T.FieldName := MyFieldDef.FieldName;
        T.Size:=MyFieldDef.FieldSize;
        T.Name := DSet.Name + T.FieldName;
        T.Index := DSet.FieldCount;
        T.DataSet := DSet;
        DSet.FieldDefs.UpDate;
 
        TC:=TStringField.Create(nil);
        TC.FieldName := MyFieldDef.FieldName;
        TC.Size:=MyFieldDef.FieldSize;
        TC.Name := CSet.Name + TC.FieldName;
        TC.Index := CSet.FieldCount;
        TC.DataSet := CSet;
        CSet.FieldDefs.UpDate;
      end;
    ftWideString, ftFixedWideChar:
      begin
        TW:= TWideStringField.Create(nil);
        TW.FieldName := MyFieldDef.FieldName;
        TW.Size:=MyFieldDef.FieldSize;
        TW.Name := DSet.Name + TW.FieldName;
        TW.Index := DSet.FieldCount;
        TW.DataSet := DSet;
        DSet.FieldDefs.UpDate;
 
        TWC:= TWideStringField.Create(nil);
        TWC.FieldName := MyFieldDef.FieldName;
        TWC.Size:=MyFieldDef.FieldSize;
        TWC.Name := CSet.Name + TWC.FieldName;
        TWC.Index := CSet.FieldCount;
        TWC.DataSet := CSet;
        CSet.FieldDefs.UpDate;
      end;
  end;
end;
 
procedure TForm2.Button1Click(Sender: TObject);
var
  MyAFieldDef:    AFieldDef;
  i:              Integer;
begin
  if ClientDataSet1.Active then ClientDataSet1.Close;
 
  MyAFieldDef:=GetFieldType('SELECT code,val,description FROM app_info LIMIT 1;');
 
  for i:=0 to length(MyAFieldDef)- 1 do
  begin
    AddMyField2(ADODataSet1,ClientDataSet1,MyAFieldDef[i]);
  end;
  ClientDataSet1.Open;
end;

Si vous avez des commentaires, n'hésitez pas, ils sont les bienvenue.

**ShaiLeTroll** · 03/02/2010, 12h02

Euh, en fait tu veux faire quoi, tu sembles te prendre la tête !

**wstboss71** · 03/02/2010, 13h23

1. Le constat:

Avec un ADODataSet qui a tous les champs définis au moment du design et suivant le type de charset de la table de la base: je rencontre une erreur car le type attendue est un string et dans un cas j'ai bien un string (base FR) mais dans l'autre j'ai un WideString (base tcheque). Message d'erreur du genre:

Type inadequat pour le champs 'code': attendue String Actuel FixedWideChar

2. Solution 1:

Ne pas renseigner les champs au moment du design mais laisser le composant géré ça tout seul au run-time.
Pas possible car j'ai des champs de type fkLookup qui générent une combobox en fonction d'une autre table (clé étrangère).

3. Solution 2:

Utiliser l'instruction :

SET collation_connection=latin1_swedish_ci

au lancement du programme pour forcer la collation utilisée.
Ca ne marche pas.

4. Solution 3:

Mixer la création des champs:
Ceux qui ne posent pas de problème seront créés au moment du design car c'est plus simple de créer les champs de type fkLookup et les autres seront créés au run-time en fonction du type réel de champs renvoyé par la base.

Voilà c'est cette troisième solution que j'essaie de mettre en oeuvre car c'est celle qui marche. Après ma façon de la mettre en oeuvre n'est peut être par orthodoxe mais elle semble fonctionner. J'ai bien essayé avec le AddFieldDef mais ça ne marche pas s'il y a déjà des champs créés au moment du design.

J'espère que tu y vois plus clair...

**ShaiLeTroll** · 04/02/2010, 10h44

Abandonne les ftLookup, c'est de la m***e, fait une requête simple, et gère le ComboBox à la main, tu as des composants TMS qui sont très intelligent pour cela (tu peux afficher plusieurs colonnes, le champ clé est modifiable, gestion de lazyload...)

En plus cela permet d'avoir un code plus explicite, j'ai déjà du maintenir une application qui utilisait les méandres du TDataSet et TField sur Oracle, alors que j'ai une logique No-IDE dans mon dévelopement avec des couches d'abstraction objet, j'ai jamais vu un truc aussi peu explicite, il faut cliquer partout pour trouver les informations, alors qu'une bonne couche Buziness bien séparé des Vues permet de comprendre tout de suite le modèle et ses restrictions !

**wstboss71** · 04/02/2010, 13h17

J'aime bien les composants TMS, je m'en sert. Mais cependant il manque quelque chose que j'utilise à la TDBAdvGrid, elle ne gère pas le mode batch pour le traitement par lots des enregistrements.

Sinon qu'entends tu par gérer la ComboBox à la main ? Parce que si c'est l'afficher en surcharge d'un champs dans une DBGrid, je trouve ça pas vraiment pratique, d'autant plus que quand tu passes à une autre ligne, c'est la clé étrangère qui apparait dans le champs et plus vraiment la valeur que l'utilisateur devrait voir.

As tu un petit exemple sous la main ?

merci de ton aide.

**ShaiLeTroll** · 04/02/2010, 15h07

Je n'utilise jamais la DBGrid pour l'édition, pour modifier les valeurs, je préfère un joli formulaire accesible depuis la Grille ... c'est bien plus pratique pour les utilisateurs

Je n'ai pas d'exemple, une DBGrid, un DataSource et un panel contenant DBEdit, DBComboBox, ... (ceux de Delphi, Jedi ou TMS), avec un bouton Modifier\Valider qui balance le focus de la grille aux Edits et inversement, idem pour le Enabled, qui est changé selon Mode Edition \ Mode Browse ...

Sinon, il existe en standard la PickList dans le TColumn !

**wstboss71** · 10/02/2010, 11h14

Salut,

désolé de ne pas avoir répondu plus rapidement mais ce n'était pas possible.
la DBGrid fait partie du cahier des charges, je ne peux pas faire autrement.

Du coup je vais rester sur mon mixte entre champs définis au moment du design et champs définis au moment du runtime.

Merci de ton aide.

TADODataSet chps statiques / MySQL charset collation

Bases de données Delphi

Discussions similaires

Partager

Partager