Discussion :

[stealth35]

stealth35 ton point de vue me conforte , donc des requêtes préparées couplées aux transactions.
s'il y'a un autre avis le débat est ouvert alors n’hésitez pas vous ête en plein chantier

pas besoin de transaction, ton formulaire doit retourner que les valeurs sous forme de tableau comme, ensuite 1 ligne ou 1000 lignes ne changera rien, ensuite t'auras juste a bouclé sur sur ton execute

[redoran]

Stealth35 :

pas besoin de transaction

selon vous les requêtes préparées feront l'affaire.
les transaction assure l’intégrité des requêtes en assurant leurs exécution c.a.d.l'exécution complète de l'opération ou pas.
donc je crois pas que les requêtes préparées remplace cette action.

[stealth35]

Stealth35 : selon vous les requêtes préparées feront l'affaire.
les transaction assure l’intégrité des requêtes en assurant leurs exécution c.a.d.l'exécution complète de l'opération ou pas.
donc je crois pas que les requêtes préparées remplace cette action.

tu sais comment fonctionne une requête préparée ?

[Marc3001]

Stealth35 : selon vous les requêtes préparées feront l'affaire.
les transaction assure l’intégrité des requêtes en assurant leurs exécution c.a.d.l'exécution complète de l'opération ou pas.
donc je crois pas que les requêtes préparées remplace cette action.

Les requêtes préparées servent surtout à gagner en perfs. La requête n'étant compilée qu'une fois et le plan d'exec calculé une fois aussi.

L'interêt des transactions c'est de pouvoir faire un rollback sur tout ton traitement si ça pête au milieu et donc d'assurer l'intégrité des données.

Le but de ces 2 fonctionnalités n'est pas du tout le même.
On peux d'ailleurs les cumuler.