Discussion :

[Kneukar]

Bonjour,
Suivant le conseil d'un modérateur je repose mon problème sur cette section
(La discussion initiale:http://www.developpez.net/forums/d15...e-pris-compte/)
je viens ici car, moi débutant à Firebird, j'ai un gros problème
en effet je développais tranquille mon application sous Delphi quand je me suis rendu compte que ma base de donnée Firebird ne prenait pas
en compte les updates, sachant que les insert into marche parfaitement.
Je m'explique, via l'application ou via l'ISQL Tool de Firebird, je fait un update, puis après je fait un select, l'update à été pris en compte,
puis quand je quitte l'application/Firebird et relance, la ligne est revenu à la normal.
ultérieurement j'avais supprimer le fichier de la base de donnée pour la remplacer par une ancienne version de la base plus propre(peut être à cause de ça?) et après je l'ai restauré mais, le problème à persisté
Du coup je viens vers vous pour vous demandez, qu'est que je pourrait faire pour faire fonctionner correctement les updates et savoir d'où ça viens.

Sur Delphi(même si je ne pense pas que le proviennent de Delphi, plutôt de Firebird) j'utilise des FireDac(Query,Connection,Transaction,Update)une DataSource(une seule pour tous mes query)
Voici un exemple des updates que j'utilisais:

Code :

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

update ARTXRES set LIBXART='le test' where REFXART='091100029';

et voici un exemple de mes insert into:

Code :

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

insert into ARTXRES VALUES(null, FM450 , 091200029, 'untest' , Y , N , 0);

sinon a part ça il y a des trigger pour générer les codes(celui qui est marqué comme null dans l'insert) et il n'y a pas de clé étrangère donc logiquement pas de problème d'intégrités

En espérant vous ayant fourni assez d'éléments de réponse j'attend impatiemment vos réponses

Kneukar

[SergioMaster]

Bonjour,

Suivant le conseil d'un modérateur

le modérateur c'est moi, mais ce n'est pas en tant que modérateur que j'avais suggéré de changer de forum mais plutôt parce que je pense que c'est un problème de programmation plutôt que Firebird (sinon cela fait longtemps que j'aurai jeté Firebird aux orties )

Sur Delphi(même si je ne pense pas que le proviennent de Delphi, plutôt de Firebird)

je pense le contraire

j'utilise des FireDac(Query,Connection,Transaction,Update)une DataSource(une seule pour tous mes query)

nous voilà à peu près au cœur du problème, car Firedac (pour Interbase et Firebird) permet deux transactions simultanées pour la connexion, mais aussi peu accepter une autre transaction pour une Query.
La première question qui me vient à l'esprit est donc : Comment tous ces composants sont liés à la/les transactions ?
Dans la plupart des cas, en mode Autocommit, pour un FDConnection on mettra une FDTransaction et c'est tout la FDQuery étant relié à la FDConnection il n'y a pas besoin d'indiquer de valeur à la propriété Transaction de cette dernière. Même en utilisant un FDUpdateSQL lié à la requête il n'y a pas besoin d'indiquer quoique ce soit.

La seconde question qui se pose donc est : Comment est paramétrée la connexion et la transaction ?
AutoCommit ou autre

puis la question qui en découle : Est-ce que la Transaction est démarrée explicitement ou non (Transaction.StartTransaction;)

Voici un exemple des updates que j'utilisais:

Code :

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

update ARTXRES set LIBXART='le test' where REFXART='091100029';

et voici un exemple de mes insert into:

Code :

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

insert into ARTXRES VALUES(null, FM450 , 091200029, 'untest' , Y , N , 0);

Enfin, je connais au moins trois manières de faire les instructions citées donc, comment est-ce fait dans le programme ?
-FDConnection.ExecSQL()
-FdQuery.SQL.Text:= .... ; FDQuery.ExecSQL;
-FDQuery.Edit; ... FDQuery.Post;

En espérant vous ayant fourni assez d'éléments de réponse j'attend impatiemment vos réponses

non , désolé pas encore assez d'éléments mais à mon avis il s'agit bien de problème de transaction mal fermée (commit)

[Kneukar]

Dans mon projet il y a quatres fenêtres/unités:
-La page de base sur lequel il y a:
Trois FDQuery(des selects)
Un DataSource, Un FDTransaction, un FDConnection et FDUpdate
-La page pour insérer/modifier:
Deux FDQuery(Insert)
Deux FDQuery(Update)
Six FDQuery(Select)
-Une autre page permettant de gérer une autre table
Trois FDQuery(Select)
-une page de confirmation de modification/suppression:
Deux FDQuery(Delete)

Pour tous mes Query j'ai rempli les propriétés Connection, Transaction et UpdateTransaction avec FDConnection et FDTransaction
J'ai regardé pour les commits sur FDConnection, et l'AutoCommits n'était pas actif pour les updates, je me suis empressé de l'activé mais sa ne persiste à ne pas fonctionné, les autres qui ne sont pas activé sont:FastUpdates,LockWait, ReadOnly, UpdateNonBaseFields.
et UpdateMode est sur upwhereKeyOnly
sur FDTransaction il n'y a que ReadOnly qui n'était pas actif
et voila les exemples de comment je fait pour
les select:

Code :

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

1
2
3
4
5
FDQuery.Active:=False;
FDQuery.SQL.Clear;
FDQuery.SQL.Add('blablabla')
FDQuery.ParamByName('eventuellement').AsString:=machin;
FDQuery.SQL.Active:=True;

insert into(qui fonctionne), update et delete(qui fonctionne)

Code :

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

1
2
3
4
FDQuery.SQL.Clear;
FDQuery.SQL.Add('blablabla')
FDQuery.ParamByName('eventuellement').AsString:=machin;
FDQuery.ExecSQL;

Voila.

[SergioMaster]

Bonjour,

Pour tous mes Query j'ai rempli les propriétés Connection, Transaction et UpdateTransaction avec FDConnection et FDTransaction

c'est certainement là que ça coince. Ne rien indiquer dans les propriétés Transaction et UpdateTransaction des Querys
je ne maitrise pas encore parfaitement Firedac sur ce sujet, surtout en ce qui concerne la différence entre Transaction et UpdateTransaction (utilisable uniquement faut-il le rappeler ? avec Interbase et Firebird donc pas portable en terme de changement de SGBD).

En fait l'utilisation de l'une ou l'autre est faite par les composants et le choix effectué n'est pas évident du tout !
j'ai pu tester en faisant ceci
- poser deux FDTransactions la première pour lecture en mode readonly FDTransLecture
la seconde normale FDTransUpdate
- mettre ensuite pour la connexion Transaction=FDTransLecture et UpdateTransaction=FDTransUpdate
on pourrait s'attendre à ce que les requêtes de SELECT se fassent via la première et que les modifications (INSERT/UPDATE/DELETE) passent par la seconde
et bien, pas du tout, et une tentative de modification (INSERT/DELETE) balance une erreur comme quoi la Transaction est en lecture seule . Du coup, je n'ai pas investiguer plus loin
peut être faut-il démarrer explicitement la requête pointée par UpdateTransaction contrairement à celle pointée par Transaction
le comportement serait plutôt : SELECT,INSERT,DELETE passe par la propriété Transaction et UPDATE et uniquement UPDATE par la propriété UpdateTransaction (si cette dernière est indiquée, et encore faut-il que ce soit un second TFDTransaction et non la même que pour la propriété Transaction car dans ce cas j'ai l'impression que ça fait mal )

Je n'ai pas testé le comportement en remplissant les propriétés transaction et update transaction des Querys, là encore la lecture de l'aide est ambiguë .

Mais c'est bien la gestion des transactions le problème et non Firebird

NB. je trouve qu'il y a quand même beaucoup de FDQuery 15 ! tu n'as pas songé à en créer au runtime ? sans parler du ExecSQL/ExecSQLScalar de la connexion et de ses versions surchargées

[Kneukar]

En vérité, je connaissais absolument pas le runtime ou FDConnection.ExecSQL
c'est pour ça que j'ai fait autant de Query... sinon je m'aurai pas privé de les utilisé histoire de rendre la lecture de mon projet plus lisible!

Mais, depuis que tu me parlais que le problème venait des Commits sur l'autre discussion, et j'ai regardé en plus approfondis... Et en réalité le problème était tout simple: Delphi attendait une confirmation que je ne faisais pas!(ce qui est étrange car cela ne genais pas pour delete et insert into...)
du coup j'ai changé mes updates et ça a marché

Code :

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

1
2
3
4
5
6
7
8
9
10
 
FDConnection.StartTransaction;
try
FDQuery.SQL.Clear;
FDQuery.SQL.Add('blablabla')
FDQuery.ParamByName('eventuellement').AsString:=machin;
FDQuery.ExecSQL;
FDConnection.Commit;
finally
end

Encore merci SergioMaster!

[seabs]

Bonjour,

J'utilise pour une application Firedac. J'ai pris l'habitude d'utiliser une transaction en lecture pour les "SELECT" et une autre lecture/ecriture pour toutes les opérations avec Insert, Update et Delete. Cela fonctionne correctement après les quelques soucis de démarrage maintenant réglés.

Tout ceci est bien expliqué par @SergioMaster et il ne semble pas nécessaire d'y revenir.

Par contre ton code me semble incomplet pour une bonne gestion des transactions. Il me paraît nécessaire d'ajouter une instruction Rollback.

Ton code est

Code :

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

1
2
3
4
5
6
7
8
9
FDConnection.StartTransaction;
try
FDQuery.SQL.Clear;
FDQuery.SQL.Add('blablabla')
FDQuery.ParamByName('eventuellement').AsString:=machin;
FDQuery.ExecSQL;
FDConnection.Commit;
finally
end

Je te propose

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
FDConnection.StartTransaction;
try
  FDQuery.SQL.Clear;
  FDQuery.SQL.Add('blablabla')
  FDQuery.ParamByName('eventuellement').AsString:=machin;
  try
    FDQuery.ExecSQL;
    FDConnection.Commit;
  exception
    on E: TFDDBError do
    begin
      if F_FDConnection.InTransaction then
        FDConnection.Rollback;
      ShowMessage('Erreur');
  end
end
finally
end

A modifier suivant les besoins. Mais en tout état de cause, il est indispensable d'annuler une transaction qui a échoué.

A+

[SergioMaster]

Content que ce soit résolu mais ma première réaction à la lecture du code a été : "Houla, y a encore du boulot !"

Voilà ce que je ferais :

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
...
var AQuery : TFDQuery;
begin
 ....
 AQuery:=TFDQuery.Create(nil);
 try 
   AQuery.Connexion:=FDConnexion1;
   AQuery.SQL.Text:='Blalablalalaa';
   AQuery.ParamByName('eventuellement').AsString:=machin;
   AQuery.Connexion.StartTransaction;
   try
     AQuery.ExecSQL;
     AQuery.Connexion.Commit;
   except
      AQuery.Connexion.RollBack;
      // message
   end;
  finally
   AQuery.Free;
 end;
.....
end;

[Edit] grillé

[seabs]

Bonjour,

@SergioMaster

Je m'étais limité au minimum vital, mais effectivement en vérifiant le code d'une de mes méthodes, j'ai constaté qu'il y avait d'autres améliorations à apporter et notamment au niveau de la gestion de la transaction.

Tu as répondu de manière plus complète que moi, j'espère que cela permettra à notre ami d'éviter des soucis dans la gestion de son application.

A+