Une transaction permet plusieurs choses et notamment d'isoler les traitements les uns des autres; Et est indispensable pour assurer la bonne cohérence des données.

Isoler les traitements les uns des autres :
Lorsqu'on développe une application client/serveur avec un SGBD, le plus souvent, ce SGBD va être interrogé et modifié par plusieurs programmes simultanément par les différentes machines connectées. Le type d'isolation permet notamment de pouvoir répondre précisément aux types de question suivante : Que se passe t'il si un utilisateur modifie plusieurs enregistrements qu'un autre est en train d'imprimer ?

On peut paramétrer les transactions pour déterminer le degré de visibilité des actions extérieures à la transaction (on parle de niveau d'isolation).
Ainsi sous Interbase si on utilise le niveau d'isolation le plus fort (snapshot) , les modifications apportées par l'utilisateur n'apparaitront pas sur l'impression. Dans ce mode à l'ouverture de la transaction, c'est comme si celle-ci prenait une photo instantannée de la base et tous les ordres SQL se trouvant dedans travailleraient sur cette photo.

Un niveau moins isolant est : readCommited. Dans ce mode les ordres SQL lisent les données qui sont validées. Dans ce mode les modifications peuvent apparaitre sur l'impression si elles ont été validées (Commit).

La bonne cohérence des données : Une transaction permet de grouper plusieurs actions SQL et de les rendre atomiques (indissociables). Cet aspect est très important car bien souvent la mise à jour de données ne peut se faire avec un seul ordre SQL. Par exemple lorsque vous faites un virement compte à compte, il y a (en simplifiant) deux actions : 1-Mise à jour du solde du compte émetteur et 2-Mise à jour du solde du compte destinataire. Dans l'opération 1 on va soustraire au solde le montant du virement et dans l'opération 2 on va ajouter le montant du virement au solde du compte. Que se passe t'il si par malheur votre machine tombe en panne juste après l'opération 1 ? Le compte émetteur est débité mais le compte récepteur n'a pas reçu le virement.... C'est inadmissible ! Encore une fois les transactions permettent d'éviter ce genre de catastrophe car on peut valider ou annuler tous les ordres SQL inclus dans la transaction. Ainsi l'opération 1 et l'opération 2 deviennent indissociables comme si c'était qu'une seule mise à jour.

Le Commit permet de valider l'ensemble des ordres SQL passés dans la transaction (les ordres de mise à jour ou d'insertion de données). Ce n'est qu'une fois cet ordre exécuté que les données sont considérées comme étant cohérentes (et donc écrites) dans la base.

Le RollBack permet lui au contraire d'annuler tous les ordres SQL passés dans la transaction. Tous les ordres de modification ou d'insertion passés dans la transaction dont on a fait le Rollback sont 'annulés'.

Il est à noter que ces deux actions ont pour effet de fermer la transaction. (Et donc les ensembles de données attachés à cette transaction).

Si on veut maintenir la transaction ouverte il faut utiliser CommitRetaining et RollBackRetaining.