Discussion :

[kaouane]

Bonsoir tout le monde;
Je me suis dis que puisque les transactions sont faites pour le transfère des données entre la DB et l'application, Qu'est ce qui serait le mieux :
- Créer une seule transaction pour toutes les tables de l'application
- Créer une transaction pour chaque table
Je pose cette question parce que je commence juste à travailler avec FireBird venant du monde du BDE.

[makowski]

une transaction par ensemble de tache cohérent

[kaouane]

une transaction par ensemble de tache cohérent

Très bien;
Mais si j'ai plusieurs traitements cohérents distincts utilisant les mêmes tables, est ce que c'est faisable de changer la propriété "default transaction" des tables à chaque traitement?

[makowski]

on ne travaille pas avec des tables ou des TTables

[kaouane]

on ne travaille pas avec des tables ou des TTables

Non je travail avec les IBTable IBTransaction et IBDatabase

[makowski]

ni des ibtables
travailler avec des Query

[kaouane]

ni des ibtables
travailler avec des Query

Pourquoi pas les Tables? pourquoi elles existent alors?
J'ai une application qui travail en local, exactement comme si c'était le système de fichier DBE ou Access; mais elle profite de la fiabilité et de la cohérence du système client serveur.
Je ne vois pas pourquoi ne pas utiliser les tables, sauf si je dois comprendre quelques choses que j'ignore.

[makowski]

Pourquoi pas les Tables? pourquoi elles existent alors?

on se demande
peut être pour faire vivre ensuite les consultants pour revoir les applications quand les perfs ne sont plus au rendez vous ?

J'ai une application qui travail en local, exactement comme si c'était le système de fichier DBE ou Access; mais elle profite de la fiabilité et de la cohérence du système client serveur.

mal et un jour ou l'autre tu paiera ce mauvais choix
un serveur SQl n'est pas un serveur de fichier

Je ne vois pas pourquoi ne pas utiliser les tables, sauf si je doit comprendre quelques choses qui j'ignore.

Il y a plein de litterature la dessus nottament dans ce site
plus tout ce qui concerne la bonne gestion des transactions

[kaouane]

mal et un jour ou l'autre tu paiera ce mauvais choix
un serveur SQl n'est pas un serveur de fichier

Pardonnez moi mais ce n'est pas un choix c'est un besoin;
Je vous pose la question : Est ce pas possible de faire une application utilisant une base de donnée en local avec FireBird?

[makowski]

Pardonnez moi mais ce n'est pas un choix c'est un besoin;
Je vous pose la question : Est ce pas possible de faire une application utilisant une base de donnée en local avec FireBird?

oui sans problème
mais cela n'a rien à voir avec le fait d'utiliser des composant xTables

[edam]

quel version de FB? ibx pour FB1.5xxx si supérieur utilise plutot UIB ou autre composant; pour plus d'information

je suis d'acord avec makowski pour IBTable, IBdataset est trés bien, surtout si tu utilise les jointures, oublie le monde BD fichier, est bien venu au monde de SGBDR client/serveur,
pour FB local voir la la faq et ici
bon dev

[kaouane]

Merci beaucoup edam;
Vous êtes chaque fois très fructueux.

[Barbibulle]

Pourquoi pas les Tables? pourquoi elles existent alors?

Il faut se replacer dans le contexte de la création des composants IBx pour comprendre l'existance des IBTable.

Borland avait misé sur le BDE, pas mal d'applications monopostes étaient développées avec des bases de données fichier (de type paradox, access, etc).
Les IBTable ont pour seule vocation de permettre le passage à moindre cout (car relativement facile et similaire aux composants BDE) de ces 'petites applications' à un environnement plus client/serveur interbase ou firebird.
C'est aussi pour éviter de trop perturber les développeurs issu de BDE que les TIBTable existent, mais ce n'est que provisoire (à moins que l'application ne gère que peu de données et mono utilisateur) car très vite on se retrouve confronter à des problèmes de performances.

Donc autant démarrer les nouvelles application en utilisant les bons composants et en ayant les bons réflexes.

Pour conclure si vous utilisez les TIBTable vous perdez le principal intérêt du mode client/serveur firebird.

On ne gère pas une base de données client/serveur multi utilisateur de la même façon qu'une base de données fichier mono-poste.

[kaouane]

Je suis absolument daccord avec vous, mais le besoin des applications mono poste ne peut disparaitre; la preuve que fireBird propose la version embded.

[castorcharly]

Je suis absolument daccord avec vous, mais le besoin des applications mono poste ne peut disparaitre; la preuve que fireBird propose la version embded.

Le fait que tu travailles en mono poste n'a rien à voir avec le choix de travailler avec tel ou tel composant.

Comme te le signale Makowski, il y a beaucoup de litérature sur le "pourquoi du comment" on n'utilise pas de xTable.

Je te confirme que nous sommes nombreux à faire des petites applic mono poste et qu'on utilise jamais de xTable.

Donc cherches sur ce sujet et sur les transactions, car il y a beaucoup à apprendre grace à l'expérience de ceux qui maîtrise et qui ont regroupé dans ces explications une mine d'infos utiles.