RecNo : différence entre paradox et mysql ?
Re-bonjour,
Voilà que je me heurte à un truc bizarre.
Dans l'application que je suis en train de migrer, j'ai l'habitude de changer la couleur de fond de la dbgrid une ligne sur deux pour une meilleure lisibilité.
Le code est relativement simple :
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
procedure TForm3.DBGrid1DrawcolumnCell(Sender: TObject; const Rect: TRect;
DataCol: Integer; Column: TColumn; State: TGridDrawState);
begin
if odd(dbgrid1.datasource.dataset.RecNo) then
begin
if not (gdfocused in state) then
begin
dbgrid1.Canvas.Brush.color:=vertamande;
end;
end;
etc ... |
Donc, normalement quand RecNo est impair la ligne est sur fond vert, sinon c'est le fond normal.
Cela fait 20 ans que ça marche avec les tables paradox, mais lorsque j'essaye avec une base mysql, RecNo est toujours égal à 1 ....
Est ce que je n'utilise pas la bonne méthode ? Comment récupérer le numéro d'un enregistrement dans une base Mysql ?
Merci d'avance.
1 pièce(s) jointe(s)
quand il y a un os je le ronge
Bonjour,
Citation:
Envoyé par
navyg
Bon, je vais abandonner FDtable et tout faire en FDQuery
Même si c'est ce que je recommande ne serait-ce que pour utiliser la puissance des SGBD relationelles, cette bizarrerie me gênait.
Après avoir "dormi dessus", j'étais persuadé qu'il s'agissait d'un problème d'option (c'est vrai qu'avec Firedac c'est pas ce qui manque).
Au fil des versions plusieurs Fetchoptions par défaut ont changées. Pour ce qui est des récents, je ne me souviens que d'un article de Marco Cantu concernant les transactions Firebird (pas si rénet que ça) mais je me souviens aussi de mes galères du début et de mon échange avec Dmitry sur l'option LiveWindowParanoic naguère false par défaut et maintenant true.
En tatonnant un peu dans l'aide pas très claire au niveau des FetchOptions j'ai fini par identifier l'option "coupable" (ou du moins celle qui fait le job) : cursorkind
Pièce jointe 606792
:alerte: Ici j'ai modifié au niveau de FDTable et non directement de la connexion qui aurait tout aussi bien fait le job toutefois l'aide/docwiki, le paragraphe qui donne la piste sous le tableau
Citation:
Pour TFDTable, ckAutomatic active la fenêtre Données dynamiques, lorsqu'une table comporte des champs d'identification unique. ckDynamic active la fenêtre Données dynamiques sans condition, et une exception est déclenchée si une table de base de données ne comporte pas de clé unique. Les autres types de curseur désactivent le mode Fenêtre Données dynamiques et définissent TFDTable en mode standard, lorsqu'elle agit comme TFDQuery.
mais je ne sais pas si c'est une bonne idée que de la mettre au niveau connexion.
Du coup je me suis penché sur la structure de la table que j'ai utilisé. Avais-je un identifiant unique : OUI (que soit soit mon test Firebird ou MySQL) à noter que pour MySQL il s'agissait d'un auto incrément. Donc cela ctivait "la fenêtre Données dynamiques" FDTable n'était donc pas en mode standard maintenant que veux dire cette "fenêtre en mode dynamique" telle est la question du jour
pour ceux qui en ont le courage, la lecture de https://docwiki.embarcadero.com/RADS...able_(FireDAC)
Néanmoins cette fois ci je pense que c'est vraiment :resolu:
