Discussion :

[Pierre GIRARD]

Bonjour,

J'ai une petite application avec une seule table FireBird. J'utilise les composants IB avec :
TIBDatabase
TIBDataSet
TIBUpdateSQL (avec DeleteSQL, InsertSQL, ModifySQL et RefreshSQL renseignés)
TIBTranslation
TDataSource

J'ai configuré tout ça à partir des (trop peu) nombreux Tutos et exemples Delphi.

J'ai un champ avec les enregistrements suivants :
20 mn - 20 mn - 35 mn - 25 mn - ect...
Je modifie les valeurs dans ces champs avec :
21 mn - 21 mn - 36 mn - 26 mn - ect...
Et à l'arrivée j'ai :
20 mn - 21 mn - 35 mn - 25 mn - ect...

Seul le 2ème est modidié ??? Jamais le premier ni jamais les autres. Surtout que selon la totalité des exemples que j'ai trouvés, il suffit d'avoir un "TIBUpdateSQL" configuré pour écrire dans la base (pas besoin d'écrire de code supplémentaire). J'ajoute qu'il n'y a aucune erreur à aucun moment.

Une chance pour moi, c'est plus une base de données utilisée en lecture qu'en écriture, mais, c'est quand même bizarre comme comportement

[SergioMaster]

Bonjour , tu peux nous montrer les instructions de l'UpdateSQL ? (plus particulièrement celle de l'Update)
et comment tu fais pour mettre à jour les champs

[Pierre GIRARD]

Bonjour , tu peux nous montrer les instructions de l'UpdateSQL ? (plus particulièrement celle de l'Update)
et comment tu fais pour mettre à jour les champs

Pour la génération : DoubleClic sur "TIBUpdateSQL" puis clic sur "Générer le SQL" qui donne :

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
update TBL_RECETTES
set
  BOISSON = :BOISSON,
  CODE_RCT = :CODE_RCT,
  DESC_GENRE = :DESC_GENRE,
  DESC_TYPE = :DESC_TYPE,
  ID_G = :ID_G,
  ID_T = :ID_T,
  INGR_PAL = :INGR_PAL,
  INGR_SEC = :INGR_SEC,
  NB_PERS = :NB_PERS,
  NUM = :NUM,
  ORIGINE = :ORIGINE,
  TITRE = :TITRE,
  TMP_AUTRE = :TMP_AUTRE,
  TMP_CUIS = :TMP_CUIS,
  TMP_PREP = :TMP_PREP,
  UTILISATION = :UTILISATION
where
  BOISSON = :OLD_BOISSON and
  CODE_RCT = :OLD_CODE_RCT and
  DESC_GENRE = :OLD_DESC_GENRE and
  DESC_TYPE = :OLD_DESC_TYPE and
  ID_G = :OLD_ID_G and
  ID_T = :OLD_ID_T and
  INGR_PAL = :OLD_INGR_PAL and
  INGR_SEC = :OLD_INGR_SEC and
  NB_PERS = :OLD_NB_PERS and
  NUM = :OLD_NUM and
  ORIGINE = :OLD_ORIGINE and
  TITRE = :OLD_TITRE and
  TMP_AUTRE = :OLD_TMP_AUTRE and
  TMP_CUIS = :OLD_TMP_CUIS and
  TMP_PREP = :OLD_TMP_PREP and
  UTILISATION = :OLD_UTILISATION

Je n'ai aucune clé primaire, juste un index composé de plusieurs champs :

Code :

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

CREATE UNIQUE INDEX IDX_RECETTES ON TBL_RECETTES (ID_G, ID_T, CODE_RCT, NUM);

Le test a été fait sur le champ "TMP_PREP" qui est un "VARCHAR(7)"

[Barbibulle]

Bonjour,

Pourquoi utilisez-vous

Code :

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

1
2
TIBDataSet
TIBUpdateSQL

TIBDataset à tout ce qu'il faut pour mettre à jour les données il peut être utilisé sans un TIBUpdateSQL.

En générale on trouve un TIBDataSet seul ou un TIBQuery+TIBUpdateSQL car le TIBQuery contenant un select ne pourra pas mettre à jour les données.
et comme SergioMaster le demande :
Il faudrait donner plus d'information sur votre programme :

1. votre requête de mise à jour. (celle du TIBUpdateSQL et cette du TIBDataset)
2. Vous avez relié le TIBDataSet au TIBUpdateSQL ?
3. La clé primaire de votre table
4. le type de transaction que vous utilisez et aussi à quelle moment vous faites le commit

[Pierre GIRARD]

Bonjour,

Pourquoi utilisez-vous

Code :

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

1
2
TIBDataSet
TIBUpdateSQL

TIBDataset à tout ce qu'il faut pour mettre à jour les données il peut être utilisé sans un TIBUpdateSQL.

En générale on trouve un TIBDataSet seul ou un TIBQuery+TIBUpdateSQL car le TIBQuery contenant un select ne pourra pas mettre à jour les données.
et comme SergioMaster le demande :
Il faudrait donner plus d'information sur votre programme :

1. votre requête de mise à jour. (celle du TIBUpdateSQL et cette du TIBDataset)
2. Vous avez relié le TIBDataSet au TIBUpdateSQL ?
3. La clé primaire de votre table
4. le type de transaction que vous utilisez et aussi à quelle moment vous faites le commit

En fait, si ça se trouve TIBUpdateSQL n'est même pas utlisé, c'est sans doute un oubli car j'avais d'abord testé avec TIBQuery+TIBUpdateSQL (qui ne marchait pas mieux). Sinon :
1) C'est exactement la même requête (voir plus haut)
2) Non, d'ailleurs, ça donne une erreur "Update failed"
3) Il n'y en a pas (voir plus haut)
4) Le TIBTransaction (et non TIBTranslation comme écrit plus haut ) à DefaultAction = TACommitRetaining (mais c'est pareil avec TACommit)

Si il faut ajouter quelque chose, je n'ai trouvé aucun exemple l'expliquant.

PS. TIBUpdateSQL reste intéressant pour la génération automatique des scripts SQL J'ai pas vu l'équivalent avec TIBDataset.

[Barbibulle]

S'il n'y a pas de clé primaire c'est mal !

Mais avec votre index unique vous pouvez simplifier les requêtes de mises à jour :

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
update TBL_RECETTES
set
  BOISSON = :BOISSON,
  CODE_RCT = :CODE_RCT,
  DESC_GENRE = :DESC_GENRE,
  DESC_TYPE = :DESC_TYPE,
  ID_G = :ID_G,
  ID_T = :ID_T,
  INGR_PAL = :INGR_PAL,
  INGR_SEC = :INGR_SEC,
  NB_PERS = :NB_PERS,
  NUM = :NUM,
  ORIGINE = :ORIGINE,
  TITRE = :TITRE,
  TMP_AUTRE = :TMP_AUTRE,
  TMP_CUIS = :TMP_CUIS,
  TMP_PREP = :TMP_PREP,
  UTILISATION = :UTILISATION
where
  CODE_RCT = :OLD_CODE_RCT and
  ID_G = :OLD_ID_G and
  ID_T = :OLD_ID_T and
  NUM = :OLD_NUM

Vous modifiez comment les valeurs de TMP_PREP ?
Affichage dans une DBGrid ?
Affichage dans un DBEdit + un navigateur d'enregistrement ?
Par programme avec une boucle sur le dataset ?

[Pierre GIRARD]

Vous modifiez comment les valeurs de TMP_PREP ?
Affichage dans une DBGrid ?
Affichage dans un DBEdit + un navigateur d'enregistrement ?
Par programme avec une boucle sur le dataset ?

J'utilise un DBEdit, et pour tester, j'ai rajouté :

Code :

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

1
2
  DsCuisineTMP_PREP.Value := EditTmpPrepa.Text;
  EditTmpPrepaTest.Caption := DsCuisineTMP_PREP.Value;

EditTmpPrepa étant un DBEdit et EditTmpPrepaTest un simple label. Je me déplace avec un DBNavigator. Et tant que je reste connecté les modifications sont bien prises en compte. Mais dès que je sort, c'est comme si il y avait un Rollback ... mais sauf pour la deuxième valeur qui est la seule a être vraiment écrite en dur dans la base.

Quand à l'index, il correspond à une arborescence précise, à savoir : "01_Abats\01_Pas de cuisson\MillefeuilleFoieGras_1.jpg". Ce qui donne dans le code :

Code :

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

1
2
3
4
5
6
    Chemin  := 'D:\Cuisine\Recettes\'
                +DSCuisineID_G.Value+'_'
                +DSCuisineDESC_GENRE.Value+'\'
                +DSCuisineID_T.Value+'_'
                +DSCuisineDESC_TYPE.Value+'\';
    FicImag := DSCuisineCODE_RCT.Value+'_'+IntToStr(DSCuisineNUM.Value)+'.jpg';

Tout est rangé nickel et dans le même ordre dans la base de donnée que sur le disque. Et pour une base d'un peu plus de 2000 enregistrements, c'est largement suffisant, une clé primaire ne m'apporterais pas grand chose.

[SergioMaster]

Bonjour,

Et tant que je reste connecté les modifications sont bien prises en compte. Mais dès que je sort, c'est comme si il y avait un Rollback ... mais sauf pour la deuxième valeur qui est la seule a être vraiment écrite en dur dans la base.

hum , ça sent le Commit manquant ! ou un post ou les deux ?

Et pour une base d'un peu plus de 2000 enregistrements, c'est largement suffisant, une clé primaire ne m'apporterais pas grand chose.

malgré tout si , une requête UPDATE sur un index primaire unique (upWhereKey) sera toujours plus rapide qu'une requête UPDATE vérifiant tous les champs (upWhereAll). Et cela n'alourdira pas la base et permettrait le déplacement des jpg au besoin

puisque c'est de Firebird qu'il s'agit mettre en place un NUMERO UNIQUE auto incrémenté (GENERATOR aka SEQUENCE) est simple , un trigger pour gérer les incrémentations et rien à changer dans le code (si ce n'est les updates )

[Pierre GIRARD]

Bonjour,

hum , ça sent le Commit manquant ! ou un post ou les deux ?...

Oui ??? mais alors dans ce cas, le deuxième enregistrement ne serait jamais enregistré lui non plus ... ou ça serait en serait un au hasard, et pas toujours exactement le même ?

Pour le post, j'ai essayé de rajouter :

Code :

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

1
2
3
4
5
begin
  DsCuisine.Edit;
  DsCuisineTMP_PREP.Value := EditTmpPrepa.Text;
  DsCuisine.Post;
end;

Sur le bouton "nbPost" du DBNavigator ... mais, ça ne change rien.

Pour ce qui est d'une clé primaire, le problème c'est qu'il n'y a plus de logique dans la base, c'est rangé "en vrac" du coup (au fil des nouveaux enregistrements), ça oblige quand même à mettre mon index composite pour remettre tout dans le bon ordre lors de la consultation.

Quant à gagner du temps sur une base de 2000 à 3000 enregistrements sur une seule table ne comportant que 15 champs, j'ai des doutes que ce soit vraiment mesurable.

[Pierre GIRARD]

Ca y est, c'est bon. C'était juste le "where" de la requète SQL. Avec :

Code :

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

1
2
3
4
5
where
  CODE_RCT = :OLD_CODE_RCT and
  ID_G = :OLD_ID_G and
  ID_T = :OLD_ID_T and
  NUM = :OLD_NUM

Ça marche Nickel, merci à tous les deux.

[SergioMaster]

Pour le post, j'ai essayé de rajouter :

Code :

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

1
2
3
4
5
begin
  DsCuisine.Edit;
  DsCuisineTMP_PREP.Value := EditTmpPrepa.Text;
  DsCuisine.Post;
end;

Sur le bouton "nbPost" du DBNavigator ... mais, ça ne change rien.

Ah , parce qu'il y avait un DBNavigator , encore fallut-il que l'on le susse << je m'en lasserais jamais
ceci étant le "dsCuisine.Edit" est en trop, car dsCuisine est déjà en mode modification !

Pour ce qui est d'une clé primaire, le problème c'est qu'il n'y a plus de logique dans la base, c'est rangé "en vrac" du coup (au fil des nouveaux enregistrements), ça oblige quand même à mettre mon index composite pour remettre tout dans le bon ordre lors de la consultation.

Que nenni , cela n'est rangé "en vrac" que dans la base de données , mais l'ouverture avec un order by avec une query ou en specifiant la clé composite
pour une table règle le problème

Quant à gagner du temps sur une base de 2000 à 3000 enregistrements sur une seule table ne comportant que 15 champs, j'ai des doutes que ce soit vraiment mesurable.

oui c'est vrai , mais cela aurait évité le désagrément du problème , réglé avec

C'était juste le "where" de la requête SQL

Enfin (et surtout c'est une bonne pratique/habitude à prendre)
de fait si tu es (très) curieux , tu trouveras qu'en fait Firebird crée quand même cet index (RDB$KEY) dès qu'aucune clé primaire n'est crée donc ....

[Pierre GIRARD]

Ah , parce qu'il y avait un DBNavigator , encore fallut-il que l'on le susse ...

Je l'avais indiqué dans ma réponse à " Barbibulle"

Maintenant, merci pour toutes ces précisions (qui ne peuvent que m'être utile par la suite), mais si j'ai posé cette question dans "Débutant", c'est pas par hasard. Et même si il y avait eu une section "Amateur/dilettante", c'est même là que j'aurais été.

Ceci étant, attendez-vous à d'autres questions basiques. Je suis en test (ultra-basique) pour passer à Lazarus + ZeosDbo. Et pour le moment ... ça se termine par des crashs violents de mes exécutables. C'est pas gagné d'avance.

Ah oui, pour ce qui est de l'ordre (j'avais essayé avec une clé primaire), mais toutes mes mises à jour, je les fait à partir de IbExpert. Et par défaut, il range à partir de la clé primaire. Ma solution est en fait plus simple et plus rapide quand j'ajoute des enregistrements. J'ai aussi une base de données pour ma collection de timbres avec 5 tables, des clés primaires et des clés étrangères ... et je galère à la puissance 1000 par rapport à cette application là.

[SergioMaster]

Je me déplace avec un DBNavigator.

je sais , je pinaille

Ceci étant, attendez-vous à d'autres questions basiques. Je suis en test (ultra-basique) pour passer à Lazarus + ZeosDbo. Et pour le moment ... ça se termine par des crashs violents de mes exécutables. C'est pas gagné d'avance.

ça devrait pas (en theorie)

Ah oui, pour ce qui est de l'ordre (j'avais essayé avec une clé primaire), mais toutes mes mises à jour, je les fait à partir de IbExpert. Et par défaut, il range à partir de la clé primaire.

Sauf en utilisant SELECT * FROM MATABLE ORDER BY MESCHAMPS

J'ai aussi une base de données pour ma collection de timbres avec 5 tables, des clés primaires et des clés étrangères ... et je galère à la puissance 1000 par rapport à cette application là.

Rien d'insurmontable , et on est tous passé un jour ou l'autre en Débutant , suffit de poser les bonnes questions

[Pierre GIRARD]

Déjà, en suivant ton tuto ... et avec la même base firebird, (je sais, sans MasterKey) :

...ça devrait pas (en theorie)...

Et bien, dans TDBGrid, les colonnes ID_G et ID_T sont vides. Comme ce sont deux des champs utilisés pour l'index composite, on se doute du résultat.

[Pierre GIRARD]

...Enfin (et surtout c'est une bonne pratique/habitude à prendre)
de fait si tu es (très) curieux , tu trouveras qu'en fait Firebird crée quand même cet index (RDB$KEY) dès qu'aucune clé primaire n'est crée donc ....

Il y a des exemples d'utilisation de cette clé ?

[SergioMaster]

Déjà, en suivant ton tuto ... et avec la même base firebird,
dans TDBGrid, les colonnes ID_G et ID_T sont vides.

Mon tutoriel étant ce qu'il est, c.a.d. pas fini , je serais curieux de comprendre ce que tu as fait histoire d'indiquer plus précisément ce qu'il faut faire

Il y a des exemples d'utilisation de cette clé ?

à ma connaissance non , j'ai de lointaines réminiscences d'un cas par contre d'une utilisation mais ma mémoire me fait défaut pour plus de détail

[Pierre GIRARD]

Mon tutoriel étant ce qu'il est, c.a.d. pas fini , je serais curieux de comprendre ce que tu as fait histoire d'indiquer plus précisément ce qu'il faut faire...

J'avais bien compris

Voila, j'ai suivi point à point le chapitre "III. Introduction" :

Les deux champs vides sont des "VARCHAR(2) NOT NULL" et contiennent 01 à 53 pour ID_G et 01 à 11 pour ID_T. Donc, rien d'extraordinaire. Pourquoi des VARCHAR ?, parce que le classement n'est pas toujours comme Windows. Avec des nombres on a :
1 10 11 ... 19 2 20 21 etc... dans certains cas
au lieu de :
1 2 3 ... 910 11 etc... dans un autre (Windows)

Je n'ai trouvé aucun moyen (à part un VARCHAR) de contourner ce problème, car pas trouvé le moyen de déclarer un nombre sur deux chiffres (contrairement à un tableur comme celui d'OpenOffice que j'utilise). C'est à dire :
01 02 03 ... 09 10 11 etc...

Du coup, ça range de la même façon dans tous les cas.

[SergioMaster]

Bonjour,

Bon , puisque tu a lu mon début de tutoriel , tu auras remarqué sur le fait que j'insiste en disant qu'utiliser une table n'est pas forcément la meilleure idée.
tu aurais pu (du?) utiliser un ZQuery + un ZUpdateSQL (je n'ai pas encore totalement rédigé cette phase) , cela t'aurait permis de gérer l'histoire des tri .

parce que le classement n'est pas toujours comme Windows. Avec des nombres on a :
1 10 11 ... 19 2 20 21 etc... dans certains cas
au lieu de :
1 2 3 ... 910 11 etc... dans un autre

parce que dans le cas 1 le champ est déclaré en Char(n) ou varchar(n) alors que dans l'autre cas il est déclaré en entier ! pour ensuite limiter à seulement 2 chiffres il suffit d'ajouter un contrainte. L'affichage avec les zéros non significatif est 'cosmétique' dans le cas d'entier et gérable via les déclarations des champs de la Table/Query

Pour en revenir à ta grille , difficile de diagnostiquer le problème juste avec l'image écran . Dans mon tutoriel (je viens de relire ce que j'ai écrit), rien n'est ajouté, aucun champ déclaré (clic droit sur la table + ajout des champs) est-ce ton cas ?
es-tu sûr de ta table ?
comme le projet ne doit pas être énorme , ne peux-tu poster les sources + la base (j'ai lazarus , peut être pas la même version mais c'est facile à régler)?

[edit] reprise après révision de ton image écran
déjà , j'ai l'impression que la structure de ta base de données pêche
j'aurais fait la structure suivante :
1-Table des Types (code_idt, libelle_type)
2-Table des Genres (code_idg,libelle_genre)
3-Table des Recettes? (code,idt,idg,nom_recette....) contraintes de clé étrangère sur Types et Genres , code = primary key ? géré par trigger ?

pour afficher dans une grille modifiable, les recettes j'aurais utilisé une query (cette partie du tutoriel n'est pas encore rédigée/publiée)

Code sql :

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

1
2
3
4
5
SELECT R.idt, R.idg,R.nom_recettes,t.libelle_type,g.libelle_genre 
    FROM RECETTES R
                 JOIN  TYPES T ON R.idt=T.code_idt
                 JOIN GENRES G  ON R.idg=G.code_idg
ORDER BY r.idt,r.idg,r.nom_recette  // ou order by 1,2,3

Le UpdateSQL aurait les instructions suivantes (écrit à l'arrache)

UPDATE RECETTES SET IDT=:IDT,IDG=:IDG,NOM_RECETTE=:NOM_RECETTE WHERE CODE=:OLD_CODE
INSERT INTO RECETTES (IDT,IDG,NOM_RECETTE) VALUES (:IDT,:IDG,:NOM_RECETTE)
DELETE FROM RECETTES WHERE CODE=:OLD_CODE

En espérant t'avoir donné des pistes de réflexion

Serge (GIRARD et pourtant on n'est pas cousins que je sache )

[Pierre GIRARD]

Bonjour,

Bon , puisque tu a lu mon début de tutoriel , tu auras remarqué sur le fait que j'insiste en disant qu'utiliser une table n'est pas forcément la meilleure idée.
tu aurais pu (du?) utiliser un ZQuery + un ZUpdateSQL (je n'ai pas encore totalement rédigé cette phase) , cela t'aurait permis de gérer l'histoire des tri .
C'est certainement ce que je ferais, mais c'était juste un test rapide.

parce que dans le cas 1 le champ est déclaré en Char(n) ou varchar(n) alors que dans l'autre cas il est déclaré en entier ! pour ensuite limiter à seulement 2 chiffres il suffit d'ajouter un contrainte. L'affichage avec les zéros non significatif est 'cosmétique' dans le cas d'entier et gérable via les déclarations des champs de la Table/Query

Le problème ne ce situe pas exactement là, il se trouve dans le nom des répertoires. Selon qu'on est dans l'explorateur Windows ou pas, "5_Répertoire" sera placé :
Entre 4_Répertoire et 6_Répertoire
Ou entre 49_Répertoire et 50_Répertoire (avec certaines applications)
Alors que "05_Répertoire" sera toujours placé entre 04_Répertoire et 06_Répertoire

Et il ne s'agit donc pas de limiter à deux chiffres, mais d'écrire 01 au lieu de 1. Pas impossible, mais ça demande quelque lignes de plus pour passer d'un chiffre à un string, puis de rajouter 0 devant si c'est compris entre 1 et 9. Alors que là, c'est directement bon dans 100% des cas. Surtout que si un jour je dépasse 99 ...

Pour en revenir à ta grille , difficile de diagnostiquer le problème juste avec l'image écran . Dans mon tutoriel (je viens de relire ce que j'ai écrit), rien n'est ajouté, aucun champ déclaré (clic droit sur la table + ajout des champs) est-ce ton cas ?

Oui

es-tu sûr de ta table ?
comme le projet ne doit pas être énorme , ne peux-tu poster les sources + la base (j'ai lazarus , peut être pas la même version mais c'est facile à régler)?

C'est la même qui fonctionne sans problème avec Delphi et les composants IB

[edit] reprise après révision de ton image écran
déjà , j'ai l'impression que la structure de ta base de données pêche
j'aurais fait la structure suivante :
1-Table des Types (code_idt, libelle_type)
2-Table des Genres (code_idg,libelle_genre)
3-Table des Recettes? (code,idt,idg,nom_recette....) contraintes de clé étrangère sur Types et Genres , code = primary key ? géré par trigger ?
...

J'y ai pensé, mais pour une table qui ne dépassera probablement jamais les 3000 enregistrements, j'en vois pas l'intérêt. Surtout que question performances, c'est nickel comme ça. Par contre avec mon appli de gestion de mes timbres, c'est ce que j'ai fais, mais je galère encore plus pour faire des modifications sur les enregistrements des tables ... mais c'est pas d'actualité (pas encore).

Serge (GIRARD et pourtant on n'est pas cousins que je sache )

Pas que je sache, j'ai travaillé pendant 15 ans chez Digital, où il y avait pas mal de GIRARD dont 3 Pierre GIRARD

[Pierre GIRARD]

...comme le projet ne doit pas être énorme , ne peux-tu poster les sources + la base...

Ci joint en pièce jointe

[edit]Je viens de faire un autre test rapide avec Delphi. => c'est pas Lazarus, ce sont les composants ZeosDbo, car ça fait la même chose.