Discussion :

[Patrick25300]

Avec Firebird, je fais une application ou j’utilise des IBQuery et quelques tables.

Mon application est une application SDI du coup chaque Forme gère un fichier de la base de donnée, j’utilise un DataModule pour l’ensemble des Formes.

J’ai des tables ou il y a qu’un enregistrement, je m’en serre pour certaines configurations dans l’application, elles restent ouvertes jusqu’a la fermeture de l’application.
Faut-il les ouvrir et les fermer juste pour lire les données à un moment T ou mettre les données dans des variables globales de l’application ?

Idem pour les IBQuery, j’active les IBQuery lors de l’ouverture des différentes Formes et toutes se ferment lors de la déconnexion à la base de données quand je quitte l’application.
Faut-il faire autrement ?

De plus je pense faire fonctionner l’application avec la base de données en réseau. Et j’ai qu’un composant IBTransaction.
Faut-il un mettre un par IBQuery et table ?

Merci de vos réponses.
Patrick25300

[ameno_123]

Bonne question, je cherche moi même une réponse

Est-ce que je dois utiliser un unique ibcquery dans ma DM pour toutes mes update,insert et delete, ou sur chaque fiche je dois poser un ibcquery et un TIBCTransaction lier à mon TIBCConnection!?

[qi130]

Je suis tenté de retourner la question

Quelle est l'utilité de conserver la query ouverte et la transaction active ?

ou encore: quels sont les risques d'un tel fonctionnement ?

Surtout dans un contexte de mise en réseau.

Autre point: comment est paramétrée la transaction au niveau du commit ?

Je rappelle qu'une transaction permet de passer d'un état stable de la base, à un autre état stable.

Pour les tables mono-ligne, je suis partisan d'en stocker le contenu coté client, sauf si ce contenu évolue continuellement et rapidement. Encore qu'avec un event on puisse signaler le besoin de recharger le contenu.

[makowski]

un simple regard à tes stats de transactions te donnera la réponse
si tes requetes sont liées à des transactions autres que READ ONLY READ COMMITTED RECORD_VERSION tu vas droit dans le mur

[Patrick25300]

Bonjour
Merci pour ces réponses,

voici les paramètres de IBTransaction

Code :

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

1
2
3
read_committed
rec_version
nowait

DefaultAction est égale à : TACommit
Je pense comprendre que IBTransaction gère lui même le fait d'éditer est de poster les nouvelles données ou modifications. Est-ce juste?

[makowski]

oui, mais un select avec un query ouvert laisse la transaction ouverte tant que le query est ouvert

donc tu vas dans le mur (gap des transactions, garbage, etc )

[Patrick25300]

pour cette réponse très claire.
Donc ouvrir suivant le besoin, et fermer au plus vite quitte à temporiser les temps de saisie.
Maintenant, je comprends aussi pourquoi l'ERP où je travaille temporise les temps de saisie.
Le sujet est clos...

[qi130]

Je rappelle qu'une transaction permet de passer d'un état stable de la base, à un autre état stable.

Et donc, si l'état est stable, c'est que la transaction est terminée