XE2 / Datasnap / Firebird / Transactions [Résolu]

Messages postés
1293
Date d'inscription
mardi 28 octobre 2003
Statut
Contributeur
Dernière intervention
3 juillet 2015
- - Dernière réponse : cs_cantador
Messages postés
4996
Date d'inscription
dimanche 26 février 2006
Dernière intervention
27 mars 2018
- 15 nov. 2012 à 17:29
Bonjour,

Je me pose une petite question fonctionnelle sur les applications client serveur développées avec Delphi XE2, en utilisant la technologie Datasnap et une base de donnée firebird.

J'ai un serveur avec un composant base de donnée, une transaction et des query paramétrés d'update, d'insert ou de delete. Dans le client, je pose un TDSProviderConnection, puis un TClientDataSet pour chaque query. Je remets les paramètres dans le TClientDataSet (ceux du query correspondant sur le serveur) et je peux faire mes update, insert et delete. En contrôlant dans ma base sur le serveur, tout se passe à merveille. Je voudrais quand même savoir si je peux (dois ?) gérer les transactions. (Ce n'est pas le cas pour le moment, mais il se pourrait que je doive gérer un commit ou rollback sur un ensemble d'ordre SQL de mise à jour).

Any informations ?

Simon
Afficher la suite 

Votre réponse

7 réponses

Meilleure réponse
Messages postés
4996
Date d'inscription
dimanche 26 février 2006
Dernière intervention
27 mars 2018
3
Merci
les transactions sont en principe générées sur un composant "connexion".

ex : avec le TIB_connection

FAccueil.TIB_connection1.DefaultTransaction.CommitRetaining;




cantador

Dire « Merci » 3

Quelques mots de remerciements seront grandement appréciés. Ajouter un commentaire

Codes Sources a aidé 104 internautes ce mois-ci

Commenter la réponse de cs_cantador
Messages postés
4996
Date d'inscription
dimanche 26 février 2006
Dernière intervention
27 mars 2018
0
Merci
Bonjour,

les transaction sont utiles dès l'instant, où il y déjà plusieurs utilisateurs qui interviennent sur la base de données et si également, les données réclament un niveau de sécurité important.

l'accès à la base peut se faire :
- soit de manière exclusive (ce qui est rarement la cas)
- soit en mode partagé

A partir de ce constat et si bien entendu, plusieurs utilisateurs peuvent modifier une donnée dans un champ d'une table, il est nécessaire alors de fixer des règles et des droits.

les transaction entrent dans ce processus en proposant par exemple d'annuler toute une série de manipulations (ex formulaire) avant la validation dès l'instant, où la règle n'est pas respectée, cette marche arrière se faisant en respectant l'intégrité de la base.

Bref, le retour se fait sans encombres (pas de cracra dans les données..)

cordialement
cantador
Commenter la réponse de cs_cantador
Messages postés
1293
Date d'inscription
mardi 28 octobre 2003
Statut
Contributeur
Dernière intervention
3 juillet 2015
0
Merci
Cantador,
Merci pour ce petit rappel sur les transactions , mais ma question portait plus sur l'utilisation des transactions à partir d'un client datasnap. Je ne vois pas comment les gérer dans le client, avec les composants TClientDataSet. Puisque tu en parles, (même si à priori ça ne concerne pas encore mon appli), je ne vois pas non plus ou je dois gérer le niveau d'isolement de ma base...

Je me demande, même si ça fonctionne, si le clientdataset est vraiment fait pour des requêtes de mise à jour, ou si je n'ai pas plutôt intérêt à tout gérer côté serveur au moyen de méthodes publiées qui prendraient les requêtes en paramètres...

Simon
Commenter la réponse de sp40
Messages postés
4996
Date d'inscription
dimanche 26 février 2006
Dernière intervention
27 mars 2018
0
Merci
Bonjour,
[i]
je ne vois pas non plus ou je dois gérer le niveau d'isolement de ma base... /i

Ah ah..

Il s'agit le plus souvent d'une propriété d'un composant de connexion à la base qui propose en général trois formules possibles.

ex: le TDatabase avec sa propriété TransIsolation :

tiDirtyRead Permet la lecture des modifications non validées de la base de données effectuées par des transactions simultanées. Les modifications non validées ne sont pas permanentes, elles peuvent êtres annulées à tout moment. C'est le niveau le plus bas d'isolement d'une transaction par rapport aux effets d'autres transactions.

tiReadCommitted Permet la lecture des modifications validées (permanentes) de la base de données effectuées par des transactions simultanées. C'est la valeur par défaut de la propriété TransIsolation.

tiRepeatableRead Ne permet qu'une seule lecture de la base de données. La transaction ne peut connaître les modifications effectuées ultérieurement par d'autres transactions simultanées. Ce niveau garantit qu'une fois un enregistrement lu par la transaction, l'enregistrement ne change que si la transaction le change. C'est le niveau maximum d'isolement d'une transaction par rapport aux autres transactions.

et dans ce contexte, je te conseille vivement d'opter pour le niveau
tiReadCommitted.

C'est d'ailleurs le plus simple le plus employé et le plus facile à mettre en oeuvre.

Dans cette option, tout le monde peut modifier et valider.
Autrement dit, c'est le dernier qui passe qui fixe la valeur de la donnée.
Il n'y a donc, ici, aucun blocage ni message intempestif d'erreur.
Il suffit juste pour sécurité de fixer les droits des utilisateurs.

et bien entendu, tu peux utiliser le mode transactionnel :
startTransaction, RollBack, Commit

cantador
Commenter la réponse de cs_cantador
Messages postés
1293
Date d'inscription
mardi 28 octobre 2003
Statut
Contributeur
Dernière intervention
3 juillet 2015
0
Merci
Ah ouais, c'était bien caché... Clic droit sur la transaction (tibtransaction), "Editeur de transaction", choix "Lire la transaction validée". Vu le comportement de mon programme actuel, je pense que j'avais le niveau d'isolement maxi. C'est bon à savoir merci. Par contre, j'insiste mais je ne peux gérer ça que côté serveur. N'ayant pas de composant transaction sur le client, y a t'il un moyen par exemple de démarrer une transaction à partir du client, de passer des ordres via un ou plusieurs TClientDataSet, et de faire un commit ou un rollback toujours sur le client ?
En gros, existe-t-il, sur le client, un moyen d'atteindre la transaction rattachée au query sur le serveur, auquel est lié mon TClientDataSet sur le client ?
(Si je ne suis pas clair, dis le moi)

Simon
Commenter la réponse de sp40
Messages postés
4996
Date d'inscription
dimanche 26 février 2006
Dernière intervention
27 mars 2018
0
Merci
y a t'il un moyen par exemple de démarrer une transaction à partir du client

mais bien sûr et heureusement d'ailleurs, puisque c'est justement fait pour eux principalement.

mais je ne te suis pas bien néanmoins..

ton code compilé est en principe placé et exécuté sur le serveur.
Il peut être lancé bien entendu directement sur le serveur mais aussi à partir du poste client.

Si dans ton programme, tu places des instructions
type starttransaction, Rollback ou RollBackRetaining, ou encore
Commit ou CommitRetaining

elles seront nécessairement prises en compte quelque soit l'endroit où l'exécutable a été lancé.

cantador
Commenter la réponse de cs_cantador
Messages postés
1293
Date d'inscription
mardi 28 octobre 2003
Statut
Contributeur
Dernière intervention
3 juillet 2015
0
Merci
D'accord, donc à part publier trois méthodes sur le serveur (pour le start, le commit et le rollback) pour chaque transaction que j'utilise, je ne peux pas appeler la transaction à partir du TClientDataset qui est sur mon client...

Simon
Commenter la réponse de sp40

Vous n'êtes pas encore membre ?

inscrivez-vous, c'est gratuit et ça prend moins d'une minute !

Les membres obtiennent plus de réponses que les utilisateurs anonymes.

Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.

Le fait d'être membre vous permet d'avoir des options supplémentaires.